Oops - I said CSVLLA - I meant the LINKLIST dynamic activation - sorry Lizette
> -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On Behalf Of > Lizette Koehler > Sent: Thursday, May 03, 2018 6:41 AM > To: [email protected] > Subject: Re: Dynamic LNKLST SET limitations? > > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
