Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Rules for evaluating JES output to determine if a job ended ok

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM
View previous topic :: :: View next topic  
Author Message
AntonioS

New User


Joined: 27 Mar 2012
Posts: 8
Location: EU

PostPosted: Wed Jul 01, 2015 2:03 am    Post subject: Rules for evaluating JES output to determine if a job ended ok
Reply with quote

We have a client application that submits a job to JES, waits until it has finished, and then retrieve the job output. From the job output, we try to figure if the job ended okay or not.

We have found the following messages to scan for in JESMSGLG:

Job failed due to JCL error:
Code:
hh.mm.ss jobid  IEF453I jobname - JOB FAILED - JCL ERROR - TIME=hh.mm.ss


Job failed due to return code:
Code:
hh.mm.ss jobid  IEF451I jobname jobstep - ENDED BY CC ccode - TIME=hh.mm.ss


Job failed due to abend:
Code:
hh.mm.ss jobid  IEF450I jobname stepname - ABEND=scode Uucode REASON=rcode                     TIME=hh.mm.ss


If these messages do not appear in the log, and the following appears, I would assume the job ended fine:
Code:
hh.mm.ss jobid  IEF404I jobname - ENDED - TIME=hh.mm.ss


However, this seems to me as if it could turn out to be a bit unstable. Is there a better approach to evaluate the job output?
Back to top
View user's profile Send private message

Garry Carroll

Active Member


Joined: 08 May 2006
Posts: 988
Location: Dublin, Ireland / Edinburgh, Scotland

PostPosted: Wed Jul 01, 2015 12:54 pm    Post subject:
Reply with quote

I hope the client application in not running on the mainframe? The idea of having an application submit a job and "wait" for its completion has been covered numerous times - and is considered a very bad idea.

As to checking for successful completion of a job, I think it would be better to check the cond codes and not rely on catching all possible failures. A job could, for example, be considered either successful or failed where any step has a non-zero cond code. In some shops, a dummy step is included as a last step to set cond code zero only if all previous steps are considered successful. In this case, the job is OK if the last step has cond code zero.

Garry.
Back to top
View user's profile Send private message
Nic Clouston

Global Moderator


Joined: 10 May 2007
Posts: 1714
Location: UK

PostPosted: Wed Jul 01, 2015 3:02 pm    Post subject:
Reply with quote

You can always get the scheduling application to return the status when the job finishes.
Back to top
View user's profile Send private message
enrico-sorichetti

Global Moderator


Joined: 14 Mar 2007
Posts: 10202
Location: italy

PostPosted: Wed Jul 01, 2015 3:50 pm    Post subject: Reply to: Rules for evaluating JES output to determine if a job ended ok
Reply with quote

a non 0 return code from a step does NOT mean that the process ended in error

for example ( very common case )
if You need to run a step only if a dataset contains data
the usual way is to run a step to check if the dataset is empty...
with RC 0 for NON EMPTY, RC 4 for EMPTY

a RC 4 does not imply an error, just a different situation.
Back to top
View user's profile Send private message
Garry Carroll

Active Member


Joined: 08 May 2006
Posts: 988
Location: Dublin, Ireland / Edinburgh, Scotland

PostPosted: Wed Jul 01, 2015 3:56 pm    Post subject:
Reply with quote

Quote:
a non 0 return code from a step does NOT mean that the process ended in error

for example ( very common case )
if You need to run a step only if a dataset contains data
the usual way is to run a step to check if the dataset is empty...
with RC 0 for NON EMPTY, RC 4 for EMPTY

a RC 4 does not imply an error, just a different situation.
_________________
cheers
enrico


Which is what I meant by
Quote:
A job could, for example, be considered either successful or failed where any step has a non-zero cond code.
Back to top
View user's profile Send private message
enrico-sorichetti

Global Moderator


Joined: 14 Mar 2007
Posts: 10202
Location: italy

PostPosted: Wed Jul 01, 2015 3:59 pm    Post subject: Reply to: Rules for evaluating JES output to determine if a job ended ok
Reply with quote

icon_redface.gif

does it count as my
Quote:
Everyone's entitled to ONE fatal mistake.....

