On Thu, 3 May 2018 14:11:11 -0500, Steve Horein wrote: >Yes, I used the set name "LNKLSTxx" arbitrarily for demonstration purposes. >The current PROGxx defines several sets, with the final set activated at >IPL time having a name similar to &SYSNAME.LNK. > >What I am trying to avoid, in addition to "requiring" an IPL for the sake >of 1 or 2 products, is the risk of undoing a change performed by someone >else. >I think the esteemed Mr. McKown identified some of the potential issues >involved (re: [UNDEFINE] "fails if LNKLST is in use by some address space".) > >Presume LNKLST00 contains both product "A" and product "B". > >Time constraints dictate product "B" is upgraded before product "A". >LNKLST01 is defined with new product "B" data sets, resolving an SD37 abend >when attempting to reuse the existing LNKLST00 data sets.
When you upgrade a product, you should ALWAYS use new data sets. For the LNKLST data sets, a new LNKLST set is created, with the new library replacing the old one. You may have to add an entry to the APF list too. Do not use SETPROG LLA,UPDATE unless it is absolutely necessary that an address space have the new LNKLST set. It is better to recycle the address space. Other data sets, like panels and clists can be accessed using a data set alias that is defined with SYMBOLICRELATE. All you have to do is to change the symbol and activate the new LNKLST. The window of opportunity for a job to start and allocate mixed versions is small. >Time now allows product "A" be upgraded. LNKLST02 is defined to include >system specific data sets for the product, resolving the need for >SYSPLEX-wide product outage whenever the current shared data set needs the >ole "kill-n-fill" followed by "F LLA..." approach, Yes, that is dangerous, and I would never do that on a production system. For that matter, I would not do it on a test system either. It is easy to do it the safe way, as I described above. BTW, when you define a new LNKLST set, LLA refresh or update is not needed, though an LLA UPDATE is needed if you want to remove a data set from LLA management. >At this point, should product "B" encounter an error, my preference would >be to define LNKLST03, with the bigger data sets being deleted after the >COPYFROM=CURRENT, leaving product "A" intact. I think you mean add the old data set after the previous new one and delete the previous new one from the new LNKLST set. Also change the symbol used by SYMBOLICRELATE for other data sets. >If PTF for product "B" comes along, I suppose going back to LNKLST02 is an >option, but... suppose someone has upgraded product "C" in the mean time, >introducing LNKLST04. Yes, you have to know what has been done and why. D PROD LNKLST is your friend. There are many variations. -- Tom Marchant ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
