Re: Dynamic LINKLIST impact
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic LINKLIST impact
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. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic LINKLIST impact
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: > > If so, perhaps DELAY=255 should be the default. If not, why ever use it? > > 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". > > > 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, > > 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. > > > someone should be able to re-design LNKLST UPDATE so that it is 100% safe > when used within those contraints! > > 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
How does HPE non-stop prev. Tandem do it was Re: Dynamic LINKLIST impact
[Default] On 19 Jul 2019 04:46:06 -0700, in bit.listserv.ibm-main rel...@us.ibm.com (Peter Relson) wrote: In looking at the below discussion, I am brought back to the question as to how HPE non-stop (started out as Tandem) manage the update process to avoid a shutdown. Even though it is UNIX based, there are the same logical problems associated with updating running code. Clark Morris > >If so, perhaps DELAY=255 should be the default. If not, why ever use it? > >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". > > >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, > >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. > > >someone should be able to re-design LNKLST UPDATE so that it is 100% safe >when used within those contraints! > >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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic LINKLIST impact
If so, perhaps DELAY=255 should be the default. If not, why ever use it? 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". 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, 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. someone should be able to re-design LNKLST UPDATE so that it is 100% safe when used within those contraints! 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
Re: Dynamic LINKLIST impact
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: > > 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. > > > 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
Re: Dynamic LINKLIST impact
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. 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic LINKLIST impact
It should be safe as long as you don't do UPDATE. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Peter Sent: Wednesday, July 17, 2019 4:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Dynamic LINKLIST impact Hi This is a general question. 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. Please share me your opinion on this and your thoughts. Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic LINKLIST impact
On Wed, 17 Jul 2019 09:28:57 -0500, Elardus Engelbrecht wrote: >I was also lucky, but when we do a LNKLST UPDATE, we rather do it after hours >if we simply cannot do a IPL. If you simply cannot IPL, can you justify LNKLST UPDATE, knowing that it might cause you to have to IPL? I will admit that I have used LNKLST UPDATE, occasionally with JOB(*), but only when an IPL would have been tolerable. When creating a new LNKLST set, IMO you should consider carefully the reason for it and, if possible, recycle the address space(s) that you want to use the new LNKLST set. When you do an UPDATE of an address space, and all goes well, any new modules that are LOADed from LNKLST will come from the new LNKLST. However, modules that have already been LOADed from the old LNKLST set are still in memory, and you may end up with modules modules in that address space that are not compatible with each other. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic LINKLIST impact
Joel C. Ewing wrote: >Have things changed? There has been considerable discussion on Dynamic >LNKLIST in the past on this list. Yes, I remember those discussions. >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. >"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". I agree 100% with that quote. >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. I was also lucky, but when we do a LNKLST UPDATE, we rather do it after hours if we simply cannot do a IPL. >As the nature of potential UPDATE-induced failures is highly dependent on >address space activity, ... Agreed. First thing IPL, if not possible, do that UPDATE during a quit time while taking an extreme risk that something may go down the drain... As always YMMV. I still want to see why the OP wants that route. Thanks Joel for your kind comments. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic LINKLIST impact
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
Re: Dynamic LINKLIST impact
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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Dynamic LINKLIST impact
Hi This is a general question. 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. Please share me your opinion on this and your thoughts. Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
