David, Yes, your understanding is the same as mine. The primary eligible device list contains volumes that will not exceed the max threshold if the primary space is allocated there. This is sorted on performance criteria. The secondary eligible device list has volumes with enough free space to satisfy the primary space request, and my recollection is that this is in free space order.
If allocation is not satisfied in the primary list it will fall through to the secondary list. With a high threshold of 20%, most allocation will likely be influenced by space, rather than activity. If you suspect that fragmentation is the problem then have you checked if you have Space Constraint relief set to YES in the DATACLAS used by the data set, or if the % reduction is aggressive enough to counter the fragmentation. Another strategy would be to reduce to space request to something smaller, let's say (TRK(5000,5000),RLSE), and add a unit count so the space is allocated across multiple volumes - UNIT=(,5). Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of O'Brien, David W. (NIH/CIT) [C] > Sent: Tuesday, March 12, 2013 11:01 AM > To: [email protected] > Subject: Re: [IBM-MAIN] SMS QUESTION > > No, volumes which are above the threshold but have available space are put > into a secondary allocation list. Those volumes under the high threshold are > in a primary allocation list. SMS then searches for a volume which will satisfy > the allocation. At least that's the way it was explained to me by IBM at the > Share meeting in Baltimore some years ago. > > The OP has 51 volumes with available space which are either badly > fragmented or do not have 20K tracks within 5 extents. A smaller primary and > secondary with a unit parameter specifying multiple volumes will allow the > allocation. > > -----Original Message----- > From: Staller, Allan [mailto:[email protected]] > Sent: Tuesday, March 12, 2013 1:53 PM > To: [email protected] > Subject: Re: SMS QUESTION > > What if *all* of the volumes are at/near the high threshold (20%)? > Very often there are candidate volumes defined to SMS, but that do not > physically exist (which could be the 51 volumes lacking space for the > allocation). > > <snip> > While I agree that the High Threshold should be 80 (or in that vicinity), SMS > does not PREVENT allocations above the High Threshold, it merely tries to > direct them to a volume below that threshold. > The last line of the error msg. is the problem. 51 volumes lack the free space > to allow the allocation. > > The solution would be to add volumes to the pool OR allow for a multi- > volume file. Use a smaller Primary space allocation and use UNIT=(3390,10) in > your DD statement. The 10 is just an example, the upper limit is 59. > </snip> > > I believe your problem is located here: > <snip> > Allocation/migration Threshold : High 20 (1-100) Low . . 1 (0-99) > </snip> > > IIRC, the HIGH 20 will prevent allocation of new datasets if the PRI space will > exceed the high threshold. > > BTW, IMO, the ALLOC High of 20 is extremely low. I would suggest a number > more on the lines of 50 to 80 percent. > You will most likely be able to reduce the number of volumes in this pool > after the change. > > HTH, > <snip> > Allocation/migration Threshold : High 20 (1-100) Low . . 1 (0-99) > Alloc/Migr Threshold Track-Managed: High 85 (1-100) Low . . 1 (0-99) > Guaranteed Backup Frequency . . . . . . NOLIMIT (1 to 9999 or NOLIMIT) > BreakPointValue . . . . . . . . . . . . (0-65520 or blank) > > Of late we have been having allocation problems where the job is unable to > allocate the first extent and fails on jcl error etc. I found the following info > which may explain the cause. Am I barking up the wrong tree? If not, if I > change the High from 20 to 80 would that address the problem? Also, would > HSM miigrate dsn only if the pool is reached 80% or over? > > MIGR HIGH is also checked during allocation. SMS attempts to select a > volume that has enough space available to contain the primary allocation of > the new data set without exceeding the > MIGR HIGH threshold. > </snip> > > ---------------------------------------------------------------------- > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
