Global variable: sendevent -E SET_GLOBAL -G "RUN_DATE=2026-11-05", then command: /apps/bin/load.sh $$RUN_DATE
Job environment: profile: /apps/fin/env/load.env (a file of variables sourced before the job runs).
One run only: override_job with a different command, which reverts after the next run.
Upstream job decides the value: have it run sendevent SET_GLOBAL before the downstream job starts.
Watch out: globals are shared by every job that reads them; stale values cause wrong runs.
✦ Definition~90s read
What is AutoSys?
AutoSys jobs don't take arguments at run time the way a script does, but you can make their input dynamic with global variables ($$NAME in the command), a profile file of environment variables, or a one-off override_job.
★
An AutoSys job is a saved instruction card, so you can't whisper an extra word to it as it starts.
Plain-English First
An AutoSys job is a saved instruction card, so you can't whisper an extra word to it as it starts. Instead you leave a note on a shared noticeboard (a global variable) that the card reads when it runs, or you swap the card for one run only (override_job).
A common question from people moving to AutoSys from cron or scripts: how do I pass a parameter to a job, like a business date or a file name, that changes each run? AutoSys doesn't accept arguments at FORCE_STARTJOB time, but it has three clean ways to do it. This guide shows each with JIL and commands, and the stale-value trap that catches most teams.
Option 1: Global Variables ($$NAME)
A global variable is a name/value pair stored by AutoSys. Set it with sendevent, and reference it in a job's command with a $$ prefix: AutoSys substitutes the current value when the job starts.
set_global.shBASH
1
2
3
4
5
6
7
8
# Set (or change) the value
sendevent -E SET_GLOBAL -G "BUSINESS_DATE=2026-11-05"
# Check the current value
autorep -G BUSINESS_DATE
# Remove it
sendevent -E SET_GLOBAL -G "BUSINESS_DATE=DELETE"
🔥In JIL
command: /apps/fin/bin/load.sh $$BUSINESS_DATE passes the value as an argument to the script.
🎯 Key Takeaway
SET_GLOBAL plus $$NAME in the command is the standard way.
Let an Upstream Job Set the Value
Often the value is calculated, like the business date or the latest file name. Have an upstream job compute it and call sendevent SET_GLOBAL, then make the consumer depend on that job's success so it never runs with a stale value.
Every job that reads $$BUSINESS_DATE sees the same value. Use distinct names per application to avoid collisions.
🎯 Key Takeaway
Make the consumer depend on the job that sets the global.
Option 2: A Profile File of Environment Variables
For values that belong to one job or application, point the job's profile attribute at a file that sets environment variables. AutoSys sources it before running the command, so the script reads them like any environment variable, and you change the value by editing the file, without touching the job. Newer AutoSys versions also offer an envvars attribute for setting variables directly in JIL; check the JIL reference for your version before relying on it.
A profile file suits per-job settings that change occasionally.
Option 3: One Run Only with override_job
To run a job once with a different command or argument, use override_job. It applies to the next run only, then the job goes back to its normal definition. Combine with FORCE_STARTJOB for an immediate rerun.
Keep override JIL files in your change ticket, so there's a record of what ran with which parameter.
🎯 Key Takeaway
override_job is the safe one-off; it reverts automatically.
● Production incidentPOST-MORTEMseverity: high
Yesterday's Date, Loaded Again
Symptom
The nightly load completed SUCCESS but reloaded the previous day's data.
Assumption
The team assumed the global variable was always fresh because it was set every night.
Root cause
The upstream job that ran SET_GLOBAL had been put ON_ICE for maintenance. The downstream job's condition didn't depend on it, so the load ran with the stale $$BUSINESS_DATE.
Fix
Made the load depend on success of the job that sets the global, and added a check in the script that the date is today's business date.
Key lesson
A global keeps its last value until something changes it.
Make consumers depend on the job that sets the variable.
Validate dynamic inputs inside the script too.
Production debug guideCheck what value the job actually received4 entries
Symptom · 01
Job ran with an old value
→
Fix
Check the global's current value with autorep -G NAME, and whether the job that sets it actually ran.
Symptom · 02
$$NAME appears literally in the log
→
Fix
The global doesn't exist; create it with sendevent -E SET_GLOBAL -G "NAME=value".
Symptom · 03
override_job had no effect
→
Fix
It applies to the next run only; if the job already ran, it's been consumed.
Symptom · 04
Variable from the profile not visible to the script
→
Fix
Check the job's profile path with autorep -J job -q, that the file exports the variable, and that the job's owner can read it.
AutoSys jobs don't take run-time arguments directly.
2
Use SET_GLOBAL plus $$NAME for shared dynamic values.
3
Use a profile file for per-job settings, override_job for one-off runs.
4
Make consumers depend on the job that sets the value.
5
Prefix global names per application.
Common mistakes to avoid
3 patterns
×
Expecting FORCE_STARTJOB to accept arguments
Symptom
No way to pass a value when force-starting.
Fix
Set a global first, or use override_job before the force start.
×
Consumers not depending on the job that sets the global
Symptom
Jobs run with yesterday's value after a skipped run.
Fix
Add condition: s(SETTER_JOB) and validate the value in the script.
×
Using generic global names
Symptom
Two applications overwrite each other's DATE variable.
Fix
Prefix names by application, such as FIN_BUSINESS_DATE.
INTERVIEW PREP · PRACTICE MODE
Interview Questions on This Topic
Q01SENIOR
How do you pass a parameter to an AutoSys job?
Q02SENIOR
What's the risk with global variables?
Q01 of 02SENIOR
How do you pass a parameter to an AutoSys job?
ANSWER
Set a global variable with sendevent -E SET_GLOBAL and reference it as $$NAME in the job's command; or source variables from a profile file; or override_job for a single run.
Q02 of 02SENIOR
What's the risk with global variables?
ANSWER
They keep their last value until changed and are shared by every job that reads them, so a skipped setter job can make consumers run with stale values. Make consumers depend on the setter.
01
How do you pass a parameter to an AutoSys job?
SENIOR
02
What's the risk with global variables?
SENIOR
FAQ · 2 QUESTIONS
Frequently Asked Questions
01
Can we pass a dynamic parameter to an AutoSys job?
Yes, indirectly: set a global variable with sendevent SET_GLOBAL and use $$NAME in the command, source variables from a profile file, or use override_job for the next run.
Was this helpful?
02
How do I see a global variable's value in AutoSys?