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