You are on page 1of 12

AutoSys Cheatsheet

AutoSys: UNIX
Cd to the "autouser" ($AUTOUSER) directory and "." (or source) the
"ksh" file. Ex: ". ./autosys.ksh.machine" After installing AutoSys, first
make sure that the DB is up and running. Check the installation by
running the command chk_auto_up to verify connection to the DB and
event processor.
Enter the KEYS through "gatekeeper", add keys
Run the "autosys_secure" command to set the AutoSys Edit and Exec
Super users (and also to enter NT users/passwords)
Start the Event Processor by running the command "eventor"
Shutdown AutoSys: "sendevent -E STOP_DEMON"
To start the AutoSys GUI set your DISPLAY and run the command
"autosc &".
NT: Start AutoSys from start->programs->AutoSys-> administrator
->Graphical User Interface ->Command Prompt
Command Line Commands:
1. gatekeeper: Allows you to enter the License Keys which allow
you to run AutoSys.
2. eventor [-M machine_name] : Starts the event processor.
3. autorep -J [ALL | Job_name] [-q] [> file_name], -d (detail), -r (run
number), -o (override), jil < file_na -G (global var report), -M -q
for machine definitions.
Ex: autorep -J job_name -d
autorep -J job_name -d
autorep -J job_name -q > file_name queries the DB & save job
Dfn. Into a file
vi file_name
When you want a report of a box use the -L0 option
Autorep -J job_name -l1 report on the job for the day -1 (prev
day)
4. sendevent -E STARTJOB -J job_name, sendevent -E
FORCE_STARTJOB -J job_name, [JOB_ON_ICE, JOB_OFF_ICE,
JOB_ON_HOLD, JOB_OFF_HOLD, SET_GLOBAL,
STOP_DEMON. . . .]
sendevent -E STOP_DEMON - to stop AutoSys
(ex: sendevent -E SET_GLOBAL -G "var_name=/home/mydir" to
set a var)
(ex: sendevent -E SET_GLOBAL -G "var_name=DELETE" to
delete a var)]
5. chk_auto_up: checks to see if event processor and the DB are
both up.
6. autoping -m machine: verify that both client & server are
correctly configured.
7. cron2jil -f cronfile [-d outdir] [-I incl_file] [-m machine] [-p prefix]
8. jil <CR>
To insert a job directly into the DB
insert_job: job.id job_type: c
machine: machine_name
command: echo testing jil
[go | ;] (depending on the DB you are using)
Template example:
/* ----------------- template ----------------- */
insert_job: template job_type: c
box_name: box1
command: ls -l
machine: localhost
owner: lyota01@TANT-A01
permission: gx,ge,wx,we,mx,me
date_conditions: 1
days_of_week: all
start_times: "15:00, 14:00"
run_window: "14:00 - 6:00"
condition: s (job1)
description: "description field"
n_retrys: 12
term_run_time: 60
box_terminator: 1
job_terminator: 1
std_out_file: /tmp/std_out
std_err_file: /tmp/std_err
min_run_alarm: 5
max_run_alarm: 10
alarm_if_fail: 1
max_exit_success: 2
chk_files: /tmp 2000
profile: /tmp/.profile
job_load: 25
priority: 1
auto_delete: 12
9. autosyslog -e: same as tail -f autosys_log_file. This command
must be run from the machine where the server resides if used
with the -e option. Else it can be used with the -J option to see
that job's run log.
10. job_depends: -[c|d|t] -J jobname [-F "mm/dd/yy time"] [-T
"mm/dd/yy time"] (Note: It will only print out the first occurrence
found)
11. monbro -n monitor_name: Allows you to run from command line
monitor/browser programs previously created using the
monitor/browser GUI.exec superuser: AUTOSYS superuser
12. autocal_asc full_cal_name: prints, adds & deletes custom
calendar definitions.
13. autostatus: Reports the current status of a specific job, or the
value of an AutoSys global variable. Ex: autostatus -J job_name,
-S instance
14. autotimezone -l : Allows additions, deletions, and queries to the
timezones table (-l provides list).
15. autotrack: Tracks & report changes to the AutoSys DB. Ex:
autotrack -l 2 (level 2) [sets the tracking level] autotrack -U sys
-v (user sys: verbose) To start using the autotrack utility type:
autotrack -u to set tracking level 1 or 2. By default it is set to 0.
Autotrack -l will list the current tracking level. Options -[J, U, m, F,
T, and t] are to request reporting on a specific Job, User,
machine, time window (-F -T), and event type (t). Type is used in
conjunction w/other parameters. autotrack w/no arguments
retrieves information an all events omitting detail. -v option is for
verbose.
16. autosys_secure: to change edit, exec superusers, change DB
passwd, change remote authentication method.
17. chase [-A|E]: Makes sure that jobs claiming to be running in the
client machine are running. The "-E" option restarts the job.
18. archive_events: to archive events in the DB which are older
than x days to prev DB from becoming full.
19. clean_files: Deletes old remote agent log files. It does it by
searching the DB for all machines which have had jobs started on
them.
20. autostatad: to get the status of a PeopleSoft job. You can define
one of the user definable buttons to view PeopleSoft job:
Autocons*userButton1Label: Adapter Status
User definable buttons: There are user definable buttons in the
operator's console.
How to configure:
Autocons*userButton1Command: /autosys/bin/autostatad -J $JOB -g &
(which allows you to have a command button on the operator's
console.)
Dependencies:
success (job) and s(job_b)
failure(job_a) or f (job_b)
notrunning (job)
terminated(job)
exitcode(job) > 5 and exitcode(job_b) != 10
value(global_name)=100
done(job)
Hostscape: Schedule a job to run every x minutes & then go into
forecasting. Make that job fail.
• Solid black line: Hostscape can communicate with the remote
agent in the client machine.
• Solid red line: Hostscape can't communicate with the remote
agent but it can communicate with the internet daemon (inetd)
running on that machine..
• Dashed red line: Hostscape can't communicate with the client
machine at all. Client is probably down.
• Accessing a variable name: $$GLOBAL_VAR_NAME (unless
used in dependency condition with a job definition. If used in the
"command" field, you must use the $$)
Tunable Parameters:
• $AUTOUSER/config.ACE
• $AUTOUSER/autosys.ksh.xxx
• /etc/auto.profile
• /etc/inetd.conf
• /etc/services
Notify.Ace: The alarms to notify on are:
(There is an example in $AUTOSYS/install/data/Notify.Ace).
• DB_ROLLOVER
• DB_PROBLEM
• EP_HIGH_AVAILABILITY
• EP_ROLLOVER
• EP_SHUTDOWN
Where to go to find the Errors:
• $AUTOUSER/out/event_demon.$AUTOSERV
($AUTOUSER/out/event_demon.ACE)
• Output from the job definition output & error files
• /tmp files created for job_run at client machine
• $AUTOSYS/out/DBMaint.out for DB problems
• $SYBASE/install/errorlog_$DSQUERY when event server will not
start.
• NT: AutoNuTc\lib/X11\app-defaults\xpert
AutoSys Maintenance: DBMaint @$AUTOSYS/bin
Once a day the Database goes into a maintenance cycle. Every day at
3:00am it runs a program called DBMaint. This is user configurable.
The program runs DBstatistics which is found in $AUTOSYS/bin.
app-defaults file: /usr/openwin/lib/app-defaults directory. Autocons,
Xpert, etc.. ( or: /usr/lib/X11/app-defaults, /autosys/bin/X11/app-
defaults)
Environment file: /etc./auto.profile
C programs: $AUTOSYS/code
Where to change AutoSys screen fonts: /usr/openwin/lib/app-defaults
Where to look for troubleshooting: Chapter 15
Summary of commands: Appendix C
$AUTO_JOB_NAME: when naming a file dynamically using as prefix
AutoSys's job name.
$AUTORUN: unique identifier for the run of that job
$AUTOPID: unique identifier for that job's run number (PID)
$JOID: DB identifier for a job. To extract from the DB: select joid from
job where job_name=" "
Creating a Virtual Machine:
insert_machine: virtual
type: v /* default, not required */
machine: real_1
machine: real_2
max_load: 100
factor: 0.5 /* used to describe the relative processing power of a
machine. Usually between 0.0-1.0*/
machine: real_2
max_load: 60 /* this is designed to limit the loading of a machine */
Load Balancing, Queuing, priorities:
insert_job: test_load
machine: localhost
command: echo "Test load balancing"
job_load: 50
priority: 1 /* this only affects queues */
Note: For 5.0 we will be using information from ServerVision's towards
our load balancer which is composed of 26 categories such as i/o
usage, disk usage, CPU usage, etc.
Testing:
zql
zql -U autosys -P autosys
NOTES:
When a job is stuck in the starting condition this means that the event
processor communicated with the remote agent and passed all the
information the remote agent ran the job but was not able to
communicate to the DB. Once testing is done with AutoSys one should
change the default refresh interval for AutoSys. This is so there is less
querying to the DB. When AutoSys goes from dual mode to single
mode, always run the autobcp command before bringing AutoSys back
to dual mode/High Availability. Default behavior for stdout is to always
appends. If you want to overwrite the file enter the following, no
spaces: ">file.out"
Box Logic
Use boxes to group jobs with like scheduling parameters, not as means
of grouping jobs organizationally. For example, if you have a number of
jobs that run daily at 1:00 a.m., you could put all these jobs in a box
and assigning a daily start condition to the box. However, a variety of
account processing jobs with diverse starting conditions should not be
grouped in the same box.
Default Box Job Behavior
Some important rules to remember about boxes are:
• Jobs run only once per box execution.
• Jobs in a box will start only if the box itself is running.
• As long as any job in a box is running, the box remains in
RUNNING state; the box cannot complete until all jobs have run.
• By default, a box will return a status of SUCCESS only when all
the jobs in the box have run and the status of all the jobs is
"success." Default SUCCESS is described in Default Box Success
and Box Failure on page 5-13.
• By default, a box will return a status of FAILURE only when all
jobs in the box have run and the status of one or more of the
jobs is "failure." Default FAILURE is described in Default Box
Success and Box Failure on page 5-13.
• Unless otherwise specified, a box will run indefinitely until it
reaches a status of SUCCESS or FAILURE. For a description of
how to override this behavior, see Box Job Attributes and
Terminators on page 5-6.
• Changing the state of a box to INACTIVE (via the sendevent
command) changes the state of all the jobs in the box to
INACTIVE.
When you Should Not Use a Box
The fact that all jobs in a box change status when a box starts running
has lead some to use boxes to implement "job cycle" behavior. Be
aware that placing jobs in a box to achieve this end may bring with it
undesired behavior due to the nature of boxes.
Avoid the temptation to put jobs in a box as a short cut for performing
events (such as ON_ICE or ON_HOLD) on a large number of jobs at
once. You will most likely find that the default behavior of boxes
inhibits the expected execution of the jobs you placed in the box.
Likewise, you should not place jobs in a box solely because you want to
run reports on all of them. When you run autorep on a box, you will get
a report on the box and all the jobs in the box (unless you use the -L0
option). In addition, if you use wildcarding when specifying a job name,
you could get duplicate entries in your report. For example, suppose
you have a box named "acnt_box" containing three jobs named
"acnt_job1", "acnt_job2", and "daily_rep". If you specify acnt% as the
job name for the autorep report, the report will have an entry for the
box "acnt_box" and an entry for each job in the box. Then autorep will
continue searching for all job names matching the wildcard characters
and, thus, will list "acnt_job1" and "acnt_job2" a second time.
What Happens when a Box Runs
As soon as a box starts running, all the jobs in the box (including sub-
boxes) change to status ACTIVATED, meaning they are eligible to run.
(Because of this, jobs in boxes do not retain their statuses from
previous box cycles.) Then each job is analyzed for additional starting
conditions. All jobs with no additional starting conditions are started,
without any implied ordering or prioritizing. Jobs with additional
starting conditions remain in the ACTIVATED state until those
additional dependencies have been met. The box remains in the
RUNNING state as long as there are activated or running jobs in the
box.
If a box is terminated before a job in it was able to start, the status of
that job will change directly from ACTIVATED to INACTIVE.
Note o Jobs in a box cannot start unless the box is running.
However, once the job starts running, it will continue to run
even if the box is later stopped for some reason.
Time Conditions in a Box
Each job in a box will run only once per box execution. Therefore, you
should not define more than one time attribute for any job in a box
because the job will only run the first time. If you want to put a job in a
box, but you also want it to run more than once, you must assign
multiple start time conditions to the box itself, and define no time
conditions for the job. Remember also that the box must be running
before the job can start. Do not assign a start time for a job in a box if
the box will not be running at that time. If you do, the next time the
box starts the job will start immediately.
The following example illustrates a scenario that would not work
properly if placed in a box.
"job_a" is defined to run repeatedly until it succeeds. "job_report" has
one starting condition-the success of "job_a".
How Job Status Changes Affect Box Status
If a box that is not running contains a job that changes status, as a
result of a FORCE_STARTJOB or CHANGE_STATUS event, the new job
status could change the status of its container box. A change of status
of the box could trigger the start of downstream jobs that are
dependent on the box.
If a box contained only one job, and the job changed status, the box
status would change.
The difference between "on hold" and "on ice" is that when an "on
hold" job is taken off hold, if its starting conditions are already
satisfied, it will be scheduled to run, and it will run. On the other hand,
if an "on ice" job is taken "off ice," it will not start, even if its starting
conditions are already satisfied. This job will not run until its starting
conditions reoccur.

