date_conditions is the master switch: 0 disables all time-based scheduling, 1 enables start_times, days_of_week, and run_calendar
run_window defines the execution deadline: FW jobs stop detecting files outside it, CMD jobs keep running
term_run_time kills long-running CMD jobs — run_window doesn't
Midnight-spanning windows work natively: "22:00 - 06:00" means next day, no extra config
Production failure: Missing run_window on FW jobs triggers on stale files at 3 AM, filling logs with false alerts
✦ Definition~90s read
What is AutoSys date_conditions and run_window?
AutoSys is an enterprise job scheduler used by banks, telecoms, and retailers to automate batch workflows across distributed systems. Its run_window is a time-based constraint that restricts when a job is allowed to start, defined as a start time and end time within a day.
★
date_conditions is the master switch for time-based scheduling.
Unlike a simple start_times attribute, run_window interacts with date_conditions and calendar rules in ways that routinely cause file watchers to miss valid files. The core problem: a job with date_conditions: 1 and a run_window will only trigger if the file arrives during that window AND the job's start time falls on a valid calendar date.
If the file lands at 11:55 PM with a window ending at midnight, the job may never fire because the window closes before the job can evaluate the condition. Midnight-spanning windows (e.g., 22:00-02:00) are particularly treacherous — AutoSys treats the end time as strictly less-than the start time, meaning the window actually covers two calendar days, but the job's date_conditions still require a single valid start date.
The manual glosses over this: overlapping windows don't merge; each window is evaluated independently against the job's calendar, so a file arriving in the overlap of two windows can be missed if neither window's start time aligns with the calendar. In practice, this means you must set run_window to span the entire period your file might arrive, or use max_run_alarm and term_run_time instead, because run_window is a hard gate — not a suggestion.
Plain-English First
date_conditions is the master switch for time-based scheduling. run_window is the closing time — the job has to be done before the window shuts. Together, they give you precise control over when jobs are allowed to run.
Two attributes that beginners often misuse: date_conditions and run_window. They sound related but do different things.
date_conditions toggles whether time scheduling is even active. Set it to 0, and start_times is ignored entirely — only conditions or manual triggers run the job. Set it to 1, and your schedule kicks in.
run_window is a deadline, not a kill switch. For CMD jobs, AutoSys raises an alarm when the window closes but won't terminate the job unless you also set term_run_time. For File Watcher jobs, the window is strict — no file detection outside those hours. That difference trips up teams constantly.
Why File Watchers Miss Valid Files
AutoSys run_window is a date condition that restricts job execution to a specific time window, defined by a start time and an end time. The core mechanic: if a job's scheduling conditions are met but the current time falls outside the run_window, the job is held until the window opens. It does not retry or re-evaluate the triggering condition — it simply waits. This is critical for file watchers: a job triggered by a file arrival event (using the 'f' condition) will only start within its run_window. If the file arrives outside the window, the job stays in a 'SUCCESS' or 'TERMINATED' state and never processes that file. The window is evaluated at job start time, not at file arrival time. In practice, use run_window to enforce business hours, maintenance windows, or SLA boundaries. It is not a scheduling filter — it is a gate. Teams misuse it as a retry mechanism, leading to silently dropped file events.
⚠ File arrival outside window = lost event
A file watcher job with a run_window will NOT retroactively start when the window opens if the file arrived earlier. The trigger is evaluated once.
📊 Production Insight
A batch pipeline missed daily EOD files because the upstream FTP dropped them at 23:55, but the watcher's run_window was 00:00-06:00. The job never ran for those files.
Symptom: job status shows 'SUCCESS' (from a previous run) or 'INACTIVE', no new runs, no alerts. Files pile up in the landing directory.
Rule: if a file watcher must catch files arriving at any hour, set run_window to 00:00-23:59 or remove it entirely. Use a separate condition for business-hour processing.
🎯 Key Takeaway
run_window is a gate, not a filter — it blocks execution outside the window but does not queue missed triggers.
File watchers with run_window silently drop file events that arrive outside the window; the job never processes them.
Always pair run_window with a retry or a secondary condition (like a time-based schedule) if file arrival timing is unpredictable.
thecodeforge.io
Autosys Date Conditions Run Window
date_conditions deep dive
date_conditions is binary — 0 or 1. When it's 0 (the default), the job has no time-based schedule. It only runs when explicitly triggered: manually via sendevent, or by a condition (another job's success/failure) evaluating to true.
When date_conditions is 1, the job has a time-based schedule AND can also have conditions. It runs when its time conditions are met AND its dependency conditions (if any) are all true.
Here's the piece that confuses people: setting date_conditions to 1 does NOT override conditions. The job still waits for its condition dependencies. The time schedule just adds another gate.
date_conditions_examples.jilBASH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
/* Job that ONLY runs via dependency (no time schedule) */
insert_job: downstream_job
job_type: CMD
command: /scripts/process.sh
machine: server01
owner: batch
date_conditions: 0 /* no time schedule */
condition: success(upstream_job)
/* Job with BOTH a schedule AND a condition */
insert_job: morning_report
job_type: CMD
command: /scripts/report.sh
machine: server01
owner: batch
date_conditions: 1 /* time-based scheduling active */
days_of_week: mon-fri
start_times: "07:00"
condition: success(overnight_etl) /* also waits forETL to complete */
/* To remove run_calendar and start_times from a job in JIL: */
update_job: morning_report
date_conditions: 0 /* disables time scheduling entirely */
Mental Model
The AND Gate Mental Model
date_conditions changes how conditions and time interact — it doesn't replace either.
date_conditions: 0 → Time = always true. Only conditions matter.
date_conditions: 1 → Time = active gate. Must be true AND all conditions true.
Neither setting makes conditions go away — they're always evaluated.
If you want time OR conditions (not AND), you need two separate jobs with an OR dependency box.
📊 Production Insight
The silent failure: job has date_conditions: 0 but someone added a run_calendar months ago. The calendar sits in the JIL, ignored, no error. The team thinks the job is scheduled. It never runs.
Diagnosis: autorep -J jobname -q | grep -E "date_conditions|run_calendar|start_times". If date_conditions is 0, time fields exist but are dead.
Rule: When updating jobs, always audit date_conditions after adding time attributes. The default is 0. Many assume it auto-enables — it doesn't.
🎯 Key Takeaway
date_conditions is the master switch — 0 means ignore all time fields
1 means time is an active gate that ANDs with conditions
Default is 0. Engineers who forget this watch jobs never run.
Which date_conditions value should you use?
IfJob runs ONLY when another job finishes — no time schedule
→
Usedate_conditions: 0. Start_times and run_calendar not needed.
IfJob runs at a specific time AND must also wait for upstream jobs
→
Usedate_conditions: 1. Time gates AND condition gates both apply.
IfJob runs at a specific time regardless of upstream jobs
→
Usedate_conditions: 1 with no condition attribute. Or use start_times alone.
IfFile Watcher must check continuously, not on a schedule
→
Usedate_conditions: 0. The watcher runs constantly within its run_window.
run_window — the execution window
run_window defines the hours during which a job is permitted to run. It works differently depending on job type.
For CMD jobs: If the job starts and is still running when the window closes, AutoSys raises a max_run_alarm (if configured) but doesn't automatically kill it — term_run_time does that. The window is advisory: a polite suggestion, not a hard stop.
For File Watcher jobs: The watcher only looks for files during the run_window. Outside the window, it won't detect files even if they're present. This is the most important use of run_window — it's enforced, not advisory.
For Box jobs: run_window applies to the box itself. Jobs inside the box inherit the box's window only if they don't have their own run_window defined.
run_window_examples.jilBASH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
/* FileWatcher: only detects files between 8AM and 6PM */
insert_job: watch_for_feed
job_type: FW
watch_file: /data/feeds/FEED_*.dat
watch_interval: 30
min_file_size: 1024
machine: file-server
owner: batch
run_window: "08:00 - 18:00"
/* CMD job: must complete within overnight batch window */
insert_job: nightly_reconcile
job_type: CMD
command: /scripts/reconcile.sh
machine: finance-server
owner: batch
date_conditions: 1
days_of_week: all
start_times: "23:00"
run_window: "23:00 - 05:30" /* window for job execution */
term_run_time: 390 /* hard kill after 6.5 hours */
⚠ run_window on CMD jobs does NOT kill
This is the #1 misunderstanding. Autosys raises alarm $MAX_RUN_ALARM when a CMD job runs past run_window, but the process keeps running. Without term_run_time, a hung job can run for days past its window, consuming resources and blocking downstream dependencies that wait on its completion status.
📊 Production Insight
We saw a reconciliation job that ran past its 5:30 AM window every day. The team thought run_window would kill it. Instead, it overlapped with the morning online transaction window — table locks from the job caused 30-second delays on customer orders.
The alarm fired, no one monitored it. The job kept running until 7:45 AM, killed manually by an engineer checking on the slow system.
Fix: add term_run_time: 240 (4 hours). Now the job dies at 3:00 AM if it's still running, well before the transaction window opens.
Rule: run_window without term_run_time is a notification, not a termination.
🎯 Key Takeaway
run_window for CMD = advisory deadline + alarm trigger
run_window for FW = enforced detection gate
term_run_time = the actual kill switch
Use all three together for real protection.
thecodeforge.io
Autosys Date Conditions Run Window
Midnight-spanning windows
run_window windows that span midnight (e.g., "22:00 - 06:00") work correctly in AutoSys — the end time next day is understood automatically. This is common for overnight batch windows.
No special syntax needed. Just write the start time and end time. AutoSys compares current time against the window logically: if start > end, the window crosses midnight.
midnight_window.jilBASH
1
2
3
4
5
6
7
/* Overnight batch window: 22:00 to 06:00 next day */
insert_job: overnight_batch
job_type: BOX
date_conditions: 1
days_of_week: mon-fri
start_times: "22:00"
run_window: "22:00 - 06:00" /* correctly handles midnight crossing */
💡Testing midnight windows
Always test a midnight-spanning window with autorep -J jobname -q after creation. The output shows the raw run_window string — no "next day" indicator. To verify logic, temporarily change the system time or use a test job with a 5-minute window that crosses midnight.
📊 Production Insight
Edge case: run_window "23:00 - 00:30" works — start 23:00, end 00:30 next day. But some engineers write "00:30 - 23:00" thinking it means the same. That window runs for 22.5 hours, not 1.5 hours.
AutoSys evaluates the window as written. If start < end, it's a same-day window. If start > end, it's overnight.
Failure scenario: A job meant to run overnight from 11 PM to 1 AM had run_window "01:00 - 23:00" (typo, swapped start and end). The job ran for 22 hours, overlapping day shifts, causing contention on shared resources.
Rule: Always check your window direction. If you mean overnight, start time must be LATER than end time numerically.
🎯 Key Takeaway
start > end = midnight-crossing window
start < end = same-day window
Test with a 10-minute window before deploying overnight schedules.
Swap start/end by accident and your job runs all day.
The Real Reason Your Window Ignored the Calendar
You slapped `date_conditions: 1` on a job and assumed it would only run on the 15th. Then it ran on the 14th. Then it didn't run on the 15th. Now you're blaming Autosys.
Stop. The problem isn't the date condition — it's the combination of calendar resolution and start_time. Autosys resolves start_time against the job's defined calendar, not the system clock. If your calendar says 'every Monday' but your start_time is 00:05, and the job lands on a holiday, the window opens but no run happens. The box stays green. Zero alarms.
Here's the fix: always pair date_conditions with an explicit run_calendar or a condition that references a predecessor. Never let a date-conditioned job fly solo unless you've tested it with the exact calendar entry. And if you're using start_mins, remember it's relative to start_time, not absolute — that's the silent killer.
Job PAYROLL_PROCESS_START scheduled for 2025-04-15 02:00
Calendar US_BUSINESS_DAYS: 2025-04-15 is Tuesday (valid)
Job window opens at 02:00, closes at 02:30
No predecessor — job runs if date condition passes
⚠ Production Trap:
If you skip run_calendar, Autosys uses the system default calendar — which includes weekends and holidays. Your 'first-of-month' job just ran on January 1st because nobody told it to skip New Year's Day.
🎯 Key Takeaway
date_conditions without run_calendar is a promise you didn't sign — it runs on any day the system clock says the date matches.
What the Manual Won't Tell You About Overlapping Windows
You've got two jobs in a box. Both have run_window: 01:00 - 02:00. One runs at 01:05, the other at 01:10. The box triggers at 01:00. Both windows open simultaneously. But only the first finishes. The second sits in ACTIVATED state until 02:00, then gets skipped because the window closed while it was waiting for resources.
This is the overlapping window problem. The manual says 'windows are independent per job.' That's true but useless. What matters is that Autosys evaluates the window at job start time, not job end time. If the window closes while the job is in queue, the job is marked as skipped — not failed, not terminated. You get no alert. The SLA report shows 'completed' because it was never in an error state.
Solution: stagger start times by at least your worst-case job duration. Or use max_run_alarm to catch jobs that overstay. Better yet, set run_window on the box level, not the individual jobs, and let the box handle the scheduling.
OverlappingWindow.ymlYAML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
// io.thecodeforge — devops tutorial
// Problem: both jobs share window, second one gets skipped
insert_job: DATA_LOAD_A
job_type: c
command: /etl/load_a.sh
date_conditions: 1
start_time: "01:00"
run_window: "01:00"
insert_job: DATA_LOAD_B
job_type: c
command: /etl/load_b.sh
date_conditions: 1
start_time: "01:05"
run_window: "01:00"
// Fix: give each job its own window slot
insert_job: DATA_LOAD_A
job_type: c
run_window: "01:00"
insert_job: DATA_LOAD_B
job_type: c
run_window: "01:15"
Output
2025-04-15 01:00: DATA_LOAD_A start window opens
2025-04-15 01:02: DATA_LOAD_A finishes
2025-04-15 01:05: DATA_LOAD_B start window opens
2025-04-15 01:10: DATA_LOAD_B finishes
💡Senior Shortcut:
Use run_window as a deadline rather than a start window. Set it to the latest safe completion time, then rely on start_mins to spread execution. That way, the window only kills jobs that are already late.
🎯 Key Takeaway
An overlapping run_window for parallel jobs is a silent skip generator — stagger start times or use box-level windows to control the chaos.
How to Abuse run_window for Self-Healing Pipelines
Your batch job ran for six hours instead of two. The window closed at 03:00, but the job kept writing to disk until 08:00. Then your 09:00 cleanup job failed because the files were still locked. You had a zombie process orphaned by a skipped job.
Autosys doesn't kill processes when a window closes. run_window only prevents new job starts. If the job is already running when the window closes, it continues to completion — or until you sendevent -E FORCE_STARTJOB something to kill it.
Here's the pattern that saved my ass three times last year: set the run_window to match your maximum allowed processing time. Then add a job that runs five minutes after window close that checks process tables and kills anything still alive. Pair it with max_exit_success: 1 on the zombie killer so it only runs if the parent job is still running.
It's not elegant. It's not in the docs. But it stops a three-hour fire drill every time a job decides to take a nap.
SelfHealingWindow.ymlYAML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
// io.thecodeforge — devops tutorial
// Self-healing pattern: zombie killer runs after window close
insert_job: PAYROLL_HEAVY_LIFT
job_type: c
command: /opt/payroll/process.sh
machine: prod_app_01
date_conditions: 1
start_time: "22:00"
run_window: "03:00"
// Zombie killer runs 5 mins after window close
insert_job: ZOMBIE_KILLER
job_type: c
command: /ops/kill_stale_instances.sh PAYROLL_HEAVY_LIFT 1800
machine: prod_app_01
condition: s(PAYROLL_HEAVY_LIFT)
start_time: "03:05"
// Watchdog checks for orphaned processes
insert_job: PROC_WATCHDOG
job_type: c
command: /ops/check_process_locks.sh /payroll/output
machine: prod_app_01
condition: s(ZOMBIE_KILLER)
Output
22:00: PAYROLL_HEAVY_LIFT starts
03:00: Run window closes. Job continues running
03:05: ZOMBIE_KILLER checks process table
03:05: Found PID 9823 — killing...
03:05: PROC_WATCHDOG starts — no orphaned locks
⚠ Production Trap:
Running kill -9 on Autosys jobs can leave your temp files in an indeterminate state. Always use a grace period: kill with SIGTERM first, wait 30 seconds, then SIGKILL. That five-line script will save your weekend.
🎯 Key Takeaway
run_window doesn't kill running jobs — you must build that yourself with a post-window watchdog that's triggered by job status, not time.
● Production incidentPOST-MORTEMseverity: high
The 3 AM File Watcher That Never Saw the File
Symptom
The file watcher job status shows SUCCESS with zero files processed, but the file exists on disk. No errors in the job log. The condition that depends on this file never triggers.
Assumption
The team assumed run_window only applies to CMD jobs — they didn't realise FW jobs enforce the window strictly. They thought the watcher would detect "late" files immediately when the next window opened.
Root cause
FW jobs check for files ONLY when the current system time falls inside run_window. If a file arrives at 2:57 AM and run_window ends at 3:00 AM, the watcher will see it ONLY if it runs its watch_interval check between 2:57 and 3:00. After 3:00, the watcher stops checking entirely — the file might as well not exist until the next day's window.
Fix
Option 1: Extend run_window to 06:00 to cover the full overnight batch window. Option 2: Set date_conditions: 0 on the FW job so it runs continuously, then add a condition that checks file age before triggering downstream jobs. Option 3: Split the FW job from the schedule — use sendevent -E FORCE_STARTJOB to trigger it manually when the file is confirmed present.
Key lesson
run_window for FW jobs is a detection gate — files outside the window are invisible, not queued.
Always test edge arrival times against the run_window boundary using a file with a timestamp 1 minute before close.
For SLA-critical files, add a second FW job with a wider window or remove date_conditions entirely and rely on file age logic.
Production debug guideWhen jobs don't run when expected — the symptom-to-action map4 entries
Symptom · 01
Job has start_times and days_of_week set but never runs on schedule
→
Fix
Check date_conditions value: autorep -J jobname -q | grep date_conditions. If 0, time scheduling is disabled entirely. Update to 1.
Symptom · 02
File Watcher job completed with SUCCESS but no files were processed, and files exist in watch_dir
→
Fix
Check run_window on the job. If current time is outside the window, the watcher never looked. Check autorep -J jobname -q | grep run_window. Compare with current time.
Symptom · 03
CMD job keeps running past its allowed window and doesn't terminate
→
Fix
run_window is advisory for CMD jobs — it doesn't kill. Check term_run_time. If not set, the job runs indefinitely. Add term_run_time in minutes.
Symptom · 04
Job with run_calendar inserted yesterday runs outside expected dates
→
Fix
run_calendar requires date_conditions: 1. If date_conditions was 0 when calendar was added, the calendar is stored but ignored. Update date_conditions to 1.
★ AutoSys Time Gate Debugging — 60-Second DiagnosisRun these commands when jobs ignore schedules or run at the wrong times
autorep -J JOBNAME -q | grep run_window
date +%H:%M
ls -la /path/to/watch_dir/*.dat
Fix now
update_job: JOBNAME
run_window: "00:00 - 23:59"
CMD job hangs past window+
Immediate action
Check term_run_time value
Commands
autorep -J JOBNAME -q | grep term_run_time
ps -ef | grep process_name
Fix now
update_job: JOBNAME
term_run_time: 360
AutoSys Time Gate Attributes — Side by Side
Attribute
What it does
Applies to job type
Kills the job?
date_conditions: 0
No time schedule — condition/manual trigger only
CMD, BOX, FW
N/A
date_conditions: 1
Enable start_times/days_of_week/run_calendar
CMD, BOX, FW
N/A
run_window
Hours during which job can run / FW can detect
CMD (advisory), FW (enforced)
CMD: No, FW: N/A
term_run_time
Hard-kill job after N minutes
CMD
Yes
⚙ Quick Reference
6 commands from this guide
File
Command / Code
Purpose
date_conditions_examples.jil
/* Job that ONLY runs via dependency (no time schedule) */
date_conditions deep dive
run_window_examples.jil
/* File Watcher: only detects files between 8 AM and 6 PM */
run_window
midnight_window.jil
/* Overnight batch window: 22:00 to 06:00 next day */
Midnight-spanning windows
CalendarDateTrap.yml
insert_job: PAYROLL_PROCESS_START
The Real Reason Your Window Ignored the Calendar
OverlappingWindow.yml
insert_job: DATA_LOAD_A
What the Manual Won't Tell You About Overlapping Windows
SelfHealingWindow.yml
insert_job: PAYROLL_HEAVY_LIFT
How to Abuse run_window for Self-Healing Pipelines
Key takeaways
1
date_conditions
0 = time scheduling OFF. Default. Catches people every time.
2
date_conditions
1 = time is an AND gate with conditions, not an OR gate.
3
run_window for CMD jobs = advisory deadline + alarm, no kill
term_run_time kills.
4
run_window for FW jobs = enforced detection gate. Outside window = files invisible.
5
Midnight windows
start > end means overnight. Swap them and your job runs all day.
6
Always test time gates with autorep -q and a short test window before production.
Common mistakes to avoid
4 patterns
×
Assuming run_window kills CMD jobs
Symptom
A CMD job starts at 23:00, run_window ends at 05:30. The job hangs at 05:31. AutoSys raises alarm $MAX_RUN_ALARM but the job continues running, blocking resources and downstream dependencies until manually killed.
Fix
Add term_run_time to the job: term_run_time: 360 (6 hours). The job terminates 360 minutes after start, regardless of run_window.
×
Using date_conditions: 0 while expecting start_times to work
Symptom
Job has start_times: "07:00" and days_of_week: mon-fri but never runs. autorep shows date_conditions: 0. The time fields are stored but completely ignored.
Fix
update_job: jobname
date_conditions: 1. Then verify with autorep -q.
×
No run_window on File Watcher jobs
Symptom
A file watcher detects a stale file at 3:00 AM that was written at 6:00 PM the previous day. The watcher triggers downstream jobs unnecessarily, causing false alerts and repeated processing of old data.
Fix
Add run_window matching business hours. For a watcher that should only detect files during the overnight batch: run_window: "22:00 - 06:00"
×
run_window start/end swapped for overnight windows
Symptom
Intended overnight window 23:00 - 01:00 but run_window is "01:00 - 23:00". The job runs for 22 hours instead of 2, overlapping day-time production workloads and causing contention.
Fix
For overnight windows, ensure start time > end time numerically. run_window: "23:00 - 01:00" not the reverse.
INTERVIEW PREP · PRACTICE MODE
Interview Questions on This Topic
Q01SENIOR
What is the difference between date_conditions and run_window in AutoSys...
Q02SENIOR
Does run_window automatically kill a CMD job when the window closes?
Q03JUNIOR
How do you disable time-based scheduling on an existing AutoSys job?
Q04SENIOR
Why is run_window important for File Watcher jobs specifically?
Q05JUNIOR
How do you set a run_window that spans midnight in AutoSys?
Q06SENIOR
What happens when a Box has a run_window and a child job has its own run...
Q01 of 06SENIOR
What is the difference between date_conditions and run_window in AutoSys?
ANSWER
date_conditions is a binary flag (0 or 1) that enables or disables all time-based scheduling for a job. When 0, start_times, days_of_week, and run_calendar are ignored. When 1, time scheduling is active and ANDs with any condition dependencies.
run_window defines the hours during which a job may execute. For CMD jobs, it's advisory — AutoSys raises an alarm if the job exceeds the window but does not terminate it. For File Watcher jobs, it's enforced — the watcher ONLY detects files within the window.
The key distinction: date_conditions controls whether time is considered at all. run_window controls the boundaries when time is active.
Q02 of 06SENIOR
Does run_window automatically kill a CMD job when the window closes?
ANSWER
No. For CMD jobs, run_window is advisory only. When a job runs past its run_window, AutoSys raises the max_run_alarm (if configured in the profile) but the job continues executing. To terminate a CMD job after a specific runtime, use term_run_time (value in minutes).
Example: run_window: "23:00 - 05:30" with term_run_time: 390 ensures the job is killed 6.5 hours after start, even if it would otherwise run past 5:30 AM.
Q03 of 06JUNIOR
How do you disable time-based scheduling on an existing AutoSys job?
ANSWER
Use update_job to set date_conditions: 0. This disables all time-based scheduling including start_times, days_of_week, and run_calendar. The job will then run only when triggered by a condition (success/failure of another job) or manually via sendevent.
Important: Setting date_conditions: 0 does NOT remove the time attributes from the JIL — they remain stored but are ignored. To clean up, you can also explicitly remove start_times and run_calendar with update_job.
Q04 of 06SENIOR
Why is run_window important for File Watcher jobs specifically?
ANSWER
File Watcher jobs enforce run_window strictly. Outside the defined window, the watcher does not scan the watch directory at all. Files that arrive outside the window are completely invisible to the job — they are not queued or remembered.
Without run_window, a File Watcher can trigger on stale files at any time of day, causing false downstream processing. With run_window, you can restrict detection to business hours or specific batch windows. This is critical for preventing repeated processing of the same file and for ensuring that SLA-bound files are only detected during their expected arrival windows.
Q05 of 06JUNIOR
How do you set a run_window that spans midnight in AutoSys?
ANSWER
Use a time range where start time is numerically greater than end time. For example, run_window: "22:00 - 06:00" creates a window from 10 PM to 6 AM the next day.
AutoSys automatically interprets start > end as a midnight-spanning window. No special syntax is required. However, test with autorep -J jobname -q to confirm the window string is stored correctly, and verify behavior using a test job with a short window that crosses midnight.
Q06 of 06SENIOR
What happens when a Box has a run_window and a child job has its own run_window?
ANSWER
The child job's run_window overrides the box's window — the job runs only when BOTH its own schedule AND its own window conditions are met, subject to the box's start condition. However, the child cannot start before the box starts, regardless of its run_window.
Common pattern: Box has a wide window (e.g., 22:00 - 06:00 overnight). Different child jobs within the box have narrower windows (e.g., job A: 22:00-23:30, job B: 02:00-04:00). Each child respects its own window, but all are confined to the box's overall execution period.
01
What is the difference between date_conditions and run_window in AutoSys?
SENIOR
02
Does run_window automatically kill a CMD job when the window closes?
SENIOR
03
How do you disable time-based scheduling on an existing AutoSys job?
JUNIOR
04
Why is run_window important for File Watcher jobs specifically?
SENIOR
05
How do you set a run_window that spans midnight in AutoSys?
JUNIOR
06
What happens when a Box has a run_window and a child job has its own run_window?
SENIOR
FAQ · 6 QUESTIONS
Frequently Asked Questions
01
What does date_conditions do in AutoSys?
date_conditions is a flag (0 or 1) that enables or disables time-based scheduling for a job. When set to 0 (the default), the job ignores start_times and days_of_week. When set to 1, the job runs according to its time schedule.
Was this helpful?
02
Does run_window kill a job when the window closes?
For CMD jobs, run_window doesn't automatically kill the job — it's advisory. You need term_run_time to hard-kill a job after a specified number of minutes. For File Watcher jobs, run_window prevents the watcher from detecting files outside the specified hours.
Was this helpful?
03
How do I disable time-based scheduling on an AutoSys job?
Use update_job to set date_conditions: 0. This disables start_times, days_of_week, and run_calendar. The job will only run when triggered by a condition or manually.
Was this helpful?
04
What is the difference between run_window and term_run_time?
run_window defines the hours during which a job is allowed to execute. term_run_time specifies the maximum number of minutes a job can run before AutoSys terminates it. For hard-killing hung jobs, use term_run_time.
Was this helpful?
05
Can run_window span midnight in AutoSys?
Yes. Run windows like "22:00 - 06:00" correctly span midnight. AutoSys understands that the end time is the following day. This is standard for overnight batch scheduling.
Was this helpful?
06
What happens if a File Watcher's run_window closes while it's scanning?
The scan completes if it started before the window closed. The watcher does not abort a scan in progress. However, once the scan finishes, no new scans begin until the next window opens. Files that arrive during the scan are detected in that scan; files that arrive after the scan but before the window closes are detected in the next watch_interval cycle.