Re: Linklist and Syncsort confusion
Thank you, everybody, for correcting my understanding of what the LNKLST UNALLOCATE/ALLOCATE does and doesn't do. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Relson Sent: Tuesday, August 23, 2022 6:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Linklist and Syncsort confusion Once more into the breach. All of this has been covered multiple times, but searching archives is no one's favorite thing to do and often it's too hard to find what you want. Use of LNKLST ALLOCATE/UNALLOCATE is solely provided so that you can access uncataloged datasets of the same name as a LNKLST dataset. It has no effect on an active LNKLST. Stopping VLF is not of any help. The right approach, as was mentioned, is to define a new LNKLST set (and activate it). For things to work, there needs to be a DCB with a new DEB that tracks to the new dataset. Only LNKLST ACTIVATE will do that. For example, LNKLST DEFINE NAME(xx) COPYFROM(CURRENT) LNKLST ACTIVATE NAME(xx) This approach works too if you have a LNKLST dataset that was allocated in such a way that it could extend into secondary extents and then, because of your actions, did. If you want to get rid of the old dataset, you need to get everyone from using the current (and any old) LNKLST sets. This is unpredictably dangerous and can result in absolutely anything, from "no problem" to "wait state". But if you must (such as if the alternative is "IPL anyway"), then SETPROG LNKLST UPDATE JOB(*). The safe approach is to leave the old dataset and use the new name. LNKLST DEFINE NAME(xx) COPYFROM(CURRENT) LNKLST DELETE NAME(xx) DSN(yyy) LNKLST ADD NAME(xx) DSN(yyy) LNKLST ACTIVATE NAME(xx) And then decide if you have existing jobs that actually need the new dataset. If you don't, then no LNKLST UPDATE is needed, and no problems will occur. LLA does not need to be stopped or refreshed. 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 -- The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linklist and Syncsort confusion
On Tue, 23 Aug 2022 12:12:47 +, Allan Staller wrote: >Classification: Confidential >... >::DISCLAIMER:: > >The contents of this e-mail and any attachment(s) are confidential and >intended for the named recipient(s) only. E-mail transmission is not >guaranteed to be secure or error-free as information could be intercepted, >corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses >in transmission. The e mail and its contents (with or without referred errors) >shall therefore not attach any liability on the originator or HCL or its >affiliates. Views or opinions, if any, presented in this email are solely >those of the author and may not necessarily reflect the views or opinions of >HCL or its affiliates. Any form of reproduction, dissemination, copying, >disclosure, modification, distribution and / or publication of this message >without the prior written consent of authorized representative of HCL is >strictly prohibited. If you have received this email in error please delete it >and notify the sender immediately. Before opening any email and/or >attachments, please check them for viruses and other defects. > > What is the process for obtaining "prior written consent" if I choose to share this article with a colleague? Please provide contact information for the "authorized representative of HCL". -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: Linklist and Syncsort confusion
that's what I suggested at first, I think the original linklist is still active, shutting down LLA and VLF, only used to fetch members faster. I think you need to create a new LINKLST https://www.ibm.com/docs/en/zos/2.4.0?topic=command-updating-lnklst-concatenations and make it active I really should have documented the steps in my response, and made it more clear why he was getting FETCH failures Carmen On 8/23/2022 7:14 AM, Allan Staller wrote: Classification: Confidential The new lnklst must be explicitly defined and activated. It doesn't automagically happen. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex Sent: Monday, August 22, 2022 2:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: Linklist and Syncsort confusion [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] Hi Carmen, Yes the issue got resolved with the IPL. I am just trying to figure out what went wrong, why the system gave me the 106 abends after doing the dynamic changes. I'm thinking I should have built a new linklist and activated that one instead of just unallocating and allocating the current one. I wasn't having any luck using ISRFIND so I used ISRDDN and did a search thru the linklist and I did, indeed, find IEBGENER in the SYNCLINK loadlib as an alias to SYNCGENR.SYS1.LINKLIB has no IEBGENER, it has IEBGENR as an alias to IEBGENE9 which was renamed from IEBGENER by a usermod as part of the Syncsort install. It may be that the Syncsort standard is to rename IEBGENER to OLDGENER in LINKLIB, but our company standard is that when we rename something to "old" status, we change the last character of the name to '9'. Thanks again for your help. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Carmen Vitullo Sent: Monday, August 22, 2022 2:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: Linklist and Syncsort confusion ok, maybe I just missed it, do you resolve your issue? my ISRFIND shows IEBGENER in my linklist in the SYNCSORT LINKLIB, did the vendor change the usermod to assign an alias rather than use the IEBGERNER module name? in my SYS1.LINKLIB IEBGENER is an alias of OLDGENER maybe the usermod changed since I last supported SYNCSORT. Carmen On 8/22/2022 2:19 PM, Pommier, Rex wrote: Answers embedded. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Carmen Vitullo Sent: Monday, August 22, 2022 1:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Linklist and Syncsort confusion you're sure the library is on the same volume? Yes did the new library contain secondary extents? No, but the old one was in danger of going into secondary so we wanted to make it bigger. did you follow the syncsort process or usermod process to make syncgener available as IEBGENER? Yes it renames IEBGENER as OLDGENER, I don't have the MOD in front of me currently but I think. In our case, we manually renamed the default IEBGENER to IEBGENE9 (don't ask why...) I agree with Dave, an LLA refresh or update should have been enough to refresh LLA but sometime running address spaces will still pick up the old linklist. Bouncing LLA should have done the same as a refresh - and I had to shut it down in order to remove the allocation so I could rename the libraries. I did double-check and did the ALLOCATE of LNKLST before starting LLA. ISRFIND will help you see the linklist concatenation and tell you where IEBGENER is found. ISRDDN LNKLST is showing IEBGENER as an alias of SYNCGENR in the SYNCLINK library. 20-20 hindsight, I should have shut LLA and VLF back down to see if I still got the 106 abends, to see if it was a mismatch between the linklist and LLA. Rex Carmen On 8/22/2022 1:37 PM, Gibney, Dave wrote: You might have got away with a F LLA,REFRESH. I think you are correct, all UNALLOCATE/AlLOCATE does is ENQ related. No re-reading the libraries involved. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex Sent: Monday, August 22, 2022 11:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Linklist and Syncsort confusion [EXTERNAL EMAIL] Hi list, I don't know if this is specifically a Syncsort issue or a more generic confusion about linklist datasets. Here goes. We have the SYNCLINK library defined in the linklist. We have installed Precisely's IEBGENER replacement as part of our install. We determined SYNCLINK was too small. I allocated a larger version of the library on the same volume as the current one. We had an IPL scheduled for Saturday so right before the IPL, I logged in and did the library swap. My process was (as I thought) pretty standard. Shut down LLA and VLF SETPRO
Re: [EXTERNAL] Re: Linklist and Syncsort confusion
Classification: Confidential The new lnklst must be explicitly defined and activated. It doesn't automagically happen. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex Sent: Monday, August 22, 2022 2:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: Linklist and Syncsort confusion [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] Hi Carmen, Yes the issue got resolved with the IPL. I am just trying to figure out what went wrong, why the system gave me the 106 abends after doing the dynamic changes. I'm thinking I should have built a new linklist and activated that one instead of just unallocating and allocating the current one. I wasn't having any luck using ISRFIND so I used ISRDDN and did a search thru the linklist and I did, indeed, find IEBGENER in the SYNCLINK loadlib as an alias to SYNCGENR.SYS1.LINKLIB has no IEBGENER, it has IEBGENR as an alias to IEBGENE9 which was renamed from IEBGENER by a usermod as part of the Syncsort install. It may be that the Syncsort standard is to rename IEBGENER to OLDGENER in LINKLIB, but our company standard is that when we rename something to "old" status, we change the last character of the name to '9'. Thanks again for your help. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Carmen Vitullo Sent: Monday, August 22, 2022 2:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: Linklist and Syncsort confusion ok, maybe I just missed it, do you resolve your issue? my ISRFIND shows IEBGENER in my linklist in the SYNCSORT LINKLIB, did the vendor change the usermod to assign an alias rather than use the IEBGERNER module name? in my SYS1.LINKLIB IEBGENER is an alias of OLDGENER maybe the usermod changed since I last supported SYNCSORT. Carmen On 8/22/2022 2:19 PM, Pommier, Rex wrote: > Answers embedded. > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Carmen Vitullo > Sent: Monday, August 22, 2022 1:48 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXTERNAL] Re: Linklist and Syncsort confusion > > you're sure the library is on the same volume? Yes > > did the new library contain secondary extents? No, but the old one was in > danger of going into secondary so we wanted to make it bigger. > > did you follow the syncsort process or usermod process to make > syncgener available as IEBGENER? Yes > > it renames IEBGENER as OLDGENER, I don't have the MOD in front of me > currently but I think. In our case, we manually renamed the default > IEBGENER to IEBGENE9 (don't ask why...) > > I agree with Dave, an LLA refresh or update should have been enough to > refresh LLA but sometime running address spaces will still pick up the old > linklist. Bouncing LLA should have done the same as a refresh - and I had to > shut it down in order to remove the allocation so I could rename the > libraries. I did double-check and did the ALLOCATE of LNKLST before starting > LLA. > > ISRFIND will help you see the linklist concatenation and tell you where > IEBGENER is found. ISRDDN LNKLST is showing IEBGENER as an alias of SYNCGENR > in the SYNCLINK library. > > 20-20 hindsight, I should have shut LLA and VLF back down to see if I still > got the 106 abends, to see if it was a mismatch between the linklist and LLA. > > Rex > > > Carmen > > On 8/22/2022 1:37 PM, Gibney, Dave wrote: >> You might have got away with a F LLA,REFRESH. I think you are correct, all >> UNALLOCATE/AlLOCATE does is ENQ related. No re-reading the libraries >> involved. >> >> >> >>> -Original Message- >>> From: IBM Mainframe Discussion List On >>> Behalf Of Pommier, Rex >>> Sent: Monday, August 22, 2022 11:32 AM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Linklist and Syncsort confusion >>> >>> [EXTERNAL EMAIL] >>> >>> Hi list, >>> >>> I don't know if this is specifically a Syncsort issue or a more >>> generic confusion about linklist datasets. Here goes. >>> >>> We have the SYNCLINK library defined in the linklist. We have >>> installed Precisely's IEBGENER replacement as part of our install. >>> We determined SYNCLINK was too small. I allocated a larger version >>> of the library on the same volume as the current one. We had an IPL >>> scheduled for Saturday so right before the IPL, I logged in and did >>> the library swap. My process was (as I >>> thought)
Re: Linklist and Syncsort confusion
Classification: Confidential The original lnklst dataset remains in use for the length of the IPL unless modified via the SETPROG process. There is a well documented procedure for doing what the OP is trying to accomplish. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Carmen Vitullo Sent: Monday, August 22, 2022 1:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Linklist and Syncsort confusion [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] you're sure the library is on the same volume? did the new library contain secondary extents? did you follow the syncsort process or usermod process to make syncgener available as IEBGENER? it renames IEBGENER as OLDGENER, I don't have the MOD in front of me currently but I think I agree with Dave, an LLA refresh or update should have been enough to refresh LLA but sometime running address spaces will still pick up the old linklist. ISRFIND will help you see the linklist concatenation and tell you where IEBGENER is found Carmen On 8/22/2022 1:37 PM, Gibney, Dave wrote: > You might have got away with a F LLA,REFRESH. I think you are correct, all > UNALLOCATE/AlLOCATE does is ENQ related. No re-reading the libraries involved. > > > >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of Pommier, Rex >> Sent: Monday, August 22, 2022 11:32 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Linklist and Syncsort confusion >> >> [EXTERNAL EMAIL] >> >> Hi list, >> >> I don't know if this is specifically a Syncsort issue or a more >> generic confusion about linklist datasets. Here goes. >> >> We have the SYNCLINK library defined in the linklist. We have >> installed Precisely's IEBGENER replacement as part of our install. >> We determined SYNCLINK was too small. I allocated a larger version >> of the library on the same volume as the current one. We had an IPL >> scheduled for Saturday so right before the IPL, I logged in and did >> the library swap. My process was (as I >> thought) pretty standard. >> >> Shut down LLA and VLF >> SETPROG LNKLST,UNALLOCATE >> Rename the 2 libraries to get the new, larger one with the right name >> SETPROG LNKLST,ALLOCATE Start LLA and VLF. >> >> The operator then needed to run a couple pre-IPL jobs that use IEBGENER. >> They failed with >> IEW4009I FETCH FAILED FOR MODULE IEBGENER FROM DDNAME -LNKLST- >> BECAUSE OF AN I/O ERROR. >> IEW4005I FETCH FOR MODULE IEBGENER FROM DDNAME -LNKLST- FAILED >> BECAUSE IEWFETCH ISSUED RC 0F AND REASON 40 CSV031I LIBRARY ACCESS >> FAILED FOR MODULE IEBGENER, RETURN CODE 24, REASON CODE 26080021, >> DDNAME *LNKLST* >> >> The manuals were less than helpful. IPLing took care of the problem >> but I'm not clear as to either what I did wrong or if my >> understanding of the UNALLOCATE/ALLOCATE is wrong. I was under the >> impression that doing the UNALLOCATE then ALLOCATE rebuilt the >> linklist. It appears now to me that all the UNALLOCATE does is >> remove the enqueues on the datasets and ALLOCATE simply reestablishes >> the enqueues, still pointing to the original location, but even that >> doesn't compute in my mind because I didn't change any locations of >> either the old or new libraries. Or was it a mismatch between the >> linklist and the LLA, and that possibly the linklist was still >> pointing to the original location of the SYNCLINK library but the LLA >> is now pointing to the new location? Would I have not had the >> problem if, instead of just doing the UNALLOCATE/ALLOCATE, I would >> have built and activated a >> LNKLST01 concatenation? >> >> I see the cautions in the system commands manual against moving or >> deleting a linklist dataset while the allocations are inactive and I >> obviously got burned by disobeying that warning. I'm just trying to >> figure out what the UNALLOCATE is doing and how to not have this >> happen when I have to perform this kind of maintenance. >> >> TIA, >> >> Rex >> >> - >> - The information contained in this message is confidential, >> protected from disclosure and may be legally privileged. If the >> reader of this message is not the intended recipient or an employee >> or agent responsible for delivering this message to the intended >> recipient, you are hereby notified that any disclos
Re: Linklist and Syncsort confusion
Classification: Confidential Looks like you a) forgot the LLA refresh and b) did not add the "new library" to lnklstxx -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex Sent: Monday, August 22, 2022 1:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Linklist and Syncsort confusion [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] Hi list, I don't know if this is specifically a Syncsort issue or a more generic confusion about linklist datasets. Here goes. We have the SYNCLINK library defined in the linklist. We have installed Precisely's IEBGENER replacement as part of our install. We determined SYNCLINK was too small. I allocated a larger version of the library on the same volume as the current one. We had an IPL scheduled for Saturday so right before the IPL, I logged in and did the library swap. My process was (as I thought) pretty standard. Shut down LLA and VLF SETPROG LNKLST,UNALLOCATE Rename the 2 libraries to get the new, larger one with the right name SETPROG LNKLST,ALLOCATE Start LLA and VLF. The operator then needed to run a couple pre-IPL jobs that use IEBGENER. They failed with IEW4009I FETCH FAILED FOR MODULE IEBGENER FROM DDNAME -LNKLST- BECAUSE OF AN I/O ERROR. IEW4005I FETCH FOR MODULE IEBGENER FROM DDNAME -LNKLST- FAILED BECAUSE IEWFETCH ISSUED RC 0F AND REASON 40 CSV031I LIBRARY ACCESS FAILED FOR MODULE IEBGENER, RETURN CODE 24, REASON CODE 26080021, DDNAME *LNKLST* The manuals were less than helpful. IPLing took care of the problem but I'm not clear as to either what I did wrong or if my understanding of the UNALLOCATE/ALLOCATE is wrong. I was under the impression that doing the UNALLOCATE then ALLOCATE rebuilt the linklist. It appears now to me that all the UNALLOCATE does is remove the enqueues on the datasets and ALLOCATE simply reestablishes the enqueues, still pointing to the original location, but even that doesn't compute in my mind because I didn't change any locations of either the old or new libraries. Or was it a mismatch between the linklist and the LLA, and that possibly the linklist was still pointing to the original location of the SYNCLINK library but the LLA is now pointing to the new location? Would I have not had the problem if, instead of just doing the UNALLOCATE/ALLOCATE, I would have built and activated a LNKLST01 concatenation? I see the cautions in the system commands manual against moving or deleting a linklist dataset while the allocations are inactive and I obviously got burned by disobeying that warning. I'm just trying to figure out what the UNALLOCATE is doing and how to not have this happen when I have to perform this kind of maintenance. TIA, Rex -- The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ---
Re: Linklist and Syncsort confusion
Once more into the breach. All of this has been covered multiple times, but searching archives is no one's favorite thing to do and often it's too hard to find what you want. Use of LNKLST ALLOCATE/UNALLOCATE is solely provided so that you can access uncataloged datasets of the same name as a LNKLST dataset. It has no effect on an active LNKLST. Stopping VLF is not of any help. The right approach, as was mentioned, is to define a new LNKLST set (and activate it). For things to work, there needs to be a DCB with a new DEB that tracks to the new dataset. Only LNKLST ACTIVATE will do that. For example, LNKLST DEFINE NAME(xx) COPYFROM(CURRENT) LNKLST ACTIVATE NAME(xx) This approach works too if you have a LNKLST dataset that was allocated in such a way that it could extend into secondary extents and then, because of your actions, did. If you want to get rid of the old dataset, you need to get everyone from using the current (and any old) LNKLST sets. This is unpredictably dangerous and can result in absolutely anything, from "no problem" to "wait state". But if you must (such as if the alternative is "IPL anyway"), then SETPROG LNKLST UPDATE JOB(*). The safe approach is to leave the old dataset and use the new name. LNKLST DEFINE NAME(xx) COPYFROM(CURRENT) LNKLST DELETE NAME(xx) DSN(yyy) LNKLST ADD NAME(xx) DSN(yyy) LNKLST ACTIVATE NAME(xx) And then decide if you have existing jobs that actually need the new dataset. If you don't, then no LNKLST UPDATE is needed, and no problems will occur. LLA does not need to be stopped or refreshed. 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: Linklist and Syncsort confusion
On Mon, 22 Aug 2022 18:32:21 +, Pommier, Rex wrote: >Hi list, > >I don't know if this is specifically a Syncsort issue or a more generic >confusion about linklist datasets. Here goes. > >We have the SYNCLINK library defined in the linklist. We have installed >Precisely's IEBGENER replacement as part of our install. We determined >SYNCLINK was too small. I allocated a larger version of the library on the >same volume as the current one. We had an IPL scheduled for Saturday so right >before the IPL, I logged in and did the library swap. My process was (as I >thought) pretty standard. > >Shut down LLA and VLF >SETPROG LNKLST,UNALLOCATE >Rename the 2 libraries to get the new, larger one with the right name >SETPROG LNKLST,ALLOCATE >Start LLA and VLF. Nope, not standard. Perhaps before dynamic LNKLST - *and* if you had planned on really doing the rename just before an IPL and not trying to run any jobs. I still see people do it this way though (minus bothering to do the "reallocate" and re-starting LLA). >The operator then needed to run a couple pre-IPL jobs that use IEBGENER. They >failed with >IEW4009I FETCH FAILED FOR MODULE IEBGENER FROM DDNAME -LNKLST- BECAUSE OF AN >I/O ERROR. >IEW4005I FETCH FOR MODULE IEBGENER FROM DDNAME -LNKLST- FAILED BECAUSE >IEWFETCH ISSUED RC 0F AND REASON 40 >CSV031I LIBRARY ACCESS FAILED FOR MODULE IEBGENER, RETURN CODE 24, REASON CODE >26080021, DDNAME *LNKLST* Because the original extents are still known to the LNKLST. > >The manuals were less than helpful. This has been covered countless times on this list, in SHARE presentations and while I didn't just search a manual to see what it says these days, a quick google search did turn up this hit that explains how to do this safely and what NOT to do (what you did) and why it caused a problem. https://www.ibm.com/support/pages/using-dynamic-lnklst-facility-safely-and-properly Don't feel bad, I work with a lot of Jr. sysprogs and it seems everyone gets this wrong and doesn't understand how it is supposed to work until they break break something. Thankfully it's in a sandbox LPAR 99% of the time because they know better than to be mucking with a production system. Best 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: Linklist and Syncsort confusion
me too + I have to switch between a work PC and a personal PC at home. no complains, I'm home till I retire in Jan :) I hate Monday :( when supporting some CA products long ago, I'd often get S016 abends, it was self inflicted since I'd do everything possible to avoid an IPL midnight or 2AM sometime, so I'd do pretty much what you did, It was suggested to me, my only mistake was not created a new PROG member making LNKST00 a new LNKLST01 and using a T PROG=CV (my member name of choice PROGCV) and activating the new linklist. so easy to IPL these days so I don't see this issue any longer. Carmen On 8/22/2022 2:57 PM, Pommier, Rex wrote: It's Monday, my fingers aren't doing what my brain is telling them either! LOL Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Carmen Vitullo Sent: Monday, August 22, 2022 2:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: Linklist and Syncsort confusion correction: in my SYS1.LINKLIB, IEBGENR is an alias of OLDGENER, since if SYNCGENER cannot perform as IEBGENER it will call OLDGERNER IIRC Carmen On 8/22/2022 2:19 PM, Pommier, Rex wrote: Answers embedded. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Carmen Vitullo Sent: Monday, August 22, 2022 1:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Linklist and Syncsort confusion you're sure the library is on the same volume? Yes did the new library contain secondary extents? No, but the old one was in danger of going into secondary so we wanted to make it bigger. did you follow the syncsort process or usermod process to make syncgener available as IEBGENER? Yes it renames IEBGENER as OLDGENER, I don't have the MOD in front of me currently but I think. In our case, we manually renamed the default IEBGENER to IEBGENE9 (don't ask why...) I agree with Dave, an LLA refresh or update should have been enough to refresh LLA but sometime running address spaces will still pick up the old linklist. Bouncing LLA should have done the same as a refresh - and I had to shut it down in order to remove the allocation so I could rename the libraries. I did double-check and did the ALLOCATE of LNKLST before starting LLA. ISRFIND will help you see the linklist concatenation and tell you where IEBGENER is found. ISRDDN LNKLST is showing IEBGENER as an alias of SYNCGENR in the SYNCLINK library. 20-20 hindsight, I should have shut LLA and VLF back down to see if I still got the 106 abends, to see if it was a mismatch between the linklist and LLA. Rex Carmen On 8/22/2022 1:37 PM, Gibney, Dave wrote: You might have got away with a F LLA,REFRESH. I think you are correct, all UNALLOCATE/AlLOCATE does is ENQ related. No re-reading the libraries involved. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex Sent: Monday, August 22, 2022 11:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Linklist and Syncsort confusion [EXTERNAL EMAIL] Hi list, I don't know if this is specifically a Syncsort issue or a more generic confusion about linklist datasets. Here goes. We have the SYNCLINK library defined in the linklist. We have installed Precisely's IEBGENER replacement as part of our install. We determined SYNCLINK was too small. I allocated a larger version of the library on the same volume as the current one. We had an IPL scheduled for Saturday so right before the IPL, I logged in and did the library swap. My process was (as I thought) pretty standard. Shut down LLA and VLF SETPROG LNKLST,UNALLOCATE Rename the 2 libraries to get the new, larger one with the right name SETPROG LNKLST,ALLOCATE Start LLA and VLF. The operator then needed to run a couple pre-IPL jobs that use IEBGENER. They failed with IEW4009I FETCH FAILED FOR MODULE IEBGENER FROM DDNAME -LNKLST- BECAUSE OF AN I/O ERROR. IEW4005I FETCH FOR MODULE IEBGENER FROM DDNAME -LNKLST- FAILED BECAUSE IEWFETCH ISSUED RC 0F AND REASON 40 CSV031I LIBRARY ACCESS FAILED FOR MODULE IEBGENER, RETURN CODE 24, REASON CODE 26080021, DDNAME *LNKLST* The manuals were less than helpful. IPLing took care of the problem but I'm not clear as to either what I did wrong or if my understanding of the UNALLOCATE/ALLOCATE is wrong. I was under the impression that doing the UNALLOCATE then ALLOCATE rebuilt the linklist. It appears now to me that all the UNALLOCATE does is remove the enqueues on the datasets and ALLOCATE simply reestablishes the enqueues, still pointing to the original location, but even that doesn't compute in my mind because I didn't change any locations of either the old or new libraries. Or was it a mismatch between the linklist and the LLA, and that possibly the linklist was still pointing to the original location of the SYNCLINK library but the LLA is now pointing to the new location? Would I have not had the problem if, instea
Re: [EXTERNAL] Re: Linklist and Syncsort confusion
It's Monday, my fingers aren't doing what my brain is telling them either! LOL Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Carmen Vitullo Sent: Monday, August 22, 2022 2:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: Linklist and Syncsort confusion correction: in my SYS1.LINKLIB, IEBGENR is an alias of OLDGENER, since if SYNCGENER cannot perform as IEBGENER it will call OLDGERNER IIRC Carmen On 8/22/2022 2:19 PM, Pommier, Rex wrote: > Answers embedded. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Carmen Vitullo > Sent: Monday, August 22, 2022 1:48 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXTERNAL] Re: Linklist and Syncsort confusion > > you're sure the library is on the same volume? Yes > > did the new library contain secondary extents? No, but the old one was in > danger of going into secondary so we wanted to make it bigger. > > did you follow the syncsort process or usermod process to make syncgener > available as IEBGENER? Yes > > it renames IEBGENER as OLDGENER, I don't have the MOD in front of me > currently but I think. In our case, we manually renamed the default IEBGENER > to IEBGENE9 (don't ask why...) > > I agree with Dave, an LLA refresh or update should have been enough to > refresh LLA but sometime running address spaces will still pick up the old > linklist. Bouncing LLA should have done the same as a refresh - and I had to > shut it down in order to remove the allocation so I could rename the > libraries. I did double-check and did the ALLOCATE of LNKLST before starting > LLA. > > ISRFIND will help you see the linklist concatenation and tell you where > IEBGENER is found. ISRDDN LNKLST is showing IEBGENER as an alias of SYNCGENR > in the SYNCLINK library. > > 20-20 hindsight, I should have shut LLA and VLF back down to see if I still > got the 106 abends, to see if it was a mismatch between the linklist and LLA. > > Rex > > > Carmen > > On 8/22/2022 1:37 PM, Gibney, Dave wrote: >> You might have got away with a F LLA,REFRESH. I think you are correct, all >> UNALLOCATE/AlLOCATE does is ENQ related. No re-reading the libraries >> involved. >> >> >> >>> -Original Message- >>> From: IBM Mainframe Discussion List On >>> Behalf Of Pommier, Rex >>> Sent: Monday, August 22, 2022 11:32 AM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Linklist and Syncsort confusion >>> >>> [EXTERNAL EMAIL] >>> >>> Hi list, >>> >>> I don't know if this is specifically a Syncsort issue or a more generic >>> confusion >>> about linklist datasets. Here goes. >>> >>> We have the SYNCLINK library defined in the linklist. We have installed >>> Precisely's IEBGENER replacement as part of our install. We determined >>> SYNCLINK was too small. I allocated a larger version of the library on the >>> same volume as the current one. We had an IPL scheduled for Saturday so >>> right before the IPL, I logged in and did the library swap. My process was >>> (as I >>> thought) pretty standard. >>> >>> Shut down LLA and VLF >>> SETPROG LNKLST,UNALLOCATE >>> Rename the 2 libraries to get the new, larger one with the right name >>> SETPROG LNKLST,ALLOCATE >>> Start LLA and VLF. >>> >>> The operator then needed to run a couple pre-IPL jobs that use IEBGENER. >>> They failed with >>> IEW4009I FETCH FAILED FOR MODULE IEBGENER FROM DDNAME -LNKLST- >>> BECAUSE OF AN I/O ERROR. >>> IEW4005I FETCH FOR MODULE IEBGENER FROM DDNAME -LNKLST- FAILED >>> BECAUSE IEWFETCH ISSUED RC 0F AND REASON 40 >>> CSV031I LIBRARY ACCESS FAILED FOR MODULE IEBGENER, RETURN CODE 24, >>> REASON CODE 26080021, DDNAME *LNKLST* >>> >>> The manuals were less than helpful. IPLing took care of the problem but I'm >>> not clear as to either what I did wrong or if my understanding of the >>> UNALLOCATE/ALLOCATE is wrong. I was under the impression that doing the >>> UNALLOCATE then ALLOCATE rebuilt the linklist. It appears now to me that >>> all the UNALLOCATE does is remove the enqueues on the datasets and >>> ALLOCATE simply reestablishes the enqueues, still pointing to the original >>> location, but even that doesn't compute in my mind because I didn't change >>> any locations of either the old or new libraries. Or was it a mismatch >>> between the linklist and the LLA, and that possibly the linklis
Re: [EXTERNAL] Re: Linklist and Syncsort confusion
Hi Carmen, Yes the issue got resolved with the IPL. I am just trying to figure out what went wrong, why the system gave me the 106 abends after doing the dynamic changes. I'm thinking I should have built a new linklist and activated that one instead of just unallocating and allocating the current one. I wasn't having any luck using ISRFIND so I used ISRDDN and did a search thru the linklist and I did, indeed, find IEBGENER in the SYNCLINK loadlib as an alias to SYNCGENR.SYS1.LINKLIB has no IEBGENER, it has IEBGENR as an alias to IEBGENE9 which was renamed from IEBGENER by a usermod as part of the Syncsort install. It may be that the Syncsort standard is to rename IEBGENER to OLDGENER in LINKLIB, but our company standard is that when we rename something to "old" status, we change the last character of the name to '9'. Thanks again for your help. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Carmen Vitullo Sent: Monday, August 22, 2022 2:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: Linklist and Syncsort confusion ok, maybe I just missed it, do you resolve your issue? my ISRFIND shows IEBGENER in my linklist in the SYNCSORT LINKLIB, did the vendor change the usermod to assign an alias rather than use the IEBGERNER module name? in my SYS1.LINKLIB IEBGENER is an alias of OLDGENER maybe the usermod changed since I last supported SYNCSORT. Carmen On 8/22/2022 2:19 PM, Pommier, Rex wrote: > Answers embedded. > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Carmen Vitullo > Sent: Monday, August 22, 2022 1:48 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXTERNAL] Re: Linklist and Syncsort confusion > > you're sure the library is on the same volume? Yes > > did the new library contain secondary extents? No, but the old one was in > danger of going into secondary so we wanted to make it bigger. > > did you follow the syncsort process or usermod process to make > syncgener available as IEBGENER? Yes > > it renames IEBGENER as OLDGENER, I don't have the MOD in front of me > currently but I think. In our case, we manually renamed the default > IEBGENER to IEBGENE9 (don't ask why...) > > I agree with Dave, an LLA refresh or update should have been enough to > refresh LLA but sometime running address spaces will still pick up the old > linklist. Bouncing LLA should have done the same as a refresh - and I had to > shut it down in order to remove the allocation so I could rename the > libraries. I did double-check and did the ALLOCATE of LNKLST before starting > LLA. > > ISRFIND will help you see the linklist concatenation and tell you where > IEBGENER is found. ISRDDN LNKLST is showing IEBGENER as an alias of SYNCGENR > in the SYNCLINK library. > > 20-20 hindsight, I should have shut LLA and VLF back down to see if I still > got the 106 abends, to see if it was a mismatch between the linklist and LLA. > > Rex > > > Carmen > > On 8/22/2022 1:37 PM, Gibney, Dave wrote: >> You might have got away with a F LLA,REFRESH. I think you are correct, all >> UNALLOCATE/AlLOCATE does is ENQ related. No re-reading the libraries >> involved. >> >> >> >>> -Original Message- >>> From: IBM Mainframe Discussion List On >>> Behalf Of Pommier, Rex >>> Sent: Monday, August 22, 2022 11:32 AM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Linklist and Syncsort confusion >>> >>> [EXTERNAL EMAIL] >>> >>> Hi list, >>> >>> I don't know if this is specifically a Syncsort issue or a more >>> generic confusion about linklist datasets. Here goes. >>> >>> We have the SYNCLINK library defined in the linklist. We have >>> installed Precisely's IEBGENER replacement as part of our install. >>> We determined SYNCLINK was too small. I allocated a larger version >>> of the library on the same volume as the current one. We had an IPL >>> scheduled for Saturday so right before the IPL, I logged in and did >>> the library swap. My process was (as I >>> thought) pretty standard. >>> >>> Shut down LLA and VLF >>> SETPROG LNKLST,UNALLOCATE >>> Rename the 2 libraries to get the new, larger one with the right >>> name SETPROG LNKLST,ALLOCATE Start LLA and VLF. >>> >>> The operator then needed to run a couple pre-IPL jobs that use IEBGENER. >>> They failed with >>> IEW4009I FETCH FAILED FOR MODULE IEBGENER FROM DDNAME -LNKLST- >>> BECAUSE OF AN I/O ERROR. >>> IEW4005I FETCH FOR MODULE IEBGENER FROM DDNAME -LNKLST
Re: [EXTERNAL] Re: Linklist and Syncsort confusion
correction: in my SYS1.LINKLIB, IEBGENR is an alias of OLDGENER, since if SYNCGENER cannot perform as IEBGENER it will call OLDGERNER IIRC Carmen On 8/22/2022 2:19 PM, Pommier, Rex wrote: Answers embedded. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Carmen Vitullo Sent: Monday, August 22, 2022 1:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Linklist and Syncsort confusion you're sure the library is on the same volume? Yes did the new library contain secondary extents? No, but the old one was in danger of going into secondary so we wanted to make it bigger. did you follow the syncsort process or usermod process to make syncgener available as IEBGENER? Yes it renames IEBGENER as OLDGENER, I don't have the MOD in front of me currently but I think. In our case, we manually renamed the default IEBGENER to IEBGENE9 (don't ask why...) I agree with Dave, an LLA refresh or update should have been enough to refresh LLA but sometime running address spaces will still pick up the old linklist. Bouncing LLA should have done the same as a refresh - and I had to shut it down in order to remove the allocation so I could rename the libraries. I did double-check and did the ALLOCATE of LNKLST before starting LLA. ISRFIND will help you see the linklist concatenation and tell you where IEBGENER is found. ISRDDN LNKLST is showing IEBGENER as an alias of SYNCGENR in the SYNCLINK library. 20-20 hindsight, I should have shut LLA and VLF back down to see if I still got the 106 abends, to see if it was a mismatch between the linklist and LLA. Rex Carmen On 8/22/2022 1:37 PM, Gibney, Dave wrote: You might have got away with a F LLA,REFRESH. I think you are correct, all UNALLOCATE/AlLOCATE does is ENQ related. No re-reading the libraries involved. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex Sent: Monday, August 22, 2022 11:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Linklist and Syncsort confusion [EXTERNAL EMAIL] Hi list, I don't know if this is specifically a Syncsort issue or a more generic confusion about linklist datasets. Here goes. We have the SYNCLINK library defined in the linklist. We have installed Precisely's IEBGENER replacement as part of our install. We determined SYNCLINK was too small. I allocated a larger version of the library on the same volume as the current one. We had an IPL scheduled for Saturday so right before the IPL, I logged in and did the library swap. My process was (as I thought) pretty standard. Shut down LLA and VLF SETPROG LNKLST,UNALLOCATE Rename the 2 libraries to get the new, larger one with the right name SETPROG LNKLST,ALLOCATE Start LLA and VLF. The operator then needed to run a couple pre-IPL jobs that use IEBGENER. They failed with IEW4009I FETCH FAILED FOR MODULE IEBGENER FROM DDNAME -LNKLST- BECAUSE OF AN I/O ERROR. IEW4005I FETCH FOR MODULE IEBGENER FROM DDNAME -LNKLST- FAILED BECAUSE IEWFETCH ISSUED RC 0F AND REASON 40 CSV031I LIBRARY ACCESS FAILED FOR MODULE IEBGENER, RETURN CODE 24, REASON CODE 26080021, DDNAME *LNKLST* The manuals were less than helpful. IPLing took care of the problem but I'm not clear as to either what I did wrong or if my understanding of the UNALLOCATE/ALLOCATE is wrong. I was under the impression that doing the UNALLOCATE then ALLOCATE rebuilt the linklist. It appears now to me that all the UNALLOCATE does is remove the enqueues on the datasets and ALLOCATE simply reestablishes the enqueues, still pointing to the original location, but even that doesn't compute in my mind because I didn't change any locations of either the old or new libraries. Or was it a mismatch between the linklist and the LLA, and that possibly the linklist was still pointing to the original location of the SYNCLINK library but the LLA is now pointing to the new location? Would I have not had the problem if, instead of just doing the UNALLOCATE/ALLOCATE, I would have built and activated a LNKLST01 concatenation? I see the cautions in the system commands manual against moving or deleting a linklist dataset while the allocations are inactive and I obviously got burned by disobeying that warning. I'm just trying to figure out what the UNALLOCATE is doing and how to not have this happen when I have to perform this kind of maintenance. TIA, Rex -- The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error
Re: [EXTERNAL] Re: Linklist and Syncsort confusion
ok, maybe I just missed it, do you resolve your issue? my ISRFIND shows IEBGENER in my linklist in the SYNCSORT LINKLIB, did the vendor change the usermod to assign an alias rather than use the IEBGERNER module name? in my SYS1.LINKLIB IEBGENER is an alias of OLDGENER maybe the usermod changed since I last supported SYNCSORT. Carmen On 8/22/2022 2:19 PM, Pommier, Rex wrote: Answers embedded. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Carmen Vitullo Sent: Monday, August 22, 2022 1:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Linklist and Syncsort confusion you're sure the library is on the same volume? Yes did the new library contain secondary extents? No, but the old one was in danger of going into secondary so we wanted to make it bigger. did you follow the syncsort process or usermod process to make syncgener available as IEBGENER? Yes it renames IEBGENER as OLDGENER, I don't have the MOD in front of me currently but I think. In our case, we manually renamed the default IEBGENER to IEBGENE9 (don't ask why...) I agree with Dave, an LLA refresh or update should have been enough to refresh LLA but sometime running address spaces will still pick up the old linklist. Bouncing LLA should have done the same as a refresh - and I had to shut it down in order to remove the allocation so I could rename the libraries. I did double-check and did the ALLOCATE of LNKLST before starting LLA. ISRFIND will help you see the linklist concatenation and tell you where IEBGENER is found. ISRDDN LNKLST is showing IEBGENER as an alias of SYNCGENR in the SYNCLINK library. 20-20 hindsight, I should have shut LLA and VLF back down to see if I still got the 106 abends, to see if it was a mismatch between the linklist and LLA. Rex Carmen On 8/22/2022 1:37 PM, Gibney, Dave wrote: You might have got away with a F LLA,REFRESH. I think you are correct, all UNALLOCATE/AlLOCATE does is ENQ related. No re-reading the libraries involved. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex Sent: Monday, August 22, 2022 11:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Linklist and Syncsort confusion [EXTERNAL EMAIL] Hi list, I don't know if this is specifically a Syncsort issue or a more generic confusion about linklist datasets. Here goes. We have the SYNCLINK library defined in the linklist. We have installed Precisely's IEBGENER replacement as part of our install. We determined SYNCLINK was too small. I allocated a larger version of the library on the same volume as the current one. We had an IPL scheduled for Saturday so right before the IPL, I logged in and did the library swap. My process was (as I thought) pretty standard. Shut down LLA and VLF SETPROG LNKLST,UNALLOCATE Rename the 2 libraries to get the new, larger one with the right name SETPROG LNKLST,ALLOCATE Start LLA and VLF. The operator then needed to run a couple pre-IPL jobs that use IEBGENER. They failed with IEW4009I FETCH FAILED FOR MODULE IEBGENER FROM DDNAME -LNKLST- BECAUSE OF AN I/O ERROR. IEW4005I FETCH FOR MODULE IEBGENER FROM DDNAME -LNKLST- FAILED BECAUSE IEWFETCH ISSUED RC 0F AND REASON 40 CSV031I LIBRARY ACCESS FAILED FOR MODULE IEBGENER, RETURN CODE 24, REASON CODE 26080021, DDNAME *LNKLST* The manuals were less than helpful. IPLing took care of the problem but I'm not clear as to either what I did wrong or if my understanding of the UNALLOCATE/ALLOCATE is wrong. I was under the impression that doing the UNALLOCATE then ALLOCATE rebuilt the linklist. It appears now to me that all the UNALLOCATE does is remove the enqueues on the datasets and ALLOCATE simply reestablishes the enqueues, still pointing to the original location, but even that doesn't compute in my mind because I didn't change any locations of either the old or new libraries. Or was it a mismatch between the linklist and the LLA, and that possibly the linklist was still pointing to the original location of the SYNCLINK library but the LLA is now pointing to the new location? Would I have not had the problem if, instead of just doing the UNALLOCATE/ALLOCATE, I would have built and activated a LNKLST01 concatenation? I see the cautions in the system commands manual against moving or deleting a linklist dataset while the allocations are inactive and I obviously got burned by disobeying that warning. I'm just trying to figure out what the UNALLOCATE is doing and how to not have this happen when I have to perform this kind of maintenance. TIA, Rex -- The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that
Re: [EXTERNAL] Re: Linklist and Syncsort confusion
Answers embedded. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Carmen Vitullo Sent: Monday, August 22, 2022 1:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Linklist and Syncsort confusion you're sure the library is on the same volume? Yes did the new library contain secondary extents? No, but the old one was in danger of going into secondary so we wanted to make it bigger. did you follow the syncsort process or usermod process to make syncgener available as IEBGENER? Yes it renames IEBGENER as OLDGENER, I don't have the MOD in front of me currently but I think. In our case, we manually renamed the default IEBGENER to IEBGENE9 (don't ask why...) I agree with Dave, an LLA refresh or update should have been enough to refresh LLA but sometime running address spaces will still pick up the old linklist. Bouncing LLA should have done the same as a refresh - and I had to shut it down in order to remove the allocation so I could rename the libraries. I did double-check and did the ALLOCATE of LNKLST before starting LLA. ISRFIND will help you see the linklist concatenation and tell you where IEBGENER is found. ISRDDN LNKLST is showing IEBGENER as an alias of SYNCGENR in the SYNCLINK library. 20-20 hindsight, I should have shut LLA and VLF back down to see if I still got the 106 abends, to see if it was a mismatch between the linklist and LLA. Rex Carmen On 8/22/2022 1:37 PM, Gibney, Dave wrote: > You might have got away with a F LLA,REFRESH. I think you are correct, all > UNALLOCATE/AlLOCATE does is ENQ related. No re-reading the libraries involved. > > > >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of Pommier, Rex >> Sent: Monday, August 22, 2022 11:32 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Linklist and Syncsort confusion >> >> [EXTERNAL EMAIL] >> >> Hi list, >> >> I don't know if this is specifically a Syncsort issue or a more generic >> confusion >> about linklist datasets. Here goes. >> >> We have the SYNCLINK library defined in the linklist. We have installed >> Precisely's IEBGENER replacement as part of our install. We determined >> SYNCLINK was too small. I allocated a larger version of the library on the >> same volume as the current one. We had an IPL scheduled for Saturday so >> right before the IPL, I logged in and did the library swap. My process was >> (as I >> thought) pretty standard. >> >> Shut down LLA and VLF >> SETPROG LNKLST,UNALLOCATE >> Rename the 2 libraries to get the new, larger one with the right name >> SETPROG LNKLST,ALLOCATE >> Start LLA and VLF. >> >> The operator then needed to run a couple pre-IPL jobs that use IEBGENER. >> They failed with >> IEW4009I FETCH FAILED FOR MODULE IEBGENER FROM DDNAME -LNKLST- >> BECAUSE OF AN I/O ERROR. >> IEW4005I FETCH FOR MODULE IEBGENER FROM DDNAME -LNKLST- FAILED >> BECAUSE IEWFETCH ISSUED RC 0F AND REASON 40 >> CSV031I LIBRARY ACCESS FAILED FOR MODULE IEBGENER, RETURN CODE 24, >> REASON CODE 26080021, DDNAME *LNKLST* >> >> The manuals were less than helpful. IPLing took care of the problem but I'm >> not clear as to either what I did wrong or if my understanding of the >> UNALLOCATE/ALLOCATE is wrong. I was under the impression that doing the >> UNALLOCATE then ALLOCATE rebuilt the linklist. It appears now to me that >> all the UNALLOCATE does is remove the enqueues on the datasets and >> ALLOCATE simply reestablishes the enqueues, still pointing to the original >> location, but even that doesn't compute in my mind because I didn't change >> any locations of either the old or new libraries. Or was it a mismatch >> between the linklist and the LLA, and that possibly the linklist was still >> pointing to the original location of the SYNCLINK library but the LLA is now >> pointing to the new location? Would I have not had the problem if, instead >> of just doing the UNALLOCATE/ALLOCATE, I would have built and activated a >> LNKLST01 concatenation? >> >> I see the cautions in the system commands manual against moving or >> deleting a linklist dataset while the allocations are inactive and I >> obviously got >> burned by disobeying that warning. I'm just trying to figure out what the >> UNALLOCATE is doing and how to not have this happen when I have to >> perform this kind of maintenance. >> >> TIA, >> >> Rex >> >> -- >> The information contained in this message is confidential, protected from >
Re: Linklist and Syncsort confusion
you're sure the library is on the same volume? did the new library contain secondary extents? did you follow the syncsort process or usermod process to make syncgener available as IEBGENER? it renames IEBGENER as OLDGENER, I don't have the MOD in front of me currently but I think I agree with Dave, an LLA refresh or update should have been enough to refresh LLA but sometime running address spaces will still pick up the old linklist. ISRFIND will help you see the linklist concatenation and tell you where IEBGENER is found Carmen On 8/22/2022 1:37 PM, Gibney, Dave wrote: You might have got away with a F LLA,REFRESH. I think you are correct, all UNALLOCATE/AlLOCATE does is ENQ related. No re-reading the libraries involved. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex Sent: Monday, August 22, 2022 11:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Linklist and Syncsort confusion [EXTERNAL EMAIL] Hi list, I don't know if this is specifically a Syncsort issue or a more generic confusion about linklist datasets. Here goes. We have the SYNCLINK library defined in the linklist. We have installed Precisely's IEBGENER replacement as part of our install. We determined SYNCLINK was too small. I allocated a larger version of the library on the same volume as the current one. We had an IPL scheduled for Saturday so right before the IPL, I logged in and did the library swap. My process was (as I thought) pretty standard. Shut down LLA and VLF SETPROG LNKLST,UNALLOCATE Rename the 2 libraries to get the new, larger one with the right name SETPROG LNKLST,ALLOCATE Start LLA and VLF. The operator then needed to run a couple pre-IPL jobs that use IEBGENER. They failed with IEW4009I FETCH FAILED FOR MODULE IEBGENER FROM DDNAME -LNKLST- BECAUSE OF AN I/O ERROR. IEW4005I FETCH FOR MODULE IEBGENER FROM DDNAME -LNKLST- FAILED BECAUSE IEWFETCH ISSUED RC 0F AND REASON 40 CSV031I LIBRARY ACCESS FAILED FOR MODULE IEBGENER, RETURN CODE 24, REASON CODE 26080021, DDNAME *LNKLST* The manuals were less than helpful. IPLing took care of the problem but I'm not clear as to either what I did wrong or if my understanding of the UNALLOCATE/ALLOCATE is wrong. I was under the impression that doing the UNALLOCATE then ALLOCATE rebuilt the linklist. It appears now to me that all the UNALLOCATE does is remove the enqueues on the datasets and ALLOCATE simply reestablishes the enqueues, still pointing to the original location, but even that doesn't compute in my mind because I didn't change any locations of either the old or new libraries. Or was it a mismatch between the linklist and the LLA, and that possibly the linklist was still pointing to the original location of the SYNCLINK library but the LLA is now pointing to the new location? Would I have not had the problem if, instead of just doing the UNALLOCATE/ALLOCATE, I would have built and activated a LNKLST01 concatenation? I see the cautions in the system commands manual against moving or deleting a linklist dataset while the allocations are inactive and I obviously got burned by disobeying that warning. I'm just trying to figure out what the UNALLOCATE is doing and how to not have this happen when I have to perform this kind of maintenance. TIA, Rex -- The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- 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: Linklist and Syncsort confusion
I think the original linklist is still active, shutting down LLA and VLF, only used to fetch members faster. I think you need to create a new LINKLST https://www.ibm.com/docs/en/zos/2.4.0?topic=command-updating-lnklst-concatenations and make it active Carmen On 8/22/2022 1:32 PM, Pommier, Rex wrote: Hi list, I don't know if this is specifically a Syncsort issue or a more generic confusion about linklist datasets. Here goes. We have the SYNCLINK library defined in the linklist. We have installed Precisely's IEBGENER replacement as part of our install. We determined SYNCLINK was too small. I allocated a larger version of the library on the same volume as the current one. We had an IPL scheduled for Saturday so right before the IPL, I logged in and did the library swap. My process was (as I thought) pretty standard. Shut down LLA and VLF SETPROG LNKLST,UNALLOCATE Rename the 2 libraries to get the new, larger one with the right name SETPROG LNKLST,ALLOCATE Start LLA and VLF. The operator then needed to run a couple pre-IPL jobs that use IEBGENER. They failed with IEW4009I FETCH FAILED FOR MODULE IEBGENER FROM DDNAME -LNKLST- BECAUSE OF AN I/O ERROR. IEW4005I FETCH FOR MODULE IEBGENER FROM DDNAME -LNKLST- FAILED BECAUSE IEWFETCH ISSUED RC 0F AND REASON 40 CSV031I LIBRARY ACCESS FAILED FOR MODULE IEBGENER, RETURN CODE 24, REASON CODE 26080021, DDNAME *LNKLST* The manuals were less than helpful. IPLing took care of the problem but I'm not clear as to either what I did wrong or if my understanding of the UNALLOCATE/ALLOCATE is wrong. I was under the impression that doing the UNALLOCATE then ALLOCATE rebuilt the linklist. It appears now to me that all the UNALLOCATE does is remove the enqueues on the datasets and ALLOCATE simply reestablishes the enqueues, still pointing to the original location, but even that doesn't compute in my mind because I didn't change any locations of either the old or new libraries. Or was it a mismatch between the linklist and the LLA, and that possibly the linklist was still pointing to the original location of the SYNCLINK library but the LLA is now pointing to the new location? Would I have not had the problem if, instead of just doing the UNALLOCATE/ALLOCATE, I would have built and activated a LNKLST01 concatenation? I see the cautions in the system commands manual against moving or deleting a linklist dataset while the allocations are inactive and I obviously got burned by disobeying that warning. I'm just trying to figure out what the UNALLOCATE is doing and how to not have this happen when I have to perform this kind of maintenance. TIA, Rex -- The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- 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: Linklist and Syncsort confusion
You might have got away with a F LLA,REFRESH. I think you are correct, all UNALLOCATE/AlLOCATE does is ENQ related. No re-reading the libraries involved. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Pommier, Rex > Sent: Monday, August 22, 2022 11:32 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Linklist and Syncsort confusion > > [EXTERNAL EMAIL] > > Hi list, > > I don't know if this is specifically a Syncsort issue or a more generic > confusion > about linklist datasets. Here goes. > > We have the SYNCLINK library defined in the linklist. We have installed > Precisely's IEBGENER replacement as part of our install. We determined > SYNCLINK was too small. I allocated a larger version of the library on the > same volume as the current one. We had an IPL scheduled for Saturday so > right before the IPL, I logged in and did the library swap. My process was > (as I > thought) pretty standard. > > Shut down LLA and VLF > SETPROG LNKLST,UNALLOCATE > Rename the 2 libraries to get the new, larger one with the right name > SETPROG LNKLST,ALLOCATE > Start LLA and VLF. > > The operator then needed to run a couple pre-IPL jobs that use IEBGENER. > They failed with > IEW4009I FETCH FAILED FOR MODULE IEBGENER FROM DDNAME -LNKLST- > BECAUSE OF AN I/O ERROR. > IEW4005I FETCH FOR MODULE IEBGENER FROM DDNAME -LNKLST- FAILED > BECAUSE IEWFETCH ISSUED RC 0F AND REASON 40 > CSV031I LIBRARY ACCESS FAILED FOR MODULE IEBGENER, RETURN CODE 24, > REASON CODE 26080021, DDNAME *LNKLST* > > The manuals were less than helpful. IPLing took care of the problem but I'm > not clear as to either what I did wrong or if my understanding of the > UNALLOCATE/ALLOCATE is wrong. I was under the impression that doing the > UNALLOCATE then ALLOCATE rebuilt the linklist. It appears now to me that > all the UNALLOCATE does is remove the enqueues on the datasets and > ALLOCATE simply reestablishes the enqueues, still pointing to the original > location, but even that doesn't compute in my mind because I didn't change > any locations of either the old or new libraries. Or was it a mismatch > between the linklist and the LLA, and that possibly the linklist was still > pointing to the original location of the SYNCLINK library but the LLA is now > pointing to the new location? Would I have not had the problem if, instead > of just doing the UNALLOCATE/ALLOCATE, I would have built and activated a > LNKLST01 concatenation? > > I see the cautions in the system commands manual against moving or > deleting a linklist dataset while the allocations are inactive and I > obviously got > burned by disobeying that warning. I'm just trying to figure out what the > UNALLOCATE is doing and how to not have this happen when I have to > perform this kind of maintenance. > > TIA, > > Rex > > -- > The information contained in this message is confidential, protected from > disclosure and may be legally privileged. If the reader of this message is not > the intended recipient or an employee or agent responsible for delivering > this message to the intended recipient, you are hereby notified that any > disclosure, distribution, copying, or any action taken or action omitted in > reliance on it, is strictly prohibited and may be unlawful. If you have > received > this communication in error, please notify us immediately by replying to this > message and destroy the material in its entirety, whether in electronic or > hard copy format. Thank you. > > > -- > 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
