IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

ABEND due to FETCH FAILED


IBM Mainframe Forums -> ABENDS & Debugging
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
jackzhang75

Active User


Joined: 09 Jun 2014
Posts: 125
Location: US

PostPosted: Thu Mar 10, 2016 3:08 am
Reply with quote

Hi Experts,

I got following error due to i didn't refresh LLA after copying the new module . I know the reason is because of the pointer save in storage is the old so it cant find the new module. But my questions is that how about if nothing changed in term of location and size for new modules . It stay in same location where the old module resides. Even I don’t do the LLA refresh , it should load the new module since LLA only save the time to fetch the module but actually the load module is still in physical DSAD not in virtual memory and It still need actual physical I/O to get the load module, right ?


Code:
S ABENDAID                                                               
$HASP100 ABENDAID ON STCINRDR                                             
IEF695I START ABENDAID WITH JOBNAME ABENDAID IS ASSIGNED TO USER         
ABENDAID                                                                 
$HASP373 ABENDAID STARTED                                                 
ACF9CCCD USERID ABENDAID IS ASSIGNED TO THIS JOB - ABENDAID               
IEF403I ABENDAID - STARTED - TIME=07.26.42                               
IEW4009I FETCH FAILED FOR MODULE CWINSTAL FROM DDNAME -LNKLST- BECAUSE   
OF AN I/O ERROR.                                                         
IEW4005I FETCH FOR MODULE CWINSTAL FROM DDNAME -LNKLST- FAILED BECAUSE   
IEWFETCH ISSUED RC 0F AND REASON 40                                       
CSV031I LIBRARY ACCESS FAILED FOR MODULE CWINSTAL, RETURN CODE 24,       
REASON CODE 26080021, DDNAME *LNKLST*                                     
CSV028I ABEND106-0F  JOBNAME=ABENDAID  STEPNAME=ABENDAID   
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA

PostPosted: Thu Mar 10, 2016 3:52 am
Reply with quote

It does NOT stay in the same location. When you update a PDS member, the space currently in use is left unused and the member moved to the end of the data set. This is why compresses are needed. Since LLA uses the directory location of the member, updating the member means a refresh is needed.
Back to top
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 917
Location: The Universe

PostPosted: Thu Mar 10, 2016 7:10 am
Reply with quote

Mr. Sample is correct. When you “copy” a module, even if it replaces an existing module, it is always added to the end of the data set. For example, I ran this JCL.
Code:
//A       EXEC PGM=IEFBR14
//LM       DD  DISP=(MOD,DELETE),UNIT=SYSALLDA,SPACE=(TRK,0),
//             DSN=&SYSUID..COPYLM.LOAD
//B       EXEC PGM=IEBCOPY
//SYSPRINT DD  SYSOUT=*
//I        DD  DISP=(SHR,PASS),DSN=&SYSUID..LOAD
//O        DD  DISP=(,CATLG),UNIT=SYSDA,SPACE=(CYL,(1,1,1)),
//             DSN=*.A.LM
//SYSIN    DD  *
 C I=I,O=O
 S M=(TSOLPDIR,LISTPDS)
//C       EXEC PGM=IKJEFT01,
// PARM='LISTPDS COPYLM.LOAD DUMP'
//STEPLIB  DD  DISP=(SHR,PASS),DSN=*.A.LM
//SYSTSPRT DD  SYSOUT=*
//SYSTSIN  DD  DUMMY
//D       EXEC PGM=IEBCOPY
//SYSPRINT DD  SYSOUT=*
//I        DD  DISP=(SHR,PASS),DSN=&SYSUID..LOAD
//O        DD  DISP=OLD,
//             DSN=*.A.LM
//SYSIN    DD  *
 C I=((I,R)),O=O
 S M=(TSOLPDIR,LISTPDS)
//E       EXEC PGM=IKJEFT01,
// PARM='LISTPDS COPYLM.LOAD DUMP'
//STEPLIB  DD  DISP=(SHR,PASS),DSN=*.A.LM
//SYSTSPRT DD  SYSOUT=*
//SYSTSIN  DD  DUMMY
//F       EXEC PGM=IEBCOPY
//SYSPRINT DD  SYSOUT=*
//I        DD  DISP=(SHR,PASS),DSN=&SYSUID..LOAD
//O        DD  DISP=OLD,
//             DSN=*.A.LM
//SYSIN    DD  *
 C I=((I,R)),O=O
 S M=(TSOLPDIR,LISTPDS)
//G       EXEC PGM=IKJEFT01,
// PARM='LISTPDS COPYLM.LOAD DUMP'
//STEPLIB  DD  DISP=(SHR,PASS),DSN=*.A.LM
//SYSTSPRT DD  SYSOUT=*
//SYSTSIN  DD  DUMMY
//H       EXEC PGM=PDSGAS
//STEPLIB  DD  DISP=(SHR,PASS),DSN=&SYSUID..LOAD
//SYSPRINT DD  SYSOUT=*
//SYSUT1   DD  DISP=OLD,DSN=*.A.LM
LISTPDS is a TSO command processor and is an alias of TSOLPDIR. Its output when DUMP is specified mimics the output from the IEHLIST LISTPDS command. The output for the first TSO in batch step is -
Code:
-MEMBER- --TTRC-- --USER DATA (TTRC AND USER DATA ARE HEX)             
LISTPDS  000003B1 0000080000 000000C2E3 0012D812D8 000000881A 01000000E3
                  E2D6D3D7C4 C9D90100                                   
