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 <[email protected]> On Behalf Of
Carmen Vitullo
Sent: Monday, August 22, 2022 1:48 PM
To: [email protected]
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 <[email protected]> On
Behalf Of Pommier, Rex
Sent: Monday, August 22, 2022 11:32 AM
To: [email protected]
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 [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] 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 [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
