Senior 3 min · March 19, 2026

AutoSys sendevent Command — FORCE_STARTJOB Pitfalls

FORCE_STARTJOB bypasses file_watcher and calendar checks—one midnight run caused 12 hours of missing ETL data.

N
Naren · Founder
Plain-English first. Then code. Then the interview question.
About
 ● Production Incident 🔎 Debug Guide
Quick Answer
  • sendevent sends signals to the AutoSys Event Processor to control jobs
  • Common events: FORCE_STARTJOB, STARTJOB, KILLJOB, JOB_ON_HOLD, CHANGE_STATUS
  • Use -E for event type and -J for job name; -S for instance name
  • Performance: bulk events without sleep can overwhelm the Event Processor queue
  • Production insight: sending FORCE_STARTJOB when dependencies are unmet can cause silent data corruption
  • Biggest mistake: assuming STARTJOB runs the job immediately — it only works if conditions are satisfied
Plain-English First

sendevent is the remote control for your AutoSys jobs. Just like a TV remote sends signals to change channels, sendevent sends signals to AutoSys to change what a job is doing — start it, stop it, put it on hold, release it, kill it.

sendevent is one of the most frequently used AutoSys commands in day-to-day operations. Every manual job control action — starting a job, putting it on hold, killing it, setting a global variable — goes through sendevent. It's the command-line interface to the AutoSys event system. If you've ever triggered a production outage because you sent the wrong event, you know exactly why this reference exists.

sendevent syntax and key options

The basic syntax is: sendevent -E event_type -J job_name. The -E flag specifies the event type, -J the job name. Most commands also support -S for the AutoSys instance name if you have multiple environments. Always use single quotes around job names if they contain special characters. The event types are case-sensitive — KILLJOB works, killjob doesn't.

sendevent_syntax.shBASH
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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
# Basic syntax
sendevent -E EVENT_TYPE -J job_name

# For a specific AutoSys instance
sendevent -E EVENT_TYPE -J job_name -S INSTANCE_NAME

# ── The most common sendevent operations ──────────────────────────

# Force start a job (run immediately regardless of conditions)
sendevent -E FORCE_STARTJOB -J daily_report

# Start a job normally (only if conditions are met)
sendevent -E STARTJOB -J daily_report

# Kill a running job
sendevent -E KILLJOB -J daily_report

# Put a job on hold (won't run until released)
sendevent -E JOB_ON_HOLD -J daily_report

# Release a job from hold
sendevent -E JOB_OFF_HOLD -J daily_report

# Put a job on ice (stronger suspension)
sendevent -E JOB_ON_ICE -J daily_report

# Release from ice
sendevent -E JOB_OFF_ICE -J daily_report

# Delete a job via event
sendevent -E DELETEJOB -J old_legacy_job

# Manually change a job's status
sendevent -E CHANGE_STATUS -J job_name -s SUCCESS

# Set a global variable
sendevent -E SET_GLOBAL -G "TRADE_COUNT=5432"

# Stop the Event Processor gracefully
sendevent -E STOP_DEMON
FORCE_STARTJOB vs STARTJOB
STARTJOB only works if the job's starting conditions are currently met. FORCE_STARTJOB bypasses all conditions and starts the job immediately. Use FORCE_STARTJOB with caution in production — you're deliberately skipping the dependency checks that are there for a reason.
Production Insight
Sending events to the wrong instance is the #1 cause of sendevent 'not working'.
Always use -S when your environment has multiple AutoSys instances (dev, test, prod).
Tip: set $AUTOSYS in your shell to avoid forgetting.
Key Takeaway
Flag order doesn't matter, but case does.
Get into the habit of: sendevent -E EVENT -J job -S instance.
That pattern catches 90% of execution errors.
sendevent Event Types sendevent Event Types. Control any aspect of job execution · Start Events · STARTJOB — if conditions met · FORCE_STARTJOB — bypass all · RESTART — retry failed job · CHANGE_STATUS — manual overrideTHECODEFORGE.IOsendevent Event TypesControl any aspect of job execution Start EventsSTARTJOB — if conditions metFORCE_STARTJOB — bypass allRESTART — retry failed jobCHANGE_STATUS — manual override Hold EventsJOB_ON_HOLD — pause jobJOB_OFF_HOLD — resume nowJOB_ON_ICE — suspend runJOB_OFF_ICE — next cycle System EventsKILLJOB — terminate runningDELETEJOB — remove definitionSET_GLOBAL — set variableSTOP_DEMON — stop schedulerTHECODEFORGE.IO
thecodeforge.io
sendevent Event Types
Autosys Sendevent Command

