Paul (et al): Again, I have an answer for all of you. BTW, it is also available directly from IBM.
Regards, Mitch -----Original Message----- From: Paul Gilmartin <[email protected]> To: IBM-MAIN <[email protected]> Sent: Thu, Nov 7, 2013 10:04 am Subject: IF (was: Aging ...) 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) suspect that IF piggybacks on the implementation of COND. f I put on my mathematician's hat I can say that the behavior f COND is logical (as opposed to intuitive). It means, "skip he current step the set of prior steps satisfying the predicate s nonempty." Of course that set is empty for the first step, ven when I code, as is my custom, "COND=(0,LE)" to skip step unconditionally. That argument can not be made for IF. The JCL Ref states in "Placement in the JCL" (from memory) hat IF must ("should"?) not appear before the first EXEC tatement. Dammit! Such assertions should be imperative, ot advisory, and their transgressions should be reported s syntax errors. Likewise, I can code "IF ( FALSE ) THEN" hich does not match any syntax documented as valid, but o syntax error is reported. (It results in skipping any step ut the first in the job.) The JCL Ref states that any form f the IF predicate not documented as not valid may produce npredictable and subject-to-change results even though t may appear to work in a particular instance. Dammit again! yntax errors should be reported. This sort of thing makes e a strong adversary of Postel's Robustness Principle. I have ranted about this previously here, in response to hich an IBM weasel defended the behavior, noting that here are many cases in which undocumented syntax is ot reported as errors because the constructs are reserved ither for IBM internal use or for future enhancements. is example was undocumented parameters to library acros. This is radically different. I suspect, rather, that rogue new-grad coder, enamored of BNF syntax and ecursive descent parsers, coded the parser as he believed t should be, not as it was specified. The deviation was ot discovered in testing (not enough error paths exercised) nd/or resource constraints precluded emendation. I have another dissatisfaction with IF ... The labels on orresponding IF, ELSE, and ENDIF should be required to atch, with mismatches reported as syntax errors, to acilitate verification of nesting. Rather, the JCL Ref tates that those labels "should" (IIRC) be unique. Again, ransgressions are not reported. -- gil ---------------------------------------------------------------------- or IBM-MAIN subscribe / signoff / archive access instructions, end email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
