13-Autosys UserGuide

AutoSys®
Reference Guide
for UNIX
Version 3.5
This documentation and related computer software program (hereinafter referred to as the
"Documentation") is for the end user’s informational purposes only and is subject to change
or withdrawal by Computer Associates International, Inc. ("CA") at any time.
THIS DOCUMENTATION MAY NOT BE COPIED, TRANSFERRED, REPRODUCED,
DISCLOSED OR DUPLICATED, IN WHOLE OR IN PART, WITHOUT THE PRIOR WRITTEN
CONSENT OF CA. THIS DOCUMENTATION IS PROPRIETARY INFORMATION OF CA AND
PROTECTED BY THE COPYRIGHT LAWS OF THE UNITED STATES AND INTERNATIONAL
TREATIES.
TO THE EXTENT PERMITTED BY APPLICABLE LAW, CA PROVIDES THIS
DOCUMENTATION "AS IS" WITHOUT WARRANTY OF ANY KIND, INCLUDING WITHOUT
LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE OR NONINFRINGEMENT. IN NO EVENT WILL CA BE LIABLE TO
THE END USER OR ANY THIRD PARTY FOR ANY LOSS OR DAMAGE, DIRECT OR
INDIRECT, FROM THE USE OF THIS DOCUMENTATION, INCLUDING WITHOUT
LIMITATION, LOST PROFITS, BUSINESS INTERRUPTION, GOODWILL OR LOST DATA,
EVEN IF CA IS EXPRESSLY ADVISED OF SUCH LOSS OR DAMAGE.
THE USE OF ANY PRODUCT REFERENCED IN THIS DOCUMENTATION AND THIS
DOCUMENTATION IS GOVERNED BY THE END USER’S APPLICABLE LICENSE
AGREEMENT.
The manufacturer of this documentation is Computer Associates International, Inc.
Provided with "Restricted Rights" as set forth in 48 C.F.R. Section 12.212, 48 C.F.R. Sections
52.227-19(c)(1) and (2) or DFARS Section 252.227.7013(c)(1)(ii) or applicable successor
provisions.
©1993, 1999 Computer Associates International, Inc., One Computer Associates Plaza,
Islandia, New York 11788-7000. All rights reserved.
All product names referenced herein belong to their respective companies.
Table of Contents
Preface
About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Typographical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Command Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
UNIX and Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Contacting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Related Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
1 • AutoSys Commands
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3
Functional Listing of AutoSys Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-4
archive_events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-6
autocal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
autocal_asc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13
autocons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
autoflags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-18
autoping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20
autorep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-23
autosc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-36
autostatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-37
autosyslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-41
autosys_secure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-45
autotimezone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-53
autotrack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-57
chase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-65
chk_auto_up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-69
chk_cond (SP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-73
clean_files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-75
AutoSys Reference Guide for UNIX iii ■

■ Table of Contents
cron2jil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-77
dbstatistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-80
eventor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-82
gatekeeper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-87
jil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-89
job_depends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-95
monbro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-102
record_sounds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-105
sendevent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-108
sendevent (SP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-121
xql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-124
2 • JIL/GUI Job Definitions

JIL Sub-commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
Job Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
alarm_if_fail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
auto_delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
auto_hold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
avg_runtime (JIL only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
box_failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13
box_name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
box_success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17
box_terminator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19
chk_files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21
command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-23
condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-27
date_conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-35
days_of_week . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-37
delete_box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-39
delete_job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-40
description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-42
exclude_calendar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-44
heartbeat_interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-46
insert_job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-48
job_load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-51
■ iv AutoSys Reference Guide for UNIX

Table of Contents ■
job_name (GUI only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-53

job_terminator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-54
job_type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-56
machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-58
max_exit_success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-61
max_run_alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-63
min_run_alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-65
n_retrys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-67
override_job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-69
owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-73
permission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-76
priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-81
profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-84
run_calendar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-87
run_window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-89
start_mins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-92
start_times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-94
std_err_file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-96
std_in_file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-99
std_out_file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-101
term_run_time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-104
timezone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-106
update_job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-109
watch_file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-111
watch_file_min_size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-114
watch_interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-116
3 • JIL Machine Definitions

JIL Sub-commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-2
Machine Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-2
delete_machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-3
factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-5
insert_machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-8
machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
max_load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15
AutoSys Reference Guide for UNIX v ■

type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17
4 • JIL/GUI Monitor/Report Definitions

JIL Sub-commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Monitor and Report Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
after_time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
alarm_verif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
all_events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10
all_status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
currun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14
delete_monbro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16
failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17
insert_monbro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-19
job_filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-22
job_name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24
mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26
monbro_name (GUI only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28
restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-30
running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32
sound . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-34
starting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-36
success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-38
terminated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-40
update_monbro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-42
5 • System States
Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
ALARM (106) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
CHANGE_PRIORITY (120) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
CHANGE_STATUS (101) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
CHECK_HEARTBEAT (116) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
CHK_BOX_TERM (118) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
CHK_MAX_ALARM (114) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
CHK_RUN_WINDOW (122) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
■ vi AutoSys Reference Guide for UNIX

COMMENT (117) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-5

DELETEJOB (119) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-5
EXTERNAL_DEPENDENCY (127) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-6
FORCE_STARTJOB (108) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-6
HEARTBEAT (115) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-6
JOB_ON_ICE (110) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-6
JOB_OFF_ICE (111) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-6
JOB_ON_HOLD (112) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-6
JOB_OFF_HOLD (113) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-7
KILLJOB (105) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-7
RESEND_EXTERNAL_STATUS (128) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-7
SET_GLOBAL (125) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-7
SEND_SIGNAL(126) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-7
STARTJOB (107) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-7
STOP_DEMON (109) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-8
Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-8
ACTIVATED (9) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-8
FAILURE (5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-8
INACTIVE (8) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-8
ON_HOLD (11) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-8
ON_ICE (7) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-9
QUE_WAIT (12) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-9
RESTART (10) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-9
RUNNING (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-9
STARTING (3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-9
SUCCESS (4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
TERMINATED (6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
ALREADY_RUNNING (528) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
AUTO_PING (526) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
CHASE (514) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
DATABASE_COMM (516) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
DB_PROBLEM (523) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11
DB_ROLLOVER (519) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11
DUPLICATE_EVENT (524) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11
AutoSys Reference Guide for UNIX vii ■

EP_HIGH_AVAIL (522) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11

EP_ROLLOVER (520) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11
EP_SHUTDOWN (521) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11
EVENT_HDLR_ERROR (507) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12
EVENT_QUE_ERROR (508) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12
FORKFAIL (501) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12
INSTANCE_UNAVAILABLE (525) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12
JOBFAILURE (503) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12
JOBNOT_ONICEHOLD (509) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12
MAX_RETRYS (505) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
MAXRUNALARM (510) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
MINRUNALARM (502) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
MISSING_HEARTBEAT (513) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
OB_SHUTDOWN (527) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
RESOURCE (512) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14
STARTJOBFAIL (506) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14
VERSION_MISMATCH (518) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14
AutoSys Exit Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15
6 • Database Tables and Codes

AutoSys Tables and Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
alamode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
audit_info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
audit_msg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
avg_job_runs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
calendar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
chase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
cred . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
event0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
event2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
eventvu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
ext_job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
glob . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6
■ viii AutoSys Reference Guide for UNIX

intcodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-6
job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-6
job2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-6
job_cond . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-6
job_runs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-7
job_status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-7
jobst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-7
keymaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-7
last_Eoid_counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-7
machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-8
monbro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-8
msg_ack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-8
next_oid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-8
next_run_num . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-8
overjob . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-8
req_job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-9
restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-9
svarchive_tbl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-9
svarchive_vw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-9
timezones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-9
wait_que . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-9
AutoSys Database Numeric Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10
Event Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10
Event status Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11
Event que_status Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11
Alarm Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11
Alarm State Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-12
7 • AutoSys API
Accessing Events from the Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2
Sending Heartbeats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-4
Index
AutoSys Reference Guide for UNIX ix ■

■ x AutoSys Reference Guide for UNIX

Preface
Welcome to the world of AutoSys, the scheduling and operations
automation software for distributed computing environments.
About This Guide 0
The AutoSys Reference Guide for UNIX is intended for system

administrators and operations personnel who will be responsible for
defining jobs to AutoSys, and monitoring and managing these jobs. It
lists the AutoSys system states and commands, and it lists job, machine,
monitor, and report definition parameters
The chapters of this guide are organized in the following way.
Ch.
No. Chapter Name Content Description
1 AutoSys Commands Provides a listing, in “man page”

format, of all the commands used to
control, configure, and report on
AutoSys from the UNIX command line.
AutoSys Reference Guide for UNIX xi ■

■ Preface
About This Guide
Ch.
2 JIL/GUI Job Definitions Provides a listing, in “man page”

format, of all the JIL sub-commands
used to control whether a job is to be
created, updated, deleted, and so forth.
It also provides a listing, in “man page”
format, of all the JIL and GUI-entered
job attributes for defining and
describing jobs.
3 JIL Machine Definitions Provides a listing, in “man page”
format, of all the JIL sub-commands
and job attributes used to define and
describe real and virtual machines.
4 JIL/GUI Monitor/Report Provides a listing, in “man page”
Definitions format, of all the JIL sub-commands
used to monitor and generate reports
on AutoSys jobs. It also provides a
listing, in “man page” format, of all the
JIL and GUI-entered attributes for
monitoring and generating reports on
AutoSys jobs.
5 System States Provides a listing of the events, states,
alarms, and exit codes that AutoSys can
generate and process at runtime.
6 Database Tables and Codes Provides a listing of the AutoSys
database tables and views and the
event and alarm codes used in the
database.
■ xii AutoSys Reference Guide for UNIX

Preface ■
Assumptions
Ch.
7 AutoSys API Describes how to integrate AutoSys

events and alarms into the user’s
processing environment using the
AutoSys application program interface
or API. It describes how to access events
from the AutoSys database, and how to
send heartbeats that can verify normal
processing.
Index Helps you locate information within

this manual.
Assumptions 0
This guide assumes familiarity with AutoSys and the UNIX operating
system, as well as the operating system on which the jobs will be
scheduled, and it assumes that you have already installed AutoSys using
the AutoSys Installation and Getting Started Guide for UNIX.
Typographical Conventions 0
Some or all of the following conventions appear in this guide:
Symbol or
Type Style Represents Example
Bold a new term ...called a source object.
field names (optional) Click OK.
AutoSys Reference Guide for UNIX xiii ■

■ Preface
Typographical Conventions
Symbol or
Type Style Represents Example
Magenta (online only) hotlinked ...see Chapter 3, Data

cross-references to other Migration.
sections in this guide; if
you are viewing this guide
online in PDF format, you
can click the cross-
reference to jump directly
to its location
Italic words that are emphasized ...the entry after the current
entry...
the titles of other General Facilities Reference

documents Guide
syntax variables COPY filename
Monospace directories, file names, &HIGHLVL.SRCLIB

command names,
computer code
computer screen text, Copy file? Y/N

system responses,
command line commands
Monospace what a user types ...enter RUN APP.EXE in the
bold Application field
} choosing a command from File } Import } Object

a cascading menu
Highlighted used to callout screen text Dataset....
Screen Text Product....
on character- based screen Parmlib...
captures. (When viewed
online, the screen text will
be blue.)
■ xiv AutoSys Reference Guide for UNIX

Preface ■
Command Syntax Conventions
Command Syntax Conventions 0
UNIX and Windows 0
Syntax statements for UNIX and Windows commands are formatted as

follows:
name [option...] [command argument...]
The following is an example:

xxx_stgd -h [-l [level]] [-L file] [-a port] [-d [level]] [-s server]
[-m hostname] [-S status] [action -P|-R -p {-T -H -y}]
■ Options consist of one character and are always preceded by a hyphen

(-).
■ Options with no arguments can be grouped after a single hyphen.
■ [ ]—Brackets surround an option or command argument that is not

required.
■ {}—Curly brackets enclose options or arguments that are

interdependent; everything enclosed must be treated as a unit.
■ |—Denotes OR condition.
Contacting Technical Support 0
You can contact us with any questions or problems you have. You will be
directed to an experienced software engineer familiar with AutoSys. You
can contact Computer Associates Technical Support at:
www.support.cai.com.
AutoSys Reference Guide for UNIX xv ■

■ Preface
Related Publications
Related Publications 0
As you use this AutoSys Reference Guide for UNIX, you might find it
helpful to have these additional books available for reference:
■ AutoSys and AutoSys/Xpert Release Notes for UNIX, which provides

important information about this release. Please read this before
proceeding.
■ AutoSys Upgrade Instructions for UNIX, which describes how to upgrade

to the current version of AutoSys.
■ AutoSys Installation and Getting Started Guide for UNIX, which describes
the basic AutoSys configurations, how to install AutoSys, including
how to configure AutoSys components, databases, and high
availability features. In addition, this guide describes how to enter
license keys.
■ AutoSys User Guide for UNIX, which describes how to define, run,
monitor, and report on jobs. In addition it describes how to run and
manage AutoSys, and it describes AutoSys security and the AutoSys
configuration file.
■ xvi AutoSys Reference Guide for UNIX

1
AutoSys Commands
This chapter provides a task oriented list of AutoSys commands followed
by an alphabetical listing of all the commands used to control, configure,
and report on AutoSys jobs.
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Functional Listing of AutoSys Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
archive_events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
autocal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
autocal_asc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13
autocons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
autoflags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-18
autoping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20
autorep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-23
autosc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-36
autostatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-37
autosyslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-41
AutoSys Reference Guide for UNIX 1-1 ■

■ AutoSys Commands
autosys_secure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-45
autotimezone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-53
autotrack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-57
chase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-65
chk_auto_up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-69
chk_cond (SP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-73
clean_files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-75
cron2jil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-77
dbstatistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-80
eventor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-82
gatekeeper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-87
jil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-89
job_depends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-95
monbro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-102
record_sounds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-105
sendevent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-108
sendevent (SP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-121
xql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-124
■ 1-2 AutoSys Reference Guide for UNIX

AutoSys Commands ■
Introduction
Introduction 1
You execute AutoSys commands at the UNIX operating system prompt,

using options and arguments to specify exactly what you want them to
do. You can also embed many of these commands within shell scripts.
After you are familiar with the commands in this chapter, you can create
aliases for those commands you will use frequently, such as the
sendevent command that is used for starting jobs.
Note • The command reference found in this chapter is also available

on-line, by way of the UNIX man command. For example, to access the
reference page for the sendevent command, enter this:
man sendevent
If this does not display the proper man page, it is because the MANPATH
environment variable is not set correctly. This variable is usually set in
the $AUTOUSER/autosys.* files used for setting up the environment for
AutoSys (* = .csh.hostname, .sh.hostname, or ksh.hostname).

Functional Listing of AutoSys Commands
Functional Listing of AutoSys Commands 1
This section lists which AutoSys commands to use for specific tasks. Turn
to the listed page number for a full description of the command.
Task Command Page
Accessing Sybase xql page 1-124

Checking System Status autoflags page 1-18
autoping page 1-20
autosyslog page 1-41
chase page 1-65
chk_auto_up page 1-69

Converting cron to JIL cron2jil page 1-77
Defining AutoSys Jobs jil page 1-89
or Machines
autocal_asc page 1-13

Defining Calendars autocal page 1-11
autocal_asc page 1-13

Installing and gatekeeper page 1-87
Managing License Keys
Maintaining Databases archive_events page 1-6
clean_files page 1-75
dbstatistics page 1-80

Managing Security autosys_secure page 1-45

Functional Listing of AutoSys Commands
Task Command Page
Monitoring Jobs autocons page 1-16

Recording Sounds record_sounds page 1-105
Reporting Job job_depends page 1-95
Dependencies and
Conditions
Reporting Job Status autorep page 1-23
autostatus page 1-37
monbro page 1-102

Starting AutoSys eventor page 1-82
Stopping AutoSys sendevent page 1-108

archive_events
archive_events 1
Function 1
Removes old information from the AutoSys database. archive_events

will optionally copy the information to an archive directory before
deletion.
Syntax 1
archive_events {-n num_of_days | -j num_of_days |

-l num_of_days | -s num_of_days } [-A] [-d directory_name]
[-B batch_size] [-D dataserver:database | -D TNSname]
[-t timeout_in_secs]
Description 1
archive_events removes data from various AutoSys database tables that

are older than the specified number of days. You use this command to
prevent the AutoSys database from becoming full. If the -A option is
used, the data is archived before it is deleted. It is copied into a default
directory unless you specify a different directory with -d option. The -n
option removes events and any alarms associated with them from the
event table. The -j option removes information from the job_runs table.
Because data from both the event and the job_runs tables is used to
generate reports with autorep, we recommend that you always archive
the same number of days of information from both tables. The -l option
removes autotrack information from the audit_info and audit_msg
tables. The -s option removes ServerVision audit information from the
svarchive_tbl table.
In Dual Server mode, the data is archived from both servers at the same
time.

archive_events
If information from these tables is not regularly purged from the

database, the database can fill up rather quickly, stopping all AutoSys
processing. We highly recommend that you run archive_events during
the database maintenance cycle. The DBMaint script, which runs daily by
default, will do this for you.
Data that has been archived with archive_events is no longer accessible

for reports (with autorep) or for simulations with AutoSys/Xpert.
Options 1
-n num_of_days
Indicates that records older than the num_of_days should be deleted
from the event table. The num_of_days value indicates the number of
days of information that should be left in the database. If a row in the
table is as old or older than this value, it will be deleted.
-j num_of_days
Indicates that the information older than the num_of_days should be
deleted from the job_runs table. The num_of_days value indicates the
number of days of information that should be left in the database. If
a row in the table is as old or older than this value, it will be deleted.
-l num_of_days
Indicates that the autotrack information older than the num_of_days
should be deleted from the audit_info and audit_msg tables. The
num_of_days value indicates the number of days of information that
should be left in the database. If a row in the table is as old or older
than this value, it will be deleted.
-s num_of_days
Indicates that the job resource usage information older than the
num_of_days should be deleted from the svarchive_tbl table. The
num_of_days value indicates the number of days of information that
should be left in the database. If a row in the table is as old or older
than this value, it will be deleted.

archive_events
-A
Indicates that information is to be copied to an archive file before
being deleted; otherwise, the information is discarded.
For events, archive_events generates a filename for the file in which

events are stored. This is the file:
archive_events.$AUTOSERV.MM.DD.YYYY
where: MM.DD.YYYY is the date on which the archive_events command
was run.
For job_runs, archive_events generates a filename for the file in

which the job_runs information is stored. This is the file:
archive_job_runs.$AUTOSERV.MM.DD.YYYY
was run.
For autotrack tables, archive_events generates a filename for the file

in which the job_runs information is stored. This is the file:
archive_audit.$AUTOSERV.MM.DD.YYYY
was run.
WARNING • If you run the archive_events command more than
once a day, this file will be overwritten in that 24-hour period.
-d directory_name
Indicates a user-specified directory in which the archived data should
be stored. If this option is omitted, data is archived to the default
directory named $AUTOUSER/archive.
-B batch_size
Specifies the batch size—the number of events to be archived at a
time.

archive_events
For Sybase, the default number of events to archive at one time is 100,
which should be used unless the database is dangerously full and the
transaction log is likely to become full if 100 events are moved at
once. Each transaction (in this case the deletion of a single event) is
recorded in the database’s transaction file, which shares file space with
the actual data. If the data space is almost full, you might want to
remove only a few events at a time. The maximum value is 500.
For Oracle, there is no advantage to specifying a value other than the

default, which is 200.
-D data_server:database
Indicates the name of the Sybase dataserver, and the specific database
within it, from which events are to be archived.
-D TNSname
Indicates the TNS alias name of the Oracle dataserver from which
events are to be archived.
-t timeout_in_secs
Specifies the number of seconds to wait before timing out your SQL
connection. This value is used only by Sybase (Oracle silently ignores
it). When archiving large event tables, set timeout_in_secs to a large
number to prevent your SQL connection from timing out. If the
default setting of 300 seconds is insufficient, increase the setting in
300 second increments. If timeout_in_secs is larger than the
DBLibWaitTime configuration parameter value (in the configuration
file), archive_events will use the new time-out for the current session
only. If -t is not specified, archive_events defaults to 300 seconds,
regardless of the Database Wait Time setting.
Examples 1
1 To copy all events in the events table older than 5 days to the default
archive file, and delete it from the database, enter this:
archive_events -A -n 5

archive_events
2 To copy all job_runs statistics older than 5 days to a specified archive

directory, and delete them from the database, enter this:
archive_events -A -d /my_archive -j 5

autocal
autocal 1
Function 1
Starts the Graphical Calendar Facility.
Syntax 1
autocal
Description 1
The autocal command is used to start up the AutoSys Graphical Calendar

Facility to define and maintain AutoSys calendars. Calendars are lists of
dates that you can use to schedule the days on which jobs should, or
should not, run. You can also start the facility by single-clicking on the
Calendar button from the AutoSys GUI Control Panel, or from the Date/
Time Options dialog in the Job Definition dialog. This facility lets you
define calendars using a point and click approach on different screens
that display a real-world calendar.
The Calendar Facility allows you to do the following:
■ Apply various custom rules to a calendar, such as the “first weekday of

every month,” rather than selecting the individual dates by hand.
■ Block out certain dates, such as holidays, when editing calendars.
■ When applying a rule, select options that will automatically

reschedule conflicting dates—dates which are blocked out but also
meet the qualifications of the rule being applied. A number of
alternatives for rescheduling are also provided.
■ Build a new calendar by overlaying multiple, pre-existing calendars, as

well as letting you perform additional modifications to the new
calendar manually.
■ Preview a calendar before applying it to another calendar.

autocal
Calendars created using the Calendar Facility are actually a collection of

dates which can be referenced in a job definition. Use one of the
following methods to apply a calendar:
■ In the Job Definition Date/Time Options dialog, enter a calendar

name in the Run on Days in Calendar field or the Do NOT Run on
Days in Calendar (Exclude) field.
■ With JIL, enter a calendar name in the run_calendar or

exclude_calendar attribute.
Options 1
None.
Example 1
To start the Graphical Calendar Facility, enter this:

autocal &
See Also 1
Chapter 8, The Graphical Calendar Facility, in the AutoSys User Guide for
UNIX.

autocal_asc
autocal_asc 1
Function 1
Adds, deletes, and prints custom calendar definitions.
Syntax 1
autocal_asc
Description 1
autocal_asc provides a text-based, command line mechanism for

creating, deleting, and printing custom calendars, which may be used to
specify the days on which to start jobs, or days on which a job should not
be started (e.g., holidays). Each calendar has a unique name and a list of
days.
Once created, calendars can be referenced in a job definition. Use one of

the following methods to apply a calendar:
■ In the Job Definition Date/Time Options dialog, enter a calendar

name in the Run on Days in Calendar field or the Do NOT Run on
Days in Calendar (Exclude) field.
■ With JIL, enter a calendar name in the run_calendar or

exclude_calendar attribute.
Whenever a calendar is updated, AutoSys recomputes the starting times

for all jobs which use that calendar.
Options 1
None.

autocal_asc
Example 1
To start autocal_asc to begin entering calendar information, follow these

steps:
1 Enter the following command:
autocal_asc
The following messages will appear:
Utility to Add/Delete or Print entries in Calendar
Calendar Name:
2 At this point you can enter the name of an existing calendar you want
to edit, or the name of a new calendar.
After entering the name, the following message appears:

Add (A) or Delete (D) or Print (P)?
3 If you want to add a date to the calendar, enter this: A
The following prompt appears:

Date (MM/DD/[YY]YY [HH:MM]):
Note • If you enter D to delete, the same prompt appears, and you
can enter the date and time you want to delete from the calendar
definition. If you enter P to print, the screen displays a summary of
the specified calendar.
4 Using the following format, enter the date and, optionally, the time:
MM/DD/[YY]YY [HH:MM]
where: MM is the month, DD is the day, [YY]YY is the year, HH is the hours,
in 24-hour format, and MM is the minutes.
This prompt is repeated as long as dates are entered in response to the

prompt.

autocal_asc
Note • If you enter a two digit year, AutoSys saves the setting to the
database as a four digit year. If you enter 79 or less, AutoSys
prepends 20, and, if you enter 80 or greater, AutoSys prepends 19.
5 To complete the additions, press <Enter> without specifying a date.
This action will also exit the autocal_asc utility.
See Also 1
Chapter 8, The Graphical Calendar Facility, in the AutoSys User Guide for
UNIX.

autocons
autocons 1
Function 1
Starts the AutoSys Operator Console.
Syntax 1
autocons
Description 1
The autocons command starts up the AutoSys Operator Console for

monitoring AutoSys jobs in real-time. You can also start the Console by
single-clicking on the Ops Console button in the AutoSys GUI Control
Panel.
The Operator Console lets you specify job selection criteria, which can be
dynamically changed, to control which jobs you want to view. This
criteria includes the current job state, the job name (with wildcarding),
and the machine on which the job runs. You can select any job and view
more detailed information about it, including its starting conditions,
dependent jobs, and autorep reports. You can invoke the job definition
automatically, allowing you to change the job, if the correct permissions
are set.
The Operator Console also provides an Alarm Manager, which allows the
monitoring of alarms as they are generated. In the Alarm Manager, you
can do the following:
■ Enter responses to alarms.
■ Set the alarm’s state—either acknowledged or closed.
Options 1
None.

autocons
Example 1
To start the Operator Console, enter this:

autocons &
See Also 1
Chapter 10, The Operator Console, in the AutoSys User Guide for UNIX.

autoflags
autoflags 1
Function 1
Prints information about AutoSys and the system configuration.
Syntax 1
autoflags [-a | -i | -o | -d | -v | -r | -h | -n]
Description 1
The autoflags command prints out the AutoSys version and release
number, the database being used, and the operating system. You also use
autoflags to determine the proper hostname and hostid for AutoSys
license key generation.
Options 1
-a
Displays all autoflags information to standard output.
-i
Displays the AutoSys tape ID number to standard output.
-o
Displays the operating system to standard output.
-d
Displays the database type to standard output, either SYB for Sybase
or ORA for Oracle.
-v
Displays the AutoSys version number to standard output.

autoflags
-r
Displays the AutoSys release number to standard output.
-h
Displays the hostid to standard output to standard output.
-n
Displays the hostname to standard output to standard output.
Example 1
To view all AutoSys and system configuration information, enter this:

autoflags -a
An following is an example of the information that would be displayed
to standard output from issuing the command:
3 AIX SYB 3.4 0 c0a9e38d venice

autoping
autoping 1
Function 1
Verifies that the various AutoSys communication facilities are correctly

configured and functioning.
Syntax 1
autoping -m {machine|ALL} [-A] [-D]
Description 1
autoping verifies that the server and client machines are properly
configured and are communicating successfully. It also checks and
verifies that the Remote Agent and the Remote Agent’s database
connection are functioning correctly. If you are running Dual Event
Servers, it checks both database connections. If requested, it generates an
alarm when problems are detected.
Since these client/server communication facilities are critical to AutoSys

functioning, autoping provides valuable information for
troubleshooting, and should always be used early in that process.
When autoping is executed, the server (the machine from which autoping
is issued) establishes a connection with the client machine, which starts
a Remote Agent on that machine, and the server waits for the Remote
Agent to respond. If successful, the following message will be displayed
on standard output at the server:
AutoPinging Machine[machine]
AutoPing WAS SUCCESSFUL!

autoping
If there is a problem with the configuration, a message indicating that the

remote machine has not responded (or that there is a more serious
problem, such as a socket read error) will be displayed. Most of the time,
these problems have to do with the improper installation of the Remote
Agent with regard to the configuration of the internet daemon (inetd).
If the -D argument is used, autoping attempts to connect to the database

and displays the resultant output to the screen. It includes the output in
the alarm, if one was generated with the -A argument. If you are running
Dual Event Servers, both databases are checked.
You can issue autoping from any machine on which the autoping
executable resides. The target can be any Remote Agent machine.
Options 1
-m machine|ALL
The name of the machine to be verified. This must be a real machine,
and must be listed in the /etc/hosts file on the machine from which
the command is issued. ALL checks all machines.
Note • In order to use the -m ALL option, you must first define
machines to the database using the insert_machine command. If
you do not define the machines, autoping will display the following
message:
Could not get list of machines from Database.
-A
Send an alarm if problems are detected.
-D
Check the database connections on the specified machine(s).

autoping
Example 1
To check whether the machine “venice” is properly configured for

AutoSys, and that its Remote Agent can function properly, enter this:
autoping -m venice
If successful, the following will display:
AutoPinging Machine [venice]
AutoPing WAS SUCCESSFUL!
To check all machines and verify their database access, enter this:
autoping -m ALL -D
If successful, the following will display:
AutoPinging Machine [venice] AND checking the Remote Agent’s DB
Access. AutoPing WAS SUCCESSFUL!
AutoPinging Machine [rome] AND checking the Remote Agent’s DB
Access. AutoPing WAS SUCCESSFUL!

autorep
autorep 1
Function 1
Reports information about a job, jobs within boxes, machines, and

machine status. Also reports information about job overrides and global
variables.
Syntax 1
autorep {-J job_name | -M machine_name | -G global_name}

[-s | -d | -q | -o over_num] [-r run_num][-L print_level] [-t]
[-D data_server:database | -D TNSname]
Description 1
autorep lists a variety of information about jobs, machines, and global

variables currently defined in the AutoSys database. You can use it to list
a summary of all currently defined jobs, or to display current machine
load information. autorep serves as a problem tracking tool by listing all
relevant event information for the last run of any given job, or a specified
job run. You can also use it to extract job definitions in JIL script format
and save them to an output file for later re-loading into AutoSys, as a
means of backing up job definitions.
autorep retrieves data from the AutoSys database to formulate the

reports. Any data that has been archived with archive_events will not
appear in the reports.
When listing nested jobs, subordinate jobs are indented to illustrate the
hierarchy. The following sections describe the types of autorep reports.
Job Run Summary

When a summary is requested, autorep prints the current status, if the job
is still running, or the status for a previous run. The summary report
reflects the last status posted to the AutoSys database.

autorep
Job Run Detail

When detail is requested, autorep prints all events for the job that are
recorded in the event table in the AutoSys database. If the job is running,
it posts events for the current run. If the job is not running, it posts events
for the most recent run, or, if requested, a previous run.
Machine Definition and Status in the Database

For all machines defined to AutoSys, you can use autorep to examine the
current load and the defined maximum load and factor.
Job Override Information

autorep can print information for a specified override, based on job
name and override number. In addition to the overridden job definition
fields, it also displays user, time and run information.
Columns in the autorep Report

The columns in an autorep report vary with the type of report requested.
The following table describes the columns.
Job Name Name of job.
Last Start Date and time of the most recent start of the job.
Last End Date and time of the most recent completion of the
job.
ST The completion status of the most recent run of the

job, or, if the job is still running, the current status.
Note • The completion status is shown in an
abbreviated format. For information, see the next
section, Status Abbreviations.
Run Job run number and number of tries, separated by a

slash ( / ). For information, see Job Run Numbers and
Names in Chapter 3, AutoSys Jobs.

autorep
Pri/Xit Priority/Exit code. If the job is in QUE_WAIT status,

this column shows the priority in the queue; if the
job completed, this column shows the exit code.
Status/[Event] Status for the current run of the job.
Time Time stamp when the change status event was

generated by the Event Processor or Remote Agent.
Ntry Number of restart attempts for the listed event.
ES Processing state of the status (event).

Note • The completion status is shown in an
abbreviated format. For information, see the next
section, Event State Abbreviations.
Process Time Time stamp when the change status event was
processed by the Event Processor (the effective state
change).
Machine Name of the machine the job was run on or is

running on.
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.
Abbreviation Status (Event)
AC ACTIVATED
FA FAILURE
IN INACTIVE
OH ON_HOLD
OI ON_ICE

autorep
Abbreviation Status (Event)
QU QUE_WAIT
RE RESTART
RU RUNNING
ST STARTING
SU SUCCESS
TE TERMINATED
Event State Abbreviations

The following table lists the abbreviations used in the ES (event state)
column of the autorep report, and gives the status for each abbreviation.
Abbreviation Event State
ER Error
PD Processed
PG Processing
UP Unprocessed
US Unsent

autorep
Options 1
-J job_name
Indicates that a Job Report is desired. job_name specifies the name of
the job on which to report. Any valid AutoSys job name may be
specified. To report on all jobs, specify ALL. The “%” character may be
used in the job name as a wildcard (e.g., %box% will select all jobs
containing the string “box”).
Note • The “_” character may also be used as a wildcard to match

exactly one character. However, this can lead to some unexpected
results when the job name itself contains a “_” character. For
example, specifying the job name “mon_%” will select all jobs
beginning with the string “mon”, such as mon_box, monet, and so
on.
The SQL ESCAPE option is not supported for wildcards in AutoSys.
-M machine_name
Indicates that a Machine Report is desired, which lists the machine’s
Max Load, Current Load, and Factor. machine_name specifies the
machine on which to report. This may be a virtual machine, a real
machine, or ALL for all machines; the machine must be defined to
AutoSys.
-G global_name
Indicates that a global variable report is desired, listing the variable
name, value, and last modification date. global_name specifies the
name of a global variable that has been set using the sendevent
command or the Send Event dialog. In the specification, you can use
ALL or wildcard characters.
-s
Indicates that a Summary Report is desired. This is the default.

autorep
For a Job Report, the following information is provided: Start date/

time, End date/time, Current Status, Run Number, and Priority. You
can request a report on a specific job run with the -r option. If the -r
option is omitted, the most current job run is used.
For a Machine Report, the following information will be provided for

each specified machine: Machine Name, Max Load, Current Load, and
Factor.
For a Global Variable Report, this option is ignored.

-d
Indicates a Detail Report is desired.
For a Job Report, all events from the last run of the requested job will
be listed. For each event, the following data is provided: Status, Date/
Time, Try Number, Event State (whether the event has been processed
by the Event Processor yet), Process Date/Time, and the Machine on
which the job was run. Also specifies if a job was run with an override
and lists the override number.
For a Machine Report, the following information will be provided for

each specified machine: Machine Name, Maximum Load, Current
Load, and Factor. In addition, for any jobs currently running on the
specified machine(s), the following information will be provided: Job
Name, Machine, Status, Load, and Priority.

-q
Indicates a Query Report is desired, providing the current job or
machine definition, in JIL format, as it exists in the AutoSys database.

-o over_num

autorep
Indicates an Override Report is desired, providing the overrides for the

specified override number (over_num) and job_name. If the most
current override is desired, the value of over_num should be zero. The
job attributes and their associated overrides are displayed to standard
output. You must supply a job name (-J job_name) with this option.
-r run_num
Indicates a report is desired for a specific job run (run_num). This
option can only be used with the -s and -d options. If this option is
omitted, or run_num is zero, the most current job run is reported. A
minus sign (-) can be used before the run_num value to indicate a
relative counter for a past job run, relative to the current run number.
For example, the option -r -2 would generate a report for the job run
two runs back.
-t
Requests that the time zone, if one is specified in the job definition,
appear in the report. If requested, the time zone will appear in
parentheses beneath the job name and the Time column of the report
will be based on the specified time zone.
-L print_level
(Job reports only.) Indicates the number of levels of nesting for boxes
for which the specified information should be listed. For example, a
level of 2 means list the information for the specified job (a box) as
well as two levels of jobs within that box.
This value may be any valid numeric value; to list the outermost box
alone, specify “0”. The default is to list all levels within the box.
within it, to be searched for the specified information. Normally,
autorep consults the AutoSys configuration file ($AUTOUSER/
config.$AUTOSERV) to determine which database to connect to. This
option enables autorep to report on any AutoSys Event Server on the
network.

autorep
-D TNSname
Indicates the TNS alias name of the Oracle dataserver to be searched
for the specified information. Normally, autorep consults the AutoSys
configuration file ($AUTOUSER/config.$AUTOSERV) to determine which
database to connect to. This option enables autorep to report on any
AutoSys Event Server on the network.
Examples 1
1 The following summary report is for a run of the Nightly_Download

example, whose JIL script is provided at the end of Chapter 7, Defining
Jobs Using JIL, of the AutoSys User Guide for UNIX. This is the command
that requests the report:
autorep -J Nightly_Download
Job Name Last Start Last End ST RunPri/Xit

________________ _____________________________________ _________
Nightly_Download 11/10/1997 17:0011/10/1997 17:52SU 101/1

Watch_4_file 11/10/1997 17:0011/10/1997 17:13SU 101/1
filter_data 11/10/1997 17:13 11/10/1997 17:24SU 101/1
update_DBMS 11/10/1997 17:24 11/10/1997 17:52SU 101/1

autorep
2 The following is the detail report that shows each event and status for
each job. This is the command that requests this report:
autorep -J Nightly_Download -d
Job Name Last Start Last End ST Run Pri/Xit

________________ ____________________________________________________
Nightly_Download 11/10/1997 17:00 11/10/1997 17:52SU 101/1
Status/[Event] Time Ntry ES ProcessTime Machine

-------------- -------------------------------------------------------
RUNNING 11/10/1997 17:00:12 1 PD 11/10/1997 17:00:17
SUCCESS 11/10/1997 17:52:31 1 PD 11/10/1997 17:52:32
Watch_4_file 11/10/1997 17:00 11/10/1997 17:13 SU 101/1

-------------- -------------------------------------------------------
STARTING 11/10/1997 17:00:13 1 PD 11/10/1997 17:00:19
RUNNING 11/10/1997 17:00:19 1 PD 11/10/1997 17:00:29 gateway
SUCCESS 11/10/1997 17:13:22 1 PD 11/10/1997 17:13:31
filter_data 11/10/1997 17:13 11/10/1997 17:24 SU 101/1

-------------- -------------------------------------------------------
STARTING 11/10/1997 17:13:32 1 PD 11/10/1997 17:13:34 gateway
SUCCESS 11/10/1997 17:24:23 1 PD 11/10/1997 17:24:30
update_DBMS 11/10/1997 17:24 11/10/1997 17:52 SU 101/1

-------------- -------------------------------------------------------
STARTING 11/10/1997 17:24:16 1 PD 11/10/1997 17:24:22 gateway
SUCCESS 11/10/1997 17:52:23 1 PD 11/10/1997 17:52:31
In the above example report, Nightly_Download is a box job.

Therefore it does not enter the “Starting” state, but goes directly to the
“Running” state. Box jobs do not list an associated machine, because
the jobs in boxes may execute on different machines.

autorep
3 The following is an example of a detailed report for one run back. This
is the command that requests this report:
autorep -J RunData -d -r -1

_____________ ________________________________________________________
RunData 08/15/1997 12:14 08/15/1997 12:15 FA 2565/11

-------------- -----------------------------------------------------
STARTING 08/15/1997 12:14:56 1 PD 08/15/1997 12:15:00 venice
RUNNING 08/15/1997 12:14:58 1 PD 08/15/1997 12:15:05 venice
FAILURE 08/15/1997 12:15:00 1 PD 08/15/1997 12:15:05
[*** ALARM ***]
JOBFAILURE 08/15/1997 12:15:04 1 PD 08/15/1997 12:15:10 venice
[STARTJOB] 08/15/1997 12:15:38 0 PD 08/15/1997 12:15:46
4 The following example lists all machines defined on the dataserver.

This is the command that request this report:
autorep -M ALL
Machine Name Max Load Current LoadFactor O/S

_______________ ________ __________________ _____
london 100 0 1.00 Unix

berlin 90 0 0.90 NT
v_italy.rome 0 0 0.00 Unix
v_italy.venice 0 0 0.00 Unix
v_france.paris 100 0 1.00 NT
v_france.cannes 75 0 1.00 NT

autorep
5 The following is an override report, showing the current one-time job

override in effect for the job. This is the command that requests this
report:
autorep -J RunData -o 0
/* -------------------- over -------------------- */
override_job: RunData
/* Over-Ride #2 Set by User: roger@venice on [07/28/1997 16:13:59] */
/* Over-Ride CURRENTLY IN EFFECT.*/
command: /bin/rundata2
6 The following is an override report, showing the first one-time job

override for the job. This is the command that requests this report:
autorep -J RunData -o 1
/* -------------------- over -------------------- */
override_job: RunData
/* Over-Ride #1 Set by User: roger@venice on [07/25/1997 18:23:45] */
/* Was RUN on run_num=175, Started on: 07/25 18:24:01 */
command: /bin/rundata1
7 To list the value of a specific variable, specify the variable using the -G
option, as shown in the following example:
autorep -G DAY
The output from this command would look similar to the following:
Wednesday
8 To list the value of all global variables that have been set, enter this:
autorep -G ALL

autorep
The output from this command would look similar to the following:
Global Name Value Last Changed
------------ ------------ -------------------
DAY Wednesday 11/12/1997 12:18:27
AUDIT_DIR /usr/audit 11/12/1997 12:41:00
DINNER_TIME 18:30 11/12/1997 12:40:00
MAX_VAL 2048 11/12/1997 12:30:24
9 To list a summary report on the top two levels of boxes in the job
named “Box3”, enter this:
autorep -J Box3 -s -L 2
10 To include the time zone specification in a detailed report for the last
run of the job named “MyJob”, enter this:
autorep -J MyJob -d -t
When you use the -t option, the time reported in the Time column is
translated to the time zone specified in the job definition. The time
reported in the ProcessTime column is not affected by the -t option.
It shows the time the Event Processor processed the events (server
time).
The output from this command would look similar to this:

_____________________________ _________________ _______ _____ _______
MyJob 12/10/1997 17:30 12/10/1997 17:30 SU 102/1
(Chicago)

-----------------------------------------------------------------------------
STARTING 12/10/1997 17:30:05 1 PD 12/10/1997 16:30:13 localhost
RUNNING 12/10/1997 17:30:08 1 PD 12/10/1997 16:30:13 localhost
SUCCESS 12/10/1997 17:30:10 1 PD 12/10/1997 16:30:13
[STARTJOB] 12/10/1997 17:30:00 0 UP
<Event was Scheduled based on Job Definition.>

autorep
11 You can use the autorep command to extract job definitions in JIL
script format and direct the output to a file. The following example
shows how to save all job definitions to a file.
autorep -J ALL -q > dump_file
The output of this command is formatted exactly as a JIL job

definition script, like this:
insert_job: test_job
job_type: c
command: sleep 60
machine: juno
#owner: jerry@jupiter
permission: gx,ge,wx
alarm_if_fail: 1
Note • The owner field of each job definition is commented out

unless the Edit Superuser ran the autorep command to generate
this report. Only the Edit Superuser can change the owner field.
You can save this file as a backup of job definitions, or you can use a
text editor to quickly edit the job definitions. To re-load the job
definitions into the AutoSys database, using the following jil
command:
jil < dump_file

autosc
autosc 1
Function 1
Starts the AutoSys Graphical User Interface (or GUI) and displays the
GUI Control Panel.
Syntax 1
autosc
Description 1
autosc starts up the AutoSys graphical user interface. From the GUI
Control Panel, you can open applications and dialogs to define jobs,
monitors, reports (browsers), and custom run or exclude calendars, as
well as access the Operator Console. If AutoSys/Xpert has been installed
and activated with keys, you can display any of the AutoSys/Xpert
interface windows from the GUI Control Panel. These windows include
HostScape, JobScape, or TimeScape.
Options 1
None.
Example 1
To start the AutoSys Graphical User Interface, you enter:

autosc &
See Also 1
Chapter 6, Defining AutoSys Jobs Using the GUI, Chapter 10, The Operator
Console, and Chapter 11, Monitoring and Reporting Jobs, in the AutoSys User
Guide for UNIX.

autostatus
autostatus 1
Function 1
Reports the current status of a specific job, or the value of an AutoSys

global variable.
Syntax 1
autostatus {-J job_name | -G global_name} [-S autoserv_instance]
Description 1
autostatus writes the current status of the specified job or the current
value of a global variable to standard output. This facility is especially
useful in two circumstances:
■ When an application needs to know the status of another job.
■ When complex starting conditions are required that are beyond the
scope of the starting conditions that can be easily specified in the job
definition.
As an example of the latter situation, a job may need to be started when

two out of a set of three jobs have completed successfully. This situation
could be encoded by way of the starting conditions, but the conditions
would be very cumbersome to define. Instead, you could use autostatus
in a shell script to check the status of these jobs, and perform the
appropriate action. A detailed description of this is given in the Examples
section, below.

autostatus
Options 1
-J job_name
Specifies the name of the job whose status needs to be determined.
The current status is returned to standard output.
-G global_name
Specifies the name of a global variable that has been set using the
sendevent command or the Send Event dialog. The value of the global
variable is returned to standard output.
-S autoserv_instance
Specifies the three-character code of the AutoSys instance to be
queried. The default is the value of $AUTOSERV from the current
environment.
Examples 1
1 To check the current status of the job named “test_install” in the

current instance of AutoSys, enter this:
autostatus -J test_install
A one-word response to this command displays on standard output,
such as the following:
SUCCESS
2 This example shows how to use autostatus in place of a cumbersome
condition statement. Assume a job named “New_Stats” is dependent
on the jobs named “Account_Run”, “Corp_Run”, and “End_Run”.
“New_Stats” is to be run when all three of these jobs have run, at least
two jobs have completed successfully, and it is not the 13th day of the
month. These conditions are too complex to be specified as
“New_Stats” starting condition, so autostatus should be used in a
shell script to specify these conditions. To implement this, you would
perform the following steps.

autostatus
a Create a job named “New_Stats_Starter” with the following job

definition:
#
# JIL for New_Stats_Starter
#
insert_job: New_Stats_Starter
job_type: command
machine: mombo
command: new_stats_starter
condition: done(Account_Run) and
done(Corp_Run) and done(End_Run)
b Create a Bourne shell script with the name “new_status_starter” to
run for the job named “New_Stats_Starter”. This script will
determine if the job “New_Stats” should be started. It
communicates its decision back to AutoSys by exiting with a “0”
(SUCCESS) or non-zero (FAILURE) exit code. The job named
“New_Stats” bases its starting condition on that exit code.
#!/bin/sh
#
# Program to determine when to start New_Stats
# Check for 13th of month - if it is, exit
# with 2
if [ ‘date +%d‘ -eq 13 ]
then
exit 2
fi
# Add up the Number of SUCCESS endings
SUCCESS=0
for JobName in Account_Run Corp_Run End_Run
do

autostatus
if [ ‘autostatus -J $JobName‘ = "SUCCESS" ]

then
SUCCESS=‘expr $SUCCESS + 1‘
fi
done
if [ $SUCCESS -gt 1 ]
then
exit 0
else
exit 1
fi
Note • To reference jobs running on other instances of AutoSys,

the $AUTOSERV for that instance needs to be supplied in the call to
autostatus.
c Create the job named “New_Stats” and specify that it should start
when the above job completes successfully. Use the following
starting condition as its job definition:
condition: success(New_Stats_Starter)
3 To check the value of a global variable named “Today”, enter this:
autostatus -G Today

autosyslog
autosyslog 1
Function 1
Displays the Event Processor and Remote Agent log files.
Syntax 1
autosyslog [-e | -J job_name] [-p]
Description 1
autosyslog is used to view either the Event Processor log file or the
Remote Agent log file for the specified job. Both the Remote Agent and
Event Processor write diagnostic messages to their respective logs, as part
of their normal operations and in response to detected error conditions.
autosyslog provides useful troubleshooting information because the

Event Processor logs all events it processes and provides a detailed trace
of its activities. If AutoSys appears to be behaving abnormally, these logs
are the first places you should look.
Using autosyslog to view the Event Processor log is the same as issuing
the following command:
tail -f $AUTOUSER/out/event_demon.$AUTOSERV
The last ten lines of the Event Processor log file are displayed when the
autosyslog command is issued. The log file is updated continually as
processing occurs. To terminate the display of the log, press <Control+c>
in the display window.

autosyslog
Remote Agent log

The autosyslog utility can be a useful diagnostic tool when jobs fail. This
command, when provided with the name of a job, displays the log of the
job’s most recent run. Although the Remote Agent’s log file is
automatically deleted by default after a successful job run, the log file will
not be deleted at job completion if the job ended with a FAILURE status.
Event Processor Log

The Event Processor log contains a time-stamped history of each event
that occurs. Viewing this log is an alternative to monitoring “all jobs” and
“all events”.
Options 1
-e
Indicates that the Event Processor log is to be monitored. When in this
mode, in order to terminate the command, you must press
<Control+c>.
Note • To view the Event Processor log, you must execute this
command on the machine that is running the Event Processor, or
on a machine that can access the same $AUTOUSER file system. Also,
the $AUTOUSER and $AUTOSERV environment variables must be set the
same as it was when the Event Processor was run.
-J job_name
Indicates that the Remote Agent log for the specified job_name is to be
viewed. You must issue this command on the machine where
job_name ran. Otherwise, the following message will display:
*** No remote agent files found for job_name job_name***

autosyslog
Note • To view the Remote Agent log, you must execute this
command from the machine on which the specified job ran last.
-p
Specifies to append messages to the output file if anything in the
profile file failed, if commands were not executed, or environment
variables or definitions were not set. For example, if the profile file
tried to execute a command (e.g., date) but could not find it, the
output file would contain the line:
/bin/sh: date: not found
The -p option must be used with the -J job_name option.
Note • If the CleanTmpFiles parameter in the AutoSys

configuration file is “on,” AutoSys removes the Remote Agent log
file upon successful completion of the job. Therefore, if this
parameter is set to “on,” the autosyslog command will not able to
display the log contents of jobs that completed successfully—these
log files will not exist.
Examples 1
1 To view the Event Processor log, enter this on the command line of the
system where the Event Processor is running, or where it ran last:
autosyslog -e
You can enter this command on any machine that can access the same
file system (i.e., $AUTOUSER) as the Event Processor.
2 To view the Remote Agent log of the last run of the “test_install” job,
you would issue the following command on the command line of the
machine where the “test_install” job ran:
autosyslog -J test_install

autosyslog
3 To view the output file with profile information, enter this:
autosyslog -j job_name -p
This command will display the log file first, appending the profile
output, if there is any. If no profile output file exists, the profile output
section will be empty, for example:
---------------------------------------------------
OutPut from File: auto_rem_pro.491.216.1
---------------------------------------------------
---------------------------------------------------

autosys_secure
autosys_secure 1
Function 1
Maintains the AutoSys Edit and Exec superuser ownerships, remote

authentication methods and AutoSys database password. Also maintains
NT user IDs and passwords, which are required for AutoSys jobs to run
on NT client machines.
Syntax 1
autosys_secure
Or
autosys_secure [-q] {-a | -c | -d} -u user@host_or_domain
[-o old_password] -p password
Description 1
You use the autosys_secure command to specify the AutoSys Edit

Superuser and Exec Superuser, the AutoSys database password, remote
authentication method, and NT user IDs and passwords.
Edit Superuser and Exec Superuser

Two AutoSys users have administrator privileges: the Edit Superuser and
the Exec Superuser.
The Edit Superuser is the only user with permission to:
■ Edit or delete any AutoSys job, regardless of who owns it and what
permissions are set for it.
■ Change the owner of an AutoSys job.
■ Change the AutoSys database password, remote authentication

method, and NT user passwords.

autosys_secure
For details on NT user passwords, see the autosys_secure section in

Chapter 1, AutoSys Commands in the AutoSys Reference Guide for
Windows NT. For a discussion on AutoSys security, see Chapter 2, AutoSys
Security, in the AutoSys User Guide for UNIX.
The Exec Superuser is the only user with permission to:
■ Issue start or kill any AutoSys job, regardless of the execution

permissions on the specified job. This user can affect how jobs run,
typically by issuing the sendevent command.
■ Shut down the Event Processor (by sending the STOP_DEMON

event).
AutoSys Database Password

The AutoSys database password is used by the AutoSys Event Processor,
GUIs, and command-line utilities to securely access the AutoSys database
(Event Server). By default, this password is stored in the AutoSys database
as autosys, but you can change it using autosys_secure.
Every Event Server in an AutoSys instance must have the same AutoSys
database password. If you are running in Dual Server mode,
autosys_secure changes the password on both Event Servers.
WARNING • If you have rolled over to Single Server mode, do not

change the password until you have established Dual Server mode again.
Remote Authentication Method

Remote authentication methods are used to verify one or both of the
following:
■ A user has permission to start a job on an AutoSys client machine.
■ An Event Processor has permission to start a job on an AutoSys client

machine.
The remote authentication methods are stored in the AutoSys database

and are referenced when an AutoSys client initializes.

autosys_secure
Running autosys_secure 1
Before using autosys_secure to change the AutoSys database password or

the remote authentication method, you must shut down all AutoSys
processes that access the database (e.g., Event Processor, GUIs, Remote
Agent). Also ensure no AutoSys jobs are running.
Running autosys_secure in Interactive Mode

When the Edit Superuser invokes autosys_secure, this menu displays:
AutoSys Security Utility.
Please select an action to perform:
[1] Change AutoSys EDIT and EXEC superusers.
[2] Change AutoSys database password.
[3] Change AutoSys remote authentication method.
[4] Create AutoSys User@Host or Domain password.
[5] Change AutoSys User@Host or Domain password.
[6] Delete AutoSys User@Host or Domain password.
[7] Exit autosys_secure.
When a user other than the AutoSys Edit Superuser invokes autosys_secure,
the following menu displays:
AutoSys Security Utility.
Only the AutoSys EDIT superuser has access to all options!
Please select an action to perform:
Options 1 thru 4 for superusers only
[5] Change AutoSys User@Host or Domain password.
[6] Delete AutoSys User@Host or Domain password.
[7] Exit autosys_secure.

autosys_secure
Any user that knows an existing user ID and password combination can
change the password or delete the user from the AutoSys database.
Running autosys_secure from the Command Line

You can run autosys_secure from the command line to enter, change, or
delete NT user IDs and passwords. This option allows you to write
interactive programs, scripts, or batch files to enter or modify large
numbers of user IDs and passwords, if necessary. To do this, you can use
any scripting language, such as NT Batch or Perl (Perl is shipped with
AutoSys for Windows NT).
To print the usage statement for the command-line options to the screen,
enter this command:
autosys_secure -h
This is the autosys_secure command-line syntax:

autosys_secure [-q] {-a | -c | -d} -u user@host_or_domain
[-o old_password] -p password
For more information on the command-line options, see Options on
page 1-51.
Edit and Exec Superusers

The first time option [1] in the autosys_secure menu is chosen after
AutoSys is installed, you are prompted for the names of the users who
should be assigned the Edit Superuser and Exec Superuser privileges.
Both these privileges can be assigned to the same user. These users must
be valid users on the host or domain that you are logged onto.
After the initial assignments, only the Edit Superuser can change these
assignments. Option [1] displays the current settings and allows the Edit
Superuser to accept the same users by pressing <Enter>, or change the
users by entering a new specification.

autosys_secure
AutoSys Database Password

Option [2] in the autosys_secure menu displays a prompt at which you
can change the AutoSys database password. This option changes the
database password for the “autosys” user. By default, the password is
“autosys”.
Only the AutoSys Edit Superuser can change the AutoSys database
password. The password must be between six and twenty characters in
length. It can contain upper- and lowercase alpha characters, numbers,
and punctuation marks; it cannot contain single or double quotes,
spaces, or control characters.
Note • For bundled Sybase only, the “sa” system administrator user
password is “sysadmin” by default. To change the password for the
“sa” user, use the xql utility, described on page 1-124.
Remote Authentication Methods

Only the AutoSys Edit Superuser can change the remote authentication
method. When option [3] in the autosys_secure menu is chosen, the
following menu displays.
Current remote authentication method:
No remote authentication.
Please select a remote authentication method:
[1] No remote authentication.
[2] Unix ruserok authentication only.
[3] AutoSys event processor authentication only.
[4] Both Unix and AutoSys authentication methods [2]&[3]).
No Remote Authentication
When this option is selected, the remote authentication feature is
disabled.
Unix ruserok Authentication Only

When this option is selected, remote authentication will be
accomplished by telling a client’s Remote Agent to make the UNIX
system call named ruserok(). This function checks both the client

autosys_secure
machine’s /etc/hosts.equiv and the user’s .rhosts files to validate that

the requesting user is registered in that environment. This function call
performs a “local” verification, and it is not related in any way to rshd or
rlogind.
On Windows NT, Remote Agent user authentication is enabled using the

Security settings in the AutoSys Administrator For a description of
Remote Agent user authentication on an NT machine, see the AutoSys
User Guide for Windows NT.
Note • The Edit Superuser can override this type of remote

authentication by changing the ownership of a job from the form
user@machine to the form user. As a result, remote authentication on
the job on the target machine at execution time is not performed.
AutoSys Event Processor Authentication Only

When this option is selected, remote authentication will be
accomplished by binding a specific Remote Agent to one or more Event
Processors. This means a Remote Agent must verify that it has permission
to process an Event Processor’s requests before starting each job.
On UNIX, the Event Processor reads the /etc/.autostuff file on the

machine on which the Remote Agent is running. On Windows NT, the
Event Processor checks the list of Authorized Event Processor Host
Names in the Remote Agent screen of the AutoSys Administrator on the
machine on which the Remote Agent is running.
Note • Before activating Event Processor authentication, you must set

up and properly configure the /etc/.autostuff file on every client
machine that will participate in this authentication method, as
described in the Configuring Remote Authentication section of Chapter 13,
Configuring AutoSys, in the AutoSys User Guide for UNIX.

autosys_secure
Both Unix and AutoSys Authentication Methods

When this option is selected, both the UNIX ruserok() and the AutoSys
Event Processor authentication methods will be used. If this option is
enabled, both methods of authentication must succeed for the job to run.
Options 1
-h
Displays help. Use this option to get help on the autosys_secure
command-line options.
-q
Specifies to run in quiet mode and not print any messages to the
screen. When run in quiet mode, autosys_secure will not print any
error messages. You can, however, check the return code to see if there
were any run errors. To check the return code, enter a command
similar to the following:
csh echo $status
sh or ksh echo $?
If autosys_secure is successful, the return value is 0; and if it is

unsuccessful, the value is 1.
-a
Specifies to add a user ID and password. You must also supply the -u
and -p options.
-c
Specifies to change an existing user password. You must also supply
the -u, -o, and -p options.

autosys_secure
-d
Specifies to delete an existing user password. You must also supply the
-u and -o options.
-u user@host_or_domain
Specifies the NT user whose password you are entering. NT user names
can be from 1 to 20 characters in length and can contain all characters
except the following:
*[]+:;"<>.,?/\|
-o old_password
Specifies the password for an existing user. If you are changing a
password or deleting a user ID and password, you must supply this
option. If the password is NULL, enter NULL.
-p password
Specifies the password for the user@host_or_domain that you want
entered in the AutoSys database. If you are adding a user or changing
a password, you must supply this option. NT passwords can be a
maximum of 14 characters in length. Passwords are case-sensitive and
may contain any character except a space. NULL passwords are
accepted. To specify a NULL password, enter NULL.
Example 1
To start autosys_secure in interactive mode, enter this:

autosys_secure
The autosys_secure options display.

autotimezone
autotimezone 1
Function 1
Allows additions, deletions, and queries to the timezones table.
Syntax 1
autotimezone [-a entry_name value] [-c entry_name value]

[-t timezone_name] [-d entry_name] [-q entry_name | sql_pattern]
[-l]
Description 1
autotimezone lets you query the timezones table, and add and delete
timezones table entries. The timezones table contains entries that you
can specify in a job definition using the timezone attribute, documented
in Chapter 2, JIL/GUI Job Definitions.
The timezones table maps cities and common aliases to valid POSIX TZ
environment variables. The table contains entries for all the common
time zones that are recognized by most operating systems, as well as
many cities in the world.
The AutoSys timezones table has three entry “Types,” Zone, Alias, and
City, as shown in the following excerpt from the timezones table:
Entry Type Zone
---------------------- ------ ----------------
US/Pacific Zone PST8PDT

US/Samoa Alias Pacific/Samoa
UTC Alias GMT+0
Vancouver City Canada/Pacific

autotimezone
All “Alias” and “City” Types are eventually resolved to “Zone” Types. The
“Zone” Types resolved to TZ Variables (in the Zone column) that
correspond to those recognized by the operating system for the machine
on which the Event Server is running. For details on the format of the TZ
variable, refer to your system ctime, timezone, or environ man page.
When processing a job definition that includes a time zone, AutoSys first
tries to resolve the specified time zone using the zones known to the
operating system. If it is not found there, AutoSys looks up the zone in
the timezones table. If the time zone specification is not a TZ Variable
(i.e., a “Zone” Type), the timezones table will be read multiple times
until it resolves to a TZ Variable. For example, assume a job definition
included the attribute timezone:Berlin. Berlin would be resolved to
Europe/Berlin the first time the table was read. The second time the table
was read, Europe/Berlin would be resolved to METS-1METD, which is a
TZ Variable. If a time zone is not resolved within five lookups, it is
considered invalid and the job specifying the time zone will fail.
WARNING • If you change the timezones table, be sure you do not
change or delete entries that are used by pre-existing STARTJOB and
other events that were scheduled using the old timezones table.
Options 1
-a entry_name value
Adds an Alias entry to the timezones table. An Alias entry associates a
name with a time zone. For example, you could alias “US/Mountain”
to “MST.” entry_name is a string between 1 and 50 characters; and can
include upper- or lowercase letters, digits, slash ( / ), hyphen ( — ),
and underscore ( _ ). value must correspond to a time zone
recognized by the operating system. Use spaces to separate the
entry_name and the value.

autotimezone
-c entry_name value
Adds a City entry to the timezones table. A City entry is a type of Alias
that maps a city to a time zone. Entries added to the table via the -c
argument will display as type “City” in a listing of the timezones table.
See the -a argument, above, for a description of entry_name and
value.
-t timezone_name
Adds a time zone entry to the timezones table. A Zone entry must be
of the format of a valid POSIX standard timezone (TZ) environment
variable.
-d entry_name
Deletes an entry from the timezones table.
-q entry_name | sql_pattern
Queries the timezones table for the setting of a specific alias, city, or
zone. Queries are case insensitive, and you can use the wildcard
character ( % ) or the SQL underscore.
-l
Lists all entries in the timezones table.
Examples 1
1 The following command adds a city named “San-Jose” to the

timezones table:
autotimezone -c San-Jose US/Pacific
2 The following command deletes the city named “San-Jose” from the
timezones table:
autotimezone -d San-Jose

autotimezone
3 The following command queries the timezones table for all entries
beginning with the letter “d”:
autotimezone -q d%
The output from this command would be similar to the following:

Entry Type Zone
--------------------------------------
Dallas City US/Central
Denver City US/Mountain
Detroit City US/Central

autotrack
autotrack 1
Function 1
Tracks and reports changes to the AutoSys database.
Syntax 1
autotrack [-D data_server:database | -D TNSname] [-u 0|1|2] [-l]

[-h|H] [-v] [-F "from_time"] [-T "to_time"] [-U user_name]
[-m machine] [-J job_name] [-t A|B|C|J|M|O|S|T]
Description 1
autotrack tracks changes to the AutoSys database (e.g., job definition

changes, sendevent calls, and job overrides) and writes this information
to the database. When you query for this information, autotrack prints
a report to the screen, or you can use standard UNIX file redirection to
save the output to a file. autotrack can track changes to job definitions,
both from JIL or the GUIs. Changes made directly to the database via SQL
commands cannot be tracked.
This facility is especially useful for:
■ Sites desiring careful monitoring of the job definition environment.
■ Sites where multiple users have permission to edit job definitions or

send AutoSys events.
To start tracking, use the autotrack -u command to set the tracking level
to 1 or 2, depending on the amount of detail you want tracked. By
default, autotrack is set to level 0 (no tracking). autotrack -l lists the
current tracking level.
Note • Only the AutoSys Exec or Edit Superuser can change the
tracking level.

autotrack
Use the autotrack command with one or more query options (-J, -U, -m,
-F, -T, and -t) to request reporting on a specific job, user, machine, time
window, or event type.
Typing autotrack with no arguments retrieves information on all events,

but omits the detail.
Type autotrack -h or autotrack -H to display the usage summary.
For sample autotrack output, see Examples on page 1-62.
autotrack output is stored in two tables: audit_info and audit_msg. By

default, these tables reside in the same database (or tablespace) as all
other AutoSys tables. You might want to relocate these tables to another
database (or tablespace) to insulate event processing from an auditing
table overflow. If you frequently unload all your jobs from the database
and reload, you should turn off autotrack temporarily to prevent the
database from growing unnecessarily large. For example:
autotrack -u 0
jil -V none < whole_thing.jil
autotrack -u 1
Running archive_events will help prevent the database from filling up
with autotrack output. The archive_events -l num_of_days command
archives information from the audit_info and audit_msg tables older
than the specified number of days.
Options 1
autotrack consults the environment variables and the AutoSys
configuration file to determine to which database to connect. This
option enables autotrack to report on any AutoSys Event Server on
the network.

autotrack
-D TNSname
for the specified information. Normally, autotrack consults the
environment variables and the AutoSys configuration file to
determine to which database to connect. This option enables
autotrack to report on any AutoSys Event Server on the network.
-u tracking_level
Updates the level of detail that autotrack writes to the database, using
Level 0, 1, or 2.
Level 0
The default setting, and it indicates no tracking.

Level 1
Tracks job, calendar, monitor, browser, and machine definition

changes; job overrides; and autosys_secure, autotrack, and
sendevent calls. It condenses each tracked event to a one-line
summary.
Level 2
Tracks the same information as level 1, but also writes the entire
job definition for overrides and job definition changes. Level 2 is
very database intensive and will significantly impair jil
performance.
-l
Displays the currently set tracking level (0, 1, or 2).
-h|H
Displays the autotrack usage summary.
-v
Verbose reporting.

autotrack
-F "from_time"
Reports changes or events that occurred from this date and time
forward; the format is “MM/DD/[YY]YY HH:MM”.
If you enter a two digit year, AutoSys saves the setting to the database
as a four digit year. If you enter 79 or less, AutoSys prepends 20, and,
if you enter 80 or greater, AutoSys prepends 19.
-T "to_time"
Reports changes or events that occurred up to this date and time; the
format is “MM/DD/[YY]YY HH:MM”.
-U user_name
Reports changes or events initiated by the specified user.

-m machine_name
Reports changes or events initiated from the specified machine.

-J job_name
Reports on the specified job. The “%” character may be used in the job
name as a wildcard.

on.

autotrack
-t autotrack_type
Reports on a specific event; an event can be one of the following types:

A
Calls generated by the autosys_secure command.
B
Monbro definition changes generated by jil or the GUI.
C
Calendar definition changes generated by the autocal_asc
command or the Graphical Calendar Facility.
J
Job definition changes, sendevent -J (or the Send Event dialog
sent from the Operator Console), or overrides to a specific job
generated by jil or the GUI.
M
Machine definition changes generated by jil.
O
Override definition changes generated by jil or the GUI.
S
Calls generated by the sendevent command evoked via jil or the

GUI.
T
Calls generated by the autotrack command, i.e., changes to the

tracking level.

autotrack
Examples 1
The amount of detail written to the database (and, thus, available to

query against) is determined by the autotrack tracking level. Level 2
tracking provides much more detail than does level 1, as shown in
examples 1 and 2.
1 The following query requests verbose reporting about a job named

“NightlyReport.”
autotrack -J NightlyReport -v
If the autotrack tracking level had been set to 1, the output of this
request would resemble that shown below.
jane@taurus
11/21 10:04:54
job definition change
::::::::::::::::::::::::::::::::::::::::::::::::
jane@taurus
11/21 10:05:49
command: date
::::::::::::::::::::::::::::::::::::::::::::::::
jane@taurus
11/21 10:06:29
sendevent issued
If the tracking level had been set to 2, autotrack would have written
much more detail to the database. Thus, the same query
autotrack -J NightlyReport -v
would produce a report that includes the entire job definition with
changes indicated by an asterisk.

autotrack
2 The following query requests non-verbose reporting about the job

“NightlyReport”:
autotrack -J NightlyReport
A query without verbose reporting omits all indented detail; only the
first three lines for each event appears, as shown in the following:
jane@taurus
11/21 10:04:54
::::::::::::::::::::::::::::::::::::::::::::
jane@taurus
11/21 10:05:49
::::::::::::::::::::::::::::::::::::::::::::
jane@taurus
11/21 10:06:29
sendevent issued
3 To view all the changes that occurred to the job “NightlyReport” after
1 a.m. on November 12, 1997, enter this:
autotrack -F "11/12/1997 01:00" -J NightlyReport
4 To view all changes made by user “sue” over the weekend of
November 16 and 17, 1997, enter this:
autotrack -U sue -F "11/16/1997 01:00" -T "11/17/1997 23:59"
5 To view all autosys_secure changes that occurred from the machine
“gemini,” enter this:
autotrack -t A -m gemini

autotrack
The output from this command would resemble the following:

jane@gemini
11/05 19:08:12
autosys_secure change
EDIT Super-User: jane
EXEC Super-User: jane
password: **************

chase
chase 1
Function 1
Verifies that the jobs that the AutoSys database indicates are running, are
running. This process also checks the associated Remote Agents.
Syntax 1
chase [-A] [-E]
Description 1
chase determines from the AutoSys database which jobs are in the
STARTING or RUNNING state, and on which machine. For each client
machine, chase passes to a Remote Agent a list of jobs that are supposed
to be running there and instructs the Remote Agent to verify that the
processes actually are running. For Command jobs running on a UNIX
machine, the Remote Agent also checks for the pid of the UNIX process.
When verifying that the Remote Agent is running, chase checks that the
Remote Agent has a lock on the Remote Agent log file. (This is more
reliable than checking the Remote Agent’s process ID.)
Note • If you have disabled file locking on the client machine, chase
will not be able to verify if a Remote Agent is running. Therefore,
ensure that the directory specified by the AutoRemoteDir parameter in
the AutoSys configuration file is on a file system that has file locking
enabled.
When the Event Processor is started (by way of the eventor command),
chase is automatically invoked. Since chase uses the same mechanism as
the Event Processor to communicate with the Remote Agent machines, it
gives an accurate picture of the system’s state of health.

chase
Note • The Event Processor does not have to be running while chase
is run, but the database must be available.
Errors detected by chase are sent to standard output. Optional arguments

used with chase further determine what actions to take when error
conditions are detected. The -A option sends an alarm to AutoSys to alert
the user that problems were found. If the -E option is specified, chase will
force a FAILURE of any job that is supposed to be running but is not. This
will trigger an automatic restart of the job if the n_retrys attribute has
been defined. The Event Processor must be running for chase to
automatically restart jobs.
Note • If chase cannot connect to a Remote Agent machine, it cannot

determine if the reason is due to a network failure or the machine
being down. As a result, to prevent jobs from being restarted when in
fact they may have run already, chase will not change the status of jobs
in this case, even if chase is run with the -E option.
Note • If jobs are stuck in the STARTING state, chase will not
automatically restart them. Instead, it will write a message to standard
output that manual intervention may be required. Jobs stuck in the
STARTING state should not be automatically restarted—it is possible,
due to network problems, that the job may be running or have run,
and its state not yet communicated to the database. The actual status
of these jobs should be verified before they are restarted and their
status is changed.
Running chase Automatically

It is a good idea to run chase automatically at regular intervals to track
down any problems on the network. For example, if a machine becomes
unreachable while it is running a job, chase will detect that the machine
is down and send an alarm. If a user or operator has a monitor running,
they will also be alerted to the problem.

chase
To run the chase process automatically, you can use AutoSys to run it as
a job. The $AUTOSYS/data/chase.jil file contains the JIL statements that
will instruct AutoSys to run chase every 10 minutes on the machine
running the Event Processor (“charley”, in the example below). You can
change the specific parameters in this script to suit your own
environment, then submit it to the jil command.
The following are examples of JIL statements for automatically running

chase.
# chase function
#
insert_job: chase
machine: charley
command: $AUTOSYS/bin/chase -A -E
date_conditions: yes
days_of_week: all
start_mins: 05,15,25,35,45,55
max_run_alarm: 5 # change if many jobs are running
term_run_time: 10 # ditto
# These output files can be changed
std_out_file: $AUTOUSER/out/chase.out
std_err_file: $AUTOUSER/out/chase.err
Options 1
-A
Indicates that if chase detects any inconsistencies (i.e., jobs that
should be running, but are not) it sends alarms to the AutoSys
RDBMS(s).
-E
Indicates that if a job and the job’s Remote Agent are not running on
the client machine, but the database indicates they should be, chase
puts the job in FAILURE status, triggering the job to be restarted if the
job definition includes the n_retrys attribute.

chase
Note • If chase is run without any options, AutoSys performs all chase
activities and writes the results to standard output. No alarms or job
restart events are sent.
Example 1
If a job is running longer than expected and you suspect it may have
abnormally ended (but still shows as “running”), you should run chase.
To verify that the job is running, receive an alarm if there is an
inconsistency, and restart the job if necessary, enter this:
chase -A -E

chk_auto_up
chk_auto_up 1
Function 1
Inspects the environment variables and configuration files, then

determines if the AutoSys database (Event Server) and Event Processor
are running.
Syntax 1
chk_auto_up [-Q]
Description 1
chk_auto_up determines if the Event Server (database) and the Event

Processor are running. This facility is essential for locating the cause of
problems, such as jobs not being started at the scheduled time. The Event
Server and the Event Processor must both be running for job to start.
chk_auto_up uses the AutoSys product environment variables to locate

the AutoSys configuration file ($AUTOUSER/config.$AUTOSERV), and uses
the configuration file to determine the dataserver and database names. If
chk_auto_up completes successfully, this indicates that those
environment variables and the AutoSys configuration file are set up
correctly. If events are not being processed, or jobs are not running, this
is the first utility you should run.
If a Shadow Event Processor is running in addition to the primary Event

Processor, or if Dual Event Servers are being run, chk_auto_up will report
on the state of these objects as well.
chk_auto_up will look for Event Processors both on the current machine
and on machines in the EDMachines list, which is located in the AutoSys
configuration file ($AUTOUSER/config.$AUTOSERV).
For information on the configuration file, see the EDMachines section in

Chapter 13, Configuring AutoSys, of the AutoSys User Guide for UNIX.

chk_auto_up
Options 1
-Q
Indicates that the command should output just the exit code without
any descriptive message. This makes the command useful for
inclusion in shell scripts. In this case, the return code is sufficient to
indicate the status.
Return Codes 1
One of the return codes listed below is returned by chk_auto_up. If you

omit the -Q option, a descriptive message also will be displayed.
0 Event Processor not running; No Event Server.
1 Event Processor not running; Event Server up.
2 Event Processor not running; Primary and Dual Event Servers

up.
10 Event Processor up; Event Server name invalid, probably

because the Event Server (EventServer parameter in the
AutoSys configuration file) was correct when the Event
Processor was started, but was corrupted before you ran
chk_auto_up.
11 Event Processor up; Event Server up.
12 Event Processor up; Primary and Dual Event Servers up.
20 Shadow Event Processor up; Event Server name invalid (see

return code 10).
21 Shadow Event Processor up; Primary Event Processor not

running; Event Server up.
22 Shadow Event Processor up; Primary Event Processor not

running; Primary and Dual Event Servers up.

chk_auto_up
30 Primary and Shadow Event Processors up; Event Server name

invalid (see return code 10).
31 Primary and Shadow Event Processors up; Event Server up.
32 Primary and Shadow Event Processors up; Primary and Dual

Event Servers up.
50 Event Processor “not running” because could not connect to

machine in the EDMachines list in the AutoSys configuration
file; No Event Server.
51 Event Processor “not running” (see return code 50); Event

Server up.
52 Event Processor “not running” (see return code 50); Primary

and Dual Event Servers up.
60 Event Processor “not running” because no machines listed in

the EDMachines list in the AutoSys configuration file; No Event
Server.
61 Event Processor “not running” (see return code 60); Event

Server up.
62 Event Processor “not running” (see return code 60); Primary

and Dual Event Servers up.
99 One of the following can cause this message to appear:

■ One or more of the following environment variables is not
set or is set incorrectly: AUTOSYS, AUTOSERV, AUTOUSER.
■ You issued the chk_auto_up command with invalid

arguments.

chk_auto_up
Example 1
To check that the database and Event Processor are up and to view the
results on your monitor, enter this:
chk_auto_up

chk_cond (SP)
chk_cond (SP) 1
AutoSys Stored Procedure
Function 1
Prints diagnostics if a job has starting conditions based on another job

that does not exist.
Syntax 1
chk_cond job_name
Description 1
The chk_cond (SP) prints a report containing diagnostics about a job

having starting conditions that are based on another job that does not
exist.
Note • chk_cond is called every time a job is inserted or updated. If

there is a missing job, chk_cond prints out a warning message.
chk_cond is supported for Sybase databases only.
Options 1
job_name
Specifies the name of the job against which diagnostics should be run.
If job_name is not specified, the stored procedure will be run against
all jobs.

chk_cond (SP)
Example 1
A job named “jobA” has the following conditions specified:

condition: success(jobB) and success(jobC)
But, “jobC” does not exist.
To print out diagnostics for all jobs in a Sybase dataserver, enter this:
1> chk_cond
2> go
The following would be displayed to standard output:
Job Missing_Condition_Job
--------- --------------------------------
jobA jobC

clean_files
clean_files 1
Function 1
Removes Remote Agent log files from the various machines.
Syntax 1
clean_files -d days
Description 1
The clean_files command deletes old Remote Agent log files. It

performs this task by searching the database for all machines which have
had jobs started on them, then sending a command to the Remote Agent
on that machine to purge all remaining log files from the machine’s
Remote Agent Log directory (specified by AutoRemoteDir in the AutoSys
configuration file).
Remote Agent log files are deleted automatically only if the job
completed normally, and if the CleanTmpFiles parameter in the AutoSys
configuration file specifies that the log files be deleted at the end of each
job.
Remote Agent logs for failed jobs are not deleted, and these files can take
up valuable disk space. Therefore, we recommend that you run the
clean_files command daily, as part of the daily DBMaint cycle.
For information on DBMaint, see AutoSys Database Numeric Codes in

Chapter 6, Database Tables and Codes.
Note • If you are experiencing problems running jobs successfully,

the Remote Agent log files are very useful diagnostic tools. In this
case, you should not run clean_files, or remove the Remote Agent log
files using any other method, until the problem has been diagnosed
and resolved.

clean_files
Options 1
-d days
Specifies that log files older than the number of days will be removed.
Example 1
To start clean_files and delete all Remote Agent log files older than 1
day, enter this:
clean_files -d 1

cron2jil
cron2jil 1
Function 1
Translates UNIX crontab files into AutoSys JIL format.
Syntax 1
cron2jil -f crontab_file [-d output_directory] [-i include_file]

[-m machine] [-p prefix]
Description 1
The cron2jil command converts each line in a UNIX crontab file to a

corresponding JIL script (*.jil file) and, if necessary, a run calendar file
(*.cal file). The cron2jil command cannot comprehensively address all
job processing requirements. It should be used as a first step in
converting from cron to the AutoSys environment. The second step
requires editing the newly created JIL and calendar files to ensure the
desired job processing.
When cron2jil reads a crontab file, it assigns job names by combining

the basename of the job’s command and the line number of the file. For
example, the following crontab entries would result in the job names
“cp_1” and “mail_2” respectively.
>>0,59 0,23 * * 0,6 /bin/cp /etc/passwd /etc/passwd.bak
>>0,59 * * * 0,6 /usr/ucb/mail root@support1 < /tmp/errorLog
After translation, cron commands involving pipes and I/O redirection
perform just as they did in the cron environment. If run calendars are
created, cron2jil only generates calendars with a one year duration.
After conversion, pipe and I/O redirections might not take full advantage
of the fault tolerance mechanisms of AutoSys. For example, the exit code
of a failed command in a pipe might not result in the failure of the
complete command expression. Because of this behavior, translated JIL

cron2jil
scripts should be edited and pipes should be split into separate jobs with
the appropriate conditions and job control. With this approach,
problems can be detected and reported at the point of failure.
cron2jil does not generate JIL files for jobs that are defined in crontab to
start every minute; i.e., with a “*” specified in the first field of the cron
listing. In the AutoSys environment, this is a special case and should be
remedied by using a starting condition for the job that is the successful
completion of the job itself.
Note • Once any *.jil or *.cal files are generated, you must submit
these files to the AutoSys database using the jil and the autocal_asc
commands, respectively.
Options 1
-f crontab_file
Specifies the name of the crontab formatted file.
-d output_directory
Specifies the directory to which the *.jil and *.cal files should be
written. The default is the current working directory.
-i include_file
Specifies the name of a file containing JIL statements that are to be
included in every generated *.jil file. This file must be created before
the conversion, and it can contain any default JIL statements.
-m machine
Specifies the name of the machine on which the translation should
occur. If no machine is specified, the default is “localhost”.

cron2jil
-p prefix
Specifies a prefix that should be inserted before each job’s name. For
example, if a prefix of “AUTO” is specified, the jobs cited in the
example above would have the following names: “AUTOcp_1” and
“AUTOmail_2”.
Example 1
To translate a crontab file with the name “daily”, enter this:

cron2jil -f daily

dbstatistics
dbstatistics 1
Function 1
Generates statistics in the dataserver(s) to maintain an optimal

performance environment for AutoSys.
Syntax 1
dbstatistics
Description 1
dbstatistics performs the following tasks:
■ It update statistics in the database for optimal performance by

invoking the Sybase Transact-SQL command update statistics. For
Sybase databases, it updates the statistics for the event, job, job_status,
and job_cond tables. For Oracle, it computes statistics for all of the
AutoSys tables.
■ For Sybase only, dbstatistics recompiles stored procedures in the

event, job, and job_status tables by invoking the Sybase Transact-SQL
command sp_recompile.
■ dbstatistics runs the AutoSys dbspace command to check the

available space in the database. dbspace prints a summary of the free
space versus the used space in the database. If the amount of free space
is insufficient, dbspace issues warning messages and generates a
DB_PROBLEM alarm.
Note • If you use an Oracle database, running DBMaint may report

that your database is close to full when this is not the case. This can
occur because DBMaint calculates how much space is allocated for
extents not the number of bytes that are in use. The extents may be
nearly empty, but DBMaint reports the whole extent as used space.

dbstatistics
■ dbstatistics calculates and updates the average job run statistics in

the avg_job_run table. The old data is overwritten with the new data.
The update statistics command returns either a 0 or 1; 0 indicates
success and 1 indicates failure. The average job run statistics are used
by AutoSys/Xpert.
Options 1
None.

eventor
eventor 1
Function 1
Starts the Event Processor(s).
Syntax 1
eventor [-f] [-n] [-q][-G] [-M shadow_machine] [-Z $ZTEAMDIR]
Description 1
Use the eventor command to bring up the Event Processor (and,

optionally, the Shadow Event Processor), also referred to as the “event
demon.” eventor runs in the background, by default. It first makes sure
that another Event Processor of the same instance is not running on the
same machine as this instance of AutoSys (as determined by the
$AUTOSERV variable), unless two Event Processors are specified in the
configuration file.
It then runs chase, which inspects the database to determine which jobs
are supposed to be running, and then checks each machine to verify that
the jobs are there. If problems are detected, chase sends alarms and/or
failure events, depending on the options specified, for any missing jobs.
If the missing jobs can be restarted, they are automatically restarted.
The eventor -M command brings up the Primary and the Shadow Event
Processor (which takes over if the Primary Event Processor machine
fails).
If the Event Processor has been down for a long period of down time, you
can start it in Global AutoHold mode by specifying the -G option. This
prevents the system from being flooded at once with numerous jobs
which were scheduled to run during the down time.

eventor
Log Files
eventor writes log information to the file named $AUTOUSER/out/
event_demon.$AUTOSERV. The output from the chase command is written
to this same log file.
By default, eventor executes the tail -f command against the log file.
This tail is useful for monitoring the execution of the Event Processor,
particularly when there are problems with its start-up.
For example, if the machine from which eventor is issued does not have
a valid AutoSys license, the Event Processor will not start. The only
indication that this condition exists is a message output by the Event
Processor in its log file. To exit the tail command, you press
<Control+c> in the window displaying the Event Processor log.
The Shadow Event Processor writes log information to the $AUTOUSER/

out/event_demon_shadow.$AUTOSERV file.
Options 1
-f
Specifies that the Event Processor should run in the foreground, and
all of its output should be sent to the display from which the
command was issued.
Note • The -f option is not recommended for production use. The

default behavior is to run the Event Processor in the background,
with all output going to the $AUTOUSER/out/event_demon.$AUTOSERV
file.
-n
Specifies that eventor is not to run the chase command on start-up.
The default behavior is to run the chase -A -E command. The chase

command inspects the database to find out what jobs are supposed to
be running, then it checks each machine to verify that the jobs are

eventor
there. If there are any problems, chase sends alarms, changes the
missing jobs’ states to FAILURE, and, if conditions permit, causes the
missing jobs to be restarted.
All chase output is redirected to the following file:

$AUTOUSER/out/event_demon.$AUTOSERV
-q
Specifies that eventor should run in quiet mode, meaning that after
the Event Processor has been started, eventor should not execute the
tail -f command on the event_demon log file.
-G
Starts up the Event Processor in Global AutoHold mode. Global
AutoHold is useful if you are restarting the Event Processor after a
period of down time. This prevents the system from being flooded at
once with numerous jobs that were scheduled to run during the down
time. When in Global AutoHold mode, the Event Processor evaluates
all jobs whose starting conditions have passed and are eligible to run.
But instead of starting the jobs, the Event Processor puts the jobs
ON_HOLD. This gives you the opportunity to decide which jobs
should run by selectively starting them with the Force Start Job button
in the Operator Console, or with the sendevent -E FORCE_STARTJOB
command.
When Global AutoHold is on, the following message appears after

every timestamp:
-------------< Date: 12/12 20:22:00 >---------------
******* Global AutoHold IS ON ! *******
If Global AutoHold is on, you cannot take a job OFF_HOLD via the
Operator Console or the sendevent command. The only way to start a
job when Global AutoHold is on is with the FORCE_STARTJOB event.
When sent, this event will override the AutoHold mode.
If you start a Shadow Event Processor with the -G flag, the Shadow
Event Processor will also be in Global AutoHold mode.

eventor
To turn off Global AutoHold, you must shut down the Event
Processor, then start it up again without the -G flag.
-M shadow_machine
Specifies that a Shadow Event Processor should be started on the
machine named shadow_machine.
-Z $ZTEAMDIR
Sets the ZTEAMDIR environment variable, if it is not already set. This
is needed only for integrating AutoSys with Zeke and Team Agent. See
Appendix A, Integrating AutoSys with Zeke and AutoSys/Team Agent in the
AutoSys User Guide for UNIX for more information.
No Options Set
This is the recommended way to bring up the Event Processor. All
restart checks are performed, alarms are sent, and output is recorded
in the log file.
WARNING • Do not attempt to start the Event Processor by invoking the
event_demon binary at the command line. The eventor script is required
to properly check and configure the environment for the Event
Processor.
Examples 1
1 To start the Event Processor under normal circumstances, enter this:
eventor
2 To start the Event Processor on the local machine, and a Shadow Event
Processor on the machine named “jupiter”, enter this:
eventor -M jupiter

eventor
See Also 1
For more information about running multiple Event Processors, see the
Shadow Event Processor section of Chapter 1, Introduction to AutoSys, in the
AutoSys Installation and Getting Started Guide for UNIX.

gatekeeper
gatekeeper 1
Function 1
Maintains license keys.
Syntax 1
gatekeeper
Description 1
gatekeeper is an interactive utility you can use to maintain AutoSys

license keys located in the AutoSys database. The following types of keys
are used in AutoSys:
Single Time Key
Time Keys are assigned for software evaluations, and will indicate an
expiration date. For purchased licenses, the expiration date is
“*Infinity*”.
Note • When entering a temporary license key, you must enter a

four-digit year.
Server Key
Required for each server (that is, machine running an Event

Processor). You will be asked for the host name and ID of the server
machine where the Event Processor will run, and the key will be
generated for you by the AutoSystems Development Lab.
Client Key
Required for each client (that is, machine running any AutoSys
software, from the Remote Agent which runs jobs under AutoSys
control, to the utilities, such as jil). You will be asked for the host

gatekeeper
name and host ID of the client machine, and the key will be generated
for you by the AutoSystems Development Lab. Frequently, the
AutoSys server machine is also a client; if it is, it will need a client
license as well as a server license key. Each client must have a key
registered individually.
Xpert Key
Xpert Keys are assigned to separately enable the AutoSys/Xpert

product.
Options 1
None.
Example 1
To start the license utility, enter this:

gatekeeper
See Also 1
Chapter 10, License Management, in the AutoSys Installation and Getting

Started Guide for UNIX.

jil
jil 1
Function 1
Runs the Job Information Language (JIL) processor to add, update, and
delete AutoSys jobs, machines, monitors, and reports. Also used to insert
one-time job override definitions.
Syntax 1
jil [-q] [-S autoserv_instance] [-V none | job | batch]
Description 1
The jil executable is the language processor for the AutoSys Job
Information Language (JIL). Using JIL (the language itself), you can
define and update jobs, monitors, reports, and machines. The jil
command can be used in one of two ways:
■ To automatically submit job definitions to the AutoSys database. You

do this by redirecting a JIL script file to the jil command.
■ To interactively submit job definitions to the AutoSys database. You

do this by issuing the jil command only and entering JIL statements
at the provided jil>> prompts. To exit interactive mode, enter “exit”
at the prompt, or press <Control+d>.
A JIL file contains a sub-command such as insert_job and a set of

attributes for that job, in a specific format. The complete syntax rules are
defined below. The JIL sub-commands listed in Table 1-1 are used to
create, update, delete, or override a job definition.

jil
Table 1-1 • JIL Sub-commands for Job Definitions
Sub-command Action
insert_job Add a new job to AutoSys.

update_job Edit fields on an existing job.
delete_job Delete this job from AutoSys.
delete_box Delete this box job, and recursively delete all the
jobs contained in the box.
override_job Insert overrides on indicated job attributes for
the next run of this job.
The JIL syntax rules are given below:
Rule 1
Each sub-command uses the following form:
sub_command: job_name
where:
sub_command
Is one of the sub-commands listed in Table 1-1.
job_name
Is the user-specified name of the job to be acted upon.

jil
Rule 2
Each sub-command may be followed by one or more attribute
statements. These statements may occur in any order, and are applied to
the job specified in the preceding sub-command. A subsequent
sub-command begins a new set of attributes for a different job. The
attribute statements are of the form:
attribute_keyword: value
where:
attribute_keyword
Is one of the legal JIL attributes.
value
Is the setting to be applied to the attribute.
Rule 3
Multiple attribute statements can be entered on the same line; however,
they must be separated by at least one space.
Rule 4
A box that contains jobs must be defined before the jobs can be placed in
it.
Rule 5
Legal value settings can include any of the following characters: upper-
and lowercase letters, numbers, colons (if the colon is escaped), and the
special character “@”.
Rule 6
Any colons used in an attribute statement’s value setting must be
escaped, since JIL parses on the combination of keyword followed by a
colon. For example, to specify the time to start a job, specify “10:00”. The
colon may also be escaped with a preceding backslash “\”, as in 10\:00.

jil
Rule 7
Comments are indicated using one of two methods.
■ An entire line can be commented by placing a pound sign “#” in the

first column.
■ The C programming syntax used for beginning a comment with “/*”

and ending it with “*/” may be used; this allows comments to span
multiple lines. The following is an example:
/* this is a comment */
One of the primary advantages of using JIL is the ability to use the UNIX
tools that are available for file manipulation that create and control
AutoSys job definitions. For example, you run the following command
on every workstation:
rm /tmp/stuff/*
Then, it would be far simpler to create a “generic” JIL template (text file),
and copy it for each machine, changing only the machine attribute of the
job. In fact, you could use a shell script to iteratively copy the template to
a temporary file, replacing the machine name, and redirecting the
temporary file into jil.
Options 1
-q
Specifies that jil should be run in “quiet” mode and that it should
only output error messages. This is useful when entering a large
number of jobs, so that errors can be easily seen. The default is to also
output status messages, indicating the success or failure of the JIL sub-
commands. This information is very useful and should typically be
allowed to print out.

jil
Specifies the three-character AutoSys instance name, e.g. ACE, (and
therefore the RDBMS) to which to apply the definition(s). If not
specified, jil will use the value of the environment variable named
$AUTOSERV.
-V none | job | batch

Specifies whether or not the JIL processor should verify that jobs
specified in the job dependency condition for the job actually exist in
the AutoSys database. By default, the JIL processor always performs
this operation on a job-by-job basis, when jobs are submitted to the
database. You can use this option to bypass this behavior by using the
none or batch arguments. The none option does not perform any job
dependency verification. The batch option checks the database after
the JIL file has been entirely processed. The job option checks the
database on a job-by-job basis; this is the same as not using the -V
option.
Note • The portion of a condition statement that includes job

dependencies on undefined jobs will evaluate to FALSE for all
conditions except notrunning. For example, if “jobA” has the
condition success(jobB) and success(jobC), and “jobC” is not
defined in the database, the condition will evaluate to FALSE. If
“jobA” depends on notrunning(jobC), the condition will evaluate to
TRUE.

jil
When you use this option, the jobs specified in job dependencies that do
not exist in the AutoSys database are reported to standard output. The
display will look something similar to the following:
________________________________________________________
Insert/Updating Job: JobA
*** WARNING: The Following Jobs are referenced in the ***
Conditions for this Job, YET are not defined!
1) JobC
Database Change WAS Successful!
________________________________________________________
Examples 1
1 To redirect a text file named “job1” containing JIL statements into jil,
enter this:
jil < job1
2 To redirect a text file named “job1” containing JIL statements into jil
and prohibit the JIL processor from verifying the existence of specified
jobs in its job dependencies, enter this:
jil < job1 -V none

job_depends
job_depends 1
Function 1
Reports information about the dependencies and conditions of a job.
Syntax 1
job_depends [-c | -d | -t] [-J job_name] [-F from_date/time]

[-T to_date/time] [-L print_level]
[-D data_server:database | -D TNSname]
Description 1
job_depends provides detailed reports about the dependencies and

conditions of a job. This command can be used to determine the current
state of a job, its job dependencies, and (for boxes) nested hierarchies as
specified in the job definition, and a report of what jobs will run during
a given period of time.
Options 1
-c
Current Condition Status. Prints out the current state of a job and the
names of any jobs that are dependent on this job. The output of this
option is similar to that displayed in the Starting Conditions area of
the Job Activity Console.
-d
Dependencies Only. Prints out the starting conditions for a job; no
indication of the current status of the job is provided. For box jobs,
jobs inside the box are shown hierarchically. The -L option controls
how many levels of nesting are displayed.

job_depends
-t
Time Dependencies. Prints out the starting conditions for a job;
however, the top level of jobs (or boxes) that are reported are limited
to those that will start within the time period specified by the job or
box’s date conditions. In the event that a box will satisfy those date
conditions, all of the jobs within it will also be printed. The level of
nesting displayed can be controlled with the -L option.
job_depends -t does not calculate all complex job dependencies when

reporting on the jobs and boxes that are scheduled to run. For
example, “JobB” may have a date condition and be dependent on
“JobA”. The date conditions for “JobB” may be met for a given day,
while those for “JobA” are not. As a result, “JobA” won’t run, and
neither will “JobB”. However, “JobB” will appear on the report
produced by job_depends. For this reason, the starting conditions are
also printed; e.g., next to “JobB” would be the condition:
success(JobA).
-J job_name
Indicates the job on which to report, where job_name is the name of
the target job. To report on all jobs, enter the word ALL for the
job_name. Wildcards are also supported, using the percent symbol
“%”. For example, to print all jobs that have ‘Backup’ in their job
name, enter this:
%Backup%

on.

job_depends
-F "from_date/time"
Indicates the report start date and time, where from_date/time is the
date and time of the first job in the report. This option is used with the
-T option only. The format is MM/DD/[YY]YY HH:MM.
-T "to_date/time"
Indicates the report end date and time, where to_date/time is the date
and time of the last job in the report.
This option is used with the -F option only. The format is MM/DD/
[YY]YY HH:MM. If this option is not specified, job_depends will
search without limitation into the future.
-L print_level
Indicates the print level for the report, where print_level is any valid
numeric value specifying the number of levels of nesting to display for
a box job. This option is used with the -d and -t options only.
For example, a print_level of 2 indicates that information for the

specified box job and two levels of jobs within that box, should be
shown. If you want to report on the outer most box alone, specify “0”.
The default is to list all levels within the box.
job_depends consults the environment variables and the AutoSys

job_depends
configuration file to determine to which database to connect. This

option enables job_depends to report on any AutoSys Event Server on
the network.
-D TNSname
for the specified information. Normally, job_depends consults the
environment variables and the AutoSys configuration file to
determine to which database to connect. This option enables
job_depends to report on any AutoSys Event Server on the network.
Example 1
1 To display a report on the current condition status of a job named

“jobX”, you would issue the following command:
job_depends -c -J jobX
You would see a report similar to the following displayed to standard
output:
________________________________________________________________
Start Dependent
Job Name Status Date Cond? Cond? Jobs?
-------- ------ ---------- ------ ---------
jobX INACTIVE No No Yes
Dependent Job Name

-------------------
jobY
________________________________________________________________
This report shows that “jobX” has no date or starting conditions, but
another job, “jobY” is dependent on it.

job_depends
2 To display a report on the current condition status of a job named

“jobA”, which does have starting conditions and dependencies, you
would issue the following command:
job_depends -c -J jobA
output:
________________________________________________________________
Start Dependent
Job Name Status Date Cond? Cond? Jobs?
-------- ------ ---------- ------ ---------
JobA INACTIVE Met Yes No
Condition: done(jobB) and success(jobC) and success(jobD)

and success(jobE) and success(jobF) and success(jobG) and
success(jobH) and success(jobI)
Atomic Condition Current Status T/F

---------------- -------------- ---
DONE(jobB) INACTIVE F
SUCCESS(jobC) INACTIVE F
SUCCESS(jobD) INACTIVE F
SUCCESS(jobE) RUNNING F
SUCCESS(jobF) INACTIVE F
SUCCESS(jobG) INACTIVE F
SUCCESS(jobH) SUCCESS T
SUCCESS(jobI) INACTIVE F
________________________________________________________________
This report shows that even though the date conditions have been met
for “jobA”, it is in the INACTIVE state because its starting conditions
have not been met. An “F” next to an atomic condition indicates that
the atomic condition has not been satisfied (F = False, T = True).
3 To display a report on the box job named “job_bxA” showing all the
nested levels of jobs and boxes within this job, you would enter the
following command:
job_depends -d -J job_bxA

job_depends

output:
________________________________________________________________
Job Dependency Report
Job Name Date Cond? Atomic Start Conditions

_____________________ _________________________________
job_bxA Yes d(job1)
s(job2)
job3
job_bxB ------- -------
job_bxC ------- -------
job4 ------- -------
job5 ------- -------
job6 ------- -------

job7 ------- -------
job8 ------- s(job6)
s(job7)
________________________________________________________________
In this report, all the nested jobs and boxes within “job_bxA” are
shown. If a job has a date condition and/or any atomic starting
conditions, these are indicated. Starting conditions are abbreviated as
follows: s = SUCCESS, f = FAILURE, d = DONE, t = TERMINATED,
and n = NOTRUNNING.
4 To display a report on jobs that are scheduled to run on New Years

day, you would enter the following command:
job_depends -t -J ALL -F "01/01/1998 00:00"
-T "01/02/1998 00:00"

job_depends
The -F (from date/time) and -T (to date/time) options allow you to

specify the date and time for the beginning and end of the report. You
would see a report similar to the following displayed to standard
output:
________________________________________________________________
Job Forecast Report

From: 01/01/1998 00:00:00 To: 01/02/1998 00:00:00
Job Name NextStart Atomic Start Conditions

_________________________________________________________
job1 01/01/191 12:05-------
job_bxA ------- d(job1)
job2
job_bxB ------- -------
job_bxC ------- -------
job3 ------- -------
job4 ------- -------
job5 ------- -------
job6 ------- -------
job7 ------- s(job5)
s(job6)
job8 01/01/1998 02:00-------

job_bxD ------- d(job8)
job_bxE ------- -------
job9 ------- -------
job10 ------- -------
job11 ------- -------

job12 ------- -------
job13 ------- -------
job14 ------- s(job11)
s(job12)
s(job13)
job15 01/02/1998 04:00-------

job_bxF ------- d(job15)
job_bxG ------- -------
job16 ------- -------
job17 ------- -------
job18 ------- -------

job19 ------- -------
job20 ------- s(job18)
s(job19)
________________________________________________________________

monbro
monbro 1
Function 1
Runs a monitor or report (browser) previously registered in the database.
Syntax 1
monbro -N name [-P poll_frequency]

[-D data_server:database| -D TNSname] [-q]
Description 1
monbro runs a monitor or report (browser) that has already been defined,
either using either jil or the GUI.
Output from monbro goes to standard output. If a monitor is configured

with sound on, it will use the sound capabilities of the machine on which
it is running. The sound clips must be pre-recorded, and the machine
running monbro must be able to access the $AUTOUSER/sounds directory.
For details on recording sound and a list of machines for which AutoSys
supports sound, see the record_sounds command on page 1-105.
The definition of the monitor or report to be run must reside on the

database for the instance you are accessing. monbro can connect to any
that your AutoSys instance is configured to use. By default, it will inspect
the environment variables $AUTOSYS, $AUTOUSER and $AUTOSERV to
determine which database to connect to. This default can be overridden
by using the -D option.

monbro
Options 1
-N name
Specifies the name of the monitor or report (browser) to be run. The
“%” character may be used in the name as a wildcard; or you can type
ALL for all.
-P poll_frequency
Applies to monitors only, and indicates the time interval (in seconds)
to sleep between polls of the database. The default is 10 seconds.
Specifies the name of the Sybase dataserver, and the specific database
within it, from which to retrieve events and the monitor or report
definition. The default behavior is to inspect the AutoSys
environment variables and configuration file to determine which
dataserver and database to use.
-D TNSname
Specifies the TNS alias name of the Oracle database from which to
retrieve events and the monitor or report definition. The default
behavior is to inspect the AutoSys environment variables and
configuration file to determine which database instance to use.
-q
Specifies that you want to display monbro definitions in JIL format.
Examples 1
To run a monitor called “mon1” which is defined in the default database,

enter:
monbro -N mon1
Sample output with the -q option:
monbro -N mon1 -q

monbro
insert_monbro: xxx
mode: m
all_events: Y
job_filter: a
sound: N
alarm_verif: N
insert_monbro: xxx2
mode: b
all_events: N
alarm: Y
all_status: N
running: N
success: Y
failure: Y
terminated: N
starting: N
restart: N
job_filter: b
job_name: box
currun: N
after_time: "11/11/1997 12:12"
See Also 1
For more information about using monitors and reports (browsers), see
Chapter 11, Monitoring and Reporting Jobs, in the AutoSys User Guide for
UNIX.

record_sounds
record_sounds 1
Function 1
Records sounds to be played back by monitors.
Syntax 1
record_sounds AutoSys_password
Description 1
This utility records sounds for playback in monitors. It stores the sounds
in files located in the $AUTOUSER/sounds directory. It assumes that the
workstation you are on is equipped for sound, has a microphone plugged
in, and is set up correctly.
Note • As of this printing, the sound facility is supported on SunOS,

Solaris, and SGI platforms.
record_sounds is an interactive tool that will record sounds for jobs (the
Job Names) or System Phrases (e.g., RUNNING or SUCCESS). The
recordings for all System Phrases come with AutoSys. However, we
recommend that the person who records the Job Names should also re-
record the System Phrases.
record_sounds inspects the AutoSys database to get lists of Job Names

and System Phrases. You will be prompted for each sound to record.
Sounds are stored in various files in the $AUTOUSER/sounds directory. The

filename for these files is constructed using the Job Name or the System
Phrase name. For example, the sound file for the job “DB_Backup” is
stored in the $AUTOUSER/sounds/DB_Backup file, and the MINRUNALARM
System Message is stored in the $AUTOUSER/sounds/MINRUNALARM file.

record_sounds
If you have a favorite pre-recorded sound you want to use, you can
simply copy it into the proper file.
record_sounds gets lists of jobs names and system phrases from the
AutoSys database. The sound clips themselves are stored in files in the
$AUTOUSER/sounds directory. When you run the command, you are
prompted to decide which sounds you will record.
To Record Sounds:
1 Choose whether to record job names, system phrases, or one sound
only. If you choose one sound, you must supply the filename. If you
choose to record job names or system phrases, you are prompted by
the following message:
Record only those sounds that are missing? y/n
If you answer “y”, you will then be prompted to record those sounds
that are not already in the $AUTOUSER/sounds directory. Selecting this
option is useful for maintaining a complete set of sounds when new
jobs are added.
If you answer “n”, you will be prompted to record all of the sounds
until you finish or exit.
2 At each prompt, you are asked to press <Enter> to start recording, then
speak or play a sound into the microphone, and press <Enter> to end
the recording.
3 To exit the record sounds utility, press <Control+c> at any time.
Sounds are stored in files in the $AUTOUSER/sounds directory. The file

name is the job or system phrase name. For example, the sound file for
the job “DB_Backup” is stored in $AUTOUSER/sounds/DB_Backup, while the
message for MINRUNALARM is stored in the $AUTOUSER/sounds/
MINRUNALARM file. If you have a favorite pre-recorded sound that you want
to use, simply copy it into the appropriate file.

record_sounds
Options 1
None.
Example 1
To record sounds, be sure the workstation you are on is equipped for

sound, has a microphone plugged in, and is set up correctly, then, enter
this:
record_sounds
See Also 1
None.

sendevent
sendevent 1
Function 1
Sends events 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.
Syntax 1
sendevent -E event [-S autoserv_instance] [-A alarm] [-J job_name]

[-s status] [-C comment] [-P priority] [-M max_send_trys]
[-q job_queue_priority] [-T "time_of_event"]
[-G "global_name=value"] [-k signal_number(s)] [-u]
Description 1
Issuing the sendevent command is the only method of externally sending

an event to AutoSys for such purposes as starting a job or stopping the
Event Processor. You can also use sendevent to communicate with any
instance of AutoSys, provided the machine on which it is executing can
connect with the database(s) associated with that instance of AutoSys.
The event that is sent is written to the database, which the Event
Processor is continually polling. The Event Processor reads and processes
the event.
The Send Event dialog can also be used to send an event. You access this
dialog by choosing the Send Event button in the Job Activity Console.
The Send Event dialog is described in Chapter 10, The Operator Console, in
the AutoSys User Guide for UNIX.
A brief description of each “sendable” event is provided below. For

additional information about the different types of events, see Chapter 5,
System States.

sendevent
Note • To issue a sendevent on a job, you must have execute

permission on that job. Only alarms, comments, and set global can be
sent without regard to permissions.
Options 1
-E event
Specifies the event to be sent. This option is required. Any one of the
following events may be specified:
STARTJOB
Start the job specified in -J job_name if the starting conditions are

satisfied. A STARTJOB event ignores time and date conditions, but
it does consider other start conditions, such as dependencies on
other jobs. This command cannot be used on jobs in boxes. Jobs in
boxes inherit the starting conditions of the box they are in; as a
result, they will be started when that box is started.
KILLJOB
Kill the job specified in -J job_name. The action depends on one of

the following job types:
Command Jobs
Kills the process that is currently running and all the processes that
it has spawned; i.e., the process group. It will not kill orphan
processes. It sends a signal to the process, waits five seconds, then
sends a second signal, if the process is still there. The default kill
signals to be sent are specified in the AutoSys configuration file
with the KillSignals parameter, and typically the signals are
SIGINT and SIGKILL. This enables the application programmer to
program commands that will react intelligently to the KILLJOB
event. For UNIX processes, specific signals can be specified, or
default signals can be overridden using the -k option.

sendevent
Box Jobs
Changes the status to TERMINATED. No more jobs within the box

will be started. Jobs that are already running will continue to run
to completion.
File Watcher Jobs
Kills the file watcher job and changes the status to TERMINATED.
DELETEJOB
Delete the job specified in -J job_name from the database. If the job
is a box, deletes the box and all the jobs in the box.
FORCE_STARTJOB
Start the job specified in -J job_name, regardless of whether the

starting conditions are satisfied. Because multiple instances of the
same job could be started using this command, we recommended
you use the FORCE_STARTJOB event only in extreme situations.
Do not force start a job in QUE_WAIT state because jobs in

QUE_WAIT state are already “started” and are waiting for machine
resources to become available to run. If you want a job in
QUE_WAIT to start running immediately, change the job queue
priority to 0 (using the CHANGE_PRIORITY event).
If a job fails inside a box and you fix the problem manually, use
FORCE_STARTJOB to rerun the job.
Note • If you force start a job, AutoSys will start the job right
away on the machine specified in the job definition, regardless
of the current load on the machine or the job_load specified for
the job. For more information, see the Force Starting Jobs section
in Chapter 9, Load Balancing and Queuing Jobs, of the AutoSys User
Guide for UNIX.

sendevent
JOB_ON_ICE
Puts the job specified in -J job_name “on ice.” When a job is placed
on ice, it effects downstream jobs dependent upon that job. For
example, the starting conditions for jobs downstream from “JobA”,
which has been put “on ice,” will evaluate as shown in Table 1-2.
Table 1-2 • Evaluation of Dependent Jobs’ Conditions
If the condition is this: It will evaluate to this:
success (JobA) TRUE

failure (JobA) FALSE
terminated (JobA) FALSE
done (JobA) TRUE
notrunning (JobA) TRUE
exitcode FALSE
For details on how “On Ice” affects boxes, see Chapter 5, Box Job
Logic, in the AutoSys User Guide for UNIX.
Note • If a job’s status is RUNNING or STARTING, AutoSys will

not allow the job be put “On Ice.”
JOB_OFF_ICE
Takes the job specified in -J job_name “Off Ice”. Jobs that are taken
“Off Ice” will not start until the next time their starting conditions
are met.

sendevent
JOB_ON_HOLD
Puts the job specified in -J job_name “On Hold”. When a job is “On
Hold”, it will not be started, and downstream dependent jobs will
not run. A box cannot successfully complete if a job within it is
ON_HOLD. If the job is already STARTING or RUNNING, you
cannot put it ON_HOLD.
JOB_OFF_HOLD
Takes the job specified in -J job_name “Off Hold.” If the starting

conditions are met, the job will be started.
CHANGE_STATUS
Forces a change in the status of the job specified in -J job_name.

Ordinarily this should not be used, since AutoSys manages job
state changes internally. If this option is selected, the -s status
option must also be selected.
When you send a CHANGE_STATUS event, you are changing the

status of the job in the database; this event does not affect the
current running of the job. That is, if you change the status to
running, the status is changed in the database but the job is not run.
You will have to change the status to a termination state before the
job can be run again.
STOP_DEMON
Stops the Event Processor (event demon). This is the only way to
stop the Event Processor. This command does not stop the AutoSys
database.
CHANGE_PRIORITY
Changes the Job Queue Priority of the job specified in -J job_name

to the priority specified by the -q priority arguments. Queue
priority is the relative priority of all jobs in the queue. The lower
the number, the higher the priority; zero means to run the job right

sendevent
away. If the job has not been started, priority is changed for the
next run only. If the job has been started, and is in a queue, priority
is changed immediately.
COMMENT
Attaches a message to the event, for informational purposes only.

When used with the -J job_name option, the message is attached to
the specified job for a given job run. When used with the -c option,
sendevent will write a comment directly to the Event Processor Log.
ALARM
Sends an alarm. Generally alarms are generated internally;

however, using this event, users and programmers can send alarms
to alert operators.
SET_GLOBAL
Sets an AutoSys global variable. This event is sent with a high

priority so the Event Processor will process the variable before it is
referenced by any jobs at runtime. The -G ”global_name=value”
option must be used with this event.

sendevent
SEND_SIGNAL
Sends a signal to a running AutoSys job. For processes running on

UNIX systems, you must use the -k signal_number(s) and
-J job_name options with this event. For processes running on
Windows NT, you must use the -k signal_name and -J job_name
options with this event.
On Windows NT, you can use the SEND_SIGNAL event to signal a

specific named semaphore. Then, you can program your
application to watch for and react to that semaphore signal.
Specifies the three-character AutoSys instance (e.g., ACE) to which the
event should be sent. If not specified, sendevent will use the value of
the environment variable named $AUTOSERV.
-A alarm
Specifies the name of the alarm to be sent. This option is only used
when the specified event is ALARM; it is required when using this
event. (For the allowable values of alarm, see Chapter 5, System
States.)
-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.
-s status
Specifies the status to which the job specified in -J job_name should be
changed. This option is used only when the specified event is
CHANGE_STATUS, which requires this option.
These are the valid statuses: RUNNING, STARTING, SUCCESS,

FAILURE, INACTIVE, and TERMINATED.

sendevent
Note • Changing the status to RUNNING does not cause the job to
run. It only changes the status of the job in the database. Changing
the status of a box to INACTIVE will cause all the jobs in the box to
be changed also to INACTIVE.
-C comment
Specifies a textual comment that is to be attached to this event for,
documentation purposes only. The text string can be up to 255
characters, entered as a single line. If the text string contains spaces,
the entire string must be enclosed in double quotes.
For example, this option may be used to document why a KILLJOB

event was sent, in which case it is attached to the KILLJOB event and
is viewable in an autorep report. Or, it may be a stand-alone comment
(when issued with the COMMENT event), in which case it can be used
to post a note to the event log.
For example, this option might be used to indicate a condition which

was noticed by the operator, and is “viewable” by using the
autosyslog utility.
-P priority
Specifies the priority to be assigned to the event being sent. The value
may be from 1 to 1000, with 1 being the highest priority and 1000 the
lowest. The default value is 10. Assign a high priority if the event must
be processed immediately (for example, when attempting to place a
job which is about to be started on hold).

sendevent
-M max_send_trys
Specifies the maximum number of times sendevent will attempt to
send the event to the database. Any number of attempts may be
specified. If all the specified send attempts resulted in failure,
sendevent will exit with an exit code of “1”. The default is 0, meaning
sendevent will try indefinitely.
-q job_queue_priority
Specifies the new queue priority to be assigned to the job. This option
is only used, and is required, with the CHANGE_PRIORITY event. The
priority must be a numeric value from 0 to 99, with higher numbers
indicating a lower priority. A value of 0 signifies to start the job
immediately.
-T "time_of_event"
Specifies the date and time when the event should be processed. The
format is MM/DD/[YY]YY hh:mm, where hh denotes hours and must
be from 0 to 23. Double quotes are required as part of the
specification. This is used to schedule an event in the future. The
default is to process the event immediately.
If you enter a two digit year, AutoSys writes the setting to the database
-G "global_name=value"
Specifies the name and value of a global variable when a SET_GLOBAL
event is sent. The global_name and the value can each be a maximum
of 30 characters (leading and trailing spaces in the value are ignored).
Once a global variable is set, it can be referenced by jobs at runtime
using the syntax by the indicated job attributes in Table 1-3

sendevent
.
Table 1-3 • Attributes and Global Variable Syntax
Job Attribute Global Variable Syntax
condition VALUE(global_name)operator "value"
command $$global_name or $${global_name}
std_*_file $$global_name or $${global_name}
watch_file $$global_name or $${global_name}
To delete a global variable from the database, set it with a value of

DELETE, like this:
sendevent -E SET_GLOBAL -G "global_name=DELETE"
Note • Global variables are stored in the AutoSys database, they

are not set in the AutoSys environment. Therefore, they cannot be
referenced in the default (etc/auto.profile) or the job’s defined
AutoSys profile.
-k signal_number(s) or signal_name
For processes running on UNIX, this argument specifies the signal
number. This option is only used with the SEND_SIGNAL or KILLJOB
event. This argument is required for the SEND_SIGNAL event. For
KILLJOB events this option overrides any KillSignals specified in the
AutoSys configuration file. The signal_number(s) value can contain a
comma delimited list of signals to send to the process. In this case, the
Remote Agent will send the first signal, sleep for five seconds, then
send the next signal, and so forth. To send a signal to an entire process
group, place a minus sign (-) before the appropriate signal_number(s)
value(s).

sendevent
For processes running on Windows NT, this argument is used only

with the SEND_SIGNAL event, and it specifies the name of the
semaphore that the application is watching.
Microsoft Windows NT does not support the concept of process groups,

and thus the KILLJOB event functions differently on NT. Any
processes that were launched by user applications or batch (*.bat)
files will not be killed; only the CMD.EXE process with be killed. To
workaround this limitation, you can use modify your programs to
watch for an AutoSys signal from an AutoSys job running on an NT
machine, and you can implement this using the SEND_SIGNAL event.
For more information, see KILLJOB on page 1-109 and
SEND_SIGNAL on page 1-114.
-u
Cancels the event specified in the -E event option. This option can be
used only for unprocessed events that are scheduled to be processed
in the future. If no time is specified with the -T option, all events
satisfying the indicated criteria (options) will be cancelled. If multiple
future events exist, the -T option can be used to specify a specific event
for cancellation.
Cancelled events are not deleted from the database. Their status is
changed (e.g., que_status=4), which prevents them from being
processed.
Examples 1
1 To start a job named “test_install” that has no starting conditions (and

therefore must be started manually), enter this:
sendevent -J test_install -E STARTJOB
2 To force a job to start named “wait_job”, which is waiting on the
completion of another job, and explain the reasons for your action,
enter this:
sendevent -J wait_job -E FORCE_STARTJOB -C "tired of waiting,forced it"

sendevent
3 To change the status of a job called “ready_to_run” to ON_HOLD to

prevent its execution, and to assign the sendevent command a high
priority so it will be sent immediately, enter this:
sendevent -J ready_to_run -E JOB_ON_HOLD -P 1
When you want the above job to run, enter this:
sendevent -J ready_to_run -E JOB_OFF_HOLD
4 To prevent a job called “lock_out” from running between the hours of
11:00 a.m. and 2:00 p.m., a pair of sendevent commands could be
used to place it on hold during that time. (These same sendevent
commands could be placed in a job that is run daily to perpetuate this
condition on a regular basis.)
To put the job on hold at 11:00 a.m., enter this:

sendevent -J lock_out -E JOB_ON_HOLD -T "11/08/1997 11:00"
To take the job off hold at 2:00 p.m., enter this:
sendevent -J lock_out -E JOB_OFF_HOLD -T "11/08/1997 14:00"
5 To write a comment into the Event Processor log file, enter this:
sendevent -E COMMENT -C "have not received EOD files - an hour

late again"
6 To stop the Event Processor at 2:30 a.m. on November 9, 1997 (it is
always a good idea to attach a comment to this event), enter this:
sendevent -E STOP_DEMON -T "11/09/1997 02:30" -C "stopped for upgrade"
7 To change a job called “resource_hog” to a lower priority (it is

currently at 1 and is not yet running), and to only issue the sendevent
command 5 times, rather than letting it try indefinitely, enter this:
sendevent -J resource_hog -E CHANGE_PRIORITY -q 10 -M 5
The above command will change the job queue priority only for the
next run of the job.

sendevent
8 To kill a job named “wrong_job” which is running on another

AutoSys instance called “PRD”, enter this:
sendevent -J wrong_job -E KILLJOB -S PRD
9 To set a global variable named “today” having a value of “12/25/
1997”, enter this:
sendevent -E SET_GLOBAL -G "today=12/25/1997"
10 To delete the global variable named “today”, enter this:
sendevent -E SET_GLOBAL -G "today=DELETE"

11 To send the Unix signal number 1 to a job named “RunData”, enter
this:
sendevent -E SEND_SIGNAL -J RunData -k 1
12 To cancel all unprocessed JOB_OFF_HOLD events for a job named
“RunData”, enter this:
sendevent -E JOB_OFF_HOLD -J RunData -u

sendevent (SP)
sendevent (SP) 1
AutoSys Stored Procedure
Function 1
Issues a sendevent command directly to the dataserver.
Syntax 1
sendevent ’event’, ’job_name’, ’status’, ’alarm’,

’time_of_event’, ’comment’
Description 1
The sendevent (SP) is a call made directly to the dataserver to execute a

sendevent command. To execute the procedure, you must be logged on
to the dataserver, and you must enter the command statement using the
syntax required by the target database. All options (fields) must be
entered, even if they contain no information.
This stored procedure only can be sent to the dataserver you are currently
logged on to. If you are running Dual Event Servers, the Event Processor
will copy the event to the second Event Server before it is processed.
If you are using non-UNIX applications that can access the dataserver,
they can also issue this stored procedure.
Note • Since this procedure is done directly from the database, other
database actions can call this interface. For example, updates to tables
can be configured to generate the sendevent (SP) via “triggers” to
initiate a job.
WARNING • Using sendevent (SP) bypasses the AutoSys security

feature for Execute permissions on jobs.

sendevent (SP)
Options 1
event
Specifies the event to be sent; e.g., STARTJOB. For a list and
explanations of the events you can send, see the sendevent command
on page 1-108. (All the same events can be sent with exception of the
SEND_SIGNAL event.)
job_name
Specifies the name of the job to which the specified event should be
sent. If the event is SET_GLOBAL, specify global_name=value instead
of job_name.
status
Use this option only when the specified event is CHANGE_STATUS; in
this case, this option is required. status specifies the status to which
the job specified in job_name should be changed.
alarm
Use this option only when the specified event is ALARM; in this case,
this option is required. alarm specifies the name of the alarm to be
sent. (For the allowable values of alarm, see Chapter 5, System States.)
time_of_event
Specifies the date and time when the event should be posted. The
format is the same date and time format that is currently being used
for the Event Server to which the command is issued. If a null is input,
the current date and time is used.
comment
Specifies a textual comment (up to 255 characters) to be attached to
this event.

sendevent (SP)
Examples 1
1 To immediately start a job named “test_job” on a Sybase dataserver

that you are currently logged onto, enter this:
1> sendevent ’STARTJOB’,’test_job’,’’,’’,’’,’’
2> go
2 If you are currently logged onto an Oracle dataserver and want to
change the status of a job named “test_job” to INACTIVE on
December 25, 1997, with a textual comment, enter this:
SQL> declare
2 rc int;
3 begin
4 rc := sendevent
(’CHANGE_STATUS’,’test_job’,
’INACTIVE’,’’, ’12:00:00 12/25/1997’,
’Reset for today’);
5 end;
6 /
3 To set a global variable named “Today” on a Sybase dataserver that
you are currently logged onto, enter this:
1> sendevent ’SET_GLOBAL’,’Today=12/12/1997’,’’,
2> ’’,’’,’’
3> go

xql
xql 1
Function 1
Provides direct access to the Sybase dataserver, allowing the user to query
the database itself. For Sybase versions of AutoSys only.
Syntax 1
xql -U user_name -P password [-S server] [-D database]

[-c "command_string" | -f input_file] [-d delimiter] [-l]
[-T timeout_interval]
Description 1
xql is the AutoSys-supplied utility that accesses the Sybase dataserver

from any properly configured client. It can be used as an interactive
interface to the dataserver (like isql), as a command issued at the UNIX
command line, or in a shell script (batch mode) to send requests to the
server and output results.
xql also serves as a useful tool for determining whether or not the
AutoSys database is accessible at all, given the current configuration and
state of the environment variables. Often, when AutoSys problems arise,
these variables are not set correctly, or the AutoSys or Sybase
configuration files are not set up properly. xql can be used to detect that
situation; as a result, xql should not be overlooked as a troubleshooting
tool.

xql
Batch Mode
To execute xql in batch mode and have the results sent to standard
output, you specify either the -c option, the -f option, or redirect
standard input into xql. The -c option will read its SQL input from the
command_string argument and the -f option will read its SQL input from
the file specified in input_file. Batch mode is particularly useful for
embedding SQL statements inside of shell scripts. (An example script is
given below.) When using the -c option, you must enter “go” to mark the
end of the SQL statement.
Interactive Mode
To execute xql interactively, you omit the -c and -f options; as a result,
the standard output will not be redirected into xql. The xql prompt looks
like the following:
xql>>[AutoSysDB][autosys] 1>
The second token in the prompt (AUTOSYSDB in this example) displays the
name of the dataserver to which you are connected. The third token is the
name of the database that you are currently in. At this prompt, xql is
waiting for input, in the form of Transact SQL—Sybase’s extended SQL
language. The SQL can extend across multiple lines. To execute the SQL,
you enter a semi-colon (;) at the end of the SQL statements, or enter “go”
on a new line.
Help is available in interactive mode by typing “help” at the xql

command prompt. The Help screen is displayed in the examples below.
There is a history feature which allows you to re-use past commands

stored in the buffer. Also, an editing feature, which uses emacs or vi, is
available to edit the buffer before sending it to the Server.
To exit xql, you enter exit at the prompt and press either <Return> or
<Control+d>.
Note • xql is provided only for use with the Sybase database. If you
are using Oracle, you can use Oracle’s sqlplus.

xql
Options 1
-U user_name
Specifies the name of the Sybase user to log in as, and can be any valid
Sybase user. This is typically “autosys” for the AutoSys user, or “sa” for
the system administrator.
-P password
Specifies the Sybase password for the specified user_name. By default,
the “autosys” user’s password is “autosys” and, for bundled Sybase,
the “sa” password is “sysadmin”. You can change both of these
passwords, and you should for security reasons. The password must
not be null.
-S server
Specifies the name of the Sybase dataserver to be accessed. The default
value is taken from the environment variable $DSQUERY. If no server is
specified, and $DSQUERY is not defined, xql will terminate. For the
database bundled with AutoSys, this value is normally AUTOSYSDB.
-D database
Specifies the specific Sybase database to be accessed. For the database
bundled with AutoSys, this value is normally “autosys”. If no database
is specified, it is taken from the environment variable $DSDB, if
defined. If this variable is not defined, the default database for the
identified user is taken from the user table in the master database. For
the user “sa”, this is typically “master”; for “autosys”, it is normally
“autosys”.

xql
-c "command_string"
Specifies an SQL statement to be passed to Sybase and executed in
“batch”, rather than interactive mode. The SQL statement must be
wrapped in double quotes. Multiple lines of input, as well as multiple
Sybase commands, can be entered in a single call. (See the examples
below.) xql will send this command to the dataserver, then send the
results to standard output. This option is particularly useful for
embedding SQL commands in shell scripts.
In this non-interactive mode, column names (i.e., field names) are

not output unless the -l option is also specified.
SQL is not addressed in detail in this guide; see the Sybase SQL User’s
Guide for syntax details.
-f input_file
Specifies a text file containing SQL statements to be passed to Sybase,
to be executed in batch, rather than interactive mode. xql will send
this file of commands to the dataserver, then send the results to
standard output. In this non-interactive mode, column names (i.e.,
field names) are not output unless the -l option is also specified.
-d delimiter
Specifies the delimiter to be used for output, which is written to
standard output. The default delimiter is the pipe symbol “|”, which
is placed between all output fields. This option is useful for creating a
flat file of data that uses delimiters for processing at a later time. The
delimiter is not restricted to a single character, and can even be a string
of characters with special characters. Be sure not to use a character that
your shell could mistakenly interpret, especially the asterisk symbol
“*”.

xql
-l
Specifies that a long listing is desired, meaning that the output should
be displayed as one column name (i.e., field name) with its
corresponding value per line. The default in non-interactive mode
(using the -c or -f options) is to output the selected “records” one per
line, with multiple fields of a single record appearing on the same line.
No field names are output in the non-interactive “short” mode. This
option has no effect in interactive mode.
-T timeout_interval
Specifies a period of time after which xql will terminate the session if
no activity has occurred. The interval is specified in minutes; any
number may be specified. To specify that xql should never terminate
the session, enter “0”. The default is 15 minutes.
Examples 1
The following examples assume that the Sybase account and password
are “autosys” and “autosys” respectively. The examples also assume that
the dataserver defaults to AUTOSYSDB, and the database defaults to
“autosys”.
1 To select the job ID and job name (the field names are assigned by
AutoSys) from the job table in the default dataserver and database,
enter this (using the “autosys” user and the “autosys”, or the
appropriate, password):
xql -Uautosys -Pautosys
Then, at the xql prompt, enter this:
xql>>[AUTOSYSDB][autosys] 1> select joid,
xql>>[AUTOSYSDB][autosys] 2> job_name
xql>>[AUTOSYSDB][autosys] 3> from job;

xql
Assuming that there are only three jobs, this will be the output:
joid job_name
-------- -----------------------------
101 tester
106 test1
107 domail.tibet
To exit the interactive session, enter this:
xql>>[AUTOSYSDB][autosys] 1> exit
2 To obtain the same information as above by way of the “batch” mode
and entering the SQL statement at the command line, enter this:
xql -Uautosys -Pautosys -c "select joid, job_name from job go"
Note the “go” at the end of the command line—a semi-colon will not
be accepted.
The output, with the default delimiter, would appear as follows:

101|tester
106|test1
107|domail.tibet
3 To use the percent sign “%” as the delimiter and specify a filename
named “test.sql” containing the same select statement as shown
above, enter this:
xql -Uautosys -Pautosys -f test.sql -d %
The output would appear as follows:

101%tester
106%test1
107%domail.tibet

xql
4 To request the “long listing” of the same query, enter:
xql -Uautosys -Pautosys -l -f test.sql

The output would appear as follows:
joid 101
job_name tester
joid 106
job_name test1
joid 107
job_name domail.tibet
5 To interactively query a dataserver called “PRODSERV” and a database
called “production”, and to specify no time-out, enter this:
xql -Uautosys -Pautosys -S PRODSERV -D production -T 0
6 Multiple SQL statements can be entered at the command line as
follows (do not forget the closing quote and that each escape character
“\” must be immediately followed by the newline character):
xql -Uautosys -Pautosys -c "select count(*) \
from job go \
select joid, job_name \
from job go"
7 By invoking xql with the -c or -f option, or by redirecting input into
it, xql will execute the command or file of commands, and write its
results to standard output, then exit. This use is most common in shell
scripts where data from the database is needed.
Suppose that you want to store the number of jobs defined in the
“autosys” database in a Bourne shell script. To accomplish this, enter
the following in the script:
#!/bin/sh
#
# Example program
# Get the number of Jobs in AutoSys

xql
num_jobs=‘xql -Uautosys -Pautosys -c "select count(*) from

job”`
if [ $numjobs -gt 100 ]

then
echo "Lots of Jobs in AutoSys"
fi
8 To obtain help in interactive mode, type “help” at the xql prompt as

shown below:
xql>>[AUTOSYSDB][autosys] 1> help
The following screen will be display:
******************** xql interactive mode help*********************
* ! : Displays the history of xql queries. *
* !1: Sends query 1 from hist. to SYBASE xql cmd buffer. *
* !5 11: Sends queries 5-11 from hist. to SYBASE xql cmd buffer. *
* !? : Shows what is in the SQL command buffer. *
* go or ;: Signals the SYBASE to execute the last query again.*
* emacs : Invokes emacs editor, with current or last query. *
* vi : Invokes Vi editor, with current or last query. *
* lpron : Results of queries will be sent to printer. *
* lproff : Stops sending the Results to printer. *
* clear : Clears the screen. *
* exit/quit: Exits the xql program. *
* help : Displays help for xql Usage in Interactive mode. *
*******************************************************************

xql
See Also 1
None.

2
JIL/GUI Job Definitions
This chapter provides an alphabetical listing of all the JIL sub-commands
used to control AutoSys jobs and all the JIL and GUI-entered job
attributes for defining and describing jobs.
JIL Sub-commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
Job Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
alarm_if_fail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
auto_delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
auto_hold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
avg_runtime (JIL only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
box_failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13
box_name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
box_success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17
box_terminator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19
chk_files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21
command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-23

■ JIL/GUI Job Definitions
condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-27
date_conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-35
days_of_week . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-37
delete_box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-39
delete_job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-40
description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-42
exclude_calendar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-44
heartbeat_interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-46
insert_job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-48
job_load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-51
job_name (GUI only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-53
job_terminator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-54
job_type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-56
machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-58
max_exit_success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-61
max_run_alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-63
min_run_alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-65
n_retrys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-67
override_job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-69
owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-73
permission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-76
priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-81
profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-84
run_calendar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-87

JIL/GUI Job Definitions ■
run_window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-89
start_mins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-92
start_times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-94
std_err_file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-96
std_in_file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-99
std_out_file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-101
term_run_time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-104
timezone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-106
update_job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-109
watch_file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-111
watch_file_min_size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-114
watch_interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-116

JIL Sub-commands
JIL Sub-commands 2
JIL sub-commands are used to establish if you are creating, updating, or

deleting a job. When using the AutoSys GUI, the same instructions are
conveyed by entering values in various fields, and/or by pressing
different buttons in the GUI’s dialog boxes.
Job Attributes 2
AutoSys job attributes are used to specify everything from the name of a
new job to the specific exit conditions which must be “successful” in
order for the job to be considered completed. Job attributes can be
defined using JIL statements, which are input to the jil command, or
they can be defined using the AutoSys Graphical User Interface (GUI).
Regardless of method, the attributes are virtually the same.
Note • When issuing commands that will execute on a different

operating system (i.e., Windows NT to UNIX or UNIX to
Windows NT), you must use the syntax appropriate to the operating
system of the client machine.

alarm_if_fail
alarm_if_fail 2
JIL Attribute
GUI Path 2
Job Definition } Adv Features } Send ALARM if this Job Fails?
JIL Syntax 2
alarm_if_fail: toggle
Description
Indicates whether an alarm should be posted to the Event Processor if the
job fails or is terminated. The alarm is informational only. A defined
monitor or the Alarm Manager dialog in the Operator Console needs to
be running to view the alarm as it occurs, and an operator must take the
appropriate steps to address the situation.
Where Applicable
Command job definition
File watcher job definition
Box job definition
Values
JIL: toggle can be y or 1 for yes; or n or 0 for no.
GUI: Press the Yes or No radio button; to change your selection, press the
other button.
The default value is 1, for yes.

alarm_if_fail
Example 2
To set the job currently being created or updated to post an alarm if it fails
or is terminated, enter this:
alarm_if_fail: y

auto_delete
auto_delete 2
JIL Attribute
GUI Path 2
Job Definition } Adv Features } Delete Job after Completion?
JIL Syntax 2
auto_delete: value
Description 2
Indicates whether the job should be automatically deleted after

completion. This attribute is useful for using AutoSys to schedule and run
a one-time batch job. The number of hours after the job’s completion, at
which time the job should be deleted, can be specified (including “0” for
immediately). If it is a box job, the box and all the jobs in the box will be
deleted.
If auto_delete is set to 0, AutoSys will immediately delete job definitions

only if the job completes successfully. If the job does not complete
successfully, AutoSys will keep the job definition for seven days before
automatically deleting it.
Where Applicable 2
Box job definition

auto_delete
Values 2
JIL: value can be any number of hours; 0 indicates immediate deletion,

while -1 indicates that the job should not be deleted.
GUI: Enter the value, which can be any number of hours; 0 indicates
immediate deletion. The keyword auto_delete is omitted.
The default is to not delete the job automatically.
Example 2
To set the job to be automatically deleted 5 hours after completion, enter

this:
auto_delete: 5

auto_hold
auto_hold 2
Job Attribute
GUI Path 2
Job Definition } Adv Features } AutoHold On?
JIL Syntax 2
auto_hold: toggle
Description 2
This feature is only for jobs that are in a box. When a job is in a box, it
inherits the starting conditions of the box. This means that when a box
goes into the RUNNING state, the box job will start all the jobs within it
(unless other conditions are not satisfied).
By specifying “yes” to AutoHold On, AutoSys automatically changes the

job state to ON_HOLD when the box it is in begins RUNNING. To start
the job, take the job off hold by sending the JOB_OFF_HOLD event. This
is done with the AutoSys sendevent command.
Where Applicable 2
Command job definition, if the job is in a box
File watcher job definition, if the job is in a box
Box job definition, if the job is in a box

auto_hold
Values 2
other button.
The default value is 0 for no.
Example 2
To set the job to be automatically placed on hold, enter this:

auto_hold: y

avg_runtime (JIL only)
avg_runtime (JIL only) 2
Job Attribute
JIL Syntax 2
avg_runtime: value
Description 2
Indicates an average run time (in minutes) for a job that is newly
submitted to the AutoSys database; it establishes this value in the absence
of the job having been run multiple times. This attribute is used solely to
establish an average runtime for the new job in the avg_job_runs table,
which in turn can be used for projections and simulations in AutoSys/
Xpert.
Note • When the DBMaint script executes, it recalculates the average

runtime for each job in the database. If a new job has been submitted
with the avg_runtime attribute and has not been run yet, its average
runtime will be changed to 0.
Where Applicable 2
Box job definition
Values 2
JIL: value can be any number of minutes, to include decimal numbers.

avg_runtime (JIL only)
Example 2
To set the average run time for a new job to be five minutes, enter this:
avg_runtime: 5

box_failure
box_failure 2
Job Attribute
GUI Path 2
Job Definition: Box Completion Conditions } FAILURE Condition
JIL Syntax 2
box_failure: conditions
Description 2
Specifies the conditions to be interpreted as a box failure. The Box

Completion Conditions appears in the Job Definition dialog only when
you select a box job, and when you are opening an existing box job
definition. The default condition for a box to be considered as having
failed is that any job in the box completed with a failure condition. A box
can contain complex branching logic, which can take a number of
different paths, one of which can include recovery from a failed job. In
this case, you might not want the box to be considered a failure, even
though a job inside of it failed.
Where Applicable 2
Box job definition

box_failure
Values 2
JIL: conditions can specify any of the dependencies described in the

Starting Parameters section in Chapter 3, AutoSys Jobs, of the AutoSys User
Guide for UNIX.
GUI: Enter the conditions, which can be any of the dependencies

described in the Starting Parameters section of Chapter 3, AutoSys Jobs, in
the AutoSys User Guide for UNIX. The keyword box_failure is omitted.
The conditions can be up to 255 characters.
The default Failure Condition is that all the jobs in the box have run and
at least one failed.
Examples 2
1 To set the status of the box currently being created or updated to

FAILURE if “JobA” fails or “JobB” fails, but ignoring if “JobC” fails,
enter this:
box_failure: failure(JobA) OR failure(JobB)

FAILURE only if all three jobs fail, enter this:
box_failure: failure(JobA) AND failure(JobB) AND failure(JobC)
Note • In JIL, multiple lines of input up to 255 characters can be

specified without any continuation characters.

box_name
box_name 2
Job Attribute
GUI Path 2
Job Definition } Name of the Box this Job is IN
JIL Syntax 2
box_name: name
Description 2
Indicates the name of the box in which this job is to be placed. Boxes
allow for a set of jobs to be manipulated as a group. This feature is
particularly useful for setting starting conditions at the box level, to
“gate” the jobs inside the box, then specify their starting conditions
relative to each other individually, if necessary. The specified box must
already exist.
Where Applicable 2
Box job definition
Values 2
JIL: name can be any string of up to 30 alphanumeric characters, plus the

underscore character ( _ ).
GUI: Enter the name, which can be any string of up to 30 alphanumeric

characters, plus the underscore character ( _ ). The box_name keyword is
omitted. The entered name, the box job, must already exist.

box_name
There is no default box name.
Example 2
To specify that the job currently being created or updated should be put
in the box named “Box1”, enter this:
box_name: Box1

box_success
box_success 2
Job Attribute
GUI Path 2
Job Definition: Box Completion Conditions } SUCCESS Condition
JIL Syntax 2
box_success: conditions
Description 2
Specifies the conditions to be interpreted as a box success. The Box

Completion Conditions appears in the Job Definition dialog only when
you select a box job type, or when you are opening an existing box job
definition.
The default condition for a box to be considered successful is that every

job in the box completed with a success condition. A box can contain
complex branching logic, which can take a number of different paths, all
of which constitute success. In this case, some jobs in the box may never
need to be run, but if the default box behavior is applied, the jobs that
had not run would keep the box from ever completing.
This attribute can be used to specify what is considered a success, which

could be as simple as the success of a single job, or as complex as
necessary.
Where Applicable 2
Box job definition

box_success
Values 2
JIL: conditions can specify any of the dependencies described in the

Starting Parameters section in Chapter 3, AutoSys Jobs, in the AutoSys User
Guide for UNIX.
GUI: Enter the conditions, which can be any of the dependencies

described in the Starting Parameters section in Chapter 3, AutoSys Jobs, in
the AutoSys User Guide for UNIX. The keyword box_success is omitted.
The condition can be up to 255 characters.
The default success condition is that all the jobs in the box ran and all
completed successfully.
Examples 2

SUCCESS only when “JobA” succeeds or “JobB” succeeds, but ignoring
the status of “JobC”, enter this:
box_success: success(JobA) OR success(JobB)
SUCCESS only if all three jobs succeed, and they are the only jobs in
the box, enter nothing. This is the default behavior of box jobs.

SUCCESS only if jobs “JobA” and “JobB” succeed, and “JobC”
completes, regardless of its status, enter this:
box_success: success(JobA) AND success(JobB) AND done(JobC)
Note • In JIL, multiple lines of input+ up to 255 characters can be


box_terminator
box_terminator 2
Job Attribute
GUI Path 2
Job Definition } Adv Features } If this Job Fails should the Box be
Terminated?
JIL Syntax 2
box_terminator: toggle
Description 2
This attribute specifies whether the box containing this job should be
terminated if the job fails or terminates. By using this attribute in
combination with the Terminate the Job if the Box Fails attribute, you can
control how nested jobs react when a job fails. This attribute can only be
specified if the job being defined is being placed in a box.
Where Applicable 2
Values 2
other button.
The default setting is 0 for no.

box_terminator
Example 2
To specify that if the job currently being created or updated fails, the box
it is in should be terminated, enter this:
box_terminator: y

chk_files
chk_files 2
Job Attribute
GUI Path 2
Job Definition } Adv Features } Resource Check - File System Space...
JIL Syntax 2
chk_files: file_system_name size [file_system_name size]...
Description 2
This resource check specifies the minimum amount of file space that
must be available on designated file system(s) for the job to be started.
One or more file systems, specified with full pathnames or directory
names, and their corresponding sizes, can be specified. If multiple file
systems are specified, separate them with a single space.When the
Remote Agent is preparing to start the job on the client machine, it checks
whether the required space is available before starting the job.
If the requirements are not met, an alarm is generated. If the job is a

command job, the job will not be started; after a logarithmic-backoff type
delay, another attempt will be made to check the file system space and
start the job. If the job is a file watcher job, it will be started regardless of
the lack of available space.
In the case of a file watcher definition, the file_system_name should

identify the location where the file is expected to arrive, as specified in the
“File to Watch” attribute, and the minimum file size should be the same
as the “Minimum File Size” attribute.

chk_files
Where Applicable 2
Values 2
file_system_name
The full pathname of the file system where the file space will be
needed, and environment variables exported in the profile can be
used in the pathname.
size
Is the file space needed (in kilobytes).
Many file_system_name size pairs can be specified, separated by a

space.
The value can be up to 255 characters.
JIL: Enter one or more pairs of file_system_name size.
GUI: Enter one or more file_system_name size pairs. The keyword

chk_files is omitted.
The default is to not check the file space available.
Example 2
To specify that the job currently being created or updated should have
100K of space available on the file system named “rootfs” and 120K of
space available on the file system named “auxfs1”, enter this (using the
full pathname):
chk_files: /rootfs 100 /auxfs1 120

command
command 2
Job Attribute
GUI Path 2
Job Definition } Command To Execute
JIL Syntax 2
command: command_name command_runtime_args
Description 2
The command attribute can be the name of a command, shell script, or

application program that is to be run on the client machine (when all
necessary conditions are met). When issuing commands that are to be
run on a different operating system, you must use the syntax appropriate
to the operating system of the client machine. In addition, the job’s
owner must have execute permission for this command on the client
machine. AutoSys global variables can be used as part of the command
name itself, or as part of the command’s runtime arguments. (To set a
global variable, use the sendevent command or the Send Event dialog in
the GUI.)
This command will be executed in the environment defined in the profile

script—either the AutoSys default /etc/auto.profile, or the one
specified in the job definition (which overrides the default profile).
Therefore, if $PATH is assigned in that script, that path will be searched to
find the executable.
The full pathname can be specified, in which case, variables exported

from the profile script can be used in the pathname specification. If
variable substitution is used, enclose the variable in curly braces, like this:
${PATH}

command
These are additional points to keep in mind with regard to the command
attribute:
■ Since AutoSys performs an “exec” to run the command, you cannot

separate multiple commands with semi-colons.
■ Piping and/or redirection of standard input, output, and error files are
not allowed. Shell scripts can be invoked to execute piped commands
and attributes (such as std_in_file used for standard input) to
provide the necessary functionality.
■ You cannot use the background character (&) in the command attribute.
You can call a shell script to provide that functionality.
■ If you are running a C-Shell (csh) script, the system will attempt to
source a .cshrc file when it begins interpreting the file. Although this
might be desired, the system will also overwrite any variables defined
in the profile script (the default profile is /etc/auto.profile). If you
do not wish to have the .cshrc file sourced, you must invoke the csh
script with the -f option. For example, this should be the first line of
the script:
#!/bin/csh -f
■ All commands are run under the Bourne shell (/bin/sh). Therefore, all
statements in the profile must use /bin/sh syntax, like this:
Variable=value; export Variable
Do not use this syntax:
export Variable=value or setenv Variable Value
■ Only one file is sourced—either the default /etc/auto.profile or the
profile file specified in the job definition. Therefore, the entire
environment needed for the command must be defined in the profile
file that will be sourced.
■ Command-line arguments can be passed using global variables.

command
Note • If a command is working properly when issued at a shell

prompt, but it fails to run or run properly when specified as a command
attribute, the shell and AutoSys environments are probably different.
If this is the case, ensure that all required command variables are
specified in the AutoSys profile script, either the default one or the
one you have specified.
Where Applicable 2
Values 2
command_name
The command_name can be the name of any command, shell script, or

application program executable.
command_runtime_args
Any runtime arguments.
The command name and any runtime arguments can be up to 255

characters long. Global variables can be referenced anywhere in the
command_name or in its command_runtime_args. Global variables are
referenced using one of the following expressions:
$$global_name
Or
$${global_name}.
JIL: Enter the command_name and any command_runtime_args.
GUI: Enter the command_name and any command_runtime_args. The

keyword command is omitted.

command
There is no default command_name. The command, shell script, or

executable does not need to exist at job definition time. It must however
exist at runtime.
Examples 2
1 To specify that the UNIX date command is to be executed, enter this:
command: /bin/date
2 If the /bin directory is included in the search path, either in the /etc/
auto.profile or in the user-defined profile, the UNIX date command
can be specified to execute by entering this:
command: date
3 To specify that the “Backup” script in the /usr/common directory is to
be executed, enter this:
command: /usr/common/Backup
Or
If the /usr/common directory is included in the runtime environment
path of the job being defined, enter this instead:
command: Backup
4 To specify that the “Backup” script in the /usr/common directory is to
be passed today’s date (that has been set as the global variable named
“RunDate”), you could enter this:
command: /usr/common/Backup -D $$RunDate
5 To remove all files from the /tmp subdirectory under the directory
specified in the “MY_BACKUPS” global variable, you could enter this:
command: rm $${MY_BACKUPS}/tmp/*

condition
condition 2
Job Attribute
GUI Path 2
Job Definition } Starting Condition
JIL Syntax 2
condition: [(]condition[)][{AND | OR }[(] condition [)]]...
Description 2
When using the condition attribute, any number of job dependencies can
be specified. All dependencies must evaluate to “true” before the
dependent job will be run. Starting conditions can be one or more of the
following types of dependencies:
■ Status of a job (e.g., success(DB_BACKUP))
■ Job status across-instances (e.g., success(jobB^PRD))
■ Exit code of a job (e.g., exitcode (my_job)=4)
■ Global variables (e.g., VALUE(TODAY)=Friday)
Job can conditionally start based on the status of another job running on
a different AutoSys instances.
Note • If a condition is specified for an undefined job, the condition

will be evaluated as FALSE, and any jobs dependent on this condition
will not run. To check for this type of invalid condition statement, you
can use the chk_cond stored procedure.
These conditions are described in the sections that follow.

condition
Job Status Dependencies

Starting conditions can be as simple as specifying “JobB” to start based
on the SUCCESS status of “JobA”, and “JobC” to start when “JobB”
returns a SUCCESS status. In this way, a single-threaded, batch queue-
like logic can be implemented.
The syntax for defining job dependencies is the same regardless of

whether the job is being defined using JIL or the GUI; the only difference
is that the JIL statement will begin with the condition keyword, while the
GUI field will only contain the language for the dependency itself. The
dependency specification can take one of three forms: one based on the
current AutoSys status of other job’s, and one based on the UNIX exit
codes of other jobs, and one based on AutoSys global variables.
This is the syntax, based on AutoSys status:

status(job_name)
where:
status
Is one of the following:
success
The job_name’s status is SUCCESS.

failure
The job_name’s status is FAILURE.

done
The job_name’s status is SUCCESS, FAILURE, or TERMINATED.

terminated
The job_name’s status is TERMINATED.

condition
notrunning
The job_name’s status is anything except RUNNING.

job_name
Is the job on which the job you are defining is dependent.
Note • Either uppercase or lowercase characters can be used to specify

conditions; however, mixed case is not allowed.
These statuses are internal AutoSys settings, so their actual values don’t
need to be known. The value of the SUCCESS status can be controlled by
the user by way of the Maximum Exit Code for SUCCESS field, which can
be set for a specific job. If that attribute is specified, any job that exits with
a UNIX exit code less than or equal to the specified “Maximum Exit Code
for Success” (max_exit_success attribute) value will be treated as a
success. FAILURE means the job exited with an exit code higher than this
value. The UNIX convention, and the default, for normal job completion
is “0”. All other status settings are internally defined only. TERMINATED
means the job was actually killed.
You may abbreviate the status condition identifiers with the first letter: s,
f, d, t, and n. These abbreviations can be upper- or lowercase.
You can configure more complex conditions by combining a series of

conditions with the OR and/or the AND logical operators. You may use
the symbol | instead of the word “OR”, and the symbol & instead of the
word “AND”. Spaces between conditions and delimiters are optional.
You can specify even more complex conditions by grouping the
expressions in parentheses. The parentheses do not imply any sort of
precedence; they are simply used for grouping.
As shown above, any job status can be used as part of the specification
for starting conditions. With this latitude, you can program branching
paths to be taken that will provide alternate actions for error conditions.
The notrunning operator is used to keep jobs from running at the same
time as other jobs; that is, running one is exclusive of the other.

condition
Cross-Instance Job Dependencies

To specify a cross-instance job dependency, enter the job name followed
by a caret (^) and the name of the other instance, as in the following
example:
condition: success(jobA) AND success(jobB^PRD)
The success(jobB^PRD) condition specifies the successful completion of
a job named “jobB” running on a different instance of AutoSys specified
with the three-letter ID of “PRD”.
Note • In JIL, multiple lines of input up to 255 characters can be

Exit Code Dependencies

In addition to job status, you can base job dependencies on UNIX exit
codes that indicate completed tasks. In this way, you can implement even
more specific branching logic for recovering from job failures. For
example, if a “broken” communication line results in “JobA” failing with
an exit code of 4, you can specify that when this code occurs, you want
the system to execute a shell script (“JobB”) which redials the line. This
is the syntax you would use to specify this type of job dependency:
exitcode (job_name) operator value
where:
job_name
Is the name of the job upon which the “new” job is dependent.
operator
Is one of the following exit code comparison operators:
=, != (not equal), <, >, <=, or >=
value
Is any numeric value.

condition
You can also abbreviate the dependency specification exitcode with the
letter e (uppercase or lowercase).
Global Variable Dependencies

Job dependencies can also be based on global variables you set using the
sendevent command or the Send Event dialog. When using global
variables this way, the value of the variable must evaluate to TRUE for the
job dependency to be satisfied. Global variables are referenced using the
following expression:
condition: VALUE(global_name) operator value
where:
global_name
Is the name of the global variable already set in the database.
operator
Is one of the following (spaces around the operator are optional):
=, != (not equal), <, >, <=, or >=
value
Is any numeric value or text string (no quotes or spaces).
You can also abbreviate the dependency specification VALUE (of a global
variable) with the letter v (uppercase or lowercase).
The global_name and the value can each be a maximum of 30 characters.
You can use any job status, exit code, or global variable as part of the
specification for starting conditions. With this latitude, you can program
branching paths to provide alternative actions for all types of error
conditions.
For example, the conditions for jobs downstream from “JobA”, which
has been put “on ice” (with JOB_ON_ICE), will evaluate as shown in
Table 2-1.

condition
Table 2-1 • Evaluation of Dependent Jobs’ Conditions
If the condition is this: It will evaluate to this:
success (JobA) TRUE

failure (JobA) FALSE
terminate (JobA) FALSE
done(JobA) TRUE
notrunning (JobA) TRUE
exitcode FALSE
Where Applicable 2
Box job definition
Values 2
JIL: conditions can specify any combination of the dependencies

described above.
GUI: Enter the conditions, which can specify any combination of the
starting conditions described above. The keyword condition is omitted.
The condition can be up to 255 characters. There is no default.

condition
Examples 2
1 This is the job dependency specification for a job which is to run only
if the job named “DB_BACKUP” succeeds:
condition: success(DB_BACKUP)
2 If “JobC” should be started only when both “JobA” and “JobB”
complete successfully or when both “JobD” and “JobE” complete,
regardless of whether they failed, succeeded, or terminated, specify the
following dependency in the job definition for “JobC”:
condition: (success(JobA) AND success(JobB)) OR (done(JobD) AND
done(JobE))
3 If “JobB” fails part of the way through processing, you might want to
call a routine named “Backout” that will back out of the changes. To
do this, specify the following job dependency in the job definition for
“Backout”:
condition: failure(JobB)
4 One use of the notrunning operator could be to avoid a database
dump (“DB_DUMP”) and a file backup (“BACKUP”) at the same
time, which would cause the hard disk to be accessed very frequently.
However, you might have a smaller job that can run as long as both of
these resource-intensive jobs are not running. You would specify the
smaller job’s dependency like this:
condition: notrunning(DB_DUMP) AND notrunning(BACKUP)
5 This is the job dependency specification for the re-dial job in Exit Code
Dependencies on page 2-30, for which the prerequisite job exited with
a UNIX exit code of 4:
condition: exitcode (JobA) = 4
6 The job dependency specification for a job which is to run only if the
global variable named “OK_TO_RUN” is greater than 2 would be
entered as follows:
condition: VALUE(OK_TO_RUN)>2

condition
job named “BACKUP” completes with a SUCCESS and the global
variable named “TODAY” has a value of Friday would be entered as
follows:
condition: success(BACKUP) AND VALUE(TODAY)=Friday
Note • In multiple conditions (i.e., if “JobC” is dependent on

SUCCESS of “JobA” and SUCCESS of “JobB”), “JobC” will run
whenever both “JobA” and “JobB” have succeeded, no matter when
the first SUCCESS event occurred. For example, if you want to run
a daily processing cycle, and “JobA” finished yesterday but did not
run today, and “JobB” succeeded today, this is not the desired
behavior. The recommended method is to group these jobs in a
box.
job named “DB_BACKUP” residing on another AutoSys instance
named “PRD” succeeds, would be entered as follows:
condition: success(DB_BACKUP^PRD)

date_conditions
date_conditions 2
Job Attribute
GUI Path 2
Job Definition } Is the Start Date/Time Dependent?
JIL Syntax 2
date_conditions: toggle
Description 2
This attribute specifies whether or not there are date and/or time
conditions for starting this job. If it is set to “no”, the remainder of the
date/time related attributes will be ignored. If set to “yes”, the date can be
specified using the days_of_week attribute, or the specific dates can be
specified by associating this job with a custom calendar, created using the
Graphical Calendar facility or the autocal_asc command. Starting times
can also be specified using the start_times attribute to request specific
time(s) per day, or using the start_mins attribute to request specific
time(s) per hour. (Refer to each of these attribute’s reference pages for
further details.)
Where Applicable 2
Box job definition

date_conditions
Values 2
JIL: toggle can be a y or 1 for yes; or n or 0 for no.
other button.
The default value is 0 for no. If the default is used, all other date/time
dependencies are set to off.
Example 2
To specify that starting date and time conditions are to be in effect, enter
this:
date_conditions: y

days_of_week
days_of_week 2
Job Attribute
GUI Path 2
Job Definition } Date/Time Options } Date
JIL Syntax 2
days_of_week: {day [,day]... | all}
Description 2
Indicates the days of the week when the job will be run. One or more
days can be selected, or all days can be selected. This attribute and the
run_calendar attribute are mutually exclusive. AutoSys will schedule the
job to run on every day of the week specified by this attribute, at the times
specified in the start_times or start_mins attribute, one of which must
be specified if this attribute is used.
Where Applicable 2
Box job definition

days_of_week
Values 2
JIL: day can be any of the following:
■ mo (Monday)
■ tu (Tuesday)
■ we (Wednesday)
■ th (Thursday)
■ fr (Friday)
■ sa (Saturday)
■ su (Sunday)
■ all can be specified for every day of the week.
Note • The day specifications must be in lowercase.
GUI: Select one or more of the Monday through Sunday toggle buttons
by single-clicking on them, or select the Every Day toggle button. If days
have been selected and you decide you want to use a calendar instead, de-
select the days toggle buttons to avoid an error.
If start times are specified for a job and no dates or days have been
specified using other GUI fields, the definition is invalid.
The default is that no days will be set.
Examples 2
1 To specify that the job should be run only on weekdays, enter this:
days_of_week: mo, tu, we, th, fr

2 To specify that the job should be run every day of the week, enter this:
days_of_week: all

delete_box
delete_box 2
JIL Sub-command
Function 2
Deletes a box, and all the jobs in it, from the AutoSys database.
GUI Path 2
Job Definition } Job Name } Delete
JIL Syntax 2
delete_box: box_name
Description 2
The delete_box sub-command deletes the specified box and all the jobs
in that box. Jobs in the box, and the box itself, that are already scheduled
to run, will still be deleted and will not be run.
Values 2
box_name must be a box currently defined in the AutoSys database. There

is no default.
Example 2
To delete a box named “Box1” and all jobs inside it, you would specify
the following sub-command in the JIL script:
delete_box: Box1

delete_job
delete_job 2
JIL Sub-command
Function 2
Deletes a job from the AutoSys database.
GUI Path 2
Job Definition } Job Name } Delete
JIL Syntax 2
delete_job: job_name
Description 2
The delete_job sub-command deletes the specified job from the AutoSys
database. Even if the job is already scheduled to run, it will not be run.
delete_job checks the job_cond table and notifies you if dependent

conditions for the deleted job exist. This functionality only works when
JIL is in job verification mode, which is the default setting.
If the specified job is a box, the box will be deleted. The jobs in the box
will have their box reference removed and will become stand-alone jobs.
Note • If a box name is specified in the GUI, a delete_box on the box

and all the jobs inside of it will be performed. If a box name is
specified with JIL using delete_job, only the box is deleted, the
contained jobs are not deleted.

delete_job
Values 2
job_name
Must be a job or box currently defined in the AutoSys database. There

is no default.
Example 2
To delete a job called “Job1”, you would specify the following

sub-command in the JIL script:
delete_job: Job1

description
description 2
Job Attribute
GUI Path 2
Job Definition } Description
JIL Syntax 2
description: text
Description 2
Specifies a description for the job; for documentation purposes only.
Where Applicable 2
Box job definition
Values 2
JIL: text can be any string of alphanumeric characters, up to 255

characters. Spaces can be included. You should enclose the string in
double quotes to ensure JIL properly interprets it.
GUI: Enter the text, which can be any string of alphanumeric characters,
up to 255 characters. Spaces can be included. The keyword description
is omitted. You do not have to enclose the string in quotes; the GUI does
this for you automatically when the job definition is saved.
There is no default.

description
Example 2
To specify that the job is an incremental daily backup of the database,

enter this:
description: "incremental daily backup of the database"

exclude_calendar
exclude_calendar 2
Job Attribute
GUI Path 2
Job Definition } Date/Time Options } Do NOT Run on Days in Calendar

(Exclude)
JIL Syntax 2
exclude_calendar: calendar_name
Description 2
Indicates the name of the custom calendar to be used for determining the
days of the week on which this job will not run. The calendar must have
been previously created using Graphical Calendar facility (or
autocal_asc).
If an exclude_calendar is specified as the only date_condition and the

job has other implicit or explicit start conditions, the Event Processor will
inspect the calendar before starting the job. If the current date is on the
calendar, the job will not be started and its status will be changed to
INACTIVE. If the job’s status changes to INACTIVE and it’s in a box job,
the box will complete if all other conditions are satisfied. Also, if the job
is a box job itself and its status is changed to INACTIVE, all the jobs in
the box will be changed to INACTIVE.
Where Applicable 2
Box job definition

exclude_calendar
Values 2
JIL: calendar_name must be the name of a custom calendar that has

already been created.
GUI: Enter the name of a custom calendar that has already been created.
The keyword exclude_calendar is omitted.
The default is that no exclude calendar will be used.
Example 2
To specify that the job can be run on any day except those days specified
in the “holiday” calendar, which you have previously defined, enter this:
exclude_calendar: holiday

heartbeat_interval
heartbeat_interval 2
Job Attribute
GUI Path 2
Job Definition } Adv Features } Heartbeat Interval (mins)
JIL Syntax 2
heartbeat_interval: mins
Description 2
Specifies the frequency (in minutes) at which this job’s command is

expected to issue a heartbeat. Heartbeats are AutoSys’s way of monitoring
a job’s actual progress. It automates the common practice of outputting
characters, such as displaying asterisks, which are echoed across the
screen as a process runs in order to reflect its continued progress. The
Remote Agent that starts the job will listen for these regular heartbeats. If
the job doesn’t send a heartbeat within this specified interval, a
HEARTBEAT alarm is generated.
To send a heartbeat from a C program, call the routine found in the

following file:
$AUTOSYS/code/heartbeat.c
To send a heartbeat from a Bourne shell script, execute the code found in
the following file:
$AUTOSYS/code/heartbeat.sh
You must configure the Event Processor to check for heartbeats, and you
can do so in the AutoSys configuration file ($AUTOUSER/
config.$AUTOSERV).

heartbeat_interval
For information on sending heartbeats, see the Sending Heartbeats section

in Chapter 7, AutoSys API. For information on modifying the
configuration file, see the Heartbeats section in Chapter 13, Configuring
AutoSys, in the AutoSys User Guide for UNIX.
Where Applicable 2
Values 2
JIL: mins specifies the number of minutes; any reasonable number is

acceptable.
GUI: Enter mins to specify the number of minutes between heartbeats,

which the job should send; any reasonable number is acceptable. The
keyword heartbeat_interval is omitted.
The default is “0”, indicating that heartbeats will not be listened for.
Example 2
To set the heartbeat to be expected every 2 minutes, modify your program

to call the heartbeat routine every 2 minutes or less by entering the
following:
heartbeat_interval: 2

insert_job
insert_job 2
JIL Sub-command
Function 2
Creates a new job of one of the following types: command job, box job,
or file watcher job.
GUI Path 2
Job Definition } Job Name, Job Attribute Specification } Save
JIL Syntax 2
insert_job: job_name
Description 2
The insert_job sub-command adds a new command, box, or file

watcher job definition to the AutoSys database. The
insert_job: job_name command is followed by a list of attribute:value
statements, which are listed individually in this chapter. There are a set of
job attributes that are required for each job type.
For command jobs, the following attribute values are required:

■ insert_job: job_name
■ command: value
■ machine: value
For box jobs, the following attributes are required:

■ job_type: value

insert_job
For file watcher jobs, the following attributes are required:

■ job_type: value
■ machine: value
■ watch_file: value
Values 2
job_name
The unique job identifier used throughout AutoSys. It can be from 1

to 30 alphanumeric characters, and is terminated with white space.
Embedded blanks and tabs are illegal. There is no default.
Examples 2
1 The following example creates a command job, specifying only the

essential job attributes. The job is called “time_stamp”, is to run on
the real machine “tibet”, and simply executes the time_stamp.sh shell
script. To create this definition, enter the following sub-command and
job attributes in the JIL script:
insert_job: time_stamp
machine: tibet
command: time_stamp.sh
The job_type attribute is optional when defining a command job. To
specify a command job, enter this:
job_type: c

insert_job
2 The following example creates a Box, specifying only the essential job
attributes. The box is called “end_of_day”. To create this definition,
enter the following sub-command and job attribute in the JIL script:
insert_job: end_of_day
job_type: b
3 The following example creates a file watcher job, specifying only the
essential job attributes. The file watcher is called “EOD_batch_watch”,
is to run on the real machine “tibet”, and is to watch for a file named
/tmp/EOD_batch. To create this definition, enter the following sub-
command and job attributes in the JIL script:
insert_job: EOD_batch_watch
job_type: f
machine: tibet
watch_file: /tmp/EOD_batch

job_load
job_load 2
Job Attribute
GUI Path 2
Job Definition } Adv Features } Job Load
JIL Syntax 2
job_load: load_units
Description 2
Specifies the relative amount of processing power the job will consume.
The range of possible settings is arbitrary and user-defined. (For
information on how to best use this attribute, see Chapter 9, Load
Balancing and Queuing Jobs, in the AutoSys User Guide for UNIX.) Machines
can be assigned “maximum job loads”, a measure of CPU load that is
desirable to place on a machine at any given time. Similarly, jobs can be
assigned loads indicating the relative amount of processing power they
consume. This scheme allows for machine loading to be controlled, and
to prevent a machine from being overloaded.
If a job is ready to run on a designated machine, but the current load on

that machine is too large to accept the new job’s load, the job will be
queued for that machine, to be run later when sufficient resources are
available. However, for this scheme to function properly, all jobs to be
run on a controlled machine must have job loads specified; otherwise, a
job could be started on a machine without the machine showing the
additional load.
The default priority of a job is 0, which means that the job should run
immediately and ignore any available load units. Therefore, whenever
you set a job_load for a job, you should also set a priority of 1 or higher
for the job_load to take effect.

job_load
Note • You cannot use the priority or job_load attribute if you

specify a user-defined load balancing script in the machine attribute.
Where Applicable 2
Values 2
JIL: load_units specifies the relative load of the job, and can be any
arbitrary value within the user-defined range of possible values (which
are also arbitrary).
GUI: Enter load_units, which specifies the relative load of the job. This
number can be any arbitrary value within the range of possible values the
user has defined (which are also arbitrary).
The default is that no load is assigned.
Example 2
To set the job load for a job that typically uses 10% of the CPU, with a
range of possible load values from 1-100, enter this:
job_load: 10

job_name (GUI only)
job_name (GUI only) 2
Job Attribute
GUI Path 2
Job Definition } Job Name
JIL Syntax 2
None.
Description 2
Specifies the name of the job using the GUI. When JIL is used, this
attribute is included with the JIL sub-command; e.g., insert_job:
job_name. This attribute must be unique within a single instance of
AutoSys, since it is the primary identifier of the job. The name cannot be
changed once the job has been defined.
Where Applicable 2
Command job definition—using GUI only
File watcher job definition—using GUI only
Box job definition—using GUI only
Values 2
In the Job Definition dialog, enter the job name. The job name can be up
to 30 alphanumeric characters, including the underscore character ( _ ).
There is no default; this field is always required.

job_terminator
job_terminator 2
Job Attribute
GUI Path 2
Job Definition } Adv Features } If the Box Fails should this job be
Terminated?
JIL Syntax 2
job_terminator: toggle
Description 2
This attribute specifies whether the job should be terminated if the box it
is in fails or terminates. By using this attribute in combination with the
Terminate the Box if the Job Fails attribute, you can control how
nested jobs react when a job fails. This attribute only applies if the job is
being placed in a box. The job is terminated with a KILLJOB event.
For information on sending KILLJOB events, see sendevent in Chapter 1,

AutoSys Commands.
Where Applicable 2
Values 2

job_terminator
other button.
The default value is 0, for No.
Example 2
To specify that if the box containing the job currently being created or
updated fails, the job should be terminated, enter this:
job_terminator: y

job_type
job_type 2
Job Attribute
GUI Path 2
Job Definition } Job Type
JIL Syntax 2
job_type: type
Description 2
Specifies whether the job is a command job, file watcher job, or box job.
Where Applicable 2
Box job definition
Values 2
JIL: type can be any one of the following:
c (command)
f (file watcher)
b (box)
GUI: Press the appropriate Box, Command, or File Watcher radio button;
to change your selection, press a different button.
The default value is c, specifying a command job.

job_type
Example 2
To set the job currently being created or updated to be a box job, enter
this:
job_type: b

machine
machine 2
Job Attribute
GUI Path 2
Job Definition } Execute on Machine
JIL Syntax 2
machine: {machine_name [, machine_name]...| ‘machine_chooser_script‘}
Description 2
Specifies the client machine where the job will be run, under the control
of the Remote Agent. The owner of the job must have permission to
access this machine as well as permission to execute the specified
command on this machine. The machine can be a specific real machine,
as listed in the /etc/hosts file on the AutoSys server machine, a set of real
machines, or a virtual machine. Specifying the machine “localhost” tells
AutoSys to run the job on the machine where the Event Processor is
currently running.
WARNING • If you have implemented the Shadow Event Processor
feature, you should never set the machine attribute to localhost.
localhost implies: “run on the machine on which the Event Processor is
currently running.” The job may run normally on the Primary Event
Processor machine, and yet fail on the Shadow Event Processor machine.

machine
Alternatively, you can specify a program that the Event Processor will
execute at runtime to determine which machine will be used. This
program can be the svload program provided by AutoSys or it can be a
program or script that you write yourself. The Event Processor runs this
program and writes the name of the machine to standard output; this
output will be substituted as the name of the machine. The fully qualified
program or script name must be enclosed in back quotes.
Note • If you specify the svload program or a load balancing program

or script that you wrote yourself, you cannot use the priority or
job_load attribute.
Virtual machines and the svload program are described in Chapter 9,

Load Balancing and Queuing Jobs, of the AutoSys User Guide for UNIX. The
chapter also addresses how AutoSys chooses a machine on which to run
when multiple machines are specified.
Where Applicable 2
Note • For a file watcher, you must specify one real machine.
Values 2
JIL: machine_name can be any real machine, virtual machine, or set of real
machines. The name can be up to 80 characters.
GUI: Enter the machine_name, which can be any real machine, virtual
machine, or set of real machines. The name can be up to 80 characters.
Omit the keyword machine.
There is no default; this attribute must always be explicitly specified.

machine
Examples 2
1 To specify that the job be executed on either of the machines named

“tibet” or “socrates”, enter this:
machine: tibet, socrates
2 To run the svload program at runtime to determine which machine to
use, enter this:
machine: ’svload -a alg [-v virt | -l list] -p profile’
3 To run the script /usr/local/bin/my-machine-chooser at job runtime
to determine which machine to use, enter this:
machine: ’/usr/local/bin/my-machine-chooser’

max_exit_success
max_exit_success 2
Job Attribute
GUI Path 2
Job Definition } Adv Features } Maximum Exit Code for SUCCESS
JIL Syntax 2
max_exit_success: exit_code
Description 2
Specifies the maximum UNIX exit code with which the job can exit and
still be considered a success by AutoSys. An exit code equal to or less than
this value will be considered a success. This attribute is used when a
command can exit with more than one exit code, indicating either
“degrees of success” or other conditions that cannot indicate a failure. It’s
useful when defining complex branching logic based on real-time
processing.
Where Applicable 2
Values 2
JIL: exit_code can be any integer representing a UNIX exit code.
GUI: Enter the exit_code, which can be any integer representing a UNIX
exit code. Omit the keyword max_exit_success.
The default is “0”, which is the normal exit code for UNIX executables.

max_exit_success
Example 2
To set the job to be considered successful when exiting with any exit code
of “2” or less, enter this:
max_exit_success: 2

max_run_alarm
max_run_alarm 2
Job Attribute
GUI Path 2
Job Definition } Adv Features } Maximum Run Time
JIL Syntax 2
max_run_alarm: mins
Description 2
Specifies the maximum run time (in minutes) that a job should require
to finish normally. This “reasonability” test can catch an error, such as the
application stuck in a loop or waiting on a system event that never occurs.
If the job runs longer than this time, an alarm is generated. Alarms are
informational only. You must have a monitor or the Alarm Manager
running to track alarms in real time.
In particular, we recommended that you include a max_run_alarm

attribute for file watcher jobs to keep them from running indefinitely;
this, for example, would address situations such as a communication link
being down and preventing the arrival of a file.
Where Applicable 2
Box job definition

max_run_alarm
Values 2
JIL: mins can be any integer; it represents the maximum number of

minutes the job should ever require to finish normally.
GUI: Enter the mins, which can be any integer; it represents the maximum
number of minutes the job should ever require to finish normally. Omit
the keyword max_run_alarm.
The default is to not set a maximum at all.
Example 2
To set the job to be considered as running too long if it runs for more
than an hour and a half, enter this:
max_run_alarm: 90

min_run_alarm
min_run_alarm 2
Job Attribute
GUI Path 2
Job Definition } Adv Features } Minimum Run Time
JIL Syntax 2
min_run_alarm: mins
Description 2
Specifies the minimum run time (in minutes) that a job should require
to finish normally. This “reasonability” test can catch an error, such as the
input file being truncated due to an error. If the job runs in less than this
time, an alarm is generated. Alarms are informational only. You must
have a monitor or the Alarm Manager running to track alarms in real
time.
Where Applicable 2
Box job definition
Values 2
JIL: mins can be any integer; it represents the minimum number of

GUI: Enter the mins, which can be any integer; it represents the minimum
the keyword min_run_alarm.

min_run_alarm
The default is to not set a minimum.
Example 2
To set the job to be considered as completing too quickly if it runs for less
than an hour and a half, enter this:
min_run_alarm: 90

n_retrys
n_retrys 2
Job Attribute
GUI Path 2
Job Definition } Adv Features } Number of Times to Restart this Job after
a FAILURE
JIL Syntax 2
n_retrys: attempts
Description 2
Specifies how many times, if any, the job should be restarted after exiting
with a FAILURE status. If a job is TERMINATED, it will not restart. This
attribute applies to application failures (e.g., AutoSys is unable to find a
file or a command, or permissions are not properly set); it does not apply
to system or network failures (e.g., machine unavailability, the socket
connect timed out, the fork in the Remote Agent failed, or the file system
space resource check failed). Job restarts after system or network failures
are controlled by the MaxRestartTrys parameter in the AutoSys
configuration file.
Note • The delay between restarts is determined by the

RestartConstant and RestartFactor parameters in the AutoSys
configuration file, and the delay is capped by the MaxRestartWait
parameter.

n_retrys
Where Applicable 2
Box job definition
Values 2
JIL: attempts can be any integer between 1 and 20.
GUI: Enter attempts, which can be any integer between 1 and 20. Omit
the keyword n_retrys.
The default is 0, indicating the job will not be restarted.
Example 2
To set the job to be automatically restarted up to 5 times after an

application failure (not system or network related), enter this:
n_retrys: 5
This means that the job would start as scheduled, and, if it fails, it would
restart up to five additional times for a total of six attempts.

override_job
override_job 2
JIL Sub-command
GUI Path 2
Job Definition } Edit OneTime Over-Rides
Function 2
Specifies a job override for the next run of a job.
JIL Syntax 2
override_job: {job_name | job_name delete}

attribute_keyword: {value | NULL}
Description 2
The override_job sub-command specifies that a one-time override be

applied to a particular job, for the indicated attributes. If an AutoSys
RESTART event is generated because of system problems, AutoSys will
reissue the job override until the job actually runs once, or until the
maximum number of retries limit is met. After this, the override is
discarded.
Note • The maximum number of job restarts after system or network

failures is specified in the MaxRestartTrys parameter in the AutoSys
configuration file.

override_job
These are the job attributes you can use for a job override:
auto_hold min_run_alarm std_in_file
command n_retrys std_out_file
condition profile term_run_time
date_conditions run_calendar watch_file
days_of_week run_window watch_file_min_size
exclude_calendar start_mins watch_interval
machine start_times
max_run_alarm std_err_file
JIL will not accept an override if it results in an invalid job definition. For
example, if a job definition has one starting condition, start_times, JIL
will not allow you to set the start_times attribute to NULL because
removing the start condition makes the job definition invalid (no start
time could be calculated).
All job override information is kept in a table named “overjob” in the

AutoSys database. The override has a value of over_num assigned to it
when you save the job definition, and is kept in the job_status table until
runtime. You reference this over_num value when you want to know what
overrides were applied after a job run.
For example, when applying a job override, the Event Processor will
specify the override it is using, as shown below:
Job: JOB_NAME is using Over-Ride #14

override_job
Note • You cannot edit a job override that has been specified using
JIL. If you specify an override for a job and one already exists, the new
override replaces the original one. However, the original override(s)
(i.e., their over_num) are still maintained in the overjob table in the
AutoSys database.
Values 2
job_name
Must be a job or box currently defined in the AutoSys database. There

is no default.
delete
Used to cancel a previously specified job override.

NULL
Used to delete or negate any currently existing value for the indicated
attribute_keyword.
Examples 2
1 To specify a one-time job override for the job named “job1” to change
the standard output file, enter the following sub-command and
attribute in the JIL script:
override_job: job1
std_out_file: /usr/out/run.special
2 To specify a one-time job override for the job named “jobA” to delete
its job dependency condition and change the standard output file,
enter the following sub-command and attributes in the JIL script:
override_job: jobA
std_out_file: /usr/out/run.special

override_job
3 To cancel the job overrides specified in Example 2 above, enter the

following sub-command in the JIL script:
override_job: jobA delete

owner
owner 2
Job Attribute
GUI Path 2
Job Definition } Owner
JIL Syntax 2
owner: {user@machine | user}
Description 2
Specifies the owner of the job. The owner is the user who invoked jil or
the GUI Control Panel to define the job. This user will own all jobs
defined during the session, and will have edit permission on the jobs.
The UNIX command specified in that job will be run under the user ID
of the owner. When a command is started on the Remote Agent, the uid
of the process is changed to the owner of the job.
The default owner is defined as user@machine. Therefore, only the specific

user on the specific machine can edit the job. In order for the job to run,
this user@machine combination must have execute permission on the
UNIX command specified in the job, on the client machine for the job.
The owner cannot change this ownership designation. Only the Edit
Superuser can change the owner of a job. However, the owner can grant
other users edit permission, as well as execute permission, on the job.
Execute permission controls which users can issue sendevent commands
on the job, such as STARTJOB or KILLJOB. However, it does not affect
under who’s permissions the job’s command is executed.

owner
If remote authentication has been activated using the autosys_secure

command (see autosys_secure in Chapter 1, AutoSys Commands), the
user’s permission on the Remote Agent is checked at job runtime. This is
done by having the Remote Agent make the ruserok() system call. This
function checks the Remote Agent’s /etc/hosts.equiv and the user’s
.rhosts files to validate that the requesting user is registered in that
environment. This is a “local” verification; it is not related in any way to
rshd or rlogind, which rely on the configuration of the Remote Agent’s /
etc/services and /etc/inetd.conf files.
Note • If the rshd and rlogind are disabled on a client, but the /etc/
hosts.equiv and the .rhosts files are configured correctly, users will
not be able to rlogin or rsh to the client machine, but they will be able
to run AutoSys jobs on it.
Where Applicable 2
Box job definition
Values 2
The default setting for user@machine is the user who initiated jil or the
GUI Control Panel to define the job at the machine that user was logged
onto. Only the Edit Superuser can modify this attribute.
JIL: user@machine can be any valid user with an account on the specified
machine, which must be a real, not a virtual machine. The user must have
an account on all machines where the job can be run.
GUI: Enter user@machine, which can be any valid user with an account
on the specified machine, which must be a real, not a virtual machine. The
user must have an account on all machines where the job can be run.
Omit the keyword owner.

owner
The Edit Superuser can change the owner of an individual job by using
the update_job JIL sub-command, or by using the AutoSys Job Definition
screens. To change a large number of jobs, the Edit Superuser can invoke
the autorep command to dump multiple JIL job definitions to an output
file, change the owner, and re-load the changed job definitions using the
jil command. The following example shows how to save all job
definitions to a file:
autorep -J ALL -q > dump_file
The output of this command is formatted exactly as a JIL job definition
script, like this:
insert_job: test_job
job_type: c
command: sleep 60
machine: juno
owner: jerry@jupiter
permission: gx,ge,wx
alarm_if_fail: 1
The owner field of each job definition is usually commented out, unless
the Edit Superuser runs the autorep command to generate the report.
This is because only the Edit Superuser can change the owner field.
After generating this report, the Edit Superuser can use a text editor to
change the owner field and re-load the job definitions into the AutoSys
database using the jil command, as follows:
jil < dump_file
Example 2
For the Edit Superuser to change the owner such that “chris” on any
machine in the network can edit the job, and the job’s command will run
with the permissions of “chris”, enter this:
owner: chris

permission
permission 2
Job Attribute
GUI Path 2
Job Definition } Adv Features } Permissions
JIL Syntax 2
permission: permission [, permission]
Description 2
The AutoSys permission scheme is based on the same permissions used

in native UNIX. It uses the user ID (uid), and group ID (gid) from the
UNIX environment to control who can edit job definitions and who can
execute the actual command specified in the job. (If you are defining jobs
that are to run on different operating systems, use the permissions
applicable to the operating system of the client machine.)
AutoSys uses the concept of three levels of users for any job. These levels
are:
■ Owner—The user who created the job.
■ Group—Any user who is in the same group as the owner.
■ World—Every user.

permission
Also, as in UNIX, there are multiple levels of permissions associated with

a job. Every job has the following levels of permissions:
■ Edit—The user can edit, override, or delete the job definition itself.
■ Execute—The user can affect the running of the job, typically by

issuing a sendevent command. These are the events users can execute:
• STARTJOB
• FORCE_STARTJOB
• KILLJOB
• DELETEJOB
• CHANGE_STATUS
• JOB_ON_HOLD, JOB_OFF_HOLD
• JOB_ON_ICE, JOB_OFF_ICE
• SEND_SIGNAL
The default owner is the user who initiated jil or the GUI to define the
job. The job owner has edit permission on the job, and the UNIX
command specified in the job is run under that user ID.
When a command is started on the machine specified in the job

definition, the uid of the process is changed to that of the owner of the
job. This is done with the setuid(uid) system call.
User and Permission Types

When a job is first created, the user ID is retrieved from the environment
and attached to the job. Then, the current value of the owner’s umask is
used to supply default permissions to the job. The umask “write”
permission is used as the default “edit” permission of the job, and the
umask “execute” permission is used as the default “execute” permission of
the job.

permission
Where Applicable 2
Box job definition
Values 2
When a job is first created, the user ID is retrieved from the environment
and attached to the job. Then the current value of the owner’s umask is
used to supply default permissions to the job. The umask “write”
permission is used as the default “edit” permission of the job, and the
umask “execute” permission is used as the default “execute” permission of
the job.
JIL: These are the possible values for the permission attribute:
gx
Group Execute
ge
Group Edit
mx
Execute by any authorized users, regardless of the machine they are on

(otherwise they must be logged onto the machine specified in the
owner field, i.e., user@machine)
me
Edit by any authorized users, regardless of the machine they are on

(otherwise they must be logged onto the machine specified in the
owner field, i.e., user@machine)
wx
World Execute

permission
we
World Edit
The order of occurrence is not important.
GUI: Select the desired permissions by single-clicking the appropriate

Permissions toggle buttons. The All Hosts buttons indicate whether or
not the permission should be granted regardless of the machine the user
is on. By default, the permissions apply only if the user is logged onto the
machine on which the job was created.
The default group and world permissions are based on the user’s umask
setting. Machine permissions are turned off.
The owner of the job always has full edit and execute permissions.
Job Permissions and Windows NT 2
If you are defining jobs and running them on different operating systems,
keep the following in mind:
■ When defining a job to run on an NT machine, you can set group

permissions, but they will be ignored. Group permissions will be used
if a job is edited or executed on a UNIX machine.
■ When editing a job from an NT machine, the group edit permission is

ignored. In this case, the user editing the job must be the owner of the
job, or World Edit permissions must be specified for the job.
■ When executing a job from an NT machine, the group execute

permission is ignored. In this case, the user executing the job must be
the owner of the job, or World Execute permissions must be specified
for the job.

permission
Example 2
To set the job to allow anyone to execute it, but to allow only members
of your group to edit it, enter this:
permission: ge, wx

priority
priority 2
Job Attribute
GUI Path 2
Job Definition } Adv Features } Que Priority
JIL Syntax 2
priority: priority_level
Description 2
Specifies the queue priority of the job. Queues are defined in detail in
Chapter 9, Load Balancing and Queuing Jobs, of the AutoSys User Guide for
UNIX. Machines can be assigned “maximum job loads,” a measure of
CPU load desired to place on a machine at any given time. Each job is
assigned a load as well. If a job is ready to run and designated to run on
that machine, but the current load on that machine is too large to accept
the new job’s load, the job will be “queued” for that machine.
The queue priority establishes the relative priority of all jobs queued for
a given machine, the lower number indicating a higher priority.
Scenarios can arise where a CPU-intensive, high priority job cannot get
enough resources on the machine to run because smaller, lower-priority
jobs continually grab the small amounts of resource available. The
priority “banding” scheme provides a solution. Priorities have an
associated implied “band;” 1-99 is band “0”, 100-199 is band “1”, and so
forth. A band of higher priority jobs (e.g., band 0) completely blocks a
band of lower priority jobs (e.g., band 1) until all of the high priority jobs
have been run. Thus, the higher priority jobs (although demanding) will
not be delayed unnecessarily.
Although boxes cannot be queued, they can be assigned priorities. This

permits boxes within other boxes to be run according to their priority,
rather than the order in which they were defined, which is the default.

priority
Note • You cannot use the priority or job_load attribute if you

specify a user-defined load balancing script in the machine attribute.
Where Applicable 2
Box job definition
Values 2
priority_level can be any integer 0 or larger. priority_level 0 indicates

that the job should always be run immediately, regardless of the current
machine load. The lower the priority_level number, the higher the
priority; therefore, 1 is the highest possible queued priority.
The default is 0, indicating the job will not be queued at all; instead it will
run immediately, regardless of the current machine load.
Note • If a job_load is specified for a job, but its priority is allowed

to default to 0, then the current load on the machine will be ignored,
and the job will run immediately.
JIL: Enter the priority keyword and priority_level number, which can
be any number that is 0 or larger.
GUI: Enter the priority_level number, which can be any number that
is 0 or larger. Omit the keyword priority.
Examples 2
1 To set the job to always run, regardless of the current load on the client
machine, accept the default which is 0.

priority
2 To set the job to run with the highest priority, while not overriding the
machine load control mechanism, enter this:
priority: 1
3 To set the job to run in the background when the machine load is low,
enter this:
priority: 100

profile
profile 2
Job Attribute
GUI Path 2
Job Definition } Adv Features } Job Environment Profile
JIL Syntax 2
profile: pathname
Description 2
Specifies the profile that is to be sourced by the Bourne shell before the
specified command is executed. If a profile attribute is specified, that
profile is searched for on the machine on which the command is to run. The
AutoSys Remote Agent always spawns a process and starts the Bourne
shell in that process, passing it the name of the profile to be sourced. This
profile typically includes the definitions and exports of environment
variables, which can be referenced in the job’s command (especially if
the command is a shell script).
It is very important that Korn shell and C shell statements are not
included in the profile file, since the Bourne shell that AutoSys runs will
not be able to process them. The results will be, at best, unexpected. In
particular, redirection of the stdin, stdout, and stderr files will most
likely fail.
The primary environment variable in the profile is the path. If a profile is

not specified, the default AutoSys profile, /etc/auto.profile, will be
used.

profile
The only environment variable that absolutely must be set in the profile
is the $PATH variable, since it is used to locate the command specified in
the job. For Korn shell users, we recommended that any other
environment variables required to be set are either explicitly set in the
shell script that is specified as the command to be run, or that additional
shell scripts be sourced in your main shell script.
If you want the set permissions for stdout and stderr to -rw-r--r--, you
must set umask 022 in /etc/auto.profile, or, if you are using the profile
attribute, set it in the specified profile file. If you do not set this, the
stdout and stderr files will have world write permissions.
Note • If a command normally runs at the shell prompt, but fails to

run properly from AutoSys, the most likely cause of failure is a
difference between the shell environment and the environment
specified in the profile file.
Note • Either the specified profile file, or if not specified, the default
/etc/auto.profile file is sourced, not both. Therefore, if there are
environment variables in /etc/auto.profile that your command
needs to use (e.g., the path to AutoSys binaries like autostatus), make
sure to include them in your specified profile file.
Where Applicable 2
Values 2
pathname
The full pathname of the profile file to be sourced in order to establish

the job’s runtime environment. Variable substitution cannot be used.
The full pathname cannot exceed 80 characters.

profile
The default is to source the AutoSys-supplied profile named /etc/

auto.profile.
JIL: Enter the profile keyword and the full pathname of the file to be
sourced.
GUI: Enter the full pathname of the file to be sourced. Omit the keyword
profile.
Example 2
To set the user’s profile called my_profile in their home directory called
/usr/home, enter this:
profile: /usr/home/my_profile

run_calendar
run_calendar 2
Job Attribute
GUI Path 2
Job Definition } Date/Time Options } Run on Days in Calendar
JIL Syntax 2
run_calendar: calendar_name
Description 2
Indicates the name of the custom calendar to be used when determining

the days of the week on which a job will run. This attribute is useful for
complex date specification, such as running a job on the last business day
of the month. The custom calendar will list the dates and the times when
the job is to be run. The calendar must have been previously created
using the Graphical Calendar Facility or the autocal_asc command. This
attribute and the days_of_week attribute are mutually exclusive.
AutoSys will schedule the job to run on every day specified in this
calendar, at the times specified in the calendar (default calendar time is
midnight), or at the times specified in the start_times or start_mins
attribute. The start_times and start_mins attributes override any times
set in a calendar.
Where Applicable 2
Box job definition

run_calendar
Values 2
JIL: calendar_name must be the name of a custom calendar that has

already been created.
GUI: Enter the name of a custom calendar that has been previously
created. The keyword run_calendar is omitted. If you have entered a
calendar name, then decide to specify the dates or days using other fields
in the dialog, clear this field to avoid an error.
The default is that no run calendar will be used.
Example 2
To specify that the job should be run on the last business day of the
month, as specified in the previously created custom calendar named
“last_business”, enter this:
run_calendar: last_business

run_window
run_window 2
Job Attribute
GUI Path 2
Job Definition } Date/Time Options } Run Window
JIL Syntax 2
run_window: "time-time"
Description 2
Indicates the time span during which the job will be allowed to start. If
this attribute is specified, then when the job is eligible to run (based on
its starting conditions) AutoSys will check if the current time falls within
the specified run window. If it does, the job will start. If it does not, the
following calculations are used to determine whether or not to run the
job. The end of the last run window and the beginning of the next run
window are determined. If the current time is closer to the beginning of
the next run window, the job will be scheduled to start when the next run
window starts. If the current time is closer to the end of the last run
window, the job does not start and its status is changed to INACTIVE.
One Day 1 Current time is closer to the end of the last run
window; the job will not run and the state will be
changed to INACTIVE.
1 2 Current time is closer to the beginning of the

next run window; the job will be scheduled to
Next Day start when the run window starts.
run window
2

run_window
run_window is not in itself a starting condition. It is an additional control

over when the job will be allowed to start, once the starting conditions
have been satisfied.
The time range in a run window cannot span more than 24 hours.
Note • Jobs that are not in a box must have starting conditions in
addition to the run_window attribute in order for the job to be
automatically started.
Run Windows in Boxes

If the job is in a box, the job is changed to ACTIVATED state when the
box starts running. However, if the current time is not in the specified run
window, the job is changed to INACTIVE state.
If a run_window is specified as the only date_condition, the Event

Processor will calculate the time since the run_window closed and the time
until the run_window opens again.
■ If the current time is closer to the end of the run_window than the next
opening of the run_window, the status of the job is changed to
INACTIVE. If the job is in a box, the box can still run to completion.
■ If the current time is closer to the start of the next run_window, a future
STARTJOB event is issued for the next opening of the run_window.
The above calculations and actions are done so that a box can run to
completion when the run_window for a job inside the box has just closed.
For example, “jobA”, “jobB”, and “jobC” are in “box1” and “jobA” has a
run_window of 02:00 to 04:00. If “boxA” starts at 04:05, “jobB” and
“jobC” can run and “jobA” will become INACTIVE, so that the box can
complete that day. If “box1” instead starts at 16:05, “jobA” will have a
STARTJOB event set for 02:00 the next day, and the box will continue
running until the job starts the next day.

run_window
Where Applicable 2
Box job definition
Values 2
JIL: time-time must be entered in quotes, using the format

"hh:mm-hh:mm" where the hh specifies hours, in 24-hour format, and the
mm specifies minutes.
GUI: Enter the time range, using the format hh:mm-hh:mm where the hh
specifies hours, in 24-hour format, and the mm specifies minutes.
The default is that no run window will be used.
The range can overlap midnight as long as it is not more than 24 hours,
as in the following example.
Example 2
To specify that the job should be allowed to start only between 11:00
p.m. and 2:00 a.m., regardless of other conditions, enter this:
run_window: "23:00-02:00"

start_mins
start_mins 2
Job Attribute
GUI Path 2
Job Definition } Date/Time Options } Every Hour at
JIL Syntax 2
start_mins: mins [, mins]...
Description 2
Indicates the number of minutes past the hour, every hour, on the
specified days or dates, when the job will be started. The days or dates
must be specified using one of the following attributes: days_of_week or
run_calendar. This attribute overrides any times set in a run calendar.
The start_mins attribute and the start_times attribute are mutually

exclusive.
Where Applicable 2
Box job definition
Values 2
JIL: mins must be a number 0–59, representing the number of minutes

past each hour when the job will be run. The total number of characters
must not exceed 255. Multiple lines can be used without specifying a
continuation character.

start_mins
GUI: Enter a number, 0–59, representing the number of minutes past

each hour when the job will be run. The total number of characters must
not exceed 255. The keyword start_mins is omitted.
The default is that no start time in minutes will be set.
Example 2
To specify that the job be run at a quarter past and a quarter before each
hour, enter this:
start_mins: 15, 45

start_times
start_times 2
Job Attribute
GUI Path 2
Job Definition } Date/Time Options } Time(s) of Day
JIL Syntax 2
start_times: "time [, time]..."
Description 2
Indicates the times of day, in 24-hour format, on the specified days or

dates, when the job will be started. The days or dates must be specified
using one of the following attributes: days_of_week or run_calendar. This
attribute overrides any times set in a run calendar. The start_times
attribute and the start_mins attribute are mutually exclusive.
Where Applicable 2
Box job definition
Values 2
JIL: time must be specified using the format "hh:mm" where the hh
specifies hours, in 24-hour format, and the mm specifies minutes.
Be sure to include the quotes, or an error will result. The total number of
characters must not exceed 255. Multiple lines can be used without
specifying a continuation character.

start_times
GUI: Enter the time using the format hh:mm where the hh specifies hours,
in 24-hour format, and the mm specifies minutes. You can enter a comma-
separated list of times.
The total number of characters must not exceed 255. The keyword
start_times is omitted.
The default is that no start time will be set. This is an error if days or dates
are specified for this job, and no time has been specified in the other
field.
Example 2
To specify that the job be run at 10:00 a.m. and 2:00 p.m. on every
specified day or date, enter this:
start_times: "10:00, 14:00"

std_err_file
std_err_file 2
Job Attribute
GUI Path 2
Job Definition } Adv Features } File to Redirect to Standard Error
JIL Syntax 2
std_err_file: pathname
Description 2
Specifies the file to which the standard error file’s output should be
redirected. Any file for which the job owner has write permission on the
client machine can be specified as the standard error file.
By default, new information is appended to the file. By placing the

following notation as the first character(s) in the std_err_file
specification, you can specify if the error file should be appended to or
overwritten:
> Overwrite file
>> Append file
This setting overrides the instance-wide setting for the
AutoInstWideAppend parameter in the AutoSys configuration file. It also
overrides the machine-specific setting for the AutoMachWideAppend
parameter in the /etc/auto.profile file.
Note • If you are running jobs across platforms, the Event Processor
of the issuing instance controls the default behavior. For NT, the
default is to overwrite this file.

std_err_file
Where Applicable 2
Values 2
pathname
The pathname to which all error output is to be redirected. The full

pathname must be specified, although variables exported from the
profile script or from the AutoSys global variables can be used in the
pathname specification. If variable substitution is used, we
recommended that the variable be enclosed in curly braces, such as in
“${PATH}” for variables referenced in the profile file. The expression
$${global_name} should be used for AutoSys global variables. The
pathname must not exceed 80 characters.
The default is to redirect standard error file output to /dev/null.
JIL: Enter the std_err_file keyword and the full pathname for the
standard error file.
GUI: Enter the full pathname for the standard error file. Omit the keyword
std_err_file.
Examples 2
1 To set the file /tmp/test.err to receive standard error file output for
the job, enter this:
std_err_file: /tmp/test.err
2 To append new information to the error file, enter:
std_err_file: >>/tmp/test.err

std_err_file
3 To set the file /tmp/today’s_date.err to receive standard error file

output for the job, set a global variable named “Today” (using
sendevent or the Send Event dialog) to be today’s date, then enter this:
std_err_file: /tmp/$${Today}.err
4 You can create a unique identifier by appending the process id to the
filename, using $$ as shown in the following example:
std_err_file: /tmp/my_file.$$
If you want to imbed the process id in the middle of the filename, you
must follow the $$ with a dot, slash, or space (otherwise AutoSys will
try to interpret the string following the $$ as a global variable).
Therefore, the following examples are valid:
std_err_file: /tmp/my_file.$$.err
std_err_file: /tmp/my_file.$${}err
Note • In the final example above, the curly braces must be used to
separate the $$ from the string err. Otherwise, AutoSys would try to
interpret err as a global variable. If unable to find global variable err,
AutoSys would drop that part of the filename, creating a file named
my_file. (because $$err would be null).

std_in_file
std_in_file 2
Job Attribute
GUI Path 2
Job Definition } Adv Features } File to Redirect to Standard Input
JIL Syntax 2
std_in_file: pathname
Description 2
Specifies the file to which the standard input file for the job should be
redirected. Any file for which the job owner has read permission on the
client machine can be specified as the standard input file.
Where Applicable 2
Values 2
pathname
The pathname to which all standard input is to be redirected. The full

pathname must be specified, although variables exported from the
profile script or from the AutoSys global variables can be used in the
pathname specification. If variable substitution is used, the variable
should be enclosed in curly braces, such as in “${PATH}” for variables
referenced in the profile file. The expression $${global_name} should
be used for AutoSys global variables. The pathname must not exceed
80 characters.
The default is to not redirect standard input.

std_in_file
JIL: Enter the std_in_file keyword and the full pathname of the standard
input file.
GUI: Enter the full pathname for the standard input file. Omit the
keyword std_in_file.
Examples 2
1 To set the file named /tmp/test.in to be read as the standard input

file, enter this:
std_in_file: /tmp/test.in
2 To set the file named /tmp/today’s_date.in to be read as the standard
input file, set a global variable named “Today” (using sendevent or the
Send Event dialog) to be today’s date, then enter this:
std_in_file: /tmp/$${Today}.in

std_out_file
std_out_file 2
Job Attribute
GUI Path 2
Job Definition } Adv Features } File to Redirect to Standard Output
JIL Syntax 2
std_out_file: pathname
Description 2
Specifies the file to which the standard output file should be redirected.
Any file for which the job owner has write permission on the client
machine can be specified as the standard out file.
By default, new information is appended to the file. By placing the

following notation as the first character(s) in the std_out_file
specification, you can specify if the error file should be appended to or
overwritten:
> Overwrite file
>> Append file
This setting overrides the instance-wide setting for the
AutoInstWideAppend parameter in the AutoSys configuration file. It also
overrides the machine-specific setting for the AutoMachWideAppend
parameter in the /etc/auto.profile file.
Note • If you are running jobs across platforms, the Event Processor
of the issuing instance controls the default behavior. For NT, the
default is to overwrite this file.

std_out_file
Where Applicable 2
Values 2
pathname
The pathname to which all standard output is to be redirected. The

full pathname must be specified, although variables exported from
the profile script or from the AutoSys global variables can be used in
the pathname specification. If variable substitution is used, the
variable should be enclosed in curly braces, such as in “${PATH}” for
variables referenced in the profile file. The expression
$${global_name} should be used for AutoSys global variables. The
pathname must not exceed 80 characters.
The default is to redirect standard output to /dev/null.
JIL: Enter the std_out_file keyword and the full pathname of the standard
out file.
GUI: Enter the full pathname for the standard out file. Omit the keyword
std_out_file.
Examples 2
1 To set the file named /tmp/test.out to receive standard output for the
job, enter this:
std_out_file: /tmp/test.out
2 To append new information to the output file, enter:
std_err_file: >>/tmp/test.out

std_out_file
3 To set the file named /tmp/today’s_date.out to receive standard

output for the job, set a global variable named “Today” (using
sendevent or the Send Event dialog) to be today’s date, then enter this:
std_out_file: /tmp/$${Today}.out
4 You can create a unique identifier by appending the process id to the
filename, using $$ as shown in the following example:
std_out_file: /tmp/my_file.$$
If you want to imbed the process id in the middle of the filename, you
must follow the $$ with a dot, slash, or space (otherwise AutoSys will
try to interpret the string following the $$ as a global variable).
Therefore, the following examples are valid:
std_out_file: /tmp/my_file.$$.mary
std_out_file: /tmp/my_file.$${}mary
Note • In the example above, the curly braces must be used to

separate the $$ from the string “mary”. Otherwise AutoSys would
try to interpret mary as a global variable. If unable to find global
variable mary, AutoSys would drop that part of the filename,
creating a file named my_file. (because $$mary would be null).

term_run_time
term_run_time 2
Job Attribute
GUI Path 2
Job Definition } Adv Features } Terminate this Job Mins after starting
JIL Syntax 2
term_run_time: mins
Description 2
Specifies the maximum run time (in minutes) that a job should require
to finish normally. If the job runs longer than this time, it will be
automatically terminated by AutoSys.
Where Applicable 2
Box job definition
Values 2
JIL: mins can be any integer; it represents the maximum number of

GUI: Enter the mins, which can be any integer; it represents the maximum
the keyword term_run_time.
The default is “0”, indicating the job should allowed to run forever.

term_run_time
Example 2
To set the job to be automatically terminated if it runs longer than 90

minutes, enter this:
term_run_time: 90

timezone
timezone 2
Job Attribute
GUI Path 2
Job Definition } Adv Features } Time Zone
JIL Syntax 2
timezone: zone
Description 2
Allows you to schedule a job based on a chosen time zone. When the
timezone attribute is specified in a job definition, the time settings in that
job are based on the zone time zone. For example, if you define a start
time of 01:00 for a job running on a machine in Denver, and set timezone
to San Francisco (which is in the Pacific time zone, one hour earlier than
Denver), the job will start at 2:00 a.m. in Denver.
Jobs with time-based starting conditions that do not specify a time zone
will have their start event scheduled based on the time zone under which
the Event Processor is running.
The autotimezone command, documented in Chapter 1, AutoSys

Commands, is used to query, add to, or delete entries from the timezones
table.
Where Applicable 2
Box job definition

timezone
Values 2
zone
Either a time zone recognized by the operating system or a

case-insensitive string of characters corresponding to an entry in the
timezones table. The timezones table contains entries for all the
common time zones maintained by the operating system, as well as
many cities in the United States. Entries in the timezones table are
strings between 1 and 50 characters; these characters can be upper- or
lowercase letters, decimal digits, slash ( / ), hyphen ( — ), and
underscore ( _ ). AutoSys interprets the string and matches it to a time
zone value on your platform. If the string is not found there, AutoSys
searches for it in the timezones table. The table might be read multiple
times to resolve a zone value. If the zone value is not resolved after five
attempts, the job will fail. It is best to use a time zone value that is
available from your operating system to ensure that AutoSys is using
the same values as other applications running on that platform.
This is a sample of the timezone table (to display all the entries in the
table, use the autotimezone -l command):
Entry Type TZ Variable
------------------------------------
Auckland City NZ
Bahamas Alias EST5EDT
Bangkok City GMT-7
Beijing City CST-8CDT
Berlin City METS-1METD
Bogota City EST5
Bombay City IST

timezone
WARNING • Some regions may change to daylight saving time at

different days and times than the time zone in which the AutoSys server
machine is running. Any jobs scheduled to start in such a time zone will
run one hour earlier (or later) until the time zone in the job definition and
the time zone where the server is running are both in the same time
scheme (either daylight saving time or standard time).
Example 2
To set the time zone for a job definition to Chicago time, enter this:
timezone: Chicago
To set the time zone for a job definition to Pacific time, enter this:
timezone: US/Pacific
If you specify a time zone that includes a colon, you must quote the time
zone name if you are using JIL, like this:
timezone: "IST-5:30"
If you do not quote a time zone specification that contains a colon, JIL
will interpret the colon as a delimiter, producing unexpected results.
However, if you are using the GUI, you do not need to escape the time
zone specification.

update_job
update_job 2
JIL Sub-command
Function 2
Updates an existing job of one of the following types: command job, box
job, or file watcher job.
GUI Path 2
Job Definition } Job Name, Enter New or Modify Existing

Attributes } Save
JIL Syntax 2
update_job: job_name
Description 2
The update_job sub-command updates an existing command, box, or file

watcher job definition in the AutoSys database. The update_job
statement is followed by a list of attribute:value statements, which are
listed individually in this chapter.
Any attributes in the existing definition that are not explicitly replaced by
specifying the attribute in the update_job input will retain their original
settings. If many attributes need to be “unset,” it would be more efficient
to delete and re-insert the new or updated job definitions.
Values 2
job_name
The unique job identifier used to define the original job to AutoSys.
There is no default value.

update_job
Example 2
To change a pre-existing command job called “time_stamp” to run on the

real machine “paris”, rather than on the originally specified machine,
enter the following sub-command and job attribute in the JIL script:
update_job: time_stamp
machine: paris

watch_file
watch_file 2
Job Attribute
GUI Path 2
Job Definition } Adv Features } File to Watch For
JIL Syntax 2
watch_file: pathname
Description 2
Specifies the file for which this file watcher job should watch. The name
of the file to watch for must be a legal UNIX filename, and it must
identify the full pathname of the file. Variables exported from the profile
script or AutoSys global variables can be used in the pathname
specification.
This attribute is used in combination with the “watch file minimum file
size” and “watch interval” attributes to determine when a file is
considered to have “arrived”. AutoSys doesn’t actually consider a file
complete until the minimum file size is reached, and the watch interval
has detected a “steady state” (i.e., the file size has not changed between
checked intervals).
In those cases where the user has control over the application generating
the file, we recommend that the following “fail-safe” scenario be used.
Since the generating application could crash, or a communication link
could be interrupted after having written the minimum size file, AutoSys
would evaluate that the file was complete, when it actually would not be
complete.

watch_file
To circumvent this situation, we recommend that a separate, zero-length

file be created by the generating application when it’s finished writing the
data file. The application would delete this file on its next run. The file
watcher would actually be set to watch for the appearance of this
“completion indicator” file.
Where Applicable 2
Values 2
pathname
The full pathname of the file for which to watch. Variables exported
from the profile script can be used in the pathname specification. If
variable substitution is used, it is recommended that the variable be
enclosed in curly braces, such as in “${PATH}” for variables referenced
in the profile file. The expression $${global_name} should be used for
AutoSys global variables. The pathname must not exceed 80
characters.
There is no default; a pathname is always required for a file watcher.
JIL: Enter the watch_file keyword and the full pathname of the file for
which to watch.
GUI: Enter the full pathname for file for which to watch. Omit the
keyword watch_file.

watch_file
Examples 2
1 To set the file watcher to watch for a file named

/tmp/batch.input, enter this:
watch_file: /tmp/batch.input
2 To set the file watcher to watch for a file whose name has been
assigned to a global variable named “file_1”, enter this:
watch_file: $${file_1}

watch_file_min_size
watch_file_min_size 2
Job Attribute
GUI Path 2
Job Definition } Adv Features } Minimum File Size (in Bytes)
JIL Syntax 2
watch_file_min_size: bytes
Description 2
Specifies the watch file minimum size (in bytes) which determines when
enough data has been written to the file to consider it complete. AutoSys
doesn’t consider a file complete until both the minimum file size is
reached, and the watch interval has detected a “steady state” (i.e., the file
size has not changed between checked intervals). A reasonable file size
should be specified in order to ensure that a nearly empty file doesn’t
appear to be complete, while a size that is smaller than usual doesn’t
prevent the file from being considered complete.
would think the file was complete, when it actually wouldn’t be.


watch_file_min_size
Where Applicable 2
Values 2
JIL: bytes can be any integer; it represents the minimum number of bytes
in the file before it is considered complete.
GUI: Enter the bytes, which can be any integer. This number represents
the minimum number of bytes in the file before it is considered
complete. Omit the keyword watch_file_min_size.
The default is “0”, meaning the mere presence of the file is enough to
consider the file complete.
Example 2
To set the file to be considered complete when it reaches 10K bytes

(assuming the file has reached “steady state” as well), enter this:
watch_file_min_size: 10000

watch_interval
watch_interval 2
Job Attribute
GUI Path 2
Job Definition } Adv Features } Time Interval (secs) to Determine Steady

State
JIL Syntax 2
watch_interval: seconds
Description 2
Specifies the interval (in seconds) at which the file watcher job will check
for the existence and size of the watched-for file. A “steady state” is said
to have been reached when the file hasn’t grown during the specified
time interval. When the “steady state” has been reached and the file is at
least as large as the minimum file size specified in watch_file_min_size,
the file is considered complete. A reasonable interval should be specified
to ensure that the file doesn’t appear to be at “steady state” when it really
isn’t.
would think the file was complete, when it actually wouldn’t be.


watch_interval
Where Applicable 2
Values 2
JIL: seconds can be any integer; it represents the time interval between
checks of the file existence and file size.
GUI: Enter the seconds, which can be any integer; it represents the time
interval between checks of the file existence and file size. Omit the
keyword watch_interval.
The default is interval is 60.
Example 2
To set the file to be checked for a steady state every two minutes, enter
this:
watch_interval: 120

watch_interval

3
JIL Machine Definitions
and machine attributes used to define and describe real and virtual
machines.
JIL Sub-commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Machine Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
delete_machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5
insert_machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8
machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
max_load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15
type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17

■ JIL Machine Definitions
JIL Sub-commands
JIL Sub-commands 3
Certain JIL sub-commands are used to define the machines upon which
AutoSys operates.
Machine Attributes 3
There are several attributes which are used to define and describe AutoSys
machines. Machine attributes are defined using JIL statements, which are
input to the jil command.
Note • AutoSys machines can only be defined and described using JIL
statements.

JIL Machine Definitions ■
delete_machine
delete_machine 3
JIL Sub-command
Function 3
Deletes a real or virtual machine from the AutoSys database.
JIL Syntax 3
delete_machine: machine_name
Description 3
The delete_machine sub-command deletes the specified machine from

the AutoSys database. To delete a component (real) machine from a
virtual machine, while leaving the virtual machine defined, you specify
the machine attribute immediately after the command, as in the example
given below. To delete an entire virtual machine, you use delete_machine
without the machine attribute.
If a real machine was defined separately (i.e., not as part of a virtual

machine), delete_machine will delete it from the virtual machine;
however, the real machine definition will still exist.
Values 3
machine_name
Must be a real or virtual machine currently defined in the AutoSys

database. There is no default.

delete_machine
Examples 3
1 To delete a real machine named “socrates”, you would issue the

following JIL sub-command:
delete_machine: socrates
2 To delete a component (real) machine named “socrates” from a
virtual machine called “ferrari”, while leaving “ferrari” defined, you
would issue the following JIL sub-command and attribute:
delete_machine: ferrari
machine: socrates
3 To delete the entire virtual machine named “ferrari”, you would issue
the following JIL sub-command:
delete_machine: ferrari
Note • Example 3 above deletes only the virtual machine “ferrari”.

It does not however delete any real component machines that were
defined separately.

factor
factor 3
Machine Attribute
JIL Syntax 3
factor: real_number
Description 3
Indicates the factor to be multiplied by a real machine’s available CPU

cycles in order to determine the “relative available CPU cycles.” The
real_number value is used to determine on which machine a job should
be run, when more than one real machine or a virtual is specified with
the job’s machine attribute. factor is an indication of a machine’s relative
processing power. For example, a small machine can be assigned a value
of “0.2”, while a powerful machine can be assigned a value of “1.0”.
These values are arbitrary; any range can be used.
Where Applicable 3
Real Machine definition
Values 3
real_number
Any real number within a user-selected range of values. The examples

below show the ranges as 0.0-1.0; however, any reasonable
convention can be chosen.
The default value is 1.0.

factor
Examples 3
1 To set the factor for a very high-performance real machine, when a

scale of 0.0-1.0 is in use, you would enter:
factor: 1.0
2 To set the factor for a relatively low-performance real machine, when
a scale of 0.0-1.0 is in use, you would enter something similar to the
following:
factor: 0.4
3 Assume the following virtual machine has been defined:
insert_machine: italia
machine: ferrari
factor: 1
machine: alfa_romeo
factor: .8
machine: fiat
factor: .3
If a job that is ready to start has the virtual machine “italia” specified
in its machine attribute, the Event Processor would perform the
necessary calculations to determine which machine on which to run
the job, and reflect these calculations in its output log as shown
below:
EVENT: STARTJOB JOB: test_mach
Checking Machine usages using RSTATD
:<ferrari=78*[1.00]=78> <alfa_romeo=80*[.80]=64>
<fiat=2*[.30]=06>
[ferrari connected]
EVENT: CHANGE_STATUS STATUS: STARTING JOB:
test_mach

factor
The factors weigh each machine to account for variations in

processing power. In this example, even though the usage for “ferrari”
(or raw available CPU) was less than that of “alfa_romeo”, “ferrari”
was still chosen because of the following factor calculation:
( 78 * 1.0 > 80 * 0.8 )
That is, “ferrari” had more relative CPU cycles available.
If max_load attributes had been specified for the real machines above,
the following scenario would occur.
When a job is to be started on the virtual machine, AutoSys would first

determine which of its component real machines had sufficient load
units to run the job. If more than one did, AutoSys would query each
machine for its available CPU cycles, multiply it by that machine’s
factor, and choose the machine with the largest value.

insert_machine
insert_machine 3
JIL Sub-command
Function 3
Defines a new real or virtual machine.
JIL Syntax 3
insert_machine: machine_name
Description 3
The insert_machine sub-command adds a new machine definition to the

AutoSys database for one of the following:
■ Real machine
■ Virtual machine
The machine type can be specified as either r for real, v for virtual, n for
NT, or z for AutoSys/Team Agent. The component real machines in a
virtual machine definition must be all of the same type, for example, all
UNIX machines or all NT machines (not a mix).
If the machine being defined is a virtual machine, the insert_machine

sub-command is followed by one or more machine attributes that specify
real machines.
Note • AutoSys/Team Agent managed machines cannot be part of a

virtual machine.

insert_machine
A real machine specification can also include a max_load attribute to

specify how many load units are allowed on that machine
simultaneously, and a factor attribute to specify the relative processing
capacity of the machine. Both of these attributes are assigned from of an
arbitrary, user-defined range of values. max_load is used in combination
with the job_load attribute of jobs to limit the load placed on a machine
at any one time. When overloading would otherwise occur, jobs are
placed “on queue” to run later, at a time when load units become
available again.
When more than one machine is specified with the job’s machine
attribute, AutoSys must choose on which machine to run the job. In the
simplest case, this is done by querying each machine’s available CPU
cycles and multiplying it by the factor attribute to calculate the “relative
available CPU cycles.” The machine with the largest value will run the
job. (For a more detailed discussion about the usage of these load-related
attributes, see Chapter 9, Load Balancing and Queuing Jobs, in the AutoSys
User Guide for UNIX.)
A virtual machine specification is comprised of real machines, which are

defined using the machine attribute.
Any machine defined in the /etc/hosts file on the machine running the
Event Processor can be specified in the machine attribute of a job; it need
not be explicitly defined using the insert_machine command. However,
any undefined machine will have a default factor of “1.0” and no
max_load, meaning that there will be no limit on the job load assigned to
it.
Values 3
machine_name
The unique name of the machine to be defined. It can be from 1-30

alphanumeric characters, and is terminated with white space;
embedded blanks and tabs are illegal.

insert_machine
Examples 3
1 To define a real machine named “socrates”, you would specify the

following JIL sub-command:
insert_machine: socrates
type: r
2 To define a real machine named “aristotle” with a factor of 1.5 and
capable of handling up to 100 load units, you would specify the
following JIL sub-command and attributes:
insert_machine: aristotle
type: r
max_load: 100
factor: 1.5
3 To define a virtual machine named “virtual_a” to include two real
machines, named “socrates” and “tibet”, without specifying factors or
loads, you would specify the following JIL sub-command and
attributes:
insert_machine: virtual_a
type: v
machine: socrates
machine: tibet
Note • In the above definitions of virtual machines, the real

machines have no max_load and factor attributes. If the real
machines were not previously defined individually, they will be
considered identical in terms of factor and load limits. As a result,
a job specifying the virtual machine name will be scheduled on
whichever of these real machines has the most raw CPU percentage
available. Also, if the real machines are defined again outside of a
virtual machine, the stand-alone real machine can have different
values for max_load and factor. In this case, a job specifying the
virtual machine versus a job specifying the stand-alone real
machines will be handled differently.

insert_machine
4 To define a virtual machine named “virtual_b”, to include two real

machines named “ferrari” with a factor of 5.0 and a max_load of 400,
and “vw” with a factor of .2 and a max_load of 15, you would specify
the following JIL sub-command and attributes:
insert_machine: virtual_b
type: v
machine: ferrari max_load: 400 factor: 5.0
machine: vw max_load: 15 factor: .2
When a job is to be started on the virtual machine, AutoSys will first
determine which of its component real machines has sufficient
available load units to run the job. If both do, AutoSys queries each
machine for its available CPU cycles, multiplies it by that machine’s
factor, and chooses the machine with the largest value.
Note • In example 4 above, the two real machines, when specified

in a job definition by way of the virtual machine, vary considerably
in capacity from a scheduling point of view. However, when these
machines are explicitly specified by name in a job definition, the
factor and max_load attributes defined here have no bearing; they
only have these values when specified by the virtual machine name.
5 To first define two real machines individually named “socrates” and

“tibet”, then define a virtual machine named “virtual_d” to include
these real machines, you would specify the following JIL sub-
command and attributes:
insert_machine: socrates
type: r max_load: 100 factor: 1.0
insert_machine: tibet
type: r max_load: 200 factor 1.0
insert_machine: virtual_d
type: v
machine: socrates
machine: tibet
Note • In example 5 above, the max load and factor units for both
the real machines are different in the virtual machine.

insert_machine
See Also 3
The job_load section in Chapter 2, JIL/GUI Job Definitions.

machine
machine 3
Machine Attribute
JIL Syntax 3
machine: machine_name
Description 3
Specifies a real machine to be included in the virtual machine defined in

the insert_machine sub-command.
Note • This machine attribute differs from the machine attribute used in
the job definition sub-commands; in the job definitions, this attribute
assigns the job to one or more real or virtual machines. However, in a
machine definition, it makes a real machine a component of a virtual
machine.
Where Applicable 3
Machine definition
Values 3
machine_name
The unique name of the real machine to be placed in the virtual

machine definition. It can be from 1-30 alphanumeric characters, and
is terminated with white space; embedded blanks and tabs are illegal.

machine
Examples 3
1 To define a virtual machine named “virtual_a”, to include two real

machines named “socrates” and “tibet”, without specifying factors or
loads, you would specify the following JIL sub-command and
attributes:
insert_machine: virtual_a
machine: socrates
machine: tibet
Note • In example 1, the two real machines do not have their

max_load and factor attributes set. If these two real machines were
not previously defined, they will be considered identical in terms
of factor and load limits. As a result, a new job that specifies the
virtual machine name will be scheduled on the real machine with
the most raw CPU percentage available. If these machines are
defined again outside of a virtual machine, the stand-alone real
machine can have different values for max_load and factor. In this
case, a job specifying the virtual machine versus a job specifying
the stand-alone real machines will be handled differently.
2 To define a virtual machine named “virtual_b”, to include two real

machines named “ferrari”, with a factor of 5.0 and a max_load of 400,
and “vw” with a factor of .2 and a max_load of 15, you would specify
the following JIL sub-command and attributes:
insert_machine: virtual_b
machine: ferrari max_load: 400 factor: 5.0
machine: vw max_load: 15 factor: .2
Note • In example 2 above, these two real machines, when

specified using the virtual machine in a job, are considered to vary
considerably in capacity from a scheduling point of view. However,
when these machines are explicitly specified by their real names in
a job definition, the factor and max_load defined here have no
bearing; they only have these values when specified by the virtual
machine name.

max_load
max_load 3
Machine Attribute
JIL Syntax 3
max_load: load_units
Description 3
Indicates the maximum load (in load units) which a machine can
reasonably handle. Load units are arbitrary values, the range of which is
user-defined; the examples below use 1-100, for simplicity.
A max_load is assigned to each machine, indicating its relative processing

capacity. For example, a small machine can handle 10 load units, while
a powerful machine can handle 100. Likewise, jobs are assigned loads
using the job_load attribute, which indicates how much relative
processing power they require. When a job’s starting conditions are
satisfied, resulting in the job being ready to run, a machine for it to run
on needs to be chosen. If the job has the job_load attribute set, the
potential machine(s) are checked to determine whether they have
enough load units available at the time. If not enough units are available,
the job will not be run on that machine.
Note • If job_load is not set, a job will run without checking for load
units. If a priority is not set, the priority will default to 0 and the
job_load will be ignored.
If more than one machine was set in the job’s machine attribute, the other
machines will be checked for available load units. If none of the
machines presently has the necessary load units available, the job will be
“queued” on all of the specified machines, and will run on the first one
with the necessary load units available (due to the completion of another
job).

max_load
Note • The job_load attribute has nothing to do with the priority, or

ordering, of jobs in a queue. In addition, the job_load attribute
controls what machine the job will be run on only when it exceeds the
max_load of a machine, thus eliminating that machine.
Where Applicable 3
Real Machine definition
Values 3
load_units
Any real number within a user-selected range of values. The examples

below show the ranges as 1–100, but any reasonable convention can
be chosen. Zero and negative numbers cannot be used.
There is no default; therefore, if no max_load value is set, the load on

the machine will not be limited in any way.
Examples 3
1 To set the max_load for a very high-performance real machine, when a

scale of 1–100 is in use, you would enter:
max_load: 100
2 To set the max_load for a relatively low-performance real machine,
when a scale of 1–100 is in use, you would enter something similar to
the following:
max_load: 20
See Also 3
The job_load section in Chapter 2, JIL/GUI Job Definitions.

type
type 3
Machine Attribute
JIL Syntax 3
type: {r | v | n | z}
Description 3
Specifies the type of machine being defined. r specifies a real UNIX

machine; v specifies a virtual UNIX machine; n specifies an NT machine
(real or virtual); z specifies an AutoSys/Team Agent machine. For more
information on defining real and virtual machines, see the description of
the machine attribute on page 3-13.
Where Applicable 3
Machine definition
Values 3
r, v, or n, or z.

type

4
JIL/GUI Monitor/Report
Definitions
used to monitor and generate reports on AutoSys jobs and all the JIL and
Graphical User Interface (GUI) entered attributes for monitoring and
generating reports on AutoSys jobs.
JIL Sub-commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Monitor and Report Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
after_time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
alarm_verif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
all_events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10
all_status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
currun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14
delete_monbro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16
failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17

■ JIL/GUI Monitor/Report Definitions
insert_monbro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-19
job_filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-22
job_name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24
mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26
monbro_name (GUI only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28
restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-30
running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32
sound . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-34
starting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-36
success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-38
terminated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-40
update_monbro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-42

JIL/GUI Monitor/Report Definitions ■
JIL Sub-commands
JIL Sub-commands 4
Certain JIL sub-commands can be used for monitoring and generating

reports on AutoSys jobs. When using the AutoSys GUI, the same thing is
accomplished by using the corresponding fields and buttons in the
various dialogs.
Monitor and Report Attributes 4
There are a number of attributes which are used to define and describe
AutoSys monitors and reports (browsers). Monitor and report attributes
can be defined using JIL statements, or they can be defined using the GUI.
Regardless of method, the attributes are virtually the same.

after_time
after_time 4
Report Attribute
GUI Path 4
Monitor/Browser } Events After Date/Time
JIL Syntax 4
after_time: date_time
Description 4
Specifies the date and time for the start of the reporting period, which the
report being defined should cover. Only events that occurred after this
date and time will be reported on.
Where Applicable 4
Report definition
Values 4
JIL: date_time must be specified using the format MM/DD/[YY]YY hh:mm

where MM is the month, DD is the day, [YY]YY is the year, hh is the hour in
24-hour format, and mm is the minutes.
You must include the quotes, or an error will result due to the colon in
the time.
GUI: Enter the date_time, using the format MM/DD/[YY]YY hh:mm where
MM is the month, DD is the day, [YY]YY is the year, hh is the hour in 24-hour
format, and mm is the minutes.
You can omit the quotes, since colons are not reserved characters when
entered using the GUI. The keyword after_time is omitted.

after_time
The default, if the currun attribute is set to “no” is 12:00 midnight on the
specified day. If the date is omitted, it defaults to the current day. If the
currun attribute is set to “yes”, the after_time attribute is ignored.
Note • If you enter a two digit year, AutoSys saves the setting to the
database as a four digit year. If you enter 79 or less, AutoSys prepends
20, and, if you enter 80 or greater, AutoSys prepends 19.
Example 4
To report on all events after 2:00 p.m. on October 1, 1997, enter this:
after_time: "10/01/1997 14:00"

alarm
alarm 4
Monitor/Report Attribute
GUI Path 4
Monitor/Browser } Alarms
JIL Syntax 4
alarm: toggle
Description 4
Specifies whether alarms should be tracked in the monitor or report

being defined. Alarms can be tracked at the same time as other events. If
the all_events attribute is specified, all alarms will be tracked, regardless
of the alarm attribute’s setting.
Where Applicable 4
Monitor definition
Report definition
Values 4
GUI: Press the button in to indicate yes; to change your selection, press
the button again to indicate no.

alarm
Example 4
To set the monitor or report to track alarms, enter this:

alarm: y

alarm_verif
alarm_verif 4
Monitor Attribute
GUI Path 4
Monitor/Browser } Verification Required for Alarms
JIL Syntax 4
alarm_verif: toggle
Description 4
Specifies whether alarms should continue to notify the operations staff

until there is a response. When the monitor is running, the verification
feature prompts the user in the window running the monitor for their
initials and a comment. This information is time-stamped and recorded
in the database, along with the alarm event. It provides an accounting of
the events that were responded to, and when that occurred.
If a response is not given within 20 seconds, the message is repeated.

Therefore, if someone momentarily steps out of the room and an alarm
occurs, the monitor keeps writing to the window and playing the sound
clip (if specified) until someone responds.
Where Applicable 4
Monitor definition

alarm_verif
Values 4
GUI: Press the button into indicate yes; to change your selection, press
Example 4
To set the monitor to require operator verification of alarms, enter this:

alarm_verif: y

all_events
all_events 4
GUI Path 4
Monitor/Browser } ALL EVENTS
JIL Syntax 4
all_events: toggle
Description 4
Specifies whether all events should be tracked for the monitor or report
being defined. This attribute specifies whether any event filtering is in
effect. If it is set to “yes”, the other event filtering attributes are ignored,
and all events, regardless of source, will be reported for the selected jobs.
This includes job status events, alarms, and manually-generated events,
such as starting a job.
If set to “no”, the other event selection attributes, including the alarm
attribute, are used to select the events to be tracked.
Note • If you wish to monitor all events for all jobs, you should
display the Event Processor log time in real time, using the following
command instead of running a monitor:
autosyslog -e
You should do this because running a monitor adds another
connection to the database and establishes another process, which is
continually polling the database. This will have a significant impact
on system performance. Furthermore, the information logged by the
Event Processor contains more diagnostic information than a monitor
does.

all_events
Where Applicable 4
Monitor definition
Report definition
Values 4
Example 4
To set the monitor or report to track all events, whether they are AutoSys-
or manually-generated job status changes, enter this:
all_events: y

all_status
all_status 4
GUI Path 4
Monitor/Browser } ALL Job Status Events
JIL Syntax 4
all_status: toggle
Description 4
Specifies whether all job status events should be tracked by the monitor
or report being defined. Job status events occur whenever a job’s status
changes. If this attribute is set to “yes”, all of the individual job status
events, which have their own attributes, as well as a few AutoSys-internal
job status events, will be tracked.
Alarms can be tracked in addition to job status events. If the all_events

attribute is set to “yes”, the all_status attribute is ignored.
Where Applicable 4
Monitor definition
Report definition
Values 4

all_status
Example 4
To set the monitor or report to track all job status events, enter this:
all_status: y

currun
currun 4
Report Attribute
GUI Path 4
Monitor/Browser } Current Run Only
JIL Syntax 4
currun: toggle
Description 4
Specifies whether only the events in the current or most recent execution
of the specified job(s) will be reported. (Jobs are specified using the
job_name attribute, or in the Job Name field of the GUI, in combination
with the job_filter attribute or the Job Filter field in the GUI.)
Using this attribute is useful for getting a sense of what is happening

currently. For example, you could select the job status restart event using
the Restart checkbox in the GUI, or you could specify the restart
attribute with JIL. Then, you would turn off Job Filtering, by selecting all
jobs, and set the currun attribute to yes to see all of the jobs that have
been automatically restarted by AutoSys in their current or latest run.
If this attribute is set to no, the after_time attribute must be specified.
Where Applicable 4
Report definition

currun
Values 4
GUI: Toggle the button off to indicate no; to change your selection, press
the button again to indicate yes.
The default value is 1 for yes.
Example 4
To set the monitor or report to report only on events in the current or

most recent run of the specified job(s), enter this:
currun: y

delete_monbro
delete_monbro 4
JIL Sub-command
GUI Path 4
Monitor/Browser } Delete
Function 4
Deletes a monitor or report (browser) from the AutoSys database.
JIL Syntax 4
delete_monbro: monbro_name
Description 4
The delete_monbro sub-command deletes the specified monitor or report

(browser) from the AutoSys database.
Values 4
monbro_name must be a monitor or report currently defined in the AutoSys

database.
Example 4
To delete the monitor called “track_alarm”, specify the following JIL

sub-command:
delete_monbro: track_alarm

failure
failure 4
GUI Path 4
Monitor/Browser } Failure
JIL Syntax 4
failure: toggle
Description 4
Specifies whether the job status event generated when a job changes to
the failure state should be tracked by the monitor or report being defined.
If either of the all_events or all_status attributes are set to “yes”, the

failure attribute is ignored. Alarms can be tracked in addition to job
status events.
Where Applicable 4
Monitor definition
Report definition
Values 4

failure
Example 4
To set the monitor or report to track jobs changing to the failure state,
enter this:
failure: y

insert_monbro
insert_monbro 4
JIL Sub-command
Function 4
Defines a new monitor or report (browser).
JIL Syntax 4
insert_monbro: monbro_name
Description 4
The insert_monbro sub-command defines a new monitor or report

(browser). Monitors are used to monitor events within AutoSys and to
watch for specific occurrences, such as alarms. Reports are used to filter
and report on events within AutoSys. Both of these facilities are described
in Chapter 11, Monitoring and Reporting Jobs, of the AutoSys User Guide for
UNIX.
In order to use a monitor or report, it must first be defined, then it must

be run; defining it alone has no effect. In order to define a monitor or
report, several attributes must also be specified. These attributes are
discussed individually in this chapter.
For all monitors and reports, the following four specifications are
required:
■ Monitor or report name
■ mode attribute—For monitor or report

insert_monbro
■ Event selection—This can be one or a combination of the following

status events and/or alarms:
• RUNNING
• SUCCESS
• FAILURE
• TERMINATED
• STARTING
• RESTART
• ALL_STATUS (selects all statuses)
• ALL_EVENTS (selects all events)
■ alarm attribute
In addition, the following specifications can be required for the

following reasons:
■ job_name attribute—Is required if a single box or job is to be selected.
■ For all reports, the time criteria may also need to be specified. For
example, the currun attribute, which specifies that the current or latest
run of each job is to be considered, will be used by default if no other
selection is made.
Values 4
monbro_name
The unique name of the monitor or report to be defined. It can be

from 1-30 alphanumeric characters and is terminated with white
space; embedded blanks and tabs are illegal. There is no default.

insert_monbro
Examples 4
1 To define a report named “success_report” that will browse all jobs for
success in the “current” or most recent execution of the job, specify the
following JIL sub-command and attributes:
insert_monbro: success_report
mode: b /* "browser" can also be specified */
success: y
job_filter: a /* the default */
currun: y /* the default */
2 To define a monitor named “alarm_monitor” that will watch for
alarms on all jobs and sound an audible alarm, specify the following
JIL sub-command and attributes:
insert_monbro: alarm_monitor
mode: m /* "monitor" can also be specified */
alarm: y
job_filter: a /* the default */
sound: y

job_filter
job_filter 4
GUI Path 4
Monitor/Browser } Job Filter
JIL Syntax 4
job_filter: type
Description 4
Specifies which jobs are to be monitored or reported on, for the monitor
or report being defined. The events to be tracked are determined by the
combination of the various event filters and the job filter. The job filter
can be set to one of three settings: track all jobs (no filtering), track a
single box with the jobs it contains, or track a single job.
If either of the latter two settings are selected, the name of the job to be
tracked is required. This name can be specified using the job_name
attribute or the Job Name field in the GUI.
Where Applicable 4
Monitor definition
Report definition
Values 4
JIL: type can be any one of the following:

a
All jobs (no filtering).

job_filter
Box with its jobs.

j
Single job.
GUI: Select one of the following radio buttons: ALL Jobs, Box with Its
Jobs, or Single Job. To change your selection, select a different radio
button.
The default is a (ALL Jobs).
Example 4
To set the monitor or report to only track events in the box specified in
the job_name attribute, enter this:
job_filter: b

job_name
job_name 4
GUI Path 4
Monitor/Browser } Job Name
JIL Syntax 4
job_name: name
Description 4
Specifies the box or job for which events are to be monitored or reported
on, for the monitor or report being defined. The events to be tracked are
determined by the combination of the various event filters, the job filter,
and the job name. The job_name attribute is required if the job_filter
attribute is set to a single job or to a box and its jobs; otherwise, it is
ignored.
Where Applicable 4
Monitor definition
Report definition
Values 4
JIL: name must be an existing job.
GUI: Enter the name of an existing job.

job_name
Example 4
To set the monitor or report to only track events in the box called
“EOD_Box”, enter this:
job_name: EOD_Box

mode
mode 4
GUI Path 4
Monitor/Browser } Mode
JIL Syntax 4
mode: type
Description 4
Specifies whether a monitor or report (browser) is to be defined.
Where Applicable 4
Monitor definition
Report definition
Values 4
JIL: type can be one of the following:
m or monitor for a monitor.
b or browser for a report (browser).
GUI: Press the appropriate Monitor or Browser radio button; to change

your selection, press the other button.

mode
Example 4
To set the definition to apply to a report, enter this:

mode: b

monbro_name (GUI only)
monbro_name (GUI only) 4
GUI Path 4
Monitor/Browser } Name
JIL Syntax 4
None.
Description 4
Specifies the name of the monitor or report being defined, by way of the
GUI. When JIL is used, this attribute is included with the JIL sub-
command (e.g., insert_monbro: monbro_name). This attribute must be
unique for monitors and reports within an instance of AutoSys, since it
is the primary identifier of the monitor or report. The name cannot be
changed once the monitor or report has been defined, although the
monitor or report can be deleted and re-defined.
Where Applicable 4
Monitor or Report definitions, using the GUI only
Values 4
GUI: Enter the monitor or report name. The name can be up to 30

alphanumeric characters, including the special character “_”
(underscore). Embedded blanks and tabs are illegal.
There is no default setting; this field is always required.

monbro_name (GUI only)
Examples 4
None.

restart
restart 4
GUI Path 4
Monitor/Browser } ReStart
JIL Syntax 4
restart: toggle
Description 4
the restart state should be tracked by the monitor or report being defined.

restart attribute is ignored. Alarms can be tracked in addition to job
status events.
Where Applicable 4
Monitor definition
Report definition
Values 4

restart
Example 4
To set the monitor or report to track jobs changing to the restart state,
enter this:
restart: y

running
running 4
GUI Path 4
Monitor/Browser } Running
JIL Syntax 4
running: toggle
Description 4
the running state should be tracked by the monitor or report being
defined.

running attribute is ignored. Alarms can be tracked in addition to job
status events.
Where Applicable 4
Monitor definition
Report definition
Values 4

running
Example 4
To set the monitor or report to track jobs changing to the running state,
enter this:
running: y

sound
sound 4
Monitor Attribute
GUI Path 4
Monitor/Browser } Sound
JIL Syntax 4
sound: toggle
Description 4
Specifies whether the appropriate sound clip for the specified events
should be played when a tracked event is seen by the monitor being
defined. Sound is supported on SunOS, Solaris, and SGI platforms only.
If the workstation running the monitor has sound capabilities, AutoSys

will use them to announce the events as they occur. If there is no sound
capability, this attribute is ignored. The announced message is pieced
together from pre-recorded sound clips. See the record_sounds command
in Chapter 1, AutoSys Commands.
Note • You should use sound for monitoring AutoSys, especially

alarms. It frees you from needing to examine output files to see if
there are any problems. Some users have plugged their workstation
into the P.A. system, or other external amplifiers.
Where Applicable 4
Monitor definition

sound
Values 4
Example 4
To set the monitor to play the appropriate sound clip for a specified
event, enter this:
sound: y

starting
starting 4
GUI Path 4
Monitor/Browser } Starting
JIL Syntax 4
starting: toggle
Description 4
the starting state should be tracked by the monitor or report being
defined.

