S106 abends after copying into LINKLIST

Discussion:

(too old to reply)

Barkow, Eileen

2018-10-01 14:10:15 UTC

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 CICS LINKLIST/LPA modules into the existing LINKLIST/LPA loadlibs
in use (a rather new scenario in use here - we used to use alternative datasets), in anticipation of an IPL to
be done sunday morning.
anyway, around 6pm friday evening, an I/O error occured in linklist and other jobs started abending with S106 abends.
the linklist library was not allocated with secondary extents and there was no LLA refresh issued during
the day. I cannot find anything like this situation occurring on IBMLINK and we have no dump of the original failure.

Does anyone have any idea of what could have caused the I/O error.
both the input and output datasets have a max blksize of 32760.

IEW4009I FETCH FAILED FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- BECAUSE
OF AN I/O ERROR.
IEW4005I FETCH FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- FAILED BECAUSE
IEWFETCH ISSUED RC 0F AND REASON 40
CSV031I LIBRARY ACCESS FAILED FOR MODULE DFHXCPRX, RETURN CODE 24,
REASON CODE 26080021, DDNAME *LNKLST*

________________________________

This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

ITschak Mugzach

2018-10-01 14:19:45 UTC

Permalink

You need to refresh lla.

בתאריך יום ב׳, 1 באוק׳ 2018, 16:10, מאת Barkow, Eileen ‏<

Post by Barkow, Eileen
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 CICS LINKLIST/LPA modules into the
existing LINKLIST/LPA loadlibs
in use (a rather new scenario in use here - we used to use alternative
datasets), in anticipation of an IPL to
be done sunday morning.
anyway, around 6pm friday evening, an I/O error occured in linklist and
other jobs started abending with S106 abends.
the linklist library was not allocated with secondary extents and there
was no LLA refresh issued during
the day. I cannot find anything like this situation occurring on IBMLINK
and we have no dump of the original failure.
Does anyone have any idea of what could have caused the I/O error.
both the input and output datasets have a max blksize of 32760.
IEW4009I FETCH FAILED FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- BECAUSE
OF AN I/O ERROR.
IEW4005I FETCH FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- FAILED BECAUSE
IEWFETCH ISSUED RC 0F AND REASON 40
CSV031I LIBRARY ACCESS FAILED FOR MODULE DFHXCPRX, RETURN CODE 24,
REASON CODE 26080021, DDNAME *LNKLST*
________________________________
This e-mail, including any attachments, may be confidential, privileged or
otherwise legally protected. It is intended only for the addressee. If you
received this e-mail in error or from someone who was not authorized to
send it to you, do not disseminate, copy or otherwise use this e-mail or
its attachments. Please notify the sender immediately by reply e-mail and
delete the e-mail from your system.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

Barkow, Eileen

2018-10-01 14:21:41 UTC

Permalink

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 take effect?

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of ITschak Mugzach
Sent: Monday, October 01, 2018 10:19 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST

You need to refresh lla.

בתאריך יום ב׳, 1 באוק׳ 2018, 16:10, מאת Barkow, Eileen ‏<

Pommier, Rex

2018-10-01 14:24:30 UTC

Permalink

Sounds like somebody compressed the linklist library that contained the modules.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Barkow, Eileen
Sent: Monday, October 01, 2018 9:22 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: [External] 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 take effect?

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of ITschak Mugzach
Sent: Monday, October 01, 2018 10:19 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST

You need to refresh lla.

בתאריך יום ב׳, 1 באוק׳ 2018, 16:10, מאת Barkow, Eileen ‏<

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

Jousma, David

2018-10-01 14:37:24 UTC

Permalink

You should never stage anything to active linklist datasets that you do not want to be placed into use. Your prior method of staging new datasets into the LINKLIST parmlib member to be picked up with IPL would be the proper method.

Is the dataset PDSE?

-----Original Message-----
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> On Behalf Of Barkow, Eileen
Sent: Monday, October 01, 2018 10:22 AM
To: IBM-***@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 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 take effect?

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of ITschak Mugzach
Sent: Monday, October 01, 2018 10:19 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST

You need to refresh lla.

בתאריך יום ב׳, 1 באוק׳ 2018, 16:10, מאת Barkow, Eileen ‏<

Post by Barkow, Eileen
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 CICS LINKLIST/LPA modules into the
existing LINKLIST/LPA loadlibs in use (a rather new scenario in use
here - we used to use alternative datasets), in anticipation of an IPL
to be done sunday morning.
anyway, around 6pm friday evening, an I/O error occured in linklist
and other jobs started abending with S106 abends.
the linklist library was not allocated with secondary extents and
there was no LLA refresh issued during the day. I cannot find anything
like this situation occurring on IBMLINK and we have no dump of the
original failure.
Does anyone have any idea of what could have caused the I/O error.
both the input and output datasets have a max blksize of 32760.
IEW4009I FETCH FAILED FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- BECAUSE
OF AN I/O ERROR.
IEW4005I FETCH FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- FAILED BECAUSE
IEWFETCH ISSUED RC 0F AND REASON 40 CSV031I LIBRARY ACCESS FAILED FOR
MODULE DFHXCPRX, RETURN CODE 24, REASON CODE 26080021, DDNAME *LNKLST*
________________________________
This e-mail, including any attachments, may be confidential,
privileged or otherwise legally protected. It is intended only for the
addressee. If you received this e-mail in error or from someone who
was not authorized to send it to you, do not disseminate, copy or
otherwise use this e-mail or its attachments. Please notify the sender
immediately by reply e-mail and delete the e-mail from your system.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected emails**

This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Seymour J Metz

2018-10-02 15:32:49 UTC

Permalink

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/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Barkow, Eileen <***@DOITT.NYC.GOV>
Sent: Monday, October 1, 2018 10:21 AM
To: IBM-***@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 take effect?

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of ITschak Mugzach
Sent: Monday, October 01, 2018 10:19 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST

You need to refresh lla.

בתאריך יום ב׳, 1 באוק׳ 2018, 16:10, מאת Barkow, Eileen ‏<

Barkow, Eileen

2018-10-02 16:16:26 UTC

Permalink

I was not involved with this strategy and I do not want to point any fingers, but it was developed with the assistance of the MVS group.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz
Sent: Tuesday, October 02, 2018 11:31 AM
To: IBM-***@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/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Barkow, Eileen <***@DOITT.NYC.GOV>
Sent: Monday, October 1, 2018 10:21 AM
To: IBM-***@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 take effect?

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of ITschak Mugzach
Sent: Monday, October 01, 2018 10:19 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST

You need to refresh lla.

בתאריך יום ב׳, 1 באוק׳ 2018, 16:10, מאת Barkow, Eileen ‏<

Massimo Biancucci

2018-10-01 14:22:30 UTC

Permalink

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 <

Barkow, Eileen

2018-10-01 14:33:13 UTC

Permalink

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 in -
I am not sure what this proc does since someone else set it up -
but it does not appear to have compressed the dataset - just emptied out the members.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Massimo Biancucci
Sent: Monday, October 01, 2018 10:22 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST

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 <

Carmen Vitullo

2018-10-01 14:36:25 UTC

Permalink

Well I think that's the problem, the directory for that PDS is rebuild, none of those pointers to the modules are valid, like a compress when ALL members are moved.
if you would have just copied the updated modules you should have been fine

Carmen Vitullo

----- Original Message -----

From: "Eileen Barkow" <***@DOITT.NYC.GOV>
To: IBM-***@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 in -
I am not sure what this proc does since someone else set it up -
but it does not appear to have compressed the dataset - just emptied out the members.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Massimo Biancucci
Sent: Monday, October 01, 2018 10:22 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST

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 <

Barkow, Eileen

2018-10-01 14:45:59 UTC

Permalink

Thank you for the explanation -
The emptying of the pds must have caused the problem.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo
Sent: Monday, October 01, 2018 10:36 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST

Well I think that's the problem, the directory for that PDS is rebuild, none of those pointers to the modules are valid, like a compress when ALL members are moved.
if you would have just copied the updated modules you should have been fine

Carmen Vitullo

----- Original Message -----

From: "Eileen Barkow" <***@DOITT.NYC.GOV>
To: IBM-***@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 in -
I am not sure what this proc does since someone else set it up -
but it does not appear to have compressed the dataset - just emptied out the members.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Massimo Biancucci
Sent: Monday, October 01, 2018 10:22 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST

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 <

Seymour J Metz

2018-10-02 15:38:14 UTC

Permalink

Why bother emptying the members if you're not doing a compress? Also, it sounds like you have installation programs in a system library, which is always cause for concern.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Barkow, Eileen <***@DOITT.NYC.GOV>
Sent: Monday, October 1, 2018 10:33 AM
To: IBM-***@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 the new ones in -
I am not sure what this proc does since someone else set it up -
but it does not appear to have compressed the dataset - just emptied out the members.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Massimo Biancucci
Sent: Monday, October 01, 2018 10:22 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST

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 <

Carmen Vitullo

2018-10-01 14:29:31 UTC

Permalink

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 Barkow" <***@DOITT.NYC.GOV>
To: IBM-***@LISTSERV.UA.EDU
Sent: Monday, October 1, 2018 9:09:58 AM
Subject: S106 abends after copying into LINKLIST

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 CICS LINKLIST/LPA modules into the existing LINKLIST/LPA loadlibs
in use (a rather new scenario in use here - we used to use alternative datasets), in anticipation of an IPL to
be done sunday morning.
anyway, around 6pm friday evening, an I/O error occured in linklist and other jobs started abending with S106 abends.
the linklist library was not allocated with secondary extents and there was no LLA refresh issued during
the day. I cannot find anything like this situation occurring on IBMLINK and we have no dump of the original failure.

Does anyone have any idea of what could have caused the I/O error.
both the input and output datasets have a max blksize of 32760.

IEW4009I FETCH FAILED FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- BECAUSE
OF AN I/O ERROR.
IEW4005I FETCH FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- FAILED BECAUSE
IEWFETCH ISSUED RC 0F AND REASON 40
CSV031I LIBRARY ACCESS FAILED FOR MODULE DFHXCPRX, RETURN CODE 24,
REASON CODE 26080021, DDNAME *LNKLST*

________________________________

This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Carmen Vitullo

2018-10-01 14:30:57 UTC

Permalink

Faudian slip
concatenation not contamination :)

Carmen Vitullo

----- Original Message -----

From: "Carmen Vitullo" <***@HUGHES.NET>
To: IBM-***@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 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 Barkow" <***@DOITT.NYC.GOV>
To: IBM-***@LISTSERV.UA.EDU
Sent: Monday, October 1, 2018 9:09:58 AM
Subject: S106 abends after copying into LINKLIST

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 CICS LINKLIST/LPA modules into the existing LINKLIST/LPA loadlibs
in use (a rather new scenario in use here - we used to use alternative datasets), in anticipation of an IPL to
be done sunday morning.
anyway, around 6pm friday evening, an I/O error occured in linklist and other jobs started abending with S106 abends.
the linklist library was not allocated with secondary extents and there was no LLA refresh issued during
the day. I cannot find anything like this situation occurring on IBMLINK and we have no dump of the original failure.

Does anyone have any idea of what could have caused the I/O error.
both the input and output datasets have a max blksize of 32760.

IEW4009I FETCH FAILED FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- BECAUSE
OF AN I/O ERROR.
IEW4005I FETCH FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- FAILED BECAUSE
IEWFETCH ISSUED RC 0F AND REASON 40
CSV031I LIBRARY ACCESS FAILED FOR MODULE DFHXCPRX, RETURN CODE 24,
REASON CODE 26080021, DDNAME *LNKLST*

________________________________

This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

ITURIEL DO NASCIMENTO NETO

2018-10-01 19:37:49 UTC

Permalink

I agree.
If this loadlib is in linklist, problably an extra extent was created.

During IPL time z/OS builds DEB and it knows exactly how many extentds are defined for linklist datasets,
so if a new one is created, it is not mapped.

To circunvent it you have to compress te library and hopes that all modules return to the known extents of
this specific dataset.
Another suggestion is to dynamically remove the loadlib from linklist and then add it back again.

Atenciosamente / Regards / Saludos

Ituriel do Nascimento Neto
BANCO BRADESCO S.A.
4250 / DITI Engenharia de Software
Sistemas Operacionais Mainframes
Tel: +55 11 3684-9602 R: 49602 3-1404
Fax: +55 11 3684-4427

-----Mensagem original-----
De: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] Em nome de Carmen Vitullo
Enviada em: segunda-feira, 1 de outubro de 2018 11:29
Para: IBM-***@LISTSERV.UA.EDU
Assunto: Re: S106 abends after copying into LINKLIST

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 Barkow" <***@DOITT.NYC.GOV>
To: IBM-***@LISTSERV.UA.EDU
Sent: Monday, October 1, 2018 9:09:58 AM
Subject: S106 abends after copying into LINKLIST

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 CICS LINKLIST/LPA modules into the existing LINKLIST/LPA loadlibs in use (a rather new scenario in use here - we used to use alternative datasets), in anticipation of an IPL to be done sunday morning.
anyway, around 6pm friday evening, an I/O error occured in linklist and other jobs started abending with S106 abends.
the linklist library was not allocated with secondary extents and there was no LLA refresh issued during the day. I cannot find anything like this situation occurring on IBMLINK and we have no dump of the original failure.

Does anyone have any idea of what could have caused the I/O error.
both the input and output datasets have a max blksize of 32760.

IEW4009I FETCH FAILED FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- BECAUSE OF AN I/O ERROR.
IEW4005I FETCH FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- FAILED BECAUSE IEWFETCH ISSUED RC 0F AND REASON 40 CSV031I LIBRARY ACCESS FAILED FOR MODULE DFHXCPRX, RETURN CODE 24, REASON CODE 26080021, DDNAME *LNKLST*

________________________________

