AutoSys Global Variables — Stale Flags That Skip Batch Runs

AutoSys global variables live in the Event Server. Any job can read them. Any job can write them. They persist until explicitly changed.

That last sentence is where teams get burned.

A flag set to 'COMPLETE' on Monday is still 'COMPLETE' on Tuesday. A counter that reached 5000 yesterday is still 5000 today unless you reset it. This article covers the patterns that work — and the one stale-value trap that breaks workflows silently.

How AutoSys Global Variables Become Stale Flags That Skip Batch Runs

AutoSys Global Variables are key-value pairs stored in the AutoSys database that are evaluated at job start time and remain fixed for the duration of that run. They are not dynamic environment variables — once a job begins, the global variable value is frozen, even if the underlying source (e.g., a file, a database query) changes mid-execution. This is the core mechanic: a snapshot, not a live reference.

In practice, global variables are often set by a preceding job (e.g., via sendevent -E SET_GLOBAL) and consumed by downstream jobs. The critical property: the value is resolved only when the job transitions to RUNNING. If a job is queued (ACTIVE) for minutes or hours, the global variable it sees may be stale by the time it actually runs. This is not a bug — it is by design. The variable is a static flag, not a real-time signal.

Use global variables to pass simple state between jobs in a box (e.g., 'FILE_READY=YES') or to parameterize job definitions without editing JIL. They matter in real systems because they are the only built-in mechanism for cross-job coordination without external state stores. But relying on them for time-sensitive decisions (e.g., 'is the upstream table loaded?') is dangerous — the staleness window can cause skipped runs or duplicate processing.

Setting a global variable from a job

Jobs set global variables using the sendevent command with the SET_GLOBAL event. This can be done from within the job's script or from the command line.

The syntax is: sendevent -E SET_GLOBAL -G "VARNAME=value". No spaces around the equals sign.

Critical: SET_GLOBAL events are processed asynchronously. There's a small delay (typically <1 second) between the command and the value being readable by other jobs. If your downstream job starts immediately after setting a variable, it might not see the value yet. Use condition dependencies to enforce order if timing matters.

#!/bin/bash
# Script that processes records and sets the count as a global variable

RECORD_COUNT=$(wc -l < /data/processed_trades.csv)

# Set the global variable in AutoSys
sendevent -E SET_GLOBAL -G "TRADE_COUNT=${RECORD_COUNT}"

# For workflows with date-stamped globals (recommended for daily runs)
DATE=$(date +%Y%m%d)
sendevent -E SET_GLOBAL -G "TRADE_COUNT_${DATE}=${RECORD_COUNT}"

echo "Processed ${RECORD_COUNT} trades, set TRADE_COUNT global variable"
exit 0

Reading a global variable in a JIL condition

You can reference global variables in JIL conditions using the variable() function. This lets you create data-driven conditions.

Syntax: condition: success(job_a) AND variable(TRADE_COUNT) >= 1000 The comparison operators work: =, !=, <, >, <=, >=. String comparison works too: variable(STATUS) = 'COMPLETE'

Critical: variable() returns an empty string if the global doesn't exist. In numerical comparisons, empty string compares as 0. That can cause false positives — a missing variable might silently pass a >=1 check.

/* Read a global variable in a condition */
insert_job: validate_trade_count
job_type: CMD
command: "/scripts/validate_count.sh ${TRADE_COUNT}"
machine: server01
owner: batch
condition: success(process_trades) AND variable(TRADE_COUNT) >= 1

/* String comparison with global */
insert_job: check_status
job_type: CMD
condition: variable(WORKFLOW_STATUS) = 'READY'

/* Dangerous: missing global passes >= 0 check */
/* If TRADE_COUNT never set, this condition is TRUE */
condition: variable(TRADE_COUNT) >= 0

/* Safer: check existence and value */
condition: variable(TRADE_COUNT) != '' AND variable(TRADE_COUNT) >= 100

/* Set a global variable via sendevent from command line */
# sendevent -E SET_GLOBAL -G "PROCESS_DATE=20260319"

