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

AntonioS · New User Joined: 27 Mar 2012 Posts: 8 Location: EU

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:

Garry Carroll · Posted: Wed Jul 01, 2015 12:54 pm

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.

Nic Clouston · Posted: Wed Jul 01, 2015 3:02 pm

You can always get the scheduling application to return the status when the job finishes.

enrico-sorichetti · Posted: Wed Jul 01, 2015 3:50 pm

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.

Garry Carroll · Posted: Wed Jul 01, 2015 3:56 pm

enrico-sorichetti · Posted: Wed Jul 01, 2015 3:59 pm

does it count as my

Garry Carroll · Posted: Wed Jul 01, 2015 4:05 pm

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

cheers

AntonioS · New User Joined: 27 Mar 2012 Posts: 8 Location: EU

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:

Garry Carroll · Posted: Thu Jul 02, 2015 2:48 pm

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.

David Robinson · Active User Joined: 21 Dec 2011 Posts: 199 Location: UK

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).