What do we suppose the intended use cases were for this? Cheers, Martin
Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: "Joel C. Ewing" <jcew...@acm.org> To: IBM-MAIN@listserv.ua.edu Date: 08/11/2013 15:06 Subject: Re: IF (was: Aging ...) Sent by: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> On 11/07/2013 12:04 PM, Paul Gilmartin wrote: > 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 > Perhaps the documentation was different when first introduced or maybe there are conflicting descriptions elsewhere, but I checked both z/OS 1.12 and z/OS 2.1 JCL Reference under "IF/THEN/ELSE/ENDIF", "Location in the JCL" and both now state: "An IF/THEN/ELSE/ENDIF statement construct can appear anywhere in the job. However, an IF statement specified before the first EXEC statement in a job is not evaluated before the first step executes. If the IF statement applies to later steps in the job, the statement will be evaluated when the system decides whether to process the later steps." So they don't disallow use of "IF" prior to first EXEC, it just works inconsistently (compared with usage of IF elsewhere). The meaning of "evaluate" here is slightly ambiguous to me when you consider that an IF statement may be partially formed using SET or other symbols, but I would suspect any symbol evaluations are done when the statement is first encountered and parsed and it is only the resulting relational expressions of the IF that are "evaluated" at the point of deciding whether to process a later step. -- Joel C. Ewing, Bentonville, AR jcew...@acm.org ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
