IEAOPTxx, CNTCLIST and MPLs and DOMAINS - Init and Tuning Guide needs updating?
The following is from the Initialization and Tuning Guide... Transaction Definition for CLISTs An installation can specify whether the individual commands in a TSO/E CLIST are treated as separate TSO/E commands for transaction control. Specifying CNTCLIST=YES causes a new transaction to be started for each command in the CLIST. A possible exposure of specifying CNTCLIST=YES is that long CLISTs composed of trivial and intermediate commands might monopolize a domain's MPL slots and cause interactive terminal users to be delayed. Specifying CNTCLIST=NO (the default) causes the entire CLIST to constitute a single transaction. As I understand it, domains and MPL slots are no longer externalised with WLM Goal Mode, with WLM dynamically adjusting MPL levels to meet the service class goals. So I find it hard to see how setting CNTCLIST=YES could monopolize MPL slots. I ask because somebody has quoted this section of text as a reason not to set CNTCLIST=YES. Does this section of text need updating or removal? Also, can somebody please confirm that CNTCLIST does not apply when CLIST's/EXEC's are run in batch? Regards, Fred Schmidt M: +49 (0)1766 381 9530 | E: fschm...@cptglobal.com | W: www.cptglobal.com CPT Global Ltd Independent Experience -- Informationen (einschließlich Pflichtangaben) zu einzelnen, innerhalb der EU tätigen Gesellschaften und Zweigniederlassungen des Konzerns Deutsche Bank finden Sie unter http://www.deutsche-bank.de/de/content/pflichtangaben.htm. Diese E-Mail enthält vertrauliche und/ oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet. Please refer to http://www.db.com/en/content/eu_disclosures.htm for information (including mandatory corporate particulars) on selected Deutsche Bank branches and group companies registered or incorporated in the European Union. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEAOPTxx
Can you elaborate on this? We are running IDMS DB and DC and aren't seeing this issue. What resource are you enqueuing on? here's the update that I got from CA. Since we're a uniprocessor, my solution was to set ERV=0 which was the least worse solution. Background from issue #17033487-01 In terms of the enqueuing of batch jobs in general, our process is: 1. When a CV batch job begins, it ENQUEUES SHARED on a MAJOR name of IDMSCV and a MINOR name of BATC, where is a binary time stamp. 2. When CV gets control, RHDCCKUR attempts an ENQUEUE EXCLUSIVE on the same MAJOR and MINOR names, but since the batch job still control of the enqueue names, it goes to sleep. 3. When the cv batch job terminates, RHDCCKUR will wake up and the CV will do the necessary cleanup for the batch job. This poses a problem for IBM's WLM, ERV function. The 'sleep' scenario described above is making WLM 'misbehave'. WLM / ERV wants to increase the priority of a task that holds an enque that someone else wants. That's ERV's function. This was put in place to reduce enque lockouts, ie low priority task has enque that a higher priority task need. Even though IDMS isn't waiting on the enque, WLM 'sees' the conflict and keeps trying to give the holder more cycles. Since the holder is batch, the user basically has a batch job sucking up all the resources and IDMS keeps passing it data. This causes all CV activity to grind to a halt. When the batch job is a long-running one, it creates unacceptable delays for the online system which is now running at a lower priority than the batch job. WLM ERV is adjusting the zos dispatching priority of the jobs. This gets boosted up into the F1, F2 range (higher than the IDMS CV's) for the batch jobs; the client turns off ERV and the batch jobs stay where they belong, ie high C0, low D0 range. This method of managing ENQ resources was changed in z/OS 1.3. In this processing, ERV is overriding the Service Class management of batch jobs that we suggest in technote QI02781. IBM has stated that their ERV funcionality is working as intended. It does not include a method for ignoring some jobs that hold an ENQUEUE, or for selectively implementing the feature. The client requests that we change our processing to use a RET=TEST on the enque instead of an EXCL request, or that we use POST to communicate serialization, so that this problem can be avoided. Level2 has said that the reason we do the ENQ is to allow the CV to be notified if the Batch job goes away for some reason. Without the ENQ the batch job would remain active within the CV. This would result in resources being held indefintely (Storage, DBKEY locks, RCEs, RLEs, DPEs, etc.). We We need the Batch job to hold the ENQ so when the CV CKUR task attempts to get the ENQ it waits. If the batch job goes away, the CKUR acquires the ENQ and notifies the CV that things may need to be cleaned up. Client feels that the current methodology is one way to do it BUT it has adverse affects on performance and should be changed. IBM has said ERV is working as designed, so the CA IDMS approach has forced them to disable an important vehicle to minimize contention. CV could issue EXCL enq and if it fails, then a batch job is executing. --- Error --- The operation completed successfully. Jack Kelly 202-502-2390 (Office) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEAOPTxx
Jack, Can you elaborate on this? We are running IDMS DB and DC and aren't seeing this issue. What resource are you enqueuing on? Rex -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John Kelly Sent: Wednesday, February 04, 2009 7:59 AM To: IBM-MAIN@bama.ua.edu Subject: Re: IEAOPTxx It is the time the ENQ will be promoted. In addition to DSN Enq, I ran into the problem with CA's IDMS. It enqueues on a resource (seems to be a heart beat indicator) and batch IDMS jobs also enque on it but don't wait. These batch jobs then get ERV assignment and usually make a bad scenario worse. IBM said that there's no exclusion methodology for ERV and CA says that the way IDMS works. Jack Kelly 202-502-2390 (Office) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEAOPTxx
On Wed, 4 Feb 2009 08:58:34 -0500, John Kelly wrote: > >It is the time the ENQ will be promoted. > > >In addition to DSN Enq, I ran into the problem with CA's IDMS. It enqueues >on a resource (seems to be a heart beat indicator) and batch IDMS jobs >also enque on it but don't wait. These batch jobs then get ERV assignment >and usually make a bad scenario worse. IBM said that there's no exclusion >methodology for ERV and CA says that the way IDMS works. > Can you elaborate on what your problem was. We don't run IDMS except for CA-Dispatch. We run its archive and extract tasks externally (as STCs) and those operate like an IDMS batch job would. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEAOPTxx
It is the time the ENQ will be promoted. In addition to DSN Enq, I ran into the problem with CA's IDMS. It enqueues on a resource (seems to be a heart beat indicator) and batch IDMS jobs also enque on it but don't wait. These batch jobs then get ERV assignment and usually make a bad scenario worse. IBM said that there's no exclusion methodology for ERV and CA says that the way IDMS works. Jack Kelly 202-502-2390 (Office) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEAOPTxx
>It is the time the ENQ will be promoted. >If you have a shop that routinely submits lots of jobs that get initiated and >remain in ENQ contention, (say, everyone and their uncle wants SMF data from >tape) too high of a value is going to cause extra CPU cycles to be wasted. >You're going to promote the DP for all those ENQ holders for no reason at all >for a longer period of time. This is one of those cases where any ERV is problematic. The issue, in this case, is NOT the value of ERV. The issue is scheduling. In the case you sited, we don't let everybody's uncle near SMF. And, in Production, we address this by re-scheduling jobs so there are fewer (hopefully no) conflicts. My proposed value is for those (hopefully) rare (and short) times when an ENQ conflict cannot be avoided. If you are having constant conflicts, then adjusting the ERV is just addressing the symptoms. The real question is: "Why are we having all these contentious events"? It is the time the ENQ will be promoted.If you have a shop that routinely submits lots of jobs that get initiated and remain in ENQ contention, (say, everyone and their uncle wants SMF data from tape) too high of a value is going to cause extra CPU cycles to be wasted. You're going to promote the DP for all those ENQ holders for no reason at all for a longer period of time. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEAOPTxx
On Wed, 28 Jan 2009 21:10:10 +, Ted MacNEIL wrote: >>I almost horked my coffee. Following this thread from the beginning, I've been thinking, "Gee... I guess we're not most shops!" > >The main issue with the ENQ Reservation Value is that the default is WAY too >small. Yes, I agree. > >The second issue is what to set it to. Yes. > >When I got involved with RACF ENQ problems, we were told to set it it to 20. > >The only problem with that, is no problem. >If 200K is not enough, you have a big problem. >If 200K is too much, it doesn't matter because the task doesn't consume the rest. >It's a ceiling, not a minimum. > Sort of. It is a ceiling that could be hit over and over and over again. It is a minimum time the DP will be promoted. (I dropped this thread before because I really have no hard evidence to back up what I am about to write, nor are there any white papers etc. that I know of, nor any definitive recommendations from SHARE presentations that I can find.) Even some quoted IBM resources had different values (10K, 50K and 200K from you are all numbers I've heard so far). It is the time the ENQ will be promoted.If you have a shop that routinely submits lots of jobs that get initiated and remain in ENQ contention, (say, everyone and their uncle wants SMF data from tape) too high of a value is going to cause extra CPU cycles to be wasted. You're going to promote the DP for all those ENQ holders for no reason at all for a longer period of time. Also, I think with blocked workload support, the exact setting is less important than it was before. But not everything takes advantage of that support. I'm not a capacity / performance analyst by current job function and I don't attend / follow CMG. Perhaps someone who does can say what has been discussed at CMG about this. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEAOPTxx
On Wed, 28 Jan 2009 21:10:10 +, Ted MacNEIL wrote: >>I almost horked my coffee. Following this thread from the beginning, I've been thinking, "Gee... I guess we're not most shops!" > >The main issue with the ENQ Reservation Value is that the default is WAY too small. > >The second issue is what to set it to. > >When I got involved with RACF ENQ problems, we were told to set it it to 20. > >The only problem with that, is no problem. >If 200K is not enough, you have a big problem. >If 200K is too much, it doesn't matter because the task doesn't consume the rest. >It's a ceiling, not a minimum. > >Stop bitching about you are a big/small shop. >Just do the work to see if it's required. > >Hork your coffee, or not! >Just fix it! > >I've already been excoriated over this on another discussion group! > >I say, stop complaining and fix it! Methinks the lady doth protesteth too much. My reaction was not a complaint, my good man, nor any other form of judgement, but a slapstick response to Mark's tongue-in-cheek query as to how IBM came up with the sweeping generalization that "most shops run with a value of 50,000" and his mock offense that IBM obviously slighted his installation from inclusion in that group. But then, that's what happens when you take a sound byte out of context, instead the whole passage, including Mark's post and my parting comment: "Thanks for the laugh. Excuse me while I acquire some napkins to dry my monitor..." To wit, I say, "Slow down and buy some gas!" Regards, Art Gutowski Ford Motor Company IT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEAOPTxx
>I almost horked my coffee. Following this thread from the beginning, I've >been thinking, "Gee... I guess we're not most shops!" The main issue with the ENQ Reservation Value is that the default is WAY too small. The second issue is what to set it to. When I got involved with RACF ENQ problems, we were told to set it it to 20. The only problem with that, is no problem. If 200K is not enough, you have a big problem. If 200K is too much, it doesn't matter because the task doesn't consume the rest. It's a ceiling, not a minimum. Stop bitching about you are a big/small shop. Just do the work to see if it's required. Hork your coffee, or not! Just fix it! I've already been excoriated over this on another discussion group! I say, stop complaining and fix it! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEAOPTxx
On Fri, 23 Jan 2009 12:18:40 -0600, Mark Zelden wrote: >On Fri, 23 Jan 2009 12:52:08 -0500, Lizette Koehler > wrote: > > > >> Today, most installations run with an ERV of 5. > >Really? I wonder how IBM determined "most"? I know they didn't consult >us. :-) > I almost horked my coffee. Following this thread from the beginning, I've been thinking, "Gee... I guess we're not most shops!" Thanks for the laugh. Excuse me while I acquire some napkins to dry my monitor... Art Gutowski Ford Motor Company -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEAOPTxx
I would suggest doing the cleanup others have already pointed out, include more comments, and use mixed case i.e. SYS1.PARMLIB(IEAOPTH1) - 01.09Member IEAOPT ===> Scroll = * Top of Data * /* GEICO SRM Options */ /* */ /*TSO commands executed standalone or as CLIST are treated same */ /* default is NO. We prefer YES for consistency of reporting*/ CNTCLIST=YES, /* */ /* Enqueue Residence adjustment constant*/ /* default is 500 which is way too low! */ /* GEICO raises this significantly for enqueue and latch*/ /* holders to do a timely release on resources held with*/ /* others waiting for them. */ ERV=5, /* */ /* */ /* z9 and z9 recommended by IBM to set 10,30 per FLASH10337 */ /* default is still 0,0 */ CPENABLE=(10,30), /* */ /* Project use of zIIP engines when not installed*/ PROJECTCPU=YES /* */ /* HiperDispatch z10 support is disabled by default we turn it on*/ /* HiperDispatch will not actually be running unless on z10 */ HIPERDISPATCH=YES /* */ These are for our systems currently on z/OS 1.9 Why be stingy with comments or USE ALL UPPERCASE? In a future release of z/OS I would like to see IBM raise the default for ERV significantly perhaps to 50K, change the default for CPENABLE on a new z/OS release since they don't make BASIC mode processors anymore, change the default for HiperDispatch since it is recommended to be on. Different thread but HiperDispatch is actually quite good with large n-way machines. Two z10's and both are running with HiperDispatch. Yes Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:sknut...@geico.com (office) 301.986.3574 "Think big, act bold, start simple, grow fast..." This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEAOPTxx
>> You might want to read IBM WSC FLASH10337 concerning CPENABLE. >>The latest recommendation for the z890, z990,z9 and z10 processors in both >>basic and LPAR mode is to set CPENABLE=(10,30). IBM changes its recommendation every couple of years. I've been arguing with them ever since PR/SM came out. I kept every doc (for a while) where they changed the reco. >I thought basic mode went to the museum.. It did on either z/990, or z9 -- I can't remember which (or was it z/900?). But, I wonder what this has to do with ERV? - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEAOPTxx
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Larre Shiller > > John - > > FWIW, our ERV is set to 50,000 and it has been working without any trouble > for many years. > > You might want to read IBM WSC FLASH10337 concerning CPENABLE. The > latest recommendation for the z890, z990, z9 and z10 processors in both > basic and LPAR mode is to set CPENABLE=(10,30). I thought basic mode went to the museum.. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEAOPTxx
>Really? I wonder how IBM determined "most"? I know they didn't consult us. >:-) What do you use? With today's boxes, 50,000 may be too small. As I've said, I recommend 200,000. 'Too large' doesn't hurt. 'Too small' may! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEAOPTxx
On Fri, 23 Jan 2009 12:52:08 -0500, Lizette Koehler wrote: >There is a good REDBOOK on this topic. > >SYSTEM PROGRAMMER'S GUIDE: WORKLOAD MANAGER SG24-6472-03 (2007) > >The secion about ERV goes: > > Today, most installations run with an ERV of 5. > Really? I wonder how IBM determined "most"? I know they didn't consult us. :-) Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEAOPTxx
>Do you have a reference for that 200,000 value? I'm the capacity planner/zOS >performance analyst in my shop. The reference I have is confidential. It was through a PMR at a site I supported. But, there is common sense. If you don't need it, it doesn't matter. The key is to release the reserve. The redbook (I can't remember name or number) recomends around 50,000. But, as machines increase in power, the number becomes too small. The redbook is, I believe, two generations behind in processor speed. As my late grandmother used to say: "It couldn't hoit"! Overspecifying the value is not a risk. Undersecifying... - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEAOPTxx
John - FWIW, our ERV is set to 50,000 and it has been working without any trouble for many years. You might want to read IBM WSC FLASH10337 concerning CPENABLE. The latest recommendation for the z890, z990, z9 and z10 processors in both basic and LPAR mode is to set CPENABLE=(10,30). And other than setting DVIO=NO and HIPERDISPATCH=YES, we use all other default values. Larre Shiller US Social Security Administration -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEAOPTxx
There is a good REDBOOK on this topic. SYSTEM PROGRAMMER'S GUIDE: WORKLOAD MANAGER SG24-6472-03 (2007) The secion about ERV goes: Therefore, you should ensure that work, on average, has enough CPU service time to release the enqueue before being swapped back out again. You should verify the correct value by looking at the report and evaluating whether the default value needs any further change. Today, most installations run with an ERV of 5. Lizette >> >>The change for RMPTTOM is that with z/OS 1.9 that system now uses the >>value of 3000 for faster processors. > >z/OS 1.7 and above with APAR OA18452 - which came out in March of 2007. > > If you have a z9 or z10, or even a >>z990 (I think), you'll have the "faster" processor. However, you have >>RMPTTOM=4000, so if you want to use that value you'll need to include >>it. If you're willing to go to 3000 then take it out and use the >>default. >> > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEAOPTxx
Ted, Do you have a reference for that 200,000 value? I'm the capacity planner/zOS performance analyst in my shop. While I'm not authorized to change the system performance parms directly, they do look to me for recommendations. Since we are also planning an upgrade from z/OS 1.7 to 1.9 I've been reviewing the various parms and found that we need to increase the ERV value and probably remove the RMPTTOM entry from IEAOPTxx. So I've been doing a lot of manual reading and Googling to determine optimum values. I haven't seen anything in my research about such a high value for ERV. Tom Kelman Enterprise Capacity Planner Commerce Bank of Kansas City (816) 760-7632 > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Ted MacNEIL > Sent: Friday, January 23, 2009 11:24 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: IEAOPTxx > > >Therefore, in order to increase the likelihood of the work unit releasing > the resource within the promotion period, we recommend increasing the ERV > value to a larger value like 10,000. > > The RACF people have recommended much larger. > Like 200,000 minimum. > And, I agree. > If it's not required, and the resource is freed before 200K are consumed, > then the job is swapped out. > If 200K is not enough, you have a bigger problem. > > - > Too busy driving to stop for gas! > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEAOPTxx
Thankyou Mark. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Zelden Sent: Friday, January 23, 2009 9:21 AM To: IBM-MAIN@bama.ua.edu Subject: Re: IEAOPTxx On Fri, 23 Jan 2009 11:15:16 -0600, Kelman, Tom wrote: > >The change for RMPTTOM is that with z/OS 1.9 that system now uses the >value of 3000 for faster processors. z/OS 1.7 and above with APAR OA18452 - which came out in March of 2007. If you have a z9 or z10, or even a >z990 (I think), you'll have the "faster" processor. However, you have >RMPTTOM=4000, so if you want to use that value you'll need to include >it. If you're willing to go to 3000 then take it out and use the >default. > -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEAOPTxx
Thankyou Tom. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Kelman, Tom Sent: Friday, January 23, 2009 9:15 AM To: IBM-MAIN@bama.ua.edu Subject: Re: IEAOPTxx It is correct that several of the parameters are obsolete. So if you want to cleanup your IEAOPTxx member, check the "Tuning and Installation Guide" and "Tuning and Installation Reference" to see what ones aren't there anymore. However, the system will just ignore the obsolete parameters. The change for RMPTTOM is that with z/OS 1.9 that system now uses the value of 3000 for faster processors. If you have a z9 or z10, or even a z990 (I think), you'll have the "faster" processor. However, you have RMPTTOM=4000, so if you want to use that value you'll need to include it. If you're willing to go to 3000 then take it out and use the default. Tom Kelman Enterprise Capacity Planner Commerce Bank of Kansas City (816) 760-7632 > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Mark Zelden > Sent: Friday, January 23, 2009 11:08 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: IEAOPTxx > > On Fri, 23 Jan 2009 08:42:16 -0800, Donnelly, John P > wrote: > > >Implemented z/OS V1R9 from z/OS V1R7 with IBM default IEAOPT00: > (ERV=500). > > > >Considering setting IEAOPTxx from z/OS V1R7 system into z/OS V1R9 system: > > > >INITIMP=0, /* WLM INITIATOR DISPATCH PRIO SETTING */ > >CCCSIGUR=45, /* MEAN-TIME-TO-WAIT (DEFAULT) */ > >CNTCLIST=NO, /* CLIST SINGLE TRANS ? (DEFAULT) */ > >CPENABLE=(0,0), /* I/O ENABLE(DEFAULT) */ > >DVIO=NO, /* DIRECTED VIO ? */ > >ERV=500, /* ENQUEUE RESIDENCE VALUE (DEFAULT) */ > >ESCTSWTC(2)=350, /* EXPANDED STORAGE CRITERIA FOR TSO */ > >ESCTSWWS(2)=350, /* EXPANDED STORAGE CRITERIA FOR TSO */ > >LSCTMTE=(1,15), /* THINK TIME -- LOGICAL SWAP */ > >RCCCPUT=(105,128), /* CPU UTILIZATION (FILL 'ER UP GAZ 9/22*/ > >RCCUICT=(2,4)/* UIC THRESHOLD (DEFAULT) */ > >RMPTTOM=4000 /* DEFAULT IS 1000 REPORTS AS (18432) */ > > > > >Comments are most welcome. > > Did you try looking at the init & tuning guide at all? Many of these > are obsolete. > > No more expanded storage. Those parms are obsolete since you've been > running 64-bit (perhaps as early as OS/390 2.10 ). Certainly gone > with the ability to run 31-bit after z/OS 1.4. Lose 'em. > > LSCTMTE - obsolete (since 1.8) - lose it. > > CCCSIGUR - obsolete since goal mode, lose it. > RCCCPUT - obsolete since goal mode, lose it. > > RCCUICT - obsolete (since 1.8), lose it. > > RMPTTOM - the only place I use a non-default is my sandbox. There was > a reason to set it for a while on "fast" boxes (z990 perhaps, z9), but > IBM made some changes. There have been past discussions on this. > Search the archives. > > > -- > Mark Zelden > Sr. Software and Systems Architect - z/OS Team Lead > Zurich North America / Farmers Insurance Group - ZFUS G-ITO > mailto:mark.zel...@zurichna.com > z/OS Systems Programming expert at > http://expertanswercenter.techtarget.com/ > Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. ***
Re: IEAOPTxx
>Therefore, in order to increase the likelihood of the work unit releasing the >resource within the promotion period, we recommend increasing the ERV value to >a larger value like 10,000. The RACF people have recommended much larger. Like 200,000 minimum. And, I agree. If it's not required, and the resource is freed before 200K are consumed, then the job is swapped out. If 200K is not enough, you have a bigger problem. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEAOPTxx
On Fri, 23 Jan 2009 11:15:16 -0600, Kelman, Tom wrote: > >The change for RMPTTOM is that with z/OS 1.9 that system now uses the >value of 3000 for faster processors. z/OS 1.7 and above with APAR OA18452 - which came out in March of 2007. If you have a z9 or z10, or even a >z990 (I think), you'll have the "faster" processor. However, you have >RMPTTOM=4000, so if you want to use that value you'll need to include >it. If you're willing to go to 3000 then take it out and use the >default. > -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEAOPTxx
It is correct that several of the parameters are obsolete. So if you want to cleanup your IEAOPTxx member, check the "Tuning and Installation Guide" and "Tuning and Installation Reference" to see what ones aren't there anymore. However, the system will just ignore the obsolete parameters. The change for RMPTTOM is that with z/OS 1.9 that system now uses the value of 3000 for faster processors. If you have a z9 or z10, or even a z990 (I think), you'll have the "faster" processor. However, you have RMPTTOM=4000, so if you want to use that value you'll need to include it. If you're willing to go to 3000 then take it out and use the default. Tom Kelman Enterprise Capacity Planner Commerce Bank of Kansas City (816) 760-7632 > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Mark Zelden > Sent: Friday, January 23, 2009 11:08 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: IEAOPTxx > > On Fri, 23 Jan 2009 08:42:16 -0800, Donnelly, John P > wrote: > > >Implemented z/OS V1R9 from z/OS V1R7 with IBM default IEAOPT00: > (ERV=500). > > > >Considering setting IEAOPTxx from z/OS V1R7 system into z/OS V1R9 system: > > > >INITIMP=0, /* WLM INITIATOR DISPATCH PRIO SETTING */ > >CCCSIGUR=45, /* MEAN-TIME-TO-WAIT (DEFAULT) */ > >CNTCLIST=NO, /* CLIST SINGLE TRANS ? (DEFAULT) */ > >CPENABLE=(0,0), /* I/O ENABLE(DEFAULT) */ > >DVIO=NO, /* DIRECTED VIO ? */ > >ERV=500, /* ENQUEUE RESIDENCE VALUE (DEFAULT) */ > >ESCTSWTC(2)=350, /* EXPANDED STORAGE CRITERIA FOR TSO */ > >ESCTSWWS(2)=350, /* EXPANDED STORAGE CRITERIA FOR TSO */ > >LSCTMTE=(1,15), /* THINK TIME -- LOGICAL SWAP */ > >RCCCPUT=(105,128), /* CPU UTILIZATION (FILL 'ER UP GAZ 9/22*/ > >RCCUICT=(2,4)/* UIC THRESHOLD (DEFAULT) */ > >RMPTTOM=4000 /* DEFAULT IS 1000 REPORTS AS (18432) */ > > > > >Comments are most welcome. > > Did you try looking at the init & tuning guide at all? Many of these > are obsolete. > > No more expanded storage. Those parms are obsolete since you've been > running 64-bit (perhaps as early as OS/390 2.10 ). Certainly gone > with the ability to run 31-bit after z/OS 1.4. Lose 'em. > > LSCTMTE - obsolete (since 1.8) - lose it. > > CCCSIGUR - obsolete since goal mode, lose it. > RCCCPUT - obsolete since goal mode, lose it. > > RCCUICT - obsolete (since 1.8), lose it. > > RMPTTOM - the only place I use a non-default is my sandbox. There was > a reason to set it for a while on "fast" boxes (z990 perhaps, z9), but > IBM made some changes. There have been past discussions on this. > Search the archives. > > > -- > Mark Zelden > Sr. Software and Systems Architect - z/OS Team Lead > Zurich North America / Farmers Insurance Group - ZFUS G-ITO > mailto:mark.zel...@zurichna.com > z/OS Systems Programming expert at > http://expertanswercenter.techtarget.com/ > Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEAOPTxx
>On Fri, 23 Jan 2009 08:42:16 -0800, Donnelly, John P > wrote: > >>Implemented z/OS V1R9 from z/OS V1R7 with IBM default IEAOPT00: (ERV=500). >> >>Considering setting IEAOPTxx from z/OS V1R7 system into z/OS V1R9 system: >> >>INITIMP=0, /* WLM INITIATOR DISPATCH PRIO SETTING */ >>CCCSIGUR=45, /* MEAN-TIME-TO-WAIT (DEFAULT) */ >>CNTCLIST=NO, /* CLIST SINGLE TRANS ? (DEFAULT) */ >>CPENABLE=(0,0), /* I/O ENABLE(DEFAULT) */ >>DVIO=NO, /* DIRECTED VIO ? */ >>ERV=500, /* ENQUEUE RESIDENCE VALUE (DEFAULT) */ >>ESCTSWTC(2)=350, /* EXPANDED STORAGE CRITERIA FOR TSO */ >>ESCTSWWS(2)=350, /* EXPANDED STORAGE CRITERIA FOR TSO */ >>LSCTMTE=(1,15), /* THINK TIME -- LOGICAL SWAP */ >>RCCCPUT=(105,128), /* CPU UTILIZATION (FILL 'ER UP GAZ 9/22*/ >>RCCUICT=(2,4)/* UIC THRESHOLD (DEFAULT) */ >>RMPTTOM=4000 /* DEFAULT IS 1000 REPORTS AS (18432) */ >> > >>Comments are most welcome. > >Did you try looking at the init & tuning guide at all? Many of these >are obsolete. > >No more expanded storage. Those parms are obsolete since you've been >running 64-bit (perhaps as early as OS/390 2.10 ). Certainly gone >with the ability to run 31-bit after z/OS 1.4. Lose 'em. > >LSCTMTE - obsolete (since 1.8) - lose it. > >CCCSIGUR - obsolete since goal mode, lose it. >RCCCPUT - obsolete since goal mode, lose it. > >RCCUICT - obsolete (since 1.8), lose it. > >RMPTTOM - the only place I use a non-default is my sandbox. There was >a reason to set it for a while on "fast" boxes (z990 perhaps, z9), but >IBM made some changes. There have been past discussions on this. >Search the archives. > Oh... if you were just asking about ERV, then you may want to set that higher. Again, search the archives. There has been some disagreement as to how high (for example, Cheryl Watson may have recommended one thing and Kathy Walsh another IIRC). I think some were setting it as high as 2.I have ours set at 5000. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEAOPTxx
On Fri, 23 Jan 2009 08:42:16 -0800, Donnelly, John P wrote: >Implemented z/OS V1R9 from z/OS V1R7 with IBM default IEAOPT00: (ERV=500). > >Considering setting IEAOPTxx from z/OS V1R7 system into z/OS V1R9 system: > >INITIMP=0, /* WLM INITIATOR DISPATCH PRIO SETTING */ >CCCSIGUR=45, /* MEAN-TIME-TO-WAIT (DEFAULT) */ >CNTCLIST=NO, /* CLIST SINGLE TRANS ? (DEFAULT) */ >CPENABLE=(0,0), /* I/O ENABLE(DEFAULT) */ >DVIO=NO, /* DIRECTED VIO ? */ >ERV=500, /* ENQUEUE RESIDENCE VALUE (DEFAULT) */ >ESCTSWTC(2)=350, /* EXPANDED STORAGE CRITERIA FOR TSO */ >ESCTSWWS(2)=350, /* EXPANDED STORAGE CRITERIA FOR TSO */ >LSCTMTE=(1,15), /* THINK TIME -- LOGICAL SWAP */ >RCCCPUT=(105,128), /* CPU UTILIZATION (FILL 'ER UP GAZ 9/22*/ >RCCUICT=(2,4)/* UIC THRESHOLD (DEFAULT) */ >RMPTTOM=4000 /* DEFAULT IS 1000 REPORTS AS (18432) */ > >Comments are most welcome. Did you try looking at the init & tuning guide at all? Many of these are obsolete. No more expanded storage. Those parms are obsolete since you've been running 64-bit (perhaps as early as OS/390 2.10 ). Certainly gone with the ability to run 31-bit after z/OS 1.4. Lose 'em. LSCTMTE - obsolete (since 1.8) - lose it. CCCSIGUR - obsolete since goal mode, lose it. RCCCPUT - obsolete since goal mode, lose it. RCCUICT - obsolete (since 1.8), lose it. RMPTTOM - the only place I use a non-default is my sandbox. There was a reason to set it for a while on "fast" boxes (z990 perhaps, z9), but IBM made some changes. There have been past discussions on this. Search the archives. -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEAOPTxx
I would recommend setting the ERV value to something other than 500. This is the value in service units used to determine how long to swap in an address space when it is in ENQ contention. Processor speed has increased considerably since the 500 was first used as the IBM default. So 500 SUs isn't a very long period of time. The following is from "The z/OS Planned Outage Avoidance Checklist" Redpaper. "The default ERV value is 500 service units. However, on a 2094-701 there are nearly 30,000 service units per second, meaning that the default ERV value will result in the work unit being promoted for just 1/600th of a second. Therefore, in order to increase the likelihood of the work unit releasing the resource within the promotion period, we recommend increasing the ERV value to a larger value like 10,000." Tom Kelman Enterprise Capacity Planner Commerce Bank of Kansas City (816) 760-7632 > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Donnelly, John P > Sent: Friday, January 23, 2009 10:42 AM > To: IBM-MAIN@bama.ua.edu > Subject: IEAOPTxx > > Implemented z/OS V1R9 from z/OS V1R7 with IBM default IEAOPT00: (ERV=500). > > Considering setting IEAOPTxx from z/OS V1R7 system into z/OS V1R9 system: > > INITIMP=0, /* WLM INITIATOR DISPATCH PRIO SETTING */ > CCCSIGUR=45, /* MEAN-TIME-TO-WAIT (DEFAULT) */ > CNTCLIST=NO, /* CLIST SINGLE TRANS ? (DEFAULT) */ > CPENABLE=(0,0), /* I/O ENABLE(DEFAULT) */ > DVIO=NO, /* DIRECTED VIO ? */ > ERV=500, /* ENQUEUE RESIDENCE VALUE (DEFAULT) */ > ESCTSWTC(2)=350, /* EXPANDED STORAGE CRITERIA FOR TSO */ > ESCTSWWS(2)=350, /* EXPANDED STORAGE CRITERIA FOR TSO */ > LSCTMTE=(1,15), /* THINK TIME -- LOGICAL SWAP */ > RCCCPUT=(105,128), /* CPU UTILIZATION (FILL 'ER UP GAZ 9/22*/ > RCCUICT=(2,4)/* UIC THRESHOLD (DEFAULT) */ > RMPTTOM=4000 /* DEFAULT IS 1000 REPORTS AS (18432) */ > > Comments are most welcome. > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEAOPTxx
So, what is your question? --Original Message-- From: Donnelly, John P Sender: IBM Mainframe Discussion List To: IBM Mainframe Discussion List ReplyTo: IBM Mainframe Discussion List Sent: Jan 23, 2009 11:42 Subject: IEAOPTxx Implemented z/OS V1R9 from z/OS V1R7 with IBM default IEAOPT00: (ERV=500). Considering setting IEAOPTxx from z/OS V1R7 system into z/OS V1R9 system: INITIMP=0, /* WLM INITIATOR DISPATCH PRIO SETTING */ CCCSIGUR=45, /* MEAN-TIME-TO-WAIT (DEFAULT) */ CNTCLIST=NO, /* CLIST SINGLE TRANS ? (DEFAULT) */ CPENABLE=(0,0), /* I/O ENABLE(DEFAULT) */ DVIO=NO, /* DIRECTED VIO ? */ ERV=500, /* ENQUEUE RESIDENCE VALUE (DEFAULT) */ ESCTSWTC(2)=350, /* EXPANDED STORAGE CRITERIA FOR TSO */ ESCTSWWS(2)=350, /* EXPANDED STORAGE CRITERIA FOR TSO */ LSCTMTE=(1,15), /* THINK TIME -- LOGICAL SWAP */ RCCCPUT=(105,128), /* CPU UTILIZATION (FILL 'ER UP GAZ 9/22*/ RCCUICT=(2,4)/* UIC THRESHOLD (DEFAULT) */ RMPTTOM=4000 /* DEFAULT IS 1000 REPORTS AS (18432) */ Comments are most welcome. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
IEAOPTxx
Implemented z/OS V1R9 from z/OS V1R7 with IBM default IEAOPT00: (ERV=500). Considering setting IEAOPTxx from z/OS V1R7 system into z/OS V1R9 system: INITIMP=0, /* WLM INITIATOR DISPATCH PRIO SETTING */ CCCSIGUR=45, /* MEAN-TIME-TO-WAIT (DEFAULT) */ CNTCLIST=NO, /* CLIST SINGLE TRANS ? (DEFAULT) */ CPENABLE=(0,0), /* I/O ENABLE(DEFAULT) */ DVIO=NO, /* DIRECTED VIO ? */ ERV=500, /* ENQUEUE RESIDENCE VALUE (DEFAULT) */ ESCTSWTC(2)=350, /* EXPANDED STORAGE CRITERIA FOR TSO */ ESCTSWWS(2)=350, /* EXPANDED STORAGE CRITERIA FOR TSO */ LSCTMTE=(1,15), /* THINK TIME -- LOGICAL SWAP */ RCCCPUT=(105,128), /* CPU UTILIZATION (FILL 'ER UP GAZ 9/22*/ RCCUICT=(2,4)/* UIC THRESHOLD (DEFAULT) */ RMPTTOM=4000 /* DEFAULT IS 1000 REPORTS AS (18432) */ Comments are most welcome. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEAOPTxx options in use
Hello: Shortly after upgrading to v1.7, but not necessarily connected to that migration, one of our busier systems experienced a number of IEE178I messages during heavy batch processing. We added to IEAOPTxx: mccafcth=(4000,4500) varying the actual numbers (our capacity planning tech made the recommendations). See apar OA12185 for the explanation. There was no outage but the messages alerted the operators. regards, Joe D'Alessandro -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEAOPTxx options in use
SHOWzOS 715 display some of the values, but fails for RMPTTOM because of a change from milliseconds to microseconds in z/OS R7. This will be fixed on version 716. Our IEAOPTxx contains just RMPTTOM=2000 /*SRM INVOCATION INTERVAL IN MILLISECONDS */ /* see APAR OA18452, Circumvention until PTF */ and this will be obsolete for current releases/maintenance Roland -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Anthony Fletcher Sent: Friday, June 15, 2007 10:37 AM To: IBM-MAIN@BAMA.UA.EDU Subject: IEAOPTxx options in use According to the Initialisation and Tuning Reference, from z/OS 1.3 most IEAOPTxx options are ignored. It also says that if an option is found in IEAOPTxx that is no longer used it is just ignored. It then lists quite a long list of options that are presumably recognised and used. Is there any display or module that will show which IEAOPTxx contents have been accepted? This question arises because I am working in a z/OS 1.4 system that is being prepared for upgrade for z/OS 1.7 first part of which is to switch to z/ARCH mode. My inclination is to empty IEAOPTxx so that the z/OS 1.4 defaults, whatever they are will automatically switch to the 1.4 z/ARCH values, then to the z/OS 1.7 values. Any comments please? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEAOPTxx options in use
Anthony Fletcher wrote: According to the Initialisation and Tuning Reference, from z/OS 1.3 most IEAOPTxx options are ignored. It also says that if an option is found in IEAOPTxx that is no longer used it is just ignored. It then lists quite a long list of options that are presumably recognised and used. Is there any display or module that will show which IEAOPTxx contents have been accepted? This question arises because I am working in a z/OS 1.4 system that is being prepared for upgrade for z/OS 1.7 first part of which is to switch to z/ARCH mode. My inclination is to empty IEAOPTxx so that the z/OS 1.4 defaults, whatever they are will automatically switch to the 1.4 z/ARCH values, then to the z/OS 1.7 values. Any comments please? I'm afraid there is no display command that shows which IEAOPTxx parameter values are in effect. (We do know it would be good to have one.) -- John Eells z/OS Technical Marketing IBM Poughkeepsie [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
IEAOPTxx options in use
According to the Initialisation and Tuning Reference, from z/OS 1.3 most IEAOPTxx options are ignored. It also says that if an option is found in IEAOPTxx that is no longer used it is just ignored. It then lists quite a long list of options that are presumably recognised and used. Is there any display or module that will show which IEAOPTxx contents have been accepted? This question arises because I am working in a z/OS 1.4 system that is being prepared for upgrade for z/OS 1.7 first part of which is to switch to z/ARCH mode. My inclination is to empty IEAOPTxx so that the z/OS 1.4 defaults, whatever they are will automatically switch to the 1.4 z/ARCH values, then to the z/OS 1.7 values. Any comments please? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