This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

AVISO LEGAL <br>...Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação confidencial e/ou legalmente privilegiada. Se você não for destinatário desta mensagem, desde já fica notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. Caso você tenha recebido esta mensagem por engano, pedimos que nos retorne este E-Mail, promovendo, desde logo, a eliminação do seu conteúdo em sua base de dados, registros ou sistema de controle. Fica desprovida de eficácia e validade a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha poderes de representação.
LEGAL ADVICE<br>...This message is exclusively destined for the people to whom it is directed, and it can bear private and/or legally exceptional information. If you are not addressee of this message, since now you are advised to not release, copy, distribute, check or, otherwise, use the information contained in this message, because it is illegal. If you received this message by mistake, we ask you to return this email, making possible, as soon as possible, the elimination of its contents of your database, registrations or controls system. The message that bears any mandatory links, issued by someone who has no representation powers, shall be null or void.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Jousma, David

2018-10-01 14:37:47 UTC

Permalink

Did you refresh LLA?

-----Original Message-----
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> On Behalf Of Barkow, Eileen
Sent: Monday, October 01, 2018 10:10 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: S106 abends after copying into LINKLIST

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected emails**

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 CICS LINKLIST/LPA modules into the existing LINKLIST/LPA loadlibs in use (a rather new scenario in use here - we used to use alternative datasets), in anticipation of an IPL to be done sunday morning.
anyway, around 6pm friday evening, an I/O error occured in linklist and other jobs started abending with S106 abends.
the linklist library was not allocated with secondary extents and there was no LLA refresh issued during the day. I cannot find anything like this situation occurring on IBMLINK and we have no dump of the original failure.

Does anyone have any idea of what could have caused the I/O error.
both the input and output datasets have a max blksize of 32760.

IEW4009I FETCH FAILED FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- BECAUSE OF AN I/O ERROR.
IEW4005I FETCH FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- FAILED BECAUSE IEWFETCH ISSUED RC 0F AND REASON 40 CSV031I LIBRARY ACCESS FAILED FOR MODULE DFHXCPRX, RETURN CODE 24, REASON CODE 26080021, DDNAME *LNKLST*

________________________________

This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected emails**

This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Barkow, Eileen

2018-10-01 14:42:59 UTC

Permalink

We did not refresh LLA - looks like we should have.

Thanks everyone.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Jousma, David
Sent: Monday, October 01, 2018 10:37 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST

Did you refresh LLA?

-----Original Message-----
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> On Behalf Of Barkow, Eileen
Sent: Monday, October 01, 2018 10:10 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: S106 abends after copying into LINKLIST

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected emails**

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 CICS LINKLIST/LPA modules into the existing LINKLIST/LPA loadlibs in use (a rather new scenario in use here - we used to use alternative datasets), in anticipation of an IPL to be done sunday morning.
anyway, around 6pm friday evening, an I/O error occured in linklist and other jobs started abending with S106 abends.
the linklist library was not allocated with secondary extents and there was no LLA refresh issued during the day. I cannot find anything like this situation occurring on IBMLINK and we have no dump of the original failure.

Does anyone have any idea of what could have caused the I/O error.
both the input and output datasets have a max blksize of 32760.

IEW4009I FETCH FAILED FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- BECAUSE OF AN I/O ERROR.
IEW4005I FETCH FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- FAILED BECAUSE IEWFETCH ISSUED RC 0F AND REASON 40 CSV031I LIBRARY ACCESS FAILED FOR MODULE DFHXCPRX, RETURN CODE 24, REASON CODE 26080021, DDNAME *LNKLST*

________________________________

This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected emails**

This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Lizette Koehler

2018-10-01 14:44:57 UTC

Permalink

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. Did it have an I/O errors
when you browse it?

Can you do an IEBCOPY of the PDS to a new one and see if IEBCOPY shows any I/O
Errors

Can you do a IEBPDSE Copy of the PDS/E to a new one and see if there are any I/O
errors?

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ida
u100/pdse.htm

Lizette

Post by Barkow, Eileen
-----Original Message-----
Barkow, Eileen
Sent: Monday, October 01, 2018 7:10 AM
Subject: S106 abends after copying into LINKLIST
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 CICS LINKLIST/LPA modules into the existing
LINKLIST/LPA loadlibs in use (a rather new scenario in use here - we used to
use alternative datasets), in anticipation of an IPL to be done sunday
morning.
anyway, around 6pm friday evening, an I/O error occured in linklist and other
jobs started abending with S106 abends.
the linklist library was not allocated with secondary extents and there was
no LLA refresh issued during the day. I cannot find anything like this
situation occurring on IBMLINK and we have no dump of the original failure.
Does anyone have any idea of what could have caused the I/O error.
both the input and output datasets have a max blksize of 32760.
IEW4009I FETCH FAILED FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- BECAUSE OF AN
I/O ERROR.
IEW4005I FETCH FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- FAILED BECAUSE
IEWFETCH ISSUED RC 0F AND REASON 40 CSV031I LIBRARY ACCESS FAILED FOR MODULE
DFHXCPRX, RETURN CODE 24, REASON CODE 26080021, DDNAME *LNKLST*
________________________________
This e-mail, including any attachments, may be confidential, privileged or
otherwise legally protected. It is intended only for the addressee. If you
received this e-mail in error or from someone who was not authorized to send
it to you, do not disseminate, copy or otherwise use this e-mail or its
attachments. Please notify the sender immediately by reply e-mail and delete
the e-mail from your system.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to

Barkow, Eileen

2018-10-01 14:47:43 UTC

Permalink

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-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler
Sent: Monday, October 01, 2018 10:45 AM
To: IBM-***@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 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. Did it have an I/O errors
when you browse it?

Can you do an IEBCOPY of the PDS to a new one and see if IEBCOPY shows any I/O
Errors

Can you do a IEBPDSE Copy of the PDS/E to a new one and see if there are any I/O
errors?

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ida
u100/pdse.htm

Lizette

Lizette Koehler

2018-10-01 14:53:26 UTC

Permalink

We use a process from the cbttape.org called PDSCLEAN. It can clear out PDS or
PDS/E but same caveats exits. Shut down the task before cleaning the
directories.

Lizette

Post by Barkow, Eileen
-----Original Message-----
Barkow, Eileen
Sent: Monday, October 01, 2018 7:48 AM
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-----
Behalf Of Lizette Koehler
Sent: Monday, October 01, 2018 10:45 AM
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 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. Did it have an I/O
errors when you browse it?
Can you do an IEBCOPY of the PDS to a new one and see if IEBCOPY shows any
I/O Errors
Can you do a IEBPDSE Copy of the PDS/E to a new one and see if there are any
I/O errors?
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.
ida
u100/pdse.htm
Lizette

Post by Barkow, Eileen
-----Original Message-----
Behalf Of Barkow, Eileen
Sent: Monday, October 01, 2018 7:10 AM
Subject: S106 abends after copying into LINKLIST
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 CICS LINKLIST/LPA modules into the
existing LINKLIST/LPA loadlibs in use (a rather new scenario in use
here - we used to use alternative datasets), in anticipation of an IPL
to be done sunday morning.
anyway, around 6pm friday evening, an I/O error occured in linklist
and other jobs started abending with S106 abends.
the linklist library was not allocated with secondary extents and
there was no LLA refresh issued during the day. I cannot find anything
like this situation occurring on IBMLINK and we have no dump of the

original failure.

Post by Barkow, Eileen
Does anyone have any idea of what could have caused the I/O error.
both the input and output datasets have a max blksize of 32760.
IEW4009I FETCH FAILED FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- BECAUSE
OF AN I/O ERROR.
IEW4005I FETCH FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- FAILED BECAUSE
IEWFETCH ISSUED RC 0F AND REASON 40 CSV031I LIBRARY ACCESS FAILED FOR
MODULE DFHXCPRX, RETURN CODE 24, REASON CODE 26080021, DDNAME *LNKLST*
________________________________
This e-mail, including any attachments, may be confidential,
privileged or otherwise legally protected. It is intended only for the
addressee. If you received this e-mail in error or from someone who
was not authorized to send it to you, do not disseminate, copy or
otherwise use this e-mail or its attachments. Please notify the sender
immediately by reply e-mail and delete the e-mail from your system.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to

Gibney, Dave

2018-10-01 15:37:20 UTC

Permalink

It probably includes a compress

Post by Barkow, Eileen
-----Original Message-----
Behalf Of Lizette Koehler
Sent: Monday, October 01, 2018 7:53 AM
Subject: Re: S106 abends after copying into LINKLIST
We use a process from the cbttape.org called PDSCLEAN. It can clear out PDS
or PDS/E but same caveats exits. Shut down the task before cleaning the
directories.
Lizette

