DevOps Intermediate

AutoSys autorep: The 1 Command That Finds Production Failures

Q: How do I see all AutoSys jobs in FAILURE status?

Use `autorep -J % -s FA`. The -s flag filters by status code (FA = FAILURE, RU = RUNNING, SU = SUCCESS, PE = PEND_MACH, OH = ON_HOLD).

Q: How do I check what an AutoSys job looked like in its previous run?

Use `autorep -J jobname -run 1` to see the previous run, `autorep -J jobname -run 2` for the run before that, and so on. Combine with `-d` for detailed view including exit code and runtime.

Q: What is the wildcard character in autorep?

The percent sign `%` is the wildcard in AutoSys commands. `autorep -J %` returns all jobs. `autorep -J eod_%` returns all jobs starting with 'eod_'. This is consistent across AutoSys commands.

📅 March 19, 2026 ⏱ 3 min read 🎯 Intermediate

Where developers are forged. · Structured learning · Free forever.

📍 Part of: AutoSys → Topic 20 of 30

AutoSys autorep command explained with real outage stories.

⚙️ Intermediate — basic DevOps knowledge assumed

In this tutorial, you'll learn

AutoSys autorep command explained with real outage stories.

autorep is the primary status and reporting command — use it for checking job status, viewing definitions, and generating reports.
% is the wildcard for job name matching; use it freely but always filter by status in large environments.
-q outputs JIL format — use it to back up job definitions before making changes.

thecodeforge.io

autorep Flag Reference

Autosys Autorep Command

✦ Plain-English analogy ✦ Real code with output ✦ Interview questions

⚡Quick Answer

autorep is AutoSys reporting command to check job status, view definitions, and generate reports — primary monitoring tool
Key flags: -J (job name with % wildcard), -s (status filter), -d (detailed view), -q (JIL output), -M (machine status)
Performance: autorep queries Event Server database; large environments (10K+ jobs) can take 5-10 seconds — use -s to filter before display
Production trap: autorep -J % without filter in large environment returns 10K lines, scrolls off terminal, operator misses failures
Biggest mistake: Not using -q to backup job definitions before bulk JIL changes — accidental delete loses all jobs with no recovery

🚨 START HERE

autorep Debug Cheat Sheet

Fast diagnostics for autorep issues in production AutoSys environments.

🟡

Flood of output — can't find failures

Immediate ActionFilter by failed status

Commands

autorep -J % -s FA

autorep -J % -s FA -d | grep -E 'Job Name|Exit Code'

Fix NowAlias `alias autofail='autorep -J % -s FA'` in .profile. Use cron script to send email when failures detected.

🟠

autorep slow — 30 seconds or more

Immediate ActionCheck Event Server table sizes and indexes

Commands

autorep -J % -s RU | head -5

echo 'SELECT COUNT(*) FROM AE_EVENTS WHERE EVENT_TIME < SYSDATE - 90;' | sqlplus autosys_user@autosys_db

Fix NowPurge old events: `db_purge_events -date "$(date -d '90 days ago' +%m/%d/%Y)"`. Run `analyze table AE_EVENTS compute statistics;`

🟡

autorep -s FA shows no failures but business complains

Immediate ActionCheck job history and exit codes

Commands

autorep -J suspect_job -run 1

autostatus -J suspect_job

Fix NowCheck job's stdout/stderr: `autorep -J suspect_job -d | grep 'Stdout'`. Exit code 0 doesn't guarantee success — business logic may have failed silently.

🟡

autorep -q output truncated after 2000 lines

Immediate ActionRedirect to file or use pagination

Commands

autorep -J % -q > /tmp/all_jobs.jil

autorep -J % -q | wc -l

Fix NowUse `-q` with output redirection, not terminal. To view, `less /tmp/all_jobs.jil`. For individual jobs, `autorep -J job_name -q` fits on screen.

🟡

autorep -M shows agent missing but job still running on machine

Immediate ActionCheck if agent is down but process still runs

Commands

