IBM Mainframe Forum

I'm trying to modify an existing proc that performs an ftp from a mainframe to a Wintel box. The original JCL (from the point of interest) looks like this:

//IF20 IF (RC=0) THEN
//PS0020 EXEC FTPPROC
//INPUT DD DSN=OPCPROD.NETRC.WFTPPROD.FTP,DISP=SHR
// DD DSN=OPCPROD.NETRC.&NTFILE..FTP,DISP=SHR
// DD DSN=NM.&CLIB..CNTLIB(&CONTROL1),DISP=SHR
////ENDIF20 ENDIF

The job fails occasionally, due to transisent network problems. It doesn't retry. My proposed modification is this:

//IF20 IF (RC=0) THEN
//PS0020 EXEC FTPPROC
//INPUT DD DSN=OPCPROD.NETRC.WFTPPROD.FTP,DISP=SHR
// DD DSN=OPCPROD.NETRC.&NTFILE..FTP,DISP=SHR
// DD DSN=NM.&CLIB..CNTLIB(&CONTROL1),DISP=SHR
//*
//* ---First retry
//IF21 IF (PS0020.RC NE 0) THEN
// EXEC PGM=BPXBATCH,PARM='SH sleep 150'
//PS0021 EXEC FTPPROC
//INPUT DD DSN=*.PS0020.INPUT
//*
//* ---Second retry
//IF22 IF (PS0021.RC NE 0) THEN
// EXEC PGM=BPXBATCH,PARM='SH sleep 150'
//PS0022 EXEC FTPPROC
//INPUT DD DSN=*.PS0020.INPUT
//*
//ENDIF22 ENDIF
//ENDIF21 ENDIF
//ENDIF20 ENDIF

This more or less works, but the problem is that if any step produces a non-zero RC, the entire job still abends, which kind of defeats the whole purpose. Is there a way to produce a 0 RC as long as one of the retries succeeds, or is there a better approach?

Thanks!

I don't understand. Under normal circumstances, how would a non-zero Return-Code Abend a job?

And, just a comment - I'd script out what you're doing and put all of that logic under program control. It's usually necessary for FTP steps anyway, and gives you a lot better control over the whole process.

Tim wrote:This more or less works, but the problem is that if any step produces a non-zero RC, the entire job still abends

You are very probably misusing the term abend, as is far too common these days. A program that sets a return code in register 15 and returns via the address passed by the BA*R instruction does not abend, no matter what the value in R15.

OK, let me rephrase the question. It seems that if the first ftp attempt returns a non-zero RC, and then a retry succeeds and returns RC=0, the proc still returns a non-zero RC even though the last step succeeded. I want the proc to return a non-zero RC if and only if all three ftp attempts return a non-zero RC, and to return RC=0 if ANY of the three ftp attempts succeed. How can I do that?

Still don't know EXACTLY what you're getting at, but I guess I'd add a step at the end to check the cumulative RC's:

// IF (PS0020.RC EQ 0) OR (PS0021.RC EQ 0) OR (PS0022.RC EQ 0) THEN
//PS0023 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD * <== obviously this can't be done as instream, but hopefully you get the gist
SET &MAXCC=0
/*
// ENDIF

so if the proc.PS0023.RC = 0 then at least one of the FTP steps was successful.

You CANNOT change the return code of a previously executed step. And why should you? A non-zero RC indicates something went wrong - that you anaged to recover from it does not matter. Something went wrong and the RC is an audit trail of the fact. As it is not the last step of a successfully executed job then any scheduling software should be able to be told that it worked.

Dear Tim,

Have you considered Mr Spock's first response?

Mr Spock has then given you a test in the JCL for if any of your three steps succeed. I don't think you need the SET or IDCAMS, maybe IEFBR14 will do. You can then safely test that code/have OPS look at it/try to do what you want.

NicC says you can't change the maximum previously set (I agree, although hate saying "can't"), but points you to any scheduler software you might have. I'd add that JES3 networking might give you a solution (release another Job when one of the FTPs is successful, then use the RC from that job (running, say, IEFBR14)), I saw something a little bit similar, but long ago and far away and I only saw it, I didn't work on it, so I can't be certain.

I think it might help if you tell us why the non-zero RC is a problem for you.

PS. NicC, there is never a "last step of a successfully executed job", there's always IEFBR14 if you need it

PPS. Three references to seperate uses of IEFBR14 in one post. Now, if only I could make it run faster?

Now, if only I could make it run faster

Replace all programs with IEFBR14 Runs real quick and no middle of the night callouts

Thanks for the laugh. Enjoyed it greatly.

no middle of the night callouts

What are those these days? Call on the "cell", roll out of bed to the PC. 20 minutes and back again. Bed still warm (I'm imagining, not experience this...). Eeee, when I were a lad...

Still don't know EXACTLY what you're getting at, but I guess I'd add a step at the end to check the cumulative RC's:

// IF (PS0020.RC EQ 0) OR (PS0021.RC EQ 0) OR (PS0022.RC EQ 0) THEN
//PS0023 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD * <== obviously this can't be done as instream, but hopefully you get the gist
SET &MAXCC=0
/*
// ENDIF

so if the proc.PS0023.RC = 0 then at least one of the FTP steps was successful.

What does IDCAMS do here, and what is MAXCC?