On 01/19/2012 07:38 AM, Don Imbriale wrote:
From the DFSMS Using Data Sets manual:
*PDSE Unused Space*
PDS gas is the unreclaimed space in a PDS that was vacated when members
were deleted or rewritten. Users often overallocate their PDSs to allow for
the inevitable amount of PDS gas that would develop over time. With PDSEs,
you do not need to add additional space to the allocation to allow for
growth of the data set due to gas.
Studies show that a typical installation has 18% to 30% of its PDS space in
the form of gas. This space is unusable to the data set until it has been
compressed. A PDSE dynamically reuses all the allocated space according to
a first-fit algorithm. You do not need to make any allowance for gas when
you allocate space for a PDSE.
Space is only reclaimed for an OPEN for output when it is the only open for
output on that system. PDSE space cannot be reclaimed immediately after a
member is deleted or dated. If a deleted or updated member still has an
existing connection from another task (or the input DCB from an ISPF edit
session), the member space is not reclaimed until the connection is
released and the data set is opened for output and that OPEN for OUTPUT is
the only one on that system.
ABEND D37 can occur on a PDSE indicating it is FULL, but another member can
still be saved in the data set. Recovery processing from an ABEND D37 in
ISPF closes and reopens the data set. This new open of the data set allows
PDSE code to reclaim space so a member can now be saved.
- Don Imbriale
On Thu, Jan 19, 2012 at 7:26 AM, Juergen Keller<
[email protected]> wrote:
hello,
I have a very strange "problem". Maybe there is someone having an idea how
to solve it. So what happens:
We have a pdse-load-library (with only primary allocation - no secondary!)
for testing software. Now when testing a new versions we first delete all
members with a batch-job and copy the new version to this dataset. This
worked fine in the past but now ...
... we added this dataset to LINKLIST to get rid of the steplib. When I
now delete all members and copy the new version to that dataset I will
receive D37. I can see that after deleting all members the dataset is still
filled with 80%. Someone told me that I have to do a LLA REFRESh afterwards
but that did not help. When you browse that dataset ISPF says that there
are no members in, but its still 80% used. Then I do an ISPF-COPY for one
member and then its only filled with 1%. When doing the same with a batch
job it does not help.
I'm quite sure that it has to do with the LINKLIST and the PDSE-format. I
tested it with z/OS 1.10 and 1.12 .. no difference. Has anyone had the same
problem before and has a solution for me? Any comments are welcome.
regards Juergen
...
From Juergen's initial problem description and the DFSMS manual quote I
certainly would have expected the space reclaim to have occurred, but
perhaps not until after the LLA refresh. It sounds like his update
should have been the only OPEN for OUTPUT/UPDATE, and it doesn't seem at
all reasonable that LINKLIST/LLA/VLF should be holding any active
connects to PDSE members that wouldn't be reset by an LLA REFRESH (and
they certainly should not have any OPENs for OUTPUT). Perhaps he didn't
retry the update operation after the REFRESH, as it sounds plausible it
might take the next OPEN OUTPUT after the REFRESH before space might be
reclaimed.
I have seen some other counter-intuitive PDSE reclaim behavior, which
has at times made me wonder if the manual's description of space reclaim
was 100% accurate:
We had an application ISPF table library PDS with some rather large
tables which might get updated 100's of times in the course of a week,
mostly in-place updates because of table padding, but eventually a
library compress would be needed. Unfortunately, once or twice a year
when the system load was unusually heavy, someone would think they were
hung and attention-out of their ISPF session right in the middle of a
table update and trash a table. Since PDSE's don't allow updates
in-place, this sounded like an obvious candidate for migration to PDSE
to eliminate the integrity issue, using PDSE space reclaim to solve the
space/compress problem the ISPF in-place updates on a PDS were intended
to solve.
The Unexpected:
Over the course of the first day on a PDSE, the table PDSE library
grew to over 20 times the typical size of the original PDS. Finally, as
ISPF users began to logout at the end of the day, the deleted space
began to be reclaimed. The PDSE stabilized to this same daily pattern
consistently and ceased to grow, so it did solve the integrity problem
and was retained for that reason, but the extreme delay on space reclaim
and resulting size increase was an unpleasant surprise.
In retrospect, the peculiar behavior above may be explainable by the
ISPF internal behavior of keeping table libraries OPEN even after all
referenced tables have been closed. ISPF users who were no longer in
the application might still have had hanging references to the
application PDSE library - but I would not have expected this to tie up
connections to specific table members that were no longer in use, or to
have the major impact on space reclaim that it had. It's almost as if
some PDSE member "connection" issues never get fully resolved until the
applications are also forced to de-allocate the PDSE - which is
certainly not what I would have expected from my reading of the quoted
DFSMS manual.
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
