On Mon, 27 Jan 2014 19:45:14 -0500, John Gilmore wrote:
>To the question, "Might this introduce behavior changes unanticipated
>by end users?", the answer must of course be yes.
>
>Such an end user could, for example, supply a buffer of length 2N
>bytes, expecting confidently that the last N bytes would remain
>available to him/her for further use after symbol substitution, only
>to discover that some of them were not available.
>
I was concerned less with the syntax of the value than the syntax
of the name.
Peter said (hypothetically) that the new feature might by enabled
by use of a new character in symbol names, not supported at
present. Suppose '_' is used as such a symbol. Today, I get
(in JCL):
3 // SET WOMBAT='Short'
4 //STEP EXEC PGM=IEFBR14,PARM='&WOMBAT_1'
IEFC653I SUBSTITUTION JCL - PGM=IEFBR14,PARM='Short_1'
but if '_' were added to the alphabet of symbol names, the symbol
would be not "&WOMBAT" but "&WOMBAT_1" which (in my example)
is undefined and no substitution would occur; a behavior change
unanticipated by programmers for many decades now.
>Preoccupation with dismaying such people can be paralyzing. It can
>lead to a state of mind which views any change as too risky.
>
>When a change can have untoward consequences that can reasonably be
>anticipated they should be described where it, the change, is
>described; but there is no requirement that change be avoided to
>protect users from all of their bad design decisions.
>
A matter of opinion, of course. If I had cautiously coded "PARM='&WOMBAT._1'",
I would be protected from the hypothetical change, but get a changed
behavior if I left &WOMBAT undefined. I think from the beginning the
JCL R/C (whatever) should have made reference to an undefined symbol
an error.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
