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