> -----Ursprungligt meddelande----- > Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Paul > Gilmartin > Skickat: den 22 januari 2011 01:11 > Till: IBM-MAIN@bama.ua.edu > Ämne: Re: SV: If Else JCL question > > 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.
Maybe. But not for me, I see it that an "EQ" or "=" is naturally implicit. > Is there any difference between NOTRUN and FLUSHED? If so, > should there also be a NOTFLUSHED? I it could be JCLERROR (rather than "FLUSHED" due to previous RC). > 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? Mainly due to backward compatibility concerns. And it could lead to confusion with two different type of syntaxthinking in COND. > > IF...THEN has some nice properties: My main dislike with IF..THEN etc. is that the resulting JCL is not easy to read (for me at least). With a keyword at each EXEC it is at least more compact. And You don't have to search for pairing the IF's with the ENDIF's etc. > > 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). Yes, this is nice in itself. But You still have to pair the ENDIF's with the IF's etc. > 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 My idea is that the "RUNIF" would work also against the step that EXEC's the proc. (Including the proc's steps.) > 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." Isn't that a fair stance ? :) Hälsn Thomas _________________________________________ Thomas Berg Specialist A M SWEDBANK ---------------------------------------------------------------------- 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
