http://www.redbooks.ibm.com/abstracts/sg242568.html?Open
Been thru the SMS FIT process. It works. IBM came in to help walk me thru the process. Rob Schramm Senior Systems Consultant Imperium Group On Wed, Jul 4, 2012 at 6:59 PM, Ron Hawkins <ronjhawk...@sbcglobal.net>wrote: > Lizette, > > Before starting down the SMS path I think there are ways of approaching > your storage groups that will become increasingly important over time. One > is horizontal pooling, and the other is vertical pooling. > > Horizontal pooling is where you group volumes based on some business or > application boundary, like having all the volumes for banking in one > storage group, and all the volumes for credit cards in another. > > Vertical pooling is where you pool volumes based on the volume attributes, > so you may have all your HUR copied DUPLEX volumes in one storage group, > and all the suspended temporary dataset volumes in another storage group. > > I would urge you to consider vertical pooling rather than horizontal > pooling. Horizontal pooling by its nature appeases many of the political > problems that occur with implementing SMS, especially the MVS neophytes > that cannot get their mind beyond the "that other application can steal all > my freespace" mindset. I have seen this turn a site into 120+ storage > groups, and I've heard of more. You don't want to be managing that. > > Horizontal pooling allows you to minimize the things you manage, and > maximize the access to the resources within the pool. I start out with just > a few Storage Group categories that define workload that you may want to > keep separate for usage, performance, or some other reason. As a rule I use: > > TMP: truly temporary datasets, and not transitory datasets passed from job > to job > > DBS: any dataset allocated by a DBMS (IMS, DB2, IDMS, etc) or an OLTP > (CICS, etc). Some datasets may also be used by batch jobs, but if it is > part of a database at any point then it goes here. > > GEN: the general pool which starts out as anything with a TSO users HLQ or > a DSORG=PO. > > SYS: the system software pool. Datasets with a software product HLQ go > here (SYS2, SYS3, CA, BMC, etc). Most of this is software that is not > cutover with a pack copy, or the actual data files used by the software. > > GTD: a guaranteed space pool for anything that requires hand placement or > dedicated volumes. For example volumes shared across plexes with converted > reserves turned off, or a dedicated, custom sized volume for the TMC. > > BAT: the batch pool. Essentially anything that does not qualify for the > first five categories will be created a by a batch job and drop through > into this pool. It makes ACS coding easy :-) > > If datasets within these categories have special hardware requirements, > you can split the pool and name them with a suffix. For example you have a > mixed vendor shop and most of your batch datasets can use HDS Shadowimage, > but there are a few applications that are built around EMC Timefinder. You > can use SGBAT00 as a generic Storage Group, and have a SGBAT01 storage > group for datasets that require Shadowimage, and SGBAT02 for datasets that > require Timefinder. SGBAT01 only has HDS volumes, and SGBAT02 only has EMC > volumes. When you replace your EMC with a VSP (VBG) you can merge the three > pools back into SGBAT00. > > Once I have poured over DCOLLECT and Type42_6 records to establish how > datasets are used I build a model of the storage group space requirements > and contents. Many years ago I wrote a SMS allocation simulator in SAS > using these SMF records. It helped me plan SMS conversions at a few sites, > especially the pool sizes and Management Class migration potential. It also > provided the basis for a large part of the ACS code. > > One medium sized site in Indonesia - really smart people - implemented a > complete conversion with this approach in a three month window from project > start to end. After seeing this work on production they implemented this in > development with a single storage group, which is what I would usually > recommend for a typical development setup. > > Anyway I have probably bored you to tears. My key point is to go > horizontal, and avoid vertical pooling. > > Ron > > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Lizette Koehler > > Sent: Tuesday, July 03, 2012 6:27 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: [IBM-MAIN] Converting to SMS for the first time > > > > I have a friend who has a shop that is non SMS. I am trying to provide a > > simple check list on how to convert to SMS managed storage. > > > > If anyone has suggestions on best practices for a conversion – please > let me > > know. > > > > I have one idea of how to do, but others with more experience might have > a > > more elegant approach. > > > > My concept is to create some empty SMS Pools. Change/establish ACS > > routines (using the SAMPLE IBM provides) and slowly take one HLQ after > > another. Then when comfortable with the process and ACS/HSM processes > > work, go for the big bang. Yes – This is a high level view of what I > would do. > > So steps are missing. ☺ > > > > If there are better ideas, I thank you for the guidance. > > > > > > Lizette Koehler > > > > ---------------------------------------------------------------------- > > 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
