This only works on an empty dasd storage group. In a well filled one, there are only few allocations per volume of this calculated size possible, reducing very much the real amount of usable space per volume. If you lower the size, there are more allocatins possible and somewhere there is the optimum extent size that gives you the maximum space for a dataset and it is depending on the amount of filling of the storage group, the concurrent allocations in the storage group, the moment and amount of dasd cleanup, the outside temperature and the mood of programmers.
YMMV is very appropriate here. Kees. "Mike Schwab" <mike.a.sch...@gmail.com> wrote in message news:<CAJTOO59sE28iM+pw5Zp53XoWGyDGVhSpTdBkQf=mcxu64w0...@mail.gmail.com>... > You can always take the capacity of your largest volume, divide it by > the maximum number of extents, and make that your allocation size. > Then it can spread across 59 volumes for the maximum possible data set > size. > > On Mon, Feb 13, 2012 at 9:19 AM, Chris Craddock <crashlu...@gmail.com> wrote: > > On Mon, Feb 13, 2012 at 8:56 AM, Paul Gilmartin <paulgboul...@aim.com>wrote: > > > >> On Mon, 13 Feb 2012 07:21:11 -0600, McKown, John wrote: > >> > >> >Or, as the programmers at our shop would do: > >> > >> >SPACE=EAT-EVERYTHING-IN-SIGHT-AND-CAUSE-OTHER-JOBS-TO-ABEND-BECAUSE-MY-STUFF-IS-IMPORTANT-AND-YOUR-STUFF-ISNT. > >> > > >> >In many other systems, such as Winblows, everybody gets their own > >> personal "space". And if it is "used up", it doesn't impact others. z/OS > >> shares DASD space. ... > >> > > >> The z/OS cultural norm for HFS and zFS is to give each user a > >> dedicated filesystem for HOME. This is similar to the behavior > >> of personal instances of those "other systems". > > > > I think it is fair to say that JCL and space management are areas where > > z/OS truly is archaic. The "other" world manages to get by just fine > > without having to figure out how much resource to give. There's no reason > > z/OS couldn't do the same other than slavish adherence to legacy. IMHO it > > is about time the system itself took care answering its own incessant "how > > big?", "how many?", "how often?" questions. It's 2012 ferpetesakes. I'm all > > in favor of making sure that existing applications continue to work. I am > > far less impressed with continuing to impose 1960s thinking on new ones. > > -- > > This email might be from the > > artist formerly known as CC > > (or not) You be the judge. > > > > -- > Mike A Schwab, Springfield IL USA > Where do Forest Rangers go to get away from it all? > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN ******************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ******************************************************** ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
