On Tue, 9 Apr 2013 12:51:49 -0500, John McKown wrote: >Just a question that may be a bit pedantic. It is JES doing the >substitution (a HASPnnnn program) or is it the converter/interpreter? I >guess the main reason is to determine who to yell at. <grin/> > Hardly cause to yell. If you need an external item with substitutable symbols, you can make it an instream data set in a JCLLIB member. I'll hardly miss the double substitution. CLIST fans might disagree. But instream data sets read from JCLLIB are limited to LRECL<=80. That's worth yelling at for. And we can both yell that UNIX directories are not supported in JCLLIB (at least I think not).
(And apropos of nothing in this thread so far, JCL processing desperately needs HLASM's string BIFs such as DOUBLE() and DEQUOTE().) >On Tue, Apr 9, 2013 at 12:46 PM, Walt Farrell wrote: > >> I think your understanding has a flaw, gil. As I understand the >> discussion, it is not the initiator doing the substitution. If it were, >> then symbols in non-instream PARMDD data sets would work. Rather, it is JES >> doing the substitution. The initiator merely passes along whatever GET >> provided, and GET in turn merely passes along exactly what was in the >> non-instream data set, or whatever JES provided for an instream data set. >> I had come pretty close to that conclusion until Peter challenged me with: >> -On Tue, 9 Apr 2013 07:45:18 -0400, Peter Relson wrote: > >>"[S]hortly before the jobstep program >>attach" sounds far too late for JES JCL symbol substitution. > >Perhaps I am missing something. Why would it be "too late"? It is before >the program gets control. It is after the JCL symbol values are known. > OK. Peter is saying it would be technically possible; Walt says, but it's not done. No contradiction there. And climbing aboard Peter Hunkeler's rant, I wonder, since the processing of PARMDD is complex and may mislead programmers, is anything akin to IEFC653I SUBSTITUTION JCL - ... ... issued to show the actual PARM as it will be passed to the job/proc step program? Similarly, when the programmer specifies DD *,SYMBOLS=JCL, is IEFC653I issued to show the resolution of symbols in the instream data set? May I assume that ampersands in the scope of SYMBOLS=JCL may/should be doubled to escape them from being treated as introducing symbols? I see no corresponding cause to double apostrophes. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN