Re: S106 abends after copying into LINKLIST
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 on behalf of John Eells Sent: Monday, October 8, 2018 3:44 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: S106 abends after copying into LINKLIST I do not know whether LLA keeps a pointer to the first text record (though it might), but it would certainly need the preceding associated control and ESD records to be cached as well if the first read done is for a 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: > > 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 origi
Re: S106 abends after copying into LINKLIST
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: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 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: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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: 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
Re: S106 abends after copying into LINKLIST
> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
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-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: Friday, October 5, 2018 11:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST STOPX-37 :( Carmen Vitullo - Original Message - From: "Robert E Longabaugh" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, October 5, 2018 1:03:52 PM Subject: Re: S106 abends after copying into LINKLIST " 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 On Behalf Of Elardus Engelbrecht Sent: Friday, October 05, 2018 6:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying 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. John Eells wrote: >I expect that we will err on the side of more free space pretty soon to help >alleviate out of space problems in this new(er) era of larger system software >volumes, particularly because system software is such a small fraction of the >disk space requirements for nearly any 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? 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
Stop x37 Sent from my iPhone Sorry for the autocorrect issues > On Oct 5, 2018, at 13:05, Carmen Vitullo wrote: > > STOPX-37 :( > > > Carmen Vitullo > > - Original Message - > > From: "Robert E Longabaugh" > To: IBM-MAIN@LISTSERV.UA.EDU > Sent: Friday, October 5, 2018 1:03:52 PM > Subject: Re: S106 abends after copying into LINKLIST > > " Now my memory is fading, what is the name of that third 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 On Behalf Of > Elardus Engelbrecht > Sent: Friday, October 05, 2018 6:26 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: S106 abends after copying 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. > > > John Eells wrote: > >> I expect that we will err on the side of more free space pretty soon to help >> alleviate out of space problems in this new(er) era of larger system >> software volumes, particularly because system software is such a small >> fraction of the disk space requirements for nearly any 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? > > 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 > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
And ACC/SRS from DTS Software. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jackson, Rob Sent: Friday, October 05, 2018 2:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [Originated Externally]Re: S106 abends after copying into LINKLIST [External Email] Hah, I'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 On Behalf Of Longabaugh, Robert E Sent: Friday, October 05, 2018 2:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST [External Email] " Now my memory is fading, what is the name of that third party product which could intercept x37 abends and then dynamically fix it for you? " CA 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 On Behalf Of Elardus Engelbrecht Sent: Friday, October 05, 2018 6:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying 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. John Eells wrote: >I expect that we will err on the side of more free space pretty soon to help >alleviate out of space problems in this new(er) era of larger system software >volumes, particularly because system software is such a small fraction of the >disk space requirements for nearly any 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? 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
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 On Behalf Of Longabaugh, Robert E Sent: Friday, October 05, 2018 2:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST [External Email] " Now my memory is fading, what is the name of that third party product which could intercept x37 abends and then dynamically fix it for you? " CA 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 On Behalf Of Elardus Engelbrecht Sent: Friday, October 05, 2018 6:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying 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. John Eells wrote: >I expect that we will err on the side of more free space pretty soon to help >alleviate out of space problems in this new(er) era of larger system software >volumes, particularly because system software is such a small fraction of the >disk space requirements for nearly any 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? 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
STOPX-37 :( Carmen Vitullo - Original Message - From: "Robert E Longabaugh" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, October 5, 2018 1:03:52 PM Subject: Re: S106 abends after copying into LINKLIST " 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 On Behalf Of Elardus Engelbrecht Sent: Friday, October 05, 2018 6:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying 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. John Eells wrote: >I expect that we will err on the side of more free space pretty soon to help >alleviate out of space problems in this new(er) era of larger system software >volumes, particularly because system software is such a small fraction of the >disk space requirements for nearly any 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? 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 On Behalf Of Elardus Engelbrecht Sent: Friday, October 05, 2018 6:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying 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. John Eells wrote: >I expect that we will err on the side of more free space pretty soon to help >alleviate out of space problems in this new(er) era of larger system software >volumes, particularly because system software is such a small fraction of the >disk space requirements for nearly any 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? 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
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 on behalf of John Eells Sent: Friday, October 5, 2018 6:45 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: S106 abends after copying into LINKLIST Jesse 1 Robinson wrote: > I sympathize with IBM's predicament in reading the future maintenance tea > leaves. The 'fix rate' 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. > 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? -- John Eells IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
Practically a guarantee that **someone** out there will... /Tom Sims On 10/5/2018 3:45 AM, John Eells wrote: Unlike some other memories, nobody will miss the "good old days." -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
John Eells wrote: >I expect that we will err on the side of more free space pretty soon to help >alleviate out of space problems in this new(er) era of larger system software >volumes, particularly because system software is such a small fraction of the >disk space requirements for nearly any 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? 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
Jesse 1 Robinson wrote: I sympathize with IBM's predicament in reading the future maintenance tea leaves. The 'fix rate' 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. 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? -- John Eells IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
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 robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Eells Sent: Thursday, October 04, 2018 4:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: S106 abends after copying into LINKLIST Elardus Engelbrecht wrote: > This is why you see in Program Directories the required space for each > dataset/OMVS files needed for each product you ordered. Let's just be clear about what those space numbers represent. They are: - a fixed percentage larger (10 or 15%, I forget right now) than 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 ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
Elardus Engelbrecht wrote: This is why you see in Program Directories the required space for each dataset/OMVS files needed for each product you ordered. Let's just be clear about what those space numbers represent. They are: - a fixed percentage larger (10 or 15%, I forget right now) than 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 ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
Jesse 1 Robinson wrote: >Whether 'tis nobler in the mind to suffer >The slings and arrows of secondary extents, >Or to take arms against a sea of B37s, >And by opposing end them? Good one. +1 for you. For me: c all 'B37' 'ICH408I' ;-) >Gil may have been right about this being 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. >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 ... >... 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. >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... :-( >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 Seymour J Metz wrote: >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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
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 robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Wednesday, October 03, 2018 1:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: S106 abends after copying into LINKLIST I 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 on behalf of Ed Jaffe Sent: Tuesday, October 2, 2018 7:06 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: S106 abends after copying into LINKLIST On 10/2/2018 8:43 AM, Seymour J Metz wrote: > I prefer to avoid the problem by never 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... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 on behalf of Ed Jaffe Sent: Tuesday, October 2, 2018 7:06 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: S106 abends after copying into LINKLIST On 10/2/2018 8:43 AM, Seymour J Metz wrote: > I prefer to avoid the problem by never 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: S106 abends after copying into LINKLIST
On 10/3/2018 10:46 AM, Paul Gilmartin wrote: On Wed, 3 Oct 2018 10:04:44 -0700, Ed Jaffe wrote: The issue is the connection created by FIND and traditional BLDL. The newfangled BLDL NOCONNECT avoids gratuitous connections to members you don't really intend to access, but at some point if you're 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. 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: S106 abends after copying into LINKLIST
On Wed, 3 Oct 2018 10:04:44 -0700, Ed Jaffe wrote: > >The issue is the connection created by FIND and traditional BLDL. The >newfangled BLDL NOCONNECT avoids gratuitous connections to members you >don't really intend to access, but at some point if you're gonna read in >the member, you're gonna 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: S106 abends after copying into LINKLIST
On 10/2/2018 10:30 PM, Peter Hunkeler wrote: Are you sure space is reclaimed for deleted members if the data set is open by LNKLST? Interesting question. Easy to test for someone with a sandbox system (I don't have any such to play with). Well, one could test with STEPLIB but that does not 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. 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: S106 abends after copying into LINKLIST
On Wed, 3 Oct 2018 07:30:09 +0200, Peter Hunkeler wrote: >>Are you sure space is reclaimed for deleted members if the data set is open >>by LNKLST? > >Interesting question. Easy to test for someone with a sandbox system (I don't >have any such to play with). Well, one could test with STEPLIB 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. > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
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" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, October 2, 2018 6:11:29 PM Subject: Re: S106 abends after copying into LINKLIST On 10/2/2018 12:32 PM, Carmen Vitullo wrote: > Got me, I've never had an issue with a PDS/E in the linklist, PDS/E's for me > solved some issues with directory block allocation and having the ability to > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
>And never put your LNKLST datasets in SMS I strongly disagree with this statement. There is nothing wrong with having your LNKLST data sets be SMS-managed. There is nothing wrong with having PDSEs in the LNKLST. >Update your LNKLST dynamically. Sure. But do not use LNKLST UPDATE JOB(*) 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
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. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Peter Hunkeler > Sent: Tuesday, October 02, 2018 10:30 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: AW: Re: S106 abends after copying into LINKLIST > > >Are you sure space is reclaimed for deleted members if the data set is open > by LNKLST? > > > Interesting question. Easy to test for someone with a sandbox system (I > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
On 10/2/2018 12:32 PM, Carmen Vitullo wrote: Got me, I've never had an issue with a PDS/E in the linklist, PDS/E's for me solved some issues with directory block allocation and having the ability to 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
On 10/2/2018 8:43 AM, Seymour J Metz wrote: I prefer to avoid the problem by never 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
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" <000433f07816-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, October 2, 2018 2:01:27 PM Subject: Re: S106 abends after copying into LINKLIST On Tue, 2 Oct 2018 13:28:27 -0400, Carmen Vitullo wrote: >absolutely agree, my link list lib's 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. > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
On Tue, 2 Oct 2018 13:28:27 -0400, Carmen Vitullo wrote: >absolutely agree, my link list lib's 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. > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
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" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, October 2, 2018 12:15:21 PM Subject: Re: S106 abends after copying into LINKLIST Never, ever let your LINKLST go into secondary's. Otherwise you will quickly learn how to Update your LNKLST dynamically. And never put your LNKLST datasets in SMS -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, October 2, 2018 12:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST On Tue, 2 Oct 2018 15:34:44 +, Seymour J Metz wrote: >Alas, your allocation can still get another extent, but I'd prefer that nobody >explain how; >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? > >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) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
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 .2 cents Carmen Vitullo - Original Message - From: "Eileen Barkow" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, October 2, 2018 10:42:25 AM Subject: Re: S106 abends after copying into LINKLIST I agree that this maintenance 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-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Tuesday, October 02, 2018 11:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST > Perhaps someone can offer a plausible explanation for this, so that > the MVS group will stop blaming the CICS group for the problem. An explanation will not stop the MVS group from blaming the CICS group for a problem caused by the CICS group. 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 on behalf of Barkow, Eileen Sent: Monday, October 1, 2018 10:09 AM To: IBM-MAIN@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the messag
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-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, October 2, 2018 12:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST On Tue, 2 Oct 2018 15:34:44 +, Seymour J Metz wrote: >Alas, your allocation can still get another extent, but I'd prefer that nobody >explain how; >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? > >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) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
On Tue, 2 Oct 2018 15:34:44 +, Seymour J Metz wrote: >Alas, your allocation can still get another extent, but I'd prefer that nobody >explain how; >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? > >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) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
On Tue, 2 Oct 2018 09:01:02 -0400, John Eells wrote: > >*I expect most people to move to thin provisioned volumes over time >because the business case is compelling. On TP volumes, there is no >reason not to use very large primary extents, which can obviate any >advantage to secondary space 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
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-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Tuesday, October 02, 2018 11:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST Because otherwise you risk an S106. A better question is why you didn't consult with the MVS group and devise a bulletproof maintenance strategy. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Barkow, Eileen Sent: Monday, October 1, 2018 10:21 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: S106 abends after copying into LINKLIST The whole idea was not to have to refresh LLA - we wanted to wait until the IPL. Why should LLA have to be refreshed if we did not want the changes to take effect? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of ITschak Mugzach Sent: Monday, October 01, 2018 10:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST You need to refresh lla. בתאריך יום ב׳, 1 באוק׳ 2018, 16:10, מאת Barkow, Eileen < ebar...@doitt.nyc.gov>: > Hi MVS gurus. > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
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 on behalf of Ed Jaffe Sent: Tuesday, October 2, 2018 2:33 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: S106 abends after copying into LINKLIST On 10/1/2018 1:34 PM, Jesse 1 Robinson wrote: > There are two separate problems here. (1) A link list 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://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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Tuesday, October 02, 2018 11:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST > Perhaps someone can offer a plausible explanation for this, so that > the MVS group will stop blaming the CICS group for the problem. An explanation will not stop the MVS group from blaming the CICS group for a problem caused by the CICS group. 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 on behalf of Barkow, Eileen Sent: Monday, October 1, 2018 10:09 AM To: IBM-MAIN@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
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 on behalf of Barkow, Eileen Sent: Monday, October 1, 2018 10:33 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: S106 abends after copying into LINKLIST The dataset is a standard pds (CICS SDFHLINK). We used some sort of SAS proc/clists to empty out the members before copying 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-MAIN@LISTSERV.UA.EDU] On Behalf Of Massimo Biancucci Sent: Monday, October 01, 2018 10:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST Hi, only to better understand. Is the loadlib a standard PDS ? Was it compressed ? Is the loadlib a PDSE ? This could better explain the incident. Best regards. Max Il giorno lun 1 ott 2018 alle ore 16:10 Barkow, Eileen < ebar...@doitt.nyc.gov> ha scritto: > Hi MVS gurus. > Perhaps someone 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
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 on behalf of Carmen Vitullo Sent: Monday, October 1, 2018 11:55 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: S106 abends after copying into LINKLIST There's the key, in the allocation, if I allocate space for a linklist library I DO NOT specify any secondary allocation, 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" To: IBM-MAIN@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] < 00f1be92566d-dmarc-requ...@listserv.ua.edu> wrote: > 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: SYSTEM: > 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-MAIN@LISTSERV.UA.EDU] On > Behalf Of Barkow, Eileen > Sent: Monday, October 01, 2018 10:48 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: S106 abends after copying into LINKLIST > > 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-MAIN@LISTSERV.UA.EDU] On > Behalf Of Lizette Koehler > Sent: Monday, October 01, 2018 10:45 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: S106 abends after copying into LINKLIST > > What the Dataset where the modules were staged shared among Plexes or are > just > allocated to one Plex (but shared among any members in that 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_KQ8DpRQhNwB8jYpUyN8DzUe3
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 on behalf of Barkow, Eileen Sent: Monday, October 1, 2018 10:21 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: S106 abends after copying into LINKLIST The whole idea was not to have to refresh LLA - we wanted to wait until the IPL. Why should LLA have to be refreshed if we did not want the changes to take effect? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of ITschak Mugzach Sent: Monday, October 01, 2018 10:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST You need to refresh lla. בתאריך יום ב׳, 1 באוק׳ 2018, 16:10, מאת Barkow, Eileen < ebar...@doitt.nyc.gov>: > Hi MVS gurus. > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
> Perhaps someone can offer a plausible explanation for this, so that > the MVS group will stop blaming the CICS group for the problem. An explanation will not stop the MVS group from blaming the CICS group for a problem caused by the CICS group. 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 on behalf of Barkow, Eileen Sent: Monday, October 1, 2018 10:09 AM To: IBM-MAIN@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
John Eells wrote: exceeding the link list extent limit the topic of this thread That should read, "...exceeding the link list extent limit *and* the topic of this thread" -- John Eells IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
Ed Jaffe wrote: I never liked defining secondary of zero. I realize it's IBM's recommendation, but it all but ensures a compress will be performed when the library fills up. I've had systems crash either during or after such a compress -- sometimes with disastrous consequences! Whether it's "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 IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
I use 60 % free space. In this way, the entire contents can be replaced (if needed) and also allows for some growth. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Blake, Daniel J [CTR] Sent: Tuesday, October 2, 2018 5:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST When building a new system or adding maintenance I go back through all LNK, LPA and APF libraries making sure they all have at least 20% free space. If for no other reason getting setup for the next maintenance cycle. When I'm bored, which is 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-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, Kees (ITOPT1) - KLM Sent: Tuesday, October 02, 2018 2:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying 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. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Ed Jaffe > Sent: 02 October, 2018 8:33 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: S106 abends after copying into LINKLIST > > On 10/1/2018 1:34 PM, Jesse 1 Robinson wrote: > > There are two separate problems here. (1) A link list 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://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .phoenixsoftware.com%2Fdata=02%7C01%7Callan.staller%40HCL.COM%7Ce > 5b22f96eb864d1712df08d62855ad14%7C189de737c93a4f5a8b686f4ca9941912%7C0 > %7C0%7C636740745807628066sdata=%2Bq5m1B%2BWqBPQLMrX%2BwfqTsTuniUY > PzuVswtZNlub6i8%3Dreserved=0 > > > -- > -- > > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
When building a new system or adding maintenance I go back through all LNK, LPA and APF libraries making sure they all have at least 20% free space. If for no other reason getting setup for the next maintenance cycle. When I'm bored, which is 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-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, Kees (ITOPT1) - KLM Sent: Tuesday, October 02, 2018 2:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying 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. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Ed Jaffe > Sent: 02 October, 2018 8:33 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: S106 abends after copying into LINKLIST > > On 10/1/2018 1:34 PM, Jesse 1 Robinson wrote: > > There are two separate problems here. (1) A link list 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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.
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. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Ed Jaffe > Sent: 02 October, 2018 8:33 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: S106 abends after copying into LINKLIST > > On 10/1/2018 1:34 PM, Jesse 1 Robinson wrote: > > There are two separate problems here. (1) A link list 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
On 10/1/2018 1:34 PM, Jesse 1 Robinson wrote: There are two separate problems here. (1) A link list library taking a new extent after IPL. (2) An LLA-managed library having contents moved by either compress or reload. (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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
Skip nailed it! -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jesse 1 Robinson Sent: Monday, October 1, 2018 3:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST There are two separate problems here. (1) A link list library 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 robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of ITURIEL DO NASCIMENTO NETO Sent: Monday, October 01, 2018 12:37 PM To: IBM-MAIN@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-MAIN@LISTSERV.UA.EDU] Em nome de Carmen Vitullo Enviada em: segunda-feira, 1 de outubro de 2018 11:29 Para: IBM-MAIN@LISTSERV.UA.EDU Assunto: Re: S106 abends after copying into LINKLIST 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" To: IBM-MAIN@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessari
Re: S106 abends after copying into LINKLIST
Moral of the story (to the OP).] Don't update LNKLST until ready for IPL. BTW, the SAS PDS empty does perform the compress. When all members have been deleted, the directory is essentially the same as it would have been for a newly allocated PDS. HTH ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
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 robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of ITURIEL DO NASCIMENTO NETO Sent: Monday, October 01, 2018 12:37 PM To: IBM-MAIN@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-MAIN@LISTSERV.UA.EDU] Em nome de Carmen Vitullo Enviada em: segunda-feira, 1 de outubro de 2018 11:29 Para: IBM-MAIN@LISTSERV.UA.EDU Assunto: Re: S106 abends after copying into LINKLIST 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" To: IBM-MAIN@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
On Mon, 1 Oct 2018 16:51:26 +, Jesse 1 Robinson wrote: >What's with these CICS people anyway? ;-) ... >... >-- Compressing a PDS moves modules around. The directory is updated >accordingly, but LLA is not automatically notified. The next fetch for the >previous location will surely fail. > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
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 robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: Monday, October 01, 2018 8:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: S106 abends after copying into LINKLIST 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" To: IBM-MAIN@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] < 00f1be92566d-dmarc-requ...@listserv.ua.edu> wrote: > 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: SYSTEM: > 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-MAIN@LISTSERV.UA.EDU] > On Behalf Of Barkow, Eileen > Sent: Monday, October 01, 2018 10:48 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: S106 abends after copying into LINKLIST > > 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 M
Re: S106 abends after copying into LINKLIST
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-MAIN@LISTSERV.UA.EDU] On Behalf Of Blake, Daniel J [CTR] Sent: Monday, October 01, 2018 12:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST I got that. Just wanted to point out there is a situation where a data set can have secondary extents even though you did not specify any during the allocation. Dan On: 01 October 2018 12:11, "Barkow, Eileen" mailto:ebar...@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-MAIN@LISTSERV.UA.EDU] On Behalf Of Blake, Daniel J [CTR] Sent: Monday, October 01, 2018 11:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST Very interesting conversation. Kind of related, like a third cousin is what I found: ,SDSF OUTPUT DISPLAY CSV_LNKLST_SPACE LINE 0 COLUMNS ,COMMAND INPUT ===>, ,SCROLL == * TOP OF DATA ** CHECK(IBMCSV,CSV_LNKLST_SPACE) SYSPLEX: SYSTEM: 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 EXT92 LINE 1-37 (91) COMMAND INPUT ===>, ,SCROLL ===>,CSR , PREFIX=* DEST=(ALL) OWNER=* SORT=EXTENT/D SYSNAME= NP DSNAME Seq VolSer BlkSize Extent SMS APFLRecL SYS2.BMC.DB2BMCLINK 66 ISVM06 23476 2 NO YES 0 PO SYS2.GENER.LOAD1 ISVM06 32760 1 NO NO 0 PO Dan -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Barkow, Eileen Sent: Monday, October 01, 2018 10:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST 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-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, October 01, 2018 10:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST What the Dataset where the modules were staged shared among Plexes or are just allocated to one Plex (but shared among any members in that 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 > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Barkow, Eileen > Sent: Monday, October 01, 2018 7:10 AM > To: IBM-MAIN@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 FA
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" mailto:ebar...@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-MAIN@LISTSERV.UA.EDU] On Behalf Of Blake, Daniel J [CTR] Sent: Monday, October 01, 2018 11:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST Very interesting conversation. Kind of related, like a third cousin is what I found: ,SDSF OUTPUT DISPLAY CSV_LNKLST_SPACE LINE 0 COLUMNS ,COMMAND INPUT ===>, ,SCROLL == * TOP OF DATA ** CHECK(IBMCSV,CSV_LNKLST_SPACE) SYSPLEX: SYSTEM: 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 EXT92 LINE 1-37 (91) COMMAND INPUT ===>, ,SCROLL ===>,CSR , PREFIX=* DEST=(ALL) OWNER=* SORT=EXTENT/D SYSNAME= NP DSNAME Seq VolSer BlkSize Extent SMS APFLRecL SYS2.BMC.DB2BMCLINK 66 ISVM06 23476 2 NO YES 0 PO SYS2.GENER.LOAD1 ISVM06 32760 1 NO NO 0 PO Dan -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Barkow, Eileen Sent: Monday, October 01, 2018 10:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST 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-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, October 01, 2018 10:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST What the Dataset where the modules were staged shared among Plexes or are just allocated to one Plex (but shared among any members in that 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 > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Barkow, Eileen > Sent: Monday, October 01, 2018 7:10 AM > To: IBM-MAIN@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, pr
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" To: IBM-MAIN@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] < 00f1be92566d-dmarc-requ...@listserv.ua.edu> wrote: > 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: SYSTEM: > 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-MAIN@LISTSERV.UA.EDU] On > Behalf Of Barkow, Eileen > Sent: Monday, October 01, 2018 10:48 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: S106 abends after copying into LINKLIST > > 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-MAIN@LISTSERV.UA.EDU] On > Behalf Of Lizette Koehler > Sent: Monday, October 01, 2018 10:45 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: S106 abends after copying into LINKLIST > > What the Dataset where the modules were staged shared among Plexes or are > just > allocated to one Plex (but shared among any members in that 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 > > > > -Original Message- > > From: IBM Mainframe Discussion List On > Behalf Of > > Barkow, Eileen > > Sent: Monday, October 01, 2018 7:10 AM > > To: IBM-MAIN@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 d
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] < 00f1be92566d-dmarc-requ...@listserv.ua.edu> wrote: > 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: SYSTEM: > 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 EXT92 LINE 1-37 (91) > COMMAND INPUT ===>, ,SCROLL > ===>,CSR , > PREFIX=* DEST=(ALL) OWNER=* SORT=EXTENT/D SYSNAME= > NP DSNAME Seq VolSer > BlkSize Extent SMS APFLRecL > SYS2.BMC.DB2BMCLINK 66 ISVM06 23476 > 2 NO YES 0 PO > SYS2.GENER.LOAD1 ISVM06 > 32760 1 NO NO 0 PO > > > Dan > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Barkow, Eileen > Sent: Monday, October 01, 2018 10:48 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: S106 abends after copying into LINKLIST > > 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-MAIN@LISTSERV.UA.EDU] On > Behalf Of Lizette Koehler > Sent: Monday, October 01, 2018 10:45 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: S106 abends after copying into LINKLIST > > What the Dataset where the modules were staged shared among Plexes or are > just > allocated to one Plex (but shared among any members in that 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 > > > > -Original Message- > > From: IBM Mainframe Discussion List On > Behalf Of > > Barkow, Eileen > > Sent: Monday, October 01, 2018 7:10 AM > > To: IBM-MAIN@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- F
Re: S106 abends after copying into LINKLIST
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-MAIN@LISTSERV.UA.EDU] On Behalf Of Blake, Daniel J [CTR] Sent: Monday, October 01, 2018 11:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST Very interesting conversation. Kind of related, like a third cousin is what I found: ,SDSF OUTPUT DISPLAY CSV_LNKLST_SPACE LINE 0 COLUMNS ,COMMAND INPUT ===>, ,SCROLL == * TOP OF DATA ** CHECK(IBMCSV,CSV_LNKLST_SPACE) SYSPLEX: SYSTEM: 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 EXT92 LINE 1-37 (91) COMMAND INPUT ===>, ,SCROLL ===>,CSR , PREFIX=* DEST=(ALL) OWNER=* SORT=EXTENT/D SYSNAME= NP DSNAME Seq VolSer BlkSize Extent SMS APFLRecL SYS2.BMC.DB2BMCLINK 66 ISVM06 23476 2 NO YES 0 PO SYS2.GENER.LOAD1 ISVM06 32760 1 NO NO 0 PO Dan -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Barkow, Eileen Sent: Monday, October 01, 2018 10:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST 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-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, October 01, 2018 10:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST What the Dataset where the modules were staged shared among Plexes or are just allocated to one Plex (but shared among any members in that 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 > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Barkow, Eileen > Sent: Monday, October 01, 2018 7:10 AM > To: IBM-MAIN@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 us
Re: S106 abends after copying into LINKLIST
It probably includes a compress > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Lizette Koehler > Sent: Monday, October 01, 2018 7:53 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: S106 abends after copying into LINKLIST > > 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 > > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Barkow, Eileen > > Sent: Monday, October 01, 2018 7:48 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: S106 abends after copying into LINKLIST > > > > Thanks Lizette. > > > > The dataset is was emptied/copied in a different lpar than where it is used. > > But as was explained, the pds directory got altered by the empty > > member procedure and no LLA REFRESH was done. > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM- > m...@listserv.ua.edu] > > On Behalf Of Lizette Koehler > > Sent: Monday, October 01, 2018 10:45 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: S106 abends after copying into LINKLIST > > > > What the Dataset where the modules were staged shared among Plexes or > > are just allocated to one Plex (but shared among any members in that > > 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=DwICAg=C3yme8gMkxg_ihJNXS06ZyWk4EJ > m8LdrrvxQb- > Je7sw=u9g8rUevBoyCPAdo5sWE9w=SSH0jhO6X7PmFrTFoUlzrgHfxMh > w78-yYm11eiLkzS8=Q2WQ12FSAwlkrSDKWIWKwTcy4- > 1tlVJA0mEoO2gowpY=. > > ida > > u100/pdse.htm > > > > > > Lizette > > > > > > > -Original Message- > > > From: IBM Mainframe Discussion List > On > > > Behalf Of Barkow, Eileen > > > Sent: Monday, October 01, 2018 7:10 AM > > > To: IBM-MAIN@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 imm
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: SYSTEM: 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 EXT92 LINE 1-37 (91) COMMAND INPUT ===>, ,SCROLL ===>,CSR , PREFIX=* DEST=(ALL) OWNER=* SORT=EXTENT/D SYSNAME= NP DSNAME Seq VolSer BlkSize Extent SMS APFLRecL SYS2.BMC.DB2BMCLINK 66 ISVM06 23476 2 NO YES 0 PO SYS2.GENER.LOAD1 ISVM06 32760 1 NO NO 0 PO Dan -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Barkow, Eileen Sent: Monday, October 01, 2018 10:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST 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-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, October 01, 2018 10:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST What the Dataset where the modules were staged shared among Plexes or are just allocated to one Plex (but shared among any members in that 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 > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Barkow, Eileen > Sent: Monday, October 01, 2018 7:10 AM > To: IBM-MAIN@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 > lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---
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 > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Barkow, Eileen > Sent: Monday, October 01, 2018 7:48 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: S106 abends after copying into LINKLIST > > Thanks Lizette. > > The dataset is was emptied/copied in a different lpar than where it is used. > But as was explained, the pds directory got altered by the empty member > procedure and no LLA REFRESH was done. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Lizette Koehler > Sent: Monday, October 01, 2018 10:45 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: S106 abends after copying into LINKLIST > > What the Dataset where the modules were staged shared among Plexes or are > just allocated to one Plex (but shared among any members in that 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 > > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Barkow, Eileen > > Sent: Monday, October 01, 2018 7:10 AM > > To: IBM-MAIN@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, October 01, 2018 10:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST What the Dataset where the modules were staged shared among Plexes or are just allocated to one Plex (but shared among any members in that 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 > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Barkow, Eileen > Sent: Monday, October 01, 2018 7:10 AM > To: IBM-MAIN@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 > lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
Thank you for the explanation - The emptying of the pds must have caused the problem. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: Monday, October 01, 2018 10:36 AM To: IBM-MAIN@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" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, October 1, 2018 9:33:01 AM Subject: Re: S106 abends after copying into LINKLIST The dataset is a standard pds (CICS SDFHLINK). We used some sort of SAS proc/clists to empty out the members before copying the new ones 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-MAIN@LISTSERV.UA.EDU] On Behalf Of Massimo Biancucci Sent: Monday, October 01, 2018 10:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST Hi, only to better understand. Is the loadlib a standard PDS ? Was it compressed ? Is the loadlib a PDSE ? This could better explain the incident. Best regards. Max Il giorno lun 1 ott 2018 alle ore 16:10 Barkow, Eileen < ebar...@doitt.nyc.gov> ha scritto: > Hi MVS gurus. > Perhaps someone 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Barkow, Eileen > Sent: Monday, October 01, 2018 7:10 AM > To: IBM-MAIN@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 > lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
We did not refresh LLA - looks like we should have. Thanks everyone. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Monday, October 01, 2018 10:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST Did you refresh LLA? -Original Message- From: IBM Mainframe Discussion List On Behalf Of Barkow, Eileen Sent: Monday, October 01, 2018 10:10 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: S106 abends after copying into LINKLIST **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click 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 lists...@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
Did you refresh LLA? -Original Message- From: IBM Mainframe Discussion List On Behalf Of Barkow, Eileen Sent: Monday, October 01, 2018 10:10 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: S106 abends after copying into LINKLIST **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click 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 lists...@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
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 On Behalf Of Barkow, Eileen Sent: Monday, October 01, 2018 10:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** The 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-MAIN@LISTSERV.UA.EDU] On Behalf Of ITschak Mugzach Sent: Monday, October 01, 2018 10:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST You need to refresh lla. בתאריך יום ב׳, 1 באוק׳ 2018, 16:10, מאת Barkow, Eileen < ebar...@doitt.nyc.gov>: > Hi MVS gurus. > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, October 1, 2018 9:33:01 AM Subject: Re: S106 abends after copying into LINKLIST The dataset is a standard pds (CICS SDFHLINK). We used some sort of SAS proc/clists to empty out the members before copying the new ones 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-MAIN@LISTSERV.UA.EDU] On Behalf Of Massimo Biancucci Sent: Monday, October 01, 2018 10:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST Hi, only to better understand. Is the loadlib a standard PDS ? Was it compressed ? Is the loadlib a PDSE ? This could better explain the incident. Best regards. Max Il giorno lun 1 ott 2018 alle ore 16:10 Barkow, Eileen < ebar...@doitt.nyc.gov> ha scritto: > Hi MVS gurus. > Perhaps someone 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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-MAIN@LISTSERV.UA.EDU] On Behalf Of Massimo Biancucci Sent: Monday, October 01, 2018 10:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST Hi, only to better understand. Is the loadlib a standard PDS ? Was it compressed ? Is the loadlib a PDSE ? This could better explain the incident. Best regards. Max Il giorno lun 1 ott 2018 alle ore 16:10 Barkow, Eileen < ebar...@doitt.nyc.gov> ha scritto: > Hi MVS gurus. > Perhaps someone 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
Faudian slip concatenation not contamination :) Carmen Vitullo - Original Message - From: "Carmen Vitullo" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, October 1, 2018 9:29:22 AM Subject: Re: S106 abends after copying into LINKLIST the only time I've see this 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" To: IBM-MAIN@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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" To: IBM-MAIN@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
Sounds like somebody compressed the linklist library that contained the modules. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Barkow, Eileen Sent: Monday, October 01, 2018 9:22 AM To: IBM-MAIN@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-MAIN@LISTSERV.UA.EDU] On Behalf Of ITschak Mugzach Sent: Monday, October 01, 2018 10:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST You need to refresh lla. בתאריך יום ב׳, 1 באוק׳ 2018, 16:10, מאת Barkow, Eileen < ebar...@doitt.nyc.gov>: > Hi MVS gurus. > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 < ebar...@doitt.nyc.gov> ha scritto: > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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-MAIN@LISTSERV.UA.EDU] On Behalf Of ITschak Mugzach Sent: Monday, October 01, 2018 10:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST You need to refresh lla. בתאריך יום ב׳, 1 באוק׳ 2018, 16:10, מאת Barkow, Eileen < ebar...@doitt.nyc.gov>: > Hi MVS gurus. > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
You need to refresh lla. בתאריך יום ב׳, 1 באוק׳ 2018, 16:10, מאת Barkow, Eileen < ebar...@doitt.nyc.gov>: > Hi MVS gurus. > Perhaps someone can offer a plausible 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
