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:allan.stal...@kbmg.com] Sent: Tuesday, March 12, 2013 1:53 PM To: IBM-MAIN@LISTSERV.UA.EDU 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
