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
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"
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
-- 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
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.
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN