It has been tested - and validated - long ago, when GDG datasets had to 
have model DCBs (this discovery lead to programmers being required to code 
a default model DCB name in the JCL DD statement) until the model dcb 
requirement was lifted many years later.

Vacation Notice: 

None currently scheduled

 
Tom Puddicombe
Principal Systems Engineer
Mainframe Performance & Capacity Planning
CSC

31 Brookdale Rd, Meriden, CT 06450
ITIS | (860) 428-3252 | tpudd...@csc.com | www.csc.com

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to 
any order or other contract unless pursuant to explicit written agreement 
or government initiative expressly permitting the use of e-mail for such 
purpose.



From:   DASDBILL2 <dasdbi...@comcast.net>
To:     IBM-MAIN@LISTSERV.UA.EDU
Date:   02/13/2014 07:11 AM
Subject:        Re: Storage Obtain .....
Sent by:        IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>



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" <paulgboul...@aim.com> 
To: IBM-MAIN@LISTSERV.UA.EDU 
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN 

---------------------------------------------------------------------- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to