CHANGE_STATUS — manually overriding job status

CHANGE_STATUS lets you manually set a job to SUCCESS or FAILURE. This is used in recovery scenarios: if a job failed but the issue has been resolved manually outside AutoSys, you can mark it SUCCESS so downstream jobs can proceed. But be careful: you're lying to the scheduler, and downstream jobs may trust the data that never arrived. Use it only when you have verified the work is complete.

change_status.shBASH
1
2
3
4
5
6
7
8
# Manually mark a job as SUCCESS (to unblock downstream dependencies)
sendevent -E CHANGE_STATUS -J extract_job -s SUCCESS

# Manually mark a job as FAILURE (to block downstream from starting)
sendevent -E CHANGE_STATUS -J questionable_job -s FAILURE

# After CHANGE_STATUS to SUCCESS, downstream jobs that were waiting
# will now evaluate their conditions and may start automatically
Output
/* Event processed: extract_job status changed to SUCCESS
Downstream job 'transform_job' condition now met — starting */
When CHANGE_STATUS to SUCCESS is appropriate
Use CHANGE_STATUS to SUCCESS when: a job failed due to an infrastructure issue (disk full, network blip) but the actual data processing completed successfully; or you need to unblock a dependency chain while a failed job is being investigated and fixed manually.
Production Insight
CHANGE_STATUS to FAILURE is safer than SUCCESS — it forces explicit investigation.
Many teams have been burned by marking a job SUCCESS only to find it didn't actually run.
Always e-mail the team or enter a ticket before changing job status.
Key Takeaway
CHANGE_STATUS is a surgical knife, not a hatchet.
Use -s FAILURE to stop a chain, -s SUCCESS only when the work is verified.
One misapplied SUCCESS can corrupt downstream data for hours.

Using sendevent in shell scripts for automation

sendevent becomes especially powerful when used inside shell scripts for batch recovery automation. Instead of manually sending events one by one, you can script common operational patterns — like automatically restarting all failed jobs, or setting a global variable and triggering a downstream job in sequence. But there are traps: looping without a sleep can flood the Event Processor, and forgetting to quote variable expansions can break the command.

sendevent_scripting.shBASH
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
#!/bin/bash
# Auto-restart all FAILURE jobs matching a pattern

PATTERN="PRD_TRADING_%"

echo "Checking for failed jobs matching: $PATTERN"
FAILED_JOBS=$(autorep -J $PATTERN -s FA | awk 'NR>2 {print $1}' | grep -v '^$')

if [ -z "$FAILED_JOBS" ]; then
    echo "No failed jobs found"
    exit 0
fi

for JOB in $FAILED_JOBS; do
    echo "Restarting: $JOB"
    sendevent -E RESTART -J "$JOB"
    sleep 2   # brief pause between events to avoid overwhelming Event Processor
done

echo "Restart events sent for: $(echo $FAILED_JOBS | wc -w) jobs"

# Pattern 2: Set a global, then trigger downstream job
RECORD_COUNT=$(wc -l < /data/processed.csv)
sendevent -E SET_GLOBAL -G "TRADING_COUNT=${RECORD_COUNT}"
sendevent -E STARTJOB -J PRD_TRADING_VALIDATE_COUNT
Output
Checking for failed jobs matching: PRD_TRADING_%
Restarting: PRD_TRADING_EXTRACT_DAILY
Restarting: PRD_TRADING_TRANSFORM_DAILY
Restart events sent for: 2 jobs
Add a sleep between bulk sendevent calls
When sending many sendevent calls in a loop, add a small sleep (1-2 seconds) between them. Flooding the Event Processor with hundreds of events simultaneously can cause delayed processing. A small pause keeps the event queue manageable.
Production Insight
Scripting sendevent is great, but watch for race conditions.
If your script sends STARTJOB before SET_GLOBAL finishes processing, the job runs with the old global value.
For dependent operations, use autorep to verify the state before issuing the next event.
Key Takeaway
Automate recovery, but don't forget to slow down.
Sleep 2 seconds between events. Always quote your variables.
Test your script on a non-production instance first.

