IBM Mainframe Forum

Tim wrote:

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?

In this example, IDCAMS is being used solely to return a step condition code (MAXCC; but note that this term and concept applies only to IDCAMS) to zero. You might also contemplate an ELSE clause that runs an identically-named IDCAMS step that returns a non-zero return code.

NicC wrote: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.

I'm not looking to change the RC of a previously executed step. I just don't want that value returned as the RC of the proc. If the first ftp attempt fails, the proc will retry the ftp. When that succeeds, the proc should return RC=0, not RC=<RC of failed ftp step>.

So is it the case that a proc returns the highest value for RC that occurred during the run? An audit trail is nice, but in this case I don't need or want one. I need the proc to return with RC=0 if ANY of the ftp attempts was successful. Is that simply not possible using JCL?

Can you just tell us why you want RC=0? What prolem does it give you if it is zero?

A JCL procedure does not have a return code. Period. End of story. Only job steps started by
//STEPNAME EXEC PGM=...
have return codes. You can test these return codes using COND= or // IF JCL statements.

I think the real reason Tim wants a return code 0 is his production control gets hot and bothered if it sees a non-zero return code.

If Tim wants a return code 0 he should write himself a Rexx exec or CLIST that calls the FTP client, and recalls it if it gets a non-zero return code, and runs the Rexx exec or CLIST in TSO in batch. He may have a good idea here, but he can't use JCL to accomplish what he really wants.

What does IDCAMS do here, and what is MAXCC?

It does exactly what it says - sets MAXCC to 0. All it does is set the return code from the IDCAMS step to 0 so IEFBR14 would be far more efficient.

roll out of bed to the PC

Get organised! I have a PC beside the bed - but I am not on call - unemployed PL/1 programmer with little or no German/Dutch/French

NicC wrote:with little or no German/Dutch/French

And... living in Luxembourg?

steve-myers wrote:I think the real reason Tim wants a return code 0 is his production control gets hot and bothered if it sees a non-zero return code.

If Tim wants a return code 0 he should write himself a Rexx exec or CLIST that calls the FTP client, and recalls it if it gets a non-zero return code, and runs the Rexx exec or CLIST in TSO in batch. He may have a good idea here, but he can't use JCL to accomplish what he really wants.

Which gets us right back to Mr Spock's first suggestion.

I apologize for my imprecise terminology. It seems I'm unable to adequately express the problem. Let me try a different approach. My company has a mainframe (we call it the "host"). Around 2:00am it runs scheduled jobs that ftp files in both directions between the host and various other systems. Occasionally these jobs fail because of transient network problems. When that happens, an error code appears on the operator console next to the job (the code is 166, meaning the ftp destination is unreachable). At the same time, an error is automatically logged in the issue tracking system, and that triggers an email to the unlucky soul who's carrying the Blackberry that night. The operator will rerun the job a few minutes later and it will almost invariably succeed. My goal is to alter the job somehow so that it automatically retries the ftp a couple times, and only then if it hasn't succeeded will it alert the operator, automatically log the issue, and drag someone out of bed.

This is a big company, and different groups own different parts of the overall system. The part my group can access is shown below. It consists of a job and a proc (sorry if my terminology is still wrong here). In particular, we don't own ftpproc--we can use it, but we can't change it. If it completes successfully, RC is 0, and it it fails, RC is 166.

My idea was to check RC after the ftpproc executed and retry if it failed. In fact, that part works. We can force a failure at PS0020 (by simply deleting the file target before the job starts), then allow the the second step to succeed (by recreating the file while the job is sleeping before the retry). All seems good, except when the job is finished 166 still appears on the operator console, and the email still goes out.

If this still doesn't make sense, I guess I'll guess I'll have give up and just live with it.

Thanks for taking the time to help!


//NBAM029D JOB 15541840NM,'PJMESS FILE PULL',
// MSGCLASS=P,CLASS=N
//*
//*-------------------------------------------------------------------*
//* THIS JOB PULLS THE PJ ITEM MESSAGE *
//* FILES FROM EACH STORE. *
//*-------------------------------------------------------------------*
//*
//JOBLIB DD DSN=NM.FIX.BATCH.LOADLIB,DISP=SHR
// DD DSN=NM.PROD.BATCH.LOADLIB,DISP=SHR
//*
//UCC11RMS EXEC PROC=UCC11RMS,TYPRUN='P'
//*
//*-------------------------------------------------------------------*
//* RESTART PROCEDURES FOR STEP: JS0010 *
//* RESTART AT : JS0010 *
//* THIS STEP PULLS THE PJ ITEM FILE MESSAGE *
//*-------------------------------------------------------------------*
//JS0010 EXEC NBAP6004,
// NTFILE=POS29-1,
// CONTROL1='NBAPM029',
// STR='029'
//*
//*-------------------------------------------------------------------*
//* RESTART PROCEDURES FOR STEP: JS0020 *
//* RESTART AT : JS0020 *
//* THIS STEP SENDS A FLAG ALERTING NEW POS THAT FILES HAVE BEEN *
//* PULLED SO THAT THE ARCHIVING PROCESS CAN BEGIN. *
//*-------------------------------------------------------------------*
//JS0020 EXEC NBAP6008,
// NTFILE=POS29-1,
// CONTROL1='NBAPFLAG'
//*
//*--------------------------------------------------------------------*
//*- E N D O F J O B N B A M 0 2 9 D -*
//*--------------------------------------------------------------------*



