It is my felling that IEBCOPY should be corrected to compress a PDSE inplace to degas a dataset defined as a lnklst library. If copy done under TSO releases to the lnklst dataset releases the gas bubbles in the PDSE then IEBCOPY ULTILITY should also accomplish this task to relieve the a D37 error. We should not have to create a new library in order to release the gas bubbles.
Regards Otto Schumacher HP Enterprise Services Infrastructure Specialist Ahold Account CICS & Capacity Technical Support Ahold Building 1200 Brookfiled Blvd. 2S-034 Greenville, South Carolina, 29607 Cell: 864 569--5338 Tel: 864 987-1417 Fax: provide upon request E-mail: otto.schumac...@hp.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Joel C. Ewing Sent: Thursday, January 19, 2012 6:37 PM To: IBM-MAIN@bama.ua.edu Subject: Re: PDSE On 01/19/2012 02:55 PM, Paul Gilmartin wrote: > On Thu, 19 Jan 2012 11:09:27 -0800, Schwarz, Barry A wrote: > >> IEBCOPY compress generates an error message for a PDSE. >> > Become familiar with: > > Title: z/OS V1R12 DFSMS Using Data Sets > Document Number: SC26-7410-10 > > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2d490/3.8.7.1 > > 3.8.7.1 Establishing Connections to Members > > Someone might be failing to issue a DISConnect or RELEASE. > > (It's not at all clear to me why this problem shouldn't occur similarly > with a classic PDS.) > > -- gil > ... How could this be an issue with the classic PDS? Surely the "connection to members" concept doesn't exist for a traditional PDS, as old member data can only be eliminated by completely reorganizing, compressing the PDS. With no re-use of deleted-member space, there is no need for a special mechanism to prevent over-write of a deleted member while some other task is still reading the now-deleted version of the member. The referenced 3.8.7.1 specifically applies to PDSE libraries; but it also implies that if LLA REFRESH is not sufficient to DISConnect or RELEASE all the old member connects on a PDSE in the LINKLIST and allow the deleted PDSE space to be re-used (don't know for sure that this is the case, but Juergen's experience that started this thread at least raises that as one possibility), then LLA REFRESH would seem to be failing to do something it really ought to be doing. Someone surely is in a position to set up a simple test case, or may have already tested this: A PDSE library in LINKLIST/LLA which no one is actually using with but members and minimal free space; delete all members; check whether there is enough free space to re-create the members; if not, do an LLA REFRESH on the library; re-check whether there is now free space for the new members. If the deleted space is never freed, I would say we have a problem that needs fixing. I gather from past warnings on ibm-main about forcing dynamic LINKLIST updates on running address spaces that there are some cases where only a partial load of a PDSE program object member has been done and a potential of additional future loading activity still exists. If z/OS is smart enough to recognize this situation, then one would want it to preserve a PDSE member connection in such a case and continue to make the old member version available to the old A/S even across an LLA REFRESH; but I would also suspect this technique unlikely to be in use on a typical Installation library added to LINKLIST. -- 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
