On Wed, 1 Feb 2023 00:20:26 +0000, Farley, Peter wrote:
>Not necessarily what you may want, but this works:
>
>//SYM1 SET SYM1=VALUE1
>//SYM2 SET SYM2=VALUE2
>
>//TARGET SET TARGET=&SYM1
>
>//RESULT SET RESULT=&TARGET (and end up with &RESULT being set to VALUE1
>and not SYM1)
>
>I know Gil will complain the observed JCL symbol behavior (assigning the value
>of (a) previously defined symbol(s) to another symbol) is not documented (and
>it is not), but it definitely works. I use this technique all the time in my
>application testing JCL.
>
Yup. I have complained in these pages that every possible construct should
either be documented
as supported or result in a JCL error. In reply, Peter Relson has sneered at
me, saying that I
simply don't understand that constructs not documented but allowed should be
regarded as for
IBM internal use, comparable to undocumented macro parameters, or reserved for
future
extensions. JCL feels qualitatively different to me; undocumented constructs
should at least result
in warnings, or there should be a "PRO" option on the job statement, in the
absence of which undocumented constructs should be reported as JCL errors.
But, like you, I experiment:
// SET SYM3='&SYM1 &SYM2' /* No substitution -- it's documented. */
But:
// SET Q='&'
// SET SYM3=&Q&SYM1 &SYM2&Q /* Substitution performed -- hardly
documented. */
But there may be errors reported for using &SYM3 elsewhere, as in PARM=...
These behaviors should be documented, but 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
