Re: Converting to SMS for the first time
sigh I know... That I didn't tell you was they created (not through dynamic but through some other path (old TSO I'd guess) so their naming "standards" was their own which was not a && type situation) it looked like one but they never fully converted to the "new" temp naming stards that went into effect in Y2K. (4 digit year I think). On Jul 6, 2012, at 2:45 AM, Ron Hawkins wrote: Ed, In the ACS routines you usually test for &DSTYPE=TEMP, rather than a system generated dataset name mask. Ron The issue in TMP is that some software vendors use && type datasets as perm and then rename them "magically". No they shouldn't do it and you can argue with them for years and they won't budget. These vendors are nightmares and a half. -- 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
Re: Converting to SMS for the first time
Another plug for Naviquest - the free IBM test facility for SMS. This is the perfect time to start setting up your test cases & learning to use it. Unless your shop is 'rich' enough to set up a whole separate test-plex, it's one of the few ways to actually test your code before putting it into production. Here's a link - book's a little old, but the information in it would get the beginner started. I don't know if it's been updated - http://www.redbooks.ibm.com/abstracts/sg244720.html This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Converting to SMS for the first time
Ed, In the ACS routines you usually test for &DSTYPE=TEMP, rather than a system generated dataset name mask. Ron > The issue in TMP is that some software vendors use && type datasets as > perm and then rename them "magically". No they shouldn't do it and you can > argue with them for years and they won't budget. These vendors are > nightmares and a half. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Converting to SMS for the first time
Rob, One of the best strategies I feel I used to prevent problems with large dataset allocations was to stop doing it. Rather than trying to manage primary space requests of 1000-2000 cyls I made a standard of 500 CYL primary and secondary for any dataset larger than 500 CYLS. I improved that change with a unit count of five in the dataclas, and release immediate in the management class. The net result was large datasets were almost always multivolume, and fragmentation was rarely a problem because you never requested more than a 500 CYL extent. Forget trying to cater for all those 2000 CYL primary requests. I also augmented this with SRS rules, particularly primary space reduction, secondary space reduction, increase secondary, and addvol. It was not unusual to find 4-5GB datasets across 10-15 volumes, which we found to be a good thing. Why was it a good thing? Because many of these large datasets were used by 5-10 reporting jobs all running at the same time. Having the datasets spread across multiple volumes meant that only one or two jobs were reading the dataset concurrently from a volume, even though ten jobs were reading the dataset concurrently. If the datasets were allocated as a large dataset on a single volume, that volume and the underlying array group would get hammered. It lead me to introduce looking at the busiest datasets at part of SMS implementation and making sure they were always spread over enough volumes that each volume did ten IOs or less. That was the sort of IO rate that made the dataset generic and low impact to other workload. Ten IOPS may be a little low now we HyperPAV and faster disk architectures. Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Rob Schramm > Sent: Thursday, July 05, 2012 11:35 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] Converting to SMS for the first time > > I am not sure how valid it is anymore (it was more than 10 years ago). We did > it after the initial implementation... the fragmentation was messing with the > large data set allocations. With Large and extended format.. it may not be an > issue. But I would keep it in mind if things start to get "weird". IBM never > recommended it .. but it straightened things out at the time. > > Rob Schramm > Senior Systems Consultant > Imperium Group > > > > On Thu, Jul 5, 2012 at 12:56 PM, Ron Hawkins > wrote: > > > Rob, > > > > I have seen the small and large dataset concept discussed since the > > early days of DFSMS. To tell the truth I have never seen the benefit > > of doing this. > > > > It has been suggested that it helps reduce allocation failures by > > reducing fragmentation, but having always worked in shops with ACC/SRS > > or similar I was pretty aggressive with the rules and did not have a > > problem even when I ran development STORGRUPs up to 5% free space. > And I never defragged. > > > > If fragmentation is the reason for sized based pools, then I wonder if > > the practice is still necessary. DFSMS has implemented some elements > > of ACC/SRS to reduce allocation problems, and if you are using 3390-A > > with Cylinder allocation areas you have a natural separation of small > > and large datasets within the volume. > > > > I would say do not implement size related pools, but rather make sure > > you make best use of allocation recovery in DFSMSdfp, ACC/SRS, > > PRO-SMS, or whatever ISV software you have as part of your > implementation. > > > > Ron > > > > > -Original Message- > > > From: IBM Mainframe Discussion List > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Schramm > > > Sent: Thursday, July 05, 2012 8:01 AM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: [IBM-MAIN] Converting to SMS for the first time > > > > > > You may want to consider the use of a couple size-related pools. > > > During > > one > > > analysis ... something like 80% of the data sets were below 5 tracks. > > > > > > > > > Rob Schramm > > > Senior Systems Consultant > > > Imperium Group > > > > > > > > > > > > On Thu, Jul 5, 2012 at 10:52 AM, Elardus Engelbrecht < > > > elardus.engelbre...@sita.co.za> wrote: > > > > > > > Ron Hawkins wrote: > > > > > > > > >I would urge you to consider vertical pooling rather than > > > > >horizontal > > > > pooling. > > > > ... > > > > > My key point is to go horizontal, and avoid vertical pooling. > > > > > > > > Vertical against horizontal? Perhaps I missed something in your > > > > post, but in my very humble opinion, I think both sentences are > > > > not speaking the same tongue > > > > > > > > Of course, I'm pretty sure I'm as usual wrong. Please correct me > > > > if needed ... > > > > > > > > Many thanks and have a terrific day! > > > > > > > > Groete / Greetings > > > > Elardus Engelbrecht > > > > > > > > -- > > > > For IBM-MAIN subscribe / signoff / archive access > > > > instru
Re: Converting to SMS for the first time
On Jul 4, 2012, at 5:59 PM, Ron Hawkins wrote: --- SNIP--- 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. --- SNIP-- All good advice. The issue in TMP is that some software vendors use && type datasets as perm and then rename them "magically". No they shouldn't do it and you can argue with them for years and they won't budget. These vendors are nightmares and a half. I don't know if its still true (probably is based on their past behavior) a major DBMS refuses to acknowledge that their data sets are unmovable. Sure they are moveable if you use their utilities but thats the standard argument you get from these "people" -SNIP- There is a redbook (or there used to be one that gave some good advice about converting). Ever since IBM forced the issue on some datasets companies are finally (again) eyeing the possibility and Liz, you are one of them. I am mixed about the idea of forcing everyone as there are good benefits from going SMS. There are a few vendors out there that are inhibiting the conversion. I think the users have to ride them really hard to see the error of their ways. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Converting to SMS for the first time
I am not sure how valid it is anymore (it was more than 10 years ago). We did it after the initial implementation... the fragmentation was messing with the large data set allocations. With Large and extended format.. it may not be an issue. But I would keep it in mind if things start to get "weird". IBM never recommended it .. but it straightened things out at the time. Rob Schramm Senior Systems Consultant Imperium Group On Thu, Jul 5, 2012 at 12:56 PM, Ron Hawkins wrote: > Rob, > > I have seen the small and large dataset concept discussed since the early > days of DFSMS. To tell the truth I have never seen the benefit of doing > this. > > It has been suggested that it helps reduce allocation failures by reducing > fragmentation, but having always worked in shops with ACC/SRS or similar I > was pretty aggressive with the rules and did not have a problem even when I > ran development STORGRUPs up to 5% free space. And I never defragged. > > If fragmentation is the reason for sized based pools, then I wonder if the > practice is still necessary. DFSMS has implemented some elements of ACC/SRS > to reduce allocation problems, and if you are using 3390-A with Cylinder > allocation areas you have a natural separation of small and large datasets > within the volume. > > I would say do not implement size related pools, but rather make sure you > make best use of allocation recovery in DFSMSdfp, ACC/SRS, PRO-SMS, or > whatever ISV software you have as part of your implementation. > > Ron > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Rob Schramm > > Sent: Thursday, July 05, 2012 8:01 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: [IBM-MAIN] Converting to SMS for the first time > > > > You may want to consider the use of a couple size-related pools. During > one > > analysis ... something like 80% of the data sets were below 5 tracks. > > > > > > Rob Schramm > > Senior Systems Consultant > > Imperium Group > > > > > > > > On Thu, Jul 5, 2012 at 10:52 AM, Elardus Engelbrecht < > > elardus.engelbre...@sita.co.za> wrote: > > > > > Ron Hawkins wrote: > > > > > > >I would urge you to consider vertical pooling rather than horizontal > > > pooling. > > > ... > > > > My key point is to go horizontal, and avoid vertical pooling. > > > > > > Vertical against horizontal? Perhaps I missed something in your post, > > > but in my very humble opinion, I think both sentences are not speaking > > > the same tongue > > > > > > Of course, I'm pretty sure I'm as usual wrong. Please correct me if > > > needed ... > > > > > > Many thanks and have a terrific day! > > > > > > Groete / Greetings > > > Elardus Engelbrecht > > > > > > -- > > > 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Converting to SMS for the first time
Rob, I have seen the small and large dataset concept discussed since the early days of DFSMS. To tell the truth I have never seen the benefit of doing this. It has been suggested that it helps reduce allocation failures by reducing fragmentation, but having always worked in shops with ACC/SRS or similar I was pretty aggressive with the rules and did not have a problem even when I ran development STORGRUPs up to 5% free space. And I never defragged. If fragmentation is the reason for sized based pools, then I wonder if the practice is still necessary. DFSMS has implemented some elements of ACC/SRS to reduce allocation problems, and if you are using 3390-A with Cylinder allocation areas you have a natural separation of small and large datasets within the volume. I would say do not implement size related pools, but rather make sure you make best use of allocation recovery in DFSMSdfp, ACC/SRS, PRO-SMS, or whatever ISV software you have as part of your implementation. Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Rob Schramm > Sent: Thursday, July 05, 2012 8:01 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] Converting to SMS for the first time > > You may want to consider the use of a couple size-related pools. During one > analysis ... something like 80% of the data sets were below 5 tracks. > > > Rob Schramm > Senior Systems Consultant > Imperium Group > > > > On Thu, Jul 5, 2012 at 10:52 AM, Elardus Engelbrecht < > elardus.engelbre...@sita.co.za> wrote: > > > Ron Hawkins wrote: > > > > >I would urge you to consider vertical pooling rather than horizontal > > pooling. > > ... > > > My key point is to go horizontal, and avoid vertical pooling. > > > > Vertical against horizontal? Perhaps I missed something in your post, > > but in my very humble opinion, I think both sentences are not speaking > > the same tongue > > > > Of course, I'm pretty sure I'm as usual wrong. Please correct me if > > needed ... > > > > Many thanks and have a terrific day! > > > > Groete / Greetings > > Elardus Engelbrecht > > > > -- > > 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
Re: Converting to SMS for the first time
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 conv
Re: Converting to SMS for the first time
You may want to consider the use of a couple size-related pools. During one analysis ... something like 80% of the data sets were below 5 tracks. Rob Schramm Senior Systems Consultant Imperium Group On Thu, Jul 5, 2012 at 10:52 AM, Elardus Engelbrecht < elardus.engelbre...@sita.co.za> wrote: > Ron Hawkins wrote: > > >I would urge you to consider vertical pooling rather than horizontal > pooling. > ... > > My key point is to go horizontal, and avoid vertical pooling. > > Vertical against horizontal? Perhaps I missed something in your post, but > in my very humble opinion, I think both sentences are not speaking the same > tongue > > Of course, I'm pretty sure I'm as usual wrong. Please correct me if needed > ... > > Many thanks and have a terrific day! > > Groete / Greetings > Elardus Engelbrecht > > -- > 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
Re: Converting to SMS for the first time
Ron Hawkins wrote: >I would urge you to consider vertical pooling rather than horizontal pooling. ... > My key point is to go horizontal, and avoid vertical pooling. Vertical against horizontal? Perhaps I missed something in your post, but in my very humble opinion, I think both sentences are not speaking the same tongue Of course, I'm pretty sure I'm as usual wrong. Please correct me if needed ... Many thanks and have a terrific day! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Converting to SMS for the first time
Ron, These two sentences contradict each other: > I would urge you to consider vertical pooling rather than horizontal pooling. > My key point is to go horizontal, and avoid vertical pooling. I understand your point, but others may not. Care to rewrite this post a little bit for clarification? Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ron Hawkins Sent: Wednesday, July 04, 2012 6:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 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-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
Re: Converting to SMS for the first time
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 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
Re: 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-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-MAI
Re: Converting to SMS for the first time
Ooops ... I think I meant we restricted STORGRP (not STORCLAS). be seeing you ... Don Don Melton, Sr. Consultant, Vatic Technologies Ltd "Don Melton" wrote in message news:<78F313C333AA482DAFD8A71679B2F846@vtdskntw513>... > "Lizette Koehler" wrote in message > news:<01de01cd591f$8b52a580$a1f7f080$@mindspring.com>... > > 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 > > > > These comments may seem a bit "radical", but they worked very well in the > implementation that I led. > > 1) During the SMS implementation we set things up so that general users > could specify SMS attributes (except for STORCLAS). The idea was to > decouple the dataset name (which hopefully describes content and function) > from the management attributes. It was a long time ago, but I seem to > recall using RACF to authorize users to specific subsets of data/management > classes. > > 2) I also took the opportunity to "refactor" the data management rules. I > worked with all of the "stakeholders" to review current storage management > practices (e.g., backup retention, space allocation etc.) and try to > rationalize and reduce them to a small(er) set of SMS constructs. > > 3) Finally I seem to recall that the order of conversion was something like: > temporary datasets, TSO user datasets, general application datasets, > database datasets, other datasets. > > be seeing you ... Don > > Don Melton, Sr. Consultant, Vatic Technologies Ltd > > -- > 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
Re: Converting to SMS for the first time
"Lizette Koehler" wrote in message news:<01de01cd591f$8b52a580$a1f7f080$@mindspring.com>... > 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 > These comments may seem a bit "radical", but they worked very well in the implementation that I led. 1) During the SMS implementation we set things up so that general users could specify SMS attributes (except for STORCLAS). The idea was to decouple the dataset name (which hopefully describes content and function) from the management attributes. It was a long time ago, but I seem to recall using RACF to authorize users to specific subsets of data/management classes. 2) I also took the opportunity to "refactor" the data management rules. I worked with all of the "stakeholders" to review current storage management practices (e.g., backup retention, space allocation etc.) and try to rationalize and reduce them to a small(er) set of SMS constructs. 3) Finally I seem to recall that the order of conversion was something like: temporary datasets, TSO user datasets, general application datasets, database datasets, other datasets. be seeing you ... Don Don Melton, Sr. Consultant, Vatic Technologies Ltd -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Converting to SMS for the first time
With regard to immediate deletion of uncataloged datasets, is this shop running Stop X37? If yes have them check the uncatlg2 setting. I once worked in a shop where it caused many uncatalogued datasets on SMS managed vols. You might also advise having a few Quinew'd volumes in his active pools to allow for the occasional user who tends toward large primary allocations whether or not it is needed. Every shop seems to have one. Thank You, Dave O'Brien From: Elardus Engelbrecht [elardus.engelbre...@sita.co.za] Sent: Tuesday, July 03, 2012 10:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Converting to SMS for the first time >>If anyone has suggestions on best practices for a conversion – please let me >>know. Two more (and last) hints: Keep RACF DB and perhaps other certain datasets (DSORG=U for example) away from SMS. Have a hard and fast and absolute unpopular rule: "Anything uncataloged means immediate deletion because of duplication issues." Of course YMMV because YOU do the deletion action(s) in one or other [manual] way. Groete / Greetings Elardus Engelbrecht -- 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
Re: Converting to SMS for the first time
>>If anyone has suggestions on best practices for a conversion – please let me >>know. Two more (and last) hints: Keep RACF DB and perhaps other certain datasets (DSORG=U for example) away from SMS. Have a hard and fast and absolute unpopular rule: "Anything uncataloged means immediate deletion because of duplication issues." Of course YMMV because YOU do the deletion action(s) in one or other [manual] way. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Converting to SMS for the first time
Lizette Koehler wrote: >If anyone has suggestions on best practices for a conversion – please let me >know. There are redbooks and ABC of system programmer books, sigh, I don't have the links to send to you... Sorry > So steps are missing. ☺ Keep things small and easy. ISMF also provide a Test and Validate to check your ACS routines. You can't go wrong with the Test facility. :-) While I'm not a storage admin now anymore, I have in the past kept a double set of ACS setups (routines, datasets, etc) in production... One little hint I picked up somewhere - I have reserved a group of DASD which are marked as DISNEW and introduce them piece by piece to the 'live' pool. Oh yes, let RACF decides on naming standards and have SMS decides on actual allocation for a start until you and your friend are established. >If there are better ideas, I thank you for the guidance. I'm pretty sure you will spark a long thread full of valuable hints. Every one likes to help a lady. ;-) Good luck on your adventure! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Converting to SMS for the first time
The very first thing that we did was to create a "minimal" SMS environment, which had nothing managed, and IPL'd. We then create a "SGWORK" pool. We set up an SMS pool of WORKnn volumes. We created a STORGRUP called SGWORK, a STORCLAS called SCWORK and a DATACLAS called DCWORK. The three ACS routines were very simple: PROC 1 DATACLAS IF (&DSTYPE EQ 'TEMP') THEN SET &DATACLAS='DCWORK' END PROC 1 STORCLAS IF (&DSTYPE EQ 'TEMP') THEN SET &STORCLAS='SCWORK' END PROC 1 STORGRUP IF (&STORCLAS EQ 'SCWORK') THEN SET &STORGRUP='SGWORK' END DCWORK basically had not attributes assigned to it. The same with SCWORK and SGWORK. We then did a dynamic activate of this. Eventually the old work (PUBLIC) volumes were empty (had to recycle some STCs). Once they were empty, we reinitialized them as SMS volumes for new data. We did something similar to you at that point. We converted HLQs, starting with TSO user data (separating PS and VSAM from PDSs into different pools beause we backup PDSs with HSM but not user PS or VSAM), then test datasets, then model office datasets, and finally production datasets. In each case, we converted PS files first, then PDSes, then VSAM. VSAM is the most critical to us, so we did it last. We don't have DB2 or any other database system. We converted some system infrastructure datasets, but not many. I wanted to, but was shot down. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 • N. Richland Hills • TX 76010 (817) 255-3225 phone • john.mck...@healthmarkets.com • www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. –The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -Original Message- > From: IBM Mainframe Discussion List > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler > Sent: Tuesday, July 03, 2012 8:27 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: 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