TSOLPDIR 0000032C 0000080000 000000C2E3 0012D812D8 0000008812 01010000 
1 ALLOCATED DIRECTORY BLOCKS, 1 USED DIRECTORY BLOCKS
The first 6 hexadecimal digits after the member name are the location of the first data record for the member – 000003. The output for the second TSO in batch step is -
Code:
-MEMBER- --TTRC-- --USER DATA (TTRC AND USER DATA ARE HEX)             
LISTPDS  00000BB1 0000100000 000000C2E3 0012D812D8 000000881A 01000000E3
                  E2D6D3D7C4 C9D90100                                   
TSOLPDIR 00000B2C 0000100000 000000C2E3 0012D812D8 0000008812 01010000 
1 ALLOCATED DIRECTORY BLOCKS, 1 USED DIRECTORY BLOCKS
And the third -
Code:
-MEMBER- --TTRC-- --USER DATA (TTRC AND USER DATA ARE HEX)             
LISTPDS  000013B1 0000180000 000000C2E3 0012D812D8 000000881A 01000000E3
                  E2D6D3D7C4 C9D90100                                   
TSOLPDIR 0000132C 0000180000 000000C2E3 0012D812D8 0000008812 01010000 
1 ALLOCATED DIRECTORY BLOCKS, 1 USED DIRECTORY BLOCKS
The last step runs a program that locates the space occupied by deleted members; its output is
Code:
DIRECTRY 000001 000001 000002 0125000001 0125000002
*****GAS        000003 00000A 0125000003 012500000A
*****GAS        00000B 000012 012500000B 0125000012
TSOLPDIR 000013 000013 00001A 0125000013 012500001A
The program regards the PDS directory as a member. Much of this output is for debuggging, not really necessary since the last update was in 2007

TSOLPDIR 000013 000013 00001A 0125000013 012500001A

The first set of hexadecimal digits after the member name is the first block address; the second set is the address of the EOF “record” at the end of the member. Since “gas” “members” do not have a directory entry, the first set of hexadecimal digits are not printed.
Back to top
View user's profile Send private message
jackzhang75

Active User


Joined: 09 Jun 2014
Posts: 125
Location: US

PostPosted: Thu Mar 10, 2016 9:36 pm
Reply with quote

Hi Mr samply and steve , really appreicate your answer. Back to my example , What i did is :

1. Copied over the new load modules into LLA /LNKLST for Abend-Aid
3. Not refresh LLA
2. Issued the command /S Abendaid to start the product

Then i got the fetch I/O error . According to your answer , when updated the same module , the loaction for new load module should be at end of PDS so it should still can exceute the old module since the pointer is not changed. I don't undersand , whey i get this error ?
Back to top
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 917
Location: The Universe

PostPosted: Thu Mar 10, 2016 9:43 pm
Reply with quote

Jack: I do not think you bothered to actually read my long post. You do not "copy over" a load module. That is not possible. You added the new modules at the end of the library, deleted the old names in the directory, and added the same names to the directory, as was done in my example.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA

PostPosted: Thu Mar 10, 2016 10:42 pm
Reply with quote

You got the error because the LINKLIST contains directory pointers to the modules. When you updated a module, you moved the member to the end of the PDS, which changes the directory pointer. Since you did not do the LLA refresh, the LINKLIST continued to point to the where the module USED to be. Hence the fetch failed as there no longer is any data at the location on the disk -- the member got moved.
Back to top
View user's profile Send private message
jackzhang75

Active User


Joined: 09 Jun 2014
Posts: 125
Location: US

PostPosted: Fri Mar 11, 2016 1:02 am
Reply with quote

Thank you . Normally when i do the maint for my products , i just copy the updated load module from my SMPE libs to my production lib (LNKLST) then just staging there and wait for IPL to do the refresh. Before IPL i have no issue for these production . How to explan this ?

Like we disscussed before , i should also get fetch error because the module has been moved to end of PDS.

Thanks
Back to top
View user's profile Send private message
jackzhang75

Active User


Joined: 09 Jun 2014
Posts: 125
Location: US

PostPosted: Fri Mar 11, 2016 1:30 am
Reply with quote

Found the following from IBM red book ABC system progrming . How LLA still can find old module since pointer has changed.

"Whenever you update a load module in a library that LLA manages, make sure you follow the update by issuing the appropriate form of the F LLA command. Otherwise, LLA continues to use an older version of a load
module
."
Back to top
View user's profile Send private message
Akatsukami

Global Moderator


