All,
Yes, my final paragraph should read:
" Anyway I have probably bored you to tears. My key point is to go
VERTICAL, and avoid HORIZONTAL pooling."
That was a helluva transposition after such a long diatribe. Thanks to all
those that pointed out my mistake - it confirms you took the time to read my
email :-)
Ron
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Ron Hawkins
> Sent: Wednesday, July 04, 2012 3:59 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] Converting to SMS for the first time
>
> 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-
> m...@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