ping agent_host && ssh agent_host 'ps -ef | grep autosys_agent'

ssh agent_host 'tail -100 /var/log/autosys/agent.log'

Fix NowRestart agent: `ssh agent_host '/etc/init.d/autosys_agent restart'`. Then `sendevent -E FORCE_STARTMACH -M agent_host` to re-enable jobs.

Production Incident

The 10,000-Line autorep That Hid the Crash

An operator ran `autorep -J %` to check overnight batch status. The terminal displayed 10,000 lines of output. The 3 failed jobs were buried in the middle. The operator missed them. The failures weren't discovered until the morning SLA was missed.

SymptomThe overnight batch had 3 failures out of 10,000 jobs. The operator ran autorep -J % and saw pages of output scroll past. By the time the command finished, the terminal buffer showed only the last 100 lines. The 3 failures were not in those last 100 lines. The operator reported 'all jobs succeeded'. Three hours later, the business team asked why the reports weren't ready.

AssumptionThe operator assumed that if any job failed, autorep would highlight it or show failures at the end. They didn't know autorep output is sorted by job name, not by status. They also didn't know about -s FA filter. The team had no automated alerting for job failures, relying entirely on manual autorep checks.

Root causeautorep -J % output is sorted alphabetically by job name. The 3 failed jobs had names starting with 'x_' (x_report, x_load, x_validate). They appeared in the middle of the output, not at the end. The terminal buffer only kept the last 100 lines after the command finished. The operator scrolled back manually but missed them because the output was massive. The team had no monitoring system that aggregated failures or sent alerts. The operator also didn't know about -s FA to filter only failures. The incident could have been prevented by filtering: autorep -J % -s FA shows only failed jobs.

Fix1. Changed operator runbook from autorep -J % to autorep -J % -s FA to show only failures. 2. For detailed view: autorep -J % -d -s FA to see failure details (exit code, runtime). 3. Added automated monitoring: a cron job runs autorep -J % -s FA | grep -v 'No jobs match' and sends email if output non-empty. 4. Integrated with PagerDuty: critical failures trigger page to on-call engineer. 5. Wrapped autorep in a script that formats output and highlights failures in red (using ANSI colours). 6. Added terminal less to output: autorep -J % | less to scroll through large output.

Key Lesson

autorep -J % output is massive in large environments. Always filter with -s FA for failures, -s RU for running.Don't rely on visual scanning of autorep output. Use automated monitoring: script that checks for failures and alerts immediately.The terminal scrollback buffer is not a reliable monitoring tool. What you don't see will break your SLA.Build aggregation scripts: autorep -J % -s FA | wc -l gives failure count. Alert if > 0.

Production Debug Guide

Symptom → Action mapping for common autorep failures in production AutoSys environments.

autorep -J % returns 'No jobs match' but jobs exist→Check JIL syntax: your environment may have box names with special characters. Use autorep -J % (all jobs) not autorep -J %? Actually if 'no jobs match', your AutoSys instance may not have any jobs, or you're in wrong database. Check Event Server connection: echo 'select * from UJOBS' | sqlplus autosys_user@autosys_db to see if jobs exist.

autorep output takes 30+ seconds to display — very slow→Event Server table may have grown large (AE_QUEUE, AE_EVENTS). Purge old events: db_purge_events -date 'MM/DD/YYYY'. Also check if Event Server indexes are missing. Run analyze table on Event Server tables.

autorep -s FA shows no failures, but business says jobs failed→Failed jobs may have been re-run manually and status changed to SUCCESS. Check history: autorep -J job_name -run 1 to see previous run status. Also check job logs directly: exit code may have been 0 even if business logic failed.

autorep -q output is truncated — missing attributes→Job definition may be longer than default output buffer. Redirect to file: autorep -J job_name -q > job.jil. Use -l (long format) if available in your version.

autorep -M shows agent as MISSING but job still running→Agent may be down but job already started before crash. The job will continue but cannot report completion. Check agent machine: ps -ef | grep autosys_agent. Restart agent, then check job status manually on the machine.