starting attribute is ignored. Alarms can be tracked in addition to job
status events.
Where Applicable 4
Monitor definition
Report definition
Values 4

starting
Example 4
To set the monitor or report to track jobs changing to the starting state,
enter this:
starting: y

success
success 4
GUI Path 4
Monitor/Browser } Success
JIL Syntax 4
success: toggle
Description 4
the success state should be tracked by the monitor or report being
defined.

success attribute is ignored. Alarms can be tracked in addition to job
status events.
Where Applicable 4
Monitor definition
Report definition
Values 4

success
Example 4
To set the monitor or report to track jobs changing to the success state,
enter this:
success: y

terminated
terminated 4
GUI Path 4
Monitor/Browser } Terminated
JIL Syntax 4
terminated: toggle
Description 4
the terminated state should be tracked by the monitor or report being
defined.

terminated attribute is ignored. Alarms can be tracked in addition to job
status events.
Where Applicable 4
Monitor definition
Report definition
Values 4

terminated
Example 4
To set the monitor or report to track jobs changing to the terminated

state, enter this:
terminated: y

update_monbro
update_monbro 4
JIL Sub-command
GUI Path 4
Monitor/Browser } Save
Function 4
Updates an existing monitor or report (browser).
JIL Syntax 4
update_monbro: monbro_name
Description 4
The update_monbro sub-command updates an existing monitor or report

