On 8 Jan 2008 05:12:03 -0800, in bit.listserv.ibm-main you wrote: >I thought the same thing. What exactly *do* PDSEs bring to the table that >PDSs didn't have or doesn't do?
They do bring a number of good things like large load modules, the theoretical ability for longer than 8 character names and the ability to move forward. They also bring the IDIOTIC idea that a library DOES NOT need to be accessible at IPL time and that access can be interrupted by a started task abend. This carries on the tradition started by not being able to use locally attached SNA 3270's as consoles because locally attached SNA 3270's were only usable through the started VTAM task. Clark Morris > >David Logan > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf >Of Van Dalsen, Herbie >Sent: Tuesday, January 08, 2008 5:53 AM >To: [email protected] >Subject: Re: Purge all members from a PDSE > >Edward Jaffe wrote: >>> DEL SYS1.PDSE >>> ALLOCATE SYS1.PDSE > >Old habits die hard... I thought that the whole purpose of PDSE's was low >maintenance... No more IEBCOPY compress jobs, No more delete/re-alloc jobs ? >If this thing(not a sand fairy but a PDSE) is happy to continue forever >without compression etc... why reverting to the old methods... Download the >CBT and be content... Less fragmentation on the disk if you aren't >continuously deleting and reallocating... > >Herbie > > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf >Of R.S. >Sent: 08 Januarie 2008 12:15 nm >To: [email protected] >Subject: Re: Purge all members from a PDSE > >Edward Jaffe wrote: >> R.S. wrote: >>> By command ? >>> >>> I'd suggest IDCAMS: >>> DEL SYS1.PDSE >>> ALLOCATE SYS1.PDSE >>> >>> Also works with PDSes. >>> :-) >> >> The problem with this or JCL re-allocation is the high potential for >> getting something wrong. Wrong attributes, wrong space, wrong placement, >> etc., the inability to perform the function with an outstanding DISP=SHR >> ENQ in effect, and the unfortunate effect on the data set creation date >> saved in the DSCB. > >ENQ is the reason. I get it. >However IMHO reallocation risk is not a risk in well managed environment. >I absolutely disagree with Wayne's point about UPDATE. User should have >sufficient authorities. What would you do with READ access? I would ask >for more. UPDATE is insufficient to compress PDS. Should I search for >another method of compress or simly request for ALTER? >My $0.02 > >BTW: I would suggest looking at Smart DFSORT Tricks. AFAIR it contains >trick for deleteting all members using DFSORT and IDCAMS. > > > >-- >Radoslaw Skorupka >Lodz, Poland ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