? icon_wink.gif
Back to top
View user's profile Send private message
Garry Carroll

Active Member


Joined: 08 May 2006
Posts: 988
Location: Dublin, Ireland / Edinburgh, Scotland

PostPosted: Wed Jul 01, 2015 4:05 pm    Post subject:
Reply with quote

... well.... hardly fatal, Enrico.

cheers

icon_lol.gif
Back to top
View user's profile Send private message
AntonioS

New User


Joined: 27 Mar 2012
Posts: 8
Location: EU

PostPosted: Thu Jul 02, 2015 2:28 pm    Post subject:
Reply with quote

Thank you for your thoughts. However, I would prefer rather not to require a special step or something in the job. I just want to find out if it ended okay. Usually, this means:
* No JES/JCL failure
* No abend
* Most of the time, job not ended due to condition codes

As for the condition codes themselves, I often see jobs with RC=8 is okay in some steps, like a delete step that runs first to make sure no old datasets will lead to allocation failures.

I did not quite understand this:

Nic Clouston wrote:
You can always get the scheduling application to return the status when the job finishes.


What do you mean? If you are talking about what is usually referred to as the job stattus, IMO this is just "running" or "on output" (or sometimes "delayed"), but it does not say anything about the job being good or bad. Maybe you referred to something else?
[/list]
Back to top
View user's profile Send private message
Garry Carroll

Active Member


Joined: 08 May 2006
Posts: 988
Location: Dublin, Ireland / Edinburgh, Scotland

PostPosted: Thu Jul 02, 2015 2:48 pm    Post subject:
Reply with quote

You don't NEED to have the final step I mentioned in the job - though it would make life easier. Your client application needs to access the job output and know the criteria for successful execution - the number of steps and the acceptable cond codes for those steps. If these criteria aren't met, the job has failed (or was unsuccessful) for some reason.

However, if you did have the final step in the job, the client application would only have to check on the success/failure of that final step to know whether the job succeeded or failed.

As to the reference made to "scheduling application" this is not a reference to job status displays such as SDSF where the job can be seen as "running", "awaiting execution" etc. Job scheduling applications are systems which manage the submission of jobs following rules for precursor and successor job dependencies. By their nature, these systems have to know the success/failure status of jobs.

Garry.
Back to top
View user's profile Send private message
David Robinson

Active User


Joined: 21 Dec 2011
Posts: 175
Location: UK

PostPosted: Tue Jul 07, 2015 1:15 pm    Post subject: Reply to: Rules for evaluating JES output to determine if a job ended ok
Reply with quote

The OP seems to be over complicating this a bit. In 20+ years as an Ops Analyst I've never had to give that much consideration to determining if a job was successful or not. As others have said, this is exactly what you're scheduler (TWS, CA-7, Control-M, etc.) must know and handles without any problems at all.

The only issue I've ever come across is where a particular RC may or may not be acceptable in a particular job and adjust this specification in the scheduler accordingly. We used TWS and had the default set so that 4 was the highest acceptable return code, but this could be changed at individual job level to 0, 8, or whatever else was required (TWS can also be set (at a global level) to evaluate either the highest step return code, or the last step return code, when determining success or failure).

As a slight aside, back to the original errors to be scanned for, there are of course two flavours of JCL error - jobs that fail with a JCL error (e.g.; dataset not found) and jobs that do not run due to a JCL error (e.g.; syntax error).
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Problem in writing Output file vickey_dw COBOL Programming 5 Mon Nov 14, 2016 11:14 pm
No new posts Syncsort - Hard coded Value in output PORYES SYNCSORT 1 Thu Nov 03, 2016 9:23 am
No new posts output data in CSV Format janmejay COBOL Programming 8 Sat Oct 15, 2016 2:20 pm
This topic is locked: you cannot edit posts or make replies. output data in CSV Format janmejay DFSORT/ICETOOL 3 Sat Oct 15, 2016 2:16 pm
No new posts ICETOOL/SYNCSORT - SYSPRINT output nartcr DFSORT/ICETOOL 17 Wed Oct 05, 2016 10:46 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us