Question: In the actual "PROC" JCL, the JCL between the "//xxxx PROC" and "// PEND" statements (or assumed PEND if it is a PDS member), you coded a JCL statement with "// DD *"?
I think if you do, that is not acceptable, because the "*" indicates that non-JCL data follows and you cannot have that within an actual PROC statements. Because I bet if you change that "// DD *" to be "// DD DISP=SHR,DSN=xxxx.xxxx.xxxx" and in that Data Set is the first set of control cards, your override will work. Al Nims Systems Admin/Programmer 3 Information Technology University of Florida (352) 273-1298 -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ray Mullins Sent: Thursday, February 06, 2014 5:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Error overriding concatenated DD in PROC where one is instream data 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/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
