Mike,
Did you miss the "assuming the PDSE has no free blocks and  cannot be
extended"?

I was just curious if the PDSE logic mimicked  the PDS behavior of
making a distinction in the failure response for a full and
non-extendable PDSE depending on whether the no-more-space failure is
first detected when trying to allocate a free block to the directory or
when trying to allocate one for member data.  Or do both these cases
produce an identical ABEND failure along the lines of PDSE
out-of-space-and-unable-to-extend?

    JC Ewing

On 10/22/20 10:23 PM, Mike Schwab wrote:
> If all the PDSE directory blocks are full it grabs another block for
> the directory, it can't run out of space unless the entire data set
> cannot be expanded.
>
> On Thu, Oct 22, 2020 at 5:30 PM Joel C. Ewing <[email protected]> wrote:
>> I would assume a directory entry must be created before attempting to
>> allocate space for the contents of a new PDSE member.  So, assuming the
>> PDSE has no free blocks and cannot be extended, do you get a different
>> type of ABEND if the out-of-space condition occurs at directory entry
>> creation time because a new directory block just happens to be needed vs
>> finding space in an existing directory block and then hitting the
>> out-of-space condition trying to allocate a block for the member data?
>> With no free blocks, obviously no new members can be added to the PDSE,
>> but it looks like it might still  be possible that the failure could be
>> reflected differently to the user or program depending on purpose for
>> which a block were needed at the initial point of failure.
>>
>> In a pathological case where you were just adding a very large number
>> of  Alias directory entries pointing to existing members, I would think
>> you could use all remaining free blocks in the PDSE just for directory
>> blocks without allocating any new blocks for member content, so if PDSE
>> block allocation failure makes any distinction between failures
>> occurring when a directory block is needed vs a member data block, that
>> would be another case that might be reflected as a shortage of directory
>> space.
>>     JC Ewing
>>
>> On 10/22/20 10:52 AM, Charles Mills wrote:
>>> Putting it differently, there is no distinction between "member data space" 
>>> and "directory entry space." Being out of one is being out of both. A PDSE 
>>> of 10 tracks could equally well hold one member of ~500K or lots and lots 
>>> of tiny or "null" members. A mischievous programmer adding an unbounded 
>>> number of empty members would be no different in effect from a mischievous 
>>> programmer adding one member of unbounded size.
>>>
>>> Charles
>>>
>>>
>>> -----Original Message-----
>>> From: IBM Mainframe Discussion List [mailto:[email protected]] On 
>>> Behalf Of R.S.
>>> Sent: Thursday, October 22, 2020 7:29 AM
>>> To: [email protected]
>>> Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down
>>>
>>> W dniu 22.10.2020 o 15:12, Paul Gilmartin pisze:
>>>> On Thu, 22 Oct 2020 13:50:44 +0200, R.S. wrote:
>>>>
>>>>> Remark: while shortage of space is possible in PDSE, then shortage of
>>>>> directory blocks is not possible.
>>>>>
>>>> What happens if an inquisitive programmer mischievously adds an
>>>> unbounded number of empty  members to a small PDSE?  Or adds
>>>> numerous aliases to a nearly full PDSE?
>>> My guess: x37 abend or next extent. This is NOT directory full, it is
>>> lack of space.
>>>
>>> ...
>>
>> --
>> Joel C. Ewing
>>
>
>

-- 
Joel C. Ewing

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to