AutoSys Installation — AUTOSERV Environment Traps

Your infrastructure team handles the AutoSys install. You just use it. That's the theory.

Reality: you'll SSH into the AutoSys server at 2 AM to debug why a job isn't running. And if you don't know where the logs live or which AUTOSERV you're in, you'll waste 30 minutes figuring out the basics.

This guide assumes the install is done. We focus on the 5 checks that verify it's working — and the environment variables you'll type every single day.

Prerequisites before installation

Before AutoSys can be installed, you need:

On the AutoSys server: - A supported OS (RHEL/CentOS Linux, or Windows Server) - A supported database (historically Sybase ASE, now Oracle or other RDBMS) - Java runtime (AutoSys WCC runs on Tomcat) - Sufficient RAM — at least 8GB for a small installation, 16GB+ for production - A dedicated service account (commonly named autosys or appuser)

On each agent machine: - A supported OS (Linux, Windows, AIX, Solaris) - The AutoSys Agent package (lightweight, minimal footprint) - Network connectivity to the AutoSys server on the configured port

Port planning matters. The Event Processor communicates with agents over specific ports (default 7520). Make sure firewalls are open between the AutoSys server and every agent machine.

The silent killer: Using a shared account for multiple environments. If the same OS account connects to DEV and PRD, you will eventually run a command against the wrong instance.

# Check Java version (required for WCC)
java -version

# Check available memory
free -h

# Check disk space on AutoSys installation paths
df -h /opt/CA /opt/autosys /u01

# Verify network connectivity to agent machines
autoping -m agent-machine-01

# Check AutoSys port is open between server and agent
nc -zv agent-machine-01 7520

# Verify separate service accounts (critical)
whoami
# Should be autosys_dev, autosys_qat, or autosys_prd — never 'autosys' shared

Key environment variables you'll use every day

AutoSys uses several environment variables that control which instance you're talking to and where log files live. These are set in your shell profile (.bash_profile or .profile) for the AutoSys service account.

Knowing these by heart makes you much faster at debugging. When something goes wrong at 3 AM and you're SSH'd into the AutoSys server, these are the first things you check.

Most critical: AUTOSERV. It tells AutoSys which instance to connect to. Set it wrong, and you'll submit jobs to the wrong environment. No warning. No error. Just silent wrongness.

The 3 AM trick: If a job isn't behaving, echo $AUTOSERV and autoflags -a. If they don't match your expectation, fix the environment before touching anything else.

# The AutoSys instance name — critical, everything uses this
export AUTOSERV=ACE

# AutoSys installation directory
export AUTOSYS=/opt/CA/WorkloadAutomationAE

# AutoSys user/data directory (logs, config files, PID files)
export AUTOUSER=/opt/CA/WorkloadAutomationAE/autouser

# Path to AutoSys binaries (needed for jil, autorep, sendevent etc.)
export PATH=$AUTOSYS/bin:$PATH

# The "3 AM sanity check": put AUTOSERV in your prompt
export PS1='[\u@\h:$AUTOSERV \W]\$ '

# Add the above to your .bash_profile for the autosys service account:
# source this file or add these lines to ~/.bash_profile

# Verify the environment is set correctly:
echo "Instance: $AUTOSERV"
echo "Install dir: $AUTOSYS"
echo "User dir: $AUTOUSER"
autoflags -a

Verifying a fresh installation

After installation, run through this checklist before declaring the system ready:

1. Event Processor is running — chk_auto_up -A
2. Can connect to Event Server — autoflags -a
3. Agents are registered and active — autorep -M %
4. Can define a test job — create a simple JIL job
5. WCC web interface is reachable — open the browser URL
6. Test job runs successfully end-to-end

Test job best practice: Use a job that does something harmless but observable. Write to a test log file. Run it manually first on the agent machine to verify the command works. Then let AutoSys run it.

The rookie mistake: Assuming the test job works because the JIL insert succeeded. A successful insert only means the syntax was correct. It doesn't mean the command will run successfully on the agent.

# 1. Check Event Processor
chk_auto_up -A

# 2. Check overall system
autoflags -a

# 3. List all registered machines
autorep -M %

# 4. Insert and immediately force-run a test job
jil << 'JIL'
insert_job: INSTALL_TEST
job_type: CMD
command: echo 'AutoSys installation verified successfully' >> /tmp/autosys_test.log
machine: autosys-server
owner: autosys
date_conditions: 0
JIL

# Force start it
sendevent -E FORCE_STARTJOB -J INSTALL_TEST

# Wait a few seconds, then check its status
autorep -J INSTALL_TEST

# Check the test log
cat /tmp/autosys_test.log

# Verify the test job runs on the correct machine
# The machine attribute must match the agent hostname

# Clean up
echo 'delete_job: INSTALL_TEST' | jil