Re: LNKLST Question
> http://www-01.ibm.com/support/docview.wss?uid=isg3T1010789 I don't know who wrote that document, but it wasn't me, and does not represent anything that anyone sane would think is suitable for production use. The basic problem is the use of LNKLST UPDATE JOB=* which is unpredictably dangerous and can vary from "working" to abends to crashing your system (with little to no sympathy for those that suffer the latter symptom). It is basically a "I have nothing to lose because I'd have to re-IPL anyway if this didn't happen to work" option. >would it be possible to activate LNKLST1 again instead of defining LNKLST3 ? Going beyond "possible", activating LNKLST1 would be the recommended approach. 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: LNKLST Question
On Tue, 31 Oct 2017 20:09:07 +, Steely.Mark wrote: >This is the steps to add and remove PDS/E from the LNKLST from an IBM document: >http://www-01.ibm.com/support/docview.wss?uid=isg3T1010789 > >To remove a PDSE in LNKLST: > >SETPROG LNKLST,DEFINE,NAME=LNKLST2,COPYFROM=LNKLST1 >SETPROG LNKLST,DELETE,NAME=LNKLST2,DSNAME=YOUR.LINKLIST.PDSE >SETPROG LNKLST,ACTIVATE,NAME=LNKLST2 >SETPROG LNKLST,UPDATE,JOB=* >F LLA,REFRESH > >To add it back, do the following: > >SETPROG LNKLST,DEFINE,NAME=LNKLST3,COPYFROM=LNKLST2 >SETPROG LNKLST,ADD,NAME=LNKLST3,DSNAME=YOUR.LINKLIST.PDSE >SETPROG LNKLST,ACTIVATE,NAME=LNKLST3 >SETPROG LNKLST,UPDATE,JOB=* >F LLA,REFRESH > >This would need to be done on all LPARs that share the link listed PDSE. > >My question is would it be possible to activate LNKLST1 again instead of >defining LNKLST3 ? > >We are z/OS v2.2. > It depends. If LNKLST1 is the IPL LNKLST, then no. If it isn't the IPL LNKLST then you can UNDEFINE LNKLST1 and then create a new LNKLST1. See "UNDEFINE" in the SETPROG LNKLST command syntax. But why? It doesn't hurt to have multiple names, even if no address spaces were using a particular named set. I would remove the library from LLA along with the 1st step as well. It should get automatically added in when you add the library back to the LNKLST since LLA manages the LNKLST set. In addition, I wouldn't use UPDATE,JOB=* at all unless it was some sort of emergency. Any new job will pick up the new LNKLST set. If you are trying to get some address space the new modules without restarting it, there is a chance it doesn't matter anyway since so many system / ISV address spaces keep the module loaded in internal storage at startup time. If you still think you need it, I would add ",DELAY=5" and limit it to whatever address space(s) you are trying to "fix". See the archives for past discussions on using "UPDATE,JOB=*" . The FM has some warnings on using UPDATE also. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
LNKLST Question
This is the steps to add and remove PDS/E from the LNKLST from an IBM document: http://www-01.ibm.com/support/docview.wss?uid=isg3T1010789 To remove a PDSE in LNKLST: SETPROG LNKLST,DEFINE,NAME=LNKLST2,COPYFROM=LNKLST1 SETPROG LNKLST,DELETE,NAME=LNKLST2,DSNAME=YOUR.LINKLIST.PDSE SETPROG LNKLST,ACTIVATE,NAME=LNKLST2 SETPROG LNKLST,UPDATE,JOB=* F LLA,REFRESH To add it back, do the following: SETPROG LNKLST,DEFINE,NAME=LNKLST3,COPYFROM=LNKLST2 SETPROG LNKLST,ADD,NAME=LNKLST3,DSNAME=YOUR.LINKLIST.PDSE SETPROG LNKLST,ACTIVATE,NAME=LNKLST3 SETPROG LNKLST,UPDATE,JOB=* F LLA,REFRESH This would need to be done on all LPARs that share the link listed PDSE. My question is would it be possible to activate LNKLST1 again instead of defining LNKLST3 ? We are z/OS v2.2. Thank You -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: setrog lnklst question
>UPDATE JOB(*) is dangerous >However, we use it with no ill effect. To be picky, that cannot be a wholly correct statement. What might be correct is that you have observed no ill effects in the times that you have used it so far. 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: setrog lnklst question
Not funny. Search Google on northern exposure satellite episode Confirmation not required. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Wednesday, May 17, 2017 4:49 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: setrog lnklst question This Guy? https://www.themarysue.com/the-sky-is-falling/ ... the apparent meteorite struck a college campus in Tamil Nadu in southern India. A 40 year old bus driver named Kamaraj died while a student and two gardeners nearby were injured. There was an impact crater 4 feet deep containing “bluish black” rock fragments, according to the statement from the college’s principal, G. Baskar. Laurie Cantillo, a NASA spokeswoman, said that they’re still testing the object to make sure it’s a meteorite and not a random bit of space junk or debris. “Our Planetary Defense Coordination Office is aware of the reports and is looking into it,” she said. “So at this point the report is unconfirmed.” On Wed, May 17, 2017 at 3:42 PM, Jesse 1 Robinson wrote: > You can calculate the odds of getting hit by space debris on 5th Avenue, but > a nonzero probability would not impel you to live in a bunker. Friday > preview: an episode of Northern Exposure centered on the funeral of a fellow > who was actually that unlucky. Impossible to find a conventional coffin that > could hide all the antennae sticking out in all directions. Morbidly > hilarious. > > Omegamon (Candle days) provide a dynamic linklist update facility. Offered > with all the caveats of the current IBM function. Not sure I ever used it, > but I remember ragging on IBM to provide a similar facility many years before > they did. > > I think it's especially rare that a linklist update would really need JOBS(*) > anyway. Dr. Murphy does like to be taunted. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Mark Zelden > Sent: Wednesday, May 17, 2017 12:52 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: setrog lnklst question > > On Wed, 17 May 2017 19:07:35 +, Jesse 1 Robinson > wrote: > >> More important, has anyone actually experienced a problem with JOB(*)? > > I don't think that's more important. What's more important is that the > experts at IBM (the people that write the code and have the manuals updated) > have stated that it is dangerous. I don't care if 1000 people on IBM-MAIN say > they have never had a problem. Murphy doesn't really like me. :-) > > Besides that, I doubt "DELAY" would have been developed / added for no > reason at all because someone felt it would be a good idea just in case to > help resolve a theoretical problem. > > Regards, > > Mark > -- > Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL > v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: > http://www.mzelden.com/mvsutil.html > Systems Programming expert at > http://search390.techtarget.com/ateExperts/ > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: setrog lnklst question
This Guy? https://www.themarysue.com/the-sky-is-falling/ ... the apparent meteorite struck a college campus in Tamil Nadu in southern India. A 40 year old bus driver named Kamaraj died while a student and two gardeners nearby were injured. There was an impact crater 4 feet deep containing “bluish black” rock fragments, according to the statement from the college’s principal, G. Baskar. Laurie Cantillo, a NASA spokeswoman, said that they’re still testing the object to make sure it’s a meteorite and not a random bit of space junk or debris. “Our Planetary Defense Coordination Office is aware of the reports and is looking into it,” she said. “So at this point the report is unconfirmed.” On Wed, May 17, 2017 at 3:42 PM, Jesse 1 Robinson wrote: > You can calculate the odds of getting hit by space debris on 5th Avenue, but > a nonzero probability would not impel you to live in a bunker. Friday > preview: an episode of Northern Exposure centered on the funeral of a fellow > who was actually that unlucky. Impossible to find a conventional coffin that > could hide all the antennae sticking out in all directions. Morbidly > hilarious. > > Omegamon (Candle days) provide a dynamic linklist update facility. Offered > with all the caveats of the current IBM function. Not sure I ever used it, > but I remember ragging on IBM to provide a similar facility many years before > they did. > > I think it's especially rare that a linklist update would really need JOBS(*) > anyway. Dr. Murphy does like to be taunted. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Mark Zelden > Sent: Wednesday, May 17, 2017 12:52 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: setrog lnklst question > > On Wed, 17 May 2017 19:07:35 +, Jesse 1 Robinson > wrote: > >> More important, has anyone actually experienced a problem with JOB(*)? > > I don't think that's more important. What's more important is that the > experts at IBM (the people that write the code and have the manuals updated) > have stated that it is dangerous. I don't care if 1000 people on IBM-MAIN say > they have never had a problem. Murphy doesn't really like me. :-) > > Besides that, I doubt "DELAY" would have been developed / added for no reason > at all because someone felt it would be a good idea just > in case to help resolve a theoretical problem. > > Regards, > > Mark > -- > Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 > Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: > http://www.mzelden.com/mvsutil.html > Systems Programming expert at http://search390.techtarget.com/ateExperts/ > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: setrog lnklst question
You can calculate the odds of getting hit by space debris on 5th Avenue, but a nonzero probability would not impel you to live in a bunker. Friday preview: an episode of Northern Exposure centered on the funeral of a fellow who was actually that unlucky. Impossible to find a conventional coffin that could hide all the antennae sticking out in all directions. Morbidly hilarious. Omegamon (Candle days) provide a dynamic linklist update facility. Offered with all the caveats of the current IBM function. Not sure I ever used it, but I remember ragging on IBM to provide a similar facility many years before they did. I think it's especially rare that a linklist update would really need JOBS(*) anyway. Dr. Murphy does like to be taunted. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Zelden Sent: Wednesday, May 17, 2017 12:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: setrog lnklst question On Wed, 17 May 2017 19:07:35 +, Jesse 1 Robinson wrote: > More important, has anyone actually experienced a problem with JOB(*)? I don't think that's more important. What's more important is that the experts at IBM (the people that write the code and have the manuals updated) have stated that it is dangerous. I don't care if 1000 people on IBM-MAIN say they have never had a problem. Murphy doesn't really like me. :-) Besides that, I doubt "DELAY" would have been developed / added for no reason at all because someone felt it would be a good idea just in case to help resolve a theoretical problem. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: setrog lnklst question
On Wed, 17 May 2017 19:07:35 +, Jesse 1 Robinson wrote: > More important, has anyone actually experienced a problem with JOB(*)? I don't think that's more important. What's more important is that the experts at IBM (the people that write the code and have the manuals updated) have stated that it is dangerous. I don't care if 1000 people on IBM-MAIN say they have never had a problem. Murphy doesn't really like me. :-) Besides that, I doubt "DELAY" would have been developed / added for no reason at all because someone felt it would be a good idea just in case to help resolve a theoretical problem. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: setrog lnklst question
Yes, I have spent way too much time looking at dumps that were caused by this (enough so that I persuaded Peter Relson to make a change in z/OS 2.2 so that a DELAY(1) is done if a delay value larger than 1 was not specified). That has helped a lot. But you could easily have a fetching operation that takes longer than 1 second (or any arbitrary number of seconds) due to things like a reserve on the device, or the job getting logically swapped due to workload considerations. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > > More important, has anyone actually experienced a problem with JOB(*)? > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU > ] On Behalf Of Mark Zelden > Sent: Wednesday, May 17, 2017 10:49 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: setrog lnklst question > > On Tue, 16 May 2017 23:10:10 +, Gibney, Dave wrote: > > >And the LNKLST UPDATE JOB(*) is documented as potentially dangerous. > > > >On the other hand, so far, I haven't have need to modify my linklst and > >effect all running address spaces. It's usually limited to a smaller subset. > > Yet I continue to see people using it as a matter of habit instead > of an "emergency" > basis. The only place I have used it regularly is in a sysprog > sandbox LPAR and since "delay" was added as an option, I use that > along with it. > > LNKLST UPDATE JOB(*) DELAY(5) > > > Mark > -- > Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL > v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: > http://www.mzelden.com/mvsutil.html > Systems Programming expert at http://search390.techtarget.com/ateExperts/ > > > -- > 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: setrog lnklst question
More important, has anyone actually experienced a problem with JOB(*)? . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Zelden Sent: Wednesday, May 17, 2017 10:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: setrog lnklst question On Tue, 16 May 2017 23:10:10 +, Gibney, Dave wrote: >And the LNKLST UPDATE JOB(*) is documented as potentially dangerous. > >On the other hand, so far, I haven't have need to modify my linklst and >effect all running address spaces. It's usually limited to a smaller subset. Yet I continue to see people using it as a matter of habit instead of an "emergency" basis. The only place I have used it regularly is in a sysprog sandbox LPAR and since "delay" was added as an option, I use that along with it. LNKLST UPDATE JOB(*) DELAY(5) Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: setrog lnklst question
On Tue, 16 May 2017 23:10:10 +, Gibney, Dave wrote: >And the LNKLST UPDATE JOB(*) is documented as potentially dangerous. > >On the other hand, so far, I haven't have need to modify my linklst and effect >all >running address spaces. It's usually limited to a smaller subset. Yet I continue to see people using it as a matter of habit instead of an "emergency" basis. The only place I have used it regularly is in a sysprog sandbox LPAR and since "delay" was added as an option, I use that along with it. LNKLST UPDATE JOB(*) DELAY(5) Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: setrog lnklst question
Thank you all for your help on my linklst question. I went the 'safe' route and built a new lnklst and added the datasets I need for DB2 v12. Thanks again, Bill J. On Wednesday, May 17, 2017 11:08 AM, Lizette Koehler wrote: Peter, Thanks. That was much clearer than the manual. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Peter Relson > Sent: Wednesday, May 17, 2017 4:57 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: setrog lnklst question > > > and the LNKLST UPDATE JOB(*) is documented as potentially dangerous. > > > If you're lucky, nothing bad will happen. If you're really unlucky, you will > trash your system. And all sorts of variants in between. > The operation is unpredictably dangerous. The effects depend on what happens > to be going on at the time. > > If you use it, you will get no sympathy (or support) if something bad > happens. The only safe thing to do is not to use that option. > New jobs and new address spaces will use the newly activated LNKLST without > this option. > > You might check out the DELAY sub-option of LNKLST UPDATE. There is no way of > knowing how long might be necessary to delay before the system is to clean > up. And the command will not complete until the delay ends. > > Why is it provided at all? Because sometimes you're willing to take a risk if > your only choice is re-IPL. > > 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: setrog lnklst question
Peter, Thanks. That was much clearer than the manual. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Peter Relson > Sent: Wednesday, May 17, 2017 4:57 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: setrog lnklst question > > > and the LNKLST UPDATE JOB(*) is documented as potentially dangerous. > > > If you're lucky, nothing bad will happen. If you're really unlucky, you will > trash your system. And all sorts of variants in between. > The operation is unpredictably dangerous. The effects depend on what happens > to be going on at the time. > > If you use it, you will get no sympathy (or support) if something bad > happens. The only safe thing to do is not to use that option. > New jobs and new address spaces will use the newly activated LNKLST without > this option. > > You might check out the DELAY sub-option of LNKLST UPDATE. There is no way of > knowing how long might be necessary to delay before the system is to clean > up. And the command will not complete until the delay ends. > > Why is it provided at all? Because sometimes you're willing to take a risk if > your only choice is re-IPL. > > 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: setrog lnklst question
One of my favorite campfire routines. She: Pa, ya gotcher foot in the fahr. Pause She: Pa, ya gotcher foot in the fahr. Pause She: (Emphatically) Pa, ya gotcher foot in the fahr! He: Yeah Ma? Which one? . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Tuesday, May 16, 2017 9:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: setrog lnklst question UPDATE JOB(*) is dangerous. And was discussed in the IBM MAIN Archives, a couple of years ago I think. However, we use it with no ill effect. UPDATE Indicates that the system is to update an address space so that a specified job or jobs associated with that space can use the current LNKLST set. If the job is using another LNKLST set when the current LNKLST set is activated, it will continue to use the original LNKLST set until it completes operations. When the job completes and restarts, it then uses the data sets defined in the new currently active LNKLST set. See "Removing or Compressing a Data Set in an Active LNKLST Set" in z/OS MVS Initialization and Tuning Reference for information about LLA management of the LNKLST data set. 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. Start of changeJOBNAME | JOB=jobnameEnd of change Specifies the name of the job or jobs to update. You can use wildcard characters (? or *) for jobname. UPDATE updates any job whose name matches the specified criteria. The system compares jobname to the name of any initiated job or jobs that match, or to the name of the address space. Dangle your foot in the fire. If it does not burn you are okay, If it does, take it out Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Gibney, Dave > Sent: Tuesday, May 16, 2017 4:10 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: setrog lnklst question > > And the LNKLST UPDATE JOB(*) is documented as potentially dangerous. > > On the other hand, so far, I haven't have need to modify my linklst > and effect all running address spaces. It's usually limited to a smaller > subset. > > > -Original Message- > > From: IBM Mainframe Discussion List > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler > > Sent: Tuesday, May 16, 2017 3:25 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: setrog lnklst question > > > > So an EXAMPLE would be > > > >/**/ > >/* Adding a dataset to the LINKLIST when it */ > >/* does not already exist */ > >/**/ > >LNKLST DEFINE NAME(NEWLNKA) COPYFROM(CURRENT) > >LNKLST ADDNAME(NEWLNKA) DSNAME(SYS1.NEWDSN.INLNK.LIST), > >AFTER(SYS1.LOCTION.INLNK.LIST) > >LNKLST DELETE NAME(NEWLNKA) DSNAME(SYS1.DELETE.THIS.LNKLST.DSN) > >LNKLST ACTIVATE NAME(NEWLNKA) > >LNKLST UPDATE JOB(*) > >APF ADD DSNAME(SYS1.NEWDSN.INLNK.LIST) VOLUME(&SYSR3) > > > > > > APF ADD is not needed if the file being added is already APF Authorized. > > DELETE is not needed if you are not removing anything from the Linklst. > > > > > > Lizette > > > > -Original Message- > > >From: Lizette Koehler > > >Sent: May 16, 2017 3:19 PM > > >To: IBM-MAIN@LISTSERV.UA.EDU > > >Subject: Re: setrog lnklst question > > > > > >You can create a parmlib member to > > > > > >COPY the current linklst to a new name Activate the new linklist > > >name > > > > > >If you need further assistance let us know. > > > > > >Lizette > > > > > >-Original Message- > > >>From: william janulin <008d52e04f2e-dmarc- > > requ...@listserv.ua.edu> > > >>Sent: May 16, 2017 1:52 PM > > >>To: IBM-MAIN@LISTSERV.UA.EDU > > >>Subject: setrog lnklst question > > >> > > >>To list; > > >> Is it possible to add a dataset to the active lnklst? I tried a > > >>setprog lnklst > > add command and got a messagethat the lnklst was active. > > >> > > >>Thank you in advance, Bill J. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: setrog lnklst question
and the LNKLST UPDATE JOB(*) is documented as potentially dangerous. If you're lucky, nothing bad will happen. If you're really unlucky, you will trash your system. And all sorts of variants in between. The operation is unpredictably dangerous. The effects depend on what happens to be going on at the time. If you use it, you will get no sympathy (or support) if something bad happens. The only safe thing to do is not to use that option. New jobs and new address spaces will use the newly activated LNKLST without this option. You might check out the DELAY sub-option of LNKLST UPDATE. There is no way of knowing how long might be necessary to delay before the system is to clean up. And the command will not complete until the delay ends. Why is it provided at all? Because sometimes you're willing to take a risk if your only choice is re-IPL. 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: setrog lnklst question
UPDATE JOB(*) is dangerous. And was discussed in the IBM MAIN Archives, a couple of years ago I think. However, we use it with no ill effect. UPDATE Indicates that the system is to update an address space so that a specified job or jobs associated with that space can use the current LNKLST set. If the job is using another LNKLST set when the current LNKLST set is activated, it will continue to use the original LNKLST set until it completes operations. When the job completes and restarts, it then uses the data sets defined in the new currently active LNKLST set. See "Removing or Compressing a Data Set in an Active LNKLST Set" in z/OS MVS Initialization and Tuning Reference for information about LLA management of the LNKLST data set. 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. Start of changeJOBNAME | JOB=jobnameEnd of change Specifies the name of the job or jobs to update. You can use wildcard characters (? or *) for jobname. UPDATE updates any job whose name matches the specified criteria. The system compares jobname to the name of any initiated job or jobs that match, or to the name of the address space. Dangle your foot in the fire. If it does not burn you are okay, If it does, take it out Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Gibney, Dave > Sent: Tuesday, May 16, 2017 4:10 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: setrog lnklst question > > And the LNKLST UPDATE JOB(*) is documented as potentially dangerous. > > On the other hand, so far, I haven't have need to modify my linklst and > effect all running address spaces. It's usually limited to a smaller subset. > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Lizette Koehler > > Sent: Tuesday, May 16, 2017 3:25 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: setrog lnklst question > > > > So an EXAMPLE would be > > > >/**/ > >/* Adding a dataset to the LINKLIST when it */ > >/* does not already exist */ > >/**/ > >LNKLST DEFINE NAME(NEWLNKA) COPYFROM(CURRENT) > >LNKLST ADDNAME(NEWLNKA) DSNAME(SYS1.NEWDSN.INLNK.LIST), > >AFTER(SYS1.LOCTION.INLNK.LIST) > >LNKLST DELETE NAME(NEWLNKA) DSNAME(SYS1.DELETE.THIS.LNKLST.DSN) > >LNKLST ACTIVATE NAME(NEWLNKA) > >LNKLST UPDATE JOB(*) > >APF ADD DSNAME(SYS1.NEWDSN.INLNK.LIST) VOLUME(&SYSR3) > > > > > > APF ADD is not needed if the file being added is already APF Authorized. > > DELETE is not needed if you are not removing anything from the Linklst. > > > > > > Lizette > > > > -Original Message- > > >From: Lizette Koehler > > >Sent: May 16, 2017 3:19 PM > > >To: IBM-MAIN@LISTSERV.UA.EDU > > >Subject: Re: setrog lnklst question > > > > > >You can create a parmlib member to > > > > > >COPY the current linklst to a new name Activate the new linklist name > > > > > >If you need further assistance let us know. > > > > > >Lizette > > > > > >-Original Message- > > >>From: william janulin <008d52e04f2e-dmarc- > > requ...@listserv.ua.edu> > > >>Sent: May 16, 2017 1:52 PM > > >>To: IBM-MAIN@LISTSERV.UA.EDU > > >>Subject: setrog lnklst question > > >> > > >>To list; > > >> Is it possible to add a dataset to the active lnklst? I tried a > > >>setprog lnklst > > add command and got a messagethat the lnklst was active. > > >> > > >>Thank you in advance, Bill J. > > >> > > > > > > > -- > > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: setrog lnklst question
And the LNKLST UPDATE JOB(*) is documented as potentially dangerous. On the other hand, so far, I haven't have need to modify my linklst and effect all running address spaces. It's usually limited to a smaller subset. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Lizette Koehler > Sent: Tuesday, May 16, 2017 3:25 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: setrog lnklst question > > So an EXAMPLE would be > >/**/ >/* Adding a dataset to the LINKLIST when it */ >/* does not already exist */ >/**/ >LNKLST DEFINE NAME(NEWLNKA) COPYFROM(CURRENT) >LNKLST ADDNAME(NEWLNKA) DSNAME(SYS1.NEWDSN.INLNK.LIST), >AFTER(SYS1.LOCTION.INLNK.LIST) >LNKLST DELETE NAME(NEWLNKA) DSNAME(SYS1.DELETE.THIS.LNKLST.DSN) >LNKLST ACTIVATE NAME(NEWLNKA) >LNKLST UPDATE JOB(*) >APF ADD DSNAME(SYS1.NEWDSN.INLNK.LIST) VOLUME(&SYSR3) > > > APF ADD is not needed if the file being added is already APF Authorized. > DELETE is not needed if you are not removing anything from the Linklst. > > > Lizette > > -Original Message- > >From: Lizette Koehler > >Sent: May 16, 2017 3:19 PM > >To: IBM-MAIN@LISTSERV.UA.EDU > >Subject: Re: setrog lnklst question > > > >You can create a parmlib member to > > > >COPY the current linklst to a new name > >Activate the new linklist name > > > >If you need further assistance let us know. > > > >Lizette > > > >-Original Message- > >>From: william janulin <008d52e04f2e-dmarc- > requ...@listserv.ua.edu> > >>Sent: May 16, 2017 1:52 PM > >>To: IBM-MAIN@LISTSERV.UA.EDU > >>Subject: setrog lnklst question > >> > >>To list; > >> Is it possible to add a dataset to the active lnklst? I tried a setprog > >>lnklst > add command and got a messagethat the lnklst was active. > >> > >>Thank you in advance, Bill J. > >> > > > > -- > 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: setrog lnklst question
So an EXAMPLE would be /**/ /* Adding a dataset to the LINKLIST when it */ /* does not already exist */ /**/ LNKLST DEFINE NAME(NEWLNKA) COPYFROM(CURRENT) LNKLST ADDNAME(NEWLNKA) DSNAME(SYS1.NEWDSN.INLNK.LIST), AFTER(SYS1.LOCTION.INLNK.LIST) LNKLST DELETE NAME(NEWLNKA) DSNAME(SYS1.DELETE.THIS.LNKLST.DSN) LNKLST ACTIVATE NAME(NEWLNKA) LNKLST UPDATE JOB(*) APF ADD DSNAME(SYS1.NEWDSN.INLNK.LIST) VOLUME(&SYSR3) APF ADD is not needed if the file being added is already APF Authorized. DELETE is not needed if you are not removing anything from the Linklst. Lizette -Original Message- >From: Lizette Koehler >Sent: May 16, 2017 3:19 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: setrog lnklst question > >You can create a parmlib member to > >COPY the current linklst to a new name >Activate the new linklist name > >If you need further assistance let us know. > >Lizette > >-Original Message- >>From: william janulin <008d52e04f2e-dmarc-requ...@listserv.ua.edu> >>Sent: May 16, 2017 1:52 PM >>To: IBM-MAIN@LISTSERV.UA.EDU >>Subject: setrog lnklst question >> >>To list; >> Is it possible to add a dataset to the active lnklst? I tried a setprog >>lnklst add command and got a messagethat the lnklst was active. >> >>Thank you in advance, Bill J. >> > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: setrog lnklst question
You can create a parmlib member to COPY the current linklst to a new name Activate the new linklist name If you need further assistance let us know. Lizette -Original Message- >From: william janulin <008d52e04f2e-dmarc-requ...@listserv.ua.edu> >Sent: May 16, 2017 1:52 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: setrog lnklst question > >To list; > Is it possible to add a dataset to the active lnklst? I tried a setprog >lnklst add command and got a messagethat the lnklst was active. > >Thank you in advance, Bill J. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: setrog lnklst question
You have to use SETPROG to make a copy of the active list, add your new library and activate the new list. Read all the special caveats > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of william janulin > Sent: Tuesday, May 16, 2017 1:52 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: setrog lnklst question > > To list; > Is it possible to add a dataset to the active lnklst? I tried a setprog > lnklst add > command and got a messagethat the lnklst was active. > > Thank you in advance, Bill J. > > -- > 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
setrog lnklst question
To list; Is it possible to add a dataset to the active lnklst? I tried a setprog lnklst add command and got a messagethat the lnklst was active. Thank you in advance, Bill J. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN