To: IBM-MAIN@listserv.ua.edu
Subject: Re: S106 abends after copying into LINKLIST
I do not know whether LLA keeps a pointer to the first text record
(though it might), but it would certainly need the preceding associated
control and ESD records to be cached as well if the first read done is
for a
My $0,02:
1. Use PDSE on LNKLST whenever possible
2. For PDS do not use secondary allocation (and single extent for
primary, CONTIG)
3. Keep number of "your own" libraries as small as possible
4. Allow LNKLST additions, not deletions (or just be prepared for IPL)
5. PTFs on LNKLST are good reaso
I do not know whether LLA keeps a pointer to the first text record
(though it might), but it would certainly need the preceding associated
control and ESD records to be cached as well if the first read done is
for a text record. I would expect that, since the ESD and control
records encode the
> Last friday morning we copied new CICS LINKLIST/LPA modules into the
> existing LINKLI in use (a rather new scenario in use here - we used to
> use alternative datasets), in be done sunday morning.
>
> anyway, around 6pm friday evening, an I/O error occured in linklist
> and other jobs s the lin
@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST
STOPX-37 :(
Carmen Vitullo
- Original Message -
From: "Robert E Longabaugh"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Friday, October 5, 2018 1:03:52 PM
Subject: Re: S106 abends after copying into LINKLIST
A.EDU
> Sent: Friday, October 5, 2018 1:03:52 PM
> Subject: Re: S106 abends after copying into LINKLIST
>
> " Now my memory is fading, what is the name of that third party product which
> could intercept x37 abends and then dynamically fix it for you? "
>
> CA
And ACC/SRS from DTS Software.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Jackson, Rob
Sent: Friday, October 05, 2018 2:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [Originated Externally]Re: S106 abends after copying into LINKLIST
[External Email]
Hah, I&#x
nt: Friday, October 05, 2018 2:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST
[External Email]
" Now my memory is fading, what is the name of that third party product which
could intercept x37 abends and then dynamically fix it for you? "
CA Allocat
STOPX-37 :(
Carmen Vitullo
- Original Message -
From: "Robert E Longabaugh"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Friday, October 5, 2018 1:03:52 PM
Subject: Re: S106 abends after copying into LINKLIST
" Now my memory is fading, what is the name of that third part
id it does.
Just trying to help
Bob Longabaugh
CA Technologies
Storage Management
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Elardus Engelbrecht
Sent: Friday, October 05, 2018 6:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying int
n List on behalf of
John Eells
Sent: Friday, October 5, 2018 6:45 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: S106 abends after copying into LINKLIST
Jesse 1 Robinson wrote:
> I sympathize with IBM's predicament in reading the future maintenance tea
> leaves. The 'fix rate' fo
Practically a guarantee that **someone** out there will...
/Tom Sims
On 10/5/2018 3:45 AM, John Eells wrote:
Unlike some other memories, nobody will miss the "good
old days."
--
For IBM-MAIN subscribe / signoff / archive
John Eells wrote:
>I expect that we will err on the side of more free space pretty soon to help
>alleviate out of space problems in this new(er) era of larger system software
>volumes, particularly because system software is such a small fraction of the
>disk space requirements for nearly any s
Jesse 1 Robinson wrote:
I sympathize with IBM's predicament in reading the future maintenance tea
leaves. The 'fix rate' for a product might be subject to guesstimation from
past experience. But the effects of future enhancements like SPEs and customer
requirements are a bundle of uncertaintie
Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of John Eells
Sent: Thursday, October 04, 2018 4:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: S106 abends after copyin
Elardus Engelbrecht wrote:
This is why you see in Program Directories the required space for each
dataset/OMVS files needed for each product you ordered.
Let's just be clear about what those space numbers represent.
They are:
- a fixed percentage larger (10 or 15%, I forget right now) than
Jesse 1 Robinson wrote:
>Whether 'tis nobler in the mind to suffer
>The slings and arrows of secondary extents,
>Or to take arms against a sea of B37s,
>And by opposing end them?
Good one. +1 for you. For me: c all 'B37' 'ICH408I' ;-)
>Gil may have been right about this being th
43-6132 Office ⇐=== NEW
robin...@sce.com
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Seymour J Metz
Sent: Wednesday, October 03, 2018 1:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: S106 abends after copying into LINKLIST
I state
du/~smetz3
From: IBM Mainframe Discussion List on behalf of Ed
Jaffe
Sent: Tuesday, October 2, 2018 7:06 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: S106 abends after copying into LINKLIST
On 10/2/2018 8:43 AM, Seymour J Metz wrote:
> I prefer to avoid the problem by never up
On 10/3/2018 10:46 AM, Paul Gilmartin wrote:
On Wed, 3 Oct 2018 10:04:44 -0700, Ed Jaffe wrote:
The issue is the connection created by FIND and traditional BLDL. The
newfangled BLDL NOCONNECT avoids gratuitous connections to members you
don't really intend to access, but at some point if you're
On Wed, 3 Oct 2018 10:04:44 -0700, Ed Jaffe wrote:
>
>The issue is the connection created by FIND and traditional BLDL. The
>newfangled BLDL NOCONNECT avoids gratuitous connections to members you
>don't really intend to access, but at some point if you're gonna read in
>the member, you're gonna iss
On 10/2/2018 10:30 PM, Peter Hunkeler wrote:
Are you sure space is reclaimed for deleted members if the data set is open by
LNKLST?
Interesting question. Easy to test for someone with a sandbox system (I don't
have any such to play with). Well, one could test with STEPLIB but that does
not t
On Wed, 3 Oct 2018 07:30:09 +0200, Peter Hunkeler wrote:
>>Are you sure space is reclaimed for deleted members if the data set is open
>>by LNKLST?
>
>Interesting question. Easy to test for someone with a sandbox system (I don't
>have any such to play with). Well, one could test with STEPLIB bu
2018 6:11:29 PM
Subject: Re: S106 abends after copying into LINKLIST
On 10/2/2018 12:32 PM, Carmen Vitullo wrote:
> Got me, I've never had an issue with a PDS/E in the linklist, PDS/E's for me
> solved some issues with directory block allocation and having the ability to
> reu
>And never put your LNKLST datasets in SMS
I strongly disagree with this statement.
There is nothing wrong with having your LNKLST data sets be SMS-managed.
There is nothing wrong with having PDSEs in the LNKLST.
>Update your LNKLST dynamically.
Sure. But do not use LNKLST UPDATE JOB(*) unle
0:30 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: AW: Re: S106 abends after copying into LINKLIST
>
> >Are you sure space is reclaimed for deleted members if the data set is open
> by LNKLST?
>
>
> Interesting question. Easy to test for someone with a sandbox system (I
&g
>Are you sure space is reclaimed for deleted members if the data set is open by
>LNKLST?
Interesting question. Easy to test for someone with a sandbox system (I don't
have any such to play with). Well, one could test with STEPLIB but that does
not tell anything, if there was special code in PD
On 10/2/2018 12:32 PM, Carmen Vitullo wrote:
Got me, I've never had an issue with a PDS/E in the linklist, PDS/E's for me
solved some issues with directory block allocation and having the ability to
reuse space, when a member is deleted/modified or added
Are you sure space is reclaimed for de
On 10/2/2018 8:43 AM, Seymour J Metz wrote:
I prefer to avoid the problem by never updating a live linklist library.
NEVER is a strong word. Too strong for the dynamic modern world, IMHO.
If there is some sort of *major* error that needs fixing NOW, then we
will receive the fix and -- if it h
;Paul Gilmartin" <000433f07816-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Tuesday, October 2, 2018 2:01:27 PM
Subject: Re: S106 abends after copying into LINKLIST
On Tue, 2 Oct 2018 13:28:27 -0400, Carmen Vitullo wrote:
>absolutely agree, my link list lib's ar
On Tue, 2 Oct 2018 13:28:27 -0400, Carmen Vitullo wrote:
>absolutely agree, my link list lib's are not SMS manged, but I'm the z/OS guy,
>some on the team are not sysprogs and allocate based on the vendor doc and my
>storage guy, likes to mis I mean manage everything, and they get burnt :(
>
ve Beaver"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Tuesday, October 2, 2018 12:15:21 PM
Subject: Re: S106 abends after copying into LINKLIST
Never, ever let your LINKLST go into secondary's. Otherwise you will quickly
learn how to
Update your LNKLST dynamically. And never put yo
te for the install +
maint, if possible.
my .2 cents
Carmen Vitullo
- Original Message -
From: "Eileen Barkow"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Tuesday, October 2, 2018 10:42:25 AM
Subject: Re: S106 abends after copying into LINKLIST
I agree that this maintenance
artin
Sent: Tuesday, October 2, 2018 12:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST
On Tue, 2 Oct 2018 15:34:44 +, Seymour J Metz wrote:
>Alas, your allocation can still get another extent, but I'd prefer that nobody
>explain how;
>somebo
On Tue, 2 Oct 2018 15:34:44 +, Seymour J Metz wrote:
>Alas, your allocation can still get another extent, but I'd prefer that nobody
>explain how;
>somebody might think that it was a good idea and cause the obvious problems.
>
Since I don't encourage integrity by obscurity, I'll ask the quest
On Tue, 2 Oct 2018 09:01:02 -0400, John Eells wrote:
>
>*I expect most people to move to thin provisioned volumes over time
>because the business case is compelling. On TP volumes, there is no
>reason not to use very large primary extents, which can obviate any
>advantage to secondary space alloca
11:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST
Because otherwise you risk an S106. A better question is why you didn't consult
with the MVS group and devise a bulletproof maintenance strategy.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~s
@listserv.ua.edu
Subject: Re: S106 abends after copying into LINKLIST
On 10/1/2018 1:34 PM, Jesse 1 Robinson wrote:
> There are two separate problems here. (1) A link list library taking a new
> extent after IPL. (2) An LLA-managed library having contents moved by either
> compress or reload.
>
: Re: S106 abends after copying into LINKLIST
> Perhaps someone can offer a plausible explanation for this, so that
> the MVS group will stop blaming the CICS group for the problem.
An explanation will not stop the MVS group from blaming the CICS group for a
problem caused by the CICS group
frame Discussion List on behalf of
Barkow, Eileen
Sent: Monday, October 1, 2018 10:33 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: S106 abends after copying into LINKLIST
The dataset is a standard pds (CICS SDFHLINK).
We used some sort of SAS proc/clists to empty out the members before copying
th
frame Discussion List on behalf of
Carmen Vitullo
Sent: Monday, October 1, 2018 11:55 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: S106 abends after copying into LINKLIST
There's the key, in the allocation, if I allocate space for a linklist library
I DO NOT specify any secondary allocation, zer
lf of
Barkow, Eileen
Sent: Monday, October 1, 2018 10:21 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: S106 abends after copying into LINKLIST
The whole idea was not to have to refresh LLA - we wanted to wait until the
IPL.
Why should LLA have to be refreshed if we did not want the changes to
> Perhaps someone can offer a plausible explanation for this, so that
> the MVS group will stop blaming the CICS group for the problem.
An explanation will not stop the MVS group from blaming the CICS group for a
problem caused by the CICS group. Your current maintenance strategy is
dangerous an
John Eells wrote:
exceeding the link list extent limit the topic of this thread
That should read, "...exceeding the link list extent limit *and* the
topic of this thread"
--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com
Ed Jaffe wrote:
I never liked defining secondary of zero. I realize it's IBM's
recommendation, but it all but ensures a compress will be performed when
the library fills up. I've had systems crash either during or after such
a compress -- sometimes with disastrous consequences!
Whether it's
: Re: S106 abends after copying into LINKLIST
When building a new system or adding maintenance I go back through all LNK, LPA
and APF libraries making sure they all have at least 20% free space. If for no
other reason getting setup for the next maintenance cycle. When I'm bored,
which is a
The most likely explanations are those that were mentioned:
-- a LNKLST data set did, despite your thought, go into a secondary
extent.
Does the output of the CSV_LNKLST_SPACE health check agree that you
have no secondary extents in LNKLST data sets?
-- a LNKLST data set was compressed
If you
on the RES volume for free
space.
;-D an
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Vernooij, Kees (ITOPT1) - KLM
Sent: Tuesday, October 02, 2018 2:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying int
M-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Ed Jaffe
> Sent: 02 October, 2018 8:33
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S106 abends after copying into LINKLIST
>
> On 10/1/2018 1:34 PM, Jesse 1 Robinson wrote:
> > There are two separate problems here. (1) A link list
On 10/1/2018 1:34 PM, Jesse 1 Robinson wrote:
There are two separate problems here. (1) A link list library taking a new
extent after IPL. (2) An LLA-managed library having contents moved by either
compress or reload.
(1) Can be avoided by simply not defining any secondary extent, i.e. specify
Skip nailed it!
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Jesse 1 Robinson
Sent: Monday, October 1, 2018 3:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST
There are two separate problems here. (1) A link list library
Moral of the story (to the OP).]
Don't update LNKLST until ready for IPL.
BTW, the SAS PDS empty does perform the compress.
When all members have been deleted, the directory is essentially the same as it
would have been for a newly allocated PDS.
HTH
::DISCLAIMER::
-
49602 3-1404
Fax: +55 11 3684-4427
-Mensagem original-
De: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Em nome de
Carmen Vitullo Enviada em: segunda-feira, 1 de outubro de 2018 11:29
Para: IBM-MAIN@LISTSERV.UA.EDU
Assunto: Re: S106 abends after copying into LINKLIST
On Mon, 1 Oct 2018 16:51:26 +, Jesse 1 Robinson wrote:
>What's with these CICS people anyway? ;-) ...
>...
>-- Compressing a PDS moves modules around. The directory is updated
>accordingly, but LLA is not automatically notified. The next fetch for the
>previous location will surely fail
obile
626-543-6132 Office ⇐=== NEW
robin...@sce.com
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Carmen Vitullo
Sent: Monday, October 01, 2018 8:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: S106 abends after copying into LINKLIST
Blake, Daniel J [CTR]
Sent: Monday, October 01, 2018 12:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST
I got that. Just wanted to point out there is a situation where a data set can
have secondary extents even though you did not specify any during the
ober 01, 2018 11:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST
Very interesting conversation. Kind of related, like a third cousin is what I
found:
,SDSF OUTPUT DISPLAY CSV_LNKLST_SPACE LINE 0 COLUMN
, SMS or not, (as long
as an SMS dataclass is not getting me in trouble)
Carmen Vitullo
- Original Message -
From: "Michael Babcock"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, October 1, 2018 10:49:48 AM
Subject: Re: S106 abends after copying into LINKLIST
Secondary spa
an
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Barkow, Eileen
> Sent: Monday, October 01, 2018 10:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S106 abends after copying into LINKLIST
>
>
, October 01, 2018 11:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST
Very interesting conversation. Kind of related, like a third cousin is what I
found:
,SDSF OUTPUT DISPLAY CSV_LNKLST_SPACE LINE 0 COLUMNS
,COMMAND INPUT
It probably includes a compress
> -Original Message-
> From: IBM Mainframe Discussion List On
> Behalf Of Lizette Koehler
> Sent: Monday, October 01, 2018 7:53 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S106 abends after copying into LINKLIST
>
> W
RV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST
Thanks Lizette.
The dataset is was emptied/copied in a different lpar than where it is used.
But as was explained, the pds directory got altered by the empty member
procedure and no LLA REFRESH was done.
-Original Message-
day, October 01, 2018 7:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S106 abends after copying into LINKLIST
>
> Thanks Lizette.
>
> The dataset is was emptied/copied in a different lpar than where it is used.
> But as was explained, the pds directory got altered by th
@LISTSERV.UA.EDU] On Behalf
Of Lizette Koehler
Sent: Monday, October 01, 2018 10:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST
What the Dataset where the modules were staged shared among Plexes or are just
allocated to one Plex (but shared among any members in that
tullo
- Original Message -
From: "Eileen Barkow"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, October 1, 2018 9:33:01 AM
Subject: Re: S106 abends after copying into LINKLIST
The dataset is a standard pds (CICS SDFHLINK).
We used some sort of SAS proc/clists to empty out the
What the Dataset where the modules were staged shared among Plexes or are just
allocated to one Plex (but shared among any members in that Plex)
PDS/E datasets can be very touchy.
Did you find an S213 abends on the libraries prior to the S106?
Check the first module indicated in the first S106.
We did not refresh LLA - looks like we should have.
Thanks everyone.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Jousma, David
Sent: Monday, October 01, 2018 10:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S106 abends after
Did you refresh LLA?
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Barkow, Eileen
Sent: Monday, October 01, 2018 10:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: S106 abends after copying into LINKLIST
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click
Mainframe Discussion List On Behalf Of
Barkow, Eileen
Sent: Monday, October 01, 2018 10:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
The
From: "Eileen Barkow"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, October 1, 2018 9:33:01 AM
Subject: Re: S106 abends after copying into LINKLIST
The dataset is a standard pds (CICS SDFHLINK).
We used some sort of SAS proc/clists to empty out the members before copying
the new ones
.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Massimo Biancucci
Sent: Monday, October 01, 2018 10:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST
Hi,
only to better understand.
Is the loadlib
Faudian slip
concatenation not contamination :)
Carmen Vitullo
- Original Message -
From: "Carmen Vitullo"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, October 1, 2018 9:29:22 AM
Subject: Re: S106 abends after copying into LINKLIST
the only time I've see this prob
the only time I've see this problem is when the library went into extends, the
pds was compressed or LLA was refreshed or updated, I think CICS and IMS may
act differently, so is DFHLOAD in a steplib contamination and link listed?
Carmen Vitullo
- Original Message -
From: "Eileen B
@LISTSERV.UA.EDU] On Behalf
Of ITschak Mugzach
Sent: Monday, October 01, 2018 10:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST
You need to refresh lla.
בתאריך יום ב׳, 1 באוק׳ 2018, 16:10, מאת Barkow, Eileen <
ebar...@doitt.nyc.gov>:
> Hi MVS gurus.
&
Hi,
only to better understand.
Is the loadlib a standard PDS ? Was it compressed ?
Is the loadlib a PDSE ? This could better explain the incident.
Best regards.
Max
Il giorno lun 1 ott 2018 alle ore 16:10 Barkow, Eileen <
ebar...@doitt.nyc.gov> ha scritto:
> Hi MVS gurus.
> Perhaps someone c
Sent: Monday, October 01, 2018 10:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST
You need to refresh lla.
בתאריך יום ב׳, 1 באוק׳ 2018, 16:10, מאת Barkow, Eileen <
ebar...@doitt.nyc.gov>:
> Hi MVS gurus.
> Perhaps someone can offer a plausible
You need to refresh lla.
בתאריך יום ב׳, 1 באוק׳ 2018, 16:10, מאת Barkow, Eileen <
ebar...@doitt.nyc.gov>:
> Hi MVS gurus.
> Perhaps someone can offer a plausible explanation for this, so that
> the MVS group will stop blaming the CICS group for the problem.
>
> Last friday morning we copied new
77 matches
Mail list logo