Post by Barkow, Eileen
-----Original Message-----
Behalf Of Barkow, Eileen
Sent: Monday, October 01, 2018 7:48 AM
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-----
From: IBM Mainframe Discussion List [mailto:IBM-
On Behalf Of Lizette Koehler
Sent: Monday, October 01, 2018 10:45 AM
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
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. Did it have an
I/O errors when you browse it?
Can you do an IEBCOPY of the PDS to a new one and see if IEBCOPY shows
any I/O Errors
Can you do a IEBPDSE Copy of the PDS/E to a new one and see if there
are any I/O errors?
https://urldefense.proofpoint.com/v2/url?u=https-

3A__www.ibm.com_support_knowledgecenter_en_SSLTBW-
5F2.1.0_com.ibm.zos.v2r1&d=DwICAg&c=C3yme8gMkxg_ihJNXS06ZyWk4EJ
m8LdrrvxQb-
Je7sw&r=u9g8rUevBoyCPAdo5sWE9w&m=SSH0jhO6X7PmFrTFoUlzrgHfxMh
w78-yYm11eiLkzS8&s=Q2WQ12FSAwlkrSDKWIWKwTcy4-
1tlVJA0mEoO2gowpY&e=.

Post by Barkow, Eileen
ida
u100/pdse.htm
Lizette

Post by Barkow, Eileen
-----Original Message-----

Post by Barkow, Eileen

Post by Barkow, Eileen
Behalf Of Barkow, Eileen
Sent: Monday, October 01, 2018 7:10 AM
Subject: S106 abends after copying into LINKLIST
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 CICS LINKLIST/LPA modules into the
existing LINKLIST/LPA loadlibs in use (a rather new scenario in use
here - we used to use alternative datasets), in anticipation of an
IPL to be done sunday morning.
anyway, around 6pm friday evening, an I/O error occured in linklist
and other jobs started abending with S106 abends.
the linklist library was not allocated with secondary extents and
there was no LLA refresh issued during the day. I cannot find
anything like this situation occurring on IBMLINK and we have no
dump of the

original failure.

LNKLST-

Post by Barkow, Eileen

Post by Barkow, Eileen
BECAUSE OF AN I/O ERROR.
IEW4005I FETCH FOR MODULE DFHXCPRX FROM DDNAME -LNKLST-

FAILED

Post by Barkow, Eileen

Post by Barkow, Eileen
BECAUSE IEWFETCH ISSUED RC 0F AND REASON 40 CSV031I LIBRARY

ACCESS

Post by Barkow, Eileen

Post by Barkow, Eileen
FAILED FOR MODULE DFHXCPRX, RETURN CODE 24, REASON CODE

26080021,

Post by Barkow, Eileen

Post by Barkow, Eileen
DDNAME *LNKLST*
________________________________
This e-mail, including any attachments, may be confidential,
privileged or otherwise legally protected. It is intended only for
the addressee. If you received this e-mail in error or from someone
who was not authorized to send it to you, do not disseminate, copy
or otherwise use this e-mail or its attachments. Please notify the
sender immediately by reply e-mail and delete the e-mail from your

system.

Post by Barkow, Eileen

Post by Barkow, Eileen
--------------------------------------------------------------------
-- For IBM-MAIN subscribe / signoff / archive access instructions,

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to

Blake, Daniel J [CTR]

2018-10-01 15:33:33 UTC

Permalink

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 ===>, ,SCROLL ==
********************************* TOP OF DATA **************************
CHECK(IBMCSV,CSV_LNKLST_SPACE)
SYSPLEX: XXXX SYSTEM: YYYY
START TIME: 10/01/2018 02:11:10.736219
CHECK DATE: 20050720 CHECK SEVERITY: LOW

CSVH0983I None of the data sets in LNKLST set LNKLST00 were allocated
with secondary space defined.

END TIME: 10/01/2018 02:11:11.449077 STATUS: SUCCESSFUL

Looks great right? Unless you allocated a data set on a volume that does not have enough contiguous space. I that case you get this:

SDSF LNK DISPLAY SYS1 SYS1 EXT 92 LINE 1-37 (91)
COMMAND INPUT ===>, ,SCROLL ===>,CSR ,
PREFIX=* DEST=(ALL) OWNER=* SORT=EXTENT/D SYSNAME=
NP DSNAME Seq VolSer BlkSize Extent SMS APF LRecL
SYS2.BMC.DB2BMCLINK 66 ISVM06 23476 2 NO YES 0 PO
SYS2.GENER.LOAD 1 ISVM06 32760 1 NO NO 0 PO

Dan

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Barkow, Eileen
Sent: Monday, October 01, 2018 10:48 AM
To: IBM-***@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 the empty member procedure and no LLA REFRESH was done.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler
Sent: Monday, October 01, 2018 10:45 AM
To: IBM-***@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 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. Did it have an I/O errors
when you browse it?

Can you do an IEBCOPY of the PDS to a new one and see if IEBCOPY shows any I/O
Errors

Can you do a IEBPDSE Copy of the PDS/E to a new one and see if there are any I/O
errors?

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ida
u100/pdse.htm

Lizette

Barkow, Eileen

2018-10-01 15:37:43 UTC

Permalink

The dataset allocation stayed the same. It was the emptying out of members and compressing that caused the problem.
Thanks for the response.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Blake, Daniel J [CTR]
Sent: Monday, October 01, 2018 11:23 AM
To: IBM-***@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 ===>, ,SCROLL ==
********************************* TOP OF DATA **************************
CHECK(IBMCSV,CSV_LNKLST_SPACE)
SYSPLEX: XXXX SYSTEM: YYYY
START TIME: 10/01/2018 02:11:10.736219
CHECK DATE: 20050720 CHECK SEVERITY: LOW

CSVH0983I None of the data sets in LNKLST set LNKLST00 were allocated
with secondary space defined.

END TIME: 10/01/2018 02:11:11.449077 STATUS: SUCCESSFUL

Looks great right? Unless you allocated a data set on a volume that does not have enough contiguous space. I that case you get this:

SDSF LNK DISPLAY SYS1 SYS1 EXT 92 LINE 1-37 (91)
COMMAND INPUT ===>, ,SCROLL ===>,CSR ,
PREFIX=* DEST=(ALL) OWNER=* SORT=EXTENT/D SYSNAME=
NP DSNAME Seq VolSer BlkSize Extent SMS APF LRecL
SYS2.BMC.DB2BMCLINK 66 ISVM06 23476 2 NO YES 0 PO
SYS2.GENER.LOAD 1 ISVM06 32760 1 NO NO 0 PO

Dan

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Barkow, Eileen
Sent: Monday, October 01, 2018 10:48 AM
To: IBM-***@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 the empty member procedure and no LLA REFRESH was done.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler
Sent: Monday, October 01, 2018 10:45 AM
To: IBM-***@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 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. Did it have an I/O errors
when you browse it?

Can you do an IEBCOPY of the PDS to a new one and see if IEBCOPY shows any I/O
Errors

Can you do a IEBPDSE Copy of the PDS/E to a new one and see if there are any I/O
errors?

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ida
u100/pdse.htm

Lizette

Blake, Daniel J [CTR]

2018-10-01 16:17:47 UTC

Permalink

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 allocation.

Dan

________________________________
On: 01 October 2018 12:11,
"Barkow, Eileen" <***@DOITT.NYC.GOV<mailto:***@DOITT.NYC.GOV>> wrote:

The dataset allocation stayed the same. It was the emptying out of members and compressing that caused the problem.
Thanks for the response.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Blake, Daniel J [CTR]
Sent: Monday, October 01, 2018 11:23 AM
To: IBM-***@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 ===>, ,SCROLL ==
********************************* TOP OF DATA **************************
CHECK(IBMCSV,CSV_LNKLST_SPACE)
SYSPLEX: XXXX SYSTEM: YYYY
START TIME: 10/01/2018 02:11:10.736219
CHECK DATE: 20050720 CHECK SEVERITY: LOW

CSVH0983I None of the data sets in LNKLST set LNKLST00 were allocated
with secondary space defined.

END TIME: 10/01/2018 02:11:11.449077 STATUS: SUCCESSFUL

Looks great right? Unless you allocated a data set on a volume that does not have enough contiguous space. I that case you get this:

SDSF LNK DISPLAY SYS1 SYS1 EXT 92 LINE 1-37 (91)
COMMAND INPUT ===>, ,SCROLL ===>,CSR ,
PREFIX=* DEST=(ALL) OWNER=* SORT=EXTENT/D SYSNAME=
NP DSNAME Seq VolSer BlkSize Extent SMS APF LRecL
SYS2.BMC.DB2BMCLINK 66 ISVM06 23476 2 NO YES 0 PO
SYS2.GENER.LOAD 1 ISVM06 32760 1 NO NO 0 PO

Dan

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Barkow, Eileen
Sent: Monday, October 01, 2018 10:48 AM
To: IBM-***@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 the empty member procedure and no LLA REFRESH was done.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler
Sent: Monday, October 01, 2018 10:45 AM
To: IBM-***@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 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. Did it have an I/O errors
when you browse it?

Can you do an IEBCOPY of the PDS to a new one and see if IEBCOPY shows any I/O
Errors

Can you do a IEBPDSE Copy of the PDS/E to a new one and see if there are any I/O
errors?

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ida
u100/pdse.htm

Lizette

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Barkow, Eileen

2018-10-01 16:27:19 UTC

Permalink

I thought that the system would take up to 5 extents if there Is not enough contiguous space when the dataset is allocated.
But not on an existing dataset which is already allocated.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Blake, Daniel J [CTR]
Sent: Monday, October 01, 2018 12:16 PM
To: IBM-***@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 allocation.

Dan

________________________________
On: 01 October 2018 12:11,
"Barkow, Eileen" <***@DOITT.NYC.GOV<mailto:***@DOITT.NYC.GOV>> wrote:

The dataset allocation stayed the same. It was the emptying out of members and compressing that caused the problem.
Thanks for the response.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Blake, Daniel J [CTR]
Sent: Monday, October 01, 2018 11:23 AM
To: IBM-***@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 ===>, ,SCROLL ==
********************************* TOP OF DATA **************************
CHECK(IBMCSV,CSV_LNKLST_SPACE)
SYSPLEX: XXXX SYSTEM: YYYY
START TIME: 10/01/2018 02:11:10.736219
CHECK DATE: 20050720 CHECK SEVERITY: LOW

CSVH0983I None of the data sets in LNKLST set LNKLST00 were allocated
with secondary space defined.

END TIME: 10/01/2018 02:11:11.449077 STATUS: SUCCESSFUL

Looks great right? Unless you allocated a data set on a volume that does not have enough contiguous space. I that case you get this:

SDSF LNK DISPLAY SYS1 SYS1 EXT 92 LINE 1-37 (91)
COMMAND INPUT ===>, ,SCROLL ===>,CSR ,
PREFIX=* DEST=(ALL) OWNER=* SORT=EXTENT/D SYSNAME=
NP DSNAME Seq VolSer BlkSize Extent SMS APF LRecL
SYS2.BMC.DB2BMCLINK 66 ISVM06 23476 2 NO YES 0 PO
SYS2.GENER.LOAD 1 ISVM06 32760 1 NO NO 0 PO

Dan

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Barkow, Eileen
Sent: Monday, October 01, 2018 10:48 AM
To: IBM-***@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 the empty member procedure and no LLA REFRESH was done.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler
Sent: Monday, October 01, 2018 10:45 AM
To: IBM-***@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 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. Did it have an I/O errors
when you browse it?

Can you do an IEBCOPY of the PDS to a new one and see if IEBCOPY shows any I/O
Errors

Can you do a IEBPDSE Copy of the PDS/E to a new one and see if there are any I/O
errors?

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ida
u100/pdse.htm

Lizette

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Michael Babcock

2018-10-01 15:50:08 UTC

Permalink

Secondary space and multiple extents are really two different things.
Initial primary space for a PDS can be allocated in up 5 extents (SMS may
change that though).

Secondary space (if defined) may add additional extents.

On Mon, Oct 1, 2018 at 10:33 AM Blake, Daniel J [CTR] <

Post by Blake, Daniel J [CTR]
,SDSF OUTPUT DISPLAY CSV_LNKLST_SPACE LINE 0 COLUMNS
,COMMAND INPUT ===>, ,SCROLL ==
********************************* TOP OF DATA **************************
CHECK(IBMCSV,CSV_LNKLST_SPACE)
SYSPLEX: XXXX SYSTEM: YYYY
START TIME: 10/01/2018 02:11:10.736219
CHECK DATE: 20050720 CHECK SEVERITY: LOW
CSVH0983I None of the data sets in LNKLST set LNKLST00 were allocated
with secondary space defined.
END TIME: 10/01/2018 02:11:11.449077 STATUS: SUCCESSFUL
Looks great right? Unless you allocated a data set on a volume that does
SDSF LNK DISPLAY SYS1 SYS1 EXT 92 LINE 1-37 (91)
COMMAND INPUT ===>, ,SCROLL ===>,CSR ,
PREFIX=* DEST=(ALL) OWNER=* SORT=EXTENT/D SYSNAME=
NP DSNAME Seq VolSer
BlkSize Extent SMS APF LRecL
SYS2.BMC.DB2BMCLINK 66 ISVM06 23476
2 NO YES 0 PO
SYS2.GENER.LOAD 1 ISVM06
32760 1 NO NO 0 PO
Dan
-----Original Message-----
Behalf Of Barkow, Eileen
Sent: Monday, October 01, 2018 10:48 AM
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-----
Behalf Of Lizette Koehler
Sent: Monday, October 01, 2018 10:45 AM
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 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. Did it have an I/O errors
when you browse it?
Can you do an IEBCOPY of the PDS to a new one and see if IEBCOPY shows any I/O
Errors
Can you do a IEBPDSE Copy of the PDS/E to a new one and see if there are any I/O
errors?
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ida
u100/pdse.htm
<https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.idau100/pdse.htm>
Lizette

Post by Barkow, Eileen
-----Original Message-----

Behalf Of

Post by Barkow, Eileen
Barkow, Eileen
Sent: Monday, October 01, 2018 7:10 AM
Subject: S106 abends after copying into LINKLIST
Hi MVS gurus.
Perhaps someone can offer a plausible explanation for this, so that the

MVS

Post by Barkow, Eileen
group will stop blaming the CICS group for the problem.
Last friday morning we copied new CICS LINKLIST/LPA modules into the

existing

Post by Barkow, Eileen
LINKLIST/LPA loadlibs in use (a rather new scenario in use here - we

used to

Post by Barkow, Eileen
use alternative datasets), in anticipation of an IPL to be done sunday
morning.
anyway, around 6pm friday evening, an I/O error occured in linklist and

other

Post by Barkow, Eileen
jobs started abending with S106 abends.
the linklist library was not allocated with secondary extents and there

was

Post by Barkow, Eileen
no LLA refresh issued during the day. I cannot find anything like this
situation occurring on IBMLINK and we have no dump of the original

failure.

OF AN

Post by Barkow, Eileen
I/O ERROR.
IEW4005I FETCH FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- FAILED BECAUSE
IEWFETCH ISSUED RC 0F AND REASON 40 CSV031I LIBRARY ACCESS FAILED FOR

MODULE

Post by Barkow, Eileen
DFHXCPRX, RETURN CODE 24, REASON CODE 26080021, DDNAME *LNKLST*
________________________________
This e-mail, including any attachments, may be confidential, privileged

Post by Barkow, Eileen
otherwise legally protected. It is intended only for the addressee. If

you

Post by Barkow, Eileen
received this e-mail in error or from someone who was not authorized to

send

Post by Barkow, Eileen
it to you, do not disseminate, copy or otherwise use this e-mail or its
attachments. Please notify the sender immediately by reply e-mail and

delete

Post by Barkow, Eileen
the e-mail from your system.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send

email to
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

Carmen Vitullo

2018-10-01 15:55:54 UTC

Permalink

There's the key, in the allocation, if I allocate space for a linklist library I DO NOT specify any secondary allocation, zero zilch! a secondary extend can be taken to get my primary space if needed, but my PDS cannot get another extend due to my initial allocation of 100,0 for example , SMS or not, (as long as an SMS dataclass is not getting me in trouble)

Carmen Vitullo

----- Original Message -----

From: "Michael Babcock" <***@GMAIL.COM>
To: IBM-***@LISTSERV.UA.EDU
Sent: Monday, October 1, 2018 10:49:48 AM
Subject: Re: S106 abends after copying into LINKLIST

Secondary space and multiple extents are really two different things.
Initial primary space for a PDS can be allocated in up 5 extents (SMS may
change that though).

Secondary space (if defined) may add additional extents.

On Mon, Oct 1, 2018 at 10:33 AM Blake, Daniel J [CTR] <

Post by Barkow, Eileen
-----Original Message-----

Behalf Of

MVS

Post by Barkow, Eileen
group will stop blaming the CICS group for the problem.
Last friday morning we copied new CICS LINKLIST/LPA modules into the

existing

Post by Barkow, Eileen
LINKLIST/LPA loadlibs in use (a rather new scenario in use here - we

used to

Post by Barkow, Eileen
use alternative datasets), in anticipation of an IPL to be done sunday
morning.
anyway, around 6pm friday evening, an I/O error occured in linklist and

other

Post by Barkow, Eileen
jobs started abending with S106 abends.
the linklist library was not allocated with secondary extents and there

was

Post by Barkow, Eileen
no LLA refresh issued during the day. I cannot find anything like this
situation occurring on IBMLINK and we have no dump of the original

failure.

OF AN

Post by Barkow, Eileen
I/O ERROR.
IEW4005I FETCH FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- FAILED BECAUSE
IEWFETCH ISSUED RC 0F AND REASON 40 CSV031I LIBRARY ACCESS FAILED FOR

MODULE

Post by Barkow, Eileen
DFHXCPRX, RETURN CODE 24, REASON CODE 26080021, DDNAME *LNKLST*
________________________________
This e-mail, including any attachments, may be confidential, privileged

Post by Barkow, Eileen
otherwise legally protected. It is intended only for the addressee. If

you

Post by Barkow, Eileen
received this e-mail in error or from someone who was not authorized to

send

Post by Barkow, Eileen
it to you, do not disseminate, copy or otherwise use this e-mail or its
attachments. Please notify the sender immediately by reply e-mail and

delete

Post by Barkow, Eileen
the e-mail from your system.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send

Seymour J Metz

2018-10-02 15:34:54 UTC

Permalink

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.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Carmen Vitullo <***@HUGHES.NET>
Sent: Monday, October 1, 2018 11:55 AM
To: IBM-***@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, zero zilch! a secondary extend can be taken to get my primary space if needed, but my PDS cannot get another extend due to my initial allocation of 100,0 for example , SMS or not, (as long as an SMS dataclass is not getting me in trouble)

Carmen Vitullo

----- Original Message -----

From: "Michael Babcock" <***@GMAIL.COM>
To: IBM-***@LISTSERV.UA.EDU
Sent: Monday, October 1, 2018 10:49:48 AM
Subject: Re: S106 abends after copying into LINKLIST

Secondary space and multiple extents are really two different things.
Initial primary space for a PDS can be allocated in up 5 extents (SMS may
change that though).

Secondary space (if defined) may add additional extents.

On Mon, Oct 1, 2018 at 10:33 AM Blake, Daniel J [CTR] <

Very interesting conversation. Kind of related, like a third cousin is
,SDSF OUTPUT DISPLAY CSV_LNKLST_SPACE LINE 0 COLUMNS
,COMMAND INPUT ===>, ,SCROLL ==
********************************* TOP OF DATA **************************
CHECK(IBMCSV,CSV_LNKLST_SPACE)
SYSPLEX: XXXX SYSTEM: YYYY
START TIME: 10/01/2018 02:11:10.736219
CHECK DATE: 20050720 CHECK SEVERITY: LOW
CSVH0983I None of the data sets in LNKLST set LNKLST00 were allocated
with secondary space defined.
END TIME: 10/01/2018 02:11:11.449077 STATUS: SUCCESSFUL
Looks great right? Unless you allocated a data set on a volume that does
SDSF LNK DISPLAY SYS1 SYS1 EXT 92 LINE 1-37 (91)
COMMAND INPUT ===>, ,SCROLL
===>,CSR ,
PREFIX=* DEST=(ALL) OWNER=* SORT=EXTENT/D SYSNAME=
NP DSNAME Seq VolSer
BlkSize Extent SMS APF LRecL
SYS2.BMC.DB2BMCLINK 66 ISVM06 23476
2 NO YES 0 PO
SYS2.GENER.LOAD 1 ISVM06
32760 1 NO NO 0 PO
Dan
-----Original Message-----
Behalf Of Barkow, Eileen
Sent: Monday, October 01, 2018 10:48 AM
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-----
Behalf Of Lizette Koehler
Sent: Monday, October 01, 2018 10:45 AM
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 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. Did it have an I/O
errors
when you browse it?
Can you do an IEBCOPY of the PDS to a new one and see if IEBCOPY shows any
I/O
Errors
Can you do a IEBPDSE Copy of the PDS/E to a new one and see if there are
any I/O
errors?
https://secure-web.cisco.com/1wgF6g5gRw23P6g1rdufxDSxXTAzKlL0zoyYXNAXE-gwoYq_AybtuEaBCljakDCmPFvyAb1i2KnxT9z3jkF1ocSdsIAwFtCAjB6aTZ3-DLC3_88ZHo3zbLSd2NHWiqgYMrQTNRd__VJZ5rP8SYeuNPzGtkeQJ3KCWls9a3HFD6WXkk671HhMz6gLolqQEMrHD_NxNnwH1d6amRJa-dRDFawLh3zmjLH-XAM-zGisRXFvVKzC2wMIxLdL3slwBOWpydR9aR1yA2cSmJirLYaAZ5AeUliYkLOVeT_IZZzv51UqZo9lX8oa_8ZU43oD5MgpXAjnd1YVyTYwctDN4i9HjwavUw9myijsC6_bQn35rBHsAAQpkXYwrF8c2dLGp-nRWB_vF3syaiLC9-F-5HDCYDKhIXjQtk9fgKjOJmGiuMAIWc3Vk904gpbvCb7KQhaGj/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.1.0%2Fcom.ibm.zos.v2r1.ida
u100/pdse.htm
<https://secure-web.cisco.com/1TGLnmuaQEcCNLV_1kvbFkYGgldnXMlBUZdXwSxV_ggiGyl0qAwGHCGlYJC3FiuO5ihiiEbcXkl3vp2RMTxjGs-6MCVx-zCqLlQ8fare5V4iSRNvwAzm2OZkZJzLOUNwSZAVvRr4RjiEmkUPN8Hz_y7VWb5hceVkfBy1iqQmD0nZpK23i9gEBXj7ywZCdhcrA9H1HQpgqPgLr13zODrxLXepSru36h0Rv4Lgyuu5QDeEL03XAiOqs662BpLOEHgvlNX6-L8oU59dsfSCCMBucmTzJwYxEl3ivVIkDcFGJ_YlyJWwgeywPmNYPofExDuR7pk9xT-VtQn56lyM3NUne05Glp3ExAyC4-H9hEqKMVTx6r_7yc_e9njaDXOpJgrps_KQ8DpRQhNwB8jYpUyN8DzUe34Apm23kPEV8bjg8cBZNLxgTG35QMzch2ipRT_9L/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.1.0%2Fcom.ibm.zos.v2r1.idau100%2Fpdse.htm>
Lizette

Post by Barkow, Eileen
-----Original Message-----

Behalf Of

MVS

Post by Barkow, Eileen
group will stop blaming the CICS group for the problem.
Last friday morning we copied new CICS LINKLIST/LPA modules into the

existing

Post by Barkow, Eileen
LINKLIST/LPA loadlibs in use (a rather new scenario in use here - we

used to

Post by Barkow, Eileen
use alternative datasets), in anticipation of an IPL to be done sunday
morning.
anyway, around 6pm friday evening, an I/O error occured in linklist and

other

Post by Barkow, Eileen
jobs started abending with S106 abends.
the linklist library was not allocated with secondary extents and there

was

Post by Barkow, Eileen
no LLA refresh issued during the day. I cannot find anything like this
situation occurring on IBMLINK and we have no dump of the original

failure.

OF AN

Post by Barkow, Eileen
I/O ERROR.
IEW4005I FETCH FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- FAILED BECAUSE
IEWFETCH ISSUED RC 0F AND REASON 40 CSV031I LIBRARY ACCESS FAILED FOR

MODULE

Post by Barkow, Eileen
DFHXCPRX, RETURN CODE 24, REASON CODE 26080021, DDNAME *LNKLST*
________________________________
This e-mail, including any attachments, may be confidential, privileged

Post by Barkow, Eileen
otherwise legally protected. It is intended only for the addressee. If

you

Post by Barkow, Eileen
received this e-mail in error or from someone who was not authorized to

send

Post by Barkow, Eileen
it to you, do not disseminate, copy or otherwise use this e-mail or its
attachments. Please notify the sender immediately by reply e-mail and

delete

Post by Barkow, Eileen
the e-mail from your system.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send

r***@gmail.com

2018-10-01 16:25:30 UTC

Permalink

"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 allocation."

Perhaps better said as "A data set can exist in nmultiple extents even though you did not specify a secondary allocation quantity."

Jesse 1 Robinson

2018-10-01 16:51:39 UTC

Permalink

What's with these CICS people anyway? ;-) I have had the same issue with CICS folks here since I walked in the door in the mid-1990s. They have always--still!--updated their key load lib(s) in the same way. My protestations that the procedure is wrong carries little weight against their decades-long history of 'success'. My argument is that their practice works ONLY because they customarily employ it immediately before an IPL. So what I try to tell them...

The function of LLA is to read all linklist library directories and 'memorize' the TTRs (internal location) of all members. LLA saves a huge amount of later directory I/O during the life of an IPL because a module does not have to be located every time it's fetched. LLA knows where a module lives--library and exact spot within than library--so it can read directly from the physical track(s) on the physical device. If the physical location of a module changes, LLA will direct I/O to the wrong spot, hence S106.

What causes LLA to go wrong?

-- 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.

-- Emptying and refilling a load library has the same effect. While the directory is updated for each module's actual location, LLA will not know. The next fetch will surely fail.

In general, in order to get away with dynamic updates, refresh LLA or recycle LLA altogether. As long as the library's extent map has not changed, the result is more or less equivalent to IPL. If an IPL follows a dynamic update immediately--our CICS guys typically perform their updates after the regions have been shut down--the problems outlined above are dodged.

Note that LLA has not been around forever. Before LLA was introduced, modules had to be located on every fetch. Highly inefficient, but S106 was rare(r).

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
***@sce.com

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo
Sent: Monday, October 01, 2018 8:56 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):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, zero zilch! a secondary extend can be taken to get my primary space if needed, but my PDS cannot get another extend due to my initial allocation of 100,0 for example , SMS or not, (as long as an SMS dataclass is not getting me in trouble)