/* Check current value of a global variable */
# autostatus -G TRADE_COUNT

Global variable naming, lifecycle, and best practices

Global variables persist in the Event Server until explicitly changed or cleared. They do not reset between daily runs — a value set yesterday is still there today unless something overwrites it. This is both powerful and dangerous.

Lifecycle: Created on first SET_GLOBAL. Persists indefinitely. Cleared by SET_GLOBAL with empty value (or by database cleanup). Survives Event Processor restarts, failovers, and system reboots.

Best practices that separate senior engineers from beginners: 1. Always use a naming convention with a workflow prefix (e.g., TRADING_RECORD_COUNT not just COUNT) 2. Reset flags and counters at the start of each workflow run, not the end 3. For per-run state, include the date in the variable name (e.g., TRADING_COUNT_20260319) 4. Document every global variable your workflow uses — undocumented globals become tribal knowledge 5. Audit global variables monthly with autostatus -G % to catch stale or orphaned ones 6. Never assume a global exists. Check before reading.

# PATTERN: Reset globals at the START of a workflow (not end)
# Add this as the first job in your box:

insert_job: PRD_TRADING_RESET_GLOBALS
job_type: CMD
box_name: PRD_TRADING_EOD_BOX
command: /scripts/reset_trading_globals.sh
machine: server01
owner: batch
# No condition — first job in box

# reset_trading_globals.sh contents:
# sendevent -E SET_GLOBAL -G "TRADING_RECORD_COUNT=0"
# sendevent -E SET_GLOBAL -G "TRADING_STATUS_FLAG="
# sendevent -E SET_GLOBAL -G "TRADING_PROCESS_DATE=$(date +%Y%m%d)"

# PATTERN: Date-stamped globals for per-run state
DATE=$(date +%Y%m%d)
sendevent -E SET_GLOBAL -G "TRADING_COUNT_${DATE}=5432"
# Downstream job reads: variable(TRADING_COUNT_20260319)

# List all current global variables
autostatus -G %

# Clear a stale global
sendevent -E SET_GLOBAL -G "STALE_FLAG="

Why Autosys Global Variables Are the Worst Debugging Tool You’re Relying On

You’ve been there: a job fails, you check the logs, and the global variable is empty. Not because it wasn’t set—but because it was set in the wrong scope, or overwritten by a parallel job, or expired before the condition evaluated. Global variables are shared mutable state. Treat them like an unlocked production database. Every job can read and write them. That means a misconfigured nightly data load can silently clobber the flag your critical ETL job depends on. The why is simple: Autosys stores global variables in a flat namespace. No isolation. No versioning. No audit trail. So when you set a variable at 2 AM in one job, and another job reads it at 2:01 AM, you have zero guarantee it’s the same value. The how: always log the variable state at both write and read points. Use a dedicated job to echo the variable into a shared file or monitoring platform before the dependent job runs. That way, when the incident postmortem lands on your desk, you’re not guessing what the value was.

// io.thecodeforge — devops tutorial

// Log the variable before it’s consumed
insert_job: nightly_extract_logvar
job_type: c
command: 'echo "DEBUG: CURR_CYCLE_DATE=$CURR_CYCLE_DATE" >> /var/log/autosys/gv_snapshot.log'
machine: prod_data_worker
owner: svc_etl

// Downstream job that reads it
insert_job: nightly_extract_main
job_type: c
condition: s(nightly_extract_logvar) AND $CURR_CYCLE_DATE != ""
command: '/app/scripts/run_extract.sh'
machine: prod_data_worker
owner: svc_etl

Global Variables as Cross-Domain Handshakes: When They Work and When They Don’t

