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 > <ronjhawk...@sbcglobal.net>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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
