How Job Management Manager Works › Delta Time Formats › Job Management Manager Delta Time › Time Creep in Jobs

Time Creep in Jobs

When a job’s schedule interval is a delta time expression, for instance, "+00 15:00," the manager calculates the job’s next scheduled run time by adding the time interval to the job’s actual start time. Typically, there is a small time lapse (usually a second or two) between a job’s scheduled start time and the time it actually begins to run. When delta time schedule intervals are used, this time delay is reflected in the job’s next scheduled run time. For example, a job that was scheduled to start at 11:30:00.00 may be next scheduled to run at 11:45.01.35, reflecting a "time creep" of 1.35 seconds.

You can use the /USE_NEXT_TIME qualifier when creating or modifying a job that uses a delta time interval. This will calculate the next scheduled run time from the scheduled time, not from the actual start time, preventing time creep. However, if a user uses the RUN command to run the job manually, the job will add the delta time interval to the next scheduled run time. This problem can be avoided by using the command RUN/NORESCHEDULE when running the job manually.

Alternatively, you can create several similar jobs with specific schedule intervals. For example, to run a job every fifteen minutes exactly (beginning on the hour, 15 minutes past, 30 minutes past, and 45 minutes past), create four similar jobs with the following schedule intervals:

• H 00:00
• H 15:00
• H 30:00
• H 45:00

When calculating a job's Next Scheduled Run Time, the manager starts by finding the start of the next period specified in the Schedule interval. For example, if using a schedule interval of "D 22:00," the manager first finds the start of the next Day and then applies the hour specification. The resulting Next Scheduled Run Time always lies within the next period of time. For example, if a job with an interval of "D 22:00" is created (or run) at 10AM today, the next scheduled run time for that job will be tomorrow at 22:00 (Not today at 22:00). This behavior is expected.

Note: You must keep the system times for all nodes in a cluster synchronized. Time differences between cluster nodes can result in job dependencies not being processed correctly or jobs running repeatedly.