I think you can only have on Linklst activate at one time. And only good until the next IPL - where if not updated in the IPL member(s) will get lost.
So how you name them in your Parmlib dataset is up to you. Remember 00-99,0a-zz,and you can include @ $ # - are available. So how you set them up to activate, would be up to you so long as your PARMLIB dataset is large enough to hold all your iterations. Remember to update your IPL member so you do not lose your changes. The CSVLLAxx dynamic activation could be lost over an IPL So I have 00 Non PDS/E Linklst and 01 PDS/E Linklist (activated through COMMNDxx) I have to ensure any system changes are updated in there so they are not lost during any IPL. So if you do a dynamic activation use B1 for the first product, then the B2 (for the second product) would need to contain the same info as B1 plus the new product. The backout members would need to reverse that. There are lots of discussions in the IBM MAIN Archives on this Process in the member COPY THE CURRENT LINKLST Add new libraries using BEFORE or AFTER statements Delete other libraries using REMOVE Statements (Not looking at the book, so from memory) ACTIVATE All done in one member. Hope that Helps Note: So long as you are the only one doing this, it will be fine. Should others start to "help" you convention will go out the door pretty quick ;-D Lizette > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On Behalf Of > Steve Horein > Sent: Thursday, May 03, 2018 6:24 AM > To: [email protected] > Subject: Dynamic LNKLST SET limitations? > > Is there a practical limit to the number of dynamic LNKLST sets created? > > I find myself in a position to deploy two products upgrades, both requiring > new data sets in LNKLST (either new names, or under-sizing issues). To > accommodate implementation and back out processes, I would like to come up > with a naming convention for the LNKLST sets that includes a numeric suffix, > such that if product "A" is introduced first, the new set name is LNKLST01. > When product "B" is introduced, set name LNKLST02 is defined. If product "A" > requires back out, LNKLST03 is defined. If product "B" requires back out, > LNKLST04 is defined, etc, etc, rinse, repeat. I honestly doubt there would > ever be need to extend past "LNKLST99", or even "LNKLST09", but knowing a > limitation (if one exists) will help shape a standard. Is hex representation > acceptable, allowing from 01-FF sets? Does decimal representation, allowing > from 01-99 sets exceed a limit? > > If the maximum number of LNKLST sets is defined somewhere, my apologies for > not seeing it! > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
