Allan Thanks for the help. I have changed the Threshold to 60. Would Space Management (Primary & Secondary) be affected because of the new threshold?
________________________________ From: "Staller, Allan" <allan.stal...@kbmg.com> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, 12 March 2013 1:23 PM Subject: Re: SMS QUESTION 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
