Home DevOps AutoSys sendevent Command — Complete Reference

AutoSys sendevent Command — Complete Reference

Where developers are forged. · Structured learning · Free forever.
📍 Part of: AutoSys → Topic 19 of 30
The AutoSys sendevent command controls job events: start, kill, hold, ice, force start, and more.
⚙️ Intermediate — basic DevOps knowledge assumed
In this tutorial, you'll learn:
  • sendevent is the primary command for manually controlling AutoSys job execution and state
  • FORCE_STARTJOB bypasses all conditions; STARTJOB respects them — use FORCE_STARTJOB carefully in production
  • CHANGE_STATUS -s SUCCESS is a recovery tool to unblock dependency chains when a job was fixed manually
✦ Plain-English analogy ✦ Real code with output ✦ Interview questions
⚡ Quick Answer
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.

sendevent syntax and key options

The basic syntax is: sendevent -E event_type -J job_name

sendevent_syntax.sh · BASH
12345678910111213141516171819202122232425262728293031323334353637383940
# 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 STARTJOBSTARTJOB 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.

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.

change_status.sh · BASH
12345678
# 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 appropriateUse 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.

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.

sendevent_scripting.sh · BASH
12345678910111213141516171819202122232425
#!/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 callsWhen 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.
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

  • sendevent is the primary command for manually controlling AutoSys job execution and state
  • FORCE_STARTJOB bypasses all conditions; STARTJOB respects them — use FORCE_STARTJOB carefully in production
  • CHANGE_STATUS -s SUCCESS is a recovery tool to unblock dependency chains when a job was fixed manually
  • Always use sendevent -E STOP_DEMON to stop the Event Processor — never kill -9

⚠ Common Mistakes to Avoid

  • Using STARTJOB when you meant FORCE_STARTJOB — STARTJOB does nothing if conditions aren't met
  • Using FORCE_STARTJOB without understanding what conditions it's bypassing — can run jobs out of order
  • Forgetting -S instance_name when working in a multi-instance environment — sends the event to the wrong instance
  • Using KILLJOB on a job that's in a BOX without accounting for how that affects the box status

Interview Questions on This Topic

  • QWhat is the sendevent command used for in AutoSys?
  • QWhat is the difference between STARTJOB and FORCE_STARTJOB?
  • QHow do you put an AutoSys job on hold using the command line?
  • QWhat does CHANGE_STATUS do and when would you use it?
  • QHow do you gracefully stop the AutoSys Event Processor?

Frequently Asked Questions

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.

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.

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.

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.

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.

🔥
Naren Founder & Author

Developer and founder of TheCodeForge. I built this site because I was tired of tutorials that explain what to type without explaining why it works. Every article here is written to make concepts actually click.

← PreviousAutoSys Job Status Codes ExplainedNext →AutoSys autorep Command
Forged with 🔥 at TheCodeForge.io — Where Developers Are Forged