Carmen Vitullo

----- Original Message -----

From: "Michael Babcock" <***@GMAIL.COM>
To: IBM-***@LISTSERV.UA.EDU
Sent: Monday, October 1, 2018 10:49:48 AM
Subject: Re: S106 abends after copying into LINKLIST

Secondary space and multiple extents are really two different things.
Initial primary space for a PDS can be allocated in up 5 extents (SMS may change that though).

Secondary space (if defined) may add additional extents.

Post by Barkow, Eileen
-----Original Message-----

Behalf Of

MVS

Post by Barkow, Eileen
group will stop blaming the CICS group for the problem.
Last friday morning we copied new CICS LINKLIST/LPA modules into the

existing

Post by Barkow, Eileen
LINKLIST/LPA loadlibs in use (a rather new scenario in use here - we

used to

Post by Barkow, Eileen
use alternative datasets), in anticipation of an IPL to be done
sunday morning.
anyway, around 6pm friday evening, an I/O error occured in linklist
and

other

Post by Barkow, Eileen
jobs started abending with S106 abends.
the linklist library was not allocated with secondary extents and
there

was

Post by Barkow, Eileen
no LLA refresh issued during the day. I cannot find anything like
this situation occurring on IBMLINK and we have no dump of the
original

failure.

OF AN

Post by Barkow, Eileen
I/O ERROR.
IEW4005I FETCH FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- FAILED
BECAUSE IEWFETCH ISSUED RC 0F AND REASON 40 CSV031I LIBRARY ACCESS
FAILED FOR

MODULE

Post by Barkow, Eileen
DFHXCPRX, RETURN CODE 24, REASON CODE 26080021, DDNAME *LNKLST*

Paul Gilmartin

2018-10-01 18:58:45 UTC

Permalink

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.

Appears like a misdesign to me.

Note that LLA has not been around forever. Before LLA was introduced, modules had to be located on every fetch. Highly inefficient, but S106 was rare(r).

Happy October! I wonder whether there will be any other thread topics this month.

Couldn't IBM fix this by providing a tool to update link libraries safely?
o Update library
o Update LLA in a single command
o Lock out searches meanwhile.

Of course:
o "[T]hese CICS people" would bypass it somehow.
o No good if a programmer fetches TTR and continues to use it for days afterward.

Does PDSE flavor of LUW encapsulation immunize against this by maintaining the
validity of the TTR until STOW DISCONNECT?

But some linklist catenands are not PDSE-eligible.

And any fix is likely to introduce (some of) the overhead that LLA is designed to avoid.
I once had a script that refreshed LLA whenever I added a member. (We were a lab shop.)
Admins made me stop that.

(I haven't read the entire thread.)

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Jesse 1 Robinson

2018-10-01 20:34:47 UTC

Permalink

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. specifying a secondary of zero. Getting more than one extent to satisfy the original allocation is not a problem as long as no additional extent is allowed afterward. If a new extent is truly needed to hold enlarged content, then link list update can be used.

(2) Seems to be OP's issue. LLA REFRESH can handle the consequences of dynamic update within the original (IPL time) extent(s). Note that REFRESH is needed on all sharing systems.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
***@sce.com

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of ITURIEL DO NASCIMENTO NETO
Sent: Monday, October 01, 2018 12:37 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):RES: S106 abends after copying into LINKLIST

I agree.
If this loadlib is in linklist, problably an extra extent was created.

During IPL time z/OS builds DEB and it knows exactly how many extentds are defined for linklist datasets, so if a new one is created, it is not mapped.

To circunvent it you have to compress te library and hopes that all modules return to the known extents of this specific dataset.
Another suggestion is to dynamically remove the loadlib from linklist and then add it back again.

Atenciosamente / Regards / Saludos

Ituriel do Nascimento Neto
BANCO BRADESCO S.A.
4250 / DITI Engenharia de Software
Sistemas Operacionais Mainframes
Tel: +55 11 3684-9602 R: 49602 3-1404
Fax: +55 11 3684-4427

-----Mensagem original-----
De: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] Em nome de Carmen Vitullo Enviada em: segunda-feira, 1 de outubro de 2018 11:29
Para: IBM-***@LISTSERV.UA.EDU
Assunto: Re: S106 abends after copying into LINKLIST

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 Barkow" <***@DOITT.NYC.GOV>
To: IBM-***@LISTSERV.UA.EDU
Sent: Monday, October 1, 2018 9:09:58 AM
Subject: S106 abends after copying into LINKLIST

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 CICS LINKLIST/LPA modules into the existing LINKLIST/LPA loadlibs in use (a rather new scenario in use here - we used to use alternative datasets), in anticipation of an IPL to be done sunday morning.
anyway, around 6pm friday evening, an I/O error occured in linklist and other jobs started abending with S106 abends.
the linklist library was not allocated with secondary extents and there was no LLA refresh issued during the day. I cannot find anything like this situation occurring on IBMLINK and we have no dump of the original failure.

Does anyone have any idea of what could have caused the I/O error.
both the input and output datasets have a max blksize of 32760.

IEW4009I FETCH FAILED FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- BECAUSE OF AN I/O ERROR.
IEW4005I FETCH FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- FAILED BECAUSE IEWFETCH ISSUED RC 0F AND REASON 40 CSV031I LIBRARY ACCESS FAILED FOR MODULE DFHXCPRX, RETURN CODE 24, REASON CODE 26080021, DDNAME *LNKLST*

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Ed Jaffe

2018-10-02 06:33:35 UTC

Permalink

Post by Jesse 1 Robinson
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. specifying a secondary of zero. Getting more than one extent to satisfy the original allocation is not a problem as long as no additional extent is allowed afterward. If a new extent is truly needed to hold enlarged content, then link list update can be used.
(2) Seems to be OP's issue. LLA REFRESH can handle the consequences of dynamic update within the original (IPL time) extent(s). Note that REFRESH is needed on all sharing systems.

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!

