I forgot to mention that you can reduce the risks of using SETPROG LNKST,UPDATE by specifying the DELAY=nnn parameter. This causes the processing to wait for nnn seconds after doing the update before freeing control blocks for now unused LNKLSTs. This allows time for operations against old LNKLSTs to complete before control blocks that they may have been using get freed.
Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY > From: Jim Mulder/Poughkeepsie/IBM > To: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> > Date: 08/22/2014 12:32 AM > Subject: Re: PLPA entry (was PLPA enty) > > > > >On Tue, 19 Aug 2014 08:28:22 -0400, Peter Relson wrote: > > > > > >>The only thing that is truly safe is to let new address spaces and jobs > > >>use the new lnklst while old ones continue to use the old one. > > > > > >This has always been my approach - protect the long running address spaces. > > >Of course, on a sysprog sandpit it can be a matter of "full steam > > ahead, and damn the users". The users in that case being (only) "us". > > From: Brian Westerman <brian_wester...@syzygyinc.com> > > To: IBM-MAIN@LISTSERV.UA.EDU > > Date: 08/22/2014 12:15 AM > > Subject: Re: PLPA entry (was PLPA enty) > > Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> > > > > I think I have to disagree. I can't see where there is any evidence > > that altering the LINKLIST while things are running would not > > "work". If that were the case, I think there would be a lot of > > angry people opening problems with IBM support, and I would be one > > of the first on that list of people. > > > > Not using the features is not an option, that's why we asked for > > them in the first place. I know that IBM doesn't always provide > > what we ask for, but in this case it was done and it has never been > > unsuccessful for me. I install and upgrade new systems for clients > > many times per year and I have yet to have this process fail or to > > experience a problem with this method. > > > > I "could" just be lucky, but with the frequency that I use these > > commands and the number of systems I use them on, I would think that > > I would have experienced a problem by now.:) > I have to disagree with your disagreement. When these failures occur > on IBM test systems, people tend to send me the dumps. And I have > seen the failures on several occasions. > > I am not telling you not to use it, as long as you are in an > environment where you can understand and accept the risks. > But it was not possible to design it in a way which was free > from risks. > > Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
