I should have been more clear. I used what may be an unsupported construct. According to the JCL reference manual: <snip> A relational-expression consists of:
Comparison operators Logical operators NOT (¬) operators Relational-expression keywords. </snip> FALSE (and TRUE) are clearly not operators, which are listed on the following page of the manual. Whether they are keywords depends on the correct interpretation of the 'Relational-Expression Keywords' section. Initally, that section seems very clear - <snip> The following keywords are the only keywords supported by IBM and recommended for use in relational-expressions. Any other keywords, even if accepted by the system, are not intended or supported keywords. Keyword Use RC indicates a return code ABEND indicates an abend condition occurred ¬ABEND indicates no abend condition occurred ABENDCC indicates a system or user completion code RUN indicates that the specified step started execution ¬RUN indicates that the specified step did not start execution </snip> which seems to state that TRUE and FALSE are not keywords. In the keyword descriptions that follow, however, are the following: ABEND=TRUE ABEND=FALSE stepname.RUN=TRUE stepname.RUN=FALSE using the words TRUE and FALSE as if they were keywords with a comparison operator. Testing the constructs supports the theory that they were implemented this way. My guess is that the only _supported_ use of TRUE and FALSE is with the ABEND= and RUN= comparison. It seems unlikely to me, however, that IBM will complicate their code by limiting the constructs to that. So... today 'IF FALSE THEN' and 'IF TRUE THEN' work (at least in my testing). There is no guarantee that they will continue to do so. The same is true of 'IF U0100 = U0140 THEN', also an unsupported construct. Perhaps the manual seems clear to you in this description. Personally, I would like it if they would clearly support the use of TRUE and FALSE as relational keywords. Of course, the manual also states <snip> If you specify a stepname as part of a relational-expression, the system first determines whether the step executed. If the step did not execute, the evaluation of the relational-expression is false. </snip> which is clearly not true for 'IF (stepname.RUN = FALSE) THEN'. Absolute statements in the manual may not be absolutely true. Cautions in the manual may be overstated. On Fri, 28 Jan 2011 16:07:36 -0700, Roger Bolan <[email protected]> wrote: >Robert, > >I'm confused by your example. Are you expecting that there is some kind of >predefined FALSE symbol you can use. I'm not aware of that. I think what >follows the IF has to be a test (what the book calls "relational >expression") which is why the 'IF (U0100 = U0140) THEN' works. > >--Roger > >On Fri, Jan 28, 2011 at 1:50 PM, Robert Birdsall <[email protected]> wrote: > >> This is just silly, so be warned! >> >> Last week, I posted some JCL in a response which used 'COND=ONLY' to >> suppress execution of a JCL step. In this case, I knew it was OK because >> it >> was a simple test job, and if some previous step abended for some strange >> reason I could just throw the results away. >> >> Paul Gilmartin suggested using COND=(0,LE) instead to suppress execution of >> a >> step as a general principal. >> >> I was just playing, and tried this: >> //jobname JOB (acct),'BSquare',CLASS=X,MSGCLASS=X,NOTIFY=&SYSUID >> //* >> // IF FALSE THEN >> // EXEC PGM=KLUGE,COND=ONLY >> // ENDIF >> //* >> // IF (U0100 = U0140) THEN >> //YES1 EXEC PGM=IEFBR14 >> //NO1 EXEC PGM=IEFBR14 >> // ELSE >> //YES2 EXEC PGM=IEFBR14 >> // ENDIF >> >> where KLUGE is a program that does not exist in the standard search order. >> OK, that works (KLUGE is not attempted, YES1 and NO1 are flushed and YES2 >> is executed). >> >> Add ',COND=(0,LE)' to YES2. >> Funny - YES2 is still executed! >> >> Hmm... get rid of the COND=ONLY on the unnamed KLUGE execution. >> Wait... I got an S806. What happened to the 'IF FALSE'? >> >> Well... IF (cond) THEN [whatever] [ELSE whatever] ENDIF is only evaluated >> after the 1st step of a job (even if that step does not execute). >> So the 1st 'IF FALSE' is completely useless in this job. >> The 'IF (U0100 = U0140) THEN' (which could just as easily have been 'IF >> FALSE THEN') works as expected to flush YES1 and NO1 whether the unnamed >> KLUGE step is 'executed' or not. This is true even if a valid program is >> called. >> >> The COND=(0,LE) was not effective on YES2 because no previous steps had >> been executed. Unlike the 'IF FALSE' test, COND=(0,LE) doesn't work if all >> previous steps were flushed (say, because of COND=ONLY). >> >> The only way I know to suppress execution of a step that 'always' works on >> any step of a job is >> // IF FALSE THEN >> //job step to flush...,COND=ONLY >> ... the rest of the job step DDs, etc. >> // ENDIF >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: GET IBM-MAIN INFO >> Search the archives at http://bama.ua.edu/archives/ibm-main.html >> > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: GET IBM-MAIN INFO >Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