I would much rather take a new extent for one relinked module than risk corrupting the *ENTIRE LIBRARY* with a "live" compress using DISP=SHR. Of course, periodic compress of LNKLST PDS libraries is not a bad idea when done under controlled circumstances: i.e., "quiet" time and LLA on all sharing systems has been shut DOWN. Also, I like to STEPLIB any IEBCOPY job to a recent *copy* of SYS1.LINKLIB to ensure IEBCOPY program parts are not moved during the compress... BTDTGTS!!
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/

--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Vernooij, Kees - KLM , ITOPT1

2018-10-02 06:40:56 UTC

Permalink

You can also avoid both by allocating it large enough: calculate what you need during the life of the IPL, double, triple or whatever it and you can sleep quietly. What do a few 1000 cyls cost these days?

Kees.

Post by Barkow, Eileen
-----Original Message-----
Behalf Of Ed Jaffe
Sent: 02 October, 2018 8:33
Subject: Re: S106 abends after copying into LINKLIST

Post by Jesse 1 Robinson
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.

Post by Jesse 1 Robinson
(1) Can be avoided by simply not defining any secondary extent, i.e.

specifying a secondary of zero. Getting more than one extent to satisfy
the original allocation is not a problem as long as no additional extent
is allowed afterward. If a new extent is truly needed to hold enlarged
content, then link list update can be used.

Post by Jesse 1 Robinson
(2) Seems to be OP's issue. LLA REFRESH can handle the consequences of

dynamic update within the original (IPL time) extent(s). Note that
REFRESH is needed on all sharing systems.
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!
I would much rather take a new extent for one relinked module than risk
corrupting the *ENTIRE LIBRARY* with a "live" compress using DISP=SHR.
Of course, periodic compress of LNKLST PDS libraries is not a bad idea
when done under controlled circumstances: i.e., "quiet" time and LLA on
all sharing systems has been shut DOWN. Also, I like to STEPLIB any
IEBCOPY job to a recent *copy* of SYS1.LINKLIB to ensure IEBCOPY program
parts are not moved during the compress... BTDTGTS!!
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/
------------------------------------------------------------------------
--------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination,
distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

********************************************************
For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
********************************************************

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Blake, Daniel J [CTR]

2018-10-02 10:55:56 UTC

Permalink

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 almost never, I'll check every data set on the RES volume for free space.

;-D an

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Vernooij, Kees (ITOPT1) - KLM
Sent: Tuesday, October 02, 2018 2:38 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST

You can also avoid both by allocating it large enough: calculate what you need during the life of the IPL, double, triple or whatever it and you can sleep quietly. What do a few 1000 cyls cost these days?

Kees.

Post by Barkow, Eileen
-----Original Message-----
Behalf Of Ed Jaffe
Sent: 02 October, 2018 8:33
Subject: Re: S106 abends after copying into LINKLIST

Post by Jesse 1 Robinson
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.

Post by Jesse 1 Robinson
(1) Can be avoided by simply not defining any secondary extent, i.e.

Post by Jesse 1 Robinson
(2) Seems to be OP's issue. LLA REFRESH can handle the consequences of

John Eells

2018-10-02 13:01:21 UTC

Permalink

Ed Jaffe wrote:
<snip>

Post by Ed Jaffe
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!

<snip>

Whether it's "IBM's" recommendation depends on who you talk to (smile).
I believe Peter and I have disagreed about this for about 25 years.

There are two possible problems when using secondary extents for link
list data saets, exceeding the link list extent limit the topic of this
thread, everyone's favorite ABEND106-F RC40. If your link list is not
especially long, hitting the 255 limit will probably not happen; you can
count extents before IPL after putting on PTFs and if necessary compress
or reallocate. In the meantime, you will have many fewer x37 abends
while putting on PTFs. This should be an informed choice, in my view,
rather than a blanket recommendation. But see below.*

If you don't update running systems, the second problem will never occur.

Likewise, whether it's IBM's recommendation to never update a copy of
system software that is in use depends on who you talk to and whether
DYNACT is specified for a particular PTF. Here there be tygers, and my
recommendation is never to do that unless you clearly and thoroughly
scope out the probable result first and are prepared to IPL if you miss
something (which is easy to do) and the change goes pear-shaped.

*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 allocation for system software volumes.
"Just let the disk controller manage the actual real estate" is my (new)
recommendation for system software volumes.

John Eells

2018-10-02 14:41:54 UTC

Permalink

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...."

Seymour J Metz

2018-10-02 15:43:49 UTC

Permalink

I prefer to avoid the problem by never updating a live linklist library.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Ed Jaffe <***@PHOENIXSOFTWARE.COM>
Sent: Tuesday, October 2, 2018 2:33 AM
To: IBM-***@listserv.ua.edu
Subject: Re: S106 abends after copying into LINKLIST

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!

I would much rather take a new extent for one relinked module than risk corrupting the *ENTIRE LIBRARY* with a "live" compress using DISP=SHR. Of course, periodic compress of LNKLST PDS libraries is not a bad idea when done under controlled circumstances: i.e., "quiet" time and LLA on all sharing systems has been shut DOWN. Also, I like to STEPLIB any IEBCOPY job to a recent *copy* of SYS1.LINKLIB to ensure IEBCOPY program parts are not moved during the compress... BTDTGTS!!

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://secure-web.cisco.com/1q8GhGGjGwO5ssJJgtG_tT5WKJ_rYH8AUo2gsNSG8zHaWD8GRoN3t5cTibn5HAkwdZERfkLyrabLgeVrt9KBZCPT2SrOjk9ep2Hf2eQWbMWvftOuZ2ERmcHXpcAZ52N4fT0y0iizIs0dcaFmdLk6hAk_QRtJQO2-qDrVtaJEhhu13sZUCvmibSV7W6gjvtr4ceCEduqBgWlTBHwP115SaVENlRqaafahiX4TxFWBqbj6mVb2TAZiUZr5NuZqsxrAG0VVuAm0a0ceXJr4YXBxBuebUVMwd2a7NxyMj7c8qsD0iBH9mXpgyQYb6cCn5hy8whtD_gAqVkIGTVbteWe13MRs6L-dCer4i-W23-BA-XQXNkc-hI5nAlGrxSPUdTQa9qFBP1Ry-LavSEX56ptGDNovjGGZdoJlKJjPGgcEKHMOn8TKuyXI3BdlZ0P4JIGPt/https%3A%2F%2Fwww.phoenixsoftware.com%2F

--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Ed Jaffe

2018-10-02 23:07:10 UTC

Permalink

Post by Seymour J Metz
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 has no IPL hold -- stop LLA, apply the
fix, bring LLA back up, and perform any documented DYNACT restart.
Problem solved. No downtime whatsoever...
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/

--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Seymour J Metz

2018-10-03 20:06:01 UTC

Permalink

I stated that I *prefer* to never update I live linklist library, not that I wouldn't or haven't done it in an emergency situation. What I do to avoid an outage is not what is sound for routine maintenance.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Ed Jaffe <***@PHOENIXSOFTWARE.COM>
Sent: Tuesday, October 2, 2018 7:06 PM
To: IBM-***@listserv.ua.edu
Subject: Re: S106 abends after copying into LINKLIST

Post by Seymour J Metz
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 has no IPL hold -- stop LLA, apply the
fix, bring LLA back up, and perform any documented DYNACT restart.
Problem solved. No downtime whatsoever...

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://secure-web.cisco.com/1aOWW9glDQFjnKuh3fDYuN26IHbT-_N5Fr6A4K0TjpD2c9Bgo5GW9Z3MNrZAb-OVpNQm_qkNyZIOL8NctYJkxacBsKoMc1LC8Atzs0TF0n5vQgNkyAVsGeUcICQOomGEj-EHPGUKH9MJbUKpyWrhlsEnd6-VH1txxIYQrv4heHRQ7Uk3Yx7O4_1TlU_CBpcy3l_tgHi4ZyXW25KX-HVWzQ4u0rZNziJ6bWg7xy5PZah3E3NfQtlKDLu0JjrJWVbcinx99vNmCOYfGqgol32cS3jZGUEp3p8Y9mNlxNWKnTupMJTEdTZg0o9DzRgxWWvFi9t1iPIVhiUmnShC_uTxu5IY8uRWVN1eSJVvpMbL_QeGfgMsWaCklX3mMSOhAEvnqn5TQZgELCFx4Xw4b23V7BwdtIN23m0Ht8XLR-WLPjO_6nccH17JQQjOkrMefAuLC/https%3A%2F%2Fwww.phoenixsoftware.com%2F

--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Peter Relson

2018-10-02 11:51:37 UTC

Permalink

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 properly avoid compress without getting the proper (DISP=OLD,
exclusive) serialization, the allocations done on the LNKLST data sets
will prevent that.
But if you simply use DISP=SHR, you're on your own.

There is no reason that I can think of to refresh LLA as long as you have
not done of those things.

Peter Relson
z/OS Core Technology Design

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Seymour J Metz

2018-10-02 15:28:52 UTC

Permalink

Post by Barkow, Eileen
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 and is the cause of the problem.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Barkow, Eileen <***@DOITT.NYC.GOV>
Sent: Monday, October 1, 2018 10:09 AM
To: IBM-***@listserv.ua.edu
Subject: S106 abends after copying into LINKLIST

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 CICS LINKLIST/LPA modules into the existing LINKLIST/LPA loadlibs
in use (a rather new scenario in use here - we used to use alternative datasets), in anticipation of an IPL to
be done sunday morning.
anyway, around 6pm friday evening, an I/O error occured in linklist and other jobs started abending with S106 abends.
the linklist library was not allocated with secondary extents and there was no LLA refresh issued during
the day. I cannot find anything like this situation occurring on IBMLINK and we have no dump of the original failure.

Does anyone have any idea of what could have caused the I/O error.
both the input and output datasets have a max blksize of 32760.

IEW4009I FETCH FAILED FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- BECAUSE
OF AN I/O ERROR.
IEW4005I FETCH FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- FAILED BECAUSE
IEWFETCH ISSUED RC 0F AND REASON 40
CSV031I LIBRARY ACCESS FAILED FOR MODULE DFHXCPRX, RETURN CODE 24,
REASON CODE 26080021, DDNAME *LNKLST*

________________________________

This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Barkow, Eileen

2018-10-02 15:43:06 UTC

Permalink

I agree that this maintenance strategy is no good but the MVS group does not want to have to change parmlib for new maintenance, so
We now have to do the updates right before an IPL - usually about 4am on Sunday mornings.
We used to at least keep separate linklist/lpa datasets for different releases of CICS - now the same datasets get overlaid for new releases as well as maintenance.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz
Sent: Tuesday, October 02, 2018 11:29 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST

Post by Barkow, Eileen
Perhaps someone can offer a plausible explanation for this, so that
the MVS group will stop blaming the CICS group for the problem.

Carmen Vitullo

2018-10-02 17:22:30 UTC

Permalink

I do also, every place has their own process and if it's a standard practice that works, that's great.
I've worked at places that did as you, update live link listed libraries on a Friday afternoon before a scheduled IPL, crossing their fingers an in prompt-u IPL is not done before, or, oh well, my changes are in :)
I've been in client sites that will not allow you to Stage changes prior to your downtime, this controlled by a change managment monitoring tool, if you do make a change beforehand, you're toast.
I've been at site that control changes by keeping 2 sets of SMP/E target environments, and you flip from one to the other, this is done for CICS and DB2 and MQ and......
this strategy worked best IMHO but a lot of folks don't like the thought of managing 2 target environments. so I think this time you (team) got burnt. tons of explanation here on how PDS's allocation should be done and what happens when a PDS is emptied/reloaded or compressed without an LLA refresh, all good stuff, I'll continue what works for me and NOT allocation secondary space for a link listed library and ensure my primary space is adequate for the install + maint, if possible.
my .00002 cents

Carmen Vitullo

----- Original Message -----

From: "Eileen Barkow" <***@DOITT.NYC.GOV>
To: IBM-***@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 strategy is no good but the MVS group does not want to have to change parmlib for new maintenance, so
We now have to do the updates right before an IPL - usually about 4am on Sunday mornings.
We used to at least keep separate linklist/lpa datasets for different releases of CICS - now the same datasets get overlaid for new releases as well as maintenance.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz
Sent: Tuesday, October 02, 2018 11:29 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST

Post by Barkow, Eileen
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 and is the cause of the problem.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Barkow, Eileen <***@DOITT.NYC.GOV>
Sent: Monday, October 1, 2018 10:09 AM
To: IBM-***@listserv.ua.edu
Subject: S106 abends after copying into LINKLIST

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 CICS LINKLIST/LPA modules into the existing LINKLIST/LPA loadlibs
in use (a rather new scenario in use here - we used to use alternative datasets), in anticipation of an IPL to
be done sunday morning.
anyway, around 6pm friday evening, an I/O error occured in linklist and other jobs started abending with S106 abends.
the linklist library was not allocated with secondary extents and there was no LLA refresh issued during
the day. I cannot find anything like this situation occurring on IBMLINK and we have no dump of the original failure.

Does anyone have any idea of what could have caused the I/O error.
both the input and output datasets have a max blksize of 32760.

IEW4009I FETCH FAILED FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- BECAUSE
OF AN I/O ERROR.
IEW4005I FETCH FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- FAILED BECAUSE
IEWFETCH ISSUED RC 0F AND REASON 40
CSV031I LIBRARY ACCESS FAILED FOR MODULE DFHXCPRX, RETURN CODE 24,
REASON CODE 26080021, DDNAME *LNKLST*

________________________________

This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Paul Gilmartin

2018-10-02 16:58:53 UTC

Permalink

