Caveat: "daily digest, delayed list responses, yada, yada, yada..."
Skip/Jesse/Wayne: I have 3 items for you to validate viz. OVERFLOW volume selection. Has the OVERFLOW StorGrp got OVERFLOW=YES? If not, it's just another, normal group to SMS. I've been using a *true* SMS overflow pool for years to eliminate x37 abends and they are selected last. All of the volumes are ENABLEd but the StorGrp is marked as OVERFLOW=YES. The latter essentially defaults the StorGrp as QuiNew [1] placing all the volumes as 2nd+ tier in the selection criteria. (same result as Vary,SMS,StorGrp(xxx,ALL),QUIESCE,NEW) For certainty, I also defined the group's status as QuiNew in ISMF. Does the primary allocation put all the volumes in SVCDUMP over the High Threshold? [2] That means SMS starts with choosing from the 2nd+ tier (that includes Overflow) until it finds sufficient primary space. You should also check the StorClas entries for "Multi-Tiered SG"=Yes. This indicates you want volumes from SVCDUMP preferred to SG2 and OVERFLOW when the StorGrp ACS routine assigns &STORGRP= "SVCDUMP", "SG2", "OVERFLOW". It's been my default for a long time, now. [1] "Volumes in Overflow storage groups will be selected for primary space allocation only when all the volumes in non-overflow storage groups can not satisfy the allocation amount without exceeding the storage group high threshold." (ISMF StorGrp help text) [2] "The primary list consists of online volumes that meet all the requested preference attributes, are below their threshold, and whose volume status and storage group status are enabled." "PRIMARY THRESHOLD Volume has sufficient space in the target addressing space for the allocation amount without exceeding the storage group HIGH THRESHOLD value." Conventional volume selection, Chap 7, Storage Admin Ref. --------> signature = 8 lines follows <-------- Neil Duffee, Joe Sysprog, uOttawa, Ottawa, Ont, Canada telephone:1 613 562 5800 x4585 fax:1 613 562 5161 mailto:NDuffee of uOttawa.ca http:/ /aix1.uOttawa.ca/ ~nduffee "How *do* you plan for something like that?" Guardian Bob, Reboot "For every action, there is an equal and opposite criticism." "Systems Programming: Guilty, until proven innocent" John Norgauer 2004 "Schrodinger's backup: The condition of any backup is unknown until a restore is attempted." John McKown 2015 -----Original Message----- From: Schroeder, Wayne [mailto:[email protected]] Sent: April 25, 2017 10:33 Subject: Re: SMS STORGRP question I have the same setup but I have my OVERFLOW volumes set as QUINEW so they are only used if the original SG can't hold all of the data. Hope this helps. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Jesse 1 Robinson Sent: Friday, April 21, 2017 7:43 PM To: [email protected] Subject: SMS STORGRP question 'Forever' we have directed DUMPSRV SVC dumps via ACS routine to STORGRP 'SVCDUMP', which is defined to a small set of volumes called SVCDxx. We had a (major) problem a while back when DB2/CICS wanted to take a humongous dump that exceeded the available capacity of of the SVCDxx volumes. So we *added* group 'OVERFLOW' to the ACS routine expecting this much larger group to accommodate dumps that SVCDUMP could not handle. Much to our chagrin, from that moment forward, *all* SVCDUMPs went directly to OVERFLOW without even trying to find space in group SVCDUMP. We have an RYO mechanism to manage dumps created on volume SVCDxx, so dumps created elsewhere are a problem we can live with on occasion but not regularly. I know there are various ways to resolve to this problem, but I want to know why SMS is behaving this way and whether there is a purely SMS solution: try SVCDUMP first; if no room, then try OVERFLOW. In that order. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
