Controlling proc RC



JES, JES2, JCL utilities, IDCAMS, Compile & Run JCLs, PROCs etc...

Controlling proc RC

Postby Tim » Thu Mar 24, 2011 1:26 am

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!
Tim
 
Posts: 21
Joined: Thu Mar 24, 2011 1:00 am
Has thanked: 0 time
Been thanked: 0 time

Re: Controlling proc RC

Postby MrSpock » Thu Mar 24, 2011 1:33 am

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.
User avatar
MrSpock
Global moderator
 
Posts: 807
Joined: Wed Jun 06, 2007 9:37 pm
Location: Raleigh NC USA
Has thanked: 0 time
Been thanked: 4 times

Re: Controlling proc RC

Postby Akatsukami » Thu Mar 24, 2011 2:40 am

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.
"You have sat too long for any good you have been doing lately ... Depart, I say; and let us have done with you. In the name of God, go!" -- what I say to a junior programmer at least once a day
User avatar
Akatsukami
Global moderator
 
Posts: 1058
Joined: Sat Oct 16, 2010 2:31 am
Location: Bloomington, IL
Has thanked: 6 times
Been thanked: 51 times

Re: Controlling proc RC

Postby Tim » Thu Mar 24, 2011 3:21 am

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?
Tim
 
Posts: 21
Joined: Thu Mar 24, 2011 1:00 am
Has thanked: 0 time
Been thanked: 0 time

Re: Controlling proc RC

Postby MrSpock » Thu Mar 24, 2011 4:29 am

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.
User avatar
MrSpock
Global moderator
 
Posts: 807
Joined: Wed Jun 06, 2007 9:37 pm
Location: Raleigh NC USA
Has thanked: 0 time
Been thanked: 4 times

Re: Controlling proc RC

Postby NicC » Thu Mar 24, 2011 12:32 pm

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.
The problem I have is that people can explain things quickly but I can only comprehend slowly.
Regards
Nic
NicC
Global moderator
 
Posts: 3025
Joined: Sun Jul 04, 2010 12:13 am
Location: Pushing up the daisies (almost)
Has thanked: 4 times
Been thanked: 136 times

Re: Controlling proc RC

Postby BillyBoyo » Thu Mar 24, 2011 1:27 pm

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?
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 265 times

Re: Controlling proc RC

Postby NicC » Thu Mar 24, 2011 4:13 pm

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
The problem I have is that people can explain things quickly but I can only comprehend slowly.
Regards
Nic
NicC
Global moderator
 
Posts: 3025
Joined: Sun Jul 04, 2010 12:13 am
Location: Pushing up the daisies (almost)
Has thanked: 4 times
Been thanked: 136 times

Re: Controlling proc RC

Postby BillyBoyo » Thu Mar 24, 2011 5:47 pm

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...
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 265 times

Re: Controlling proc RC

Postby Tim » Thu Mar 24, 2011 7:45 pm

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?
Tim
 
Posts: 21
Joined: Thu Mar 24, 2011 1:00 am
Has thanked: 0 time
Been thanked: 0 time

Next

Return to JCL

 


  • Related topics
    Replies
    Views
    Last post