This Month's Tool Tip

How to Troubleshoot When a Job Does Not Run

SUMMARY

This article explains how to troubleshoot when a job does not run at it is supposed to.

MORE INFORMATION

The most common inquiry received is why a job didn't run like it was supposed to.  Sometimes it helps to see how Schedule is orchestrating the commands/scripts that you have declared in the job. In many cases, the commands are run but the expected results are not obtained. Quite often these unexpected results are caused by environmental or operational reasons.

The following is background to help debug commands and scripts that are run in EnterpriseSCHEDULE.This is a Windows example.  Unix and OpenVMS cases are very similar.

TROUBLESHOOTING SCHEDULE

1. EnterpriseSCHEDULE creates two temp script files "a" and "b" where:
       "a" and "b" - have the path {log_location}{jobname}{schedule_extension}
       "a" - setups the Schedule User environment.
       "b" - is the makeup of the job commands.
2. Schedule deletes these files after the job is run. At times it is helpful to turn off the deleting of these temp files so that you can debug and run these pieces interactively. You can either toggle off the deletion of the temp files by clicking on the field in the job's "submit" property page "Delete Bat File" or "schedule modify \isedirectory\jobname /submit:flags=nodelete"
3. Then in a "CMD" session go to "c:\program files\ise\EnterpriseSCHEDULE\sch0_temp\isedirectory\" and run the "a" and "b" scripts interactively.
4. Some reasons scripts don't behave the way you expect them to:
        a. The locations of where the script is running from.
        b. Who the script is running as.
        c. Permissions, both files/directory and or user rights.
        d. Environmental setup is missing where job is run like a missing mapped drive.
5. Running the pieces interactively helps isolate scripting issues into smaller pieces for debugging.