Page 1 of 5

Controlling proc RC

PostPosted: Thu Mar 24, 2011 1:26 am
by Tim
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!

Re: Controlling proc RC

PostPosted: Thu Mar 24, 2011 1:33 am
by MrSpock
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.

Re: Controlling proc RC

PostPosted: Thu Mar 24, 2011 2:40 am
by Akatsukami
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.

Re: Controlling proc RC

PostPosted: Thu Mar 24, 2011 3:21 am
by Tim
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?

Re: Controlling proc RC

PostPosted: Thu Mar 24, 2011 4:29 am
by MrSpock
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.

Re: Controlling proc RC

PostPosted: Thu Mar 24, 2011 12:32 pm
by NicC
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.

Re: Controlling proc RC

PostPosted: Thu Mar 24, 2011 1:27 pm
by BillyBoyo
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?

Re: Controlling proc RC

PostPosted: Thu Mar 24, 2011 4:13 pm
by NicC
Now, if only I could make it run faster

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

Re: Controlling proc RC

PostPosted: Thu Mar 24, 2011 5:47 pm
by BillyBoyo
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...

Re: Controlling proc RC

PostPosted: Thu Mar 24, 2011 7:45 pm
by Tim
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?