Certainly a very strong argument against ever performing UPDATE=*. I appreciate the clarification, but certainly don't like the answer. Without some idea about what z/OS services or subsystems might make unwarranted assumptions about old lnklst control structures, the user or other vendors are in no position to make a rational assessment about whether even an update on a specific running address space poses an imminent danger to the system. If UPDATE can only be used when an unplanned IPL at some arbitrary point in the future can be tolerated, that would pretty well eliminate the usefulness of this option on a production system. If the risk could be isolated to the updated address space, that might be acceptable; but if it puts arbitrary address spaces or the entire system at risk, that is not.
>From our usage of this in the past (before the risks were advertised), I would question the assumption that in the majority of cases it would not be a requirement, or at least highly useful if running address spaces could be updated - TSO user communities running ISPF-based applications, and in some cases CICS-regions come to mind. Back before lnklst PDSEs were common and before we were aware of risks, we even did UPDATE=* several times a year to roll in revisions and free up obsolete lnklst datasets where the intent was definitely to affect running address space. We might rename an old dataset that was removed from lnklst, but were careful to never delete or move such datasets until after the next IPL. I guess we were just lucky, but we never saw any adverse system behavior from this practice. JC Ewing On 11/01/2009 08:13 AM, Peter Relson wrote: > The page-fault-driven loading case from PDSE was addressed many years ago. > It was not done solely for integrity reasons. It was addressed by not doing > page-fault-driven loading at all for LNKLST fetches. > > The problem that will exist forever is references to the control structures > that will no longer be valid (or no longer be recognized as being part of a > LNKLST, for which special rules apply) once a LNKLST update has been made. > Can you guarantee, no matter how long you wait, that no address space > relies on those structures? Not usually. A delay makes it less likely that > an operation is still in progress, but by no means eliminates the > possibility. And these references, I believe, might not even be limited to > within the scope (for example) of a LOAD or similar operation, especially > when program objects / PDSEs are involved. That is a recollection; I don't > have concrete examples to share. > > The safe thing to do is not to use UPDATE. In the majority of cases, > LNKLST updates are needed only by newly started programs, not existing ones > (for which case no UPDATE is needed or appropriate). The rules are what the > rules are. They will not change. It's your system, so you can choose to > follow them or not at your own risk. But you should not expect subsequently > to be able to complain about problems that happen to arise as a result. > >> 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 in that case it is much more likely that the update is needed only by > programs that start (or are restarted) after this point, so no UPDATE is > needed. > > FWIW, an integrity issue caused by "improper" usage by an authorized user > is to be dealt with by the user. The system for the most part has no > alternative but to do what it has been told to do, as the authorized issuer > could do it itself without cooperation by the operating system if it chose > to.. > > 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
