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 [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
