Peter, Obviously UPDATEing the link list for an address space (AS) in ways that would enable a future fetch by that AS to load a module that was incompatible with existing code in the AS could have unknown and probably bad side effects, but I would contend there are many cases where you know the change in the link list is not of that nature, perhaps required to fix a malfunctioning module for a future fetch by a running AS, or to resolve issues with a link list ds taking an additional extent, without disrupting the continuing availability of that AS.
My recollection from previous discussions of LNKLST UPDATE risks is that the worst part of the exposure came from an ability of of a loadmod fetch from a PDSE to defer loading of some module code pages until they were actually referenced, and that dynamically updating the linklist created the possibility that an unrelated 4K code page could be substituted for one of those pending references. Is that recollection accurate, and if so is your warning an indication that this still hasn't been resolved in the latest z/OS release? If this is indeed the case I'm surprised this isn't considered a bug that should be fixed, as it would certainly seem to an integrity exposure that affects system availability; and where there is any IBM or other vendor code involved in the AS you would have no way to know for sure if there is an exposure. If there is something in the AS control blocks to indicate that certain page faults should be resolved by a page load from a link list dataset, then obviously it is technically possible for LNKLST UPDATE processing to find such unloaded pages and force a loading of all such pages before completing the LNKLST UPDATE for that AS. It would obviously be better for LNKLST UPDATE to potentially add even significant additional overhead rather than add an exposure for executing the wrong code, which would create an exposure for application loss, application data loss, or system loss! If the PDSE issue has been resolved in some way on recent z/OS versions and your warning is just because of the potential that future load module fetches by an active AS after the UPDATE might be incompatible and cause problems, then I would say the warning is overly restrictive. In the case where IBM or vendor code is changed in the new link list, then barring explicit advice from the vendor that an UPDATE is OK, I would agree that to use it is rolling the dice. When the changes in the link list only involve user or installation code, there is a much higher likelihood that you would understand the way the code is used and whether there are interdependencies that would be a problem and whether use of LNKLST UPDATE poses unacceptable risk. Joel C Ewing On 10/30/2009 06:23 AM, Peter Relson wrote: > LNKLST UPDATE is never safe no matter what you do. > The DELAY sub-keyword of LNKLST UPDATE might help to reduce the exposure. > It will in no way eliminate it, any more than you can guarantee the > wall-clock elapsed-time of a specific piece of code. > > Joe Owens wrote >> It is not properly documented anywhere > Perhaps Joe could elaborate on that. It is documented in both the z/OS 1.10 > and 1.11 books, albeit not overly descriptive. > > Peter Relson > z/OS Core Technology Design ... -- Joel C. Ewing, Fort Smith, AR [email protected] ---------------------------------------------------------------------- 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