autorep (short for 'auto report') is the command you'll run dozens of times every day as an AutoSys operator. It's how you check job statuses, view job definitions, and generate reports. Mastering autorep patterns makes you dramatically faster at monitoring and troubleshooting.

But autorep can be dangerous. Run autorep -J % in an environment with 10,000 jobs and you'll flood your terminal with 10,000 lines of output. The failures you care about scroll past before you see them. Without -s FA (filter failures) and -d (detailed view), you'll miss critical information. And without -q backups, an accidental jil < delete_all.jil is catastrophic.

By the end you'll know every useful autorep flag, practical query patterns for finding failed jobs, how to back up job definitions, and how to avoid the terminal-clogging trap that hides failures.

Basic autorep usage

The most common use is checking the status of one or more jobs.

io/thecodeforge/autosys/autorep_basic.sh · BASH

1234567891011121314151617

# Check a single job
autorep -J daily_report

# Check all jobs (% is the wildcard in AutoSys)
autorep -J %

# Check all jobs matching a pattern
autorep -J eod_%        /* all jobs starting with eod_ */
autorep -J %_extract    /* all jobs ending with _extract */
autorep -J etl_*_load   /* wildcard in middle */

# Check all jobs inside a specific box
autorep -J eod_box%

# Check machine status
autorep -M %            /* all machines */
autorep -M prod-server-01

📊 Production Insight

In an environment with 10,000 jobs, autorep -J % produces 10,000 lines of output. The failures you need to see scroll past in milliseconds.

Always filter by status: -s FA (failures), -s RU (running), -s PE (PEND_MACH). This reduces output to only what matters.

Rule: Never run autorep -J % without filtering in production. Use autorep -J % -s FA as your default.

🎯 Key Takeaway

autorep is the primary status and reporting command — use it for checking job status, viewing definitions, and generating reports.

% is the wildcard for job name matching; use it freely but always filter by status in large environments.

Rule: For quick failure check: autorep -J % -s FA. For detailed failure info: autorep -J % -s FA -d.

The -q flag — getting JIL definitions

The -q flag outputs the job definition in JIL format. This is essential for backups, auditing, and creating job templates.

io/thecodeforge/autosys/autorep_q.sh · BASH

1234567891011

# Get JIL definition of one job
autorep -J daily_report -q

# Backup all jobs to a file
autorep -J % -q > /backup/all_jobs_$(date +%Y%m%d).jil

# Backup all jobs in a box
autorep -J eod_box% -q > /backup/eod_jobs_backup.jil

# Compare with previous backup (useful for change auditing)
diff /backup/eod_jobs_20260318.jil /backup/eod_jobs_20260319.jil

🔥Regular JIL backups are good practice

Automate autorep -J % -q > /backup/all_jobs_$(date +%Y%m%d).jil as a daily AutoSys job itself. When someone accidentally deletes or corrupts a job, yesterday's backup saves the day.

📊 Production Insight

An engineer once ran a JIL script that accidentally deleted 2,000 jobs. Without a backup, recovery would take days of manual work.

Daily autorep -J % -q backups cost nothing but save months of recovery time. Store backups in version control (Git).

Rule: Backup all jobs weekly and before any bulk JIL change. Use diff to audit changes: diff yesterday.jil today.jil shows exactly what changed.

🎯 Key Takeaway

-q outputs JIL format — use it to back up job definitions before making changes.

Regular backups (daily or weekly) protect against accidental deletions or corruptions.

Rule: Automate autorep -J % -q as a scheduled AutoSys job. Store in version control for audit trail.

The -d flag — detailed job information

The -d flag shows all attributes of a job including its current runtime and any active overrides — much more detail than the default status view.

io/thecodeforge/autosys/autorep_d.sh · BASH

1234567891011

# Detailed view of one job
autorep -J daily_report -d

# Check prior runs (-run flag)
autorep -J daily_report -run 1    /* previous run */
autorep -J daily_report -run 2    /* run before that */