Joined: 03 Oct 2009
Posts: 1787
Location: Bloomington, IL

PostPosted: Fri Mar 11, 2016 1:50 am
Reply with quote

jackzhang75 wrote:
Found the following from IBM red book ABC system progrming . How LLA still can find old module since pointer has changed.

Remember that the data (in this case the load module) does not disappear, only the directory entry does.
Back to top
View user's profile Send private message
jackzhang75

Active User


Joined: 09 Jun 2014
Posts: 125
Location: US

PostPosted: Fri Mar 11, 2016 2:20 am
Reply with quote

So now i just confused why sometime it get fectch error sometimes it still can load old module.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA

PostPosted: Fri Mar 11, 2016 2:40 am
Reply with quote

Fetch is done when no previous version has been read. So in your original post the module needed to loaded from disk; if it does not have to be loaded from disk no fetch is done and the LLA discrepancy won't appear. But since you may not know if a previous fetch has been done on the load module, you should always do F LLA,REFRESH after updating the link list.
Back to top
View user's profile Send private message
jackzhang75

Active User


Joined: 09 Jun 2014
Posts: 125
Location: US

PostPosted: Fri Mar 11, 2016 3:22 am
Reply with quote

Thank you Robert. now it make more sense. So weather or not you get I/O error is depends on when the Fetch is done , right ?

So for example , i have a job to excute the program CWPAMAIN .
As soon as i submit this job , it will go to fectch the load module
CWPAMAIN or it used previous done , how to determine this ?

//ASM EXEC PGM=CWPAMAIN, <--- CHECK
// REGION=4096K,
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA

PostPosted: Fri Mar 11, 2016 7:41 am
Reply with quote

Quote:
it will go to fectch the load module CWPAMAIN or it used previous done , how to determine this ?
One of the points we're trying to get across to you is that YOU DON'T KNOW AND YOU CANNOT FIND OUT (at least, not in any easy way -- it may or may not be available by going through control blocks but that would require a LOT of research). Just accept that you do an F LLA,REFRESH after an update to the LINKLIST and go on.
Back to top
View user's profile Send private message
jackzhang75

Active User


Joined: 09 Jun 2014
Posts: 125
Location: US

PostPosted: Fri Mar 11, 2016 7:14 pm
Reply with quote

Thank you Robert. How about if lnklst is PDSE not PDS?
Back to top
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 917
Location: The Universe

PostPosted: Fri Mar 11, 2016 7:33 pm
Reply with quote

  • Unless the program referenced in // EXEC PGM=xxx is in the LPA, it will not be available. But it takes an IPL to refresh LPA. Many products load modules into CSA to provide a pseudo LPA when they start. I do not know if ABENDAID is one of them. If CWPAMAIN is the ABENDAID initializer, it's unlikely to be in the pseudo LPA.
  • LLA refresh updates the directory, but it the library added an extent to store the module, the new extent will not be available until the system is IPLed. This WILL result in an I/O error.
I cannot answer your query about a PDSE from my own knowledge. I speculate that since PDSE reuses space, strange things can happen.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA

PostPosted: Fri Mar 11, 2016 7:48 pm
Reply with quote

The issue is with how the directory is updated and the LINKLIST not pointing to the current member after an update, so using PDSE instead of PDS in the LINKLIST doesn't really change anything -- a PDSE still uses directory entries, and does not put replaced members back where they came from -- find the Using Data Sets manual and look up PDSE gas for more information. A PDSE in the LINKLIST is helpful as it only takes one extent out of the 255 available to the LINKLIST, but you can still get fetch errors and S106 abends with a PDSE.
Back to top
View user's profile Send private message
jackzhang75

Active User


Joined: 09 Jun 2014
Posts: 125
Location: US

PostPosted: Fri Mar 11, 2016 8:05 pm
Reply with quote

Thank you Robert. very nice answer.

Stave, can you tell me more about pseudo LPA , it was very intereting . Product will load the modle into CSA and keep in there until IPL ?
Back to top
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 917
Location: The Universe

PostPosted: Fri Mar 11, 2016 10:08 pm
Reply with quote

jackzhang75 wrote:
... Steve, can you tell me more about pseudo LPA , it was very intereting . Product will load the modle into CSA and keep in there until IPL ?
I don't know all that much. Yes, the module storage persists - usually - until the next IPL. Module information is kept in the same control structures that are used for MLPA. The module search is slower because the control structure is less conclusive for a fast lookup.

I said the module storage persists to the next IPL because it may be used by a program even if the lookup information has changed, so it's dangerous to delete the storage.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> ABENDS & Debugging

 


Similar Topics
Topic Forum Replies
No new posts Call an hlasm from REXX in batch and ... CLIST & REXX 4
No new posts What is the most complex abend you've... Mainframe Interview Questions 8
No new posts To fetch records that has Ttamp value... DFSORT/ICETOOL 5
No new posts ISAM and abend S03B JCL & VSAM 10
No new posts Fetch data from programs execute (dat... DB2 3
Search our Forums:

Back to Top