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
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
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. 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
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. 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
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
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
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
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
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
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
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
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
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
>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
