Why do you assume there is/should be other abend than x37?
Any request for new place in the dataset could end with such an abend.

--
Radoslaw Skorupka
Lodz, Poland






W dniu 23.10.2020 o 15:15, Joel C. Ewing pisze:
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




======================================================================

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: [email protected]. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 0000025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: [email protected]. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
0000025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

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

Reply via email to