Post by John Eells
*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 allocation for system software volumes.
"Just let the disk controller manage the actual real estate" is my (new)
recommendation for system software volumes.

Does TP reclaim space from deleted members?

But I hope not while connections to those members persist?

Does any of this apply to program objects and other files in zFS?

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Paul Gilmartin

2018-10-02 17:10:31 UTC

Permalink

Post by Seymour J Metz
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 question that occurs to me.
Can an overriding SPACE option in a DD statement allow allocation of a secondary
extent to a data set initially allocated with zero secondary?

Post by Seymour J Metz
________________________________________
From: I Carmen Vitullo
Sent: Monday, October 1, 2018 11:55 AM
There's the key, in the allocation, if I allocate space for a linklist library I DO NOT specify any secondary allocation, zero zilch! a secondary extend can be taken to get my primary space if needed, but my PDS cannot get another extend due to my initial allocation of 100,0 for example , SMS or not, (as long as an SMS dataclass is not getting me in trouble)

Steve Beaver

2018-10-02 17:15:57 UTC

Permalink

Never, ever let your LINKLST go into secondary's. Otherwise you will quickly learn how to
Update your LNKLST dynamically. And never put your LNKLST datasets in SMS

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
Sent: Tuesday, October 2, 2018 12:10 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST

Post by Seymour J Metz
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.

Carmen Vitullo

2018-10-02 17:28:36 UTC

