Peter, I understand that you are coming from a much deeper understanding of the current internals of z/OS than the rest of us and from the standpoint of what would be practical to implement, but what you are basically saying is that the current design of LNKLST is flawed and difficult to adapt for safe dynamic LNKLST.
If one were starting a design from scratch, there are clearly ways dynamic LNKLST can be safely done [for cases where cross-module conflicts are not an issue] without serializing all fetches: The manner in which services and address spaces were allowed to use LNKLST DCBs should have been much better constrained so that those system processes using a LNKLST DCB for any extended time were required to "register" their active and continuing usage, and each time before actual use check whether there is a pending request to quiesce the DCB, in which case if possible the service should relinquish its use of the old DCB and refresh its LNKLST knowledge. With such a design the system should then be able to "advise" user address spaces to cooperate in the UPDATE process and know which active address spaces are holding up a safe UPDATE. There would be NO need under such a design to serialize all fetches, only to serialize updating the list of active users of a LNKLST DCB, which would be very quick and of minimal impact. I admittedly have no perception of how many places in z/OS would have to be changed to implement such a re-design, but it does seem like something worthy of thought. IBM couldn't directly address related issues in 3rd party vendor code or installation code, but if all the IBM address spaces and services were to play by better rules that allowed for safe LNKLST update, that alone should improve the stability of z/OS across a LNKLST UPDATE. Joel Ewing On 7/19/19 6:45 AM, Peter Relson wrote: > <snip> > If so, perhaps DELAY=255 should be the default. If not, why ever use it? > </snip> > That would never be done. This delays the completion of the command. It is > not up to IBM to decide how long a customer can tolerate that. > What is being deferred, in particular, is the closing of the old DCB and > the free-ing of control structures that goes with that. The update of > address space(s) to use the new LNKLST is done "immediately". > > <snip> > It seems rather obvious that what you would want LNKLIST UPDATE do is > insure that any in-flight or incomplete loads of modules are forced to > complete before the old LNKLST definitions are allowed to disappear, > </snip> > What is also obvious is that that is not possible without crippling the > system, as it would requirel having complete serialization across all > fetches for the complete duration of every fetch. > > Some processes simply cannot tolerate the performance impacts of obtaining > serialization. Compromises are the result. Here, it is the unpredictable > dangerousness. Elsewhere, it might be that storage must be orphaned. Etc. > > <snip> > someone should be able to re-design LNKLST UPDATE so that it is 100% safe > when used within those contraints! > </snip> > Without adding "and never close the old LNKLST DCB", it cannot, while > living within the constraint of having the system remain usable. > > Peter Relson > z/OS Core Technology Design > > > -- Joel C. Ewing ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
