View previous topic :: View next topic
|
Author |
Message |
Siva S
New User
Joined: 26 Mar 2008 Posts: 35 Location: Chennai
|
|
|
|
Hi,
While I was trying to invoke SMPE panel, it is showing the following message,
IEW4009I FETCH FAILED FOR MODULE GIMSTART FROM DDNAME -LNKLST- BECAUSE OF AN I/O ERROR.
IEW4005I FETCH FOR MODULE GIMSTART FROM DDNAME -LNKLST- FAILED BECAUSE IEWFETCH
ISSUED RC 0F AND REASON 40
CSV031I LIBRARY ACCESS FAILED FOR MODULE GIMSTART, RETURN CODE 24, REASON CODE
26080021, DDNAME *LNKLST*
IEW4009I FETCH FAILED FOR MODULE GIMSTART FROM DDNAME -LNKLST- BECAUSE OF AN I/
O ERROR.
IEW4005I FETCH FOR MODULE GIMSTART FROM DDNAME -LNKLST- FAILED BECAUSE IEWFETCH
ISSUED RC 0F AND REASON 40
CSV031I LIBRARY ACCESS FAILED FOR MODULE GIMSTART, RETURN CODE 24, REASON CODE
26080021, DDNAME *LNKLST*
***
After these messages, I got ISPD212 which shows Invalid PGM found. So, I have checked in the PDS for GIMSTART existence. It is there. Then finally I have checked for APF authorization for PDS contains GIMSTART, it is also fine.
But still i am getting the same error while invoking the panel.
Kindly help me to rectify this problem.
Thanks in advance. |
|
Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007 Posts: 8797 Location: Welsh Wales
|
|
|
|
I think here might be a better place to start, rather than at the last message issued.
Please learn to search for and use the manuals before posting.
Quote: |
IEW4005I FETCH FOR MODULE program-name FROM DDNAME ddname FAILED BECAUSE
IEWFETCH ISSUED RC return-code AND REASON reason code.
Explanation: Fetch for the load module failed. The possible hexadecimal return codes and hexadecimal reason codes are as follows:
Return Code
Error Description
00
Processing completed normally.
0B
Program check.
0C
Not enough storage available. Reason Code Error Description 04 No storage for DATD 08 No storage for DEB 0C No storage for IOSB 10 No storage for EXTLIST 14 No storage for module
0D
Bad record area.
0E
Invalid address. Reason Code Error Description 20 Error converting TTR 24 Block outside of module 28 ADCON location invalid
0F
Permanent I/O error. Reason Code Error Description 40 I/O error on a real dataset 44 I/O error on a virtual dataset 48 Seek ADDR outside extent
System Action: An abend will occur unless the program was loaded by a LOAD macro with the ERRET option specified.
User Response: If the reason code indicates lack of module storage (reason 14), rerun the JOB with a larger region size. If the reason code indicates a TTR conversion error or seek address outside of extent, it is possible that the dataset was opened with DISP=SHR by a concurrent task and was updated to cause the number of extents to be increased. In that case the error will persist until the DCB is closed and reopened to cause the DEB to reflect the new extents.
If the error occurred while fetching a module from the linklist, using the commands available via dynamic linklst services to define and activate a new linklst may create a DCB and DEB for the new LNKLST that encompasses the new extents. A TTR conversion error can also occur if a LINK/LOAD/ATTACH/XCTL macro is coded with the DE and DCB parameters if the directory entry was obtained from a different DCB than the one passed in or if the directory entry is modified by the application program. Otherwise either an I/O error has occurred or the data set has been corrupted or built incorrectly.
|
|
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8697 Location: Dubuque, Iowa, USA
|
|
|
|
When I saw the sequence of messages you presented, I thought of two possibilities:
1) a linklist library got compressed and members got moved, or
2) SMP/E APPLY was run and an IPL was not done, thereby causing some linklist problem
unless, of course, you really do have an I/O problem with your linklist libraries in which case you may have to rebuild a disk pack. |
|
Back to top |
|
|
MBabu
Active User
Joined: 03 Aug 2008 Posts: 400 Location: Mumbai
|
|
|
|
I think Robert is correct. Something changed in the link list. I think you can also get this when the link list data sets go to new extents.
I always do a refresh of LLA when this happens, but I'm not on a system that anyone else is using so I can't say if that is the right thing to do in general. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8697 Location: Dubuque, Iowa, USA
|
|
|
|
MBabu, I didn't mention that possibility because our link list files are set up with secondary allocations of zero but if the link list files are allowed to use secondary allocaitons, going into extents could also cause this type of message chain. Thanks for pointing that out! |
|
Back to top |
|
|
|