Thanks for the replies!

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.

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,

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.

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.
Ouch. I just made someone's day a little bit worse by reusing LNKLST02.
I'd rather move forward with creating LNKLST05, preserving integrity of
both know product "A", and surprise product "C".

In other words, always +1 to reduce risk.
This is of course is not a typical scenario, but potentially one I find
myself in!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to