Re: IF/ELSE/ENDIF strange behavior
In jobs where I need to segment my processing, I will just stick a BR14 step as the first step. This avoids the not evaluated yet problem and allows me to control my segments. For example, in my job I have three segments of processing: 1. FTP get a file, then check to make sure it is not empty 2. Process the file 3. Send out the reports. I use symbolics on the IF statements to control whether or not I want to run each segment - including the first - which only works because of my //STEP0 EXEC PGM=IEFBR14. If a step in one segment depends on a step in another segment having run, I use IF STEPXxx.run. It may not be the most glamorous logic programming, but it seems to be fairly straightforward most of the time when thought through. * Don * On Thu, Jun 10, 2010 at 8:30 AM, Robert Birdsall bsqu...@umich.edu wrote: I understand why it would be necessary to have an effective COND=EVEN on each step in an IF ABEND controlled sequence, but why on IF NOT ABEND? In your IF ABEND...ELSE...ENDIF construct, the ELSE if treated as IF NOT ABEND, forcing the COND=EVEN behaviour. Just for fun (and contrary to a previously posted doc excerpt), note that the following 'works' under z/OS 1.10 (I don't have 1.11 installed, yet). //TESTJOB JOB (0200),'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 By works, I mean: The unnamed step is _not_ executed (COND=ONLY on 1st step, no ABEND) YES1 and NO1 are _not_ executed (U0100 U0140) YES2 _is_ executed (U0100 U0140) If you comment out the IF FALSE...ENDIF lines: YES1 _is_ executed (1st step, 'IF (U0100 = U0140)' not evaluated yet) NO1 is _not_ executed (_now_ 'IF (U0100 = U0140)' has been evaluated) YES2 _is_ executed (U0100 U0140) -- 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 -- 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
Re: IF/ELSE/ENDIF strange behavior
Not very intuitive, I admit, but that's my interpretation of how it is supposed to work. non-serious I thought that only the designers of COND= were drunken, but is seems those desinging the IF/THEN/ELSE/ENDIF may have been, too. /non-serious -- Peter Hunkeler Credit Suisse -- 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
Re: IF/ELSE/ENDIF strange behavior
I understand why it would be necessary to have an effective COND=EVEN on each step in an IF ABEND controlled sequence, but why on IF NOT ABEND? In your IF ABEND...ELSE...ENDIF construct, the ELSE if treated as IF NOT ABEND, forcing the COND=EVEN behaviour. Just for fun (and contrary to a previously posted doc excerpt), note that the following 'works' under z/OS 1.10 (I don't have 1.11 installed, yet). //TESTJOB JOB (0200),'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 By works, I mean: The unnamed step is _not_ executed (COND=ONLY on 1st step, no ABEND) YES1 and NO1 are _not_ executed (U0100 U0140) YES2 _is_ executed (U0100 U0140) If you comment out the IF FALSE...ENDIF lines: YES1 _is_ executed (1st step, 'IF (U0100 = U0140)' not evaluated yet) NO1 is _not_ executed (_now_ 'IF (U0100 = U0140)' has been evaluated) YES2 _is_ executed (U0100 U0140) -- 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
Re: IF/ELSE/ENDIF strange behavior
Yeah, I don't care for this design from a programmer's perspective: //MYTEST EXEC SKIPSTEP, // COND.MYGEN1=(4093,NE), UNLIKELY CONDITION CODE: THIS WILL RUN // COND.MYGEN2=(4093,NE), UNLIKELY CONDITION CODE: THIS WON'T RUN // COND.MYGEN3=(4093,NE)UNLIKELY CONDITION CODE: THIS WON'T RUN //*MYTEST EXEC SKIPSTEP,COND.MYGEN2=(0,LE) ALWAYS CONDITION CODE //***IF MYTEST.MYGEN2.RC . . . //*** NOTE THIS WON'T WORK WITH MYGEN1, AS NO CONDITION CODE HAS BEEN SET //*** IN THE FIRST STEP. //MYGEN1.SYSUT1 DD * STEP 1 //MYGEN2.SYSUT1 DD * STEP 2 //MYGEN3.SYSUT1 DD * STEP 3 // -- 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
IF/ELSE/ENDIF strange behavior
Hello group, I'm running following job with z/OS 1.10 /JES3). Program MAKEABND (STEP04) produces an S0C1-Abend, and STEP06 is executed, which I did not expect. If I put the ENDIF before STEP06, STEP06 is Flushed (like expected), //STEP01 EXEC PGM=IEFBR14 //* // IF ABEND THEN //STEP02 EXEC PGM=IEFBR14 // ELSE //STEP03 EXEC PGM=IEFBR14 //* //STEP04 EXEC PGM=MAKEABND,COND=(0,NE,STEP03) //* //STEP05 EXEC PGM=IEFBR14,COND=(EVEN) //* //STEP06 EXEC PGM=IEFBR14 // ENDIF Does somebody has an explanation fot this behaviour. Any hint appreciated. With best regards Monika -- 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
Re: IF/ELSE/ENDIF strange behavior
Monika, I found the following tidbit in the JCL reference: By default, job steps within the IF/THEN/ELSE/ENDIF statement construct do not execute when * An abend occurred, and * the IF/THEN/ELSE/ENDIF structure containing the job steps does not specify the ABEND, ABENDCC, or ¬ABEND keyword. If any of these keywords is specified (with or without stepname or procstepname), the job steps do execute despite the abend. * The step's COND parameter, if any, does not specify an abend condition (COND=EVEN or COND=ONLY). Note in the second asterisk (bullet) that it specifies steps (plural) in the THEN/ELSE structure. I interpret that as meaning that ALL steps after IF ABEND THEN are executed when an ABEND occurs unless overridden by a COND= (or nested IF). You can easily test this by adding the COND= to STEP06 or enclosing it in a nested IF. Not very intuitive, I admit, but that's my interpretation of how it is supposed to work. Regards, Alan -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Monika Amiss Sent: Wednesday, June 09, 2010 09:08 To: IBM-MAIN@bama.ua.edu Subject: IF/ELSE/ENDIF strange behavior Hello group, I'm running following job with z/OS 1.10 /JES3). Program MAKEABND (STEP04) produces an S0C1-Abend, and STEP06 is executed, which I did not expect. If I put the ENDIF before STEP06, STEP06 is Flushed (like expected), //STEP01 EXEC PGM=IEFBR14 //* // IF ABEND THEN //STEP02 EXEC PGM=IEFBR14 // ELSE //STEP03 EXEC PGM=IEFBR14 //* //STEP04 EXEC PGM=MAKEABND,COND=(0,NE,STEP03) //* //STEP05 EXEC PGM=IEFBR14,COND=(EVEN) //* //STEP06 EXEC PGM=IEFBR14 // ENDIF Does somebody has an explanation fot this behaviour. Any hint appreciated. With best regards Monika -- 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 -- 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
Re: IF/ELSE/ENDIF strange behavior
On Wed, 9 Jun 2010 18:07:40 +0200, Monika Amiss wrote: I'm running following job with z/OS 1.10 /JES3). Program MAKEABND (STEP04) produces an S0C1-Abend, and STEP06 is executed, which I did not expect. If I put the ENDIF before STEP06, STEP06 is Flushed (like expected), //STEP01 EXEC PGM=IEFBR14 //* // IF ABEND THEN //STEP02 EXEC PGM=IEFBR14 // ELSE //STEP03 EXEC PGM=IEFBR14 //* //STEP04 EXEC PGM=MAKEABND,COND=(0,NE,STEP03) //* //STEP05 EXEC PGM=IEFBR14,COND=(EVEN) //* //STEP06 EXEC PGM=IEFBR14 // ENDIF Does somebody has an explanation fot this behaviour. Any hint appreciated. This seems to considerably violate: 17.1.9 z/OS V1R10.0 MVS JCL Reference * The result of processing an IF/THEN/ELSE/ENDIF statement construct, once determined, remains unchanged regardless of the outcome from running any remaining steps in a job. The system does not reexamine the original condition at any later job step termination, either normal or abnormal. ... but, e.g., read carefully: * 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. That latter bullet is new. There was formerly a statement that IF could appear only after the first EXEC statement. Apparently someone complained and they changed the doc. It appears as if IF ABEND operates by adding an implicit COND to every step in the ELSE group. You can try a PMR. I wouldn't expect anything more than a DOC closure. It's an intractable, fragile kludge. -- 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
