Try running an IEBCopy compress against the data set (option "z" against. TSO-ISPF display of the PDSE). It might be a little complicated as it's in the Linklist, and so disp=old wouldn't work (still allocated to LLA), so you'll have to use disp=shri in a batch job.
Run this after deleting the members, and you'd also be as well to run an LLA refresh after this and then again after populating it again. Al Playford On 19 Jan 2012, at 17:50, "Joel C. Ewing" <jcew...@acm.org> wrote: > 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< >> juergen.kel...@deutsche-boerse.com> 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 jcew...@acm.org > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
