On 7/17/19 4:08 AM, Elardus Engelbrecht wrote: > Peter wrote: > >> Is it recommended to do a dynamic LINKLIST during a peak production hours ? > Rather not, but this is not my dog. > > >> Will there be any impact to the system during that time as we stop LLA as >> well. > Why do you want to stop it? What are you trying to solve? > > Why not rebuild a new linklist table and then do a refresh on that new table? > > Something like this in a PROGxx member: > > LNKLST DEFINE NAME(????A) COPYFROM(????) > LNKLST ADD NAME(????A) > DSN(<???>.LOAD) > LNKLST ACTIVATE NAME(????A) > LNKLST UPDATE JOB(*) > > >> Please share me your opinion on this and your thoughts. > I would practise first on a sandbox and then do the same on to a prod LPAR > during AFTER HOURS! > > Groete / Greetings > Elardus Engelbrecht > Have things changed? There has been considerable discussion on Dynamic LNKLIST in the past on this list.
Basically "ACTIVATE" was always safe, provided it is OK that newly started address spaces use the new LNKLST and old address spaces continue with the previous LNKLST concatenation until restarted. But "UPDATE" has always been advertised as with risk. To quote from the Knowledge Center on "Updating LNKLST Concatenations" for z/OS 2.3.0: "Be careful when you use UPDATE. Updating an address space while a program in that address space is fetching a module can cause the fetch to fail or to locate an incorrect copy of the module. The system does not attempt to verify the validity of the data for UPDATE". If your only choice is between UPDATEing a running address space or causing a service interruption to critical users, sometimes you can reduce possible exposure by only updating the specific address spaces that must see the change, rather than updating all running address spaces. I was always lucky when I did LNKLST UPDATE, but I also did this with the awareness that if it did cause some critical address space to fail that an IPL might be the safest recovery -- that there was a nonzero, hopefully low, probability that using this to avoid a service interruption could instead cause a bigger service interruption. Testing this out on a sandbox system only proves the command syntax and sequences are correct. As the nature of potential UPDATE-induced failures is highly dependent on address space activity, I wouldn't draw any conclusions that lack of failures on a sandbox means there is no UPDATE risk on a much more active production system. Joel C Ewing -- Joel C. Ewing ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
