Controlling proc RC



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

Re: Controlling proc RC

Postby NicC » Thu Mar 24, 2011 10:57 pm

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

Re: Re: Controlling proc RC

 

Re: Controlling proc RC

Postby Tim » Thu Mar 24, 2011 11:48 pm

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

Re: Controlling proc RC

Postby enrico-sorichetti » Thu Mar 24, 2011 11:57 pm

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
cheers
enrico
When I tell somebody to RTFM or STFW I usually have the page open in another tab/window of my browser,
so that I am sure that the information requested can be reached with a very small effort
enrico-sorichetti
Global moderator
 
Posts: 2644
Joined: Fri Apr 18, 2008 11:25 pm
Has thanked: 0 time
Been thanked: 130 times

Re: Controlling proc RC

Postby steve-myers » Thu Mar 24, 2011 11:59 pm

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
Global moderator
 
Posts: 1886
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 197 times

Re: Controlling proc RC

Postby Tim » Fri Mar 25, 2011 12:30 am

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

Re: Controlling proc RC

Postby Robert Sample » Fri Mar 25, 2011 12:43 am

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.
Robert Sample
Global moderator
 
Posts: 3367
Joined: Sat Dec 19, 2009 8:32 pm
Location: Dubuque, Iowa, USA
Has thanked: 1 time
Been thanked: 222 times

Re: Controlling proc RC

Postby Tim » Fri Mar 25, 2011 12:57 am

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

Re: Controlling proc RC

Postby enrico-sorichetti » Fri Mar 25, 2011 1:47 am

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
cheers
enrico
When I tell somebody to RTFM or STFW I usually have the page open in another tab/window of my browser,
so that I am sure that the information requested can be reached with a very small effort
enrico-sorichetti
Global moderator
 
Posts: 2644
Joined: Fri Apr 18, 2008 11:25 pm
Has thanked: 0 time
Been thanked: 130 times

Re: Controlling proc RC

Postby Tim » Fri Mar 25, 2011 1:57 am

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

Re: Controlling proc RC

Postby enrico-sorichetti » Fri Mar 25, 2011 2:14 am

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>
cheers
enrico
When I tell somebody to RTFM or STFW I usually have the page open in another tab/window of my browser,
so that I am sure that the information requested can be reached with a very small effort
enrico-sorichetti
Global moderator
 
Posts: 2644
Joined: Fri Apr 18, 2008 11:25 pm
Has thanked: 0 time
Been thanked: 130 times

PreviousNext

Return to JCL

 


  • Related topics
    Replies
    Views
    Last post