The other major distinction is that jobs downstream from the job that is
"on ice" will run as though the job succeeded. Whereas, all dependent
jobs do not run when a job is on "on hold"—nothing downstream from
this job will run.

Starting Parameters :
AutoSys determines whether to start or not to start a job based on the
evaluation of the starting conditions (or starting parameters) defined
for the job. These conditions can be one or more of the following:
¦ Date and time scheduling parameters are met (it is or has passed the
specified date and time).
¦ Starting Conditions specified in the job definition evaluate to true.
¦ For jobs in a box, the box must be in the RUNNING state.
¦ The current status of the job is not ON_HOLD or ON_ICE.
Every time an event changes any of the above conditions, AutoSys
finds all the jobs that may be affected by this change, and determines
whether or not to start them.

sample jil code / Writing jil code:


1. insert_job: template job_type: c
2. box_name: box1
3. command: ls -l
4. machine: localhost
5. owner: lyota01@TANT-A01
6. permission: gx,ge,wx,we,mx,me
7. date_conditions: 1
8. days_of_week: all
9. start_times: “15:00, 14:00″
10. run_window: “14:00 - 6:00″
11. condition: s (job1)
12. description: “description field”
13. n_retrys: 12
14. term_run_time: 60
15. box_terminator: 1
16. job_terminator: 1
17. std_out_file: /tmp/std_out
18. std_err_file: /tmp/std_err
19. min_run_alarm: 5
20. max_run_alarm: 10
21. alarm_if_fail: 1
22. profile: /tmp/.profile
Explanation of each line:
1. Insert_job: this will let the autosys server to recognize the job and inserts into autosys
DataBase. Jobtype: there are two types of jobs namely box and child ( c=child, box)
2. box_name: this is the box job name: box job can have more than 1 child jobs. (this is
just like grouping the jobs).
3. commands: this is where you tell autosys, what to do when the job runs. ( you’ll give
reference to your scripts here).
4. machine: name of the machine where you want to run the job.
5. owner: owner of the job.
6. permissions.
7. date_conditions: 1 if you have any specifications.
8. days_of_week: on which days of the week you want the job to run.
9. start_time: the time at which the job should kick-off.
10. run_window: this option is for monitoring jobs. the job will run continously for the
specified time window.
11. conditions: here you can specify the dependencies. like success of some other job.
12. description.
13. n_retrys: no of retrys on a failure.
14. term_run_job: the job will terminate if it runs for specified time.
15. box_terminator: if 1, terminates box job depends on term_run_time.
16. job_terminator: if 1, terminates child job depends on term_run_time.
17. std_out_file: standard output file (log) for the job
18. std_err_file: Error log file if the job fails
19. min_run_alarm: if the job terminates/completed with in that time it generate an alarm
20. max_run_alarm: if the job runs for more than the specified time, it generate an alarm
21. alarm_if_fail: generates an alarm if the job fails
22. profile: the file where you can keep all your variables (variable names)
We don’t use all the above options in all the jobs, it depends on the requirements.
Here is a sample job which will verify a particular process is running or not.
/* —————– SAP_UAT_MU03_C —————– */
insert_job: SAP_UAT_MU03_C job_type: c
command: /local/SAP/processCheckUAT.sh
machine: MU03-UAT
owner: admin@MU03-UAT
permission: gx,wx,mx,me
days_of_week: all
start_times: “15:00, 14:00″
description: “Job used for Run testing of process”
alarm_if_fail: 1
max_exit_success: 1

