AutoSys Job with Look-Back Condition Skips First Hour During DST Fall Back

Products

• Autosys Workload Automation

Issue/Introduction

This article addresses an issue where an AutoSys job, scheduled with a start_times attribute that falls within the repeated hour of a Daylight Saving Time (DST) "fall back" event, does not trigger as expected. The job has a time-based look-back condition to check for the success of a predecessor job.

The observed behavior is:

1. The job does not run at the first instance of the repeated hour (e.g., the first 1:00 AM).
2. The scheduler attempts to start the job at the second instance of the repeated hour (e.g., the second 1:00 AM).
3. At the second instance, the job fails its condition check with the message: CAUAJM_I_40162 The starting conditions for job <issue_job_name> have not been met. Cannot be started.

This can lead to the job missing its scheduled execution unless manually started

Environment

12.1 (and potentially other versions)

Cause

The behavior is the result of two distinct functions within the AutoSys scheduler when handling the autumn time change.

1. Scheduling During the Repeated Hour:
   This part of the behavior is by design. To prevent jobs from running twice or to avoid ambiguity, the AutoSys scheduler will intentionally skip the first instance of a repeated hour. Any job scheduled to start during that hour will be scheduled to run during the second instance of that hour. For example, a job scheduled for 1:00 AM during a "fall back" where the clock moves from 1:59 AM back to 1:00 AM will only be considered for execution at the second 1:00 AM.

2. Failure of the Look-Back Condition:
   The condition failure is a side effect of the scheduling delay. The look-back condition s(job_name,HH.MM) checks if the predecessor job succeeded within the last HH.MM period from the time the dependent job is evaluated.

   • In the scenario from the case, the predecessor job "Issue_job_name" finished at 00:00:04.
   • The dependent job  "Issue_job_name" was scheduled for 01:00 with a one-hour look-back: condition: s(...,01.00).
   • Due to the DST change, the scheduler did not evaluate this job until the second 01:00 AM.
   • From the scheduler's perspective, two hours of clock time have passed between 00:00 and the second 01:00.
   • When the condition was checked, the predecessor's success at 00:00:04 was now outside the 01.00 (one-hour) look-back window, causing the condition to fail.

Resolution

To prevent this issue, you can apply one of the following workarounds:

1. Extend the Look-Back Period:
   Temporarily modify the job definition to extend the look-back period to cover the extra hour from the DST change. For the day of the time change, you would change the condition to look back at least two hours.

   • Example: Change condition: s(dependant_job_name,01.00) to condition: s(dependant_job_name,02.00).
     This change should be planned and applied before the DST event.

2. Adjust Job Scheduling:
   Schedule the dependent job to run outside of the repeated hour. For example, setting the start_times to "02:01" would avoid the ambiguity of the repeated 1:00 AM hour altogether.

Additional Information

Refer to the explanation below clearly explained:

Standard Time Changes