We're about 27 hours in to our first full day with z/OS in production and 
having a few issues.  Namely things like this:

IEW4009I FETCH FAILED FOR MODULE CVDCDCOP FROM DDNAME DFHRPL   BECAUSE OF AN 
I/O ERROR.                    
IEW4005I FETCH FOR MODULE CVDCDCOP FROM DDNAME DFHRPL   FAILED BECAUSE IEWFETCH 
ISSUED RC 0F AND REASON 40 
CSV031I LIBRARY ACCESS FAILED FOR MODULE CVDCDCOP, RETURN CODE 24, REASON CODE 
26080021, DDNAME DFHRPL     
IEW4009I FETCH FAILED FOR MODULE CVDCDCOP FROM DDNAME DFHRPL   BECAUSE OF AN 
I/O ERROR.                    
IEW4005I FETCH FOR MODULE CVDCDCOP FROM DDNAME DFHRPL   FAILED BECAUSE IEWFETCH 
ISSUED RC 0F AND REASON 40 
CSV031I LIBRARY ACCESS FAILED FOR MODULE CVDCDCOP, RETURN CODE 24, REASON CODE 
26080021, DDNAME DFHRPL     
+DFHLD0203 CICSPATM Loader SVC LOAD request failed due to I/O errors on library 
DFHRPL.                    
+DFHLD0002 CICSPATM A severe error (code X'1925') has occurred in module 
DFHLDLD1.                         
+DFHME0116 CICSPATM  698                                                        
                           
 (Module:DFHMEME) CICS symptom string for message DFHLD0002 is                  
                           
 PIDS/5655S9700 LVLS/660 MS/DFHLD0002 RIDS/DFHLDLD1 PTFS/HCI6600                
                           
 PRCS/00001925                                                                  
                           
+DFHDU0205 CICSPATM A SYSTEM DUMP FOR DUMPCODE: LD0002  , WAS SUPPRESSED BY THE 
DUMP TABLE OPTION FOR THIS 
         DUMPCODE                                                               
                           

I am generally able to just do a PHASEIN and it recovers.  But we need to solve 
the underlying issue.

I think I may have made a bad decision that is causing the issue.  We have all 
of the COBOL CICS programs compiled with the TEST compile option of Enterprise 
COBOL 4.2.  This gives us "TEST(NOHOOK,NOSEPARATE,NOEJPD)".  This includes 
debug symbolics in the load modules and makes them about 10 times larger than 
had I not done this.  Might this make it so we can't load all of the modules in 
to storage at once and thus cause the issue?  If we increase the region size, 
or something else, might this help?  We did this yesterday and it seemed to 
help, but we got bit again at 6am this Morning.  IS there some other "quick 
fix" we can do without requiring a recompile of all modules with NOTEST?

Thanks!!

Frank

-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403


>>> 

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to