>If the risk could be isolated to the updated address >space, that might be acceptable;
The risk is isolated to "the updated address space" if you only update that address space. If you ask to update every address then you apply the risk to every address space. None of the appends has asked "why do you want to use LNKLST UPDATE with JOB=*"? The reason is probably "because if I update everyone then I don't have to worry about just who needs the new LNKLST set" but going with that is "but then every address space is at risk". The functional reason I know of why people would want to do a LNKLST UPDATE with JOB=* is because they want to get the system to stop using "data set x" (thus the new LNKLST set does not have data set x") because "data set x" is on a volume that they feel that they must take offline "now". The choice then is between taking the volume off now and putting your system at risk, or deferring that action if that is feasible. The system is yours; the choice is yours. What reasons do you use it for? You surely all know that the recommendation is not to apply service to a running system. Of course many do not pay attention to (or perhaps agree with) that recommendation. Aside from service, we're talking about "new function". Often, new function does not need to be made available to curently-running jobs. An exception might be something that is run in the master address space. But even there, an alternative could be to put the new module(s) needed within the master address space into dynamic LPA and not update ASID 1 to use the new LNKLST set. Obviously that alternative is not always viable. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