To Insert a new JIL code :


issue command "jil"
bash-3.00$ jiljil>>1>
"The following prompt will appear" copy paste the jil code u have made example of jil code
below...........
At the end the "C" or "B" determines if the job is box job or child job.
if the jil is inserted properly successfull message will come if any errors are there the jil code
contains some errors..
if successfull exit;

Using Autorep command:


Function
Reports information about a job, jobs within boxes, machines, and machine status. Also reports
information about job overrides and global variables.
Syntax
autorep {-J job_name -M machine_name -G global_name} [-s -d -q -o over_num] [-r run_num]

autorep -J (job name here)

This will display a list of jobs with complete details with box/jobname, last/latest run date &
time, status, exit code, etc.
Viewing JIL code for any Autosys job

autorep -J (job name here) -q

To obtain the underlying JIL (Job Interaction Language) source code for any Autosys job, run
command:

To obtain the information of previous runs

autorep -J (job name here) -r (No of runs back) example : autorep -J (job name here) -r 1

would generate a report for the job run one runs back

Status Abbreviations
The following table lists the abbreviations used in the ST (status) column of the autorep report,
and gives the status for each abbreviation.

AC - ACTIVATED
FA - FAILURE
IN - INACTIVE
OH - ON_HOLD
OI - ON_ICE
QU - QUE_WAIT
RE - RESTART
RU - RUNNING
ST - STARTING
SU - SUCCESS
TE - TERMINATED

