<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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
