So there was a presentation in 2011 at Anaheim by Steve Huber on SMS Volume selection. I found it by going to an internet browser and entering
HOW DOES IBM SMS CHOSE VOLUMES? And top of the list was this entry Presentation title DFSMS Basics: How SMS Volume Selection Works Then I could search on it and find others. Here are the points he presented on selection Conventional Volume Selection . Used for all non-striped data sets . Used for all data sets with zero or blank SDR . Uses a preference sequence to sort volumes in the candidate storage groups into: . Primary . Secondary . Tertiary . Rejected Meet data set separation requirement . SMS storage group and volume statuses are enabled . MVS status is online . IART requirement is met . Number of volumes in storage group >= volume count . Accessibility requested can be met . Availability requested can be met . Meets the guaranteed space requirement . Can perform the allocation & stay below high threshold . For MSR=999, volume is non-cached (MSR= Milli Second Response) . Data class extended format request can be met After that, it if nothing meets this, SMS will go through some other iterations to select a volume. Remember SMS does not think like a human. It sets priorities of volumes then makes a selection. Which is not what we might have chosen. ;-D HTH Lizette > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Jesse 1 Robinson > Sent: Friday, April 21, 2017 5: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. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office <===== NEW > [email protected]<mailto:[email protected]> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
