On Fri, 21 Jan 2011 13:28:51 +0100, Thomas Berg wrote: >I would have preferred something like this instead of the delivered IF..THEN >logic: > >//S050 EXEC WHATEVER,RUNIF=(RC,LE,4,S010) > RUNIF=(RC,8,S010) > RUNIF=(RUN,S020) > RUNIF=(RUN,ANY) > RUNIF=(NOTRUN,S030) > RUNIF=(FLUSHED,S040) > RUNIF=(JCLERROR,S040) >..and in combinations as in COND. >etc. > Why?
Eliding the "EQ" may be more confusing than convenient. Is there any difference between NOTRUN and FLUSHED? If so, should there also be a NOTFLUSHED? The ability to test and recover from a JCLERROR is a novel concept. Would IBM buy it as a construct in IF...THEN? Why not? And why not just extend COND with the new constructs? IF...THEN has some nice properties: o ELSE provides a nice alternative; no need to invert the COND with deMorgan's Laws (and COND supports disjunction but not conjunction). o IF...THEN can control multiple steps with no need to restate the COND on every EXEC statement (but symbol substitution could simplify this). o One or more of the controlled steps can be a PROC call with no need to override COND on the individual PROC steps, and no conflict with COND in legacy library PROCs o The ability to test for specific ABEND codes. All in all, I see considerable fear of innovation here. Perhaps, "If I couldn't run it on my turnkey MVS 3.8 under Hercules, I'd rather not deal with it." -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
