Ray, Just out of curiosity, would it work if you added a third DD card to the original SYSLPARM DD concatenation? The JCL ref manual doesn't explicitly state the override needs something to override, but it might be worth a try.
Can you try something like: //SYSLPARM DD DSN=&&tempds,DISP=(OLD,DELETE) // DD * some more binder parms overriding the first one /* // DD * A comment line or do-nothing line (or possibly nothing at all) /* And then your override would have the second DD * to be overridden. Or maybe the third DD could be DD DUMMY? Rex -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ray Mullins Sent: Thursday, February 06, 2014 4: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 The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
