Peter >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.
This is I'm sure the exact issue we had - everything we did was to reduce the IPL Linklist set and then add the libraries dynamically later Jerry Whitteridge Sr Manager Managed Services Tech Operations & Innovation [email protected] 480 578 7889 -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Peter Relson Sent: Tuesday, February 3, 2026 2:03 PM To: [email protected] Subject: EXTERNAL Email: Re: Do you still have to add PDS/e separately at IPL in lnklst <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 ________________________________ Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. ________________________________ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