# Filter by status
autorep -J % -s FA    /* all FAILURE jobs */
autorep -J % -s RU    /* all RUNNING jobs */
autorep -J % -s PE    /* all PEND_MACH jobs */

📊 Production Insight

The default autorep output shows only job name, last start, status, and exit code. This is not enough for debugging.

Use -d to see actual runtime (duration), command, stdout/stderr paths, and any override attributes.

Rule: When a job fails, first command: autorep -J $JOB -d. Then check stdout/stderr paths from output. Always include -d in your debugging workflow.

🎯 Key Takeaway

-d shows detailed attributes, runtime, command, and log file paths — essential for debugging failures.

-run N shows historical runs (1 = previous run, 2 = run before that).

Rule: alias alias autobug='autorep -J $1 -d -run 1' in .profile for quick debugging.

🗂 autorep Flags Quick Reference

Choose the right flag based on what information you need

Flag	What It Shows	Use Case	Example Command	Performance
(no flag)	Basic status: job name, last start, status, exit code	Quick health check	autorep -J daily_report	Fast (minimal data)
-d	Detailed attributes, runtime, command, log paths, overrides	Debugging failures, checking runtime, finding log files	autorep -J daily_report -d	Fast (one job)
-q	Full JIL definition (all attributes in JIL syntax)	Backups, auditing, creating templates, comparing changes	autorep -J % -q > backup.jil	Slow (10K jobs = 5-10 seconds)
-s STATUS	Filter by status code (FA, RU, SU, PE, OH, AC, IN, TE)	Finding failed jobs, monitoring running jobs, checking PEND_MACH	autorep -J % -s FA	Fast (filters at DB level)
-run N	Show N runs back in history (1 = previous run)	Debugging intermittent failures, checking historical runtime trends	autorep -J daily_report -run 1	Fast
-M	Machine/agent status instead of jobs	Checking agent availability, seeing which jobs run on a machine	autorep -M %	Fast
-J pattern	Filter job names by pattern (% = wildcard)	View subset of jobs by naming convention	autorep -J eod_%	Fast (if pattern selective)

🎯 Key Takeaways

autorep is the primary status and reporting command — use it for checking job status, viewing definitions, and generating reports.
% is the wildcard for job name matching; use it freely but always filter by status in large environments.
-q outputs JIL format — use it to back up job definitions before making changes.
-s filters by status code; -s FA for failures, -s RU for running, -s PE for PEND_MACH.
Never run autorep -J % -d without filtering — output is massive. Use -s and specific job patterns.

⚠ Common Mistakes to Avoid

✕Running autorep -J % without filtering in large environment

Symptom

Terminal flooded with thousands of lines of output. Failures scroll past before operator sees them. Operator misses critical failures, SLAs missed.

Fix

Always filter: autorep -J % -s FA for failures, -s RU for running. Create aliases: alias autofail='autorep -J % -s FA'. Use autorep -J % -s FA -d for detailed failure info.

✕Not using -q before bulk JIL changes — losing job definitions

Symptom

Engineer runs faulty JIL script that deletes or corrupts 1000 jobs. No backup. Recovery requires recreating all jobs from memory or old documentation. Days of work lost.

Fix

Always backup before changes: autorep -J % -q > backup_$(date +%Y%m%d_%H%M%S).jil. Automate daily full backup via AutoSys job. Store backups in version control (Git).

✕Using -d without filtering — too much output

Symptom

Engineer runs autorep -J % -d and gets 50,000 lines of output. Terminal freezes or takes minutes to complete. Worthless for real-time monitoring.

Fix

Filter before -d: autorep -J % -s FA -d for failures, or autorep -J eod_% -d for specific job family. Never run -d on all jobs.

✕Assuming autorep output is sorted by status — it's not

Symptom

Operator scans autorep output looking for FAILURE, but output is sorted alphabetically by job name. Failures appear in middle, not at end.

Fix

