I found and fixed the problem. There was a bad user exit for the product in
one of the linklist datasets concatenated ahead of the vendor library. This
was put in place to try to resolve another issue but no one realized that
the library was actually in the linklist.
Thanks for all the
It is conceivable that there is an error in LLA, particularly if there are
multiple LNKLST sets active.
If you are getting an entirely wrong module (i.e., the system loaded X
when you requested Y),
that could be LLA. There were problems several years ago that manifested
itself this way.
If the
PDSEs (was: linklisted load library failing)
PDS's have the reclaiming space issue, PDSE's should not.
With a PDSE when a member is deleted, or re-written to a larger block,
the unused space it had occupied becomes available for immediate usage
by the next write (STOR) activity. It maintains
On Thu, 16 Aug 2007 11:32:01 -0400, Imbriale, Donald wrote:
To reclaim space in a PDSE which is in linklist and if linklist is
managed by LLA, the library will need to be removed from LLA management
then a job to write one member to the PDSE should be run to initiate the
reclaim process.
From
On Thu, 16 Aug 2007 11:55:19 -0500, Paul Gilmartin
[EMAIL PROTECTED] wrote:
On Thu, 16 Aug 2007 11:32:01 -0400, Imbriale, Donald wrote:
From Using Data Sets:
the
member space is not reclaimed until the connection is released and the
data set is opened for output and that OPEN for OUTPUT
On Thu, 16 Aug 2007 11:21:24 -0400, Peter Relson [EMAIL PROTECTED] wrote:
It is conceivable that there is an error in LLA, particularly if there are
multiple LNKLST sets active.
The really strange thing is that an IPL is what broke it. We verified this
by IPLing our Test LPAR today. What
Silly question but is the catalog entry for the dataset in question
pointing to one volume but the linklist entry pointing to a different
volume?
No. The dataset is cataloged in the mastercat and the volume isn't
specified in PROGxx. Thanks for the thought though.
Debbie Mitchell
Debbie Mitchell wrote:
On Thu, 16 Aug 2007 11:21:24 -0400, Peter Relson [EMAIL PROTECTED] wrote:
It is conceivable that there is an error in LLA, particularly if there are
multiple LNKLST sets active.
The really strange thing is that an IPL is what broke it. We verified this
by
Debbie Mitchell said:
The really strange thing is that an IPL is what broke it. We verified
this by IPLing our Test LPAR today. What worked
there yesterday no longer works after the IPL.
And you get NO errors at IPL time? Is this a physically different
SYSRES? Are there new LINKLIST
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 08/16/2007
02:53:00 PM:
And you get NO errors at IPL time? Is this a physically different
SYSRES? Are there new LINKLIST libraries ahead of the one getting the
errors? What was updated, compressed, etc. since the last IPL?
No
In a message dated 8/16/2007 2:03:07 P.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
Tomorrow morning I plan to move the library having the problems up in the
linklist concatenation (currently it's nearly last) to see if that has any
impact.
Without knowing what else has gone
On Thu, 16 Aug 2007 15:05:00 -0400, Debbie Mitchell
[EMAIL PROTECTED] wrote:
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 08/16/2007
02:53:00 PM:
And you get NO errors at IPL time? Is this a physically different
SYSRES? Are there new LINKLIST libraries ahead of the one getting
On Thu, 16 Aug 2007 15:05:00 -0400, Debbie Mitchell
[EMAIL PROTECTED] wrote:
...
No errors at IPL. I can't find anything different at all. I had applied
one PTF between IPLs and even though I was 99.9% sure that
wasn't the
problem I restored it on my test LPAR and IPL'd. Still broken. ...
As Peter Relson already asked: What exactly are the abend0C4s/0C1s? Which
module, for the 0C4 which reason code? Take a look at the dumps!
Barbara Nitz
--
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger
I'm pretty sure that limit is 123 extents. It may have been changed in a
later release though.
255 extents; just like the JCL concatenation limit.
If your datasets are all in one extent you can get to 255 datasets.
BTW, a PDSE counts as only one extent, regardless.
-
Too busy driving to stop
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Bill Wilkie
Sent: Tuesday, August 14, 2007 7:19 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: linklisted load library failing
You may also want to check on the Blksize of the libraries and place
No one appeared even to take the step of inquiring what caused the 0C1 or
0C4.
It is very unlikely that extents have anything to do with this, as an
extent problem would usually result in some sort of fetch failure, well
preceding a module execution problem.. It is possible that reentrancy has
On Tue, 14 Aug 2007 21:41:02 +, Ted MacNEIL [EMAIL PROTECTED] wrote:
I'm pretty sure that limit is 123 extents. It may have been changed in a
later release though.
255 extents; just like the JCL concatenation limit.
True now, but this did change much more recently than the LNKLST
change
On Wed, 15 Aug 2007 09:29:51 -0400, Thompson, Steve
[EMAIL PROTECTED] wrote:
However, I have been reading the posts on this, and I think you may want
to review all files in the LNKLST and ensure that that they are
allocated as only PRIMARY space.
I say this because I ran into a similar problem
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Mark Zelden
Sent: Wednesday, August 15, 2007 10:30 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: linklisted load library failing
On Wed, 15 Aug 2007 09:29:51 -0400, Thompson, Steve
[EMAIL PROTECTED
---snip--
And so, this is why I tell people to do their allocations for LNKLST or
CICS as only a primary, no secondary, CONTIG. And make the primary space
at least 25% larger than the used space once it is compressed
(especially so CICS).
On Wed, 15 Aug 2007 14:47:16 -0500, Paul Gilmartin
[EMAIL PROTECTED] wrote:
...
100% in order to do an APPLY REDO (but that's a strange thing
to do in a LINKLST library). PDSE could make the situation
better, even to the extent of needing only surplus space as
large as the largest member; or
On Wed, 15 Aug 2007 09:29:51 -0400, Thompson, Steve wrote:
However, I have been reading the posts on this, and I think you may want
to review all files in the LNKLST and ensure that that they are
allocated as only PRIMARY space.
Should this recommendation also apply to libraries that are
kept
On Wed, 15 Aug 2007 14:44:03 -0700, GAVIN Darren * OPS EAS
[EMAIL PROTECTED] wrote:
...
With a PDSE when a member is deleted, or re-written to a larger
block,
the unused space it had occupied becomes available for immediate
usage
by the next write (STOR) activity. It maintains a list of free
Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Paul Gilmartin
Sent: Wednesday, August 15, 2007 1:40 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Refreshing PDSEs (was: linklisted load library failing)
On Wed, 15 Aug 2007 14:57:16 -0500, Patrick O'Keefe wrote:
Then, how
On Wed, 15 Aug 2007 15:40:26 -0500, Paul Gilmartin
[EMAIL PROTECTED] wrote:
...
But this is for integrity in case:
Address space A does a BLDL, FIND, or NOTE.
Address space B replaces or deletes the member that
address space A found.
Address space A then POINTs at the member.
PDS's have the reclaiming space issue, PDSE's should not.
With a PDSE when a member is deleted, or re-written to a larger block, the
unused space it had occupied becomes available for immediate usage by the next
write (STOR) activity.
Not entirely accurate.
If the member(s) are still in use
On Wed, 15 Aug 2007 21:50:21 +, Ted MacNEIL wrote:
PDS's have the reclaiming space issue, PDSE's should not.
With a PDSE when a member is deleted, or re-written to a larger block, the
unused space it had occupied becomes available for immediate usage by the next
write (STOR) activity.
Not
On Wed, 15 Aug 2007 14:57:16 -0500, Patrick O'Keefe wrote:
100% in order to do an APPLY REDO (but that's a strange thing
to do in a LINKLST library). PDSE could make the situation
better, even to the extent of needing only surplus space as
large as the largest member; or worse, because space may
I am having various abends (S0c1, S0c4) with modules accessed through a
linklisted library. The library itself appears to be fine. If I steplib to
the library instead of accessing it through the linklist, my job runs
without issue. I have recycled both LLA and VLF and still have the same
snip
I am having various abends (S0c1, S0c4) with modules accessed through a
linklisted library. The library itself appears to be fine. If I
steplib to the library instead of accessing it through the linklist, my
job runs without issue. I have recycled both LLA and VLF and still have
the same
I'm pretty sure that limit is 123 extents. It may have been changed in a
later release though.
Eric Bielefeld
Sr. z/OS Systems Programmer
Milwaukee, Wisconsin
414-475-7434
- Original Message -
From: Fletcher, Kevin [EMAIL PROTECTED]
Debbie,
I remember (I am old and has been
The last formula I saw was
total = 100 + (16 * totextents) + (numds - 1)
if total 2041 then the Linklist is too large and will be truncated
Where ttextents is the total number of extents for all linklist
libraries and numds is the number of libraries in the linklist.
On Tue, 14 Aug 2007 13:08:05 -0500, Eric Bielefeld wrote:
I'm pretty sure that limit is 123 extents. It may have been changed in a
later release though.
I think LINKLIST itself allows 255 extents total - including primaries. If you
went beyond that, you'd get messages telling you that though.
On Tue, 14 Aug 2007 13:33:08 -0500, Dave Kopischke wrote:
Have you tried SETPROG LINKLIST,DEALLOCATE and then
ALLOCATE ??? That should address any linklist library that went into an
extent,
but I'd try to find it first before doing this.
Make that:
SETPROG LNKLST,UNALLOCATE
--- and then ---
On Tue, 14 Aug 2007 12:53:07 -0500 Debbie Mitchell
[EMAIL PROTECTED] wrote:
:I am having various abends (S0c1, S0c4) with modules accessed through a
:linklisted library. The library itself appears to be fine. If I steplib to
:the library instead of accessing it through the linklist, my job runs
If there is a problem with the linklist you should be getting fetch fail
messages. Are you sure that you are picking up the same modules? They
don't reside in an earlier linklist library?
Jon L. Veilleux
[EMAIL PROTECTED]
(860) 636-2683
This e-mail may contain confidential or privileged
Might they be marked reentrant and loaded in protected storage when
coming from linklist?
--
Binyamin Dissen
Debbie, Binyamin is right. If they are marked RENT and they are not
actually reentrant then they will fail when loaded from the LINKLIST.
Jon L. Veilleux
[EMAIL PROTECTED]
(860)
I'm sure that you have checked that the library didn't go into a new extent
since ipl/sestprog and that lla was refreshed since adding a module.
Jack Kelly
LA Systems @ US Courts
x 202-502-2390
--
For IBM-MAIN subscribe /
If you have any control over the source for these modules you could try
assembling them with the RENT option. This will do some checking to see
if the modules violate reentrancy. It is not exhaustive but it might
help. Th following is from the HLASM Programmers guide:
On Tue, 14 Aug 2007 12:53:07 -0500, Debbie Mitchell
[EMAIL PROTECTED] wrote:
I am having various abends (S0c1, S0c4) with modules accessed through a
linklisted library. The library itself appears to be fine. If I steplib to
the library instead of accessing it through the linklist, my job runs
On Tue, 14 Aug 2007 14:26:18 -0400, Veilleux, Jon L [EMAIL PROTECTED]
wrote:
The last formula I saw was
total = 100 + (16 * totextents) + (numds - 1)
if total 2041 then the Linklist is too large and will be truncated
Where ttextents is the total number of extents for all linklist
libraries and
On Tue, 14 Aug 2007 13:33:08 -0500, Dave Kopischke
[EMAIL PROTECTED] wrote:
Is it one product that is giving you trouble ??? Was there maintenance applied
to it lately. Maybe a library went into an extent that linklist doesn't know
about Have you tried SETPROG LINKLIST,DEALLOCATE and then
Mark Zelden wrote:
That is *very* old. It changed in DFSMS/MVS 1.3.
Mark, I am old also.
Thanks for the update!
Jon
Jon L. Veilleux
[EMAIL PROTECTED]
(860) 636-2683
This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please
On Tue, 14 Aug 2007 21:43:15 +0300, Binyamin Dissen
[EMAIL PROTECTED] wrote:
On Tue, 14 Aug 2007 12:53:07 -0500 Debbie Mitchell
[EMAIL PROTECTED] wrote:
:I am having various abends (S0c1, S0c4) with modules accessed through a
:linklisted library. The library itself appears to be fine. If I
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Mark Zelden
Sent: Tuesday, August 14, 2007 3:10 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: [SPAM] Re: linklisted load library failing
Importance: Low
On Tue, 14 Aug 2007 12:53:07 -0500, Debbie Mitchell
Actually, this is vendor code which is *very* old and an unsupported
release...that being said, it has been working without issue virtually
forever. We IPL'd on Saturday and last night all sorts of jobs started
failing. I don't see any messages from the IPL that indicate any problem.
Our
Debbie,
All good suggestions.
What I typically do is browse the data set in the linklst the member (module)
resides. I first look to make sure there are no extents. I will allocate
datasets in the linkst with primary and no seconday.
Next in the data set I sort on TTR and see if the module
So the question now comes to: What changes occurred at IPL?
What software changes? Apar/PTFs applied. What level of z/OS or OS/390 are
you running.
Any parmlib changes - I ran into an issue when we moved SWA above the line,
same with UCB.
Have you reviewed a dump to see what area the
noone has access to those libraries.
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Lizette Koehler
Sent: Tuesday, August 14, 2007 3:32 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: [SPAM] Re: linklisted load library failing
Importance: Low
So
You may also want to check on the Blksize of the libraries and place the
larger one first if they are different.
Bill
From: Dave Kopischke [EMAIL PROTECTED]
Reply-To: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: linklisted load library failing
Date
51 matches
Mail list logo
