On 2 Nov 2009 06:35:21 -0800, in bit.listserv.ibm-main you wrote: >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.
I still remember the notifications that were sent out when the Tandem system at the shop where I worked. Basically they said that the operator would do some simple procedure and that was it. I'm not even certain if there was an outage. > 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 ---------------------------------------------------------------------- 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