(browser). Monitors are used to monitor events within AutoSys and to
watch for specific occurrences, such as alarms. Reports are used to filter
and report on events within AutoSys. Both of these facilities are described
in detail in Chapter 11, Monitoring and Reporting Jobs, of the AutoSys User
Guide for UNIX.
Any attributes in the existing definition which are not explicitly replaced
by specifying the attribute in the update_monbro input will retain their
original settings. If many attributes need to be “unset”, use the alternative
method of deleting and re-defining the monitor or report definition,
because it would be more efficient.
Values 4
monbro_name
The unique name of the monitor or report to be modified. There is no

default.

update_monbro
Example 4
To change a monitor called “alarm_monitor” so that it will indicate all

terminations, in addition to the already-specified alarms, specify the
following JIL sub-command and attribute:
update_monbro: alarm_monitor
terminated: y

update_monbro

5
System States
This chapter lists the events, states, alarms, and exit codes that AutoSys
can generate and process at runtime.
Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
ALARM (106) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
CHANGE_PRIORITY (120) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
CHANGE_STATUS (101) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
CHECK_HEARTBEAT (116) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
CHK_BOX_TERM (118) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
CHK_MAX_ALARM (114) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
CHK_RUN_WINDOW (122) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
COMMENT (117) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
DELETEJOB (119) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
EXTERNAL_DEPENDENCY (127) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
FORCE_STARTJOB (108) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
HEARTBEAT (115) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
JOB_ON_ICE (110) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
JOB_OFF_ICE (111) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
JOB_ON_HOLD (112) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
JOB_OFF_HOLD (113) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7