sendevent Event Types Deep Dive — When to Use Each

Beyond the common events, there are less frequently used but critical ones: DELETEJOB to remove jobs, RESTART to restart a failed job (respects conditions), STOP_DEMON for graceful shutdown, and SET_GLOBAL for variables. Understanding the nuances — like RESTART only works on FAILURE jobs, or that JOB_ON_ICE prevents the job from running indefinitely until explicitly released — can prevent outages.

event_types.shBASH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# RESTART - only works if job status is FAILURE or has next cycle pending
sendevent -E RESTART -J export_daily   # re-runs with original conditions

# DELETEJOB - removes job definition permanently; use with extreme care
sendevent -E DELETEJOB -J old_job

# SET_GLOBAL - sets a global variable visible to all jobs
sendevent -E SET_GLOBAL -G "ENVIRONMENT=STAGING"

# SENDSTATUS - sends an application status (rarely used, but available)
sendevent -E SENDSTATUS -J my_job -s "Data validated OK"

# STOP_DEMON - graceful shutdown of Event Processor
sendevent -E STOP_DEMON

# START_DEMON - restart Event Processor (usually via script, not sendevent)
# NOTE: There is no START_DEMON event; use the autostart mechanism
Mental Model: Events are signals, not commands
  • Events are queued and processed asynchronously by the Event Processor
  • There's a small delay (milliseconds to a few seconds) between sending and the job reacting
  • Multiple events for the same job are processed in order, but events for different jobs may interleave
  • Persistent events (like STOP_DEMON) override later related events
Production Insight
DELETEJOB is irreversible. Once sent, the job is gone from the database.
Always verify you have the correct JIL export before deleting.
Consider deactivating the job (via JIL) instead.
Key Takeaway
Know which events wait and which fire instantly.
FORCE_STARTJOB fires now; STARTJOB waits. JOB_ON_HOLD prevents both.
For deleting, use JIL deactivation first, then DELETEJOB only after a cooling period.

sendevent Troubleshooting and Common Failures

When sendevent 'does nothing', the culprit is almost always one of: wrong instance name, job name typo, case mismatch, or the Event Processor is down. Other issues: sending FORCE_STARTJOB to a box job (which may be running), or forgetting that JOB_ON_HOLD doesn't affect a job already running — you need KILLJOB first. This section gives you the debug flow to resolve 90% of issues in under a minute.

troubleshoot_sendevent.shBASH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# Step 1: Is the Event Processor running?
autorep -W   # returns NOSUCH? If yes, Event Processor is down

# Step 2: What is the job's current status?
autorep -q jobname | head -20

# Step 3: Check event log for recent events
tail -100 $AUTOUSER/events/events.log | grep jobname

# Step 4: Verify job name spelling and case
autorep -J "JOBNAME*" | grep -i jobname

# Step 5: Test connectivity to Event Processor host
ping autoevent_host

# Step 6: Check for multiple instances
sendevent -E PING   # sends a test event; responds with 'PONG' from Event Processor
Output
AutoSys Event Processor: UP (pid 12345)
Job: daily_report
Status: FAILURE
...
sendevent -E PING is your best friend
PING sends a test event to the Event Processor. If you get 'PONG' back (in the event log), you know the connection works. If not, you have a connectivity or Event Processor problem. Always run this before escalating.
Production Insight
The event log is your gold mine. $AUTOUSER/events/events.log records every sendevent.
When an event 'didn't work', check the log — it often tells you exactly why (e.g., 'Invalid job name' or 'Non-existent instance').
Don't forget: events are case-sensitive, so 'daily_report' vs 'Daily_Report' are different.
Key Takeaway
When sendevent fails silently, work through the checklist in order.
Start with autorep -W, then -q, then event log.
Send PING to test connectivity. Never assume the Event Processor is running.
● Production incidentPOST-MORTEMseverity: high

