"Thomas Berg" <thomas.b...@swedbank.se> wrote in message news:<a90e503c23f97441b05ee302853b0e6263ff850...@fspas01ev010.fspa.myntet.se>... > > -----Ursprungligt meddelande----- > > Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För R.S. > > Skickat: den 13 februari 2012 15:49 > > Till: IBM-MAIN@bama.ua.edu > > Ämne: Re: SV: SV: Archaic allocation in JCL (Was: Physical record size > > query) > > > > W dniu 2012-02-13 15:21, Thomas Berg pisze: > > > (This is an answer also to Vernooij.) > > > > > > Please consider what You do manually when the space is to small (e g B37 > > etc.), or You just is unsure: You try a bigger allocation, maybe also > > extend (or reduce) the secondary amount. And repeat. Often many times. > > > Would it be a problem if this (more or less) is automated ? Hm ? > > > > > > Technically I suppose it's solved by an initial "virtual" allocation > > filling a buffer in memory. > > > Then a disk allocation is done at a threshold with e g 5 cyl. > > > If that is not enough, add 4 times the amount, 20 cyl. > > > Repeat this until finish. > > > Release unused space (from the last add). > > > > > > This is just an example, it can be done much more sophisticated by the > > OS. > > > > > > And the limit of allocation should be set by userid or datasetname > > properly. Or maybe by a (e g) LIMIT= keyword. > > > > > > (I'm using the JCL case as an illustrative example, it should of course > > be general system interface.) > > > > > > Actually space abends in my environment are very very rare. Time and > > experience were needed to go there, but the experience + SMS facilities > > + DFSMShsm causes x37 abends almost non-existent. > > > > As I said, z/OS storage requires different approach. On Windows system > > programmer opens the file and writes to it. On z/OS he has to answer the > > question: HOW MUCH DATA DO YOU EXPECT TO BE WRITTEN. The answer can be > > veeeery imprecise, but it is required. > > > > Could it be better? I think so. What about unlimited number of extents? > > Or at least, let's say, 3000 per volume? What about multi-volume > > PDS(E)s? What about FBA disks? > > WAKE UP! > > ;-) > > I refuse! :) > > (In my life space abends occurs regularly, often caused by circumstances > beyond my control.) > BTW, You latter suggestions is not bad - but You didn't go far enough! There > should unlimited number of *everything*! Don't make artificial limits. > > > > Regards, > Thomas Berg
This is a huge conversion. There was a good point in your previous suggestion and in Gill's: take a primary allocation and add ever larger secondaries. With multivolume datasets, you can have a lot of extents and consequently a lot of space, all without having to change the current limits in the Dasd architecture. It only requires a new Space Constraint Releave algorithme. This is what DB2 does nowadays. Our DB2 administrators converted to this (-1,-1) allocation a year ago and happily saw problems with mis/underallocated space amounts disappear completely and we gained back a lot of unnecessarily overallocated space from the former way of database space allocation. The knife cuts on both sides this way. Kees. ******************************************************** 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
