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 [email protected] with the message: INFO IBM-MAIN
