What is Autosys ?

What is Autosys?
An automated job control system for scheduling,monitoring and reporting jobs
The jobs can reside on an Autosys configured machine attached to a network
What is an Autosys Job?
A single action performed on a validated machine
Autosys jobs can be defined using GUI or JIL
Any single command, executable script or NT batch file. It includes a set of qualifying attributes ,conditions
specifying when and where a job should be run.
Autosys jobs can be defined by assigning it a name and specifying attributes describing its behavior.
Two methods to define Autosys Jobs are:1. Using Autosys GUI
Autosys GUI allows to set the attributes that describe when,where and how a job should be run.
GUI Control Panel is used to define jobs.Contain fields that correspond to Autosys JIL sub-commands and
attributes.
2. Using Job Information Language(JIL)
A specification language that has its own commands to describe when,where and how a job should be run.
The attributes are set b JIL sub-commands
Defining Autosys Jobs
There are the three methods you can use to create job definitions:
# By Autosys Web interface
# By AutoSys Graphical User Interface (GUI).
# By using AutoSys Job Information Language (JIL) through a command-line interface.

Autosys Job Types and Structure

There are three types of jobs:

Command,
File Watcher
Box.
----------------------------------------------------------System Components Autosys system components are: Event Server
Event Processor
Remote Agent

Event Server (or Autosys Database)

# Data Repository that stores Autosys system information,events and job definitions.
# The Autosys Db is termed Data Server which describes a server instance
Event Processor
# Interprets and processes all the events it reads from the Autosys Database
# A program that actually runs Autosys
# Scans the database for processing events. Checks if the events satisfy the starting conditions of the job
and the determines the actions

Remote Agent
# Temporary process started by the event processor to perform a specific task on a remote machine
# It starts the command specified for a given job, sends running and completion information about a task to
the Event Server
# If it is unable to transfer the information, it waits and tries until it successfully communicates with the Db

Interaction Between System Components

Step1: From the Autosys event server(that holds the Events and Job Definitions info),the Event Processor
reads the new event,checks for the condition,reads the job definition and determines the actions.
Step2: The Remote Agent receives the instructions from the Event Processor
Step3: The Remote Agent performs resource checks,ensuring minimum specified number of processors are
available and then initiates a child process that runs the specified command
Step4: The command completes and exits,with the Remote Agent capturing the commands exit code.
Step5: The Remote Agent directly communicates the event(exit code,status) to the Event Server.
Autosys Machines V/s Autosys Instances
Autosys architecture has two types of machines: Server Machine:
# The machine on which the Event Processor and Event Server reside
Client Machine:
# The machine on which the Remote Agent resides and where Autosys jobs are run.
What is an Autosys Instance?
A version of Autosys software running as an Autosys server,with one or more clients,on single machine or
on multiple machines
An instance uses its own Event Server and Event Processor by operating independently of all other Autosys
instances
Multiple instances can run and schedule jobs on the same machine without affecting other instances on
that machine.
Events
Since Autosys in Event-driven,it requires an event to occur on which the job depends,for a job to be
activated by the Event Processor.

The sources of these events can be:# Jobs changing status such as starting,finishing
# Internal Autosys verification Agents such as detected errors.
# Events send with the SENDEVENT command
While processing an event,the Event processor scans the database for jobs that are dependent on that
event
If the event satisfies another jobs starting condition,that job is run automatically and completion of that
job can cause another job to be started,thereby making the jobs progress in a controlled sequence.
Alarms
Alarms are special events that send notifications during situations requiring attention
Addresses incidents that require manual intervention

 For example,a set of jobs could be dependent on the arrival of a file and if the file is long overdue.It is
important that someone investiage the situation,make a decision and resolve the problem.
Aspects of alarms include but is not limited to:# Alarms are informational only.Any action to be taken due to a problem is intiated by a separate action
event.
# Alarms are system messages about a detected problem
# Alarms are sent through the system as an event
Utilities
Autosys provides a set of commands that run essential utility programs for defining,controlling and
reporting on jobs .
For example the autorep command allows generating a variety of reports about job execution,and the
sendevent commands allow manually controlling job processing.
Additional utility programs are provided to assist in troubleshooting running monitors and browsers,and
starting/stoping Autosys and its components.
Autosys also provides database maintenance utility that runs daily by default
Autosys Work-Flow

