On 2017-10-04, at 08:32, Jonathan Scott wrote:
> ...
> I personally feel that built-in functions in the conditional
> assembly language need to work just the way that people would
> expect, with built-in functions being allowed everywhere that a
> term of that type would be allowed. So I can't say whether it is
> ever going to be fixed but I can say that I want it fixed sooner
> rather than later!
>
Thanks. I welcome that attitude. It's a refreshing contrast to
things in the JCL Ref., particularly:
o You can specify symbolic parameters on IF/THEN/ELSE/ENDIF statements provided
that they resolve to one of the supported relational-expression keywords.
Any other symbolic parameters, even if accepted by the system, are not
intended
or supported. ...
That's a deplorable invitation to unreliable coding practice. Ironically, the
constructs not "supported" seem, AFAICT, "to work just the way that people
would expect ..." It seems the coder understood conventional logical expression
syntax better than the designer.
For example, in a one-off, not intended for production, I regularly bypass
job steps by coding:
//GROUP IF ( FALSE ) THEN
... (steps to be skipped
//GROUP ENDIF
Unsupported:
o "( FALSE )" is not a valid relational expression. (But it has the
intuitive semantic.)
o My repeated use of "GROUP" violates "o The name should be unique
within the job." But I find it useful to visually match the boundaries
of the IF group. It would be better to have an (enforced) rule that
the name[s] of the IF, the THEN, and the ENDIF must all match.
Years ago, I ranted on IBM-MAIN about the uncertainty of "even if accepted",
arguing that any unsupported construct should be flagged as a syntax error.
Peter Relson (IIRC) countered that acceptance of unsupported constructs such
as undocumented macro arguments is pervasive and benign. They may be reserved
either for future enhancements (fallacious), or used internally by IBM
(arguably valid). I see undocumented JCL syntax as qualitatively different
from undocumented macro arguments.
My top pet peeve inconsistency in HLASM is that the semantics of quoted
strings in macro arguments and in SETC arguments are radically different.
Bad History. It's wrong, but compatibility prohibits ever fixing it.
-- gil
