Junior 3 min · March 19, 2026

AutoSys autorep — Filtering 10K Jobs With -s FA

Q: 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.

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: 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.

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.

Q: 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`.

3 failed x_ prefixed jobs hid mid-scroll in 10,000 lines of alphabetical autorep output.

Naren · Founder

Plain-English first. Then code. Then the interview question.

About

● Production Incident 🔎 Debug Guide

⚡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

Plain-English First

autorep is like the 'check status' button on a delivery tracking website. You tell it which jobs you want to track (by name or pattern), and it tells you what's happening — whether they're running, succeeded, failed, or waiting.

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.shBASH

# 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.

thecodeforge.io

autorep Flag Reference

Autosys Autorep Command

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.shBASH

# 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.shBASH

# 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.

● Production incidentPOST-MORTEMseverity: high

The 10,000-Line autorep That Hid the Crash

Symptom

The 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.

Assumption

The 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 cause

autorep -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.

Fix

1. 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 guideSymptom → Action mapping for common autorep failures in production AutoSys environments.5 entries

Symptom · 01

autorep -J % returns 'No jobs match' but jobs exist

→

Fix

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.

Symptom · 02

autorep output takes 30+ seconds to display — very slow

→

Fix

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.

Symptom · 03

autorep -s FA shows no failures, but business says jobs failed

→

Fix

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.

Symptom · 04

autorep -q output is truncated — missing attributes

→

Fix

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.

Symptom · 05

autorep -M shows agent as MISSING but job still running

→

Fix

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 Debug Cheat SheetFast diagnostics for autorep issues in production AutoSys environments.

Flood of output — can't find failures−

Immediate action

Filter by failed status

Commands

autorep -J % -s FA

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

Fix now

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

autorep slow — 30 seconds or more+

autorep -s FA shows no failures but business complains+

autorep -q output truncated after 2000 lines+

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

autorep Flags Quick Reference

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

5 patterns

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 PREP · PRACTICE MODE

Interview Questions on This Topic

Q01JUNIOR

What is the autorep command used for in AutoSys?

Q02JUNIOR

What does the -q flag do in autorep?

Q03JUNIOR

How do you list all jobs currently in FAILURE status?

Q04SENIOR

How do you see the previous run's details for an AutoSys job?

Q05JUNIOR

What wildcard does autorep use for matching job names?

Q01 of 05JUNIOR

What is the autorep command used for in AutoSys?

ANSWER

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.

FAQ · 6 QUESTIONS

Frequently Asked Questions

What is autorep in AutoSys?

How do I see all AutoSys jobs in FAILURE status?

What does autorep -J jobname -q do?

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

What is the wildcard character in autorep?

Why is autorep -J % slow in large environments?

COMPLETE GUIDE

The Complete AutoSys Workload Automation Guide for Engineers →

JIL syntax, sendevent, autorep, box jobs, file watchers, scheduling, HA, security, cloud workload automation, and 22 interview questions — the definitive AutoSys reference for production engineers.

🔥

That's AutoSys. Mark it forged?

3 min read · try the examples if you haven't