Step1: The Event Processor scans the Event Server for the next event to processor.If no event is ready,the
Event Processor scans again in 5 seconds.
Step2: The Event Processor reads from the Event Server that an event is ready.The job definition and
attributes are retrieved from the Event Server,including the command and the pointer to the profile file to be
used for the job
Step3: The Event Processor processes the event.The Event Processor attempts to establish a connection
with the Remote Agent on the client machine and passes the job attributes to the client machne.The Event
Processor sends a CHANGE_STATUS event marking in the Event Server that the job is in STARTING state
Step4: The Remote Agent is invoked using the UserID and Password passed from the Event Processor.
Step5: The Remote Agent receives the job parameters and sends an acknowledgement to the Event
Processor

 Step6: The Remote Agent Starts a process and executes the command in the job definition.
Step7: The Remote Agent issues a CHANGE_STATUS event marking in the Event Server that the job is in
RUNNING state
Step8: The client job process runs to completion,then returns an exit code to the Remote Agent and quits.
Step9: The Remote Agent sends the Event Server a CHANGE_STATUS event corresponding to the
completion status of the job.The Remote Agent quits
============================================================
/* -------------------- APT#gp#box#ps_1 ----------------- */
delete_job: APT#gp#box#ps_1
insert_job: APT#gp#box#ps_1
job_type: b
owner: PSdevl
permission: gx,ge
description: box for DIN34APT
alarm_if_fail: 1
/* -------------------- initialize ----------------- */
/* -------------- APT#gp#cmd#P0_initialize ------------- */
delete_job: APT#gp#cmd#P0_initialize
insert_job: APT#gp#cmd#P0_initialize
job_type: c
box_name: APT#gp#box#ps_1
command: /export/appl/PSdevl/src/run/pS001_initialize_id.ksh
machine: pm_ps_clust
owner: PSdevl
profile: /appl/PSdevl/.profile
permission: gx,ge
description: cmd for DIN34APT
std_out_file: /export/appl/PSdevl/serial/trans/log/$AUTO_JOB_NAME.log.$AUTORUN
std_err_file: /export/appl/PSdevl/serial/trans/err/$AUTO_JOB_NAME.err.$AUTORUN
alarm_if_fail: 1
=======================================================
Note:
gx -- group exicution
ge -- group edit
=======================================================
AutoSys Cheatsheet
=======================================================
SUB-COMMANDS
insert_job: Saves a brand-new job to the database
update_job: PERMANENTLY changes the definition of a preexisting job
override_job: TEMPORARILY changes the definition of a preexisting job
delete_job: Deletes a single job from the database
delete_box: Deletes a box as well as all the contents

ATTRIBUTES
job_type:command (c), file watcher (f), box (b)(command is default)
machine: Name of machine (or IP) where job is to be
run
command: Command to be executed (.exe, .sh, .bat)
watch_file: File being monitored by file watcher
box_name: Used to nest a job inside a box
std_out_file: Redirects output from a command job to a text
file
std_err_file: Redirects error messages to a text file
condition: Used to structure job dependencies (success,
failure, terminated, done, notrunning, exit code,
and value)
min_run_alarm: Causes job to issue an alarm if it finishes too
quickly
max_run_alarm: Causes a job to issue an alarm if it runs too
long
alarm_if_fail: States whether a job will issue an alarm if it
fails
date_conditions: Toggle which must be set in order for date/time
attributes to be recognized by AutoSys
run_calendar: Specifies the calendar a job will run off of
[cannot be used with days_of_week]
days_of_week: Specifies exact days a job will run [cannot be used with run_calendar]
start_times: Exact time each day a job will run [cannot be
used with start_mins]
start_mins: Minutes after each hour a job will execute
[cannot be used with start_times]
exclude_calendar: Specifies a calendar with days specified upon
which a job will not execute
watch_interval: Steady state for file watchers
watch_file_min_size: Minimum size a file must be before a file watcher can evaluate to success
box_success: Specifies custom success condition for a box
box_failure: Specifies custom failure condition for a box
max_exit_success: Specifies maximum exit code which will be
evaluated as a success
box_terminator: If I fail, I kill the box Im in
job_terminator: If the box Im in fails or gets killed, I kill
myself
term_run_time: I kill myself after this many minutes
chk_files: Resource check that verifies a minimum amount
of file space is available before running job
heartbeat_interval: Specifies frequency in minutes at which jobs
command is expected to issue a heartbeat
profile: Specifies a file which contains custom
environment variables to be used by a single job
std_in_file: Specifies a file to be used as input for a job
n_retrys: Specifies how many times a job should attempt to
re-run itself after an application-level failure
timezone: Specifies which timezone a job should use when
running
auto_delete: Specifies how many HOURS after successful

completion a job should delete itself from the

database
auto_hold: Used only with jobs in boxes. When the box goes
to a RUNNING state, the job will automatically go ON_HOLD
permission: Extend edit or execute permissions to others
run_window: Specifies when a job can start
avg_runtime: *Only accessible through JIL* Specifies how long
a job takes to run, on average