"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

Reply via email to