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:[email protected]] On Behalf
Of Barbara Nitz
Sent: Tuesday, January 31, 2012 10:50 PM
To: [email protected]
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 [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
