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 <IBM-MAIN@LISTSERV.UA.EDU> 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 <IBM-MAIN@LISTSERV.UA.EDU> 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 <IBM-MAIN@LISTSERV.UA.EDU> 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 <IBM-MAIN@LISTSERV.UA.EDU> 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
----------------------------------------------------------------------
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
----------------------------------------------------------------------
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.
________________________________
----------------------------------------------------------------------
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
