Interesting APAR OA31970.... I wonder if you might have set the following in ALLOCxx:
SYSTEM IEFBR14_DELMIGDS(NORECALL) I believe the default is IEFBR14_DELMIGDS(LEGACY) which might provide you with better results, while waiting for a fix from IBM. Brian On Thu, 27 May 2010 10:24:12 -0500, Darth Keller wrote: >We have an application which runs a batch job, in one step of which they >use an IEFBR14 to recall multiple GDG's. They do this by specifying the >GDG base with DISP=(MOD,KEEP,KEEP). There are approx.50 DD's in the step >and they have multiple jobs that do this - I try not to judge, but I >certainly can't defend this process. Anyway - > >A stub of the JCL: > >//DD29 DD DSN=JSDT.D1MKE.IM.RUN2.DTGDIG01, >// DISP=(MOD,KEEP,KEEP) > >Prior to the implementation of zOS1.11, this worked successfully every >time. Since we implemented 1.11, every job they have using this process >abends every day with the following: > >IEF344I ADBD090D PS060 JS010 DD29 +002 - ALLOCATION FAILED DUE TO DATA >FACILITY SYSTEM ERROR >IGD17370I UNEXPECTED RETURN CODE FROM UCBLOOK SERVICES WHILE PROCESSING >DATA SET JSDT.D1MKE.IM.RUN2.DTGDIG01.G1138V00 >RETURN CODE IS 4 REASON CODE IS 0 >IGD17203I VOLUME DEFINITION NOT FOUND FOR ALLOCATION OF DATA SET >JSDT.D1MKE.IM.RUN2.DTGDIG01.G1138V00 DDNAME >IGD306I UNEXPECTED ERROR DURING IGDCNS01 PROCESSING >RETURN CODE 5002 REASON CODE 0 >THE MODULE THAT DETECTED THE ERROR IS IGDVTSAR >SMS MODULE TRACE BACK - VTSAR SSIRT >SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00159 > >Their work-around is to issue HRECALL's for the migrated GDG's & then >re-submit the job. We're following up with IBM, but I'm curious to know >if anyone on this august list has implemented 1.11 and seen this same >issue. >thanks - ddk ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
