Re: ESQA allocation question
I've seen earlier items about Healthchecker and its ESQA checking, but I have a general question to which I haven't been able to find the information in the manuals. Given that ESQA will just overflow into ECSA is there any real reason not to allocate ESQA fairly low so that it is always at 100%, and then size/monitor ECSA for the combined requirements? I am aware that that would not be a good thing below the line, but I haven't read of any clear reason to 'tune' ESQA rather than ESQA/ECSA as a combined area. Since CSA/ECSA does not overflow to SQA/ESQA, a sufficiently sized SQA/ESQA prevents CSA/ECSA exhaustion from causing SQA/ESQA exhaustion. So a storage leak in CSA/ECSA or runaway allocator of CSA/ECSA wouldn't cause SQA/ESQA exhaustion. Whether or not this provides any signicant benefit to system reliability is difficult to say. My guess would be that if you exhaust CSA/ESCA your system is likely to be doomed anyway. Also, overflow of SQA/ESQA to CSA/ECSA may result in slightly longer pathlengths for some request to allocate and free SQA/ESQA storage. Whether this would result in any measurable performance degradation with your workload would be difficult to say. My guess would be that the degradation would be insignificant. It might be possible to construct an artificial testcase workload where the degradation is measurable. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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
ESQA allocation question
Hello, I've seen earlier items about Healthchecker and its ESQA checking, but I have a general question to which I haven't been able to find the information in the manuals. Given that ESQA will just overflow into ECSA is there any real reason not to allocate ESQA fairly low so that it is always at 100%, and then size/monitor ECSA for the combined requirements? I am aware that that would not be a good thing below the line, but I haven't read of any clear reason to 'tune' ESQA rather than ESQA/ECSA as a combined area. Best regards, David Tidy Tel:(31)115-67-1745 IS Technical Management/SAP-Mf Dow Benelux B.V. Mailto:[EMAIL PROTECTED] Inkoop Gbw (427) H. H. Dowweg 5 4542NM Hoek The Netherlands Handelsregisternr. 24104547 -- 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: ESQA allocation question
Given that ESQA will just overflow into ECSA is there any real reason not to allocate ESQA fairly low so that it is always at 100%, and then size/monitor ECSA for the combined requirements? I am aware that that would not be a good thing below the line, but I haven't read of any clear reason to 'tune' ESQA rather than ESQA/ECSA as a combined area. I have always been of the opinion that a little SQA/ESQA conversion is okay, but not a lot. IBM (I believe) used recommend as little as possible. But, now with 64-bit addressing, and no expanded storage I think you cannot get away with it. IIRC, IPL-processing needs more ESQA to build page tables, and that will not be allowed to overflow into CSA, since the entire system is not up yet. There's a paper on the WTC site explaining this. And, as my faded memory recalls, it might have been written by Kathy Welsh/Walsh (?). - Too busy driving to stop for gas! -- 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: ESQA allocation question
It's not too faded Ted. And yes, Walsh. ftp://ftp.software.ibm.com/software/mktsupport/techdocs/allreal_v11.pdf Ted MacNEIL [EMAIL PROTECTED] wrote: Given that ESQA will just overflow into ECSA is there any real reason not to allocate ESQA fairly low so that it is always at 100%, and then size/monitor ECSA for the combined requirements? I am aware that that would not be a good thing below the line, but I haven't read of any clear reason to 'tune' ESQA rather than ESQA/ECSA as a combined area. I have always been of the opinion that a little SQA/ESQA conversion is okay, but not a lot. IBM (I believe) used recommend as little as possible. But, now with 64-bit addressing, and no expanded storage I think you cannot get away with it. IIRC, IPL-processing needs more ESQA to build page tables, and that will not be allowed to overflow into CSA, since the entire system is not up yet. There's a paper on the WTC site explaining this. And, as my faded memory recalls, it might have been written by Kathy Welsh/Walsh (?). - Too busy driving to stop for gas! -- 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 -- 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: ESQA allocation question
It's not too faded Ted. And yes, Walsh. Thanks. I converted to 64-bit so long ago, that I had forgotten all the details. But, I remember we had to increase our ESQA allocation in order to be able to IPL. - Too busy driving to stop for gas! -- 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: ESQA allocation question
Ted MacNEIL wrote: I converted to 64-bit so long ago, that I had forgotten all the details. But, I remember we had to increase our ESQA allocation in order to be able to IPL. In our case, z/Architecture was not the culprit. It was PAVs that blew INITSQA out of the water! -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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: ESQA allocation question
snip In our case, z/Architecture was not the culprit. It was PAVs that blew INITSQA out of the water! snip Ed, Since we're finally getting to PAV, would you please expand on the problem/issue, e.g. how many PAVs and how much of an increase to the initial SQA? Jack Kelly 202-502-2390 (Office) -- 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: ESQA allocation question
Jack Kelly wrote: Ed, Since we're finally getting to PAV, would you please expand on the problem/issue, e.g. how many PAVs and how much of an increase to the initial SQA? I honesty don't remember the specifics after so many years (we upgraded to ESS (2105-800) from RVA in 2002). But, the phenomenon is documented in APAR II12396: OS/390 V2 R6 and above: SQA Space Shortage During NIP: During NIP processing, it is possible that the system's minimum allocation for SQA and extended SQA might be depleted before NIP processes the SQA parameter. To avoid this situation, you can increase the minimum SQA and/or extended SQA allocations, using the INITSQA parameter in LOADxx. (See OS/390 MVS Initialization Tuning Reference for information on the INITSQA parameter.) --- This type of storage exhaustion has been seen when adding ESS d/t2105 subsystems, since this subsystem typically requires the addition of many devices. FWIW, our LOADxx contains the following: INITSQA K 1536K -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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: ESQA allocation question
On Fri, 28 Mar 2008 15:04:34 -0400, Jack Kelly [EMAIL PROTECTED] wrote: snip In our case, z/Architecture was not the culprit. It was PAVs that blew INITSQA out of the water! snip Ed, Since we're finally getting to PAV, would you please expand on the problem/issue, e.g. how many PAVs and how much of an increase to the initial SQA? More UCBs = more ESQA. -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ESQA allocation question
Hi all, Thanks for the responses and pointer to Kathy's White Paper. It is true that we have INITSQA coded, and that was for IPL failures which we thought were related to additions/changes to the storage configuration. However it did seem that INITSQA did not actually help much - just the action of a second IPL was enough to avoid the shortage then, and anyway that is due to requirements before the IEASYS parameter is handled by the system. I say that because we have had failures even with INITSQA coded, and reIPLing without changes appears to resolve things. These were new systems - we haven't actually had the failures that recently, so I hope my memory isn't tricking me. As far as I understand from the White Paper, as long as you can comfortably support an IPL, there is no real reason to worry about ESQA filling and overflowing during the life of the system. She does mention that some installations do follow a policy of minimal allocation (though she doesn't recommend this). I think my likely conclusion is to check our systems needs after they are fully IPLed, and aim to cover that comfortably, but not to tune for the Healthchecker 80% recommendation. Ideally we would not have any spare ESQA by the next IPL, allowing us to manage ECSA and ESQA as a combined pool. Best regards, David Tidy Tel:(31)115-67-1745 IS Technical Management/SAP-Mf Fax:(31)115-67-1762 Dow Benelux B.V.Mailto:[EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: 28 March 2008 20:58 To: IBM-MAIN@bama.ua.edu Subject: Re: ESQA allocation question Since we're finally getting to PAV, would you please expand on the problem/issue, e.g. how many PAVs and how much of an increase to the initial SQA? More UCBs = more ESQA. -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
