IBM Mainframe Forum

I doubt it - most processes do not write to the console - the operators would be snowed under! It is probably the program writing to the console.

Sorry for my imprecise terminology again. It's not "the operator console" but something called OPCA which I understand is a job scheduling system from Tivoli. It displays the job name, start and stop time, and "return code", but apparently only for jobs with a non-zero return code. Somehow the 166 from the failed ftp step is displayed as the job error code, even though the final step in the job had an RC of 0.

I assume that a job somehow returns a code to the OS or scheduler or whatever it is that displays the status of completed jobs. Is that code the highest RC that was generated while the job was running?

the best approach in this case ( not to bother anybody for manual intervention )
would be to split the process in three stages under TWS ( OPC) control

stage 1 before the ftp
stage 2 ( the FTP step )
stage 3 the rest

the stage 2 scheduling might be a bit tricky
if stage 2 completes then schedule stage 3
if stage 2 fails schedule a stage2 clone with the same criteria
define as many stage2 clones as the retries You want to implement

its a pity that ( unless I am wrong ) tws does not have the ability to interval loop a job until success

but if the requirement and the setup is carved in stone ( as it seems ) You will just have to bear it
and provide manual intervention

NicC wrote:I doubt it - most processes do not write to the console - the operators would be snowed under! It is probably the program writing to the console.

Many sites use the IEFACTRT exit routine to write a step return code to the operator console, or at least the SYSLOG and the job's JESMSGLG. I agree with NicC; user code should not be writing messages to the operator unless there is no better alternative, or the user code must report something to the operator.

steve-myers wrote:Many sites use the IEFACTRT exit routine to write a step return code to the operator console, or at least the SYSLOG and the job's JESMSGLG. I agree with NicC; user code should not be writing messages to the operator unless there is no better alternative, or the user code must report something to the operator.

As far as I know, no one is writing anything to anyone.

There is simply a screen that lists job name, start time, end time, and "return code". After my job runs, the "return code" shows as 166. That happens to be the RC from one step in the middle of the job. The last step in the job has RC 0. Does anyone have any clue why my job's "return code" is 166 and not 0?

A job's completion (or return) code is going to be the largest completion code of any step executed within the job -- unless there's an abend in which case the abend code is the return code. An FTP condition code of 0166 is usually an FTP return code of 16550, which means a GET was attempted but the data set being retrieved did not exist on the server.

THANK YOU!! That's the answer I was looking for.

Is there any way to force the job completion code to a different value? In my case, when the ftp fails, the proc sleeps a few seconds then executes the ftp a second time and it succeeds. If it were to fail the second time, the completion code would and should be 166, but if the second attempt succeeds, I want the completion code to be 0.

Is there any way to force the job completion code to a different value? In my case, when the ftp fails, the proc sleeps a few seconds then executes the ftp a second time and it succeeds. If it were to fail the second time, the completion code would and should be 166, but if the second attempt succeeds, I want the completion code to be 0.

as said before You must change the process ( scripting it ) or using the TWS approach I described
if You cannot change anything You will have to live with it

enrico-sorichetti wrote:You must change the process ( scripting it ) or using the TWS approach

I'm sorry, but I have no idea what any of that means.

Does anyone know if it's possible to force a job completion code to 0?

I'm sorry, but I have no idea what any of that means.

strange I expressed those concept with terms commonly used in IT

Does anyone know if it's possible to force a job completion code to 0?

we all know that it is not possible

when working with a scheduler the LUW is the operation and what the scheduler considers
is how the operation ended ( success, error ) and it is not related ( broad sense ) to the jcl return code
it is quite normal to consider in certain circumstances an operation ended with success even if the job ended in error ( RC/ABEND)

but the process must be split in the proper number of operations in order to have the appropriate granularity

You need to work with Your TWS(OPC) support to consider planned and managed errors as <not errors>