Discussion:
Dynamic LNKLST SET limitations?
(too old to reply)
Steve Horein
2018-05-03 13:22:22 UTC
Permalink
Raw Message
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-05-03 13:36:05 UTC
Permalink
Raw Message
Post by Steve Horein
Is there a practical limit to the number of dynamic LNKLST sets created?
I don't know.... I would guess that there is some common storage required for
each LNKLST set.
Post by Steve Horein
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?
It sounds like you are trying to fit your naming convention into 8 characters
when 16 are allowed. Naming them LNKLSTxx seems redundant to me and
uninformative. What if you included the product name that was the reason
for the new LNKLST into the name?
--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Lizette Koehler
2018-05-03 13:39:45 UTC
Permalink
Raw Message
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-----
Steve Horein
Sent: Thursday, May 03, 2018 6:24 AM
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Lizette Koehler
2018-05-03 13:41:47 UTC
Permalink
Raw Message
Oops - I said CSVLLA - I meant the LINKLIST dynamic activation - sorry

Lizette
-----Original Message-----
Lizette Koehler
Sent: Thursday, May 03, 2018 6:41 AM
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.
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-----
Behalf Of Steve Horein
Sent: Thursday, May 03, 2018 6:24 AM
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2018-05-03 13:46:31 UTC
Permalink
Raw Message
Post by Steve Horein
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!
​The names are effectively unlimited. From the book at
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieae200/linsyn.htm

====

NAME(name)The name of the LNKLST set that you want to specify. Naming
conventions are as follows:

- You can specify from 1 to 16 characters for name.
- You can use alphanumerics, underscores, periods, and #, $, or @.
- Do not use imbedded blanks.
- Do not use the names CURRENT or IPL. The system uses CURRENT to mean
the current LNKLST set and IPL to mean LNKLST information specified in
SYS1.PARMLIB member LNKLSTxx.
- Do not begin the name with SYS. SYS is reserved for IBM® use.



====​

​If you want to calculate that, there are 31 valid symbols. So there are
36^1 single character names; 36^2​ double characters; up to 36^16 (~8E24).
So sum those up and you'll know the theoretical limit. You'll run out of
ECSA (or wherever the z/OS control blocks are built) long before then.

Now, I am pretty sure that you can do an second ACTIVATE on a previously
defined LNKLST. So assume the following:

LNKLST00 - name at IPL.
LNKLST01 - Install Product "A" (only)
LNKLST02 - Install Product "B" with product "A"
LNKLST03 - Install Product "B" (only, no "A")

SETPROG LNKLST,ACTIVATE,NAME=LNKLST00 - Do this to remove both product "A"
and "B"
SETPROG LNKLST,ACTIVATE,NAME=LNKLST01 - Do this to install "A"
SETPROG LNKLST,ACTIVATE,NAME=LNKLST02 - Add "B" while leaving "A"
SETPROG LNKLST,ACTIVATE,NAME=LNKLST03 - Leave "B" while removing "A"
SETPROG LNKLST,UNDEFINE,NAME=LNKLST01 - Remove "A" only LNKLST (fails if
LNKLST is in use by some address space)
SETPROG LNKLST,UNDEFINE,NAME=LNKLST02 - Remove "B" only LNKLST (see comment
above)

-- after the above LNKLST01 & LNKLST02 are _gone_, unless some address
space is using them. This means that the name can be reused!


--- Fixed Product "A" and reuse the same LNKLST name as above for
consistency.
SETPROG LNKLST,ACTIVATE,NAME=LNKLST02 - Add "A" while leaving "B".

SETPROG LNKLST,ACTIVATE,NAME=LNKLST01 - Leave "A" while removing "B"


and so on.
--
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-05-03 14:25:34 UTC
Permalink
Raw Message
Post by Lizette Koehler
I think you can only have on Linklst activate at one time.
Yes, but you can have address spaces still using an inactive LNKLST.
AFAIK this does not cause any problems. New jobs will always use the
active LNKLST.
--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Horein
2018-05-03 19:09:50 UTC
Permalink
Raw Message
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Relson
2018-05-04 11:45:14 UTC
Permalink
Raw Message
As with anything that has storage requirements, there is a limit. That
limit might be enforced or might be "until you run out of the necessary
storage".
LNKLST sets are no different. There is no enforcement. The storage in
this case is ECSA.

Terminology correction: There is a *current* LNKLST set. There can be any
number of *active* LNKLST sets.
An active LNKLST was current at some point but is still in use by some
address space, whether it is still current or not.
Once the last user of a non-current LNKLST set ends, the LNKLST set
becomes inactive.

It is true that new jobs and new address spaces are associated with the
current LNKLST set.
That association remains for the life of the job or address space unless
you do a LNKLST UPDATE.

Doing a LNKLST UPDATE is unpredictably dangerous, and can range from
having no down side to abends to a wait state.
There is little to no sympathy to be given to those who encounter the
adverse effects because they did it to themselves..
The only thing that is safe is to let the system do the LNKLST assignments
as it intends to do.

Peter Relson
z/OS Core Technology Design


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-05-04 12:05:19 UTC
Permalink
Raw Message
Post by Steve Horein
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.
Post by Steve Horein
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.
Post by Steve Horein
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.
Post by Steve Horein
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...