Permalink

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 :(
I just recently forwarded a health check issue to a teammate, her PDS was allocated with secondary space , SOMETIME THE VENDOR SUPPLIED in their allocation JCL, she got burnt because she compressed the library without knowing really what to do or without asking what to do first.

Carmen Vitullo

----- Original Message -----

From: "Steve Beaver" <***@STEVEBEAVER.COM>
To: IBM-***@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 your LNKLST datasets in SMS

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
Sent: Tuesday, October 2, 2018 12:10 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST

Post by Seymour J Metz
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.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Eric Jackson

2018-10-02 20:02:59 UTC

Permalink

Post by Paul Gilmartin

Post by Seymour J Metz
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.

-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

Yes, if your JCL specifies a secondary it will be effective. Obviously
the primary and directory allocation are ignored.

OP said they were avoiding doing a compress by clearing the library
first; but clearing and copying does accomplish a compress, invalidates
the TTRs, and certainly is the cause of the S106 abends.

Paul Gilmartin

2018-10-02 19:01:34 UTC

Permalink

Post by Carmen Vitullo
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 :(
I just recently forwarded a health check issue to a teammate, her PDS was allocated with secondary space , SOMETIME THE VENDOR SUPPLIED in their allocation JCL, she got burnt because she compressed the library without knowing really what to do or without asking what to do first.

Carmen Vitullo

2018-10-02 19:32:21 UTC

Permalink

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

Carmen Vitullo

----- Original Message -----

From: "Paul Gilmartin" <0000000433f07816-dmarc-***@LISTSERV.UA.EDU>
To: IBM-***@LISTSERV.UA.EDU
Sent: Tuesday, October 2, 2018 2:01:27 PM
Subject: Re: S106 abends after copying into LINKLIST

Aren't these problems of the sort that PDSE was invented to solve? Indexed directories
facilitate searcn. LUW isolation facilitates live update and compress neither needed
nor supported?

What went wrong?

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Ed Jaffe

2018-10-02 23:11:39 UTC

Permalink

Post by Carmen Vitullo
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 deleted members if the data set is
open by LNKLST?
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/

--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Peter Hunkeler

2018-10-03 05:30:24 UTC

Permalink

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 PDSE processing to recognize the data set is in linklist usage (I doubt there is, but who knows?)
I would assume that the space is reclaimed not matter whether the data set is open or not.

--
Peter Hunkeler

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Gibney, Dave

2018-10-03 08:12:50 UTC

Permalink

I don't remember the details or when, but I do remember threads here claiming that PDSE space reclaim did not occur while the dataset was open.

Post by Barkow, Eileen
-----Original Message-----
Behalf Of Peter Hunkeler
Sent: Tuesday, October 02, 2018 10:30 PM
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
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 PDSE processing to
recognize the data set is in linklist usage (I doubt there is, but who knows?) I
would assume that the space is reclaimed not matter whether the data set is
open or not.
--
Peter Hunkeler
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

Ed Jaffe

2018-10-03 17:04:55 UTC

Permalink

Post by Peter Hunkeler

Are you sure space is reclaimed for deleted members if the data set is open by LNKLST?

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 issue some kinda FIND macro and create that
connection. Once you're done using the member, newfangled code *might*
disconnect by issuing DESERV FUNC=RELEASE, but otherwise CLOSE is the
only way.
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/

--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Carmen Vitullo

2018-10-03 12:24:00 UTC

Permalink

well we are talking LINK LISTED ( LLA managed) , s o while the space in the PDS/E is reused, it makes no difference if it's LINK LISTED ( LLA managed) ?

Carmen Vitullo

----- Original Message -----

From: "Ed Jaffe" <***@PHOENIXSOFTWARE.COM>
To: IBM-***@LISTSERV.UA.EDU
Sent: Tuesday, October 2, 2018 6:11:29 PM
Subject: Re: S106 abends after copying into LINKLIST

Peter Relson

2018-10-03 11:44:55 UTC

Permalink

Post by Steve Beaver
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.

Post by Steve Beaver
Update your LNKLST dynamically.

Sure. But do not use LNKLST UPDATE JOB(*) unless you are willing to accept
any fallout (which can be from "none" to "incorrect results" to "abends"
to, conceivably, "wait state"). I don't know if the books ever used the
phrasing I always use for describing that operation -- unpredictably
dangerous. Regardless, it is at your risk. If your choice is between doing
that and re-IPLing, you might well roll the dice and hope for the best.

Peter Relson
z/OS Core Technology Design

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Paul Gilmartin

2018-10-03 14:03:30 UTC

Permalink

Post by Peter Hunkeler

Are you sure space is reclaimed for deleted members if the data set is open by LNKLST?

Can't space be reclaimed even from an open data set provided that the
members are DISCONNECTed by STOW?

o But DISCONNECT makes the pseudo-TTR invalid, so the directory must be
searched again for the member. LLA would provide no benefit.

o Absent DISCONNECT, the space would not be reclaimed.

o Indexed PDSE directories may provide some of the performance benefit of LLA

If a programmer reads the (simulated?) PDS directory of a PDSE as PS, does
that create a connection to every member returned?

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Paul Gilmartin

2018-10-03 17:47:02 UTC

Permalink

Post by Ed Jaffe
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 issue some kinda FIND macro and create that
connection. Once you're done using the member, newfangled code *might*
disconnect by issuing DESERV FUNC=RELEASE, but otherwise CLOSE is the
only way.

Did I say something I didnt know? I based my remarks on:
STOW—Update partitioned data set directory (BPAM)
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad5...
...
The STOW macro updates a partitioned data set (PDS) directory or PDSE directory.
You can perform the following directory actions with STOW:
...
o Disconnect PDSE members.

I thought that long ago you said that you conscientiously use STOW DISCONNECT.
But perhaps it was DESERV.
...
o Replace a member of a PDSE, if and only if the existing member was
created with a specified time stamp value.

Oh. I hadn't known about this. Does it rely on:
o The ISPF timestamp?
o The FileAccessMethodService (FAMS) timestamp?
(I suppose there's an interface to extract this. Ah! It says DESERV.)
Is there no "Replace if older"?
o Other (specify)?

Does ISPF LMMLIST create member connections?

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Ed Jaffe

2018-10-03 17:51:57 UTC

Permalink

Post by Paul Gilmartin

STOW—Update partitioned data set directory (BPAM)
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad5...
...
The STOW macro updates a partitioned data set (PDS) directory or PDSE directory.
...
o Disconnect PDSE members.

Yes, STOW can also be used to perform a disconnect, but that's not
normally (ever?) applicable to accesses made via LNKLST and my comment
was not aimed at you anyway. I was responding to Peter Hunkeler.
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/

--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Jesse 1 Robinson

2018-10-03 22:04:00 UTC

Permalink

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?

Gil may have been right about this being the October Topic. For ServerPac data sets, I encourage the *judicious* use of secondary extents. That's largely because we (OK, almost) never update live data sets. We install maintenance in a service-only container--oh snaps, I just made that up--and migrate it to a live environment with an IPL. A swollen data set can be inconspicuously compressed before it's (re)introduced to the wild. OTOH dealing with a data set that has incrementally outgrown its original primary-only allocation can be a major PITA even in a service-only container.

The catch is that You Need to Know What You're Doing. I know, this requirement offends manage-by-airline-rag execs who see knowledge and experience as obstacles to hiring practices. So be it.

So why not, as someone suggested, just make every data set Godzilla-size so that you never run out of space? Back when MVS releases showed up every six months, usage growth from one release to the next could somewhat be anticipated. But we all have to live with finite sysres volume(s), and after a couple of years' worth of new function before the next ServerPac, anticipating the long-term growth of every library is pretty much a crapshoot. Defining secondary extents that may or may not be needed in the current release is a fairly cheap maneuver to head off an inconvenient space crunch.

As we all agree, install fixes on live systems infrequently and with great care, but IBM has invested tons in mechanisms that make continuous availability possible if not trivial. Just come clean that it's this or guaranteed IPL. I've made a handful of gambles over the years. Won more than I've lost, but each one is a cliff hanger.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
***@sce.com

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz
Sent: Wednesday, October 03, 2018 1:06 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: S106 abends after copying into LINKLIST

I stated that I *prefer* to never update I live linklist library, not that I wouldn't or haven't done it in an emergency situation. What I do to avoid an outage is not what is sound for routine maintenance.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Ed Jaffe <***@PHOENIXSOFTWARE.COM>
Sent: Tuesday, October 2, 2018 7:06 PM
To: IBM-***@listserv.ua.edu
Subject: Re: S106 abends after copying into LINKLIST

Post by Seymour J Metz
I prefer to avoid the problem by never updating a live linklist library.

Elardus Engelbrecht

2018-10-04 08:47:39 UTC

Permalink

Post by Jesse 1 Robinson
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' ;-)

Post by Jesse 1 Robinson
Gil may have been right about this being the October popic. For ServerPac data sets, I encourage the *judicious* use of secondary extents. That's largely because we (OK, almost) never update live data sets. We install maintenance in a service-only container--oh snaps, I just made that up--and migrate it to a live environment with an IPL. A swollen data set can be inconspicuously compressed before it's (re)introduced to the wild. OTOH dealing with a data set that has incrementally outgrown its original primary-only allocation can be a major PITA even in a service-only container.

Agreed. This is why there is the ability to do 'rolling maintenance'. You leave out live things out and setup new IPL/other volsers with bigger than big datasets.

Of course, can you do that or not. YMMV.

Post by Jesse 1 Robinson
The catch is that You Need to Know What You're Doing. I know, this requirement offends manage-by-airline-rag execs who see knowledge and experience as obstacles to hiring practices. So be it.

Those 'manage-by-airline-rag' execs also are extrememely offended (because of no brain cells) by this:

1. No applying fixes on 'live' things.
2. Downtime and approvals and double check-outs/verifications are needed.
3. z/OS does not need 'three finger salute' (CTRL-ALT-DEL for reboot).
4. Nothing to click on. no GUI. (yes, I know about the new products with GUI interfaces, but ... )
5. ... etc ...

Post by Jesse 1 Robinson
... after a couple of years' worth of new function before the next ServerPac, anticipating the long-term growth of every library is pretty much a crapshoot.

This is why you see in Program Directories the required space for each dataset/OMVS files needed for each product you ordered.

Post by Jesse 1 Robinson
Defining secondary extents that may or may not be needed in the current release is a fairly cheap maneuver to head off an inconvenient space crunch.

We discourage updates of live modules, but 'they' won't listen. Only when something crash, then 'they' rememeber... :-(

Post by Jesse 1 Robinson
As we all agree, install fixes on live systems infrequently and with great care, but IBM has invested tons in mechanisms that make continuous availability possible if not trivial. Just come clean that it's this or guaranteed IPL. I've made a handful of gambles over the years. Won more than I've lost, but each one is a cliff hanger.

You're a true risk taker! ;-D

Post by Jesse 1 Robinson
I stated that I *prefer* to never update I live linklist library, not that I wouldn't or haven't done it in an emergency situation. What I do to avoid an outage is not what is sound for routine maintenance.

Good. Unless you are in a catch-22 situation, but I believe you also *prefer* not to be there. ;-)

This thread is a very interesting one. Thanks!

Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

John Eells

2018-10-04 11:35:32 UTC

Permalink

Post by Elardus Engelbrecht
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 the
amount of space consumed by each data set at a particular point in time
- are measured at the specified block sizes when the FMIDs represented
by that program directory were submitted to software manufacturing and
never updated
- provide information for only that product and no others that might
share the data set.

So if PTFs cause the space required to grow by more than the fixed
percentage, or you use different block sizes than we specify (which is
not to your advantage in general), or fail to add the space required by
all products sharing a data set together, you will be in x37 City before
you know it.

ServerPac production is smart enough to adjust space on the fly, BTW, so
the free space allocated by default stays at a fixed percentage even as
PTFs consume more space in the data sets for the products included. For
CBPDO, you get to guess yourself.

Jesse 1 Robinson

2018-10-04 15:27:07 UTC

Permalink

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 uncertainties wrapped in unknowns. The change from six month to two year release cycles further clouded space predictions.

I think customers are best off expecting data set expansions. A few like LINKLIB and LPALIB can be deliberately oversized as likely candidates for increase in a variety of components. But the migratable sysres volume is limited to whatever size installation has settled on. Secondary extents, in my view, allow for unpredictable expansion with acceptable risk.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
***@sce.com

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of John Eells
Sent: Thursday, October 04, 2018 4:35 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: S106 abends after copying into LINKLIST

Post by Elardus Engelbrecht
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 the amount of space consumed by each data set at a particular point in time
- are measured at the specified block sizes when the FMIDs represented by that program directory were submitted to software manufacturing and never updated
- provide information for only that product and no others that might share the data set.

So if PTFs cause the space required to grow by more than the fixed percentage, or you use different block sizes than we specify (which is not to your advantage in general), or fail to add the space required by all products sharing a data set together, you will be in x37 City before you know it.

ServerPac production is smart enough to adjust space on the fly, BTW, so the free space allocated by default stays at a fixed percentage even as PTFs consume more space in the data sets for the products included. For CBPDO, you get to guess yourself.

--
John Eells
IBM Poughkeepsie
***@us.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Ed Jaffe

2018-10-04 16:16:12 UTC

Permalink

What size SYSRES do most shops use these days?

We have settled on Mod-27 as our "standard" volume for almost
everything. We also have some Mod-9s and Mod-216s for special purposes.

No Mod-1s, Mod-2s, Mod-3s, Mod-54s, or any other "oddball" sizes. Just
the three described above...

Post by Jesse 1 Robinson
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 uncertainties wrapped in unknowns. The change from six month to two year release cycles further clouded space predictions.
I think customers are best off expecting data set expansions. A few like LINKLIB and LPALIB can be deliberately oversized as likely candidates for increase in a variety of components. But the migratable sysres volume is limited to whatever size installation has settled on. Secondary extents, in my view, allow for unpredictable expansion with acceptable risk.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
-----Original Message-----
Sent: Thursday, October 04, 2018 4:35 AM
Subject: (External):Re: S106 abends after copying into LINKLIST

Post by Elardus Engelbrecht
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.
- a fixed percentage larger (10 or 15%, I forget right now) than the amount of space consumed by each data set at a particular point in time
- are measured at the specified block sizes when the FMIDs represented by that program directory were submitted to software manufacturing and never updated
- provide information for only that product and no others that might share the data set.
So if PTFs cause the space required to grow by more than the fixed percentage, or you use different block sizes than we specify (which is not to your advantage in general), or fail to add the space required by all products sharing a data set together, you will be in x37 City before you know it.
ServerPac production is smart enough to adjust space on the fly, BTW, so the free space allocated by default stays at a fixed percentage even as PTFs consume more space in the data sets for the products included. For CBPDO, you get to guess yourself.
--
John Eells
IBM Poughkeepsie

Pew, Curtis G

2018-10-04 16:44:17 UTC

Permalink

Post by Ed Jaffe
What size SYSRES do most shops use these days?
We have settled on Mod-27 as our "standard" volume for almost everything. We also have some Mod-9s and Mod-216s for special purposes.
No Mod-1s, Mod-2s, Mod-3s, Mod-54s, or any other "oddball" sizes. Just the three described above...

All our volumes are configured as mod-54s. We also use thin provisioning; our defined volumes are about 135% of the physically available space, but only about 70% of that space is actually in use.

I would never want to go back to not using thin provisioning.

--
Pew, Curtis G
***@austin.utexas.edu
ITS Systems/Core/Administrative Services

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Pommier, Rex

2018-10-04 17:22:18 UTC

Permalink

SYSRES are 27s. Still using primarily 9s for other stuff but gradually moving to 27s.

Rex

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe
Sent: Thursday, October 04, 2018 11:16 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: [External] SYSRES Volume Size (Was: S106 abends ...)

What size SYSRES do most shops use these days?

We have settled on Mod-27 as our "standard" volume for almost
everything. We also have some Mod-9s and Mod-216s for special purposes.

No Mod-1s, Mod-2s, Mod-3s, Mod-54s, or any other "oddball" sizes. Just
the three described above...

Post by Elardus Engelbrecht
This is why you see in Program Directories the required space for each dataset/OMVS files needed for each product you ordered.

--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

Carmen Vitullo

2018-10-04 18:12:33 UTC

Permalink

Our last tech (DASD) refresh from 100% mod-54

Carmen Vitullo

----- Original Message -----

From: "Ed Jaffe" <***@PHOENIXSOFTWARE.COM>
To: IBM-***@LISTSERV.UA.EDU
Sent: Thursday, October 4, 2018 11:15:46 AM
Subject: SYSRES Volume Size (Was: S106 abends ...)

What size SYSRES do most shops use these days?

We have settled on Mod-27 as our "standard" volume for almost
everything. We also have some Mod-9s and Mod-216s for special purposes.

No Mod-1s, Mod-2s, Mod-3s, Mod-54s, or any other "oddball" sizes. Just
the three described above...

Post by Elardus Engelbrecht
This is why you see in Program Directories the required space for each dataset/OMVS files needed for each product you ordered.

--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Gibney, Dave

2018-10-05 06:37:30 UTC

Permalink

Mod-27, with the ZFS on a separate SMS managed Mod-27

Post by Barkow, Eileen
-----Original Message-----
Behalf Of Jousma, David
Sent: Thursday, October 04, 2018 11:30 AM
Subject: Re: SYSRES Volume Size (Was: S106 abends ...)
Just to expand on this a bit. I have all mod-54 sysres volumes that we rotate
ZFS - 398454 tracks
Traditional - ~150K tracks.
-----Original Message-----
From: Jousma, David
Sent: Thursday, October 04, 2018 1:00 PM
Subject: RE: SYSRES Volume Size (Was: S106 abends ...)
Mod-54. 70+% utilized.
-----Original Message-----
Behalf Of Ed Jaffe
Sent: Thursday, October 04, 2018 12:16 PM
Subject: SYSRES Volume Size (Was: S106 abends ...)
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or
unexpected emails**
What size SYSRES do most shops use these days?
We have settled on Mod-27 as our "standard" volume for almost everything.
We also have some Mod-9s and Mod-216s for special purposes.
No Mod-1s, Mod-2s, Mod-3s, Mod-54s, or any other "oddball" sizes. Just the
three described above...

Post by Jesse 1 Robinson
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 uncertainties wrapped in unknowns.
The change from six month to two year release cycles further clouded space
predictions.

Post by Jesse 1 Robinson
I think customers are best off expecting data set expansions. A few like

LINKLIB and LPALIB can be deliberately oversized as likely candidates for
increase in a variety of components. But the migratable sysres volume is
limited to whatever size installation has settled on. Secondary extents, in my
view, allow for unpredictable expansion with acceptable risk.

Post by Jesse 1 Robinson
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-
On Behalf Of John Eells
Sent: Thursday, October 04, 2018 4:35 AM
Subject: (External):Re: S106 abends after copying into LINKLIST

Post by Elardus Engelbrecht
This is why you see in Program Directories the required space for each

dataset/OMVS files needed for each product you ordered.

Post by Jesse 1 Robinson
Let's just be clear about what those space numbers represent.
- a fixed percentage larger (10 or 15%, I forget right now) than the
amount of space consumed by each data set at a particular point in
time
- are measured at the specified block sizes when the FMIDs represented
by that program directory were submitted to software manufacturing and
never updated
- provide information for only that product and no others that might share

the data set.

Post by Jesse 1 Robinson
So if PTFs cause the space required to grow by more than the fixed

percentage, or you use different block sizes than we specify (which is not to
your advantage in general), or fail to add the space required by all products
sharing a data set together, you will be in x37 City before you know it.

Post by Jesse 1 Robinson
ServerPac production is smart enough to adjust space on the fly, BTW, so

the free space allocated by default stays at a fixed percentage even as PTFs
consume more space in the data sets for the products included. For CBPDO,
you get to guess yourself.

Post by Jesse 1 Robinson
--
John Eells
IBM Poughkeepsie

--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and
the information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise received
this email message in error, any use, dissemination, distribution, review,
storage or copying of this e-mail message and the information contained
therein is strictly prohibited. If you are not an intended recipient, please
contact the sender by reply e-mail and destroy all copies of this email
message and do not otherwise utilize or retain this email message or any or
all of the information contained therein. Although this email message and
any attachments or appended messages are believed to be free of any virus
or other defect that might affect any computer system into which it is
received and opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by the sender for any loss or
damage arising in any way from its opening or use.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or
unexpected emails**
This e-mail transmission contains information that is confidential and may be
privileged. It is intended only for the addressee(s) named above. If you
receive this e-mail in error, please do not read, copy or disseminate it in any
manner. If you are not the intended recipient, any disclosure, copying,
distribution or use of the contents of this information is prohibited. Please
reply to the message immediately by informing the sender that the message
was misdirected. After replying, please erase it from your computer system.
Your assistance in correcting this error is appreciated.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to

Tom Sims

2018-10-05 13:31:58 UTC

Permalink

Same here, except ZFSes are in an SMS pool (once a Coug, always a Coug!).

Tom Sims

Post by Gibney, Dave
Mod-27, with the ZFS on a separate SMS managed Mod-27

John Eells

2018-10-05 10:45:56 UTC

Permalink

While we have long provided some cushion in the initial numbers and in
ServerPac (and before it, CBIPO and even IPO) allocations, we have
really left further guessing to you. 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 shop out there.

In the long term I think everyone is better off moving all their
software volumes to -54s, doubling or even tripling all the primary
space allocations, and using thin provisioning to manage space at the
volume level rather than the data set level. It will be approximately
true that only occupied space takes up actual disk real estate when you
do that. (I say "approximately" because there is an increment size, and
on the average every data set will have an extra half-increment.)

System software data set level space management and x37 abends during
APPLY and ACCEPT processing will, I would hope, become a fading memory
in a few years. Unlike some other memories, nobody will miss the "good
old days." This will be more like the stories about how much more
complicated life used to be when you had to walk to school. It was
always uphill both ways and it was always cold and snowing. At least,
that's what people used to tell their kids who rode those cushy heated
(FSVO "heated," at least in Maine) buses, right?

Tom Sims

2018-10-05 13:35:22 UTC

Permalink

Practically a guarantee that **someone** out there will...

/Tom Sims

Post by John Eells

Post by John Eells
Unlike some other memories, nobody will miss the "good

old days."

Seymour J Metz

2018-10-05 15:06:55 UTC

Permalink

Overallocate PDS directories! Or change IPL/NIP processing so that everhing can be PDSE.

I had to walk to school. There were sidewalks all the way, so walking a mile or so was no problem.

My reading of the "good old days" before my time is that they were characterized by:

High infant mortality

Mob violence

Rampant discrimination

...

As for my early years, my first computer was a 650, a nostalgia killer if ever there was one.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of John Eells <***@US.IBM.COM>
Sent: Friday, October 5, 2018 6:45 AM
To: IBM-***@listserv.ua.edu
Subject: Re: S106 abends after copying into LINKLIST

Elardus Engelbrecht

2018-10-05 11:26:26 UTC

Permalink

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 shop out there.

Indeed.

System software data set level space management and x37 abends during APPLY and ACCEPT processing will, I would hope, become a fading memory in a few years.

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?

Unlike some other memories, nobody will miss the "good old days." This will be more like the stories about how much more complicated life used to be when you had to walk to school. It was always uphill both ways and it was always cold and snowing. At least, that's what people used to tell their kids who rode those cushy heated (FSVO "heated," at least in Maine) buses, right?

Longabaugh, Robert E

2018-10-05 18:04:10 UTC

Permalink

" 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 Allocate does that and many other things. Another ISV markets the one you are thinking of, and its name matches up with what you said it does.

Just trying to help....

Bob Longabaugh
CA Technologies
Storage Management

-----Original Message-----
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> On Behalf Of Elardus Engelbrecht
Sent: Friday, October 05, 2018 6:26 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST

CAUTION: This email originated from outside of CA. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Indeed.

System software data set level space management and x37 abends during APPLY and ACCEPT processing will, I would hope, become a fading memory in a few years.

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?

Carmen Vitullo

2018-10-05 18:06:01 UTC

Permalink

STOPX-37 :(

Carmen Vitullo

----- Original Message -----

From: "Robert E Longabaugh" <***@CA.COM>
To: IBM-***@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 party product which could intercept x37 abends and then dynamically fix it for you? "

CA Allocate does that and many other things. Another ISV markets the one you are thinking of, and its name matches up with what you said it does.

Just trying to help....

Bob Longabaugh
CA Technologies
Storage Management

-----Original Message-----
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> On Behalf Of Elardus Engelbrecht
Sent: Friday, October 05, 2018 6:26 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST

CAUTION: This email originated from outside of CA. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Indeed.

System software data set level space management and x37 abends during APPLY and ACCEPT processing will, I would hope, become a fading memory in a few years.

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?

Steve Beaver

2018-10-05 18:14:42 UTC

Permalink

Stop x37

Sent from my iPhone

Sorry for the autocorrect issues

Post by Carmen Vitullo
STOPX-37 :(
Carmen Vitullo
----- Original Message -----
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 Allocate does that and many other things. Another ISV markets the one you are thinking of, and its name matches up with what you said it does.
Just trying to help....
Bob Longabaugh
CA Technologies
Storage Management
-----Original Message-----
Sent: Friday, October 05, 2018 6:26 AM
Subject: Re: S106 abends after copying into LINKLIST
CAUTION: This email originated from outside of CA. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Indeed.

System software data set level space management and x37 abends during APPLY and ACCEPT processing will, I would hope, become a fading memory in a few years.

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?

1. Running water - you run outside to get water using your pail and your feet.
2. cold and hot water - cold in the winter, hot in the summer.
3. shools have a tree structure - you just sit under a tree.
4. good transport - donkey car, cycle or just walking.
5. excellent entertainment - you just play outside.
6. But food was at least good - no junk food like those fast take aways.
7. I wish I could remember the rest, but my memory is fading... ;-)
John, thanks for your kind and educational posts. I really value them. Please continue sharing your wisdom.
Groete / Greetings
Elardus Engelbrecht
----------------------------------------------------------------------
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

Charles Mills

2018-10-05 18:15:01 UTC

Permalink

BMC MainView SRM StopX37/II, actually.

http://documents.bmc.com/products/documents/39/79/123979/123979.pdf

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo
Sent: Friday, October 5, 2018 11:06 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST

STOPX-37 :(

Carmen Vitullo

----- Original Message -----

From: "Robert E Longabaugh" <***@CA.COM>
To: IBM-***@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 party product which could intercept x37 abends and then dynamically fix it for you? "

CA Allocate does that and many other things. Another ISV markets the one you are thinking of, and its name matches up with what you said it does.

Just trying to help....

Bob Longabaugh
CA Technologies
Storage Management

-----Original Message-----
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> On Behalf Of Elardus Engelbrecht
Sent: Friday, October 05, 2018 6:26 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST

CAUTION: This email originated from outside of CA. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Indeed.

System software data set level space management and x37 abends during APPLY and ACCEPT processing will, I would hope, become a fading memory in a few years.

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?

Right. In my child days, we were so poor, we have:

1. Running water - you run outside to get water using your pail and your feet.
2. cold and hot water - cold in the winter, hot in the summer.
3. shools have a tree structure - you just sit under a tree.
4. good transport - donkey car, cycle or just walking.
5. excellent entertainment - you just play outside.
6. But food was at least good - no junk food like those fast take aways.
7. I wish I could remember the rest, but my memory is fading... ;-)

John, thanks for your kind and educational posts. I really value them. Please continue sharing your wisdom.

Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Jackson, Rob

2018-10-05 18:08:55 UTC

Permalink

Hah, I'll help too: BMC's MainView SRM StopX37.

Also, Tivoli Advanced Allocation Manager from IBM.

There are probably others.

First Tennessee Bank
Mainframe Technical Support

-----Original Message-----
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> On Behalf Of Longabaugh, Robert E
Sent: Friday, October 05, 2018 2:04 PM
To: IBM-***@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 Allocate does that and many other things. Another ISV markets the one you are thinking of, and its name matches up with what you said it does.

Just trying to help....

Bob Longabaugh
CA Technologies
Storage Management

-----Original Message-----
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> On Behalf Of Elardus Engelbrecht
Sent: Friday, October 05, 2018 6:26 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST

CAUTION: This email originated from outside of CA. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Indeed.

System software data set level space management and x37 abends during APPLY and ACCEPT processing will, I would hope, become a fading memory in a few years.

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?

Right. In my child days, we were so poor, we have:

1. Running water - you run outside to get water using your pail and your feet.
2. cold and hot water - cold in the winter, hot in the summer.
3. shools have a tree structure - you just sit under a tree.
4. good transport - donkey car, cycle or just walking.
5. excellent entertainment - you just play outside.
6. But food was at least good - no junk food like those fast take aways.
7. I wish I could remember the rest, but my memory is fading... ;-)

John, thanks for your kind and educational posts. I really value them. Please continue sharing your wisdom.

Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
FIRST TENNESSEE

Confidentiality notice:
This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

PINION, RICHARD W.

2018-10-05 18:12:29 UTC

Permalink

And ACC/SRS from DTS Software.

-----Original Message-----
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> On Behalf Of Jackson, Rob
Sent: Friday, October 05, 2018 2:09 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: [Originated Externally]Re: S106 abends after copying into LINKLIST

[External Email]

Hah, I'll help too: BMC's MainView SRM StopX37.

Also, Tivoli Advanced Allocation Manager from IBM.

There are probably others.

First Tennessee Bank
Mainframe Technical Support

-----Original Message-----
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> On Behalf Of Longabaugh, Robert E
Sent: Friday, October 05, 2018 2:04 PM
To: IBM-***@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 Allocate does that and many other things. Another ISV markets the one you are thinking of, and its name matches up with what you said it does.

Just trying to help....

Bob Longabaugh
CA Technologies
Storage Management

-----Original Message-----
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> On Behalf Of Elardus Engelbrecht
Sent: Friday, October 05, 2018 6:26 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST

CAUTION: This email originated from outside of CA. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Indeed.

System software data set level space management and x37 abends during APPLY and ACCEPT processing will, I would hope, become a fading memory in a few years.

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?

Right. In my child days, we were so poor, we have:

1. Running water - you run outside to get water using your pail and your feet.
2. cold and hot water - cold in the winter, hot in the summer.
3. shools have a tree structure - you just sit under a tree.
4. good transport - donkey car, cycle or just walking.
5. excellent entertainment - you just play outside.
6. But food was at least good - no junk food like those fast take aways.
7. I wish I could remember the rest, but my memory is fading... ;-)

John, thanks for your kind and educational posts. I really value them. Please continue sharing your wisdom.

Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN FIRST TENNESSEE

Confidentiality notice:
This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Michael Stein

2018-10-08 18:15:30 UTC

Permalink

Post by Barkow, Eileen
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 linklist library was not allocated with secondary
extents and there was no LLA r the day. I cannot find anything like this
situation occurring on IBMLINK and we have
Does anyone have any idea of what could have caused the I/O error.
both the input and output datasets have a max blksize of 32760.
IEW4009I FETCH FAILED FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- BECAUSE
OF AN I/O ERROR.
IEW4005I FETCH FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- FAILED BECAUSE
IEWFETCH ISSUED RC 0F AND REASON 40
CSV031I LIBRARY ACCESS FAILED FOR MODULE DFHXCPRX, RETURN CODE 24,
REASON CODE 26080021, DDNAME *LNKLST*

It's been a while but from what I remember about program fetch
here's a guess.

Looking up S106 RC 0F reason code 40:

either an uncorrectable I/O error occurred or an error in the
load module caused the channel program to fail.

Well, lets assume the hardware is work so this isn't a "real" I/O
error caused by some hardware problem. And there are no dataset
extent changes, only the overwriting the dataset to empty it
out and then copying in the new modules.

Well the EOF pointer for the dataset got moved toward the front after
the directory. This caused the new modules to be written starting at
the new EOF over the old modules.

And LLA still has the directory entries for the old modules, not the new
ones. These now point into the new modules. LLA's information includes
specific information on the first block of text of each old module:

- the TTR of the first block of text
- the length of the first block of text
- the linkage editor assigned origin of first block of text

This allows program fetch to start with reading first text block,
rather than having to start at the beginning of the module. Fetch can
build a CCW to directly read the first block since it knows the TTR of
the block and it's length and also the storage address (storage area +
block origin).

