Autosys job condition related query

[Arihara Subramanian]

Hello experts,

We have a job that is configured to run only when its box job completes successfully, using a lookback condition one hour. The job is also controlled by a run_calendar, so it should run only when both the dependency and the calendar requirements are satisfied.

In our recent case, one of the jobs inside the box (which is the parent dependency for this job) failed, and the team performed a force start to mark it as successful.

Immediately after the box showed a successful status, the dependent job was triggered - even though the run_calendar condition was not satisfied at that time.

Could you please explain:

1. What caused the job to trigger even though the run_calendar condition was not satisfied?
2. How can we prevent this type of unwanted trigger in the future?

-------------------------------------------

[Chandrasekaran Venkataraman]

It is likely that the run_calendar dependency was satisfied a few days back and the job was just waiting for the job-dependency (success of a box within 1 hour). Check the calendar days to see the most recent day the job couldn't run and check the Scheduler log for that day, you might find some comments around why the job was not started. 

-------------------------------------------

[Saicharan Palagiri]

To add more information to Chandru's post:

The behavior you observed is expected in AutoSys when a job has a scheduled start time but is held up by a dependency. The following explains why the job triggered and how to prevent it.

Why the job triggered

When a job is scheduled via a run_calendar and start_times, the scheduler creates a STARTJOB event for the specified day and time. If the job's condition (in this case, the box success with lookback) is not met at that scheduled time, the job does not run immediately; instead, it waits in an ACTIVATED state (or similar status depending on your version) AutoSys jobs running at unexpected times.

Because the job was already "due" to run based on a previous calendar satisfaction, the scheduler keeps the start request pending until the conditions are fulfilled. As soon as the team performed a FORCE_START on the sub-job and the parent box transitioned to SUCCESS, the job's condition was suddenly satisfied. The scheduler then executed the "pending" run of the job, even if the current time or day was no longer a valid "run day" according to the calendar AutoSys jobs running at unexpected times.

How to prevent unwanted triggers

To prevent a job from "catching up" and running at an unwanted time after a manual intervention or delayed dependency, consider the following methods:

• Manually skip the job, If you know the window for the job has passed, change its status to SUCCESS before marking the dependency as successful. This informs the scheduler that the run for that period is already complete Changing the status of job success.
• Use JOB_OFF/JOB_ON, Placing the dependent job ON_ICE or OFF_HOLD and then back to its normal state can sometimes clear pending start events, though status changes are more reliable for skipping runs.
• Refine the Condition, Ensure the lookback value (e.g., s(box_name, 01.00)) is strictly necessary. If you only want the job to run if the box succeeded this specific day, a 0 lookback might be safer, though it still waits for the first success it sees AutoSys jobs running at unexpected times.
• Controlled Delays for complex box dependencies where manual interventions are frequent, adding a "delay" job or a gatekeeper job that checks the current time before allowing the main job to start can prevent execution outside of a specific window Frequent job terminations and KILLJOB behavior.

-------------------------------------------