■ System States
KILLJOB (105) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7

RESEND_EXTERNAL_STATUS (128) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
SET_GLOBAL (125) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
SEND_SIGNAL(126) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
STARTJOB (107) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
STOP_DEMON (109) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
ACTIVATED (9) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
FAILURE (5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
INACTIVE (8) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
ON_HOLD (11) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
ON_ICE (7) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9
QUE_WAIT (12) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9
RESTART (10) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9
RUNNING (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9
STARTING (3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9
SUCCESS (4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-10
TERMINATED (6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-10
Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
ALREADY_RUNNING (528) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-10
AUTO_PING (526) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-10
CHASE (514) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-10
DATABASE_COMM (516) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-10
DB_PROBLEM (523) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-11
DB_ROLLOVER (519) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-11
DUPLICATE_EVENT (524) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-11
EP_HIGH_AVAIL (522) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-11
EP_ROLLOVER (520) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-11
EP_SHUTDOWN (521) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-11
EVENT_HDLR_ERROR (507) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-12
EVENT_QUE_ERROR (508) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-12

System States ■
FORKFAIL (501) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12

INSTANCE_UNAVAILABLE (525) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12
JOBFAILURE (503) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12
JOBNOT_ONICEHOLD (509) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12
MAX_RETRYS (505) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
MAXRUNALARM (510) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
MINRUNALARM (502) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
MISSING_HEARTBEAT (513) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
OB_SHUTDOWN (527) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
RESOURCE (512) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14
STARTJOBFAIL (506) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14
VERSION_MISMATCH (518) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14
AutoSys Exit Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15

■ System States
Events
Events 5
The following is the list of events that AutoSys processes. Some of these
events are generated internally by AutoSys, while some only occur when
sent manually using the sendevent command. For a list of manually-
executed events that can be sent using the sendevent command, see the
sendevent command reference page in Chapter 1, AutoSys Commands.
In effect, manual events are runtime commands for the Event Processor.
In the listing below, each event’s internal code assignment is provided
next to the event in parenthesis. This code number is used for viewing the
event in the database event table.
ALARM (106) 5
An alarm is an informational event only; it invokes no action on its own.

The type of alarm is further qualified by the value of the alarm, described
later in this appendix.
An alarm is generally an internal event, but an alarm can also be sent

manually if an application wants to alert an operator.
CHANGE_PRIORITY (120) 5
Changes the priority of a job. If the job is in the QUE_WAIT state, it

changes it immediately, and possibly starts the job. If the job is not yet in
the QUE_WAIT state, it changes the priority for the next run of the job
only. A permanent change of priority can be done by editing the job
definition.
CHANGE_STATUS (101) 5
Changes the value of the status for a specific job. When the Event
Processor processes this event, it initiates any actions that are dependent
upon this status of this job. The values of status are listed later in this
appendix.

System States ■
Events
CHECK_HEARTBEAT (116) 5
Instructs the Event Processor to check all jobs that have specified a
heartbeat interval to see if any are missing. If so, a MISSING_HEARTBEAT
alarm will be sent.
If the Event Processor is configured to do so, it will perform this check

automatically.
CHK_BOX_TERM (118) 5
This is an internally generated event that instructs the Event Processor to

check if a box job has run for more than its Maximum Run
(max_run_time) value.
CHK_MAX_ALARM (114) 5
This is an internally generated event, instructing the Event Processor to

check if a job has run for more than its Maximum Run value.
CHK_RUN_WINDOW (122) 5
This is a future event set to run at the end of a job’s run window, to see if
the job has run or not.
COMMENT (117) 5
For information purposes only. This event can be associated with a job
and as a result, is displayed on AutoSys reports (autorep). It is a method
for generating comments at runtime and have them be associated with a
specific run of a job.
DELETEJOB (119) 5
Tells AutoSys to delete this job. If the job is a box, it deletes everything
within the box.

■ System States
Events
EXTERNAL_DEPENDENCY (127) 5
Sent from an issuing AutoSys instance to a different, receiving AutoSys

instance to signal that a cross-instance dependency has been dispatched.
FORCE_STARTJOB (108) 5
Event to start a job, regardless of any conditions on this job. This event is
never generated by AutoSys, and should be used only in the event of
system problems. Using this event, it is possible to start the same job
twice, and as a result, have two instances of the job running at the same
time. For this reason, we recommend that this command be used only
with extreme caution.
HEARTBEAT (115) 5
The event sent from the Remote Agent posting a heartbeat for a given job.
This event is internally generated.
JOB_ON_ICE (110) 5
Event that instructs the Event Processor to place a job ON_ICE. If the job
is in the STARTING or RUNNING state, it will not place the job ON_ICE.
This event is manually generated.
JOB_OFF_ICE (111) 5
Event that instructs the Event Processor to take a job OFF_ICE. If the job
is in a RUNNING box, it will attempt to start it, conditions permitting.
This event is manually generated.
JOB_ON_HOLD (112) 5
Event that instructs the Event Processor to place a job ON_HOLD. If the
job is in the STARTING or RUNNING state, it will not place the job
ON_HOLD. This event is manually generated.

System States ■
Events
JOB_OFF_HOLD (113) 5
Event to take the job OFF_HOLD. The starting of the job will continue as
it was before it was placed ON_HOLD. This is the method for taking a
job OFF_HOLD when using the AutoHold feature.
KILLJOB (105) 5
Instructs the Event Processor to kill a specific job. For more information
on how processes are killed, see the sendevent command in Chapter 1,
AutoSys Commands. If the specified job is a box, it will change the box
status to TERMINATED, and, if so configured, kill the jobs within it. This
event is manually generated.
RESEND_EXTERNAL_STATUS (128) 5
This event is sent when a CHANGE_STATUS event is sent to another

instance and the receiving instance is unavailable. When this happens,
the receiving Event Processor will reschedule the event and try to send it
5 minutes later; an INSTANCE_UNAVAILABLE alarm is also generated.
SET_GLOBAL (125) 5
Sets an AutoSys global variable. This event is sent with a high priority so
that the Event Processor will process the variable before it is referenced
by any jobs at runtime.
SEND_SIGNAL(126) 5
Sends a Unix signal to a running AutoSys job.
STARTJOB (107) 5
Event to start a job, if and only if the starting conditions are satisfied, and
if it is not already running. This is the recommended way to start a job
manually.

■ System States
Status
STOP_DEMON (109) 5
Manually generated event telling the Event Processor to shut down. This
is used to halt the event demon.
Status 5
Every job has a status, or current state, associated with it; these are
described in this section. AutoSys moves jobs through these states as it
processes the events. Also provided are the internal codes for status, for
use when accessing the job_status table in the database.
ACTIVATED (9) 5
Top level box that this job is in is now in the RUNNING state. This status
does not have an event associated with it. It is an internal state only.
FAILURE (5) 5
For command jobs, the command exited with a exit code greater than the
maximum success value specified for this job. If a box, it means that the
failure conditions for the box evaluated to true.
INACTIVE (8) 5
Job is inactive; it has no status, per se. For example, a newly-created job,
which has not run yet is inactive.
ON_HOLD (11) 5
Job is on hold and will not be run until it receives the JOB_OFF_HOLD
event.

System States ■
Status
ON_ICE (7) 5
Job is removed from all conditions and logic, but is still defined to
AutoSys. Operationally, it is like deactivating the job.
QUE_WAIT (12) 5
The job can logically start, has a non-zero priority, and the machine(s)
on which it can start do not have enough available load units. When the
required load units become available, AutoSys will start the job. To
remove a job from QUE_WAIT, use:
sendevent -E CHANGE_PRIORITY -J job_name -q 0
RESTART (10) 5
Job was unable to start due to hardware or application problems, and has
been scheduled to restart.
RUNNING (1) 5
Job is running. If the job is a box, this means that the jobs within it may
be started (other conditions permitting). If it is a command or file
watcher job, it means that the process is actually running on the remote
machine.
STARTING (3) 5
Event Processor has initiated the start procedure with the Remote Agent.
The job is in the process of “coming up.” This status is only for command
and file watcher jobs, not box jobs.

■ System States
Alarms
SUCCESS (4) 5
Job exited and is considered by AutoSys to be successful, as determined

by the exit code for a command job, and the success conditions for a box
job.
TERMINATED (6) 5
Job was terminated.
Alarms 5
The following is a list of the alarms that may be generated by AutoSys.
ALREADY_RUNNING (528) 5
An attempt was made to start a job that was already running. The Remote
Agent did not start the job.
AUTO_PING (526) 5
The autoping -M -A command cannot connect to a client machine. The

name of the machine is listed.
CHASE (514) 5
The chase command has found a problem with a job that is supposedly
running. The job and the problem are listed.
DATABASE_COMM (516) 5
The Remote Agent had trouble sending an event to the database. The job
probably ran successfully. Inspect the Remote Agent Log file to determine
what happened.

System States ■
Alarms
DB_PROBLEM (523) 5
There is a problem with one of the AutoSys databases, such as a lack of

free space. This alarm can trigger a user-specified notification procedure.
DB_ROLLOVER (519) 5
AutoSys has rolled over from Dual Server to Single Server Mode. This
alarm can trigger a user-specified notification procedure.
DUPLICATE_EVENT (524) 5
Duplicate events have been received in the Event Server. Typically, this
means that two Event Processors are up and running, although duplicate
events can also be caused by Event Server configuration errors.
EP_HIGH_AVAIL (522) 5
Can mean that the Third Machine for resolving contentions between two
Event Processors cannot be reached, that the Event Processor is shutting
down, or that there are other Event Processor take over problems. This
alarm can trigger a user-specified notification procedure.
EP_ROLLOVER (520) 5
The Shadow Event Processor is taking over processing. This alarm can
trigger a use-specified notification procedure.
EP_SHUTDOWN (521) 5
The Event Processor is shutting down. This may be due to a normal

shutdown (SEND_EVENT triggered by sendevent -E STOP_DEMON), or due
to an error condition. This alarm can trigger a user-specified notification
procedure.

■ System States
Alarms
EVENT_HDLR_ERROR (507) 5
The Event Processor had an error while processing an event. The job
associated with that event should be inspected to see if manual
intervention is required.
EVENT_QUE_ERROR (508) 5
An event was not able to be marked as processed. This is usually due to a

problem with the Event Server. Contact your Technical Support
Representative.
FORKFAIL (501) 5
The Remote Agent was unable to start the user command because it was
unable to get a process slot on the UNIX machine. When this happens,
AutoSys will automatically attempt a RESTART. This alarm can occur only
when a job is running on a UNIX machine.
INSTANCE_UNAVAILABLE (525) 5
When different AutoSys instances communicate with each other, this

alarm is generated when the Event Server of the receiving AutoSys
instance cannot be reached. The Event Server is probably down.
JOBFAILURE (503) 5
A job has failed or was terminated. Its status is now FAILURE or

TERMINATED.
JOBNOT_ONICEHOLD (509) 5
To place a job ON_HOLD or ON_ICE, a JOB_ON_HOLD or

JOB_ON_ICE event is sent. If the job cannot be placed ON_HOLD or
ON_ICE (for example, if it is already running), this alarm is sent to alert
the user that this event could not be performed.

System States ■
Alarms
MAX_RETRYS (505) 5
AutoSys will continue attempting to restart a job if there are system

problems, or if the job is configured for application restarts (n_retrys).
There is a limit to how many times it will attempt a restart, as defined in
the configuration file (using MaxRestartTrys). When that limit has been
reached, this alarm is sent to alert operators that AutoSys has given up
trying to start it. When the problem is fixed, the job must be started
manually.
MAXRUNALARM (510) 5
The job has been running for a time greater than that defined in the
Maximum Run Time alarm (max_run_alarm) field in the Job Definition
dialog for that job. The job may continue to run; this event generates a
warning alarm.
MINRUNALARM (502) 5
The job has completed running in less time than that defined in the
Minimum Run Time alarm (min_run_alarm) field Job Definition dialog
for that job.
MISSING_HEARTBEAT (513) 5
A job has not sent a HEARTBEAT within the interval specified for that job.
The operator should inspect the job to see why.
OB_SHUTDOWN (527) 5
The Oasis Broker has shut down. This can be caused by a KILL command
issued against the Oasis Broker process or by an error condition.

■ System States
Alarms
RESOURCE (512) 5
A resource, such as file space, needed for this job was not available.
Specific information about the problem is in the comment associated
with this alarm.
If AutoSys encounters a resource problem, it will attempt to restart the

job after a suitable delay.
STARTJOBFAIL (506) 5
AutoSys was unable to start the job. This is generally due to

communication problems with the remote machine. AutoSys will
attempt to restart the job.
VERSION_MISMATCH (518) 5
Generated by the Remote Agent when the calling routine (e.g., Event
Processor, chase, clean_files, autoping, etc.) is at a different version
number than the Remote Agent. Inspect the Remote Agent Log file for the
exact version mismatch. The proper Remote Agent version should be
installed.

System States ■
AutoSys Exit Codes
AutoSys Exit Codes 5
When you use the autosyslog -J command to display the Remote Agent
log file for a specified job, you might see an entry containing one of the
following exit codes. If the exit code contains two numbers in
parentheses (e.g., (0 1)), the first number is the UNIX signal, and the
second number is the exit code. If a job is killed or terminated, the exit
code remains at zero, which is what it was set to when the job started.
Exit Codes Meaning
15 (15 0) The job was terminated by a UNIX kill -15.

101 (0 101) A CHANGE_STATUS was done on the job, i.e.,
possibly the job was changed to a TERMINATED
or FAILURE status.
121 (0 121) Can’t open std_in_file.
File doesn’t exist or is inaccessible; check
permissions.
122 (0 122) Can’t open std_out_file.
Output directory doesn’t exist or is inaccessible;
check permissions; check that the file system is
not full.
123 (0 123) Can’t open std_err_file.
Output directory doesn’t exist or is inaccessible;
check permissions; check that the file system is
not full.
127 (0 127) Directory that contains the executable not in the
command search PATH.

■ System States
AutoSys Exit Codes
Exit Codes Meaning
256 (0 1) Unable to execute the command.

There are many possible causes:
■ The command or file to be executed does not
exist.
■ The file to be executed is not executable.
Check permissions.
■ The file to be executed is in a directory that is
not accessible:
1 Check permissions (ls -ld).
2 If the directory is NFS-mounted, verify that

the mount exists.
■ If a Job Environment File is being used, the

PATH variable may be incorrect:
1 The file to be executed may not be in a
directory that is specified in PATH.
2 The PATH command may use an

undefined variable (which would translate
as blank space, and thus the PATH
command
would terminate before all the directories
are defined to it).
3 The job environment file may use

non-Bourne shell commands, e.g. "alias,"
and the expected settings (or aliases) may
not exist.
■ Wrong command options, e.g. date -JASD

can generate this return code.

System States ■
AutoSys Exit Codes
Exit Codes Meaning
512 (0 2) Wrong command options, e.g., awk ’junk’.

-655 SYSTEM_ERROR STARTJOB failures because auto_remote will not
start.
-656 NO_EXIT_CODE exit_code field in database is initialized to this.
-657 PROCESS_MIA Set by a chase-generated FAILURE event, e.g.
chase cannot find the process.

■ System States
AutoSys Exit Codes

6
Database Tables and Codes
This chapter lists the database tables and views, and it lists the event and
alarm codes used in these tables.
AutoSys Tables and Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
alamode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
audit_info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
audit_msg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
avg_job_runs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
calendar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
chase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
cred . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
event0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
event2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
eventvu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
ext_job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
glob . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6
intcodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6
job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6

■ Database Tables and Codes
job2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6
job_cond . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6
job_runs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7
job_status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7
jobst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7
keymaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7
last_Eoid_counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7
machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8
monbro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8
msg_ack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8
next_oid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8
next_run_num . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8
overjob . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8
req_job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9
restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9
svarchive_tbl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9
svarchive_vw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9
timezones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9
wait_que . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9
AutoSys Database Numeric Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10

Event Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-10
Event status Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-11
Event que_status Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-11
Alarm Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-11
Alarm State Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-12

Database Tables and Codes ■
AutoSys Tables and Views
AutoSys Tables and Views 6
Because AutoSys uses a relational database, you can query the database
to supply custom reports and information. All of the DDL (Data
Definition Language) for the database is in the following directory:
$AUTOSYS/dbobj
The table definitions are in file named table_name.tbl, and the view
definitions are in the view_name.view file.
The tables and views are described in the following sections.

WARNING • Changing information in AutoSys tables by using SQL
commands might cause your system to fail.
alamode 6
This table stores configuration information, such as autotrack level and

remote authentication level, used by the Event Processor.
WARNING • Do not change this table or you may crash the AutoSys
installation.
alarm 6
This table stores all the alarms. Each alarm has a unique eoid (event
object ID), which is the reference to the event that created the alarm.
audit_info 6
This table stores most of the autotrack utility information. You can
archive this table by using the -l option with the archive_events
command. The audit_msg table contains additional information.

audit_msg 6
This table stores additional autotrack utility information. You can

archive this table by using the -l option with the archive_events
command. The audit_info and audit_msg tables combined contain all of
the autotrack utility information.
avg_job_runs 6
Each job has a row in this table, with the field named joid (job object ID)
being the unique key. Each row of the table contains a job’s calculated
average run time, based on the data in the job_runs table. In addition,
each row contains a field named num_runs, which indicates how many
runs were used to calculate the average run time.
calendar 6
The calendar table contains a list of the dates for each calendar. Multiple
calendars may be defined, and they are referenced by unique names.
chase 6
This table stores chase utility information. Information remains in the

chase table only temporarily.
cred 6
This table stores in encrypted format the NT user passwords entered

through the autosys_secure utility.
WARNING • You can change the information in this table only by using
AutoSys utilities. If you use SQL commands to make any changes, jobs
may fail.

event 6
Each AutoSys event is a row in the event table. When an event is

processed, it is moved through the different processing states by changing
the field que_status. Each event has an identifier called its eoid, which is
unique across all instances of AutoSys. This ensures that events can never
be lost, confused, or overwritten when you run multiple instances of
AutoSys. This table can be archived using the -n option with the
archive_events command.
AutoSys utilities. If you use SQL commands to make any changes, your
jobs and events will not run.
event0 6
This table stores unprocessed events for the Event Processor. Each
unprocessed event has a unique eoid. The information remains in the
event0 table temporarily.
event2 6
This table stores duplicate events, which each have a unique eoid. Under
normal conditions the event2 table is empty.
eventvu 6
This view of the event table presents the information in that table in a
more readable form. Most notably, all the events, alarms, and statuses are
displayed in an easily interpreted textual format.
ext_job 6
This table stores the status of external job dependencies. If jobs on one
instance of AutoSys have dependencies on jobs that run on another
instance of AutoSys, this table specifies the status of the referenced jobs
that are running on the other AutoSys instance.

glob 6
Each global variable is a row in the glob table, with the field named
glo_name being the unique key.
intcodes 6
This table stores all the numeric codes—alarm, event, and status codes—
used in the other tables. These other tables reference the intcodes table.
job 6
Each job is a row in the job table, with the field named joid (job object
ID) being the unique key. Most of the parameters for all the job
definitions are contained in this table. The job2 table contains the
remaining parameters.
AutoSys utilities. If you use SQL commands to make any changes, your
jobs and events will not run.
job2 6
This table is an extension of the job table. The parameters for the job
definitions that are not in the job table are contained in this table. The
job and job2 tables combined contain all of the parameters for all of the
job definitions.
job_cond 6
Each atomic condition for a job is a row in this table.

job_runs 6
Each job run is a row in this table, with the fields named joid (job object
ID), run_num (run number), and ntry (number of tries to run the job)
being the unique keys. Each row of the table contains a job’s start time,
end time, run time (in seconds), completion status, and exit code. The
Event Processor updates this table. The table can be archived using the
archive_events command with the -j option.
job_status 6
The current run information for every job is stored in this table. It is also
identified by the key field named joid. Information such as the current
status, run number, last start time, last end time, and exit code are also in
this table.
jobst 6
This view contains the information from both the job and job_status
tables.
keymaster 6
This table stores all of the license keys and the information associated
with them.
WARNING • Do not use SQL commands to change information in this
table or AutoSys will not run, and do not use SQL commands to delete
license keys from this table, unless instructed to do so by your technical
support representative.
last_Eoid_counter 6
This table stores the number of the last event; the last eoid used by the
Event Processor.

machine 6
This table stores the machine definitions entered through JIL by using the
insert_machine command.
monbro 6
Each monitor or report (browser) definition is a row in this table. All

monitors and reports are contained in this table.
msg_ack 6
This table is used when the Verification Required for Alarms feature is set
for a monitor. This table contains the alarm ID that is responded to
(eoid), who responded to the alarm, what time it was first reported, what
time it was acknowledged, and a short comment from the operator.
next_oid 6
This table stores all of the oid (other ID) counters except the eoid used
by the Event Processor (stored in the last_Eoid_counter table).
next_run_num 6
This table stores the next run number counter.
overjob 6
This table stores the attributes for job overrides and the run number for
which the overrides were applied. The indices to this table are joid and
over_num, where joid is the unique job ID and over_num is the number of
the override for that job. The value of over_num is assigned at the time an
override is defined, and it is stored in the job_status table until run time.

req_job 6
This table stores the jobs on one instance of AutoSys that are referenced
in the starting dependencies of jobs running on another instance of
AutoSys.
restart 6
This table stores jobs that are in RESTART state. The information remains
in the restart table temporarily.
svarchive_tbl 6
This table stores CPU utilization, I/O read, I/O write, and average
memory usage information on a per-job-run basis. This information is
gathered by ServerVision and can be referenced to generate reports for
capacity planning and process auditing (charge back). ServerVision
requires this table.
svarchive_vw 6
This view of the svarchive_tbl table hides the structure of the information
in that table because the definition of the svarchive_tbl will change.
ServerVision requires this table.
timezones 6
This table stores time zone information. If you create your own time
zones with the autotimezone utility, that information is also stored in the
timezones table.
wait_que 6
This table stores information about jobs in the QUE_WAIT state. The
information remains in the wait_que table temporarily.

AutoSys Database Numeric Codes
AutoSys Database Numeric Codes 6
AutoSys events and alarms have unique numeric codes that the database
tables use to represent each event and alarm. The following sections list
the numeric codes and the associated event or alarm.
Event Codes 6
Event codes are used in the event table. The following list contains the
numeric codes and associated event types.
101 CHANGE_STATUS
103 CHK_N_START
105 KILLJOB
106 ALARM
107 STARTJOB
108 FORCE_STARTJOB
109 STOP_DEMON
110 JOB_ON_ICE
111 JOB_OFF_ICE
112 JOB_ON_HOLD
113 JOB_OFF_HOLD
114 CHK_MAX_ALARM
115 HEARTBEAT
116 CHECK_HEARTBEAT
117 COMMENT
118 CHK_BOX_TERM
119 DELETEJOB
120 CHANGE_PRIORITY
121 QUE_RECOVERY
122 CHK_RUN_WINDOW
125 SET_GLOBAL
126 SEND_SIGNAL
127 EXTERNAL_DEPENDENCY
128 RESEND_EXTERNAL_STATUS
For descriptions of the events, see Chapter 5, System States.

Event status Codes 6
Event status codes are used in the chase, event, job_runs, job_status, and
restart tables. The following list contains the numeric codes and
associated event status types.
1 RUNNING
3 STARTING
4 SUCCESS
5 FAILURE
6 TERMINATED
7 ON_ICE
8 INACTIVE
9 ACTIVATED
10 RESTART
11 ON_HOLD
12 QUE_WAIT
For descriptions of the events, see Chapter 5, System States.
Event que_status Codes 6
Event que_status codes are used in the event table. The following list
contains the numeric codes and associated event que_status types.
0 unprocessed
1 processing
2 processed
3 processed w/errors
4 unsent event
Alarm Codes 6
Alarm codes are used in the alarm and event tables. The following list
contains the numeric codes and associated alarm types.
501 FORKFAIL
502 MINRUNALARM

503 JOBFAILURE
505 MAX_RETRYS
506 STARTJOBFAIL
507 EVENT_HDLR_ERROR
508 EVENT_QUE_ERROR
509 JOBNOT_ONICEHOLD
510 MAXRUNALARM
512 RESOURCE
513 MISSING_HEARTBEAT
514 CHASE
516 DATABASE_COMM
518 VERSION_MISMATCH
519 DB_ROLLOVER
520 EP_ROLLOVER
521 EP_SHUTDOWN
522 EP_HIGH_AVAIL
523 DB_PROBLEM
524 DUPLICATE_EVENT
525 INSTANCE_UNAVAILABLE
526 AUTO_PING
527 OB_SHUTDOWN
528 ALREADY_RUNNING
For descriptions of the alarms, see Chapter 5, System States.
Alarm State Codes 6
Alarm state codes are used in the alarm table. The following list contains
the numeric codes and associated alarm state types.
43 open
44 acknowledged
45 closed

7
AutoSys API
AutoSys provides a C Programming Language API that enables you to
integrate events and alarms into your processing environment. This API
is comprised of two functions: get_auto_event which gives you direct
programmatic access to all events in the system and autoheartbeat
which generates heartbeats. With autoheartbeat, you can modify a
program to run under AutoSys control that will send “heartbeats” to
indicate the program is still running. This enables AutoSys to monitor the
execution of the program and notify you if the application becomes
inactive.
This chapter describes how to integrate AutoSys events and alarms into
the user’s processing environment by way of the AutoSys application
program API.
Accessing Events from the Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
Sending Heartbeats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4

■ AutoSys API
Accessing Events from the Database
Accessing Events from the Database 7
All the files you need to access events in the database, including an
example file, are located in the $AUTOSYS/code directory. These are the
files:
■ autosys_api.h
■ libauto.a
■ test_api
■ test_api.c
■ test_api.m (makefile)
■ heartbeat.c
■ heartbeat.sh
The AutoSys API reads the event information directly from the AutoSys
database. As a result, if the Event Processor is lost due to hardware
problems, the events will still be available to the API. Furthermore, you
can control the API so that it will attempt to reconnect to the database if
the database is unavailable.
This is the syntax for the call to get an AutoSys event:

get_auto_event()
get_auto_event ( ) 7
Name
get_auto_event
API to get AutoSys events.

AutoSys API ■
Accessing Events from the Database
Synopsis
#include <autosys_api.h>
int get_auto_event(event, polling_freq)
struct event_api *event;
int polling_freq;
Description 7
get_auto_event() loads the structure pointed to by *event with the full

event entry. The events are returned in the order in which they are posted
to the database. Events can be reported to the API before they are
processed by the Event Processor.
The event_api structure is defined in the header file autosys_api.h, like

this:
struct event_api
oid joid;
char roid[EOIDLEN+1];
char job_name[NAMELEN+1];
char box_name[NAMELEN+1];
char eventtxt[NAMELEN+1];
char statustxt[NAMELEN+1];
char alarmtxt[NAMELEN+1];
char event_time[DATETIMELEN+1];
int exit_code;
int run_num;
int ntry;
char machine[NAMELEN+1];
char comment[256];
};

■ AutoSys API
Sending Heartbeats
Sample
get_auto_event(&event, POLL_FREQ)
If a field is not used for a given event, it will be defined as a NULL-
terminated string. The only field guaranteed to be present is eventtxt.
The value POLL_FREQ instructs the API how often to inspect the database
for a new event.
After finding an event, get_auto_event() returns to the calling program.
Return Values 7
get_auto_event() returns 0 if it got an event, DB_DEAD if the database

dropped the connection or is unavailable, and -1 if it failed.
The ability to reconnect to the database is controlled by the calling

program. get_auto_event() will itself attempt to reconnect one time if an
existing connection is dropped. If it is unable to establish a connection,
it will return with DB_DEAD.
Example programs in $AUTOSYS/code/test_api.c
Sending Heartbeats 7
A function call can be imbedded in an application program that executes

under AutoSys control to periodically send a message to the Event
Processor signalling that the application is still processing normally. If
the Event Processor does not receive a message within the time interval
specified in the AutoSys configuration file, an error condition is detected,
and then the condition can be handled appropriately. This is the
function, which is located in the $AUTOSYS/code/heartbeat.c file:
autoheartbeat()

AutoSys API ■
Sending Heartbeats
autoheartbeat ( ) 7
Name
autoheartbeat
API to send heartbeats to the Event Processor.
Synopsis
int autoheartbeat()
Description 7
autoheartbeat() sends a signal (SIGUSR2) to the Remote Agent, which

sends it on to the Event Processor.
Return Values 7
autoheartbeat() returns 1 if it was able to send the signal successfully, 0

if not. Alternatively, a heartbeat can be issued from a Bourne shell script
by executing the script contained in the following file:
$AUTOSYS/code/heartbeat.sh
For information on setting the heartbeat interval in the configuration file,
see the Heartbeats section of Chapter 13, Configuring AutoSys, in the
AutoSys User Guide for UNIX.

■ AutoSys API
Sending Heartbeats

Index
A INSTANCE_UNAVAILABLE 5-12
after_time report attribute 4-4 JOBFAILURE 5-12
alamode table 6-3 JOBNOT_ONHOLD 5-12
ALARM 1-113 MAX_RETRYS 5-13
alarm monitor/report attribute 4-6 MAXRUNALARM 5-13
alarm table 6-3 MINRUNALARM 5-13
alarm_if_fail job attribute 2-5 MISSING_HEARTBEAT 5-13
alarm_verif monitor attribute 4-8 RESOURCE 5-14
alarms 1-113 STARTJOBFAIL 5-14
alarm codes 6-11 VERSION_MISMATCH 5-14
alarm state codes 6-12 all_events monitor/report attribute 4-10
AUTO_PING 5-10 all_status monitor/report attribute 4-12
CHASE 5-10 API, AutoSys
DATABASE_COMM 5-10 getting events 7-2
DB_PROBLEM 5-11 sending heartbeats 7-4
DB_ROLLOVER 5-11 archive_events 1-6
DUPLICATE_EVENT 5-11 archived event storage 1-8
EP_HIGH_AVAIL 5-11 attributes
EP_ROLLOVER 5-11 job
EP_SHUTDOWN 5-11 alarm_if_fail 2-5
EVENT_HDLR_ERROR 5-12 auto_delete 2-7
EVENT_QUE_ERROR 5-12 auto_hold 2-9
FORKFAIL 5-12 avg_runtime 2-11
AutoSys Reference Guide for UNIX Index-1 ■

■ Index
box_failure 2-13 watch_interval 2-116

box_name 2-15 machine 2-58, 3-2
box_success 2-17 factor 3-5
box_terminator 2-19 machine 3-13
chk_files 2-21 max_load 3-15
command 2-23 type 3-17
condition 2-27 monitor
date_conditions 2-35 alarm_verif 4-8
days_of_week 2-37 sound 4-34
description 2-42 monitor/report 4-3
exclude_calendar 2-44 alarm 4-6
heartbeat_interval 2-46 all_events 4-10
job_load 2-51 all_status 4-12
job_name 2-53 failure 4-17
job_terminator 2-54 job_filter 4-22
job_type 2-56 job_name 4-24
machine 2-58 mode 4-26
max_exit_success 2-61 monbro_name 4-28
max_run_alarm 2-63 restart 4-30
min_run_alarm 2-65 running 4-32
n_retrys 2-67 starting 4-36
override_job 2-69 success 4-38
owner 2-73 terminated 4-40
permission 2-76 profile 2-84
priority 2-81 report
profile 2-84 after_time 4-4
run_calendar 2-87 currun 4-14
run_window 2-89 audit_info table 6-3
start_mins 2-92 audit_msg table 6-4
start_times 2-94 auto_delete 2-7
std_err_file 2-96 auto_hold 2-9
std_in_file 2-99 autocal 1-11
std_out_file 2-101 autocal_asc 1-13
term_run_time 2-104 autocons 1-16
timezone 2-106 autoflags 1-18
watch_file 2-111 autoheartbeat 7-4
watch_file_min_size 2-114 autohold job attribute 2-9
■ Index-2 AutoSys Reference Guide for UNIX

Index ■
AutoHold, Global 1-84 command job attribute 2-23

AutoInstWideAppend 2-96, 2-101 commands
AutoMachWideAppend 2-96, 2-101 archive_events 1-6
autoping 1-20 autocal 1-11
autorep 1-23 autocal_asc 1-13
example reports 1-30 autocons 1-16
autosc 1-36 autoflags 1-18
autostatus 1-37 autoping 1-20
AutoSys commands 1-1 autorep 1-23
AutoSys/Xpert 2-11 autosc 1-36
autosys_api.h 7-2 autostatus 1-37
autosys_secure 1-45 autosys_secure 1-45
autosyslog 1-41 autosyslog 1-41
autotimezone 1-53 autotimezone 1-53
autotrack 1-57 autotrack 1-57
archive file name 1-8 chase 1-65
avg_job_runs table 6-4 chk_auto_up 1-69
avg_runtime 2-11 chk_cond (SP) 1-73
clean_files 1-75
B cron2jil 1-77
box_failure 2-13 dbstatistics 1-80
box_name 2-15 eventor 1-82
box_success 2-17 gatekeeper 1-87
box_terminator 2-19 jil 1-89
job_depends 1-95
C monbro 1-102
calendar table and view 6-4 record_sounds 1-105
CHANGE_PRIORITY 1-112 sendevent 1-108
CHANGE_STATUS 1-112 sendevent (SP) 1-121
chase 1-65 xql 1-124
eventor output in log 1-83 COMMENT 1-113
running automatically 1-66 condition job attribute 2-27
chase table 6-4 cred table 6-4
chk_auto_up 1-69 cron2jil 1-77
chk_cond (SP) 1-73 currun report attribute 4-14
chk_files 2-21
clean_files 1-75

■ Index
D accessing
database in database 7-2
DDL 6-3 using API 7-2
numeric codes 6-10 ALARM 5-4
tables 6-3 archiving 1-8
views 6-3 CHANGE_PRIORITY 5-4
date_conditions 2-35 CHANGE_STATUS 5-4
days_of_week 2-37 CHECK_HEARTBEAT 5-5
dbstatistics 1-80 CHK_BOX_TERM 5-5
DDL 6-3 CHK_MAX_ALARM 5-5
delete_box 2-48 CHK_RUN_WINDOW 5-5
delete_job 2-48 COMMENT 5-5
delete_machine 3-3 DELETEJOB 5-5
delete_monbro 4-19 event codes 6-10
DELETEJOB 1-110 event que_status codes 6-11
dependencies event status codes 6-11
cross-instance 2-30 EXTERNAL_DEPENDENCY 5-6
exit codes 2-30 FORCE_STARTJOB 5-6
global variables 2-31 HEARTBEAT 5-6
job status 2-28 JOB_OFF_HOLD 5-7
report of 1-95 JOB_OFF_ICE 5-6
description job attribute 2-40 JOB_ON_HOLD 5-6
JOB_ON_ICE 5-6
E KILLJOB 5-7
environment variables 2-84 list of names and codes 5-4
environment, runtime restrictions 2-24 RESEND_EXTERNAL_STATUS 5-7
Event Processor 1-113 SEND_SIGNAL 5-7
Global AutoHold 1-82 SET_GLOBAL 5-7
log 1-83 STARTJOB 5-7
log, monitoring 1-42 STOP_DEMON 5-8
starting 1-82 eventvu table 6-5
stopping 1-112 eventvu view 6-5
event table 6-5 exclude_calendar 2-44
event0 table 6-5 exclusive condition 2-29
event2 table 6-5 exit codes 5-15
eventor 1-82 exitcode 2-30
events ext_job table 6-5

Index ■
F Number of Times to Restart this Job

factor attribute 3-5 after a FAILURE 2-67
failure monitor/report attribute 4-17 Permissions 2-76
file locking 1-65 Que Priority 2-81
FORCE_STARTJOB 1-110 Resource Check - File System Space 2-
21
G Send ALARM if this Job Fails? 2-5
gatekeeper 1-87 SUCCESS Condition 2-17
get_auto_event (API) 7-2 Terminate this Job Mins after starting
glob table 6-6 2-104
Global AutoHold 1-82, 1-84 Time Interval (secs) to Determine
global variables Steady State 2-116
deleting 1-117 Timezone 2-106
reporting using autorep 1-27 Date/Time Options Dialog
setting 1-113 Date 2-37
GUI Fields Do NOT Run on Days in Calendar
Adv Features Dialog (Exclude) 2-44
AutoHold On? 2-9 Every Hour at 2-92
File to Redirect to Standard Error 2-96 Run on Days in Calendar 2-87
File to Redirect to Standard Input 2- Run Window 2-89
99 Time(s) of Day 2-94
File to Redirect to Standard Output 2- Job Definition Dialog
101 Command to Execute 2-23
File To Watch For 2-111 Delete Job after Completion? 2-7
Heartbeat Interval (mins) 2-46 Description 2-42
If the Box Fails should this job be Edit OneTime Over-Rides? 2-69
Terminated? 2-54 Execute on Machine 2-58
If this Job Fails should the Box be FAILURE Condition 2-13
Terminated? 2-19 Is the Start Date/Time Dependent? 2-
Job Environment Profile 2-84 35
Job Load 2-51 Job Type 2-56
Maximum Exit Code for SUCCESS 2- Name of the Box this Job is IN 2-15
61 Owner 2-73
Maximum Run Time 2-63 Starting Condition 2-27
Minimum File Size (in Bytes) 2-114 Monitor/Browser Dialog
Minimum Run Time 2-65 Alarms 4-6
ALL EVENTS 4-10

■ Index
ALL Job Status Events 4-12 Machine 3-2

Current Run Only 4-14 delete_machine 3-3
Events After Date/Time 4-4 insert_machine 3-8
Job Filter? 4-22 Monitor/Report 4-3
Mode 4-26 delete_monbro 4-16
Name 4-28 insert_monbro 4-19
ReStarting 4-30 update_monbro 4-42
Running 4-32 JIL sub-commands
Sound 4-34 Job 2-4
success 4-38 Job Name (GUI Field) 2-53
Terminated 4-40 Job Override Information (autorep) 1-24
Verification Required for Alarms 4-8 Job Run Detail (autorep) 1-24
Monitor/Report Dialog job table 6-6
Failure 4-17 job_cond table 6-6
Job Name 4-24 job_depends 1-95
starting 4-36 job_filter 4-22
job_load 2-51
H job_name 2-53, 4-24
heartbeat_interval 2-46 JOB_OFF_HOLD 1-112
heartbeats JOB_OFF_ICE 1-111
code to include 2-46 JOB_ON_HOLD 1-112
sending via API 7-4 JOB_ON_ICE 1-111
job_runs table 6-7
I job_runs, archiving 1-8
insert_job 2-48 job_status table 6-7
insert_machine 3-8 job_terminator 2-54
insert_monbro 4-19 job_type 2-56
intcodes table 6-6 job2 table 6-6
jobs
J change
jil command 1-89 owner 2-75
JIL Sub-commands priority 1-112
Job status 1-112
delete_box 2-39 deleting - sendevent 1-110
delete_job 2-40 dependencies report 1-95
insert_job 2-48 environment variables for 2-84
update_job 2-109 exit code 2-30

Index ■
force starting 1-110 max_load 3-15

killing 1-109 max_run_alarm 2-63
name 2-53 min_run_alarm 2-65
off hold 1-112 mode monitor/report attribute 4-26
off ice 1-111 monbro 1-102
on hold 1-112 monbro table 6-8
on ice 1-111 monbro_name monitor/report attribute
ON_HOLD vs. ON_ICE 2-31 4-28
owner 2-76 Monitor/Browser Editor
permissions on NT 2-79 sound 1-102
profile attribute 2-84 msg_ack table 6-8
starting via sendevent 1-109
jobst view 6-7 N
n_retrys 2-67
K next_oid table 6-8
keymaster table 6-7 next_run_num table 6-8
KILLJOB 1-109 numeric codes
alarm codes 6-11
L alarm state codes 6-12
last_Eoid_counter table 6-7 event codes 6-10
libauto.a file 7-2 event que_status codes 6-11
event status codes 6-11
M
machine O
attribute 2-58 OFF_HOLD 1-112
attribute (machine definitions) 3-13 OFF_ICE 1-111
definition 3-1 to 3-17 ON_HOLD 1-84, 1-112
delete 3-3 ON_HOLD vs. ON_ICE 2-31
factor 3-5 ON_ICE 1-111
insert 3-8 overjob table 6-8
max_load 3-15 override_job 2-69
type 3-17 owner job attribute 2-73
Machine Definition and status in database changing 2-75
(autorep) 1-24
machine table 6-8 P
man command 1-3 permission job attribute 2-76
max_exit_success 2-61 permissions

■ Index
Windows NT 2-79 sounds

permissions, using umask 2-77 recording 1-105
priority 2-81 start_mins 2-92
change event 1-112 start_times 2-94
profile starting conditions, reporting 1-95
restrictions 2-24 starting monitor/report attribute 4-36
profile attributeenvironment variables STARTJOB 1-109
See also profiles states, system 5-1
profiles 2-24, 2-84 status
changing 1-112
R job 5-8
record_sounds 1-105 ACTIVATED 5-8
Remote Agent log CHANGE_STATUS 5-4
clearing 1-75 changing 1-112
viewing 1-42 FAILURE 5-8
reporting, starting conditions 1-95 INACTIVE 5-8
req_job table 6-9 ON_HOLD 5-8
restart monitor/report attribute 4-30 ON_ICE 5-9
restart table 6-9 QUE_WAIT 5-9
restrictions, profile 2-24 RESTART 5-9
run_calendar 2-87 RUNNING 5-9
run_window 2-89 STARTING 5-9
running attribute 4-32 SUCCESS 5-10
runtime environment, restrictions 2-24 TERMINATED 5-10
ruserok() 1-49 std_err_file 2-96
std_in_file 2-99
S std_out_file 2-101
Send ALARM if this Job Fails? (GUI Field) STOP_DEMON 1-112
2-5 success monitor/report attribute 4-38
SEND_SIGNAL 1-114 svarchive_tbl table 6-9
sendevent 1-108 svarchive_vw view 6-9
sendevent (SP) 1-121 system states 5-1
sending heartbeats 7-4
SET_GLOBAL 1-113 T
Shadow Event Processor tables 6-3
starting 1-82 tables and views
sound monitor attribute 4-34 alamode 6-3

Index ■
alarm 6-3 test_api file 7-2

audit_info 6-3 test_api.c file 7-2
audit_msg 6-4 test_api.m (Makefile) 7-2
avg_job_runs 6-4 timezone 2-106
calendar 6-4 timezones table 6-9
chase 6-4 displaying 1-55
cred 6-4 type machine attribute 3-17
event table 6-5
event0 6-5 U
event2 6-5 uid 2-76
eventvu 6-5 umask 2-78
ext_job 6-5 umask in profile file 2-85
glob 6-6 update_job 2-109
intcodes 6-6 update_monbro 4-42
job 6-6 user-defined environment variables 2-84
job_cond 6-6
job_runs 6-7 V
job_status 6-7 variables in Command Job definition 2-
job2 6-6 24
jobst 6-7 views 6-3
keymaster 6-7
last_Eoid_counter 6-7 W
machine 6-8 wait_que table 6-9
mext_oid 6-8 watch_file 2-111
monbro 6-8 watch_file_min_size 2-114
msg_ack 6-8 watch_interval 2-116
next_run_num 6-8 Windows NT
overjob 6-8 job permissions on 2-79
req_job 6-9
restart 6-9 X
svarchive_tbl 6-9 xql 1-124
svarchive_vw 6-9
timezones 6-9
wait_que 6-9
technical Support xv
term_run_time 2-104
terminated monitor/report attribute 4-40

■ Index

13-Autosys UserGuide

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

13-Autosys UserGuide

Hochgeladen von

Copyright:

Verfügbare Formate

AutoSys®

AutoSys Reference Guide for UNIX iii ■

2 • JIL/GUI Job Definitions

■ iv AutoSys Reference Guide for UNIX

job_name (GUI only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-53

3 • JIL Machine Definitions

AutoSys Reference Guide for UNIX v ■

4 • JIL/GUI Monitor/Report Definitions

■ vi AutoSys Reference Guide for UNIX

COMMENT (117) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-5

AutoSys Reference Guide for UNIX vii ■

EP_HIGH_AVAIL (522) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11

6 • Database Tables and Codes

■ viii AutoSys Reference Guide for UNIX

AutoSys Reference Guide for UNIX ix ■

■ x AutoSys Reference Guide for UNIX

About This Guide 0

The AutoSys Reference Guide for UNIX is intended for system

The chapters of this guide are organized in the following way.

1 AutoSys Commands Provides a listing, in “man page”

AutoSys Reference Guide for UNIX xi ■

2 JIL/GUI Job Definitions Provides a listing, in “man page”

■ xii AutoSys Reference Guide for UNIX

7 AutoSys API Describes how to integrate AutoSys

Index Helps you locate information within

Some or all of the following conventions appear in this guide:

Bold a new term ...called a source object.

field names (optional) Click OK.

AutoSys Reference Guide for UNIX xiii ■

Magenta (online only) hotlinked ...see Chapter 3, Data

the titles of other General Facilities Reference

syntax variables COPY filename

Monospace directories, file names, &HIGHLVL.SRCLIB

computer screen text, Copy file? Y/N

} choosing a command from File } Import } Object

■ xiv AutoSys Reference Guide for UNIX

Command Syntax Conventions 0

UNIX and Windows 0

Syntax statements for UNIX and Windows commands are formatted as

The following is an example:

■ Options consist of one character and are always preceded by a hyphen

■ Options with no arguments can be grouped after a single hyphen.

■ [ ]—Brackets surround an option or command argument that is not

■ {}—Curly brackets enclose options or arguments that are

Contacting Technical Support 0

AutoSys Reference Guide for UNIX xv ■

■ AutoSys and AutoSys/Xpert Release Notes for UNIX, which provides

■ AutoSys Upgrade Instructions for UNIX, which describes how to upgrade

■ xvi AutoSys Reference Guide for UNIX

Functional Listing of AutoSys Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4

AutoSys Reference Guide for UNIX 1-1 ■

chk_cond (SP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-73

sendevent (SP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-121

■ 1-2 AutoSys Reference Guide for UNIX

You execute AutoSys commands at the UNIX operating system prompt,

Note • The command reference found in this chapter is also available

AutoSys Reference Guide for UNIX 1-3 ■

Functional Listing of AutoSys Commands 1

Task Command Page

Accessing Sybase xql page 1-124

autoping page 1-20

autosyslog page 1-41