The descriptions I find for the UPDATE DELAY=nn parameter are rather terse. It only claims to delay "closing and unallocating LNKLST data sets that are no longer in use", which sounds like it shouldn't reduce the exposure unless the "no longer in use" determination is inaccurate. Does the maximum of 255 seconds delay actually inhibit starting new actions on any of the old LNKLST datasets that that might cause problems, while allowing some problematic usage to complete? If so, perhaps DELAY=255 should be the default. If not, why ever use it?
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, so that the only concern would be whether versions of complete load modules fetched after the UPDATE were compatible with any complete load modules fetched before the UPDATE. More often than not you know precisely what modules have changed (in some cases that is nothing if the only object was to re-size or move a data set), and one can frequently make a reasonable, and sometimes exact, evaluation as to whether there is any exposure from module incompatibility. For those cases where you know that incompatibility at the module level is impossible, or that looping a few specific address spaces will resolve all compatibility issues, someone should be able to re-design LNKLST UPDATE so that it is 100% safe when used within those contraints! Joel C Ewing On 7/18/19 7:10 AM, Peter Relson wrote: > <snip> > Is it recommended to do a dynamic LINKLIST during a peak production hours > ? > Will there be any impact to the system during that time as we stop LLA as > well. > </snip> > > I agree with all the responses. > > The real answer depends on what the OP means by "do a dynamic LINKLIST". > If it means only "define and activate a new LNKLST set", then there is no > problem. That is the design point for the dynamic LNKLST function. I think > of "LNKLST update" as "unpredictably dangerous", both for the module > mismatch case that Tom M mentioned and for the cases where you rip things > out from underneath a fetch-in-progress or where PDSE operations are > involved (which can have longer durations iof sensitivity) -- the DELAY > option of LNKLST UPDATE should be considered for any use of UPDATE. > > There is potentially significant performance impact to any system if you > "stop LLA". But activating a new LNKLST set does not require stopping LLA. > You should not stop LLA if activating a new LNKLST set. > > 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
