I stumbled on to this by accident. The person who had set up the Storage Group wanted to keep the pool at 20% full i.e. migrate dsns as much as possible to prevent space abends because the users who create dsns on this pool are not authorized to create multi-volume dsns.
________________________________ From: "O'Brien, David W. (NIH/CIT) [C]" <obrie...@mail.nih.gov> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, 13 March 2013 9:15 AM Subject: Re: SMS QUESTION That is correct, although by setting the high threshold so low, you prevent SMS from determining target volumes by activity. What did you hope to accomplish with a high threshold setting of 20%? -----Original Message----- From: John Dawes [mailto:jhn_da...@yahoo.com.au] Sent: Wednesday, March 13, 2013 9:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS QUESTION Just that I understand correctly if the the High Threshold is set to 20% "SMS does not PREVENT allocations above the High Threshold" i.e. the dsn will still be allocated if the space is available. SMS will not fail the allocation request. Right? Thanks. ________________________________ From: Ron Hawkins <ronjhawk...@sbcglobal.net> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, 12 March 2013 6:51 PM Subject: Re: SMS QUESTION 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:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of O'Brien, David W. (NIH/CIT) [C] > Sent: Tuesday, March 12, 2013 11:01 AM > To: IBM-MAIN@LISTSERV.UA.EDU > 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: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 ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
