> 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
