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.

Why AutoSys AUTOSERV Setup Is a Trap for Unwary Teams

AutoSys installation setup is the process of configuring the AUTOSERV environment — the core daemon that manages job scheduling, event processing, and agent communication. The trap: AUTOSERV is not a single service but a layered stack of processes (event processor, file watcher, remote agent) that must share a consistent configuration across all nodes. A mismatch in any parameter — port, encryption key, event directory path — silently breaks job execution without clear error messages.

In practice, AUTOSERV uses a two-tier architecture: a primary event server (the 'event processor') that maintains the job schedule in memory, and remote agents that poll for work. The critical property is that the event processor's configuration file (autosys.rc) defines the event directory, which must be accessible via NFS or a shared filesystem. If the event directory is not mounted identically on all machines, jobs fail with 'Event not found' — a symptom that wastes hours of debugging. The default installation also sets a single encryption key for inter-process communication; changing it requires a coordinated restart of all AUTOSERV processes, or agents silently disconnect.

The AUTOSERV environment is essential when you need enterprise-grade job scheduling with dependencies, calendars, and cross-platform execution. It matters because a misconfigured AUTOSERV can cause cascading failures: a job that triggers 50 downstream jobs fails silently, and the event processor logs only a generic 'connection refused'. Teams that skip the shared filesystem validation or encryption key audit end up with a fragile system that breaks during failover or patching.

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

The Silent Failure: Autosys User Profiles and Login Script Pollution

You'll spend hours debugging why AUTOSERV won't start only to discover your .bashrc is dumping ANSI escape codes into STDOUT. AutoSys reads environment variables from the shell profile of the installation user. If that profile prints anything — a greeting, a path check, a colorized prompt — the autosys process chokes silently.

Teams that skip isolating the autoSys user account pay for it in downtime. Your autoSys user should have a .bash_profile that sources nothing but the bare minimum: PATH, LD_LIBRARY_PATH, and the AutoSys environment variables. No aliases. No functions. No "echo Welcome".

Before you run installer.pl, test your profile. SSH into the autoSys user, run env | grep -E 'AUTO|LD_LIBRARY|PATH'. If anything unexpected appears, you've got a leak. Fix it before proceeding.

Here's the pattern that survived three production rebuilds. Note the explicit unset of BASH_ENV and SHELLOPTS.

// io.thecodeforge — devops tutorial
// minimal .bash_profile for autosys user

# Clear harmful inherited vars
unset BASH_ENV
unset SHELLOPTS

# AutoSys essentials
export AUTOSYS=/opt/autosys/autosys11.0
export AUTOSYS_ETC=$AUTOSYS/etc
export PATH=$AUTOSYS/bin:$AUTOSYS/sbin:/usr/bin:/bin
export LD_LIBRARY_PATH=$AUTOSYS/lib

# No greetings. No prompts. No colors.

The Real Fight: Shared Libraries and the LD_LIBRARY_PATH Trap

Every second AutoSys installation fails because someone copied the LD_LIBRARY_PATH from the manual and expected it to work. It won't. AutoSys ships with specific library versions — typically OpenSSL 1.0.2, Berkeley DB 5.3, and a custom build of libxml2. If your system has newer versions, dynamic linking will load those instead of AutoSys's bundled libs.

The symptom: autosys_event_server starts, then core dumps after 30 seconds. No useful log. Or you'll see "undefined symbol: EVP_CIPHER_CTX_new" on EL8/9.

Don't set LD_LIBRARY_PATH globally. Don't add it to /etc/environment. Set it only in the autosys user's profile and use $AUTOSYS/lib as the first entry. If you have multiple AutoSys versions, you'll need a wrapper script that sets LD_LIBRARY_PATH before invoking each binary.

Test your library resolution with ldd $AUTOSYS/bin/autosys_event_server | grep "not found" before declaring victory.

// io.thecodeforge — devops tutorial
// verify autosys linked libraries

$ ldd $AUTOSYS/bin/autosys_event_server | grep -E 'not found|libssl|libcrypto|libdb'
        libssl.so.10 => /opt/autosys/autosys11.0/lib/libssl.so.10 (0x00007f...)
        libcrypto.so.10 => /opt/autosys/autosys11.0/lib/libcrypto.so.10 (0x00007f...)
        libdb-5.3.so => /opt/autosys/autosys11.0/lib/libdb-5.3.so (0x00007f...)

// if you see this, your system libs are overriding autosys:
        libssl.so.10 => /usr/lib64/libssl.so.10 (0x00007f...)
// FIX: prepend $AUTOSYS/lib to LD_LIBRARY_PATH

Deployment Choices: Why Your Autosys Install Strategy Determines Your Pain Level

Most teams treat Autosys installation like a one-size-fits-all problem. That's how you end up with a production event server running on the same hardware as your dev environment. Stop it.

Your deployment choice isn't a checkbox—it's the root cause of every future outage. You have three real paths: single-tier for small teams (one box runs everything), two-tier (application server separate from event processor), and three-tier (adds a dedicated database server). The three-tier setup is your only option if you have more than 500 jobs or need HA. Anything less and you're begging for a silent queue backup when your shared box hits 90% CPU.

