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 [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Carmen Vitullo Sent: Monday, October 01, 2018 8:56 AM To: [email protected] 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" <[email protected]> To: [email protected] 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] < [email protected]> 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: XXXX SYSTEM: YYYY > START TIME: 10/01/2018 02:11:10.736219 CHECK DATE: 20050720 CHECK > SEVERITY: LOW > > CSVH0983I None of the data sets in LNKLST set LNKLST00 were allocated > with secondary space defined. > > END TIME: 10/01/2018 02:11:11.449077 STATUS: SUCCESSFUL > > > Looks great right? Unless you allocated a data set on a volume that > does not have enough contiguous space. I that case you get this: > > > SDSF LNK DISPLAY SYS1 SYS1 EXT 92 LINE 1-37 (91) COMMAND INPUT ===>, > ,SCROLL ===>,CSR , > PREFIX=* DEST=(ALL) OWNER=* SORT=EXTENT/D SYSNAME= NP DSNAME Seq > VolSer BlkSize Extent SMS APF LRecL SYS2.BMC.DB2BMCLINK 66 ISVM06 > 23476 > 2 NO YES 0 PO > SYS2.GENER.LOAD 1 ISVM06 > 32760 1 NO NO 0 PO > > > Dan > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Barkow, Eileen > Sent: Monday, October 01, 2018 10:48 AM > To: [email protected] > 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:[email protected]] > On Behalf Of Lizette Koehler > Sent: Monday, October 01, 2018 10:45 AM > To: [email protected] > 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.zo > s.v2r1.ida > u100/pdse.htm > <https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.z > os.v2r1.idau100/pdse.htm> > > > Lizette > > > > -----Original Message----- > > From: IBM Mainframe Discussion List <[email protected]> On > Behalf Of > > Barkow, Eileen > > Sent: Monday, October 01, 2018 7:10 AM > > To: [email protected] > > 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 [email protected] with the message: INFO IBM-MAIN
