In theory and with proper planning, one should not need to compress active linklisted libraries, PDS or PDSE. After all, you should not be updating your live system datasets. Maintenance should be done on copies and brought in via (rolling) IPL.
The idea of application libraries in the linklist is not something I like, but they can certainly be dynamically added after IPL and removed, update/compress, re-added for maintenance. Even here, a copy with decent change control is a better idea. After saying this, I do have a couple libraries where this need arises. But, with them, I do know which address spaces are using them and I am not risking full system outage if I cheat. Dave Gibney Information Technology Services Washington State University > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Scott Ford > Sent: Friday, January 20, 2012 12:46 PM > To: [email protected] > Subject: Re: PDSE > > So this has my curiosity peaked, how does IBM suggest doing a compress on > a Linklist lib that needs compressing, inquiring minds would love to know ? > > Sent from my iPad > Scott Ford > Senior Systems Engineer > www.identityforge.com > > > > On Jan 20, 2012, at 8:09 AM, Peter Relson <[email protected]> wrote: > > >> 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. > > > > This is not good advice, in general. Of course it's your system, so > > shooting yourself in the foot is always an option you are allowed to take. > > > > The system allocates LNKLST data sets for a reason -- so that you can't > > get the data set DISP=OLD which in turn means that if you're doing things > > right you will not be able to do such damaging operations as compress > > (where for compress "doing things right" means getting the data set > > DISP=OLD, and by "damaging" I mean damaging to other processes that > might > > have knowledge of where a member is within the data set, not damaging > to > > the data set itself). > > > > Bluntly, if you compress a LNKLST data set without DISP=OLD, then don't > > complain if something related to that data set no longer works. > > > > If you must compress the data set, then get it out of the LNKLST and out > > of LLA management. And note that there is no fully safe way to do the > > former unless you have added the data set to the now-activated LNKLST > set > > after IPL and are able to terminate/restart all jobs that started after > > that LNKLST set was activated. > > > > Should compress require DISP=OLD? Maybe. But that's unlikely to change, > > and definitely won't change as a system default (one could imagine giving > > the customer a knob to ask that for their system the default be that). > > > > Peter Relson > > z/OS Core Technology Design > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