Pick your deployment tier based on job volume and recovery SLA. Not on your budget spreadsheet. Trust me, the cost of migrating from single to three-tier mid-production will dwarf any hardware savings.

// io.thecodeforge — devops tutorial

deployment_tiers:
  single_tier:
    components: [event_server, application_server, database]
    use_case: "< 100 jobs, dev/test only"
    risk: "Single point of failure, no recovery"
    
  two_tier:
    components:
      tier_1: [event_server, application_server]
      tier_2: [database]
    use_case: "100–500 jobs, non-critical production"
    risk: "Event server failure stops all scheduling"
    
  three_tier:
    components:
      tier_1: [event_server]
      tier_2: [application_server]
      tier_3: [database, failover_replicas]
    use_case: "> 500 jobs, HA required"
    risk: "None if failover configured correctly"

Advanced Configuration: The Six Config Files That Control Your Sanity

The default Autosys installation throws every configuration file into a single directory. That's fine for a playground. In production, you need surgical control over six files—and if you don't know which ones do what, you're flying blind.

Here's the hierarchy: config.properties sets core parameters (port, queue limits). autosys_env defines environment variables—this is where that LD_LIBRARY_PATH trap lives. jil_daemon.conf controls job submission throttling; misconfigure it and your jobs queue silently. event_server.conf sets backup intervals. db_connection.xml stores credentials; never leave default passwords. And syslog.conf determines where failure logs go—most teams find this only after a crash.

Produce a configuration audit before you deploy a single job. Validate every file against a known-good baseline. The team that forgets to review event_server.conf is the team that discovers backups were running to /tmp every 30 minutes.

// io.thecodeforge — devops tutorial

config_files:
  - path: /opt/autosys/config/config.properties
    params:
      port: 5544
      queue_max_size: 10000
      heartbeat_interval: 30
      
  - path: /opt/autosys/config/event_server.conf
    params:
      backup_interval: 60
      backup_directory: /data/autosys/backups
      log_rotation: daily
      
  - path: /opt/autosys/config/db_connection.xml
    params:
      host: db-01.prod.internal
      port: 3306
      db_name: autosys_prod
      user: autosys_admin
      
audit_rule: "Every config file must be validated against baseline before job scheduler starts."

Installations for Evaluation or Personal Use

When you're evaluating AutoSys or testing configurations, don't deploy the full clustered AUTOSERV setup meant for production. That architecture assumes multiple machines, shared storage, and a dedicated event processor — overkill for a single laptop or VM. Instead, use the standalone autosys_install.sh script with the '-standalone' flag. This creates a local event processor, writes to a local database (SQLite, not Oracle), and skips DNS and NIS requirements. The catch: this mode disables remote agent connections and high availability. You get one box, one autosys user, and rapid iteration. Map this to your evaluation goals: test job definitions, experiment with escalation rules, or validate upgrade scripts. Never mistake the standalone setup for production capacity. Document your test topology clearly — many teams waste weeks debugging failures that stem from assuming standalone behavior matches clustered behavior. For personal use, also reduce the JORAM queue size from default 50MB to 5MB to avoid filling /tmp on small drives.

// io.thecodeforge — devops tutorial

// Standalone AutoSys install for evaluation
installer: autosys_install.sh
flags:
  - -standalone
  - -db SQLite
  - -home /opt/autosys_eval
env:
  AUTOSYS: /opt/autosys_eval
  AUTOSERV: standalone_serv
  JORAM_QUEUE_SIZE_MB: 5
verify:
  check: autosys_console -ping
  expected: "Event Processor: standalone_serv is UP"

Related Articles: Extending Your AutoSys Knowledge

Once your AutoSys installation is stable, three critical follow-up topics determine whether you maintain control or descend into firefighting. First, 'AutoSys Job Status Codes and What They Actually Mean' — the difference between TERMINATED and FAILED statuses often traps new admins. TERMINATED means killed manually; FAILED means non-zero exit code. Second, 'Calendars, Run Calendars, and Extended Calendars: Which One to Use and Why' — most teams overuse extended calendars (costly joins) when run calendars (bitmask patterns) cover 90% of scheduling needs. Third, 'Event Processor Failover: What Happens When AUTOSERV Dies' — understand that failover is not instant; it takes 30-90 seconds for JORAM to elect a new leader. During that window, all job submissions queue and timeouts may fire. For deeper dives, read the AutoSys Troubleshooting Guide (chapters 5-7 cover agent logs and event processor diagnostics) and the CA Workload Automation Hardening Guide. Bookmark the official AutoSys Community Forum — the searchable archives contain fixes for 90% of edge cases.

// io.thecodeforge — devops tutorial

// Recommended learning sequence
topics:
  - title: "Job Status Codes Explained"
    priority: immediate
    reason: "Prevents misdiagnosis of failures"
  - title: "Calendar Selection Guide"
    priority: week1
    reason: "Cuts calendar maintenance by 70%"
  - title: "Failover Mechanics"
    priority: week2
    reason: "Avoids panic during AUTOSERV outage"
sources:
  - doc: "Troubleshooting Guide Ch5-7"
  - forum: "CA Workload Automation Community"