If you are allocating such a data set with disposition=new, the request will fail if there is not at least one available (Format 0) DSCB in the VTOC which z/OS can change into a Format 1 DSCB in which to save all the information about your new data set that occupies no real space. At least the data set name of this unreal data set will need to be saved.
If you really wanted to, you could initialize a new volume with a gazillion cylinders of space and a VTOC of some reasonable size, say 1 cylinder, and then completely fill the VTOC with Format 1 DSCBs for new data sets, all of which have 0 space. And then the VTOC would be full and no new data set of any size could be allocated on this volume which would have a gazillion minus one cylinders of free space on it. This sounds like something that should be tested to make sure it would work this way. Bill Fairchild ----- Original Message ----- From: "Paul Gilmartin" <[email protected]> To: [email protected] Sent: Wednesday, February 12, 2014 7:11:00 PM Subject: Re: Storage Obtain ..... On Wed, 12 Feb 2014 18:39:14 -0500, Tony Harminc wrote: > >> ..., freeing zero length is an instant disaster. > That ought to be a no-op. >You can't free 0 bytes at address 0? Now that is an inconsistency. Ah >- the subpool thing on FREEMAIN. Is that also true for STORAGE >RELEASE? > The "subpool thing" oughtn't be checked unless one or more bytes are to be freed. >>> So to be consistent, a non-zero address with appropriate access setup >>> (primarily key) should probably be returned. > >> Consistent with what? It can't return an address because one wasn't >> assigned. > >Sure - it could assign one. It wouldn't have to be unique; just >access-exception correct. > This is somewhat reminiscent of allocating a data set with VOL=SER=xxxxxx, SPACE=(CYL,0), when no space exists on volume xxxxxx, which I am told succeeds. I hope, likewise, that such a data set can be freed without a check of the validity of the primary extent. -- gil >Tony H. > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