sendevent:
sendevents to AutoSys for a variety of purposes, including starting or stopping AutoSys jobs,
stopping the Event processor, and putting a job on hold. This command is also used to set
AutoSys global variables or cancel a scheduled event.

sendevent is normally used with "-E" & -J option

-J job_name : Specifies the name of the job to which the specified event should be sent. This
option is required for all events except STOP_DEMON, COMMENT, ALARM, or SET_GLOBAL

-E event :Specifies the event to be sent. This option is required. Any one of the following
events may be specified:

STARTJOB
KILLJOB
DELETEJOB
FORCE_STARTJOB
JOB_ON_ICE
JOB_OFF_ICE
JOB_ON_HOLD
JOB_OFF_HOLD
CHANGE_STATUS
STOP_DEMON
CHANGE_PRIORITY
COMMENT
ALARM
SET_GLOBAL
SEND_SIGNAL

Following are the example of sendevent command frequently used.

To start or force start a job manually using sendevent :

sendevent –E FORCE_STARTJOB -J "Job Name Here"

sendevent -E STARTJOB -J "Job Name Here"

To put jobs on OFF ICE or ON ICE :

sendevent -E OFF_ICE -J "Job Name Here"

sendevent -E ON_ICE -J "Job Name Here"

autostatus: Reports the current status of a specific job, or the value of an AutoSys global
variable. Ex: autostatus -J job_name, -S instance
Where to go to find Autosys Errors
o $AUTOSYS/out/DBMaint.out for DB problems.
o $AUTOUSER/out/event_demon.$AUTOSERV.
o $SYBASE/install/errorlog_$DSQUERY when event server will not start..
o ($AUTOUSER/out/event_demon.ACE).
o /tmp files created for job_run at client machine.
o NT: AutoNuTc\lib/X11\app-defaults\xpert.
o Output from the job definition output & error files.

