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=00000000 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 [email protected] From: Barbara Nitz <[email protected]> To: [email protected] Date: 02/02/2012 09:47 PM Subject: Re: Very Lage Page Datasets (was ASM and HiperPAV) Sent by: IBM Mainframe Discussion List <[email protected]> >"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=000099EB VIO COUNT=00000000 ASID=00A3 JOB=DSNXDBM1 SLOTCOUNT=00008B0F VIO COUNT=00000000 ASID=002E JOB=ZFS SLOTCOUNT=00002F26 VIO COUNT=00000000 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 [email protected] with the message: INFO IBM-MAIN