//*-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-*
//*- P R O C N B A P 6 0 0 4 -*
//*-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-*
//*-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-*
//*- SYSTEM: POS HOST -*
//*- TITLE: POS PJITEM UPLOAD -*
//*- FREQUENCY: DAILY -*
//*- DESCRIPTION: THIS JOB IS RUN TO UPLOAD THE PJITEM MESSAGE -*
//*- FILE TO THE HOST EACH DAY. -*
//*-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-*
//*- -- MODIFICATION LOG -- -*
//*-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-*
//*- DATE : 06/26/05 -*
//*- PROGRAMMER : NMJP1 -*
//*- MODIFICATION : CREATED -*
//*-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-*
//*- DATE : 05/21/10 -*
//*- PROGRAMMER : NMJP1 -*
//*- MODIFICATION : ADDED RESTART INSTRUCTIONS FOR FTP ISSUES -*
//*-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-*
//*-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-*
//*- -- RESTART INSTRUCTIONS -- -*
//*-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-*
//* PROC STEP PS0010: RESTART AT PS0010
//* PROC STEP PS0020: RESTART AT PS0020
//* **NOTE** THIS JOB CAN BE STARTED FROM THE TOP
//* THIS JOB:
//* 1). CREATES AN EMPTY UPLOAD FILE.
//* 2). PULLS THE PJMESS FILE FROM THE WINDOWS BOX TO THE HOST
//* A) IF THIS JOB ABENDS, RESTART THE JOB AT LEAST THREE TIMES.
//* B) IF IT FAILS ON A CONNECTION ERROR, CALL THE NETWORK GROUP OR
//* FIND OUT IF THE SERVER IS DOWN. IF THE SERVER IS DOWN,
//* RERUN THE JOB ONCE THE SERVER IS BACK ONLINE.
//* C) IF A AND B DO NOT RESOLVE THE ISSUE, CALL THE APPLICATIONS TEAM
//*-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-*
//*
//NBAP6004 PROC OMODE=P,
// CLIB='PROD',
// CONTROL1=XXXX,
// NTFILE='POSXX-X',
// STR='999'
//*
//*--------------------------------------------------------------------*
//IF10 IF (RC=0) THEN
//PS0010 EXEC PGM=IEBGENER
//*--------------------------------------------------------------------*
//*- STEP FUNCTION: -*
//*- -*
//*- GENER EMPTY UPLOAD FILE -*
//*- RESTARTABLE IN THIS STEP -*
//*--------------------------------------------------------------------*
//*
//SYSUT1 DD DUMMY,
// DCB=(N.MODEL,RECFM=FB,LRECL=81,BLKSIZE=0)
//*
//SYSUT2 DD DSN=NMBA.&OMODE..N.TR.UPLD.DAILY.PJMESS.ST&STR,
// DISP=(NEW,CATLG,DELETE),
// DCB=(N.MODEL,RECFM=FB,LRECL=81,BLKSIZE=0),
// SPACE=(CYL,(1,1),RLSE)
//*
//SYSIN DD DUMMY
//*
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSOUD DD SYSOUT=*
//SYSABOUT DD SYSOUT=*
//*
//ENDIF10 ENDIF
//*-------------------------------------------------------------------
//IF20 IF (RC=0) THEN
//PS0020 EXEC FTPPROC
//*-----------------------------------------------------------------*
//*- STEP FUNCTION: -
//* FTP PJITEM MESSAGE FILE FROM NT MACHINE TO HOST
//*- -
//*- RESTART IN THIS STEP IF THE FILE IS NOT FOUND -
//*-------------------------------------------------------------------
//*
//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
//*-------------------------------------------------------------------
//*- E N D O F P R O C N B A P 6 0 0 4 -*
//*-------------------------------------------------------------------

Depends on what program sets the 166. If it is home-grown then use your own version of the FTP proc or see if you can provide an override to the cond param of the 166 setting program so that it does not execute. If the 166 is set by FTP itself I think you are stuck.

It seems like the operator console is displaying the highest RC that was returned by any step, and not the RC of the final step. Is that what's happening?