There is something to say in their advantage: it would/could be unsafe if the dataset were non SMS managed. But for SMS managed datasets, I see no reason to not interpret the 0 other than what it says: empty dataset. Probably the 30 year old code was never adopted for SMS.
Kees. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: 15 December, 2015 15:55 To: [email protected] Subject: Re: DFdss does not release space On Tue, 15 Dec 2015 13:00:31 +0000, Vernooij, CP (ITOPT1) - KLM wrote: >-----Original Message----- >From: Peter Hunkeler >Sent: 15 December, 2015 13:53 > >From the DSS Guide: >Chapter 9. Managing space with DFSMSdss >Releasing unused space in data sets >... >Exclude data sets whose last block pointer in the data set VTOC entry is not >maintained in the VTOC by using the EXCLUDE keyword. This can occur if you use >an access method other than BSAM, QSAM, BPAM, or VSAM. DFSMSdss does not >release space for data sets whose last block pointer in the data set entry is >0. > So the designers committed the unforgivable blunder of failing to differentiate between "0" and "unknown". This has been a problem for me elsewhere, in various DB interfaces, where I want to select all rows in which a certain column is unset, and get, in addition, those in which it is 0, or "", or some other default value. Rexx does it right: the SYMBOL function distinguishes a DROPped symbol from any possible explicitly assigned value. >There does not seem to be an option to override this restriction. > >-- > >Thanks, >that seems the explanation, as I guessed. >Still I wonder why these are not released, they have secondary space and >CA-DISK has no problem releasing them. Since they are SMS managed, they have a >decent EOF and there should be no danger of freeing space with valid data in >it because of an incorrect last block pointer. > The logic would need to modulate to distinguish an SMS-managed data set from non-SMS with a residual EOF not overwritten by BDAM updates. The likelihood of a wrong guess is small; the consequences devastating. And there's apt to be a user, somewhere, who deliberately (irresponsibly?) exploits the behavior and sets DS1LSTAR to 0 to suppress RELEASE. ISTR that at its advent HSM wouldn't migrate empty data sets, nor PDEes with no members. Perhaps a similar motivation. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] 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 [email protected] with the message: INFO IBM-MAIN
