On Thu, 6 Feb 2014 14:43:07 -0800, Ray Mullins <[email protected]> wrote:
>Hello, long time absent. > >In z/OS 1.13, I'm playing with instream data in a PROC for the first time to >try to simplify some bind JCL and I've run into an error. It's an atypical >situation, I realize. > >In the PROC I have > >//* Following is a data set created with ISRSCAN from a concatenation >//SYSLPARM DD DSN=&&tempds,DISP=(OLD,DELETE) >// DD * >some more binder parms overriding the first one >//* > >Because one of the program objects needs different stuff, I've coded > >//DRVASTRT EXEC MMB,symbolics >//B.SYSLPARM DD >// DD >// DD * >different parms to override a couple in the first two DDs >//* > >The job hits this step and gives me > >IEF344I MMDB B DRVASTRT SYSLPARM+001 - ALLOCATION FAILED DUE TO DATA >FACILITY SYSTEM ERROR >IGD17045I SPACE NOT SPECIFIED FOR ALLOCATION OF DATA SET >SYS14037.T114830.RA000.MMDB.R0484370 > >It seems like conversion/interpretation has skipped the fact that I'm not >overriding the second DD in the concatenation and is generating a data set >name, instead of noting that it's a blank DD and just leaving the original >DD alone. > > From a logic standpoint, this makes sense, but I'm wondering if this is WAD >(thou shalt not override instream data) or maybe DD concatenation needs some >extra checks if the underlying DD is instream (or does not have a DSN). I am >curious as how this would be handled if the DD was a SUBSYS. > >Yes, I could put the instream data in a PDS member, but for various reasons >that would complicate the underlying binder proc; let's just say we'd rather >not go there. > >So, what's the consensus? WAD? APARable? > >Cheers, >Ray > >-- >M. Ray Mullins >Roseville, CA, USA >http://www.catherdersoftware.com/ > I simplified the batch JCL for use with another IBM utility execution and I got different results - where the second concatenation within the PROC was ignored (overridden) altogether, though I did not get any other type of externalized error (COND CODE 0000 occurred). Here is the JCL I used: //jobname JOB ..... //MYPROC PROC //A EXEC PGM=IEBGENER //SYSPRINT DD DUMMY //SYSIN DD DUMMY //SYSUT1 DD * THIS IS DATA LINE #1 FROM STEP A - INSIDE THE JCL PROC. //SYSUT2 DD UNIT=SYSDA,DISP=(NEW,PASS),DSN=&&TEMPDS //* */ //B EXEC PGM=IEBGENER //SYSPRINT DD DUMMY //SYSIN DD DUMMY //SYSUT1 DD DISP=(OLD,DELETE),DSN=&&TEMPDS // DD * THIS IS DATA LINE #2 WITHIN THE PROC AS A CONCATENATION. //SYSUT2 DD SYSOUT=* //* */ // PEND //STEP1 EXEC MYPROC //B.SYSUT1 DD // DD // DD * THIS IS DATA LINE #3 - ANOTHER CONCATENATION AS AN EXEC JCL OVERRIDE //* */ Not your typical situation but I believe it should have worked where all data-records should be output to SYSUT2 in step B. For my results, I am missing DATA RECORD #2, unfortunately. Scott Barry SBBWorks, Inc. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
