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 EventProcessor 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.
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
forJOB in $FAILED_JOBS; do
echo "Restarting: $JOB"
sendevent -E RESTART -J "$JOB"
sleep 2 # brief pause between events to avoid overwhelming EventProcessor
done
echo "Restart events sent for: $(echo $FAILED_JOBS | wc -w) jobs"
# Pattern2: 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 EventProcessor
sendevent -E STOP_DEMON
# START_DEMON - restart EventProcessor (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.
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
# Step1: Is the EventProcessor running?
autorep -W # returns NOSUCH? If yes, EventProcessor is down
# Step2: What is the job's current status?
autorep -q jobname | head -20
# Step3: Check event log for recent events
tail -100 $AUTOUSER/events/events.log | grep jobname
# Step4: Verify job name spelling and case
autorep -J "JOBNAME*" | grep -i jobname
# Step5: Test connectivity to EventProcessor host
ping autoevent_host
# Step6: Checkfor multiple instances
sendevent -E PING # sends a test event; responds with 'PONG' from EventProcessor
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.
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
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
Event
What it does
Respects conditions?
STARTJOB
Triggers job if conditions met
Yes
FORCE_STARTJOB
Starts job immediately, bypasses conditions
No
KILLJOB
Terminates running job
N/A
JOB_ON_HOLD
Suspends job (reversible)
N/A
JOB_OFF_HOLD
Releases job from hold
Yes — runs if conditions met
JOB_ON_ICE
Strongly suspends job
N/A
JOB_OFF_ICE
Releases from ice (waits for next cycle)
Yes — waits for next occurrence
CHANGE_STATUS
Manually sets job status
N/A
SET_GLOBAL
Sets a global variable value
N/A
STOP_DEMON
Gracefully stops Event Processor
N/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).
Q02 of 06JUNIOR
What is the difference between STARTJOB and FORCE_STARTJOB?
ANSWER
STARTJOB triggers a job only if its starting conditions (date_conditions, condition attribute, file watcher) are currently satisfied. FORCE_STARTJOB bypasses all conditions and starts the job immediately regardless. Use FORCE_STARTJOB sparingly in production because it can cause out-of-order execution.
Q03 of 06SENIOR
How do you put an AutoSys job on hold using the command line?
ANSWER
Use sendevent -E JOB_ON_HOLD -J job_name to put the job on hold. To release it: sendevent -E JOB_OFF_HOLD -J job_name. The difference from JOB_ON_ICE is that JOB_OFF_HOLD allows the job to run immediately if conditions are satisfied, while JOB_OFF_ICE only allows it to run at its next scheduled time.
Q04 of 06SENIOR
What does CHANGE_STATUS do and when would you use it?
ANSWER
CHANGE_STATUS manually changes a job's status to SUCCESS or FAILURE. Use it in recovery scenarios: when a job failed due to an infrastructure issue but the actual processing completed successfully, or when you need to block a dependency chain. Be aware that marking SUCCESS without verifying actual work can cause data corruption.
Q05 of 06SENIOR
How do you gracefully stop the AutoSys Event Processor?
ANSWER
Use sendevent -E STOP_DEMON. This sends a graceful shutdown signal, allowing the Event Processor to finish processing current events before exiting. Never use kill -9 — it can leave jobs in inconsistent states and corrupt the event queue.
Q06 of 06SENIOR
Explain how you would debug a sendevent command that appears to do nothing.
ANSWER
Start by verifying the Event Processor is running with autorep -W. Then check the job's current status with autorep -q jobname. Look at the event log at $AUTOUSER/events/events.log for error messages. Send a PING event to test connectivity. Also confirm the correct instance with -S. Common causes: job name typo, case mismatch, wrong instance, or the job is already in a state that prevents the event (e.g., ON_HOLD prevents STARTJOB).
01
What is the sendevent command used for in AutoSys?
JUNIOR
02
What is the difference between STARTJOB and FORCE_STARTJOB?
JUNIOR
03
How do you put an AutoSys job on hold using the command line?
SENIOR
04
What does CHANGE_STATUS do and when would you use it?
SENIOR
05
How do you gracefully stop the AutoSys Event Processor?
SENIOR
06
Explain how you would debug a sendevent command that appears to do nothing.
SENIOR
FAQ · 7 QUESTIONS
Frequently Asked Questions
01
What is the sendevent command in AutoSys?
sendevent is the AutoSys command-line tool for sending events to the Event Processor. It's used to manually start, stop, hold, ice, kill, or change the status of jobs, as well as set global variables and control the Event Processor itself.
Was this helpful?
02
What is the difference between STARTJOB and FORCE_STARTJOB?
STARTJOB triggers a job only if its starting conditions (date_conditions, condition attribute) are currently satisfied. FORCE_STARTJOB starts the job immediately regardless of whether conditions are met — it bypasses all condition checks.
Was this helpful?
03
How do I manually start an AutoSys job from the command line?
Use sendevent -E FORCE_STARTJOB -J jobname to start immediately regardless of conditions, or sendevent -E STARTJOB -J jobname to start only if conditions are met.
Was this helpful?
04
When would you use CHANGE_STATUS in AutoSys?
CHANGE_STATUS is a recovery tool. Use it to mark a job as SUCCESS when the actual processing completed correctly outside of AutoSys, or when an infrastructure failure caused the job to fail even though the work was done. This unblocks downstream jobs waiting on the dependency.
Was this helpful?
05
How do I stop the AutoSys Event Processor?
Use sendevent -E STOP_DEMON. This sends a graceful shutdown signal. Never use kill -9 — it can leave jobs in inconsistent states requiring manual cleanup before restart.
Was this helpful?
06
What is the difference between JOB_ON_HOLD and JOB_ON_ICE?
JOB_ON_HOLD suspends the job temporarily. When released with JOB_OFF_HOLD, the job will run immediately if its conditions are met. JOB_ON_ICE is stronger — even after JOB_OFF_ICE, the job will not run until its next scheduled occurrence (next cycle or explicit STARTJOB/FORCE_STARTJOB).
Was this helpful?
07
Can sendevent be used to restart a job that is currently running?
No. sendevent -E RESTART works only on jobs with status FAILURE. For a running job, you must first KILLJOB it, then use RESTART or STARTJOB.