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" <ebar...@doitt.nyc.gov> 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