The midnight FORCE_STARTJOB that ran ETL before the source data arrived

Symptom
ETL job completed with zero rows. Downstream reports showed missing data for 12 hours.
Assumption
FORCE_STARTJOB is safe because the job had already run earlier that day.
Root cause
FORCE_STARTJOB bypasses all conditions — including file_watcher and calendar dependencies. The job ran before the external file was present.
Fix
Use sendevent -E RESTART -J jobname which respects conditions. Alternatively, verify the upstream state manually before forcing.
Key lesson
  • FORCE_STARTJOB is for emergencies — always verify the reason the job is waiting first
  • When in doubt, use STARTJOB or RESTART, not FORCE_STARTJOB
  • Document in your runbook: which jobs can be force-started and which cannot
Production debug guideSymptom → Action guide for when events don't work as expected4 entries
Symptom · 01
sendevent returns immediately but job doesn't change state
Fix
Check autorep -q jobname to see if event was queued. If not, verify Event Processor is running with autorep -W.
Symptom · 02
sendevent -E STOP_DEMON doesn't stop Event Processor
Fix
You may have sent to the wrong instance. Use -S with the correct instance name. If still not stopping, check the event log at $AUTOUSER/events.
Symptom · 03
Job receives FORCE_STARTJOB but never starts
Fix
Check if the job's status is INACTIVE or SUCCESS — FORCE_STARTJOB may not apply. Use JOB_ON_ICE first? Verify with autorep -q.
Symptom · 04
CHANGE_STATUS -s SUCCESS doesn't unblock downstream jobs
Fix
Downstream jobs may be waiting on additional conditions (e.g., date_conditions, alarms). Use autorep -j downstream_job and look at the 'Conditions' column.
★ sendevent Quick Debug Cheat SheetCopy-paste commands for the most common sendevent problems
Event sent but job status unchanged
Immediate action
Check if Event Processor is alive and job name is correct
Commands
autorep -q jobname | grep -E 'Status|Event'
autorep -W -s ALL | grep jobname
Fix now
Resend with -S instance if multi-instance; verify job name spelling
FORCE_STARTJOB looks ignored+
Immediate action
Check if job is ON_HOLD or ON_ICE — that prevents any event except JOB_OFF_HOLD/OFF_ICE
Commands
autorep -q jobname | grep -i 'hold\|ice'
sendevent -E JOB_OFF_HOLD -J jobname
Fix now
Release from hold/ice first, then FORCE_STARTJOB
Downstream job not running after CHANGE_STATUS SUCCESS+
Immediate action
Check if downstream job has additional time or alarm conditions
Commands
autorep -j downstream_job | grep -E 'Condition|Start_times|date_conditions'
sendevent -E STARTJOB -J downstream_job
Fix now
If conditions are met, STARTJOB triggers immediate execution
sendevent hangs with no output+
Immediate action
Check network connectivity and Event Processor status
Commands
ping event_processor_host # or check $AUTOUSER/.autosys
ps -ef | grep autoevent*
Fix now
Restart Event Processor only if necessary: sendevent -E STOP_DEMON then autostart via script
sendevent Event Types Comparison
EventWhat it doesRespects conditions?
STARTJOBTriggers job if conditions metYes
FORCE_STARTJOBStarts job immediately, bypasses conditionsNo
KILLJOBTerminates running jobN/A
JOB_ON_HOLDSuspends job (reversible)N/A
JOB_OFF_HOLDReleases job from holdYes — runs if conditions met
JOB_ON_ICEStrongly suspends jobN/A
JOB_OFF_ICEReleases from ice (waits for next cycle)Yes — waits for next occurrence
CHANGE_STATUSManually sets job statusN/A
SET_GLOBALSets a global variable valueN/A
STOP_DEMONGracefully stops Event ProcessorN/A

Key takeaways