Autosys Dependencies

o done(job).
o exitcode(job) > 5 and exitcode(job_b) != 10.
o failure(job_a) or f (job_b).
o notrunning (job).
o success (job) and s(job_b).
o terminated(job).
o value(global_name)=100.

Application Server

A new component which handles the Database connectivity for the AutoSys r11 clients,
Command Line Utilities and the GUI's. It has a persistent connection to the DB to allow
improved response speed. It also removes the requirement of having a global database
user/password.

Event Server

The DB containing the events. Differences from 4.5 include vendor library files for the Server
and client components.

WCC

The default user interface for AutoSys is Workload Command Centre (WCC). The current
version of this application is WCC r11.0 a browser-based application which allows job
management and editing, plus customizable view creation and granular permissions to be
created.

Remote Agent

The Remote Agent is now a persistent process on all Operating Systems, it also loses its DB
API making it independent of a particular AutoSys instance.

eEEM aka eIAM

eTrust Embedded Entitlements Manager is the replacement of the eTrust Access Control
component seen in version 4.5. eEEM is a cut down version of eAC and is aimed at a single
application access control point rather than a system based tool. It allows user and group
access to AutoSys and WCC resources via an ACL administered GUI, access can be
granted or denied based upon filters and groups or managed explicitly.

Autosys is really a very wonderful tool - especially on Unix variants. Very simple job
definition language. Lots of commands to control the job.

Autosys CLI Syntax - Interface


Here is a template file that explains the syntax of Autosys JIL. (Job Information Language.)