Re: Very Lage Page Datasets (was ASM and HiperPAV)
Two years back we had an issue where the throughput of a database utility dropped considerably (job had to be cancelled because it was too slow) because it decided to not use more memory to do it's processing. This was found to be because the page datasets were more than 50% utilized. The notes below are from my analysis of the problem at the time. Some software will believe that the system is storage constrained if the page datasets are at or near 50% full. The software affected use the SYSEVENT STGTEST macro to determine how much storage it can use without affecting system paging performance. The returned values are used to set maximum sizes for such things as memory work areas. If these are small then the programs will be inefficient and use significantly more cpu and do more IOs. This should be considered when determining page dataset size. SYSEVENT STGTST behaviour from Authorized assembler Services reference manual: After SRM returns, each word contains a storage amount that represents a specific number of frames. Before you choose a number to use as the basis for decision, be aware of how your decision affects the performance of the system. The meaning of the returned values is: Use of the first number will affect system performance very little, if at all. Use of the second number might affect system performance to some degree. Use of the third number might substantially affect system performance. If you base decisions on the value in the second or third word, SRM may have to take processor storage away from other programs and replace it with auxiliary storage. If you are running your system in workload management goal mode, the value returned in the third word will always be the same as the value returned in the second word. APAR OA20116 has a note throws some light on how the second word returned from SYSEVENT STGTST is calculated: Problem conclusion The logic in IRAEVREQ was changed in a way, that the maximum of the return value 1 and return value 2 is used as return value 2 and return value 3. Additionally the logic in IRAEVREQ ensures that the value returned in words 2 and 3 do not drive the system into an auxiliary storage shortage. The value returned in words 2 and 3 will only fill the AUX subsystem up to 50%. Examples: If the AUX subsystem is filled by 25% and the return value 1 contains 1000 frames. Then the return value 2 and 3 are set to 1000 frames + 25% of the AUX slots. Walter Medenbach -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
On 02/13/12 20:03, Jim Mulder wrote: snip Just to follow up on this, APAR OA38742 has been opened. This problem was introduced in z/OS 1.13. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN I tried to look at the apar in IBMLINK and received this error; An error has occurred: * An error occurred accessing the database: RPA0 401. Is it a security/integrity apar? -- Mark Jacobs Time Customer Service Tampa, FL Learn from yesterday, live for today, hope for tomorrow. The important thing is to not stop questioning. - Albert Einstein -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
Just to follow up on this, APAR OA38742 has been opened. This problem was introduced in z/OS 1.13. I tried to look at the apar in IBMLINK and received this error; An error has occurred: * An error occurred accessing the database: RPA0 401. Is it a security/integrity apar? I get the same error. If it is an integrity apar, then *all* ASM apars dealing with abend066 or ilrcpbld errors are integrity apars (as well as information apars). My guess is that the servicelink entry into the apar database is currently broken. I called support directly for the ASM/RSM shenanigans that we currently have (at z/OS 1.12) to see the apar text that SIS denied me and the ptf number. Barbara Nitz -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
I get the same error on OA38542 and OA37992, so I think it's just SIS itself. I opened a problem. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
No problem with me (in Belgium). *OA38742: DIFFERENCE in ASMIORQR / ASMIORQC COUNTS become LARGE ENOUGH to AFFECT FRAME STEAL PROCESSING and ASMIORQR INCREMENTED TOO HIGH* During AUX paging, I/O is scheduled to drive input and/or output I/O to auxiliary page packs. When an I/O error occurs and ASM I/O completion exit gets control in ILRCMP, the abnormal termination entry point ABNMTERM: gets control for the I/O error. When this happens, the ASM I/O is redriven, causing the ASVT ASM 'received' counts to be incremented twice, thus never allowing the 'completed' counts (ASMIORQC) to equal the 'received' counts (AMIORQR). If this continues for too long, the difference between the received-completed counts grows large enough to begin impacting RSM frame steal processing. Apar has just been openend for a few days, Barbara. - Submitted date 2012-02-09 - Last modified date 2012-02-10 Hence no PTF yet; no aparfix either. Jan - On Tue, Feb 14, 2012 at 1:29 PM, Barbara Nitz nitz-...@gmx.net wrote: Just to follow up on this, APAR OA38742 has been opened. This problem was introduced in z/OS 1.13. I tried to look at the apar in IBMLINK and received this error; An error has occurred: * An error occurred accessing the database: RPA0 401. Is it a security/integrity apar? I get the same error. If it is an integrity apar, then *all* ASM apars dealing with abend066 or ilrcpbld errors are integrity apars (as well as information apars). My guess is that the servicelink entry into the apar database is currently broken. I called support directly for the ASM/RSM shenanigans that we currently have (at z/OS 1.12) to see the apar text that SIS denied me and the ptf number. Barbara Nitz -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
SIS seems to be working again. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 02/03/2012 12:19:04 PM: BTW if you have not already seen it, please look at our PMR 81276.227.000 for an agonizing saga of RSM/ASM misadventures. JO.Skip Robinson SCE Infrastructure Technology Services Just to follow up on this, APAR OA38742 has been opened. This problem was introduced in z/OS 1.13. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
Paging (if you'll pardon the pun :-) ) Don Deese and wondering what checks he has in CPExpert in this area. Might provide inspiration to z/OS Development - if Barbara's comment had spurred them to revisit this area. Cheers, Martin Martin Packer, Mainframe Performance Consultant, zChampion Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 04/02/2012 16:03:22: From: Barbara Nitz nitz-...@gmx.net To: IBM-MAIN@bama.ua.edu, Date: 04/02/2012 16:35 Subject: Re: Very Lage Page Datasets (was ASM and HiperPAV) Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Charles, I believe you're referring to the ASM_LOCAL_SLOT_USAGE check. Yes, I do. If so, this check runs at a 30 minute interval and checks the slot usage for each in-use local paging data set regardless of whether it was defined 'statically' or added via PAGE ADD. So... it does eventually recognize a changed configuration. Some of the ASM checks are set to re-run when a PAGE ADD/DELETE is issued, but ASM_LOCAL_SLOT_USAGE is currently not one of them. Open to suggestions As far as I am concerned, there is 'intelligence' missing in that check (my usual complaint with health checks). In our installation, we only have one device geometry, behind the same controller, and all page data sets are same size. So I expect the health check to recognize that adding a page ds to the overall config will relieve the 'performance impact' of 30% overall usage. Unfortunately, ASM does NOT prefer the new page ds, it is one of many, and as I indicated before, has never filled to the same slot usage as the others. Only IPL has ever evened out slot usage (and I am not talking about 1% difference, more like 20% difference on the same geometry and size! I think Skip mentioned this, too.) So the old, already-at-30%-usage locals and the new one are treated equal, so slot usage on the old ones increases over the 30% mark, and the check would still trip every 30 minutes because of that (if I hadn't set it to only check once per day until the next IPL). After it had alerted us to the condition once, it becomes basically useless for the life of the IPL. In my opinion, this health check should have the intelligence to recognize something about the configuration (same controller, same size data set) and change the checking parms accordingly, especially when a page data set was added. The check should obviously (as Kees indicated) behave differently if different percentage slot usage is due to different geometry and/or different size page ds. Now that I have established a daily graphic that shows slot utilization (as shown by Barry via MXG), I might get rid if that check completely and check my graphic instead. :-) Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
Charles, I believe you're referring to the ASM_LOCAL_SLOT_USAGE check. Yes, I do. If so, this check runs at a 30 minute interval and checks the slot usage for each in-use local paging data set regardless of whether it was defined 'statically' or added via PAGE ADD. So... it does eventually recognize a changed configuration. Some of the ASM checks are set to re-run when a PAGE ADD/DELETE is issued, but ASM_LOCAL_SLOT_USAGE is currently not one of them. Open to suggestions As far as I am concerned, there is 'intelligence' missing in that check (my usual complaint with health checks). In our installation, we only have one device geometry, behind the same controller, and all page data sets are same size. So I expect the health check to recognize that adding a page ds to the overall config will relieve the 'performance impact' of 30% overall usage. Unfortunately, ASM does NOT prefer the new page ds, it is one of many, and as I indicated before, has never filled to the same slot usage as the others. Only IPL has ever evened out slot usage (and I am not talking about 1% difference, more like 20% difference on the same geometry and size! I think Skip mentioned this, too.) So the old, already-at-30%-usage locals and the new one are treated equal, so slot usage on the old ones increases over the 30% mark, and the check would still trip every 30 minutes because of that (if I hadn't set it to only check once per day until the next IPL). After it had alerted us to the condition once, it becomes basically useless for the life of the IPL. In my opinion, this health check should have the intelligence to recognize something about the configuration (same controller, same size data set) and change the checking parms accordingly, especially when a page data set was added. The check should obviously (as Kees indicated) behave differently if different percentage slot usage is due to different geometry and/or different size page ds. Now that I have established a daily graphic that shows slot utilization (as shown by Barry via MXG), I might get rid if that check completely and check my graphic instead. :-) Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
Are you sure that this occurs at 50% Aux. storage utilization? IRA201E defines 'Critical storage shortage' at 85%. Kees. Skip Robinson jo.skip.robin...@sce.com wrote in message news:of7017747b.2f20bada-on88257999.0017af50-88257999.0018d...@sce.com ... IEE711I SYSTEM DUMP NOT TAKEN. A CRITICAL AUXILIARY STORAGE SHORTAGE EXISTS From the message manual: If the reason field shows A CRITICAL AUXILIARY STORAGE SHORTAGE EXISTS, first you need to ensure that enough DASD resource is available for captured dumps to be written out. Then, consider adding additional auxiliary storage (paging) resources, because SVC dumps will not be allowed again until the auxiliary storage utilization drops below 35%. See the system programmer response for message IRA201E for additional information about auxiliary storage utilization concerns. According to conversations at SHARE, the threshold for this condition is too conservative. AFAIK there is no APAR open to fix it. It's especially frustrating if you want to take a dump to find out who's using up AUX. ;-( . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Mark Zelden m...@mzelden.com To: IBM-MAIN@bama.ua.edu Date: 02/02/2012 07:35 PM Subject:Re: Very Lage Page Datasets (was ASM and HiperPAV) Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu On Thu, 2 Feb 2012 16:50:44 -0800, Skip Robinson jo.skip.robin...@sce.com wrote: There is a much lower limit to worry about than the one that prevents new works from starting. At around 50%, SVC dump will fail with 'ASM shortage'. This barrier has been discussed recently at SHARE. IBM agrees that SVCDUMP's ASM calculation as implemented is too strict, but it still carries the day. With no SVC dumps possible, many would consider a system hobbled. Interesting. Is there an APAR that has more detail as to when this happens? Not too long ago I know we were getting warning messages about an LPAR that had hit 50% and I'm pretty sure I saw an email from a coworker that they manually took an SVCDUMP prior to adding some additional page volumes. Regards, Mark -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
Are you sure that this occurs at 50% Aux. storage utilization? IRA201E defines 'Critical storage shortage' at 85%. See cd command, parm AUXMGMT: SDUMP,AUXMGMT=ON or OFF Specifies when SDUMP data captures should stop. ON: No new dumps are allowed when auxiliary storage usage reaches 50%. New dumps are allowed again only after the auxiliary storage usage drops below 35%. Current SDUMP data capture stops when auxiliary storage usage exceeds 68%, generating a partial dump. Don't assume that sdump uses the same lingo as ASM :-) Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
Jim, Thanks. That's exactly the sort of update I needed. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Jim Mulder Sent: Thursday, February 02, 2012 10:14 AM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] Very Lage Page Datasets (was ASM and HiperPAV) Another element of paging that has not been referenced is the ability to handle all of the swap set size in parallel. If the swap set size is 120 pages then the old practice was to have at least four LOCALS so each thirty page block of pages could be swapped-in in parallel. While swapping, like paging, is not as prevalent as it once was I'm wondering if the swap set size is still one of the principal guidelines for the number of locals that should be defined. Starting with z/OS 1.8, physical swapping is no longer done at all. Block paging has not been done for quite a while either. There can be some trimming done for address spaces when they get logically swapped, and before global LRU is done. So those pages might get written to contiguous slots to help the throughput of the output I/O. But with no swapping and block paging, they will come back in via individual page faults, with no relation to the order in which they were written, and probably as separate I/O operations. I am not trying to say that is a good thing, just saying how it works now, so that you don't spend time trying to design your paging configuration to accommodate former behavior of the operating system. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
At around 50%, SVC dump will fail with 'ASM shortage'. I think at some point, maybe 1.13, AUXMGMT=YES became the default which prevented taking dumps at a lower aux storage percentage. You can return to the previous default threshold by issuing this command: CD SET,SDUMP,AUXMGMT=OFF Reference OA30726 Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
Barbara, In regards to: 'I like the ASM health check that tells us that usage is 30% or more. (In fact, I send an automated exception email every time this happens.) I hate that ASM does not recognize that a new page data set was added. That health check stupidly doesn't recognize a changed config and still spits out the warning.' I believe you're referring to the ASM_LOCAL_SLOT_USAGE check. If so, this check runs at a 30 minute interval and checks the slot usage for each in-use local paging data set regardless of whether it was defined 'statically' or added via PAGE ADD. So... it does eventually recognize a changed configuration. Some of the ASM checks are set to re-run when a PAGE ADD/DELETE is issued, but ASM_LOCAL_SLOT_USAGE is currently not one of them. Open to suggestions Regards, Charles Mari - IBM RSM/ASM Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
On Thu, 2 Feb 2012 20:31:12 -0800, Skip Robinson jo.skip.robin...@sce.com wrote: According to conversations at SHARE, the threshold for this condition is too conservative. AFAIK there is no APAR open to fix it. It's especially frustrating if you want to take a dump to find out who's using up AUX. ;-( There's always RMF III. I've also used this REXX exec posted to IBM-MAIN by David Barnard-Brown on 09/13/2001: http://groups.google.com/group/bit.listserv.ibm-main/msg/33117230ea79eb5a?hl=en -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
On Thu, 2 Feb 2012 23:37:06 -0600, Barbara Nitz nitz-...@gmx.net wrote: Mark, this came into z/OS with either 1.11 or 1.12. Some of my pagedels were an attempt to test this behaviour. I could not test it. I saw it on this list of changed messages on z/OS 1.11. Skip, try ipcs active, and then the undocumented command (IP) ILRSLOTC. This used to be in the hidden IPCS panel that I have forgotten how to get at (there were SHARE presentations about it). Option 2.6i But I've been stuck on 1.11 since 2010 do to moving my client to 2 new data centers in 2011 and I've never seen that message and I know we have had systems over 50% aux usage and were able to take dumps. I believe what's being said here, but on face value critical is after message IRA201E (85%). Or perhaps IRA200E (70%).What seems wrong is that message IEE711I says it won't allow dumps again until you get under 35%. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
Barbara wrote: Skip, try ipcs active, and then the undocumented command (IP) ILRSLOTC. This used to be in the hidden IPCS panel that I have forgotten how to get at 2.6i is the hidden IPCS panel. MA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
Charles, My suggestion would be to add PA/PD to the set of conditions that redrive the ASM_LOCAL_SLOT_USAGE check. I know that I've occasionally added space in an attempt relieve a shortage and been dismayed that my effort *at the time* appeared not to have helped. BTW if you have not already seen it, please look at our PMR 81276.227.000 for an agonizing saga of RSM/ASM misadventures. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Charles Mari cm...@us.ibm.com To: IBM-MAIN@bama.ua.edu Date: 02/03/2012 05:46 AM Subject:Re: Very Lage Page Datasets (was ASM and HiperPAV) Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Barbara, In regards to: 'I like the ASM health check that tells us that usage is 30% or more. (In fact, I send an automated exception email every time this happens.) I hate that ASM does not recognize that a new page data set was added. That health check stupidly doesn't recognize a changed config and still spits out the warning.' I believe you're referring to the ASM_LOCAL_SLOT_USAGE check. If so, this check runs at a 30 minute interval and checks the slot usage for each in-use local paging data set regardless of whether it was defined 'statically' or added via PAGE ADD. So... it does eventually recognize a changed configuration. Some of the ASM checks are set to re-run when a PAGE ADD/DELETE is issued, but ASM_LOCAL_SLOT_USAGE is currently not one of them. Open to suggestions Regards, Charles Mari - IBM RSM/ASM Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
I think the health check's way of working, to check each page dataset for its 30%, in stead of the entire page dataset configuration, is not such a bad one. AFAIK and some earlier posts in this thread suggested it too: ASM has one or more groups of page datasets, depending on devicetype, channel configuration etc. If you have a well balanced page configuration, there will be 1 group. It selects one group and circulates through it to select a page dataset. This means that if some are 30% full, others are 30%, all have an equal chance of being selected. So with this mechanisme in mind, it is worth while signalling than 1 page dataset is 30%, because this can cause AMS inefficiency in spite of the filling of the others. (Unless I am mistaken or outdated on ASM's algorithmes). Kees. Charles Mari cm...@us.ibm.com wrote in message news:9695857008538097.wa.cmarius.ibm@bama.ua.edu... Barbara, In regards to: 'I like the ASM health check that tells us that usage is 30% or more. (In fact, I send an automated exception email every time this happens.) I hate that ASM does not recognize that a new page data set was added. That health check stupidly doesn't recognize a changed config and still spits out the warning.' I believe you're referring to the ASM_LOCAL_SLOT_USAGE check. If so, this check runs at a 30 minute interval and checks the slot usage for each in-use local paging data set regardless of whether it was defined 'statically' or added via PAGE ADD. So... it does eventually recognize a changed configuration. Some of the ASM checks are set to re-run when a PAGE ADD/DELETE is issued, but ASM_LOCAL_SLOT_USAGE is currently not one of them. Open to suggestions Regards, Charles Mari - IBM RSM/ASM Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
On Wed, 1 Feb 2012 23:12:48 -0600, Barbara Nitz nitz-...@gmx.net wrote: So if I have 5 3390-27 locals and they are all equally used at 50%, the algorithms (CPU usage, not I/O) are going to pick one of them, then do the page outs. That paging will find contiguous slots and should be efficient. BTW, this is just an example, we still try to keep our 3390-27 local usage at 30% just like we always did with smaller local page datasets in the past. I wonder what if any studies on this have been done in the lab. It would be nice if an IBM performance expert like Kathy Walsh could weigh in. I had the 'honour' of deleting and adding several local page data sets on several lpars. They were a mixture of 1.10 and 1.12, I think. What I did observe (and that clashed with what I thought I knew about ASM) is the following: 1) Adding one or more locals, I expected them to first fill up to about the same percentage as the ones that were already in use (same size page ds, much faster -new- controller). No such luck. It looked to me like *all* of them were filling up (percentage wise) in about the same manner. Meaning that the 'old' locals had about 27%, the new ones right after add 0%. A day later the old ones had 35%, the new ones 8%. About the same behaviour when adding locals of the same size on the same controller - we only have one DASD controller per sysplex, and having two was the time when we migrated from one to the other. Sounds like they all had contiguous slots and were used evenly based on that. 2) A pagedel finishes MUCH faster than it ever did. It looked like ASM is actively shifting slots away from the to-be-deleted page data set. A pagedel finishes in under a minute. This used to be a really slow process because nothing was actively done. 3) In one case, I had two locals and pagedel'd one of them. Usage of the remaining one went up to 46%, pagedel was extremely fast. I then added a new local (on a new, different, much faster controller). Usage of that one stayed at 0% for a long time, which also surprised me. *WARNING*If you are going to be replacing page datasets, better to use the REPLACE option of PAGEDEL as opposed to DELETE then doing a PAGEADD. Not doing so can lead to ESQA shortages. See the MVS commands manual for more detail. snip 6) I bemoan IBMs failure to give us a good means of figuring out who is using HVSHARE or HVCOMMON storage and how much storage-above-the-bar is actually *used*, i.e. backed. As far as I know, there still isn't any tracking done for HVCOMMON storage, no means of reporting about it. No way to know who is excessively using common storage above the bar. Same for HVSHARE. Unless you're named Jim Mulder and know where to look in a dump, us lowly customers cannot even check that in a dump. Am I mistaken in the reporting capabilities? Has that been fixed by now? Or is it another means of IBM trying to sell software service contracts to get that done only by IBM? Not to mention the frustration until you find someone who can actually *do* it. Not sure how much info you are looking for, but there is RMF III and my RXSTOR64 exec on my web site / CBT file 434. If you want to see what the sample output looks like, here is a screen shot - http://www.mzelden.com/rxstor64.html Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
Another element of paging that has not been referenced is the ability to handle all of the swap set size in parallel. If the swap set size is 120 pages then the old practice was to have at least four LOCALS so each thirty page block of pages could be swapped-in in parallel. While swapping, like paging, is not as prevalent as it once was I'm wondering if the swap set size is still one of the principal guidelines for the number of locals that should be defined. Starting with z/OS 1.8, physical swapping is no longer done at all. Block paging has not been done for quite a while either. There can be some trimming done for address spaces when they get logically swapped, and before global LRU is done. So those pages might get written to contiguous slots to help the throughput of the output I/O. But with no swapping and block paging, they will come back in via individual page faults, with no relation to the order in which they were written, and probably as separate I/O operations. I am not trying to say that is a good thing, just saying how it works now, so that you don't spend time trying to design your paging configuration to accommodate former behavior of the operating system. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
I wonder what if any studies on this have been done in the lab. It would be nice if an IBM performance expert like Kathy Walsh could weigh in. The last performance studies I remember for paging were around the time of MVS XA/SP2.2.0. Very little has been done in the area of paging performance since then except for the PAV stuff to allow two concurrent operations to a page data set. I had the 'honour' of deleting and adding several local page data sets on several lpars. They were a mixture of 1.10 and 1.12, I think. What I did observe (and that clashed with what I thought I knew about ASM) is the following: 1) Adding one or more locals, I expected them to first fill up to about the same percentage as the ones that were already in use (same size page ds, much faster -new- controller). No such luck. It looked to me like *all* of them were filling up (percentage wise) in about the same manner. Meaning that the 'old' locals had about 27%, the new ones right after add 0%. A day later the old ones had 35%, the new ones 8%. About the same behaviour when adding locals of the same size on the same controller - we only have one DASD controller per sysplex, and having two was the time when we migrated from one to the other. The page data set selection algorithm considers service time for the devices, but not the full percentage. One could argue that the full percentage should be considered, since it affects the likihood of finding contiguous slots, and the CPU time to find available slots, but that is not how it currently works. 2) A pagedel finishes MUCH faster than it ever did. It looked like ASM is actively shifting slots away from the to-be-deleted page data set. A pagedel finishes in under a minute. This used to be a really slow process because nothing was actively done. Pagedel has always done active removal. There were some problems with doing active removal of VIO in the original SP3.1.0 implementation, but that was fixed in SP3.1.3. 6) I bemoan IBMs failure to give us a good means of figuring out who is using HVSHARE or HVCOMMON storage and how much storage-above-the- bar is actually *used*, i.e. backed. As far as I know, there still isn't any tracking done for HVCOMMON storage, no means of reporting about it. No way to know who is excessively using common storage above the bar. Same for HVSHARE. Unless you're named Jim Mulder and know where to look in a dump, us lowly customers cannot even check that in a dump. Am I mistaken in the reporting capabilities? Has that been fixed by now? Or is it another means of IBM trying to sell software service contracts to get that done only by IBM? Not to mention the frustration until you find someone who can actually *do* it. IPCS has RSMDATA HVCOMMON. That at least tells you the owner of the memory objects. For HVCOMMON which is obtained via the IARST64 macro, the IARST64 macro says: There is diagnostic support for 64 bit cell pools, created by IARST64, in IPCS via the CBFORMAT command. In order to locate the cell pool of interest, you need to follow the pointers from HP1, to HP2, to the CPHD. For common storage, the HP1 is located in the ECVT. CBF ECVT will format the ECVT, then do a FIND on HP1. Extract the address of the HP1 from the ECVT and CBF addrhp1 STR(HP1) will format the HP1. Each entry in the HP1 represents an attribute set (storage key, storage type (pageable, DREF, FIXED), and Fetch Protection (ON or OFF)) The output from this command will contain CBF commands for any connected HP2s.Select the CBF command of interest and run it to format the HP2. The HP2 consists of pointers to cell pool headers for different sizes. Choose the size of interest and select the command that will look like this: CBF addrcphd STR(IAXCPHD). This will format the cell pool header. To see details about all of the cells in the pool, use the EXIT option as follows: CBF addrcphd STR(IAXCPHD) EXIT. For private storage, the HP1 is anchored in the STCB. The quickest way to locate the HP1 is to run the SUMMARY FORMAT command for the address space of interest. Locate the TCB that owns the storage of interest and then scroll down to the formatted STCB. The HP1 field contains the address of the HP1. From here, the processing is the same as described for common storage above. You can also use the EXIT option as follows: CBF addrhp1 STR(HP1) EXIT to produce a report that summarizes the storage usage under that HP1. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
Jim Mulder d10j...@us.ibm.com wrote in message news:of15dad2d4.112617be-on85257998.0064c1d8-85257998.0066c...@us.ibm.c om... I wonder what if any studies on this have been done in the lab. It would be nice if an IBM performance expert like Kathy Walsh could weigh in. The last performance studies I remember for paging were around the time of MVS XA/SP2.2.0. Very little has been done in the area of paging performance since then except for the PAV stuff to allow two concurrent operations to a page data set. This almost 'requires' a new study, especially since those ancient studies require/recommend us to leave 70+% of a 3390-27 (17GB per page dataset) free for some algorithme that required it decades ago for devices from decades ago. I still am under the impression that leaving 70% of a 3390-3 free will equal leaving them same 2GB free on a 3390-27. Well ok, to avoid the 70% full messages, I am willing to leave 7.5GB free, but I would like to see studies that proves it benificial to leave the other 10GB free. Thanks Jim, for letting the bull out of the barn... Someone has to get it in again. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
On Thu, 2 Feb 2012 13:42:45 -0500, Jim Mulder d10j...@us.ibm.com wrote: I wonder what if any studies on this have been done in the lab. It would be nice if an IBM performance expert like Kathy Walsh could weigh in. Thanks for jumping in Jim! I hoped you or Peter would eventually to clear up some of this FUD. The last performance studies I remember for paging were around the time of MVS XA/SP2.2.0. Very little has been done in the area of paging performance since then except for the PAV stuff to allow two concurrent operations to a page data set. Even though zero demand paging is best and what many shops strive / configure for these days, I think it's time for a new study based on modern architecture and what the OS now does. The page data set selection algorithm considers service time for the devices, but not the full percentage. One could argue that the full percentage should be considered, since it affects the likihood of finding contiguous slots, and the CPU time to find available slots, but that is not how it currently works. I'm going to take a giant leap of faith here and say there is zero to negligible performance impact in having a farm of 3390-27 local page datasets running at 50% full compared to having them at 30% (or less). Maybe 69% is fine too. No higher - we certainly don't want to hit that 70% MCCASMT1 threshold! :-) Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
I liked Barry's plot the curve approach to this i.e. Relating occupation to performance. Cheers, Martin Martin Packer, Mainframe Performance Consultant, zChampion Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
On Thu, 2 Feb 2012 21:48:17 +, Martin Packer martin_pac...@uk.ibm.com wrote: I liked Barry's plot the curve approach to this i.e. Relating occupation to performance. What is the SSCH count in VMAC74? SIO74CNT ? With a static environment for the most part (except after IPL when all the subsystems are coming active), and enough real storage to (usually) have a demand paging rate of zero, and page data sets =30% full, how will I find where the knee is located? A lab environment is needed. I guess I could do this in a sandbox LPAR, but I'm not *that* interested. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
There is a much lower limit to worry about than the one that prevents new works from starting. At around 50%, SVC dump will fail with 'ASM shortage'. This barrier has been discussed recently at SHARE. IBM agrees that SVCDUMP's ASM calculation as implemented is too strict, but it still carries the day. With no SVC dumps possible, many would consider a system hobbled. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Mark Zelden m...@mzelden.com To: IBM-MAIN@bama.ua.edu Date: 02/02/2012 01:02 PM Subject:Re: Very Lage Page Datasets (was ASM and HiperPAV) Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu On Thu, 2 Feb 2012 13:42:45 -0500, Jim Mulder d10j...@us.ibm.com wrote: I wonder what if any studies on this have been done in the lab. It would be nice if an IBM performance expert like Kathy Walsh could weigh in. Thanks for jumping in Jim! I hoped you or Peter would eventually to clear up some of this FUD. The last performance studies I remember for paging were around the time of MVS XA/SP2.2.0. Very little has been done in the area of paging performance since then except for the PAV stuff to allow two concurrent operations to a page data set. Even though zero demand paging is best and what many shops strive / configure for these days, I think it's time for a new study based on modern architecture and what the OS now does. The page data set selection algorithm considers service time for the devices, but not the full percentage. One could argue that the full percentage should be considered, since it affects the likihood of finding contiguous slots, and the CPU time to find available slots, but that is not how it currently works. I'm going to take a giant leap of faith here and say there is zero to negligible performance impact in having a farm of 3390-27 local page datasets running at 50% full compared to having them at 30% (or less). Maybe 69% is fine too. No higher - we certainly don't want to hit that 70% MCCASMT1 threshold! :-) Regards, Mark -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
On Thu, 2 Feb 2012 16:50:44 -0800, Skip Robinson jo.skip.robin...@sce.com wrote: There is a much lower limit to worry about than the one that prevents new works from starting. At around 50%, SVC dump will fail with 'ASM shortage'. This barrier has been discussed recently at SHARE. IBM agrees that SVCDUMP's ASM calculation as implemented is too strict, but it still carries the day. With no SVC dumps possible, many would consider a system hobbled. Interesting. Is there an APAR that has more detail as to when this happens? Not too long ago I know we were getting warning messages about an LPAR that had hit 50% and I'm pretty sure I saw an email from a coworker that they manually took an SVCDUMP prior to adding some additional page volumes. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
IEE711I SYSTEM DUMP NOT TAKEN. A CRITICAL AUXILIARY STORAGE SHORTAGE EXISTS From the message manual: If the reason field shows A CRITICAL AUXILIARY STORAGE SHORTAGE EXISTS, first you need to ensure that enough DASD resource is available for captured dumps to be written out. Then, consider adding additional auxiliary storage (paging) resources, because SVC dumps will not be allowed again until the auxiliary storage utilization drops below 35%. See the system programmer response for message IRA201E for additional information about auxiliary storage utilization concerns. According to conversations at SHARE, the threshold for this condition is too conservative. AFAIK there is no APAR open to fix it. It's especially frustrating if you want to take a dump to find out who's using up AUX. ;-( . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Mark Zelden m...@mzelden.com To: IBM-MAIN@bama.ua.edu Date: 02/02/2012 07:35 PM Subject:Re: Very Lage Page Datasets (was ASM and HiperPAV) Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu On Thu, 2 Feb 2012 16:50:44 -0800, Skip Robinson jo.skip.robin...@sce.com wrote: There is a much lower limit to worry about than the one that prevents new works from starting. At around 50%, SVC dump will fail with 'ASM shortage'. This barrier has been discussed recently at SHARE. IBM agrees that SVCDUMP's ASM calculation as implemented is too strict, but it still carries the day. With no SVC dumps possible, many would consider a system hobbled. Interesting. Is there an APAR that has more detail as to when this happens? Not too long ago I know we were getting warning messages about an LPAR that had hit 50% and I'm pretty sure I saw an email from a coworker that they manually took an SVCDUMP prior to adding some additional page volumes. Regards, Mark -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
If the reason field shows A CRITICAL AUXILIARY STORAGE SHORTAGE EXISTS, first you need to ensure that enough DASD resource is available for captured dumps to be written out. Then, consider adding additional auxiliary storage (paging) resources, because SVC dumps will not be allowed again until the auxiliary storage utilization drops below 35%. See the system programmer response for message IRA201E for additional information about auxiliary storage utilization concerns. According to conversations at SHARE, the threshold for this condition is too conservative. AFAIK there is no APAR open to fix it. It's especially frustrating if you want to take a dump to find out who's using up AUX. ;-( Mark, this came into z/OS with either 1.11 or 1.12. Some of my pagedels were an attempt to test this behaviour. I could not test it. Skip, try ipcs active, and then the undocumented command (IP) ILRSLOTC. This used to be in the hidden IPCS panel that I have forgotten how to get at (there were SHARE presentations about it). This command works on active storage. No need for a dump in an AUX shortage to determine who holds the slots: VERSION 02/18/2010 ASID=00A4 JOB=DSW1DBM1 SLOTCOUNT=99EB VIO COUNT= ASID=00A3 JOB=DSNXDBM1 SLOTCOUNT=8B0F VIO COUNT= ASID=002E JOB=ZFS SLOTCOUNT=2F26 VIO COUNT= Jim, we talked about the need for an HVCOMMON storage tracking tool before. In a pinch, someone with a lot of knowledge of IPCS could probably find out who did what. I seem to remember you agreeing that the procedure you summarized neatly in your post :-) is not something one wants to do manually. Has anyone submitted a requirement for this on my behalf? I am still willing to have the requirement submitted, and I think that some regulars on ibmmain would agree that it were a good thing! Some might even concur with such a requirement. *WARNING*If you are going to be replacing page datasets, better to use the REPLACE option of PAGEDEL as opposed to DELETE then doing a PAGEADD. Not doing so can lead to ESQA shortages. Thanks for the warning. Unfortunately, my spaceadmin needed to reuse the name of the page data set, so there was no way I could use REPLACE. I'll keep that in mind for our pageds redesign, though. Starting with z/OS 1.8, physical swapping is no longer done at all. Block paging has not been done for quite a while either. There can be some trimming done for address spaces when they get logically swapped, and before global LRU is done. So those pages might get written to contiguous slots to help the throughput of the output I/O. But with no swapping and block paging, they will come back in via individual page faults, with no relation to the order in which they were written, and probably as separate I/O operations. That explains why (MXG) fields BLKPAGE BLKSAUIN PGBKAUIN are still filled. I'll ignore this for my colourful pictures, then! Pagedel has always done active removal. There were some problems with doing active removal of VIO in the original SP3.1.0 implementation, but that was fixed in SP3.1.3. This is interesting, given that I wasn't around for SP3. I just remember that it used to take hours to empty a page data set, SP4 right up until z/OS 1.4 (I think might have been the last time I tried). Even though zero demand paging is best and what many shops strive / configure for these days, I think it's time for a new study based on modern architecture and what the OS now does. I agree. Unfortunately, we have lots of demand paging (we are a small installation, after all), and all the newfangled applications are just storage-hungry in the typical clicker way of what's a few Terabyte more. Maybe then ASM would better use available space and better thresholds. I guess I'll need to bite the bullit and try to find the knee. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
Wow. Very interesting. PFA was just complaining about super hog address space DA20DBM1. Here's what ILRSLOTC shows as the top piggy: VERSION 02/18/2010 ASID=0079 JOB=DA20DBM1 SLOTCOUNT=00029E21 VIO COUNT= I love it when a picture comes together. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Barbara Nitz nitz-...@gmx.net To: IBM-MAIN@bama.ua.edu Date: 02/02/2012 09:47 PM Subject:Re: Very Lage Page Datasets (was ASM and HiperPAV) Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu If the reason field shows A CRITICAL AUXILIARY STORAGE SHORTAGE EXISTS, first you need to ensure that enough DASD resource is available for captured dumps to be written out. Then, consider adding additional auxiliary storage (paging) resources, because SVC dumps will not be allowed again until the auxiliary storage utilization drops below 35%. See the system programmer response for message IRA201E for additional information about auxiliary storage utilization concerns. According to conversations at SHARE, the threshold for this condition is too conservative. AFAIK there is no APAR open to fix it. It's especially frustrating if you want to take a dump to find out who's using up AUX. ;-( Mark, this came into z/OS with either 1.11 or 1.12. Some of my pagedels were an attempt to test this behaviour. I could not test it. Skip, try ipcs active, and then the undocumented command (IP) ILRSLOTC. This used to be in the hidden IPCS panel that I have forgotten how to get at (there were SHARE presentations about it). This command works on active storage. No need for a dump in an AUX shortage to determine who holds the slots: VERSION 02/18/2010 ASID=00A4 JOB=DSW1DBM1 SLOTCOUNT=99EB VIO COUNT= ASID=00A3 JOB=DSNXDBM1 SLOTCOUNT=8B0F VIO COUNT= ASID=002E JOB=ZFS SLOTCOUNT=2F26 VIO COUNT= Jim, we talked about the need for an HVCOMMON storage tracking tool before. In a pinch, someone with a lot of knowledge of IPCS could probably find out who did what. I seem to remember you agreeing that the procedure you summarized neatly in your post :-) is not something one wants to do manually. Has anyone submitted a requirement for this on my behalf? I am still willing to have the requirement submitted, and I think that some regulars on ibmmain would agree that it were a good thing! Some might even concur with such a requirement. *WARNING*If you are going to be replacing page datasets, better to use the REPLACE option of PAGEDEL as opposed to DELETE then doing a PAGEADD. Not doing so can lead to ESQA shortages. Thanks for the warning. Unfortunately, my spaceadmin needed to reuse the name of the page data set, so there was no way I could use REPLACE. I'll keep that in mind for our pageds redesign, though. Starting with z/OS 1.8, physical swapping is no longer done at all. Block paging has not been done for quite a while either. There can be some trimming done for address spaces when they get logically swapped, and before global LRU is done. So those pages might get written to contiguous slots to help the throughput of the output I/O. But with no swapping and block paging, they will come back in via individual page faults, with no relation to the order in which they were written, and probably as separate I/O operations. That explains why (MXG) fields BLKPAGE BLKSAUIN PGBKAUIN are still filled. I'll ignore this for my colourful pictures, then! Pagedel has always done active removal. There were some problems with doing active removal of VIO in the original SP3.1.0 implementation, but that was fixed in SP3.1.3. This is interesting, given that I wasn't around for SP3. I just remember that it used to take hours to empty a page data set, SP4 right up until z/OS 1.4 (I think might have been the last time I tried). Even though zero demand paging is best and what many shops strive / configure for these days, I think it's time for a new study based on modern architecture and what the OS now does. I agree. Unfortunately, we have lots of demand paging (we are a small installation, after all), and all the newfangled applications are just storage-hungry in the typical clicker way of what's a few Terabyte more. Maybe then ASM would better use available space and better thresholds. I guess I'll need to bite the bullit and try to find the knee. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
Wow. Very interesting. PFA was just complaining about super hog address space DA20DBM1. Here's what ILRSLOTC shows as the top piggy: VERSION 02/18/2010 ASID=0079 JOB=DA20DBM1 SLOTCOUNT=00029E21 VIO COUNT= I love it when a picture comes together. Yeah, and the DB admins will tell you that this is normal. Happens here all the time. On the pretext of 'someone else is the hog and we are just the innocent bystanders. We *need* this'. Guess why I complain about the code that just gets a HUGE chunk of storage, touches every page (causing it to get backed) and then to become a slot in some page dataset, probably never to get touched again. :-( And I haven't really found a way to find those that hog storage above the bar and never really use it. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
How about a new keyword DUMP=dsn,dsn similar to LOCAL=dsn,dsn for a Local paging dsn used only for dumps? On Thu, Feb 2, 2012 at 10:31 PM, Skip Robinson jo.skip.robin...@sce.com wrote: IEE711I SYSTEM DUMP NOT TAKEN. A CRITICAL AUXILIARY STORAGE SHORTAGE EXISTS From the message manual: If the reason field shows A CRITICAL AUXILIARY STORAGE SHORTAGE EXISTS, first you need to ensure that enough DASD resource is available for captured dumps to be written out. Then, consider adding additional auxiliary storage (paging) resources, because SVC dumps will not be allowed again until the auxiliary storage utilization drops below 35%. See the system programmer response for message IRA201E for additional information about auxiliary storage utilization concerns. According to conversations at SHARE, the threshold for this condition is too conservative. AFAIK there is no APAR open to fix it. It's especially frustrating if you want to take a dump to find out who's using up AUX. ;-( -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
On Tue, 31 Jan 2012 22:49:53 -0600, Barbara Nitz nitz-...@gmx.net wrote: Writing to contiguous slots and over allocation is mentioned, but unless I missed it the old ROT (and health check) of not having more than 30% of the slots allocated is not specifically addressed. Certainly with 4K pages (for the most part) and 3390-27 (or bigger) that 30% ROT doesn't apply anymore?50% of a mod-27 is still a helava lot of free slots. I think it still applies. My understanding has always been that the 30% usage (after which paging effectiveness drastically drops) applies to the algorithm used on the in-storage control blocks to pick the next free slot in a page data set. Unless that algorithm was redesigned, 30% of 44.9GB per page dataset is what you should not exceed (just as the health check says) in AUX usage. Redesign of that is IMHO unlikely, just as using more than 2 IOs on a page data set simultaneously would require (an unlikely) redesign. That sounds right as far as the algorithm, but I thought the paging effectiveness was related to likelihood of not being able to find contiguous slots for group page outs after the 30% usage (based on old technology). So if I have 5 3390-27 locals and they are all equally used at 50%, the algorithms (CPU usage, not I/O) are going to pick one of them, then do the page outs. That paging will find contiguous slots and should be efficient. BTW, this is just an example, we still try to keep our 3390-27 local usage at 30% just like we always did with smaller local page datasets in the past. I wonder what if any studies on this have been done in the lab. It would be nice if an IBM performance expert like Kathy Walsh could weigh in. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
I'm sure I don't count as like Kathy* :-) but... Contiguous Slot Allocation Algorithm is still in place so I also tout the 30% but... 1) I say this is not a falling off a cliff thing but hazard it to be more gradual than that - so a dynamic. 2) I also suggest people aim for free paging space generally 1.5x the LPAR's memory. Item 2 is a ROT I made up myself. :-) It's motivated by the need to have something to dump into - and it leans in the same direction as the Cont Slot Alloc Algorithm. I'm not sure the 1.5x number is right... ... I consider both the 30% and my 1.5x as STARTING POINTS. And I emphasise good paging subsystem design and adequate memory provision - even now. So I'm really glad we're having this conversation. Martin Martin Packer, Mainframe Performance Consultant, zChampion Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker * Kathy's the real expert to defer to From: Mark Zelden m...@mzelden.com To: IBM-MAIN@bama.ua.edu, Date: 01/02/2012 15:48 Subject: Re: Very Lage Page Datasets (was ASM and HiperPAV) Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu On Tue, 31 Jan 2012 22:49:53 -0600, Barbara Nitz nitz-...@gmx.net wrote: Writing to contiguous slots and over allocation is mentioned, but unless I missed it the old ROT (and health check) of not having more than 30% of the slots allocated is not specifically addressed. Certainly with 4K pages (for the most part) and 3390-27 (or bigger) that 30% ROT doesn't apply anymore?50% of a mod-27 is still a helava lot of free slots. I think it still applies. My understanding has always been that the 30% usage (after which paging effectiveness drastically drops) applies to the algorithm used on the in-storage control blocks to pick the next free slot in a page data set. Unless that algorithm was redesigned, 30% of 44.9GB per page dataset is what you should not exceed (just as the health check says) in AUX usage. Redesign of that is IMHO unlikely, just as using more than 2 IOs on a page data set simultaneously would require (an unlikely) redesign. That sounds right as far as the algorithm, but I thought the paging effectiveness was related to likelihood of not being able to find contiguous slots for group page outs after the 30% usage (based on old technology). So if I have 5 3390-27 locals and they are all equally used at 50%, the algorithms (CPU usage, not I/O) are going to pick one of them, then do the page outs. That paging will find contiguous slots and should be efficient. BTW, this is just an example, we still try to keep our 3390-27 local usage at 30% just like we always did with smaller local page datasets in the past. I wonder what if any studies on this have been done in the lab. It would be nice if an IBM performance expert like Kathy Walsh could weigh in. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
MXG added variable SLOTUTIL back in '97 with this change text: Change 15.064 Variable SLOTUTIL is added to dataset TYPE71 to measure VMAC71 the percentage of local page dataset slots that are in Apr 28, 1997 use. Find the maximum value of SLOTUTIL during the month to make sure you have enough page dataset slots defined. SLOTUTIL should always be less than 25% (because the ASM's contiguous slot allocation algorithm can move 30 pages in one SSCH only when there are 30 contiguous free slots, and at utilizations above 25%, ASM begins to not find 30 slots, so it tries to find 15, then 8... which causes lots of extra SSCHs to your page volumes at the very worst possible time - those few times when paging becomes a performance problem!). I have preached this concept, but had not provided the variable (and the value I used in class turns out to need to be changed): SLOTUTIL=(SLOTLOMN-SLOTUNMN)/SLOTLOMN; compares the minimum number of defined local slots with the minimum number of unused local slots to calculate the maximum utilization of slots during the interval. That note was based on a CMG or SHARE presentation I had attended years earlier, when the contiguous slot allocation algorithm was first being used, and the presentation was a smooth curve, output from a model, rather than actual measurements, so there was no real knee of the curve, but somewhere in the 25-30% range was noted as the beginning of possible pain. Since one of the consequences of breaking the contiguous slot allocation is an increase in the number of SSCHs to the paging volumes, and since you all have dedicated devices, you should be able to plot the SSCH count to your local page datasets from RMF 74 records versus the SLOTUTIL from the 71 to see where your site's knee is located. Barry Merrill -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Barbara Nitz Sent: Tuesday, January 31, 2012 10:50 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Very Lage Page Datasets (was ASM and HiperPAV) Writing to contiguous slots and over allocation is mentioned, but unless I missed it the old ROT (and health check) of not having more than 30% of the slots allocated is not specifically addressed. Certainly with 4K pages (for the most part) and 3390-27 (or bigger) that 30% ROT doesn't apply anymore?50% of a mod-27 is still a helava lot of free slots. I think it still applies. My understanding has always been that the 30% usage (after which paging effectiveness drastically drops) applies to the algorithm used on the in-storage control blocks to pick the next free slot in a page data set. Unless that algorithm was redesigned, 30% of 44.9GB per page dataset is what you should not exceed (just as the health check says) in AUX usage. Redesign of that is IMHO unlikely, just as using more than 2 IOs on a page data set simultaneously would require (an unlikely) redesign. Sometimes the need for the appearance of an autonomic, self-healing system becomes more important than the need for an autonomic, self-healing system. ;-) But, you're also saying close to 50% of health checks are useful, so that's good thing. I consider about 30 of the 180-200 checks (1.12) useful. Otherwise I'll stay out of *this* discussion. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
So if I have 5 3390-27 locals and they are all equally used at 50%, the algorithms (CPU usage, not I/O) are going to pick one of them, then do the page outs. That paging will find contiguous slots and should be efficient. BTW, this is just an example, we still try to keep our 3390-27 local usage at 30% just like we always did with smaller local page datasets in the past. I wonder what if any studies on this have been done in the lab. It would be nice if an IBM performance expert like Kathy Walsh could weigh in. I had the 'honour' of deleting and adding several local page data sets on several lpars. They were a mixture of 1.10 and 1.12, I think. What I did observe (and that clashed with what I thought I knew about ASM) is the following: 1) Adding one or more locals, I expected them to first fill up to about the same percentage as the ones that were already in use (same size page ds, much faster -new- controller). No such luck. It looked to me like *all* of them were filling up (percentage wise) in about the same manner. Meaning that the 'old' locals had about 27%, the new ones right after add 0%. A day later the old ones had 35%, the new ones 8%. About the same behaviour when adding locals of the same size on the same controller - we only have one DASD controller per sysplex, and having two was the time when we migrated from one to the other. 2) A pagedel finishes MUCH faster than it ever did. It looked like ASM is actively shifting slots away from the to-be-deleted page data set. A pagedel finishes in under a minute. This used to be a really slow process because nothing was actively done. 3) In one case, I had two locals and pagedel'd one of them. Usage of the remaining one went up to 46%, pagedel was extremely fast. I then added a new local (on a new, different, much faster controller). Usage of that one stayed at 0% for a long time, which also surprised me. 4) I like the ASM health check that tells us that usage is 30% or more. (In fact, I send an automated exception email every time this happens.) I hate that ASM does not recognize that a new page data set was added. That health check stupidly doesn't recognize a changed config and still spits out the warning. ASM also doesn't do anything active to level out slot usage on a new local. Usage only levels out after the next IPL. 5) I wonder if the behaviour I witnessed is due to applications (written by clickers with no z/OS clue) taking *a lot* - in the GB range - of above- the-bar storage, getting that backed by 'initializing' and then never use it, causing all those backed frames to become slots for the live of the IPL. Yes, I am talking primarily about the stuff that has feet in OMVS, where typically clickers write the code. 6) I bemoan IBMs failure to give us a good means of figuring out who is using HVSHARE or HVCOMMON storage and how much storage-above-the-bar is actually *used*, i.e. backed. As far as I know, there still isn't any tracking done for HVCOMMON storage, no means of reporting about it. No way to know who is excessively using common storage above the bar. Same for HVSHARE. Unless you're named Jim Mulder and know where to look in a dump, us lowly customers cannot even check that in a dump. Am I mistaken in the reporting capabilities? Has that been fixed by now? Or is it another means of IBM trying to sell software service contracts to get that done only by IBM? Not to mention the frustration until you find someone who can actually *do* it. Barry, thank you very much for pointing out the MXG SLOTUTIL thing. I am now off to reading in the TYPE71 records and doing nice coloured pictures! Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
All, Another element of paging that has not been referenced is the ability to handle all of the swap set size in parallel. If the swap set size is 120 pages then the old practice was to have at least four LOCALS so each thirty page block of pages could be swapped-in in parallel. While swapping, like paging, is not as prevalent as it once was I'm wondering if the swap set size is still one of the principal guidelines for the number of locals that should be defined. For HDS VSP customers there is a new facility called MF-HDP that allows for some very wide striping of volumes across the available spindles. If you are using or plan to use MF-HDP then LOCALS would be very good candidates for HDP pool volumes. You can allocate a 3390-3, 9, 27, 54 or A as a virtual volume within the pool, but initially the space you use will be a 672 track block that contains the volume label, VTOC, Index and VVDS. Then when you define and format you LOCAL you will only use space equal to the size of the page dataset rounded up to 672 tracks. So if you want to allocate a 3390-54 for your locals, but only make them 5000 CYLS in size you should go for it, because the 60020 CYLS of empty space won't actually use any space in the HDP pool. If you handled this concept on Iceberg and the RVA then you're well on your way to wrapping your head around this with MF-HDP? The other advantage of this is the wide striping I mentioned. Each 30 page set of contiguous slots will be within the same page, but the page is striped across the underlying parity group disks. There won't be much advantage for block page-in for each set of thirty pages, but you don't have to worry about hand placing all your locals across the parity groups. The wide striping will uniformly distribute all the page datasets across all the underlying parity groups and disks. If you have 128 parity groups of R6 6D+2P then the read miss and destage activity of your locals, no matter how many, will be uniformly spread across 1024 disk drives. Ignoring UCB constraints, it kind of makes minimizing the number of locals an academic exercise. If you think you need eight locals then allocate sixteen that are half the size on 3390-A. You will still only use the same amount of disk space. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Barbara Nitz Sent: Wednesday, February 01, 2012 9:13 PM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] Very Lage Page Datasets (was ASM and HiperPAV) So if I have 5 3390-27 locals and they are all equally used at 50%, the algorithms (CPU usage, not I/O) are going to pick one of them, then do the page outs. That paging will find contiguous slots and should be efficient. BTW, this is just an example, we still try to keep our 3390-27 local usage at 30% just like we always did with smaller local page datasets in the past. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
On Mon, 30 Jan 2012 22:35:02 +, Martin Packer martin_pac...@uk.ibm.com wrote: Because of the virtualisation within modern disk controllers robustness favours more, smaller. What 6-9 3390-27 page volumes isn't robust enough? :-) And regardless of PAV and where the physical location is on the emulated DASD, if you put 5 smaller ones on _multiple_ mod-27s, isn't there more of a chance some of them end up on the same physical disk(s). One thing this thread didn't cover are some of the performance recommendations in the init and tuning guide related to large DASD. Recommendation #1, does say to only have one page data set per device. and in the z/OS 1.11 manual I have open it even has the updated bars on the left hand side. Writing to contiguous slots and over allocation is mentioned, but unless I missed it the old ROT (and health check) of not having more than 30% of the slots allocated is not specifically addressed. Certainly with 4K pages (for the most part) and 3390-27 (or bigger) that 30% ROT doesn't apply anymore?50% of a mod-27 is still a helava lot of free slots. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
Mark Zelden m...@mzelden.com wrote in message news:9474272146773836.wa.markmzelden@bama.ua.edu... On Mon, 30 Jan 2012 22:35:02 +, Martin Packer martin_pac...@uk.ibm.com wrote: Because of the virtualisation within modern disk controllers robustness favours more, smaller. What 6-9 3390-27 page volumes isn't robust enough? :-) And regardless of PAV and where the physical location is on the emulated DASD, if you put 5 smaller ones on _multiple_ mod-27s, isn't there more of a chance some of them end up on the same physical disk(s). One thing this thread didn't cover are some of the performance recommendations in the init and tuning guide related to large DASD. Recommendation #1, does say to only have one page data set per device. and in the z/OS 1.11 manual I have open it even has the updated bars on the left hand side. Writing to contiguous slots and over allocation is mentioned, but unless I missed it the old ROT (and health check) of not having more than 30% of the slots allocated is not specifically addressed. Certainly with 4K pages (for the most part) and 3390-27 (or bigger) that 30% ROT doesn't apply anymore?50% of a mod-27 is still a helava lot of free slots. Mark -- I discussed the last issue many years ago with Greg Dyck, who then (afaik) was the expert on paging, with regards to 30% free slots on 3390-03 and -09. He stated that simulations still recommended 30% usage, in spite of the helave lot of free slots on the -09. In that same discussion I learned that ASM reserves 2 exposures per pagedataset, so it was no problem putting more than 1 pagedataset on a volume. ASM just ensured 2n-1 PAVs statically assigned to that volume. This seems contradicting with Rec #1 you mention. About health checks: I consider at least 50% of them being writen on a lost Friday afternoon, because of some target to just deliver health checks. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
On Tue, 31 Jan 2012 08:48:30 -0600, Mark Zelden m...@mzelden.com wrote: On Mon, 30 Jan 2012 22:35:02 +, Martin Packer martin_pac...@uk.ibm.com wrote: Because of the virtualisation within modern disk controllers robustness favours more, smaller. What 6-9 3390-27 page volumes isn't robust enough? :-) And regardless of PAV and where the physical location is on the emulated DASD, if you put 5 smaller ones on _multiple_ mod-27s, isn't there more of a chance some of them end up on the same physical disk(s). One thing this thread didn't cover are some of the performance recommendations in the init and tuning guide related to large DASD. Recommendation #1, does say to only have one page data set per device. and in the z/OS 1.11 manual I have open it even has the updated bars on the left hand side. Writing to contiguous slots and over allocation is mentioned, but unless I missed it the old ROT (and health check) of not having more than 30% of the slots allocated is not specifically addressed. Certainly with 4K pages (for the most part) and 3390-27 (or bigger) that 30% ROT doesn't apply anymore?50% of a mod-27 is still a helava lot of free slots. Remove (for the most part) above - I momentarily forgot that 1M pages are not pageable. At least not now... -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
On 1/31/2012 7:07 AM, Vernooij, CP - SPLXM wrote: About health checks: I consider at least 50% of them being writen on a lost Friday afternoon, because of some target to just deliver health checks. Sometimes the need for the appearance of an autonomic, self-healing system becomes more important than the need for an autonomic, self-healing system. ;-) But, you're also saying close to 50% of health checks are useful, so that's good thing. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
Writing to contiguous slots and over allocation is mentioned, but unless I missed it the old ROT (and health check) of not having more than 30% of the slots allocated is not specifically addressed. Certainly with 4K pages (for the most part) and 3390-27 (or bigger) that 30% ROT doesn't apply anymore?50% of a mod-27 is still a helava lot of free slots. I think it still applies. My understanding has always been that the 30% usage (after which paging effectiveness drastically drops) applies to the algorithm used on the in-storage control blocks to pick the next free slot in a page data set. Unless that algorithm was redesigned, 30% of 44.9GB per page dataset is what you should not exceed (just as the health check says) in AUX usage. Redesign of that is IMHO unlikely, just as using more than 2 IOs on a page data set simultaneously would require (an unlikely) redesign. Sometimes the need for the appearance of an autonomic, self-healing system becomes more important than the need for an autonomic, self-healing system. ;-) But, you're also saying close to 50% of health checks are useful, so that's good thing. I consider about 30 of the 180-200 checks (1.12) useful. Otherwise I'll stay out of *this* discussion. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