Use -s FA to show only failures. Sort output yourself: autorep -J % | sort -k5 (sorts by status column, but unreliable). Best: rely on status filter, not visual scanning.

✕Not checking prior runs with -run for intermittent failures

Symptom

Job fails occasionally but currently shows SUCCESS. Operator sees no failure and moves on. Underlying issue persists, causing silent data corruption.

Fix

When troubleshooting intermittent failures, check history: autorep -J job_name -run 1 (previous run), -run 2 (run before that). Look for patterns in exit code or runtime.

Interview Questions on This Topic

QWhat is the autorep command used for in AutoSys?JuniorReveal
autorep is the primary reporting command for AutoSys. It displays job status, job definitions, machine status, and historical runs. You use it to monitor whether jobs succeeded or failed, view job details (command, machine, owner), retrieve JIL definitions for backup, and check agent status (-M). It's the most frequently used command for AutoSys operators and administrators.
QWhat does the -q flag do in autorep?JuniorReveal
The -q flag outputs the job's definition in JIL (Job Information Language) format. It's used to back up job definitions before making changes, audit configuration changes, and generate job templates. For example: autorep -J daily_report -q returns the JIL definition of that job. autorep -J % -q > all_jobs.jil backs up all jobs to a file. This is critical for disaster recovery.
QHow do you list all jobs currently in FAILURE status?JuniorReveal
Use autorep -J % -s FA. The -s flag filters by status code, and FA is the code for FAILURE. Other useful status codes: RU (RUNNING), SU (SUCCESS), PE (PEND_MACH), OH (ON_HOLD), AC (ACTIVATED), IN (INACTIVE), TE (TERMINATED). For detailed view of failures: autorep -J % -s FA -d.
QHow do you see the previous run's details for an AutoSys job?Mid-levelReveal
Use autorep -J job_name -run 1 to see the previous run, -run 2 for the run before that. This is valuable for debugging intermittent failures — the job might be SUCCESS now but failed earlier. The output includes start time, end time, exit code, and runtime for that specific historical run. Combine with -d for full details: autorep -J job_name -run 1 -d.
QWhat wildcard does autorep use for matching job names?JuniorReveal
The percent sign % is the wildcard character in AutoSys commands. autorep -J % returns all jobs. autorep -J eod_% returns all jobs starting with 'eod_'. autorep -J %_extract returns all jobs ending with '_extract'. This pattern matching is consistent across AutoSys commands (jil, sendevent, autorep). Note that it's % not * like in Unix shells.

Frequently Asked Questions

What is autorep in AutoSys?

autorep is the AutoSys command-line tool for reporting on job status, viewing job definitions, and checking machine status. It's the primary monitoring tool for AutoSys administrators.

How do I see all AutoSys jobs in FAILURE status?

Use autorep -J % -s FA. The -s flag filters by status code (FA = FAILURE, RU = RUNNING, SU = SUCCESS, PE = PEND_MACH, OH = ON_HOLD).

What does autorep -J jobname -q do?

The -q flag outputs the job definition in JIL format — exactly as it would look if you were writing it in a JIL script. This is used to back up job definitions, create templates, and audit what attributes are currently set.

How do I check what an AutoSys job looked like in its previous run?

Use autorep -J jobname -run 1 to see the previous run, autorep -J jobname -run 2 for the run before that, and so on. Combine with -d for detailed view including exit code and runtime.

What is the wildcard character in autorep?

The percent sign % is the wildcard in AutoSys commands. autorep -J % returns all jobs. autorep -J eod_% returns all jobs starting with 'eod_'. This is consistent across AutoSys commands.

Why is autorep -J % slow in large environments?

autorep queries the Event Server database (AE_EVENTS, AE_JOBS tables). In environments with 10,000+ jobs and millions of event records, the query can take 5-10 seconds. Use -s FA to filter at the database level using indexes, which is much faster. Also regularly purge old events with db_purge_events.

🔥

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.

About Naren Get in touch

Forged with 🔥 at TheCodeForge.io — Where Developers Are Forged