On Thu, 7 Nov 2013 10:06:14 -0600, Joel C. Ewing wrote:
>
>I share your celebration of the IF Statement; although I have been bit
>on one occasion by a non-intuitive behavior of IF statements as well:
>the first EXEC in a JOB is always unconditionally executed no matter
>what (which precludes using SET symbols and a leading IF to control
>selective skipping of the first step, which seems a reasonable thing to
>try just based on syntax)
>
I suspect that IF piggybacks on the implementation of COND.
If I put on my mathematician's hat I can say that the behavior
of COND is logical (as opposed to intuitive). It means, "skip
the current step the set of prior steps satisfying the predicate
is nonempty." Of course that set is empty for the first step,
even when I code, as is my custom, "COND=(0,LE)" to skip
a step unconditionally. That argument can not be made for IF.
The JCL Ref states in "Placement in the JCL" (from memory)
that IF must ("should"?) not appear before the first EXEC
statement. Dammit! Such assertions should be imperative,
not advisory, and their transgressions should be reported
as syntax errors. Likewise, I can code "IF ( FALSE ) THEN"
which does not match any syntax documented as valid, but
no syntax error is reported. (It results in skipping any step
but the first in the job.) The JCL Ref states that any form
of the IF predicate not documented as not valid may produce
unpredictable and subject-to-change results even though
it may appear to work in a particular instance. Dammit again!
Syntax errors should be reported. This sort of thing makes
me a strong adversary of Postel's Robustness Principle.
I have ranted about this previously here, in response to
which an IBM weasel defended the behavior, noting that
there are many cases in which undocumented syntax is
not reported as errors because the constructs are reserved
either for IBM internal use or for future enhancements.
His example was undocumented parameters to library
macros. This is radically different. I suspect, rather, that
a rogue new-grad coder, enamored of BNF syntax and
recursive descent parsers, coded the parser as he believed
it should be, not as it was specified. The deviation was
not discovered in testing (not enough error paths exercised)
and/or resource constraints precluded emendation.
I have another dissatisfaction with IF ... The labels on
corresponding IF, ELSE, and ENDIF should be required to
match, with mismatches reported as syntax errors, to
facilitate verification of nesting. Rather, the JCL Ref
states that those labels "should" (IIRC) be unique. Again,
transgressions are not reported.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
