Sorry, my cut and paste went awry. Should be this:
//EP4IN PROC //STEP01 EXEC PGM=IEFBR14,COND=(20,LT) //STEP01A EXEC PGM=IEFBR14,COND=(20,LT) //STEP02 EXEC PGM=EPZOS,COND=(20,LT) //STEP03 EXEC PGM=IDCAMS,COND=(7,LT) //STEP04 EXEC PGM=EPTBLUPD // IF ( STEP04.RC = 3 ) THEN //STEP05 EXEC PGM=IEBGENER,COND=((7,LT),(4,LT,STEP03),(4,LT,STEP04)) // ENDIF // IF ( STEP04.RC = 0 | STEP04.RC = 4 ) THEN //STEPLAST EXEC EPLINK99 // ENDIF //STEP06 EXEC PGM=IEBGENER,COND=(24,LT) //STEP07 EXEC PGM=EPX99,COND=(20,LT) //EP4IN PEND Anyway, I did totally misunderstand how COND works when executing a PROC rather than a PGM. Thanks! As for mixing IF/THEN/ELSE with COND, as I said, its a vendor supplied PROC. Definitely don't want to mess with it. But it looks like you're saying I can use IF/THEN logic to skip the EP4IN step if the BACKUP1 step fails. So I will do that. As much as I hate COND, at least it "fits" within how JCL otherwise looks, which is more than I can say for IF/THEN/ELSE! Oh well! Thanks again, Frank >________________________________ > From: Joel C. Ewing <jcew...@acm.org> >To: IBM-MAIN@bama.ua.edu >Sent: Wednesday, April 18, 2012 1:14 PM >Subject: Re: JCL help (yes, with COND) > >On 04/18/2012 12:43 PM, Frank Swarbrick wrote: >> I have the following job (cut down to include only the relevant parts): >> >> >> //VAPPROC4 JOB >> //BACKUP1 EXEC PROC=SORTBKUP,COND=(4,LT) >> //EP4IN EXEC PROC=EP4IN,COND=(4,LT) >> //E4INPRT EXEC PROC=E4INPRT >> // >> >> >> The EP4IN PROC is a vendor supplied proc as follows: >> >> >> //EP4IN PROC >> //STEP01 EXEC PGM=IEFBR14,COND=(20,LT) >> //STEP01A EXEC PGM=IEFBR14,COND=(20,LT) >> //STEP02 EXEC PGM=EPZOS,COND=(20,LT) >> //STEP03 EXEC PGM=IDCAMS,COND=(7,LT) >> //STEP04 EXEC PGM=EPTBLUPD >> // IF ( STEP04.RC = 3 ) THEN >> //STEP05 EXEC PGM=IEBGENER,COND=((7,LT),(4,LT,STEP03),(4,LT,STEP04)) >> // ENDIF >> // IF ( STEP04.RC = 0 | STEP04.RC = 4 ) THEN >> //STEPLAST EXEC EPLINK99 >> // ENDIF >> //EP4IN PEND >> //STEP06 EXEC PGM=IEBGENER,COND=(24,LT) >> //STEP07 EXEC PGM=EPX99,COND=(20,LT) >> //EP4IN PROC >> >> I've already solved my issue (which I will detail below), but I'm still >> unclear as to why what I had was wrong, and why my fix actually fixes it. >> >> The issue is that EP4IN.STEP06 and EP4IN.STEP07 were not being executed: >> >> IEF202I VAPPROC4 STEP06 EP4IN - STEP WAS NOT RUN BECAUSE OF CONDITION CODES >> IEF272I VAPPROC4 STEP06 EP4IN - STEP WAS NOT EXECUTED. >> >> IEF202I VAPPROC4 STEP07 EP4IN - STEP WAS NOT RUN BECAUSE OF CONDITION CODES >> IEF272I VAPPROC4 STEP07 EP4IN - STEP WAS NOT EXECUTED. >> >> STEPNAME PROCSTEP RC >> BACKUP1 BACKUP 00 >> EP4IN STEP01 00 >> EP4IN STEP01A 00 >> EP4IN STEP02 00 >> EP4IN STEP03 05 >> EP4IN STEP04 FLUSH >> EP4IN STEP05 FLUSH >> STEPLAST STEP16 FLUSH >> STEPLAST STEP17 FLUSH >> EP4IN STEP06 FLUSH >> EP4IN STEP07 FLUSH >> >> (It's expected that EP4IN.STEP04, EP4IN.STEP05, STEPLAST.STEP16 and >> STEPLAST.STEP17 do not execute under these conditions, becasue EP4IN.STEP03 >> resulted in RC=05; they execute only when RC=03 for this step.) >> >> Anyway, the solution is to remove the COND parameter from the "EXEC >> PROC=EP4IN". >> My new result follows: >> >> BACKUP1 BACKUP 00 >> EP4IN STEP01 00 >> EP4IN STEP01A 00 >> EP4IN STEP02 00 >> EP4IN STEP03 05 >> EP4IN STEP04 FLUSH >> EP4IN STEP05 FLUSH >> STEPLAST STEP16 FLUSH >> STEPLAST STEP17 FLUSH >> EP4IN STEP06 00 >> EP4IN STEP07 00 >> E4INPRT REPORT 00 >> >> What really was the issue and why did my solution resolve it? >> My reason for including this parameter is so that EP4IN should be bypassed >> if BACKUP1 fails. >> >> Once again I ponder the sanity of the inventor of COND. >> >> Thanks, >> Frank >> > >The EP4IN PROC seems to have an embedded PEND and then a spurious PROC >statement at the end (where the PEND should be ?). I suspect the >problem is that combining COND on an EXEC PROC with embedded use of COND >inside a PROC does not interact well and seldom does what one might >expect/want. The COND on the "EXEC PROC" statement does not determine >whether that EXEC is performed -- it instead overrides the COND >parameter on every EXEC within the PROC and determines when steps within >the PROC will be executed, completely ignoring any original carefully >thought out conditional logic using COND on EXECs within the PROC >definition itself. > >As a side issue, mixing IF/THEN/ELSE conditional execution with use of >COND is so highly confusing, we always recommended not introducing the >new forms without converting old EXEC COND usage to IF/THEN/ELSE >statements at the same time (except possibly for COND on the JOB >statement). Also one can use IF/THEN/ELSE in the main JCL stream >without the bizarre override issues you get with COND on the "EXEC PROC". > >-- >Joel C. Ewing, Bentonville, AR jcew...@acm.org > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN > > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
