On Thu, 7 Jan 2010 11:45:47 -0500, Don Williams wrote:
>Many years ago, I wrote down my process to dynamically update LINKLIST.
>It uses the command "LNKLST Update Job(*)" which may not be
>appropriate in your environment (i.e., read the manual and test it
You can never adequately test LNKLST UPDATE JOB(*). It has been my
experience that it usually works with no problems. Indeed, I have used it
many times and never yet had a problem, but there is a reason that the
manual cautions against using it, and that it is known that it *can* cause
errors. I would never use it on a production system. Your procedure does
it twice, doubling the risk.
>in your environment). The basic logic is:
>
>1. Create temporary LNKLST set using SET PROG=CT
> a. Create temporary LNKLST set from current one ("source" LNKLST set)
> b. Force everyone to use temp LNKLST set.
> c. Delete source LNKLST set.
>2. Update PROGxx member that created the "source" LNKLST (the one used by
>IPL). We have separate PROGxx members for LNKLST, APF, & EXIT.
>3. Re-create updated LNKLST with SET PROG=xx.
>4. Switch back to updated LNKLST set using SET PROG=DT
> a. Force everyone to use updated LNKLST set.
> b. Delete temporary LNKLST set.
>5. Cycle LLA to pickup new library names.
I'm pretty sure that cycling LLA is not needed. When the new LNKLST set is
activated, LLA automatically manages all the data sets in the new LNKLST.
If you have removed libraries from LNKLST and ensured that no address space
still needs those libraries, you might want to remove them from LLA
management, though.
--
Tom Marchant
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
