Tom, I envision this a something that could be done at the fetch services routine level while preserving the user interface, so that LOAD LINK end users are not affected. The awareness of which library DCB is actually being used for the fetch I/O and whether LNKLIST is ieven nvolved is surely within the fetch service code, not within the code that invokes LOAD or LINK. AFter LNKLST UPDATE of all address spaces is complete it needs to be possible to determine that no LOAD/LINK is still in progress that was initiated prior to the UPDATE (that might yet generate an I/O for the old DCBs) and that no I/Os associated with the old DCBs are still in-flilght or pending. When that is satisfied, I would think the old DCBs could be closed and deallocated safely, rather than waiting on some specified delay time which might or might not be adequate..
Something that is conceptually easy to describe may be difficult to implement, and a major redesign of a critical service like fetch processing is not a casual undertaking; but surely much simpler by several orders of magnitude than changing all code that invokes LOAD or LINK. Perhaps if it were on record as a long-term goal, someone clever would figure out how to get there incrementally. Joel C Ewing On 7/19/19 11:38 AM, Tom Marchant wrote: > On Fri, 19 Jul 2019 10:47:14 -0500, Joel C. Ewing wrote: > >> 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. > Wow. You are suggesting that every program that issues LOAD, LINK, etc. > would have to be rewritten, and made considerably more complex. > >> 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. > With such a design, LNKLST would not be transparent, but every program > that loads a module would have to coordinate with LNKLST every time. > -- Joel C. Ewing ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
