That is pretty much how I see it, and the OP's original surprise with how the PARMDD's work would work just like the non-PARMDD case if modified to add "NO-OP" IEFBR14 steps before any SET statement intended for use by the *following* step::
// SET VRB=VALUE1 //STEP1 EXEC PGM=program,PARM=PARMDD //PARMDD DD *,SYMBOLS=JCLONLY &VRB /* //* //SET4STP2 EXEC PGM=IEFBR14 // SET VRB=VALUE2 //STEP2 EXEC PGM=program,PARM=PARMDD //PARMDD DD *,SYMBOLS=JCLONLY &VRB /* //* //SET4STP3 EXEC PGM=IEFBR14 // SET VRB=VALUE3 //STEP3 EXEC PGM=program,PARM=PARMDD //PARMDD DD *,SYMBOLS=JCLONLY &VRB /* Not intuitive, but ALL JCL following EXEC is processed BEFORE any symbol substitution for in-stream files, which in fact is what you want, because otherwise something like this would not work as expected: // SET VRB=VALUE2 //STEP2 EXEC PGM=program,PARM=PARMDD //PARMDD DD *,SYMBOLS=JCLONLY &VRB /* // SET LLQ=WEEKLY //STEP2DD DD DISP=SHR,DSN=HLQ.DATA.&LLQ(0) //* I remember from my VSE/SP days that all your DLBL's and other "DD" equivalents in VSE have to appear BEFORE the EXEC PGM= statements. EXEC trails the file specifications rather than leading them. Peter -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Tony Thigpen Sent: Monday, March 30, 2020 9:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARM= vs PARMDD= and symbol substitution EXTERNAL EMAIL Actually, it makes sense to me, in a strange way. I don't know if I can describe why it makes sense, but I will try. 1) An // EXEC card is read and a 'step' begins. The // EXEC card itself must be interpreted. 2) The rest of the step 'stuff' (until the next // EXEC) is read in to the pre-processor. 3) The pre-processor first handles things that don't require read-ahead processing to the end of the step. 4) The pre-processor next handles things that did require read-ahead processing, such as "//PARMDD DD *,SYMBOLS=JCLONLY" that it could not process on the first pass. Now, why it worked without PARMDD is because the '// EXEC' is processed and intrepreted before all the "let's get the step stuff now" logic (step 2 above). Like I say, hard to describe. Tony Thigpen Windt, W.K.F. van der (Fred) wrote on 3/30/20 7:50 AM: > Based on the doc I expected these two JCL variations to behave 100% > equivalent (assuming the program van handle any parameter length): > > //STEP1 EXEC PGM=program,PARM='parameter with symbols' > > And > > //STEP1 EXEC PGM=program,PARM=PARMDD > //PARMDD DD *,SYMBOLS=JCLONLY > parameter with symbols > /* > But unexpected stuff happens when you add SET statements between job steps. > > // SET VRB=VALUE1 > //STEP1 EXEC PGM=program,PARM='&VRB' > //* > // SET VRB=VALUE2 > //STEP2 EXEC PGM=program,PARM='&VRB' > //* > // SET VRB=VALUE3 > //STEP3 EXEC PGM=program,PARM='&VRB' > > Behaves as expected. In STEP1 the program in invoked with parameter VALUE1, > in STEP2 with parameter VALUE2 and in STEP3 with parameter VALUE3. > > If I change the JCL to this: > > // SET VRB=VALUE1 > //STEP1 EXEC PGM=program,PARM=PARMDD > //PARMDD DD *,SYMBOLS=JCLONLY > &VRB > /* > //* > // SET VRB=VALUE2 > //STEP2 EXEC PGM=program,PARM=PARMDD > //PARMDD DD *,SYMBOLS=JCLONLY > &VRB > /* > //* > // SET VRB=VALUE3 > //STEP3 EXEC PGM=program,PARM=PARMDD > //PARMDD DD *,SYMBOLS=JCLONLY > &VRB > /* > > Does not behave 'logical' at all. In STEP1 the program is invoked with > parameter VALUE2, in STEP2 and STEP3 with parameter VALUE3. It seems SET > statement that follow the current EXEC statement (but before the next EXEC > statement) are processed before the PARMDD= parameter is constructed. > > I can't find any documentation that specifies this behavior. Is this a bug? > > Regardz, > > Fred! > ------ This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
