On Thu, 17 Aug 2006 14:07:52 -0400, Richards.Bob <[EMAIL PROTECTED]> wrote:
>Tom, > > > >The most valuable suggestion in addition to the one on SMS manuals >is the one found at the bottom of every note on this list: > > > >Search the archives at http://bama.ua.edu/archives/ibm-main.html > Agreed. Too bad it doesn't also reference the archives of ibm-main-archives. > Snip! > >When I converted non-SMS pools, I seem to recall using selection logic in the *Storage Class* routine to first differentiate between explicit dataset allocations (PRIVATE mounted), then temporary dataset allocations (generally a PUBLIC mounted pool) and finally as a catch-all, UNIT/Esoteric allocations using ANYVOL for *storage mounted* volumes. Exceptions to these rules were coded first, but then the logic flowed top to bottom from most explicit to most generic. For the most part, storage groups were only assigned by storage classes. The exceptions I mentioned were to allow some allocations to continue to proceed to their existing non-SMS pools until such time as you were ready to manage them. > Personally, I would avoid coding ACS routines based upon the specified volume, except for transitional purposes. IMHO, you want to get away from specifying VOL=SER for all SMS-managed data sets. There might be good reasons fpr exceptions to this, but to create a "storage" pool and assign data sets to it because they are not temporary and nave no volume specified might not be what you want. For example, I can see how someone might want the ACS routines to recognize VOL=SER=DRVOL and assign one of the storage groups that will contain the first volumes to restore in a D/R situation. Tom Marchant ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
