If you specify a default data class in this manner does this negate the requirement for both SPACE and DATACLAS? Sounds good to me! Frank
>________________________________ > From: "Vernooij, CP - SPLXM" <kees.verno...@klm.com> >To: IBM-MAIN@bama.ua.edu >Sent: Monday, February 13, 2012 6:43 AM >Subject: Re: Archaic allocation in JCL (Was: Physical record size query) > >"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 >> > Vernooij, CP - SPLXM >> > Skickat: den 13 februari 2012 14:22 >> > Till: IBM-MAIN@bama.ua.edu >> > Ämne: Re: Archaic allocation in JCL (Was: Physical record size query) >> > >> > "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 >> > > > Lizette Koehler >> > > > Skickat: den 13 februari 2012 12:43 >> > > > Till: IBM-MAIN@bama.ua.edu >> > > > Ämne: Re: Archaic allocation in JCL (Was: Physical record size query) >> > > > >> > > > > >> > > > > I can't understand why we STILL need to specify SPACE= (etc) for an >> > > > allocation of a >> > > > > dataset. >> > > > > You normally don't do that in other OS (platforms), You always (both >> > > > principally and in >> > > > > practice) want to allocate as much as is needed during execution >> > > > > >> > > > > If for backward compatibility it can't be done automatically, why >> > not >> > > > introduce a new >> > > > > keyword like e g "SPACE=ANY" ? >> > > > > >> > > > > >> > > > >> > > > Thomas, >> > > > >> > > > IIRC - if you force a DATACLAS on a dataset in SMS, you can specify >> > the >> > > > Space requirements there. Then the JCL does not require Space. Have >> > you >> > > > looked at that? However, then that makes your storage admin >> > responsible >> > > > for >> > > > ensuring the space is enough. And if needed alter the dataclass if >> > there >> > > > are space issues. And it would require all such datasets be SMS >> > managed. >> > > > >> > > > >> > > > Lizette >> > > >> > > Hi Lizette, >> > > >> > > In practice it's not a viable alternative. Besides the need (if doing it >> > that way) to communicate frequently with the "space gang", it's to many >> > variants of datasetnames and to many different needs for space depending >> > on time, date and subgrouping within applications. >> > > >> > > >> > > >> > > Regards, >> > > Thomas Berg >> > >> > Now I don't understand: if you have so many different space needs, how do >> > you assume 'SPACE=ANY' to solve this? >> >> With SPACE=ANY, the needed space is allocated and extended during the >> execution. >> So You don't do any "preallocation" of a specified amount of space. >> >> >> >> Regards, >> Thomas Berg > >Consider how that is to be administrated during the execution of a job: if you >do it like PCs, your dasd is formatted in small fixed chunks of space and each >time you need more, you take another chunk. Suppose a chunk is 1 track: when a >dataset is being filled, it will create hundreds/thousands/millions of chunks. >This requires a completely new administration in DCB/DEB's and in VTOC DSCBs. >Or do you introduce a new file- and diskformat: FAT/NTFS/ZFS(oh no, this >exists),ZOSFS? On the same disks or on newly formatted disks? It brings a >truckload of consequences to implement. > >A simple variant would be: assign a default Dataclas, with a large amount of >space, enough for 90% of your needs and release overallocated space at Close. >This can all now already be done simply with Dataclass and Managementclass. > >Kees. > > >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 > > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