You can pass global variables between Autosys instances—if your company runs separate domains for dev, staging, and prod. The handshake looks clean on paper: set a variable in Domain A, read it in Domain B via a remote job condition. In practice, this is where global variables become latency grenades. The variable doesn’t replicate instantly. There’s no ACK. No retry. If the remote domain’s event processor is down for 30 seconds, your job condition sees stale data—or nothing. The why is architectural: Autosys domains share variables through a point-to-point daemon protocol. It’s not event-driven. It’s a poll-based sync with a configurable interval (default 60 seconds). That means a job in Domain B might check a variable that hasn’t been updated in Domain A for two minutes. The how: never use a global variable as a real-time handshake between domains. Instead, use a file transfer with a heartbeat check. Write a marker file to a shared NFS mount. Have the remote job check for the file’s existence and age. If the file is older than 5 minutes, kill the job with a clear error. This gives you explicit timeout control, not a silent failure.

// io.thecodeforge — devops tutorial

// Domain A: Write heartbeat file
insert_job: prod_heartbeat_writer
job_type: c
command: 'date +%s > /shared/metrics/data_ready.timestamp'
machine: prod_orchestrator
owner: svc_autosys

// Domain B: Read with age check
insert_job: staging_data_consumer
job_type: c
condition: s(prod_heartbeat_writer)
command: |
  AGE=$(($(date +%s) - $(cat /shared/metrics/data_ready.timestamp)));
  if [ $AGE -gt 300 ]; then
    echo "ERROR: stale heartbeat >5min" && exit 1;
  fi;
  /app/scripts/consume_data.sh
machine: staging_worker
owner: svc_autosys_staging

Build.Clean: Forcing Autosys to Rebuild Without Manual Override

When a batch pipeline misreads stale global variables, Build.Clean is the failsafe that forces Autosys to discard cached job states and re-execute from scratch. The WHY: Global variables persist across runs and silently block downstream jobs using s(condition). Build.Clean resets the variable to an undefined or zero state before the first job runs, ensuring that conditional logic evaluates fresh input rather than yesterday’s artifact. In practice, you insert a preprocessing job that sets BUILD_CLEAN=1 as an Autosys global, then each downstream job checks that flag early in its JIL condition. Without this, a stale BUILD_CLEAN=0 can cause the entire pipeline to skip rebuilds indefinitely—a silent outage that only surfaces when production data is days old. The HOW: assign the variable in a JIL insert_job block with global_variable parameter, then reference it in downstream conditions as g(BUILD_CLEAN). Never reuse this variable across domains; it must be scoped per pipeline to avoid cross-contamination.

// io.thecodeforge — devops tutorial
// 25 lines max
insert_job: FORCE_BUILD_CLEAN
job_type: C
command: /bin/echo 1
condition: s(TRIGGER_JOB)
global_variable: BUILD_CLEAN=1

---
insert_job: PROCESS_DATA
job_type: C
command: /apps/run_etl.sh
condition: g(BUILD_CLEAN) eq "1"
global_variable: BUILD_CLEAN=0

System.AccessToken and System.Debug: Securing and Tracing Global Variable Operations

Autosys doesn’t natively support secret rotation or debug logging for global variables, so you must inject System.AccessToken and System.Debug as engineering conventions. The WHY: global variables store API keys and run IDs in plaintext across job outputs—no encryption, no audit trail. System.AccessToken is a rotating token stored as a global variable but retrieved at runtime from a secure vault (e.g., CyberArk) via a wrapper script. System.Debug toggles verbose logging for variable reads and writes, solving the black-box debugging problem where you can’t tell which job set what value last. The HOW: In the JIL, define a job that fetches the token from vault and writes it to SYSTEM_ACCESS_TOKEN using set_global -n SYSTEM_ACCESS_TOKEN -v ${VAULT_CRED}. Enable debug by having a control job set SYSTEM_DEBUG=1, then condition job scripts to log every $VAR expansion. Without these, a leaked token or an invisible variable change becomes a security incident or a three-day root cause hunt.

// io.thecodeforge — devops tutorial
// 25 lines max
insert_job: GET_ACCESS_TOKEN
job_type: C
command: /opt/scripts/fetch_token.sh
send_notification: 1
global_variable: SYSTEM_ACCESS_TOKEN=

insert_job: ENABLE_DEBUG
job_type: C
command: /opt/scripts/set_debug.sh
condition: s(GET_ACCESS_TOKEN)
global_variable: SYSTEM_DEBUG=1