1
sendevent is the primary command for manually controlling AutoSys job execution and state
2
FORCE_STARTJOB bypasses all conditions; STARTJOB respects them
use FORCE_STARTJOB carefully in production
3
CHANGE_STATUS -s SUCCESS is a recovery tool to unblock dependency chains when a job was fixed manually
4
Always use sendevent -E STOP_DEMON to stop the Event Processor
never kill -9
5
When debugging, start with autorep -W, then -q, then check the event log
6
Add a sleep between bulk sendevent calls to avoid overwhelming the Event Processor
7
JOB_ON_ICE is persistent; JOB_ON_HOLD is reversible. Understand the difference before suspending jobs

Common mistakes to avoid

6 patterns
×

Using STARTJOB when you meant FORCE_STARTJOB

Symptom
Job doesn't start — no error message, user assumes it worked
Fix
Check job conditions with autorep -q. If conditions are not met, use FORCE_STARTJOB or resolve the missing condition first.
×

Using FORCE_STARTJOB without understanding what conditions it's bypassing

Symptom
Job runs immediately but later the downstream discovers missing data or out-of-order processing
Fix
Only use FORCE_STARTJOB after verifying all prerequisite jobs have completed or are irrelevant. Document exceptions in the runbook.
×

Forgetting -S instance_name in multi-instance environments

Symptom
Event appears to be ignored — actually sent to the wrong AutoSys instance
Fix
Always specify -S when more than one instance exists. Set $AUTOSYS environment variable to your default instance.
×

Using KILLJOB on a job that's in a BOX and expecting the box to continue normally

Symptom
Box job goes to FAILURE or broken status even though other box members ran successfully
Fix
When a box member is killed, the box status may change. Use autorep -b boxname to check. Consider using a box exit condition that ignores member failures.
×

Sending multiple events rapidly in a loop without a pause

Symptom
Some events are processed out of order or skipped due to Event Processor overload
Fix
Add sleep 1-2 seconds between sendevent calls in scripts. For critical sequences, verify each event's effect before sending the next.
×

Assuming JOB_ON_ICE is same as JOB_ON_HOLD

Symptom
Job never runs after JOB_OFF_ICE because it doesn't start until its next scheduled time
Fix
Remember: JOB_ON_ICE is persistent—even after release, the job won't rerun until its next cycle. Use JOB_ON_HOLD if you want to simply suspend and resume.
INTERVIEW PREP · PRACTICE MODE

Interview Questions on This Topic

Q01JUNIOR
What is the sendevent command used for in AutoSys?
Q02JUNIOR
What is the difference between STARTJOB and FORCE_STARTJOB?
Q03SENIOR
How do you put an AutoSys job on hold using the command line?
Q04SENIOR
What does CHANGE_STATUS do and when would you use it?
Q05SENIOR
How do you gracefully stop the AutoSys Event Processor?
Q06SENIOR
Explain how you would debug a sendevent command that appears to do nothi...
Q01 of 06JUNIOR

What is the sendevent command used for in AutoSys?

ANSWER
sendevent is the command-line tool for sending signals to the AutoSys Event Processor. It's used to manually control jobs — starting, stopping, holding, icing, killing, or changing their status — as well as setting global variables and controlling the Event Processor itself (e.g., STOP_DEMON).
FAQ · 7 QUESTIONS

Frequently Asked Questions

01
What is the sendevent command in AutoSys?
02
What is the difference between STARTJOB and FORCE_STARTJOB?
03
How do I manually start an AutoSys job from the command line?
04
When would you use CHANGE_STATUS in AutoSys?
05
How do I stop the AutoSys Event Processor?
06
What is the difference between JOB_ON_HOLD and JOB_ON_ICE?
07
Can sendevent be used to restart a job that is currently running?
COMPLETE GUIDE
The Complete AutoSys Workload Automation Guide for Engineers →

JIL syntax, sendevent, autorep, box jobs, file watchers, scheduling, HA, security, cloud workload automation, and 22 interview questions — the definitive AutoSys reference for production engineers.

🔥

That's AutoSys. Mark it forged?

3 min read · try the examples if you haven't

Previous
AutoSys Job Status Codes Explained
19 / 30 · AutoSys
Next
AutoSys autorep Command