Since the old modules were overwritten, it's certain that the block at
the old location isn't the expected one. There might not be a block there
giving no record found, there might be an EOF or there might be different
length block causing fetch's channel program to end with incorrect length.

This would explain the S106 RC 0F reason code 40.

This isn't that bad. The length of the wrong block/module might
have matched. I wonder if program fetch could successfully load the
wrong module.

Now with a blocksize of 32760, possibly each module will fit in one block
and they likely have different sizes so this wrong module case might
be unlikely. Or something else might prevent loading the wrong module
(what?) Or it may be possible to have a successful program fetch with
the wrong module. And then attempt to execute it with the parameters
and environment of the old module.

What would that cause? Program checks? Mangled data?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

John Eells

2018-10-08 19:44:13 UTC

Permalink

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 their own length, they are read with the SLI bit on in
the CCW, so that incorrect length does not cause any sort of I/O error,
logical or otherwise. The same goes for RLD records, and it might also
apply to others.

Based on some research I did a long time ago, here is how I believe
things work:

The control record contains a CCW fragment to be used in constructing
the Read CCW for the next text record, unless it's the last. PCI
processing is used to chain onto the channel program to get the entire
module in one shot unless the system is so busy the PCI can't be
serviced in time to add to the chain and the I/O operation terminates.
In that case, I believe it's restarted where it left off.

The read CCW for the text record should be constructed using the
specific length stored in the control record, and I would not expect the
SLI bit to be used for that CCW. On that basis, I would agree that if
the first "text" record you read does not have the expected length that
the unexpected status back from the device would likely result in a
"logical I/O error." However, it's possible that SLI is used for the
read (I have not read the code), and that would make other reasons
(empty track, no record at that location on a track, additional extents,
etc.) more likely culprits for ABEND106-F RC40. For performance
reasons, though, I would expect that SLI is not set. This code was
originally written before control unit cache existed and was designed to
be really good at avoiding unecessary disk latency. And, of course, we
might change details in the code at any time (though why we would ever
want to is a good question!).

The text records themselves are of variable length. They have a minimum
length of 1024 bytes, and a maximum length of the track length or block
size, whichever is smaller. The Binder (and COPYMOD) try to write the
minimum possible number based on those limits. They issue TRKBAL to
find out how much space is left on the track, and write records on
following tracks as needed to finish writing a load module. (This is
why 32760 is the best block size for load libraries.)

Because the directory pointers to PDS members are TTR pointers, every
load module does not generally happen to start on a new track. This
means that large block sizes rarely if ever result in uniform text
record lengths. They do result in fewer text records if the modules'
lengths exceed a lower block size, though.

All the above applies to load modules. I have no idea how this works
under the covers for program objects, but Program Management Advanced
Facilities documents load module records.

Just some random additional info to reinforce the "except under narrow
circumstances, with sufficient advance reflection, and malice--er, risk
acceptance-aforethought, don't update running systems' data sets" others
have already expressed.

Michael Stein wrote:
<snip>

Post by Michael Stein
It's been a while but from what I remember about program fetch
here's a guess.
either an uncorrectable I/O error occurred or an error in the
load module caused the channel program to fail.
Well, lets assume the hardware is work so this isn't a "real" I/O
error caused by some hardware problem. And there are no dataset
extent changes, only the overwriting the dataset to empty it
out and then copying in the new modules.
Well the EOF pointer for the dataset got moved toward the front after
the directory. This caused the new modules to be written starting at
the new EOF over the old modules.
And LLA still has the directory entries for the old modules, not the new
ones. These now point into the new modules. LLA's information includes
- the TTR of the first block of text
- the length of the first block of text
- the linkage editor assigned origin of first block of text
This allows program fetch to start with reading first text block,
rather than having to start at the beginning of the module. Fetch can
build a CCW to directly read the first block since it knows the TTR of
the block and it's length and also the storage address (storage area +
block origin).
Since the old modules were overwritten, it's certain that the block at
the old location isn't the expected one. There might not be a block there
giving no record found, there might be an EOF or there might be different
length block causing fetch's channel program to end with incorrect length.
This would explain the S106 RC 0F reason code 40.
This isn't that bad. The length of the wrong block/module might
have matched. I wonder if program fetch could successfully load the
wrong module.
Now with a blocksize of 32760, possibly each module will fit in one block
and they likely have different sizes so this wrong module case might
be unlikely. Or something else might prevent loading the wrong module
(what?) Or it may be possible to have a successful program fetch with
the wrong module. And then attempt to execute it with the parameters
and environment of the old module.
What would that cause? Program checks? Mangled data?

R.S.

2018-10-09 14:33:52 UTC

Permalink

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 reason to IPL
--
Radoslaw Skorupka
Lodz, Poland

======================================================================

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: ***@mBank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 0000025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 169.248.488 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have printed out or saved).
This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: ***@mBank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 0000025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169,248,488 as at 1 January 2018.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Seymour J Metz

2018-10-09 15:27:47 UTC

Permalink

The BLDL entry for a load module has included the TTR and length of the first text record since Old Man Noach cornered the market in Gopher Wood. Fetch chained the read of the text record to another read; the following record could never be a text record. There was no need to read the ESD. It seems highly unlikely that this has changed.

Of course, none of this applies to program objects.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of John Eells <***@US.IBM.COM>
Sent: Monday, October 8, 2018 3:44 PM
To: IBM-***@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 text record. I would expect that, since the ESD and control
records encode their own length, they are read with the SLI bit on in
the CCW, so that incorrect length does not cause any sort of I/O error,
logical or otherwise. The same goes for RLD records, and it might also
apply to others.

Based on some research I did a long time ago, here is how I believe
things work:

The control record contains a CCW fragment to be used in constructing
the Read CCW for the next text record, unless it's the last. PCI
processing is used to chain onto the channel program to get the entire
module in one shot unless the system is so busy the PCI can't be
serviced in time to add to the chain and the I/O operation terminates.
In that case, I believe it's restarted where it left off.

The read CCW for the text record should be constructed using the
specific length stored in the control record, and I would not expect the
SLI bit to be used for that CCW. On that basis, I would agree that if
the first "text" record you read does not have the expected length that
the unexpected status back from the device would likely result in a
"logical I/O error." However, it's possible that SLI is used for the
read (I have not read the code), and that would make other reasons
(empty track, no record at that location on a track, additional extents,
etc.) more likely culprits for ABEND106-F RC40. For performance
reasons, though, I would expect that SLI is not set. This code was
originally written before control unit cache existed and was designed to
be really good at avoiding unecessary disk latency. And, of course, we
might change details in the code at any time (though why we would ever
want to is a good question!).

The text records themselves are of variable length. They have a minimum
length of 1024 bytes, and a maximum length of the track length or block
size, whichever is smaller. The Binder (and COPYMOD) try to write the
minimum possible number based on those limits. They issue TRKBAL to
find out how much space is left on the track, and write records on
following tracks as needed to finish writing a load module. (This is
why 32760 is the best block size for load libraries.)

Because the directory pointers to PDS members are TTR pointers, every
load module does not generally happen to start on a new track. This
means that large block sizes rarely if ever result in uniform text
record lengths. They do result in fewer text records if the modules'
lengths exceed a lower block size, though.

All the above applies to load modules. I have no idea how this works
under the covers for program objects, but Program Management Advanced
Facilities documents load module records.

Just some random additional info to reinforce the "except under narrow
circumstances, with sufficient advance reflection, and malice--er, risk
acceptance-aforethought, don't update running systems' data sets" others
have already expressed.

Michael Stein wrote:
<snip>

--
John Eells
IBM Poughkeepsie
***@us.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN