<snip> You misunderstand what we did. We put only PDS into the IPL Linklist (built from PROG00). We then as soon as commands were available would do a linklist switch built from PROG01. We heavily used the dynamic Linklist and LPA list features but just avoided them being in the initial list built at IPL time.
The reasoning for that is that we had all of our production libraries in Linklist and did not use any steplib/joblib. PDSE Libraries in the INITIAL (IPL) Linklist had issues when dynamically removed from the linklist (what the problem was I no longer recall) so we came up with the 2 stem Linklist build at IPL time. After that all normal Prog** was followed. </snip> There is no safe way to "dynamically remove" ANY data set (PDS or PDSE) from any active LNKLST set. You can accomplish such removal as long as you are willing to take the inherent risks (which include your system's crashing in any number of ways). As has been clearly gone over many times, the furthest you can safely go is to remove a data set from a new LNKLST set, activate that LNKLST set (so that it is now current). Any subsequent job or address space will use the now-current LNKLST set and thus will not use the now-removed data set. But already-existing jobs and address spaces will continue as-is. SETPROG LNKLST UPDATE is available for those willing to take the risk of "unpredictably dangerous". Maybe you feel that that risk is worth it if you would be re-IPLing otherwise (the "try it", "hope for the best", "re-IPL if anything strange happens" approach). The term "the LNKLST" is inaccurate these days. There can be multiple "active" LNKLST sets. There is only one "current" LNKLST set. The only "problem" that I recall is that if you have a PDSE in the IPL-time LNKLST set you will not be able to configure offline the volume on which that data set resides, even if you accomplish "dynamically remove".I don't recall if that applies to non-IPL-time LNKLST sets. <snip> Seymour hit the nail on the head. Using LNKLST00 is the “old or non dynamic” method and doesn’t allow PDE. Coding LNKLST as part of the PROGxx concatenation is using dynamic link list and does allow pdse. While I haven’t tried it, I suspect the same would be true if retiring LPALST00 in favor of putting those statements in the PROG concatenation as well. </snip> Not true about LNKLSTxx and PDSEs. LNKLSTxx has allowed PDSEs since the advent of PDSEs. I don't know what is meant by "if retiring LPALST00 in favor of putting those statements in the PROG concatenation as well". You cannot define the LPALST via PROGxx. I don't think there is any functional reason to enhance PROGxx to allow the LPALST to be defined via PROGxx instead of LPALSTxx, so it seems unlikely that such an enhancement would be made. Peter Relson ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
