Sorry, that should be redesign of the Interpreter.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Seymour J Metz [sme...@gmu.edu] Sent: Monday, March 30, 2020 10:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARM= vs PARMDD= and symbol substitution > Sucks. WAD. Sucks. ITYM BAD. > I raised this issue here several years ago and got the > (condescending, IIRC) explanation: Of course it works that way. > the converter(?) builds a control block listing all EXPORTed JCL > symbol definitions for the step and passes that to the interpreter. Slim's out of town. That would imply a major, and implausible, redesign of the Converter. It could be true, but I don't believe it. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [0000000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Monday, March 30, 2020 9:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARM= vs PARMDD= and symbol substitution On Mon, 30 Mar 2020 09:29:35 -0400, Tony Thigpen wrote: >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. > Sucks. WAD. Sucks. I raised this issue here several years ago and got the (condescending, IIRC) explanation: Of course it works that way. The converter(?) builds a control block listing all EXPORTed JCL symbol definitions for the step and passes that to the interpreter. I suspect the substitution is actually performed by JES during execution. I had tried to use different values of the same symbol name in multiple SYSINs in the same step. I resorted to a cumbersome renaming so names would be distinct. IBM could have done better. IBM doesn't care. -- gil ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
