Autosys User Guide
Autosys User Guide
User Guide
for UNIX
Version 3.5.1
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.
Notwithstanding the foregoing, the user may print a reasonable number of copies of this
documentation for its own internal use, provided that all CA copyright notices and legends
are affixed to each reproduced copy. Only authorized employees, consultants, or agents of the
user who are bound by the confidentiality provisions of the license for the software of the user
will have access to such copies.
This right to print copies is limited to the period during which the license for the product
remains in full force and effect. Should the license terminate for any reason, it shall be the
user's responsibility to return to CA the reproduced copies or to certify to CA that same have
been destroyed.
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, 2001 Computer Associates International, Inc., One Computer Associates Plaza,
Islandia, New York 11749. All rights reserved..
Table of Contents
Preface
About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx
Typographical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Command Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii
UNIX and Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii
Contacting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii
Related Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii
1 • Introduction to AutoSys
AutoSys Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3
Defining Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3
System Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-4
Event Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-5
Event Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-6
Remote Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-7
Example Scenario on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-7
Interface Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10
AutoSys Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10
AutoSys Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12
Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12
Basic AutoSys Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13
Explanation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14
Extending AutoSys Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
2 • AutoSys Security
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Security on Events Sent by Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Security on Events Sent by the Event Processor . . . . . . . . . . . . . . . . . . . 2-5
System-Level Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
AutoSys Database Field Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
Job Definition Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
Remote Agent Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
AutoSys User and Database Administrator Passwords . . . . . . . . . . . . . 2-10
AutoSys Job-Level Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
AutoSys Job Ownership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
AutoSys User Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12
AutoSys Permission Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13
Job Permissions and Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
AutoSys Superuser Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
Edit Superuser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16
Exec Superuser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17
Restricting Access to AutoSys Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17
Remote Agent Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19
3 • AutoSys Jobs
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Job Types and Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4
Basic Job Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5
Command Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5
Box Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6
File Watcher Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
Basic Job Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8
Command Job Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8
File Watcher Job Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
Box Job Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
Job States and Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10
Example State Diagram - Simple Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12
Example State Diagram - Box Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14
4 • Job Attributes
Job Attributes and Job Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3
Using JIL to Create a Job Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3
Using the GUI to Create a Job Definition . . . . . . . . . . . . . . . . . . . . . . . . . .4-4
Chapter Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4
Essential Job Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5
Attributes Common to All Job Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5
Command Jobs Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6
File Watcher Job Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-9
Box Job Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-9
Optional Job Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10
Common Job Starting Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10
Common General Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
Command Job Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-19
File Watcher Job Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26
Box Job Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-27
Date and Time Attributes and Time Changes . . . . . . . . . . . . . . . . . . . . . . . 4-28
The Time Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28
AutoSys Behavior During Time Change . . . . . . . . . . . . . . . . . . . . . . . . . 4-29
12 • Maintaining AutoSys
Maintaining the Event Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3
Starting the Event Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3
Monitoring the Event Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-6
Stopping the Event Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-7
Shadow Event Processor Rollover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-8
Running AutoSys in Test Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-10
AutoSys Maintenance Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-12
Backing up AutoSys Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-13
Restoring AutoSys Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-16
AutoSys Database Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-16
Event Server Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-17
Database Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-18
General Database Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-20
Daily Database Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-20
DBMaint Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-21
Event Server Rollover Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-23
Event Server Crash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-23
Synchronizing the Event Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-24
13 • Configuring AutoSys
AutoSys Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-4
Sample Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-4
Configuration File Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-10
Database Time-out Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-10
Cross-Instance Database Connections . . . . . . . . . . . . . . . . . . . . . . . . . 13-11
Database Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-12
Event Processor Cascading Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-13
Machines to Check for Running Event Processors . . . . . . . . . . . . . . . 13-14
Third Machine for Event Processor Contention . . . . . . . . . . . . . . . . . . 13-14
Event Processor Log Disk Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-15
Internal Database Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-16
Event Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-17
Sendevent Retries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-18
Heartbeats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-18
Shadow Event Processor Pings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-19
Remote Agent Log Files Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-20
File Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-21
Number of Restart Attempts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-23
Calculating the Wait Time Between Restarts . . . . . . . . . . . . . . . . . . . . 13-23
Method of Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-24
14 • Troubleshooting
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-3
Event Server Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-3
Event Server is Down (Sybase) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-3
Sybase Deadlock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-6
Not Enough User Connections (Bundled Sybase) . . . . . . . . . . . . . . . . . 14-7
archive_events Fails (Bundled Sybase) . . . . . . . . . . . . . . . . . . . . . . . . . . 14-9
Event Server Will Not Start (Bundled Sybase) . . . . . . . . . . . . . . . . . . . 14-11
Event Processor Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-11
Event Processor is Down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-12
Event Processor Will Not Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-12
B • Troubleshooting CCI
Troubleshooting Tools for Remote CCI Connections . . . . . . . . . . . . . . . . . . .B-2
CCI Command Line Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B-4
Reinstalling CCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B-9
Index
The AutoSys User Guide for UNIX explains how to define, run, monitor,
manage, and control AutoSys in UNIX. The chapters of this guide are
organized as follows.
Ch.
No. Chapter Name Content Description
Ch.
No. Chapter Name Content Description
Ch.
No. Chapter Name Content Description
Ch.
No. Chapter Name Content Description
Assumptions 0
This guide is for users responsible for defining jobs to AutoSys and
monitoring and managing these jobs. It assumes familiarity with the
operating system on which jobs will be run, and it assumes that you have
already installed and are running AutoSys using the procedures described
in the AutoSys Installation and Getting Started Guide for UNIX.
Typographical Conventions 0
Symbol or
Type Style Represents Example
Italic words that are emphasized ...the entry after the current
entry...
Symbol or
Type Style Represents Example
■ |—Denotes OR condition.
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:
http://esupport.ca.com.
Related Publications 0
As you use this AutoSys User Guide for UNIX, you might find it helpful to
have these additional books available for reference:
■ AutoSys and AutoSys/Xpert Release Notes for UNIX, version 3.4.6, which
provides important information about this release. Please read this
before proceeding.
■ 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 Reference Guide for UNIX, which lists the AutoSys commands
and job, machine, monitor, and report definition parameters. It also
describes system states, database tables and views, and the API.
As with most control systems, there are many ways to correctly define and
implement jobs. It is likely that the way you utilize AutoSys to address
your distributed computing needs will evolve over time. As you become
more familiar with both the features of AutoSys and the characteristics of
your own jobs, you will also refine your use of AutoSys.
Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12
Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12
1 AutoSys Jobs
In the AutoSys environment, a job is a single action that can be
performed on a valid AutoSys client machine. On UNIX, this action can
be any single command or shell script, and on NT, this action can be any
single command, executable, or batch file. In addition, job definitions
include a set of qualifying attributes.
1 Defining Jobs
Using AutoSys utilities, you can define a job by assigning it a name and
specifying the attributes that describe its associated behavior. These
specifications make up the AutoSys job definition. These are the two
methods you can use to create job definitions:
System Components 1
■ Event Processor
■ Remote Agent
Event Processor
UNIX Job
NT Client
Remote Agent
Event Server
(database)
NT Job
1 Event Server
The Event Server or AutoSys database (the RDBMS) is the data repository
for all system information and events as well as all job, monitor, and
report definitions. Event Server refers to the database where all the
AutoSys information, events, and job definitions are stored.
Note • The AutoSys database refers to the specific server instance and
the “autosys” database for that instance. Some utilities, such as isql
(Sybase), allow you to specify a particular server and database.
For more information on using Dual Event Servers, see Dual Event Servers
in Chapter 1, Introduction to AutoSys, of the AutoSys Installation and Getting
Started Guide for UNIX.
1 Event Processor
The Event Processor is the heart of AutoSys; it interprets and processes
all the events it reads from the AutoSys database. Sometimes called the
event_demon, the Event Processor is the program, running either as a
UNIX process or as a Windows NT service, that actually runs AutoSys. It
schedules and starts jobs.
After you start it, the Event Processor continually scans the database for
events to be processed. When it finds one, it checks whether the event
satisfies the starting conditions for any job in the database.
1 Remote Agent
On a UNIX machine, the Remote Agent is a temporary process started by
the Event Processor to perform a specific task on a remote (client)
machine. On a Windows NT machine, the Remote Agent is a
Windows NT service running on a remote (client) machine that is
directed by the Event Processor to perform specific tasks.
The Remote Agent starts the command specified for a given job, sends
running and completion information about a task to the Event Server,
then exits. If the Remote Agent is unable to transfer the information, it
waits and tries again until it can successfully communicate with the
database.
PROCESS
PROCESS
Remote Agent
Event Processor
•Receives instructions from Event
1 •Determines Actions Processor
5
PROCESS PROCESS
WorkStation_2
Event Server
UNIXCommand
•Events
•Runs UNIX Command:
•Job Definitions 4 rm /tmp/mystuff/*
Local Area •Completes execution and
Network exits with status
Figure 1-2 • Interaction of the Event Server, Event Processor, and Remote Agent
Explanation
The following numbered steps explain the interactions in the example
scenario:
1 From the AutoSys Event Server, the Event Processor reads a new event,
which is a start job event with a start time condition that has been
met. Then the Event Processor reads the appropriate job definition
from the database and, based on that definition, determines what
action to take. In the example, it runs the rm /tmp/mystuff/*
command on “WorkStation_2”.
3 The Remote Agent performs resource checks, such as ensuring that the
minimum specified number of processes are available, then “forks” a
child process that will actually run the specified command.
4 The command completes and exits, and the Remote Agent captures
the command’s exit code.
5 The Remote Agent communicates the event (exit code, status, etc.)
directly to the Event Server. If the AutoSys database is unavailable for
any reason, the Remote Agent will go into a wait and resend cycle until
it can deliver the message.
Only two AutoSys processes need to be running: the Event Processor and
the Event Server. When these two components are running, AutoSys is
fully operational. The Remote Agent is started on a client machine once
per job. As soon as the job ends and the Remote Agent sends a
completion event to the database, the Remote Agent exits.
Note • The Remote Agent is started on the client machine by the Event
Processor talking to the internet daemon (inetd) on the client
machine. For this to happen, inetd must also be running. However,
since UNIX is responsible for starting this daemon, it is not
considered an AutoSys process.
1 Interface Components
To define, monitor, and report on jobs, you can use either the AutoSys
GUI or AutoSys JIL. In addition, the Operator Console and its dialogs
provide a sophisticated method of monitoring AutoSys jobs in real time.
This feature lets you view all jobs that are defined to AutoSys, whether or
not they are currently active. If you purchased AutoSys/Xpert, you can use
the Xpert product to monitor, analyze and forecast (simulate) AutoSys
jobs. For information, see the AutoSys/Xpert User Guide for UNIX.
AutoSys Machines 1
Server Machine
Client Machine
AutoSys Instance 1
You might want to install multiple AutoSys instances. For example, you
might want to have one instance for production and another for
development. Multiple instances can run on the same machine, and can
schedule jobs on the same machines without interfering or affecting the
other instances.
Events 1
■ Events sent with the sendevent command, sent from the Send Event
dialog, the command line, or user applications.
As each event is processed, the Event Processor scans the database for jobs
that are dependent on that event in some way. If the event satisfies
another job’s starting condition, that job is either started immediately, or
if necessary, queued for the next qualified and available machine. The
completion of one job can cause another job to be started, and in this
way, jobs progress in a controlled sequence.
Alarms 1
Utilities 1
To help you define, control, and report on jobs, AutoSys has its own
specification language called Job Information Language, or JIL, for
defining jobs, machines, monitors, and reports. This language is
processed by the jil command, which reads and interprets the JIL
statements that you enter and then performs the appropriate actions,
such as adding a new job definition to the database.
The diagram in Figure 1-3 and the numbered explanations that follow it
illustrate how AutoSys performs its most basic function—starting a job
(i.e., executing a command) on a client machine.
Event Processor
1 2 3 5
AutoSys Client
Event Server agent
(Database) Connect
7
Remote Agent
9 6 8
Client Job
1 Explanation
1 The Event Processor scans the Event Server for the next event to
process. If no event is ready, the Event Processor scans again in five
seconds.
2 The Event Processor reads from the Event Server that an event is ready.
If the event is a STARTJOB event, the job definition and attributes are
retrieved from the Event Server, including the command and the
pointer (full path name on the client machine) to the profile file to be
used for the job. In addition, for jobs running on Windows NT
machines, the Event Processor retrieves from the database the user
ID(s) and password(s) required to run the job on the client machine.
6 The Remote Agent starts a process and executes the command in the
job definition.
8 The client job process runs to completion, then returns an exit code to
the Remote Agent and quits.
If the return status is SUCCESS, the Remote Agent deletes the log file
in its temporary file directory (usually tmp) on the client machine (if
so specified in the AutoSys configuration file on UNIX or with the
AutoSys Administrator on Windows NT).
The Event Processor, which is scanning the Event Server, sees the process
completion status, determines if there are dependent jobs, and evaluates
the rest of the dependent jobs’ starting conditions. For each job found
whose remaining conditions are satisfied, the Event Processor sends a
STARTJOB command to the Event Server, which it will then process in the
next cycle.
You can extend AutoSys jobs with the AutoSys Connect and AutoSys
Agent integration components. Using cross-platform job dependency
notation, you can define AutoSys jobs to conditionally start based on the
status of an AutoSys Connect job running on a mainframe, and you can
define AutoSys Connect jobs to conditionally start based on the status of
an AutoSys job. You can also define AutoSys jobs that will run on an
AutoSys Agent machine, if the AutoSys Agent machine is defined to
AutoSys.
AutoSys Server
UNIX Client (UNIX or NT)
NT Client
UNIX Job
Remote Agent
Event Server
(database)
Remote Agent
NTJOB
Event Processor
AutoSys/Adapter
asbrokerII
Application
Other OS Mainframe
(e.g., AS/400) CCI (OS/390)
CCI CCI
For information about AutoSys security on Windows NT, see the AutoSys
Security chapter in the AutoSys User Guide for Windows NT.
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Security on Events Sent by Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Security on Events Sent by the Event Processor . . . . . . . . . . . . . . . . . . . . . . . . 2-5
2 Overview
AutoSys security includes:
AutoSys security is initiated when either a user sends events that affect the
running of a job or the Event Processor sends events that affect a job.
STARTJOB FORCE_STARTJOB
KILLJOB DELETEJOB
CHANGE_STATUS CHANGE_PRIORITY
JOB_ON_HOLD JOB_OFF_HOLD
JOB_ON_ICE JOB_OFF_ICE
SEND_SIGNAL
If you start a job by sending an event, the job permissions are checked as
shown in Figure 2-1.
Figure 2-1 shows how AutoSys checks for the following when a user starts
a job by sending an event:
1 Checks the database to determine if the job definition was tampered
with. If so, the job definition is invalid, and the job is not run.
2 Does the user match the owner as indicated in the job definition?
4 Does the user have job execute permissions as indicated in the job
definition?
5 Is there a machine name in the owner value of the job definition? The
Edit Superuser can remove this portion of the owner.
6 Does the machine portion of the user logon match the job owner
machine portion?
7 Does the job have machine permissions as indicated by the job
definition?
The AutoSys Event Processor scans the Event Server for any jobs with
starting conditions that have been met. When the starting conditions for
a job are met, the Event Processor sends a STARTJOB event to the
designated Remote Agent machine.
Figure 2-2 shows the permissions and security checks that occur on a
UNIX machine before a job is allowed to start on the machine.
Figure 2-2 • Security when an Event Processor starts a job on a UNIX client machine
Note • In the figure, an asterisk indicates checks that are made only if
the specific method of remote authentication is enabled (see Remote
Agent Authentication on page 2-9).
Figure 2-2 shows how AutoSys checks for the following when the Event
Processor sends a STARTJOB event to a Remote Agent machine:
3 Does the user who is defined as the job owner (user@machine) have a
logon account on the Remote Agent machine?
2 System-Level Security
The AutoSys security scheme prevents unauthorized access to AutoSys
facilities, which in turn prevents unauthorized access to AutoSys jobs.
The following features handle system security in AutoSys:
To re-enable a disabled job, the owner or the Edit Superuser must access
the definition and re-save it, by using either the JIL update_job
sub-command or the Job Definition dialog.
■ User authentication
User Authentication
This remote authentication method uses UNIX ruserok() authentication
to verify that a user has permission to start a job on an AutoSys client
machine. It accomplishes this by telling the client’s Remote Agent to
make the ruserok() UNIX system call to check the client machine’s
/etc/hosts.equiv and the user’s .rhosts file 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. To activate this type of remote authentication, use the
autosys_secure command.
The hosts.equiv and/or .rhosts file entries must match the job owner
and machine name field exactly. For example, if the owner is
tarzan@jungle, the hosts.equiv and/or .rhosts file must contain
“jungle.” Similarly, if the owner is [email protected], the
hosts.equiv and/or .rhosts file must contain “jungle.vine.com.” If they
do not match, jobs will fail to run on that machine when ruserok()
remote authentication is in use.
When you install AutoSys with bundled Sybase, the database system
administrator ID is “sa,” and the password is “sysadmin.” To enhance
security, we recommend that you change the system administrator
password by using the xql utility.
You must supply the “autosys” and “sa” user IDs and passwords when
you use several AutoSys utilities. For example, when using the xql utility
to query the database, you must know both the “autosys” user password
and the “sa” system administrator password.
By default, only the user logged on as the owner of a job can edit or
execute a job. The owner can extend permissions to other users and other
machines, as described in the following sections.
■ Group. Any user who is in the same primary group as the owner.
AutoSys uses the UNIX user ID (uid) and group ID (gid) of a job’s owner
to control the following:
The owner of a job can allow other users to edit and execute the job by
setting the permissions in the job definition (discussed in the next
section).
■ Execute. Users can send an execute event that affects the running of a
job by using the sendevent command or the Send Event dialog. For a
list of the execute events that users can send, see Security on Events Sent
by Users on page 2-3.
■ Machine. Users logged onto a machine other than the one on which a
job was created can edit or execute the job.
Note • In order for a job to run on a machine other than the one
on which the job was defined, the owner of that job must have an
account on that machine.
Granting Permissions
The owner of a job cannot override his or her ownership designation;
only the Edit Superuser has the authority to change the owner job
attribute. However, the owner can grant other users edit and execute
permissions for a job by using the GUI or JIL to set the permission job
attribute in the job definition.
The following table shows the permissions that you can set by using JIL
or the Permission toggle buttons on the Job Definitions Advanced
Features dialog.
Group Execute gx Users assigned to the job owner’s primary group can
execute the job if logged onto the machine where the job
was created (the machine specified in the owner
attribute, i.e., user@machine).
Group Edit ge Users assigned to the job owner’s primary group can edit
the job if logged onto the machine where the job was
created (the machine specified in the owner attribute, i.e.,
user@machine).
All Hosts Execute mx Users, regardless of the machine logged onto, can
execute the job (otherwise, the user must be logged onto
the machine specified in the owner attribute, i.e.,
user@machine).
All Hosts Edit me Users, regardless of the machine logged onto, can edit
the job (otherwise, the user must be logged onto the
machine specified in the owner attribute, i.e.,
user@machine).
World Execute wx Users can execute the job if logged onto the machine
where the job was created (the machine specified in the
owner attribute, i.e., user@machine).
World Edit we Users can edit the job if logged onto the machine where
the job was created (the machine specified in the owner
attribute, i.e., user@machine).
Note • A job and the command it executes will always run as the user
specified in the owner attribute of the job definition. Execute
permissions determine who can execute events against the job, but
not who the job runs as. Even if World Execute permissions are
granted, the job will still run as the user.
2 Edit Superuser
Only the Edit Superuser has permission to:
The Edit Superuser must enter valid NT user IDs and passwords into the
AutoSys database. These user IDs and passwords are required for AutoSys
to log onto and run jobs on NT client machines. When a Remote Agent
runs a job on a machine, it logs on as the user defined in the owner
attribute for the job. To do this, the Event Processor retrieves encrypted
versions of the IDs and passwords for the user@host_or_domain and the
user@machine from the Event Server and passes them to the Remote
Agent. For information about entering and changing NT user IDs and
passwords, see autosys_secure in Chapter 1, AutoSys Commands, of the
AutoSys Reference Guide for Windows NT.
Note • Any AutoSys user who knows an existing user ID and password
can change that password or delete that user and password.
2 Exec Superuser
Only the Exec Superuser has permission to:
■ Issue commands that affect the running or the state of any AutoSys
job, either using the sendevent command or the Send Event dialog.
First, you must ensure that only authorized users can change permissions
on the files and directories in the AutoSys directory structure.
Then, you should determine what level of security you want, for example:
If you want only authorized users to access AutoSys, ensure that only
those users have execute permissions on the files in the AutoSys bin
directory.
If you want all users to view reports about jobs, but only authorized users
to create and edit jobs and calendars, ensure that the following AutoSys
files in the $AUTOSYS/bin directory are executable only by the authorized
users. This will also prevent unauthorized users from making changes to
the AutoSys configuration.
You should also protect the files in the $AUTOUSER directory from
modification by ensuring that only users authorized to change the
AutoSys configuration have write permission on the files. Read
permission is necessary to source the AutoSys environment files.
3 Introduction
All activity controlled by AutoSys is based on jobs. Other AutoSys objects,
such as Monitors, Browsers (Reports), and the Operator Console, serve to
track job progress. A job is the basic building block upon which the entire
operations cycle is built.
As with most control systems, there are many ways to correctly define and
implement jobs. It is likely that the way you utilize AutoSys to address
your distributed computing needs will evolve over time. As you become
more familiar with both the features of AutoSys and the characteristics of
your own jobs, you will also refine your use of AutoSys.
Job Depends On
Name
Starting Conditions
Alarms
Basic Job Restart Conditions
Definition
Information
Current status
Start time
End time
Exit code
Current State
Command
Job Container
Command to execute File Watcher
Types File to source Box
Machine to run on File Name
Standard output files Minimum File size
Standard input file Watch Interval
As their names imply, command jobs execute commands, box jobs are
containers which hold other jobs (including other boxes), and file
watcher jobs watch for the arrival of a specified file.
3 Command Jobs
The command job is commonly thought of (and referred to) as “a job.”
The command can be a shell script, an executable program, a file transfer,
and so forth. When this type of job is run, the result is the execution of a
specified command on a client machine. When all the starting conditions
are met, AutoSys runs this command and captures its exit code upon
completion. The exit event (either SUCCESS or FAILURE) and the exit
code value are stored in the database.
Resource Criteria
AutoSys will check that a certain amount of free file space is available
before starting a process. If it is not available, an alarm is sent and the
job is rescheduled to start after a suitable delay.
Profile Script
For each job, you can specify a script to be sourced before the
execution of the command that defines the environment in which the
command is to be run. All commands are run under the Bourne shell
(/bin/sh). Therefore, all statements in the profile must use /bin/sh
syntax.
For each job, you can specify the standard input, standard output, and
standard error files. To do this, use the JIL std_* commands, or use the
Job Definition Advanced Features dialog.
3 Box Jobs
In the AutoSys environment, the box job (or box) is a container of other
jobs. A box job can be used to organize and control process flow. The box
itself performs no actions, although it can trigger other jobs to run. An
important feature of this type of job is that boxes can be put inside of
other boxes. When this is done, jobs related by like starting conditions
(not by similar application types) can be grouped and operated on in a
logical way.
Note • Box jobs are very powerful tools for organizing, managing,
and administering large numbers of jobs that have similar starting
conditions and/or have complex logic flows. Knowing how and when
to use boxes is often the result of some experimentation
For more information on box jobs, see Chapter 5, Box Job Logic.
Jobs inside of boxes will be run only once per box execution. If you do
specify multiple start times for a job during one box processing cycle,
only the first start time will be used. This prevents jobs in boxes from
inadvertently running multiple times.
AutoSys starts a job if the current time matches, or is later than, the start
time. In addition to explicit starting conditions, jobs inside of boxes have
the following implicit condition: the box job itself is running. This means
that jobs inside of a box will start only if the box job itself is running.
However, if a job inside a box starts and the box job is stopped, the
started job runs to completion.
Note • Some caution must be exercised when placing a job with more
than one time-related starting condition in a box. For example, a job
that runs at 15 and 45 minutes past the hour is placed in a box that
runs every hour. The first time the box starts, the job runs at 15
minutes past the hour. A future start is then issued for 45 minutes past
the hour, by which time the box has completed. As a result, the job
will not run until the box is running again at the top of the next hour.
At that time, the job runs as soon as the box starts because it is past
the start time. The job runs, another future start job is issued for 15
minutes past the hour, the box completes, and the cycle repeats itself.
Using file watcher jobs provides a means of integrating events which are
external to AutoSys into the processing conditions of AutoSys jobs. For
example, a file needs to be downloaded from a mainframe, and it is
expected to arrive after 2:00 a.m. After it arrives, a batch job is to be run
to process it, possibly even starting a whole sequence of jobs.
You could set up a file watcher job to start at 2:00 a.m. wait for the arrival
of the specified file, then exit. You could also set up the batch job so that
the completion of the file watcher job is its only starting condition.
Note • The owner attribute is required for all job types, but is
automatically assigned by AutoSys.
Job Name
Command
Machine Name
Starting Conditions
The date/time and/or job dependency conditions necessary for the job
to be run. (Strictly speaking, this is not required, such as in cases
where a job will always be started manually.)
Job Name
Machine Name
Starting Conditions
The date/time and/or job status conditions necessary for the job to be
run. (Strictly speaking, this is not required, such as in cases where a
job will always be started manually.)
Box Name
The unique job identifier by which the box is referenced. This name is
used by other jobs as the name of their parent box.
Starting Conditions
The date/time and/or job status conditions necessary for the job to be
run. (Strictly speaking, this is not required, such as in cases where a
job will always be started manually.)
INACTIVE
The job has not yet been processed. Either the job has never been run,
or its status was intentionally altered to “turn off” its previous
completion status.
ACTIVATED
The top-level box that this job is in is now in the RUNNING state, but
the job itself has not started yet.
STARTING
The Event Processor has initiated the start job procedure with the
Remote Agent.
RUNNING
The job is running. If the job is a box job, this value simply means that
the jobs within the box might be started (other conditions
permitting). If it is a command or file watcher job, the value means
that the process is actually running on the remote machine.
SUCCESS
The job exited with an exit code equal to or less than the “maximum
exit code for success.” By default, only the exit code “0” is interpreted
as “success.” However, a range of values up to the “maximum exit
code for success” can be reserved for each job to be interpreted as
success. If the job is a box job, this value means that all the jobs within
the box have finished with the status SUCCESS (the default), or the
“Exit Condition for Box Success” evaluated to true. (These exit
conditions are discussed further in later sections.)
FAILURE
The job exited with an exit code greater than the “maximum exit code
for success.” By default, any number greater than zero is interpreted as
“failure.” If the job is a box job, a FAILURE status means either that at
least one job within the box exited with the status FAILURE (the
default), or that the “Exit Condition for Box Failure” evaluated to true.
AutoSys issues an alarm if a job fails.
TERMINATED
RESTART
QUE_WAIT
The job can logically run (i.e., all the starting conditions have been
met), but there are not enough machine resources available.
ON_HOLD
This job is on hold and will not be run until it receives the
JOB_OFF_HOLD event.
ON_ICE
This job is removed from all conditions and logic, but is still defined
to AutoSys. Operationally, this condition is like deactivating the job.
It will remain on ice until it receives the JOB_OFF_ICE event.
The difference between “on hold” and “on ice” is that when an “on
hold” job is taken off hold, if its starting conditions are already
satisfied, it will be scheduled to run, and it will run. On the other
hand, if an “on ice” job is taken “off ice”, it will not start, even if its
starting conditions are already satisfied. This job will not run until its
starting conditions re-occur.
The other major distinction is that jobs downstream from the job that
is “on ice” will run as though the job succeeded. Whereas, all
dependent jobs do not run when a job is on “on hold”—nothing
downstream from this job will run.
For details on how “on ice” affects boxes, see Chapter 5, Box Job Logic.
STATE
Figure 3-2 depicts the simplest state transition for a job, in which an
event satisfies the starting conditions for the job.
The job starts, processes, and completes with either a failure or success
exit code.
Event Processor
Event is read by Event Processor EVENT
Check Conditions
Event generated by
Remote Agent SUCCESS - OR - FAILURE
Event Processor
EVENT
Check Conditions
SUCCESS - OR - FAILURE
In the case of a box, the box always goes into the RUNNING state as soon
as all its starting conditions are met. This RUNNING event usually
triggers jobs within the box to also start.
If the job has a priority associated with it, all its starting conditions have
been met, and there are not enough machine resources available, it goes
into the QUE_WAIT state. Once the resources become available, it goes
into the STARTING state, then runs.
The value of status reflects the AutoSys event processing. Therefore, a job
might have actually completed on a machine and if the Event Processor
has not processed that event yet, AutoSys will still show the job’s status
as RUNNING. By displaying the detail of the job (either in the Job
Activity Console, or in the output of the autorep command), you can see
all the events for a job, including those that have not processed yet.
In addition, the status always reflects the most recent event that was
processed. Therefore, after a job has completed, the status will remain as
it is on completion. If it ended successfully, the status will remain as
SUCCESS until the job is run again.
Note • When a box job starts, all jobs within the box change state to
ACTIVATED before they run. Jobs will then run immediately, unless
other conditions apply. If a box completes before a job is run, the job
is set to INACTIVE at the time of box completion. As a result, jobs do
not retain their statuses from previous box processing cycles once a
new box cycle has begun.
3 Starting Parameters
AutoSys determines whether or not it should start a job based on the
evaluation of the starting conditions (or starting parameters) defined for
the job. These conditions can be one or more of the following:
■ Date and time scheduling parameters are met (it is or has passed the
specified date and time).
Every time an event changes any of the above conditions, AutoSys finds
all the jobs that might be affected by this change, and determines
whether or not to start them.
Be aware that if this scenario were implemented and “Job2” were placed
ON_ICE, then “Job1” and “Job3” would start simultaneously as soon as
the box they are in started running. (Jobs that are dependent on a job that
is ON_ICE run as if that starting condition has been satisfied).
3 Date/Time Dependencies
AutoSys jobs can be automatically scheduled to start at a certain date and
time, based on the information you supply using JIL statements or the
GUI. You define these dependencies by specifying the day(s) or date(s)
and time(s) for time-based job starts. AutoSys then calculates a matrix of
these values and starts jobs at those times. A time range cannot span
more than 24 hours. You can also specify a time zone to apply to your
starting times.
You can specify days of the week or actual dates. However, you cannot
specify both. You can specify days of the week using JIL or the GUI, but
you can only specify actual dates through the use of custom calendars,
which you can define using the Graphical Calendar Facility.
You can specify times as certain times of the day, or hourly, denoted in
minutes past the hour. Again, the two formats are mutually exclusive.
You can specify either form using JIL or the GUI (you do not have to
create custom calendars).
TZ Environment Variable
By default, jobs with time-based starting conditions that do not specify a
time zone are scheduled to start based on the time zone of the TZ
environment variable (the same time zone under which the Event
Processor runs).
Before you start the Event Processor, ensure that the TZ environment
variable is set. The 3.4.4 Event Processor must be started once after you
upgrade your database to insert the value of the TZ environment variable
into the database. Do this before executing jil, autosc, autocons, or
autorep.
Custom Calendars
Using the Graphical Calendar Facility or the autocal_asc utility, you can
define any number of custom calendars, each with a unique name and
containing any number of dates or date/time combinations. You can use
these calendars in one of two ways: as days on which to run the jobs with
which they are associated, or as days on which to not run the jobs with
which they are associated. Calendars exist independently of any jobs that
may be associated with them; they are referenced by jobs through job
definitions.
The syntax for defining job dependencies is the same whether the job is
being defined using JIL or the GUI. The only difference is the JIL
statement will begin with the JIL condition keyword, while the GUI field
will only contain the language for the dependency itself. The dependency
specification can take one of the following three forms:
where:
success
job_name
You can abbreviate the status condition identifiers with the first letter,
using s, f, d, t, and n. You can also abbreviate the dependency
specification exitcode with the letter e and VALUE (of a global variable)
with the letter v. These abbreviations can be upper- or lowercase.
You can control the value of the SUCCESS status by using the “Maximum
Exit Code for Success” attribute, which can be set for a job. If you specify
this attribute, any job that exits with a exit code less than or equal to the
specified value will be treated as a success. A FAILURE status means the
job exited with an exit code higher than this value. The convention (and
the default) for normal job completion is “0”. A TERMINATED status
means the job was killed.
Multiple instances of AutoSys are not inherently connected, but they can
communicate with each other. You can define jobs to have cross-instance
dependencies, and multiple instances can send events to each other.
For example, multiple instances of AutoSys can send events to each other
by way of a sendevent command line like this:
sendevent -E STARTJOB -J job_name -S autoserv
The job_name argument is a job defined for the instance indicated by the
autoserv argument, which is the instance’s unique, capitalized
three-character identifier.
The specification for such a job dependency might look like this:
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”. If the dependency specification does
not include a caret (^) and a different instance ID, the current instance
will be used, by default.
Figure 3-4 shows two instances of AutoSys, each with a single Event
Server, exchanging cross-instance job dependencies.
Event Event
Processor Processor
Different instances of AutoSys can run from the same executables and can
have the same values for $AUTOSYS and $AUTOUSER, both on the Event
Processor machine and on machines running Remote Agents. However,
they must have a different value for $AUTOSERV.
3 Event Processors
When cross-instance dependencies are implemented, different Event
Processors can do the following:
3 Event Servers
Event Servers keep track of the cross-instance job dependencies. Each
time a job definition with a cross-instance job dependency is submitted
to the AutoSys database, the following entries are made:
■ An entry to the ext_job table of the issuing instance. The entries in this
table specify the status of jobs in other instances in which this instance
has an interest.
In both tables above, jobs are entered using the job name, a caret symbol
(^), and the instance name, as shown below.
jobB^PRD
As indicated in this example, you can use any job status as part of the
specification for a specific job’s starting conditions. With this latitude,
you can program branching paths that must be taken and that will
provide alternate actions for error conditions.
For example, if “JobB” fails after processing only partially, you might
want to call a routine titled “Backout” that backs out of the changes that
were made. You would specify the following job dependency in the job
definition for “Backout”:
failure(JobB)
Or
f(JobB)
You use the notrunning operator to keep multiple jobs from running
simultaneously (i.e., running one job is exclusive of any others). For
example, it might be best not to run a database dump (“DB_DUMP”) and
a file backup (“BACKUP”) at the same time. This 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 aren’t
running. You would specify the smaller job’s dependency like this:
notrunning(DB_DUMP) AND notrunning(BACKUP)
Note • If you have jobs that you want to run exclusively, use the
virtual machine and job queueing feature described in Chapter 9, Load
Balancing and Queuing Jobs.
When a box job is started, all the jobs within the box have their status
changed to ACTIVATED. Therefore, downstream jobs in the box that
depend on the completion of jobs upstream in the same box will use
only the completion statuses from this run of the box. Placing the jobs in
one processing cycle inside a top-level box and setting the box to start at
the beginning of the processing cycle will prevent time-critical jobs from
being affected by invalid information.
When a job is first entered into the database, and prior to its being run
for the first time, its status is set to INACTIVE. By changing to INACTIVE
the status of jobs that have completed, but whose completion status
should no longer be used in dependent job conditions, the completion
status from the last run will no longer be the current status, and it will not
be used.
To change a job status to INACTIVE, use the GUI (Send Event dialog), or
use the sendevent command. Of course, you can create an AutoSys job to
accomplish this as well. If you change the status of a top-level box to
INACTIVE, all the jobs in the box are recursively set to INACTIVE.
Deleting and reinserting the job using JIL will accomplish the same thing.
However, the past reporting history on the job will no longer be
available. (Updating a job using JIL does not change the status of the job.)
Is the name of the job upon which the “new” job is dependent.
operator
value
You can abbreviate the dependency specification exitcode with the letter
e (uppercase or lowercase).
For the above example, you would enter the following for the job
dependency specification for the “JobB” redial job:
e (JobA) = 4
You can use any job status or exit codes as part of the specification for
starting conditions. With this latitude, you can program branching paths
that will provide alternative actions for all types of error conditions.
Generally, a zero exit code indicates success, while a non-zero exit code
indicates an error. The expected error values should be documented with
each individual program, but some programs can return unexpected exit
codes. You should modify these programs so that they return expected
values. Use these values when specifying exit code dependencies.
When launching programs directly from AutoSys, the exit codes are
returned and put in the database. However, there are some exit code
behaviors that you must take into consideration when using AutoSys to
start *.BAT batch files.
The exit code returned from a batch file is the return code from the last
operation executed from within that particular batch file. Consider the
following example:
REM test batch file
test
if errorlevel 1 goto bad
goto good
:bad
del test.tmp
:good
exit
This example batch file will return a 0 exit code as long as test.tmp exists.
If test.tmp does not exist, the return code is from the del line and not
from the line that executes test. Therefore, this batch file will return a 0
(successful) exit code to Autosys, even if test failed to execute as
intended.
When test fails with errorlevel 1, this batch file will return an exit code
of 1 from false, whether the test.tmp file exists or not.
Is the name of the global variable upon which the job is dependent.
operator
When using the Job Definition dialog to define a job, enter the above
expression in the Starting Condition field. When using JIL, enter the
above expression in the appropriate JIL script using the condition
attribute.
You can abbreviate the dependency specification VALUE with the letter v
(upper- or lowercase).
In the example cited above, you would enter the following for the job’s
condition statement:
VALUE(manager-ok) = OK
Or
v (manager-ok) = OK
A top-level job is a job that is not contained in a box, and these run
numbers are inherited by every job that is in a box. This means that all
jobs within a top-level box have the same run number as the number
used for the run of the box. This design permits runs of nested jobs to be
associated together within the same run.
If there are restarts of a job, the run number remains the same, and the
ntrys field is incremented. In the standard reports (see the autorep
command in Chapter 1, AutoSys Commands, in the AutoSys Reference Guide
for UNIX), these two values are displayed in the “Run” column as
run_num/ntry.
AutoSys also maintains a value for each job’s name, which is defined in
the runtime environment for the job. As with $AUTORUN, this value is
accessible to those shell scripts or executables executed as the job’s UNIX
command. The value is contained in the variable $AUTO_JOB_NAME.
Alternatively, you can open the GUI by using the autosc command, and
you can enter the job definition by filling in the appropriate fields of the
Job Definition dialog and its associated dialogs.
You should back up your job definitions periodically, so you can have a
file to restore from in case of system failure. This process is explained in
the Backing up AutoSys Definitions section in Chapter 12, Maintaining
AutoSys.
Used to define jobs. The Job Definition dialog and its related dialogs
allow you to create, view, edit, and delete job definitions for
command jobs, box jobs, and file watcher jobs.
Operator Console
Note • You can also access AutoSys/Xpert from the GUI Control
Panel. For information on using AutoSys/Xpert, see the AutoSys/Xpert
User Guide for UNIX.
Before modifying or deleting an existing job, make sure the job is not
running.
You should back up your job definitions periodically so you can have a
file to restore from in case of system failure. This process is explained in
the Backing up AutoSys Definitions section of Chapter 12, Maintaining
AutoSys.
where:
4 Chapter Organization
In this chapter, job attributes are organized into two categories: Essential
and Optional. Essential attributes are those that must be specified in
order for the job definition to be accepted. As the name implies, optional
attributes are not necessarily required for a job definition to be accepted.
For each attribute described in this chapter, we indicate its name, its JIL
attribute keyword, its corresponding GUI object, or GUI Field Name, and
a description of its use, as shown below:
Job Type
job_type Job Type
Attribute description...
In the example above, the “Job Type” attribute, which specifies whether
a job is a command, file watcher, or box, is specified with the JIL keyword
job_type and is identified in the GUI as the field with the name “Job
Type”.
Because Chapter 2, JIL/GUI Job Definitions, of the AutoSys Reference Guide for
UNIX is organized alphabetically by JIL keywords, the keywords in this
chapter can act as “pointers” to more detailed descriptions about a
particular attribute in the reference chapter. The heading on each
reference page contains the same JIL keyword on the left and GUI field
name on the right as in the example above.
Job Name
insert_job Job Name
The job name is used to identify the job to AutoSys, and must be unique
within AutoSys. It can be from 1 to 30 alphanumeric characters, and is
terminated with white space. Embedded blanks and tabs are illegal.
commands, file watchers, and box jobs cannot use the same name.
Job Type
job_type Job Type
The job type specifies the type of job: command (c), file watcher (f), or
box (b).
Job Owner
owner Owner
The job owner specifies whose user ID the command will be run under
on the client machine. This attribute is automatically set to the user who
invoked jil or the GUI to define the job, and cannot be changed except
by the Edit Superuser.
Command
command Command to Execute
The command attribute can be the name of any command, executable,
UNIX shell script or batch file, and its arguments. 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.
The job’s owner must have execute permission for this command on the
client machine. Input and output redirection cannot be part of the
command. Redirection is specified by other job attributes. 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 use the Send Event dialog in the GUI.
These are additional points to keep in mind with regard to the command
attribute:
■ You cannot use the background character (&) in the command attribute.
A shell script can be called to provide that functionality.
■ All commands are run under the Bourne shell (/bin/sh). Therefore, all
statements in the profile must use /bin/sh syntax. For example:
Variable=value; export Variable
Do not use this:
export Variable=value or setenv Variable Value
■ 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
■ 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.
Machine to Run On
machine Execute on Machine
This attribute specifies the client machine on which the command
should be run. The job’s owner must have permission to access this
machine and to execute the specified command at this machine. The
machine can be a specific real machine (as listed in the /etc/hosts file of
the AutoSys server machine), a set of real machines, or a virtual machine.
You can also specify the svload program or your own, custom load
balancing program in lieu of a machine name. In this case, the Event
Processor will run the program at runtime to select the machine that is
best suited to run the job.
For more information about virtual machines, and how AutoSys chooses
a machine to run on when you specify multiple machines or a load
balancing program, see Chapter 9, Load Balancing and Queuing Jobs.
Machine to Run On
machine Execute on Machine
This attribute specifies the client machine on which the File Watcher
should run. For a File Watcher, this attribute must specify a single real
machine, defined in the /etc/hosts file on the AutoSys server machine.
When using the GUI, this field only appears when the File Watcher type
has been selected. 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.
For information on how date and time attributes are affected by the
Spring and Fall time adjustments, see Date and Time Attributes and Time
Changes on page 4-28.
This attribute controls only when the job will start, not when it will stop
running. This attribute is particularly useful when, for example, it is not
known when a watched-for file will arrive, and there are certain times
when jobs dependent on that file should not run. This setting can prevent
a late-arriving file from causing a job to run at an inopportune time. The
run window range cannot span more than 24 hours. 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.
Note • You can also block out times of day when you do not want a
job to start by putting the job on hold, then taking it off hold later.
The sendevent command can be used to accomplish this, executed
either from the command line, through the Send Event dialog, or
from within a shell script or batch file in another job.
Description
description Description
This attribute provides a comment field, used for documentation
purposes only. When entering a description using JIL, you should enclose
the string in double quotes to ensure JIL properly interprets it. The GUI
adds quotes for you automatically.
Box Name
box_name Name of the Box this Job is IN
Boxes allow 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 specifying their starting conditions
relative to each other individually, if necessary. This attribute specifies the
name of the box in which the job is to be placed. The specified box must
already exist before you can place jobs in it.
If you specify a time zone that includes a colon, you must quote the time
zone name if you are using JIL. For example:
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.
Jobs with time-based starting conditions that do not specify a time zone
will have their start event scheduled based on the TZ environment
variable, which specifies the time zone under which the Event Processor
is running.
If the job did not complete successfully, AutoSys will keep the job
definition for 7 days before automatically deleting it. This attribute is
useful for letting AutoSys schedule and run a one-time batch job.
Autohold
auto_hold Autohold On?
This feature is only for jobs in a box. When a job is in a box, it inherits the
box’s starting conditions. 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). This is typically the desired behavior;
however, there are occasions when it is not.
For example, you might want to place a job in a box, but not start the job
until a non-job (i.e., operating system level) event arrives. By specifying
“yes” to Autohold On, AutoSys automatically changes the job state to
ON_HOLD when the box it is in begins RUNNING. At this point, the job
is in exactly the same state as if it were manually placed on hold. To start
the job, take the job off hold by sending the JOB_OFF_HOLD event via
the Send Event dialog or the sendevent command.
Permissions
permission Permissions
In UNIX, there are three levels of permission by user ID (uid), and within
AutoSys, two levels of job permission.
Execute
If execute permissions are enabled for the user’s group, allows the user
to issue events that affect the running (starting, stopping, etc.) of the
job. Users in primary and secondary groups have this permission.
Edit
If edit permissions are enabled for the user’s group, allows the user to
edit or delete the job definition. Only users in the primary group have
this permission.
For more information about setting permissions, see the Overview section
of Chapter 2, AutoSys Security.
Profile
profile Job Environment Profile
The profile attribute specifies the file to be sourced by the Bourne shell
before the specified command is executed. 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 definitions and exports of environment variables, which can be
referenced in the job’s command. The primary environment variable in
the profile is the $PATH. If a profile is not specified, the default AutoSys
profile, /etc/auto.profile, is used. If the profile attribute is specified,
that profile is searched for on the machine on which the command is to run.
Note • If you are running jobs across platforms, realize that the Event
Processor of the issuing instance controls the default behavior. If the
issuing instance is NT, the default is to overwrite this file.
Note • If you are running jobs across platforms, realize that the Event
Processor of the issuing instance controls the default behavior. If the
issuing instance is NT, the default is to overwrite this file.
Job Load
job_load Job Load
Machines can be assigned “maximum job loads,” which is a measure of
the CPU load that is desirable for 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 prevents 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 when sufficient resources are
available. For load balancing to function properly, all jobs to be run on
a controlled machine must have job loads specified; otherwise, their
impact on a machine cannot be measured.
Note • If you force a job to start, it will run even if its load exceeds the
machine’s max_load. Also, if job_load is specified for a job and no
priority attribute (described below) is set, AutoSys uses the default
priority of 0, which means ignore the job_load and run the job
immediately.
Queue Priority
priority Que Priority
The queue priority establishes the relative priority of all jobs queued for
a given machine, with the lower number indicating higher priority. 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.
priority only influences the starting of jobs that are queued, unless the
jobs are in a box. If jobs in a box have a priority attribute setting, they
will be processed in order of priority, highest to lowest.
Job Overrides
override_job Edit One Time Over-Rides?
You can specify a one-time job override for the next run of a particular job.
An override lets you change the behavior of a job the next time the job
runs.
machine start_times
max_run_alarm std_err_file
For a description of how to use the GUI to specify job overrides, see
Specifying One-Time Job Overrides in Chapter 6, Defining AutoSys Jobs Using
the GUI.
Average Runtimes
avg_runtime (JIL only)
The avg_runtime attribute is used to provide an average runtime (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.
Heartbeat-Interval
heartbeat_interval Heartbeat Interval (mins)
In AutoSys, heartbeats are a means of monitoring a job’s progress. It
automates the common practice of outputting characters, similar to
displaying “progress” asterisks across the screen as a process runs. If a job
does not send a heartbeat within this specified interval, a HEARTBEAT
alarm is generated. The heartbeat interval is specified in minutes.
To send a heartbeat from a C program, you call the routine found in the
following source 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
The Event Processor must be configured to check for heartbeats. To do
this, modify the configuration file, which has the following name:
$AUTOUSER/config.$AUTOSERV
For more information about the AutoSys configuration file, see Sample
Configuration File in Chapter 13, Configuring AutoSys. For information on
sending heartbeats, see Sending Heartbeats in Chapter 7, AutoSys API, of
the AutoSys Reference Guide for UNIX.
Watch Interval
watch_interval Time Interval (secs) to Determine
Steady State
The watch interval specifies (in seconds) how often the File Watcher
should check the current file size to ascertain whether data is still being
written to the file. The default is every 60 seconds.
Box Failure
box_failure FAILURE Condition
The default condition required for a box to complete with a FAILURE
status is that all jobs in the box have completed and one or more jobs in
the box completed with a failure condition. A box can contain complex
branching logic, which may take a number of different paths, one of
which may include recovery from a failed job. In this case, you might
want the box to be considered successful, even though a job within it
failed. This attribute can be used to specify what will be considered as a
failure, which could be as simple as the failure of a single job, or as
complex as necessary. This attribute is only displayed in the GUI when
you select a box job type.
In the spring, at 2 a.m., the clocks spring forward to 3 a.m. In most of the
United States, this happens on the first Sunday in April. Figure 4-1
illustrates the time change.
Daylight-saving Time
1:00 1:59
Standard Time
When this change occurs, time runs 1:58 ST, 1:59 ST, 3:00 DT, 3:01 DT,
and the 2:00 to 2:59 hour is lost.
In the fall, at 2 a.m., the clocks fall back to 1 a.m. In most of the United
States, this happens on the fourth Sunday in October. Figure 4-2
illustrates the time change.
Standard Time
Daylight-saving Time
When this change occurs, time runs 1:58 DT, 1:59 DT, 1:00 ST, 1:01 ST,...,
2:00 ST, 2:01 ST, and the 1:00 to 1:59 hour is repeated.
There are two types of time dependencies within AutoSys: absolute, and
relative. Absolute times are defined to occur at a particular time of day,
for example 9:30 on Thursday, or 12:00 on December 25. Absolute time
dependent job attributes include:
■ days_of_week
■ exclude_calendar
■ run_calendar
■ run_window
■ start_times
Relative times are specified with respect to either the current time, or
relative to the start of the hour. For example, start a job at 10 and 20
minutes after the hour, or terminate a job after it has run for 90 minutes.
Relative time dependent job attributes include:
■ auto_delete
■ max_run_alarm
■ min_run_alarm
■ start_mins
■ term_run_time
■ watch_interval
During the time change, absolute time attributes will behave differently
than relative time attributes, as described below.
If you scheduled a job to run more than once during the missing hour,
for example, 2:05 and 2:25, only the first scheduled job would run. Any
additional start times for the same job in the missing hour will be
ignored.
Therefore, the behavior between two jobs that appear to have the same
times specified, but use start_times versus start_mins, will not be the
same. For example, job “Jrel” has start minutes of 10 and 20 minutes after
the hour, and job “Jabs” has start times of 1:10, 1:20, 2:10, 2:20, 3:10,
and 3:20. “Jrel” will run at 1:10, 1:20, 3:10, and 3:20. “Jabs” will run at
1:10, 1:20, 3:00, 3:10, and 3:20.
Run Windows
Run windows are treated a bit differently. If the specified closing of the
run window falls within the missing hour, its recalculated closing time
will be bumped up an hour, so that the effective duration of the run
window remains the same. For example, a run window of 1:00 - 2:30 will
have the closing time move to 3:30, so that the run window still remains
open for an hour and a half.
If the specified opening of the run window falls within the missing hour,
its opening time is moved to 3:00. The closing time does not get altered,
therefore the run window is foreshortened. For example, a run window
of 2:45 - 3:45 will become 3:00 - 3:45, and the actual run window elapsed
time will be 15 minutes shorter.
If both the specified opening and closing of the run window is within the
missing hour, its opening time is moved to the first minute after 3:00,
and its closing time is pushed forward one hour. Therefore, the resultant
run window may be lengthened. For example, a run window of
2:15 - 2:45 will become 3:00 - 3:45, or 15 minutes longer.
For example, a job scheduled to run on Sundays at 1:05, will run only at
the second 1:05. A job scheduled to run every 30 minutes will run at 1:00
DT and 1:30 DT, then again at 1:00 ST and 1:30 ST, and so on (as shown
in Figure 4-3).
Standard Time
Daylight-saving Time
Jobs that are not time-based, but have other dependencies, will still run
during the first hour.
When testing this time change, you must set the clock to a time before 1
a.m. and allow the entire hour to pass before you can observe the time
change. If you manually set the time to a period within the 1 a.m to 2
a.m. window, the system will assume that the time change has already
occurred and will not reset at 2 a.m.
Run Windows
Run windows are treated a bit differently. If the specified opening of a
run window is before the time change, and its specified closing falls
within the repeated hour, it will close during the daylight saving, or first
hour. For example, a run window of 11:30 - 1:30 will have the closing
time of 1:30 DT, not 1:30 ST, which means that the run window remains
open for its specified two hours. This may be a problem if there are also
associated start times on the job which occur during the repeated hour.
In the example above, if the job also had a start time of 1:15, the start
time would be calculated for 1:15 ST, and the job would not run on the
day of the time change.
If the specified opening of the run window falls within the repeated hour,
its opening time is moved to the second, Standard Time hour. The closing
time does not get altered, therefore the length of the run window will
remain the same. For example, a run window of 1:45 - 2:45 will become
1:45 ST to 2:45, or the same hour in length.
If both the specified opening and closing of the run window is within the
repeated hour, the run window will be open during the second, Standard
Time hour.
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11
Advanced Conditions in Box Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11
Default Box Success and Box Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14
Explicit Box Success and Box Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16
■ Boxes should be used primarily for jobs with the same starting
conditions. A box used to group sequential jobs is limited to 1,000
jobs.
■ By default, a box will return a status of SUCCESS only when all the
jobs in the box have run and the status of all the jobs is “success.”
■ By default, a box will return a status of FAILURE only when all jobs in
the box have run and the status of one or more of the jobs is “failure.”
Avoid the temptation to put jobs in a box as a short cut for performing
events (such as ON_ICE or ON_HOLD) on a large number of jobs at
once. You will most likely find that the default behavior of boxes inhibits
the expected execution of the jobs you placed in the box.
Likewise, you should not place jobs in a box solely because you want to
run reports on all of them. When you run autorep on a box, you will get
a report on the box and all the jobs in the box (unless you use the -L0
option). In addition, if you use wildcarding when specifying a job name,
you could get duplicate entries in your report. For example, suppose you
have a box named “acnt_box” containing three jobs named “acnt_job1”,
“acnt_job2”, and “daily_rep”. If you specify acnt% as the job name for the
autorep report, the report will have an entry for the box “acnt_box” and
an entry for each job in the box. Then autorep will continue searching for
all job names matching the wildcard characters and, thus, will list
“acnt_job1” and “acnt_job2” a second time.
If a box is terminated before a job in it was able to start, the status of that
job will change directly from ACTIVATED to INACTIVE.
Note • Jobs in a box cannot start unless the box is running. However,
once the job starts running, it will continue to run even if the box is
later stopped for some reason.
Once all the jobs in a box have completed successfully, the box completes
with a status of SUCCESS. The status of the box and the jobs in the box
remain unchanged until the next time the box runs. (Some exceptions to
this are explained in How Job Status Changes Affect Box Status.)
job_a job_b
job_c
If “job_b” fails, “job_c” will not start; it will remain in ACTIVATED state.
Because no contingency conditions have been defined, “simple_box”
will continue running indefinitely, waiting for the default completion
criteria to be met, namely that all jobs in the box ran.
The box_terminator: y attribute specifies that if the job fails, the box the
job is in should terminate. If you use this attribute, be sure you have
defined conditions for the other jobs in the box in the event that the box
is terminated. For more information, see Figure 5-7.
The job_terminator: y attribute specifies that if the box the job is in fails,
this job will terminate. If you want every job in a box to terminate upon
box failure, you must add this attribute to every job definition. For more
information, see Figure 5-8.
Remember also that the box must be running before the job can start. Do
not assign a start time for a job in a box if the box will not be running at
that time. If you do, the next time the box starts, the job will start
immediately.
bx_stat job_a
3:00 a.m. Daily
run until succeed
job_report
success(job_a)
Report success of job_a
If you force start a job in a box, the state of the box influences whether or
not other jobs in the box will run as expected, as shown in the following
example.
bx_report
3:00 a.m. Daily
In Figure 5-3, if the job “run_stats” fails, the “bx_report” box job will
terminate because “run_stats” has a box_terminator attribute. If you force
start “run_stats”, and it completes successfully, “report_stats” would still
not start because the box it is in is not running.
The next section discusses how job status changes influence the status of
the container box.
If a box contained only one job, and the job changed status, the box
status would change as shown in Table 5-1.
Table 5-1 • How Job Status Changes Impact Box Status
If another AutoSys job is dependent on the status of the box, the status
change could trigger the job to start. If the box status does not change,
dependent jobs are not affected.
If the box contains other jobs in addition to the job that changed status,
the status of the box will be re-evaluated according to the success or
failure conditions assigned to the box (either the default or user-
assigned). Any jobs in the box with a status of INACTIVE are ignored
when the status of the box is being re-evaluated. For example, consider
an INACTIVE box that contains four jobs, all with a status of INACTIVE
(this is typical of a newly created box). If one of the jobs is force started
and completes successfully, the status of the box will change to SUCCESS
even though none of the other jobs ran.
5 Examples
Spend some time studying the examples in this section. They will help
explain the logic of job flow in a box and reduce your chances of creating
unexpected box behavior.
■ The box job named “bx_daily_update” has date and time conditions
specified for its starting conditions; it runs every day of the week at
3:00 a.m. This box contains three Command Jobs whose overall
purpose is to update files and generate a report.
bx_daily_update
3:00 a.m. daily
job_update
box_terminator: y
Update files
job_run_stats
success(job_update)
box_terminator: y
Run statistics
job_report_stats
success(job_run_stats)
Report statistics
job_trigger_msg
failure(bx_daily_update)
Page operator
SUCCESS job_trigger_msg
update_accounts FAILURE
SUCCESS
run_stats
FAILURE ACTIVATED
success(update_accounts)
SUCCESS
report_stats
FAILURE ACTIVATED ACTIVATED
success(run_stats)
SUCCESS
Job Definitions
do_statistics
3:00 a.m. Daily
box_success: success(update_accounts) AND success(run_stats) AND
success(report_stats)
box_failure: failure(update_accounts) OR failure(run_stats) OR
failure(report_stats)
update_accounts run_stats report_stats
success(update_accounts) success(run_stats)
update_accounts FAILURE
SUCCESS
SUCCESS
report_stats
FAILURE INACTIVE INACTIVE
SUCCESS
Job Definitions
daily_accounts
3:00 a.m. Daily
daily_receipts daily_payables daily_balance
box_terminator: y box_terminator: y success(daily_reciepts)
AND success(daily_payables)
Process Receipts Process Payables Calculate Balance
Job Stream
daily_accounts
daily_receipts daily_payables
SUCCESS SUCCESS
FAILURE FAILURE
daily_balance
Job Definitions
daily_accounts
3:00 a.m. Daily
daily_receipts daily_payables daily_balance
job_terminator: y success(daily_reciepts)
AND success(daily_payables)
Process Receipts Process Payables Calculate Balance
Job Stream
daily_accounts
SUCCESS SUCCESS
FAILURE FAILURE
daily_balance
Job Definitions
job_Fwatch job_monthly job_daily
1:00 a.m. First Day 2:00 a.m. First Day 3:00 a.m. Daily
of Month of Month success(job_monthly)
term_run_time: 90 success(job_Fwatch)
Watch for File Re-index, Organize, Purge Generate Report
Job Stream
Date/Time Start File from
job_Fwatch Mainframe
Conditions Met
Job Dependency
Condition Met SUCCESS
Date/Time Start
job_monthly
Conditions Met
Event Status in
AutoSys Database =
SUCCESS SUCCESS
Job Dependency
Condition Met
Start job_daily
Date/Time
Conditions Met
SUCCESS
Job Definitions
job_Fwatch job_monthly job_daily
1:00 a.m.First Day 2:00 a.m. First Day 3:00 a.m. Daily
of Month of Month success(job_monthly)
term_run_time: 90 success(job_Fwatch)
Watch for File Re-index, Organize, Purge Generate Report
Job Stream
Job Dependency
Condition NOT Met
Event Status in
Date/Time NOT RUN job_monthly AutoSys Database =
NOT Conditions Met SUCCESS (from Jan 1)
Job Dependency
Condition Met
Start job_daily
Date/Time
ConditionsMet
SUCCESS
Job Definitions
job_Fwatch job_monthly job_daily
1:00 a.m.First Day 2:00 a.m. First Day 3:00 a.m. Daily
of Month of Month success(job_monthly)
term_run_time: 90 success(job_Fwatch)
Watch for File Re-index, Organize, Purge Generate Report
Job Stream
Date/Time Start File from
job_Fwatch Mainframe
Conditions Met
term_run_time: 90
TERMINATED
Job Dependency
Condition NOT Met
Event Status in
NOT RUN job_monthly AutoSys Database =
Date/Time SUCCESS (from Jan 1)
Conditions Met
Job Dependency
Condition Met
Start job_daily
Date/Time
Conditions Met
Job Definitions
job_Fwatch job_monthly job_daily
1:00 a.m.First Day 2:00 a.m. First Day 3:00 a.m. Daily
of Month of Month success(job_monthly)
term_run_time: 90 success(job_Fwatch)
Watch for File Re-index, Organize, Purge Generate Report
Job Stream
term_run_time: 90
TERMINATED Mainframe
Condition NOT Met
Event Status in
Job Dependency NOT RUN job_monthly AutoSys Database =
INACTIVE
Date/Time Job Dependency
Conditions Met Condition NOT Met
Desirable Result
Figure 5-12 • Changing Job Status
box_monthly
box_monthly
SUCCESS
FAILURE
job_monthly
SUCCESS
Job Dependency
Condition NOT Met
job_daily Start
job_daily
NOT RUN Date/Time
Date/Time ConditionsMet
Conditions Met SUCCESS
Note • The three AutoSys/Xpert buttons are disabled if you have not
purchased the AutoSys/Xpert product.
The buttons at the top of the dialog perform the following actions:
The fields in the Job Definition dialog are context sensitive based on the
type of job being defined. When you select a Job Type, only the fields
appropriate to that type of job are displayed and activated, and the other
fields are disabled.
The buttons at the bottom of the dialog perform the following actions:
All entries made in the dialog are maintained in memory after you close
the dialog. They are saved only when you select Save at the Job Definition
dialog.
The Job Definition Advanced Features dialog has fields for all the
additional features that can be specified for a job. Many of these fields are
organized by job type, and they only pertain to the type of job on which
you are working.
Note • The Owner field for the job defaults to the currently logged on
user—not the user shown in these examples.
2 In the Job Type field, single-click on the File Watcher radio button.
/usr/common/EOD_trans_file
Your entries in the Job Definition dialog should look like those shown in
Figure 6-6.
Figure 6-6 • Job Definition Dialog for File Watcher Job “EOD_watch”
At the top-center of the dialog are the File Watching Criteria. In this
region of the dialog, enter the following information:
1 In the Time Interval (secs) to Determine Steady State field, enter the
time interval: 60
AutoSys will check for the file’s existence every 60 seconds, and it will
check if the file has grown between checks—if it has not changed in
size, this is called a “steady state.”
2 In the Minimum File Size (in BYTES) field, enter the minimum file
size which should be reached before the file can be considered
complete: 50000
The file must have reached this minimum size, and must have reached
a “steady state” before the file watcher job will complete with a
SUCCESS condition.
3 To save the job and dismiss the Job Definition Advanced Features
dialog, single-click on the Save&Dismiss button.
The filled-in dialog should look like the one shown in Figure 6-7.
Figure 6-7 • Job Definition Advanced Features Dialog - File Watcher Job
The filled-in Job Definition dialog should look like the one shown in
Figure 6-8.
For information on the profile job attribute, see Chapter 2, JIL/GUI Job
Definitions in the AutoSys Reference Guide for UNIX.
Now you will create a box, then change the job you just created to put it
in the box, and then make it no longer individually dependent on the file
watcher.
When you select the box job type, the lowest section of the Job
Definition dialog changes from “Command & File Watch
Information” to “Box Completion Conditions.”
6 Changing a Job
This exercise will change an existing job. You should make sure a job is
not running before you modify or delete it.
In this exercise, you will place the “EOD_post” job, created previously, in
the newly created box. To load an existing job into the Job Definition
dialog, you can either enter its name explicitly in the Job Name field and
click the Search button, or you can use the Search Facility. For this
exercise, you will use the search facility. You can enter some portion of
the job name, followed by the “%” wildcard character. The “%” character
will match any string of one or more characters in the job name. For
instance, “%box%” will match any job name with the string “box”
anywhere in the name.
A Selection List Box similar to the one shown in Figure 6-10 appears
containing all the jobs currently defined in the database that start with
the string “EOD”. (The list box shown below may not match yours
exactly, since you can have other jobs defined.)
3 Typing just the % wildcard character will display all the jobs defined
in the database.
This will automatically dismiss the Selection List Box and display the
requested job in the Job Definition dialog. If the job you wanted was
not in the list, you could click on the Cancel button to dismiss the
Selection List Box without making a selection.
This field also has a search facility, which works the same as the Job
Name search facility, complete with wildcarding using the “%”
character.
3 Click on the Save button at the top of the dialog to save the changes.
To set the job to run on certain days at certain times, such as 10:00
a.m. and 2:00 p.m. on Mondays, Wednesdays, and Fridays
1 In the Job Name field, enter the job name to be modified: test_run
6 In the Date region of the dialog, select the days on which the job is to
run. In this case, single-click on the Monday, Wednesday, and Friday
buttons.
These buttons can be toggled on and off and are not mutually
exclusive.
7 In the Time region of the dialog, select the time(s) when the job is to
be run, in this case, click on the Time(s) of day field, then enter:
10:00, 14:00
Unlike in JIL, the times do not have to be enclosed in quotes when
they are entered in the GUI.
To save the new start date/time information for this job in the
database
} Single-click the Save button in the Job Definition dialog.
If you want to run a job every day, rather than only on specific days, you
single-click on the Every Day button instead of the individual buttons for
each day.
If you want to schedule a job for specific dates, rather than specific days
of the week, you can specify a custom calendar name in the “Run on Days
in Calendar” field. If the custom calendar does not already exist, create it
by single-clicking the Calendars button, which displays the Graphical
Calendar Facility.
To view the calendars defined in AutoSys, use the Search buttons beneath
each of these fields. These buttons display a list box from which you can
select a pre-defined calendar. To define a calendar “on the fly,” single-
click the Calendars button, which displays the Graphical Calendar
Facility.
6 Deleting a Job
Now you will delete the “test_run” job, which you just modified. You
delete all jobs, regardless of type, in exactly the same way. To delete a job,
you can either enter its name explicitly in the Job Name field, or use the
search facility. In this final exercise, you will use the search facility. You
can enter some portion of the job name, followed by the “%” character,
or just enter the “%” character alone, for a global search.
To delete a job
1 In the Job Name field, enter: %
A Selection List Box appears, allowing you to select the desired job.
4 Verify that the “test_job” job is displayed in the Job Definition dialog.
5 To delete the job from the database, at the top of the Job Definition
dialog, single-click on the Delete button.
Using the GUI, there currently is no way to delete just the box itself and
not its contents.
However, with JIL, you can use the delete_job sub-command to delete
the box while leaving its contents intact (see Deleting a Job in Chapter 7,
Defining Jobs Using JIL).
The GUI includes more fields than are discussed in this chapter. All fields
are discussed in detail in Chapter 2, JIL/GUI Job Definitions in the AutoSys
Reference Guide for UNIX.
Job overrides are applied for the next run of the job only. If an AutoSys
RESTART event is generated because of system problems, AutoSys will re-
issue a job override until the job actually runs once, or until the
maximum number of retries limit is met. After this, the override is
discarded.
The GUI dialogs, regions, and fields that you can use in a job override
specification (definition) are listed in Table 6-1.
Table 6-1 • Dialogs, Regions, and Fields for Job Overrides (continued)
Table 6-1 • Dialogs, Regions, and Fields for Job Overrides (continued)
3 At the appropriate dialogs and fields, specify the overrides you want.
■ The time interval after which the Monitor/Browser GUI will drop the
connection to the database.
■ The Monitor/Browse GUI icon text and the Monitor/Browse title bar
text.
Individual users may have their own copy of the X resources files in their
$HOME directory, which will take precedence over the app-defaults files.
For most operating systems, if you are exporting the display to another
machine you must edit the appropriate files in the app-defaults
directory on the local machine.
For Solaris, you must edit the files in both the /usr/lib/X11/
app-defaults and /usr/openwin/lib/app-defaults directories. The files
in /usr/lib/X11/app-defaults control the resources when you export the
display.
Note • When changing icon text, be sure the length of the new text
string does not exceed the recommended maximum length for icon
title text for your windowing system. Some window managers can
display long icon text strings, while others will truncate them. Ensure
the text string you specify for your icons displays appropriately. Also,
some window managers allow you to change the size of icons and
icon text font.
Note • In this chapter, all keywords shown in bold fixed font are to be
typed exactly as shown. All words shown in italic are variables that
you specify.
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 7-1.
job_name
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 have the following form:
attribute_keyword: value
where:
attribute_keyword
Rule 3
Multiple attribute statements can be entered on the same line, but the
lines must be separated by at least one space.
Rule 4
A box 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, hyphens, underscores, numbers, colons (if the
colon is escaped with quotes or a preceding backslash), and the special
character “@”.
Rule 6
Any colons used in an attribute statement’s value setting must be
escaped, because 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.
Rule 7
Comments are indicated using one of the following two methods:
7 JIL Sub-commands
JIL sub-commands are used to create, modify, override, or delete a job
definition. These sub-commands are listed in Table 7-1.
Table 7-1 • Primary JIL Sub-commands for Defining Jobs
Sub-command Action
For the jil command to work properly, the correct AutoSys environment
variables must be assigned. For more information about these variables,
see the AutoSys Installation and Getting Started Guide for UNIX. For more
information about the jil command, see its definition in Chapter 1,
AutoSys Commands in the AutoSys Reference Guide for UNIX.
7 Running JIL
After a job definition has been submitted to the AutoSys database, it will
be started according to the starting parameters specified in its JIL script.
That is, the Event Processor will continually poll the database and when
it determines that the starting parameters have been met, it will run the
job.
If a JIL script does not specify any starting parameters for a job, the job
will not be started automatically by the Event Processor; it will start only
if you issue the sendevent command. For example, assume a job named
“test_install” has no starting parameters specified in its JIL script. The
only way to start it would be to issue the following command:
sendevent -E STARTJOB -J test_install
This command tells the Event Processor to start the job named
“test_install”.
For more information about the sendevent command, see its definition
in Chapter 1, AutoSys Commands in the AutoSys Reference Guide for UNIX.
■ Determine if the file has reached the minimum file size of 50,000
bytes.
Until the minimum file size of 50,000 bytes has been reached, the file
won’t be considered by AutoSys as “complete.” When the file reaches this
minimum size and does not change between check intervals (60 seconds
in this example) it is considered compslete (also known as “steady
state”). When this occurs, the file watcher job will end with a SUCCESS
condition.
For example, the JIL script required to define a dependent command job
named “EOD_post” is given below. “EOD_post” will be specified to run
on the same machine as the file watcher job created in the previous
section, since it presumably will need the watched-for file to process.
And, it will be dependent on the success of the file watcher job.
insert_job: EOD_post
job_type: c
machine: tibet
condition: success(EOD_watch)
command: $HOME/post
■ To run the job only if the file watcher job named “EOD_watch”
completes with a SUCCESS status.
For information on the profile job attribute, see its entry in Chapter 2,
JIL/GUI Job Definitions in the AutoSys Reference Guide for UNIX.
7 Creating a Box
Box jobs are a convenient way to start multiple jobs. When you put jobs
in a box, you only have to start a single job (the box) in order for all the
jobs in the box to start running.
Assume you want to schedule a group of jobs to all start running once the
file watcher completes successfully. Rather than make each job
dependent on the file watcher, you can create a box that is dependent on
the file Watcher, and place all of the jobs in the box.
Now you will create a box, then change the job you just created to put it
in the box, and then make it no longer individually dependent on the file
watcher. The JIL script required to define a box job named “EOD_box” is
given below:
insert_job: EOD_box
job_type: b
condition: success(EOD_watch)
■ To run the job only if the file watcher job named “EOD_watch”
completes with a SUCCESS status.
7 Changing a Job
To place an existing job in a box, you need to change the “EOD_post”
command job that was created above. You will place the “EOD_post” job
in the newly created box.
You should make sure a job is not running before you modify or delete it.
To change a job, you can either use the update_job sub-command, or you
can delete the job definition, using the delete_job sub-command, then
redefine the job using the insert_job sub-command. The latter scenario
is particularly useful when many non-default attributes have been
specified, and you want to “unset” them rather than “reset” them; in
other words, you want to de-activate them. However, you’ll have to re-
specify any of the attributes that need to remain the same.
So, in the example below, you’ll use the update method. The JIL script
required to change the “EOD-post” job and to put it in the “EOD_box”
is given below:
update_job: EOD_post
condition: NULL
box_name: EOD_box
■ Remove the starting condition from the job definition, because the
job will inherit the starting condition of the box in which it is placed.
The “EOD_post” command job is now in the “EOD_box” box job, and
has inherited the box’s starting parameters.
■ On each of these three days, start the job at 10:00 a.m. and 2:00 p.m.
The times shown in the script above are quoted, since they contain a
colon. They could also have been escaped by using backslashes, as shown
below:
start_times: 10\:00, 14\:00
If you had wanted to run the job every day, rather than only on specific
days, you could have specified the all value, instead of listing the
individual day values. Or, if you had wanted to schedule the job for
specific dates, rather than specific days of the week, you could have
specified a custom calendar. First, you would have had to define the
calendar, using the Graphical Calendar Facility, or the autocal_asc
command. Then, you would specify the calendar name, “weekday_cal”,
using the following JIL statement:
run_calendar: weekday_cal
Alternatively, you could have specified a custom calendar specifying the
days on which the job was not to be run, “holiday_cal”, using the
following JIL statement:
exclude_calendar: holiday_cal
If you wanted the job to run at specific times every hour, as opposed to
specific times of day, the minutes past every hour could have been
specified. For example, to run a job at a quarter after and a quarter before
each hour, use the following JIL statement:
start_mins: 15, 45
7 Deleting a Job
Now you will delete the “test_run” job, which you specified at the
beginning of this chapter. To delete the “test_run” job, enter the
following JIL sub-command:
delete_job: test_run
The delete_job sub-command 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
mode).
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 only 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).
To cancel the job overrides specified in the script above, you would enter
the following JIL script:
override_job: RunData delete
Note • Once you have submitted a JIL script to the AutoSys database,
you cannot view the JIL script and edit a job override. If you want to
change the override values, you must submit another JIL script with
new values, or use the GUI. However, the original override (i.e., the
first over_num) remains stored in the “overjob” table in the AutoSys
database.
■ When the above functions are completed, the file named /download/
mainframe/sales.sql (containing SQL statements) is executed.
# Example of Jobs
insert_job: Nightly_Download
job_type: b
date_conditions: yes
days_of_week: all
start_times: "02:00"
insert_job: Watch_4_file
job_type: f
box_name: Nightly_Download
watch_file: /download/mainframe/sales.raw
machine: gateway
insert_job: filter_data
job_type: c
box_name: Nightly_Download
condition: success(Watch_4_file)
command: filter_mainframe_info
machine: gateway
std_in_file: /download/mainframe/sales.raw
std_out_file: /download/mainframe/sales.sql
std_err_file: /log/filter_mainframe_info.err
insert_job: update_DBMS
job_type: c
box_name: Nightly_Download
condition: success(filter_data)
machine: gateway
command: isql -U mutt -P jeff
std_in_file: /download/mainframe/sales.sql
An example of the output generated by the autorep command for the
above job definition is provided in the Examples section for the autorep
command in Chapter 1, AutoSys Commands of the AutoSys Reference Guide
for UNIX.
8 Introduction
An AutoSys calendar is simply a collection of dates grouped as a single
entity. The Calendar Facility lets you define and maintain AutoSys
calendars using a point and click approach on graphical displays of a
conventional calendar. Once these dates are defined in a calendar, you
can use the calendar to schedule jobs. In the job definition, you can
specify that a job start (or not start) on the dates defined in a calendar.
Calendars do not in themselves convey any rules about when a job
should or should not start; this meaning is assigned exclusively through
the job definition.
■ Define calendars.
For example, you could create a calendar called “holidays” containing the
dates of all corporate holidays. For jobs that you want to start on
holidays, you would define this using the attribute:
run_calendar: holidays
For jobs that you do not want to start on holidays, you would define this
using the attribute:
exclude_calendar: holidays
Jobs scheduled with the run_calendar attribute are scheduled on the next
available date from that calendar. Dates previous to the current date are
ignored.
For more details on these job attributes, see their reference pages in
Chapter 2, JIL/GUI Job Definitions in the AutoSys Reference Guide for UNIX.
Term Calendar Rule This dialog is used to specify a rule to apply to the
dialog calendar currently being created or modified.
8 Menu Bar
At the top of the Calendar Definition window is the menu bar,
containing four pull-down menus: File, Edit, Tools, and Options.
File Menu
The File menu contains the following options:
Save As Displays the Save As dialog, asking you for the new
name under which the calendar currently being
edited will be saved.
Edit Menu
The Edit menu contains the following options:
Tools Menu
The Tools menu contains the following options:
Job Definition Displays a list of all the jobs which reference the
Reference List calendar currently being edited, either as their “run
calendar” or “exclude calendar.” This list indicates
which jobs will be affected by any changes you make
to the current calendar. The Job Definition List is
shown in Figure 8-2.
Options Menu
The Options menu contains the following options:
8 Calendar Display
The Calendar Display region of the window displays six months of the
calendar currently being edited. By default at startup, two quarters of the
current year display, one of which contains the current day (indicated by
a box). Using the navigation controls at the right side of the window, you
can advance or move backward through the calendar, one quarter at a
time.
The Calendar Name field at the top left of the Calendar Display region
displays the name of the calendar currently being edited. You can change
this name using the Rename option from the File menu. You cannot edit
the Calendar Name field.
Date States
Each date in the calendar is a selectable button. By using the mouse and
single-clicking, you can set each date to one of the following states:
You can cycle through these three states by single-clicking on the mouse
button additional times. The current state of each date is indicated by its
color, as listed in the Color Key area of the Navigation Controls region.
Note • Calendars are stored in the AutoSys database. Only the Set
dates are stored. Dates designated as Blocked are only in effect while
editing a calendar. The Blocked state is only useful while applying
rules. Blocked dates are not saved in the AutoSys database, nor are the
rules.
■ A date that qualifies for setting by the rule has been previously set to
the Blocked state and rescheduling has not occurred. (Rescheduling
may not have occurred if either a reschedule rule has not been
applied, or an applied reschedule rule cannot find a non-conflicting
date to move to.)
For example, you may have marked all holidays as Blocked, one of which
was January 1. Now you want to apply a rule to the first day of each
month, which would conflict with the January 1 Blocked date. If there is
no reschedule rule in effect, such as “move to the next weekday,” or if the
reschedule rule specifies to move backwards, which would end up on a
date in the previous year, a Conflict state would result. In this case, you
must manually correct the situation before attempting to save the
calendar to the database.
8 Navigation Controls
The Navigation Controls region of the window contains controls which
do the following:
■ Let you specify which six months (or two quarters) are to be displayed
in the window.
First Entry Changes focus to the first date in the calendar that
has been set.
Next Entry Changes focus to the next date in the calendar that
has been set relative to the date that currently has the
focus.
Next Conflict Changes focus to the next date in the calendar that
has been set to the Conflict state by the system.
Last Entry Changes focus to the last date in the calendar that
has been set.
Note • The date with the focus is designated with a black box around
the date.
When you use the skip buttons, if the focus is changed to a date that is
not currently displayed, the calendar display will shift to bring that date
into view.
3 Press Return.
5 Choose File } Save. Your calendar will resemble the one shown in
Figure 8-3.
When this dialog appears, it contains a scroll list of all the calendars
currently in the AutoSys database. In the Filter field of this dialog, you
may specify any string, including the “*” wildcard character, to show
only those calendars whose names include the string. The default filter,
“*”, matches all calendar names. For example, to display only those
calendar names starting with the string “us_hol”, such as “us_hol_97”
and “us_hol_98,” you would specify the filter “us_hol*”, then click the
Filter button. The list will display only the matching calendar names.
You can select any calendar in the list by single-clicking with the mouse.
Click OK to open the calendar and dismiss the dialog. Click the Cancel
button to dismiss the dialog without selecting a calendar.
The Term Calendar Rule dialog is divided into the following three
regions:
8 Rule Specification
The Rule Specification region provides a variety of options for specifying
which dates in the currently selected calendar you want to affect, and
what state to set for those dates. This region consists of the following
three areas:
■ Action Area
■ Date Range
Action Area
The Action Area lets you apply one of the following states on the selected
dates:
Block Dates Change the state to Blocked. Blocked dates will not
be set during any subsequent rule applications.
Note • These actions are mutually exclusive; only one of these actions
can be selected.
Note • Rules are not applied to any date prior to today’s date.
Day Lets you specify the days of the week to which the
rule should be applied. Select one of the following:
Day (Any), Weekday, or Specific Day(s). If Specific
Day(s) is selected, one or more of the specific days of
the week must be chosen as well.
Period Lets you specify the period during which the rule
should be applied. Only one of the following
options can be chosen: No Period, Monthly,
Quarterly, Every “n” weeks, or the days in a specified
Calendar. The No Period option is used for non-
repeating periods, such as Every/Monday—this
option is generally used with the Every or Every “th”
option in the Occurrences sub-area.
If the Calendar option is selected, only the dates
specified in the indicated calendar will be used when
applying the rule. You can either enter the calendar
name directly, or press the Calendar button to
display the Calendar Selection dialog, from which
you can choose a calendar for the period.
Note • The rules used to set a calendar are not saved after the calendar
has been created and saved.
Setting Dates
To set the 3rd Tuesday of every month throughout the entire currently
selected calendar
1 In the Action area, select Set Dates.
2 Keep the default date range, which is the currently selected calendar's
entire range.
6 Click OK or Apply to apply the rule to the calendar you are currently
editing.
Blocking Dates
To block every holiday date and prevent those days from being
scheduled
Follow these steps (assuming the holiday dates already exist in a calendar
named “us_hol_98”).
2 Keep the default date range, which is the currently selected calendar's
entire range.
5 In the Period sub-area, press the Calendar button. When the Calendar
Selection dialog appears, select the calendar named “us_hol_98”, and
click OK. The calendar name will appear in the Calendar field in the
Period sub-area.
6 Click Apply to apply the rule to the calendar you are currently editing.
Following on with the above example, assume that you want to change
the state of the first day of every month to Set.
2 Keep the default date range, which is the currently selected calendar's
entire range.
6 Click Apply to apply the rule to whatever calendar you are currently
editing.
When you apply this rule, a Conflict state will be assigned to January 1,
since this date is defined in “us_hol_98,” and was marked as Blocked in
the previous example. To address this you must either “unset” it
manually and, if desired, set another date in its place, or you could
specify a Rescheduling Rule to accommodate this type of conflict.
Rescheduling Rules are described in the next section.
8 Rescheduling Rule
The Rescheduling Rule region lets you control how date conflicts should
be resolved when applying a rule. To specify a rescheduling rule, you
must indicate a “move direction” and the day to which the newly
scheduled Set state should be moved when a conflict occurs. You do this
in the Move Direction and To Day areas.
Move Direction
You can select one of the following Move Direction options:
To Day
In addition to specifying the Move Direction, you must specify one of the
following To Day options:
Example
To remedy the conflict situation in the last example from the previous
section (on page 8-22), assume that you want to apply a Rescheduling
Rule that specifies “any day following the date in conflict that is not also
a holiday.”
2 Keep the default date range, which is the currently selected calendar's
entire range.
7 In the To Day area, select the Not in Calendar option and enter the
calendar named “us_hol_98”.
8 Click OK or Apply to apply the rule to the calendar you are currently
editing.
8 Control
At the bottom of the Term Calendar Rule dialog, there are three buttons:
OK, Apply, and Cancel. The OK button applies the current rule and
dismisses the dialog. The Apply button applies the rule but does not
dismiss the dialog. The Cancel button dismisses the dialog without
applying the rule.
Calendar Display At the left and center of the window. The dates in
this calendar are read only—they cannot be edited.
You can only edit dates using the Calendar
Definition window.
When the Term Calendar Viewer first appears, it displays six months of
the current year. You must then select a calendar by single-clicking on its
name in the Calendar Selection list in the lower-right corner of the
window. Navigation is exactly the same as in the Calendar Definition
window.
When you are finished viewing calendars, click the Dismiss button to
close the window.
8 Combining Calendars
Calendars can be combined in a number of ways. For example, you can
create a calendar that includes all the dates that are in either one calendar
or another. Or you can create a calendar that includes all the dates that
are in one calendar but not in another. In fact, you can combine any
number of calendars in these ways.
To combine calendars
1 Choose File } New.
3 Click OK.
5 In the Term Calendar Rule dialog, select the Set Dates Action, the
Every Occurrence, and the Day (Any) Day settings.
Note • When combining calendars, any dates prior to the current date
will be dropped from the new calendar.
8 Printing Calendars
You can print calendars to obtain a hard copy for your files. Before you
attempt to print a calendar, be sure the print command is correctly
specified, either through your X resources file, or by way of the Set Print
Command option from the Options menu. The print command must
include the full path to the print facility to be used, plus all appropriate
arguments. Once this is set, you can open an existing calendar, or create
a new calendar, then select the Print option from the File menu.
At this dialog, you can either enter the full path to the calendar in the
Selection field, or use the Filter field, Directories list, and Files list to
select the file.
When using a filter, the Filter field must contain a directory pathname,
which is everything up to the last slash (“/”) followed by the file pattern
containing an asterisk (“*”). For example, to search the directory /home/
my_dir for all file names with the string cal, you would specify: /home/
my_dir/*cal*. Then, click the Filter button, and the Files list will display
all the files containing that string. Then, click on the file you wish to
import, and the full pathname will appear in the Selection field. Finally,
click OK to import the file.
Note • If the text file being imported contains calendars with the same
names as calendars already existing in the database, these calendars
will not be imported. A warning dialog will notify you that a calendar
name is duplicated, and that the import of this calendar will not
occur. Also, after the import has completed, an information dialog
will tell you how many calendars were imported.
8 Exporting Calendars
You can export all the calendars from the AutoSys database to an ASCII
text file. To export, select File } Export. The Export File Name dialog will
display, allowing you to specify a filename for the calendar text file.
Note • When you use the export facility, all the calendars in the
AutoSys database are exported to a single ASCII text file. After the
export has completed, an information dialog will tell you how many
calendars were exported. You cannot export just a single calendar;
however, you can edit the ASCII file after you export all the calendars.
The Export File Name dialog uses the same filtering as described in
Importing Calendar Text Files on page 8-28.
■ The fonts that are used in the Calendar Definition window as well as
the Calendar Facility dialogs. The choice of fonts will affect the size of
the various windows and dialogs.
■ The colors used to indicate whether dates are Set, Unset, or Blocked.
■ The Calendar GUI icon text and the Calendar title bar text.
Individual users may have their own copy of the X resources files in their
$HOME directory, which will take precedence over the app-defaults files.
For most operating systems, if you are exporting the display to another
machine you must edit the appropriate files in the app-defaults
directory on the local machine.
For Solaris, you must edit the files in both the /usr/lib/X11/
app-defaults and /usr/openwin/lib/app-defaults directories. The files
in /usr/lib/X11/app-defaults control the resources when you export the
display.
We have listed the various resource names here as a reference only. For
the default values, see the Autocal file. The provided resource file values
work well for a majority of platforms.
8 Object Color
The following resources affect the colors of the various objects within the
Calendar Facility.
The following resource sets the color for a grid that appears between the
dates in the Calendar Viewer window, to help differentiate it from the
Calendar Definition window. If you do not want the grid to appear, select
the same color as the background.
Autocal*viewerColor:
8 Date Range
The following resource sets the number of years in the date range of the
calendar, as a default at start up. This can be overridden manually by way
of the Date Range option from the Options menu, or by loading a
calendar that has a larger date range than the default. These are the legal
settings:
! 1 = prior year plus current year,
! 2 = thru next year, 3 = thru third year,
! 4 = thru fourth year, 5 = thru fifth year,
! 10 = thru tenth year
Autocal.dateRange:
8 Window Size
The following resources help keep the size of the window small, and it is
recommend that you do not change their settings.
Autocal*calViewForm*month_form*marginHeight: 0
Autocal*calViewForm*month_form*marginWidth: 0
Autocal*calViewForm*month_form.marginWidth: 2
8 Print Command
The following resource specifies the print command, and its arguments,
which will be executed when you request that a calendar be printed. Be
sure to specify the full pathname of the executable, or it may not be
located and the print will fail.
Autocal.printCommand:
Note • When changing icon text, be sure the length of the new text
string does not exceed the recommended maximum length for icon
title text for your windowing system. Some window managers can
display long icon text strings, while others will truncate them. Ensure
the text string you specify for your icons displays appropriately. Also,
some window managers allow you to change the size of icons and
icon text font.
9 Real Machines
In the AutoSys environment, a real machine is any physical CPU that has:
The above two conditions are required for a real machine to run AutoSys
jobs. However, for AutoSys to perform intelligent load balancing and
queuing while executing jobs, it needs to know the relative processing
power of the various real machines. AutoSys provides both load
balancing and queuing by way of the logical construct called virtual
machines.
9 Virtual Machines
A virtual machine is comprised of one or more real machines, in whole
or in part (or a combination of both). All real machines within a virtual
machine must be of the same type, either NT or UNIX. Virtual machines
cannot be a mix of both UNIX and NT machines
The following JIL machine attributes are used when defining machines:
type
machine
Real machines only need to be defined to AutoSys if they meet one of the
following criteria:
Load balancing and queuing can be done only if real and virtual
machines have been defined to AutoSys using these machine attribute
statements. The following two attributes, used when defining real
machines, are key for load balancing and queuing: max_load and factor.
Note • Real and virtual machines can be defined only using JIL. There
is no GUI interface for defining machines.
In addition, for job queueing to take place, the priority job attribute
must also be assigned in the job definition. The priority attribute
specifies the relative priority of all jobs queued for a given machine.
Without this attribute set, a job will run immediately on a machine,
and it will not be placed in the queue.
9 Machine Definitions
AutoSys can infer whether a machine being defined is a real or a virtual
machine based solely on the attributes in the definition. Any machine
definition containing a max_load or factor attribute must be a real
machine definition, because only real machines can have these
attributes. Any machine definition containing a list of machine attributes
is a virtual machine definition.
Because of this, you can omit the type attribute when defining a UNIX
machine. For NT, however, the type attribute is required. Compare the
definitions below.
factor: .8
machine: monkey
Figure 9-1 defines a real UNIX machine named “jaguar” with a max_load
of 100 and a factor of 1.0.
insert_machine: jaguar
type: r
max_load: 100 100 max_load
factor: 1.0 1.0 factor
jaguar
Figure 9-1 • Real UNIX Machine with max_load 100 and factor 1.0
3 Specify the real machines that will make up the virtual machine.
ferrari lambo
Figure 9-2 • Virtual Machine with Two Real Machine Components
The following JIL statements define two real machines named “fiat” and
“lotus”, and a virtual machine named “capri”, which is composed of the
two real machines. The virtual machine is a superset of the two previously
defined real machines. (Because the real machines are defined first to
AutoSys, the virtual machine will use the max_load and factor attributes
specified for them.)
insert_machine: fiat
type: r
max_load: 100
factor: 1
insert_machine: lotus
type: r
max_load: 80
factor: .9
insert_machine: capri
type: v
machine: fiat
machine: lotus
insert_machine: mustang
type: v
machine: fiat fiat lotus
max_load: 10
machine: lotus 10 9
max_load: 9
To delete the entire virtual machine, you don’t have to specify any of the
component real machines. The real machines are still defined—only the
virtual machine they were in is deleted. The following JIL statement
deletes the virtual machine named “mustang”:
delete_machine: mustang
Because the real machines “fiat” and “lotus” had been individually
defined outside of the virtual machine, their individual definitions
remain in effect.
9 Load Balancing
By specifying a virtual machine or a list of real machines in a job’s
machine attribute, rather than a single real machine, you can implement
simple load balancing. That is, you can cause the work load to be spread
across multiple machines, based on each machine’s capabilities. In
addition to load balancing, this feature is useful way to ensure reliable
job processing. For example, if one of the machines is down, load
balancing will run the job on another machine.
Alternatively, you can specify a list of real machines in the job’s machine
attribute, as shown below:
machine: ferrari, lambo
If the max_load attribute was not defined for either real machine (as in
our example), or both machines had ample load units available, AutoSys
would choose the machine to run on based solely on available
processing power. To accomplish this, AutoSys does the following:
4 Chooses the machine with the largest result (i.e., the machine with the
most relative processing cycles available).
In the example machine list above, the factor attribute is not specified
for either machine, and thus the default factor value for each machine is
1.0.
italia
Note that even though the “ferrari” usage was less than “alfa_romeo”,
“ferrari” was picked because of the factors (78 * 1.0 > 80 * 0.8). Thus, the
factors weigh each machine to account for variations in processing
power.
Before using this feature, ensure the configuration has been completed as
described in Configuring ServerVision Monitoring and Reporting section of
Chapter 13, Configuring AutoSys. For information on ServerVision, see the
SeverVision documentation on the documentation CD.
where:
svload
list
The profile file for ServerVision load balancing might look like this
example svload.prf file:
[ServervisionConfiguration]
Timeout=12
InstanceType=unix
honda=honda
toyota=toyota
jeep=jeep
[CPU]
cpu_tl,idle,maximum,1
[Memory]
memory,used,minimum,1
[CPUMemory]
cpu_tl,idle,maximum,2
memory,used,minimum,1
where:
[ServervisionConfiguration]
Timeout
InstanceType=unix
honda=honda...
9 Queuing Jobs
Queuing jobs in AutoSys is a mechanism for ordering jobs that are
unable to be run immediately. You can also issue a “change priority”
event to change the priority of a job in the queue. There is no actual
“queue” entity. Instead, jobs are chosen based on queuing policies.
The following sections discuss queuing jobs and give examples of how
load balancing and queuing are used to optimize job processing in your
AutoSys environment.
The words “in the queue” refer to an actual AutoSys QUE_WAIT job
status, and the job will stay in this state until the necessary load units
become available.
When the necessary load units become available, AutoSys again checks
all the job’s starting conditions to ensure it is still okay to run the job. If
any of the starting conditions are no longer true, the following message
is generated:
Job: job_name Starting Conditions are no longer TRUE.
De-Queuing this Job and setting to ACTIVATED.
Note • In order for any queuing to take place, all jobs must have their
priority attribute set. By default, the priority attribute is set to 0
indicating that the job should not be queued, but be run immediately.
When this is the case, even jobs whose job load would push the
machine over its load limit will be run. However, it is important to
note that even when jobs have a priority of 0, job loads will still be
tracked on each machine. This is done so that jobs that do have
non-zero priorities will still be queued.
In the case where a job has its job_load attribute set, the load value will
be reflected in the total load running on a machine. It is important to
note that if there is no job_load value set for a job, it will not be figured
into the total load units running on a machine.
Note • The constructs of job loads and machine loads are merely
conventions that you set up, and that are enforced by AutoSys. If you
do not indicate for AutoSys what the load of a job is, it will not figure
it into its queuing calculations. This is different from the load
balancing feature, which does inspect the CPU to determine its usage.
Figure 9-5 illustrates a situation where a machine has 80 load units, and
multiple jobs are waiting to start. In this example, “JobB” and “JobC” are
executing while “JobA” and “JobD” are “queued” (in the QUE_WAIT
state), waiting for available load units. The numbers in the figure indicate
the job_load assigned to each job, and the max_load of the machine. The
JIL statements provided below define the machine and the jobs.
EXECUTE
80
JobA JobB
50 50 max_load
JobD JobC
30 30
insert_machine: ferrari
max_load: 80
insert_job: JobA
machine: ferrari
job_load: 50
priority: 60
insert_job: JobB
machine: ferrari
job_load: 50
priority: 50
insert_job: JobC
machine: ferrari
job_load: 30
priority: 80
insert_job: JobD
machine: ferrari
job_load: 30
priority: 70
In the above scenario, “JobB” and “JobC” are already running because
their starting conditions were satisfied first. After “JobB” or “JobC” are
completed, “JobA” or “JobD” will start. Which job will start, “JobA” or
“JobD”, is determined by a combination of the priority and job_load
attributes of each job, and the max_load machine attribute. The resulting
scenario will differ, based on which job finishes first.
9 Subsets—Individual Queues
One variety of virtual machine can be considered a subset of a real
machine. Typically, this type of virtual machine is used to construct an
individual queue on a given machine. One use for this construct might
be to limit the number of jobs, of a certain type, that will run on a
machine at any given time. For example, you have created three different
print jobs, but you want only one job to run on a machine at a time. You
can accomplish this by using a combination of the max_load attribute for
the virtual machine and the job_load attribute for the jobs themselves.
ferrari_printQ
ferrari
15 80
To implement the schema in Figure 9-6, you would first create the virtual
machine named “ferrari_printQ”, like this:
insert_machine: ferrari_printQ
machine: ferrari max_load: 15
Next, you would define the three print jobs, like this:
insert_job: Print1
machine: ferrari_printQ
job_load: 15
priority: 1
insert_job: Print2
machine: ferrari_printQ
job_load: 15
priority: 1
insert_job: Print3
machine: ferrari_printQ
job_load: 15
priority: 2
Using this definition, only one of the jobs would run on “ferrari” at one
time, since each job requires all of the load units available on the
specified machine.
ferrari lambo
15 80 15 120
To implement the above schema, you would first create the virtual
machine named “printQ”, then you would specify two real machines,
“ferrari” and “lambo” as shown in the following example:
insert_machine: printQ
type: v
machine: ferrari
max_load: 15
machine: lambo
max_load: 15
10 Introduction
The Operator Console provides a sophisticated method of monitoring
AutoSys jobs in real-time. The Operator Console lets you view any jobs
that are defined to AutoSys, whether they are currently active or not.
Job selection criteria, which you can dynamically change, allows you to
control which jobs you want to view based on various parameters, such
as 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 even invoke the Job
Definition dialog directly from this window and change the job, if the
correct permissions are set.
10 Alarm Manager
In addition to its job monitoring capabilities, the Operator Console
provides an Alarm Manager, which lets you monitor alarms as they are
generated. You can manage alarms by doing the following:
Alarms and their responses are stored in the AutoSys database, from
which they can be retrieved for viewing, or for adding additional
responses. You can dynamically select which alarms you want to view
based on such criteria as alarm type, alarm state, and the date and time
range in which the alarm was generated.
10 InfoReports
10
■ Job List. This report allows you to select the list of jobs to be reported
on or report on all jobs in the database. It shows almost everything
associated with a job.
■ Job Find. This report allows you to enter a pattern for the job name,
and report on all jobs that match the pattern. This is very similar to the
Job List report.
■ Last Run. This report allows you to enter the job name and get
information regarding the last run of the specified job.
■ Last n Run. This report allows you to enter the job name and get
information on the nth to last run of the job.
Once you have defined these buttons, click one to run the report. When
you do this, the InfoReports Database Login dialog appears. In this
dialog, you enter information in the following fields:
■ In the Source Type drop-down menu, specify which database you are
using, either Sybase or Oracle.
■ In the Password field, enter the password for the AutoSys database
user.
■ In the Connection field, enter the Sybase database name (for Sybase)
or the TNS name (for Oracle).
Click OK after you have entered all the required information. The next
dialog to appear will very depending on the type of report to be
displayed. You will be asked to supply information, such as a job name
or a job run number. After processing these dialogs, the requested
information is read from the database and is displayed in an InfoReports
report.
Where 50 is any integer greater than zero. It is the limit on the number
of panels to buffer. The default value is 3.
To start the Operator Console, use one of the following two methods
} At the UNIX prompt, enter the following command:
autocons &
Or
} At the GUI Control Panel, single-click on the Ops Console button.
The Job Activity Console appears.
The Job Activity Console has a menu bar and the following three regions:
10 Menu Bar
At the top of the Job Activity Console is the menu bar, containing three
menus: File, View, and Options.
View menu Contains the Select Jobs option, which displays the
Job Selection dialog, discussed in Job Selection Dialog
on page 10-24.
10 Job List
The Job List region displays a list of all the jobs that are defined to
AutoSys, subject to the job selection criteria currently in effect.
Each entry in the Job List contains the following information about a
single job:
■ Job name.
■ Description.
■ Current status.
The entries in the Job List provide a snapshot of the entire system, across
multiple machines.
When you select a job from the list, the highlighted job becomes the
currently selected job, and more detailed information about the job
appears in the Currently Selected Job region.
To select a job
} Single-click on the job in the Job List display.
When you select multiple jobs, you can perform actions on all those jobs
at the same time.
Note • The Job List region has a scroll bar along the right-side for
scrolling through the job list. Using the X resource file, you can
configure the relative sizes of the columns in the Job List, as well as
the length of each field and the spacing between fields.
Console Clock The console clock initially displays the current time
for the machine on which the Operator Console is
running. You can change this display by using the
Options menu (see Changing the Console Clock
Perspective on page 10-30) or by changing the setting
in the resource file (see Console Clock Perspective on
page 10-50).
Start Time The start time of the current or most recent run of the
job.
End Time The end time of the most recent run of the job. If the
job is currently running, this field will be blank.
Run Time How much time elapsed between the start and end
of the most recent run of the job. If the job is
currently running, this field will be blank.
Exit Code The exit code from the most recent run of the job.
Next Start If the job has date and time starting conditions, this
field shows when the next run of the job is
scheduled to start.
10 Starting Conditions
The Starting Conditions area displays the job’s entire starting condition,
as specified in its job definition, as well as the “atomic” conditions—the
most basic components of an overall condition. This information is very
useful when troubleshooting a job.
For example, in the sample Job Activity Console shown in Figure 10-1 on
page 10-8, the job named “DripCoffee” has a starting condition called:
■ SUCCESS(Grinder)
■ SUCCESS(BoilWater)
If a job has not run within the time frame it was expected to, you would
select the job from the Job List and check its starting conditions to
quickly determine what “upstream” job might be preventing it from
running.
10 Reports
The Reports area displays a real-time report, and it is also included in the
Currently Selected Job region is. This report presents job run information
in the same format as that produced by the autorep command. You can
choose from the following report types:
Summary and Event reports will be run automatically each time the
dialog is refreshed. The default refresh interval is every 5 seconds, but the
interval is user-configurable. If the Event report is chosen, you can watch
the real-time progression of a job, observing, as they occur, the arrival of
the various events, such as the job starting, running, completing, and
restarting.
10 Control Area
The bottom region of the Job Activity Console is the Control area.
Action Buttons
On the left side of this region is a group of push buttons that can be
pressed to initiate certain actions on the currently selected job or jobs. By
pressing the appropriate button, you can issue an event that will:
■ Start a job
■ Kill a job
In each of these cases, a dialog box asks you to confirm, after which the
action is taken immediately, without requiring you to perform any
further actions. If you have initiated an action on multiple jobs, the
dialog will display the following:
“Ready to send event event for # jobs”
where:
event
Is the action you chose.
#
When you click the Send Event button, the Send Event dialog displays,
and it allows you to send any type of event.
In the last column are buttons that are user configurable. You can
associate any command with these buttons, and specify your own button
labels. This process is explained in User-Configurable Action Buttons on
page 10-47.
■ Select the various event parameters you want to specify when sending
the event.
You specify an event using one of the radio buttons at the top of the
dialog. Just below these buttons is the Job Name field, which by default
contains the name of the currently selected job. You can change this field
if desired.
You can specify when the event is to take effect, either Now (the default),
or at some future time and date. (The current time and date are provided
as examples of the required format.) Use the A.M. and P.M. radio buttons
if you want to specify the time using a 12-hour format. If the time field
contains an hours setting that is less than 13, it is considered a.m., while
any larger value is considered p.m.
The Comment field is a free-form field in which you can enter any text
you want to associate with this event in the database; this field is for
documentation purposes only. For example, if you force a job to start,
you might provide an explanation about why this was necessary.
The Global Name and Global Value fields are used when you have
specified a SET_GLOBAL event. Global Name and Global Value can each
be a maximum of 30 characters.
The Signal field is used to specify the signal number if you specified a
SEND_SIGNAL event.
The Queue Priority field is used only when you have specified a
CHANGE_PRIORITY event. This affects the run priority of a job that is in
QUE_WAIT state.
You can only make a selection from the Status pull-down menu if the
Change Status event type (radio button) has been selected. This menu
lets you select a new status for the currently selected job.
Use the Send Priority radio buttons to specify whether the event is to be
sent with normal priority (the default), placing the event in the queue
with all system-generated events, or with high priority, placing it at the
top of the event queue. The latter is normally reserved for emergencies,
such as killing a job.
The Execute button of the dialog executes, or sends, the event. The Cancel
button cancels the event that was about to be sent. When either button is
pressed, the Send Event dialog is dismissed.
Note • You should use this feature to cancel events that you have sent
from the Send Event dialog. If you want to override a scheduled
starting condition for a job, you should use the one time override job
attribute, either from the Job Definition dialog or from JIL.
Note • You can select multiple jobs in the Job Activity Console
before you open the Send Event dialog. If you do so, the Send Event
dialog will send this cancel event for all of the selected jobs that
meet the Event Type criteria.
Note • You can select multiple jobs in the Job Activity Console
before you open the Send Event dialog. If you do so, the Send Event
dialog will send this cancel event for all of the selected jobs that
meet the Event Type and Time criteria.
2 In the Event Type region, specify an event type by selecting one of the
radio buttons.
5 In the Time field (of the Future region), specify the time the event is
scheduled to occur.
6 Single-click the Execute button. This cancels all pending events of the
specified Event Type at the specified Time for the selected job(s).
If you cancel a future Start Job event for a time-dependent job with no
other starting conditions, the job may never run again without manually
starting it with a Send Event command. For example, “jobA” is scheduled
to run daily at 11:00. “jobA” starts at 11:00 on Monday and completes at
11:30, at which time the next future Start Job event is sent for 11:00
Tuesday. At 9:00 on Tuesday, you cancel the 11:00 Start Job event. The
job not only does not run at 11:00 on Tuesday, but it will not be
scheduled to run again. To restart the job, you can either update its job
definition, or manually issue a Start Job Send Event.
Control Buttons
In the middle of the Control area, there are several push buttons that
provide you with control functions for the Console screen. The Job
Definition button displays the Job Definition dialog with the currently
selected job already displayed. This allows you to quickly review the job’s
definition, and change it if necessary (and if permissions allow).
The Dependent Jobs button displays the Dependent Jobs dialog that
contains a list of all the jobs directly dependent on the currently selected
job. This allows you to quickly see which jobs will be affected by the
current job; in particular, which jobs will not run until the current job
completes. This is useful if the currently selected job is running late and
you need to determine which other jobs will be affected.
Figure 10-3 shows the Dependent Jobs dialog for the job “BoilWater.” As
with the atomic conditions list, any job in this Dependent Jobs List can
be selected, making it the currently selected job (and dismissing the
dialog).
Figure 10-3 • Dependent Jobs Dialog Box for the Job “BoilWater”
The Freeze Frame button freezes the Console display, which otherwise is
regularly updated. By default it is updated every 5 seconds; this refresh
interval is user-configurable. In Freeze Frame mode, all processing
continues normally, but the screen is not refreshed. This feature is useful,
for instance, when you are viewing the Event Report’s output and the
display has scrolled through some of the output. A refresh operation
would reset the report display to the first line of output, forcing you to
scroll back to the area that you were viewing. When the Freeze Frame
button is toggled back off, the Console once again reflects the current
state of the system.
The three Report buttons let you choose the type of report you want to
view, as described earlier in this section. You can specify a default report
type using the X resources, see Default Report Type on page 10-46.
Figure 10-4 shows a Job Path (History) dialog box with these entries.
Using the this dialog, you can quickly return to any previously selected
job by single-clicking on the job’s name.
Alarm Button
The large Alarm button serves both as an indicator that a new alarm has
been detected and as way to display the Alarm Manager dialog. When a
new alarm occurs, the Alarm button changes to the color red. When this
happens, and you press the button, its color returns to green, and the
Alarm Manager dialog is displayed. If the Alarm Manager dialog is
already on the screen, but is obscured by the Job Activity Console,
pressing the Alarm button will bring the Alarm Manager dialog to the top
of the display. The Alarm button can also be used to update the Alarm
Manager dialog, even if Freeze Frame is in effect.
Exit Button
The Exit button is used to close the Job Activity Console, including the
Alarm Manager. When this button is pressed, a verification dialog
displays asking you to confirm the exit.
To adjust a boundary, you simply click and hold on a resizing handle and
drag it up or down. By doing so, your screen display can be adjusted to
reveal more jobs. For example, you can borrow display space from the
Currently Selected Job region, and even the Control area, to view more
jobs in the Job List. In fact, if the upper handle is pulled all the way down
to the bottom of the Console screen, the entire Job Activity Console can
be used to display the Job List. You can expose the buttons in the Control
area later by pulling the lower handle back up. (You can alter the Job
Activity Console display size using the resizing handles surrounding the
dialog as well.)
When specifying a job name in the Job Name field, you can enter either
the entire name or a partial name with the asterisk ( * ) wildcard
character representing one or more characters. You can use this wildcard
in more than one character position. For example, specifying the job
name “*a*” would match the jobs “Dad”, “Bead”, “Bat”, and so forth.
In a similar fashion, you can specify a box name in the “Box Name” field
to select all jobs in the specified box.
Note • If you use the wildcard character to specify all box names, and
a box has other boxes inside of it, the name of the nested box job will
be listed multiple times in the Job List.
The Box Levels field lets you indicate how many levels of nesting you
want to view for a box job. You can enter any valid positive number.
1 Indicates that the box specified in the Box Name field and
only the first level nesting of its direct descendents are to
be displayed.
All Indicates that the box specified in the Box Name field and
all of its direct descendents (including nested boxes and
the jobs in those boxes) are to be displayed. This is the
default.
When selecting jobs based on box name, each level of box/job will be
indented two spaces to indicate the nesting. This convention is shown in
the Job List in Figure 10-6.
Note • Virtual machines will appear in this list, but cannot be used to
select jobs because jobs can run only on real machines.
Selecting Machines
Start Time The starting time for the most recent execution of the
job.
End Time The ending time for the most recent execution of the
job.
Note • The Console Clock Perspective does not change the Start Time
and End Time displays in the Currently Selected Job region.
Server Time displays the time based on the time zone of the AutoSys
server machine. Current Job Time displays the time using the time zone
specified in the job definition (the timezone attribute); if no time zone is
set for the job, then the server machine time is used. Local Machine Time
displays the time in the time zone of the machine on which the Operator
Console is running.
The Alarm Manager dialog has a menu bar and the following three
regions:
10 Alarm List
The Alarm List region of the dialog displays a list of all the alarms that are
currently in the system, and that meet the viewing criteria specified by the
user, which may include closed alarms. The default is to display all Open
and Acknowledged alarms, of any type, regardless of the time they were
generated.
Each entry in the Alarm List contains the following information about a
single alarm:
■ Alarm type.
■ Any comment associated with the alarm at the time it was generated.
Note • You can configure the widths of the columns in the Alarm List
using the X resource file, described in the Alarm List Column Width on
page 10-46.
The Response edit box accepts multiple lines of text. The entered text is
automatically word-wrapped, with lines breaking at appropriate spaces.
You can use the mouse to edit text. In addition, you can use the arrow
and backspace keys as well as the <Tab> and <Enter> keys.
The User field, beneath the Response edit box, shows the user who
invoked the Alarm Manager. This read-only field shows which user
responded to the alarm field.
The Alarm State region lets you change the alarm state to Acknowledged
or Closed. Once an alarm is changed from the Open state, you cannot put
it back in the Open state.
10 Control
The third region of the Alarm Manager dialog is the Control region, at the
bottom of the dialog. In this region, there are several buttons used to
control the Alarm Manager. They are:
■ Freeze Frame
■ Select Job
■ New Alarm
When you press either the New Alarm button on this dialog, or the Alarm
button on the Job Activity Console, the Alarm List is updated and both
of these buttons are reset to green, even if the Freeze Frame feature is on.
Even when this dialog is refreshing regularly, the New Alarm button can
serve as an indicator that a new alarm has arrived.
When the alarm selection criteria is restrictive enough to filter out the
new alarm, a warning dialog displays when the New Alarm button is
pressed. This dialog offers to reset the selection criteria to the defaults;
this will ensure that any new alarms that are generated will be displayed.
Regardless of whether or not you accept this option, the New Alarm
button’s color will be reset to green.
The Alarm Selection dialog is divided into three regions, described in the
next sections:
■ Select by Type
■ Select by State
■ Select by Time
10 Select by Type
In the Select by Type region of the dialog, a list of all possible alarm types
is displayed. From this list, you can select one, several, or all types of
alarms. The default is All alarm types.
10 Select by State
You can also select alarms by the state of the alarm. You can select any or
all of the states by toggling on the appropriate buttons, or the All States
toggle. The default is to display all Open and Acknowledged alarms.
10 Select by Time
By default, alarms are shown regardless of the time they were generated.
You can choose to display only alarms that were generated during a
specific date and time window. Fields are provided to specify a From
Date, From Time, To Date, and To Time. You can specify dates without
times. However, you cannot specify times without dates.
The current system date and time are automatically filled in for your
convenience. You use a 24-hour format when specifying times.
Individual users may have their own copy of the X resources files in their
$HOME directory, which will take precedence over the app-defaults files.
For most operating systems, if you are exporting the display to another
machine you must edit the appropriate files in the app-defaults
directory on the local machine.
For Solaris, you must edit the files in both the /usr/lib/X11/
app-defaults and /usr/openwin/lib/app-defaults directories. The files
in /usr/lib/X11/app-defaults control the resources when you export the
display.
We have listed the various resource names here as a reference only. For
the default values, see the Autocons file. The provided resource file values
work well for a majority of platforms.
10 Changing Fonts
The fonts used in the Operator Console fall into the following three
categories:
In order for the labels at the top of the columns to align with the columns
themselves, those labels must also use fixed-format fonts, in the same
size and style. We recommend that a bold-faced font be used for the
labels, so that they are consistent with the other, non-list field labels
(unless, of course, you have chosen a non-bold font for everything).
The font chosen for the column data should be a non-bold version of the
same font used in the labels.
Note • The model X resources file provided specifies values that work
well for each of the SunOS and AIX platforms.
10 Object Color
The following resources affect the colors of the various objects within the
Operator Console. We recommend that the default colors be used, since
they match those used in the main AutoSys graphical user interface.
Border Colors
The following resources set the decorative dark blue borders of the
interface:
*workAreaForm.background:
*workAreaForm*XmPanedWindow.background:
*workAreaForm*controlForm*XmSeparator.background:
*reportType:
Note • When changing icon text, be sure the length of the new text
string does not exceed the recommended maximum length for icon
title text for your windowing system. Some window managers can
display long icon text strings, while others will truncate them. Ensure
the text string you specify for your icons displays appropriately. Also,
some window managers allow you to change the size of icons and
icon text font.
You must specify the full path to the command (environment variables
are not resolved). After the path to the command, environment variables
are allowed. $JOB will take the value of the currently active job. It is
recommended that you run the command in the background by placing
an ampersand (&) at the end of the command. Otherwise, the Operator
Console will pause until the command has completed.
!Autocons*userButton1Command:/autosys/inforeports/xproview -rep/
autosys/inforeports/reports/lastnrun.rep &
1 Remove the comment characters (!) from the beginning of the lines.
4 The default example assumes the reports (.rep files) are located in the
/autosys/inforeports/reports directory. If necessary, replace this
path with the actual path on your system.
The example command line is configured to display the Last n Run report
(lastnrun.rep). You can change this to display any of the following
reports:
lastrun.rep Creates a last run report on the job that you specify.
The report contains information on the last run of
the job.
lastnrun.rep Creates a last specified run (n) report on the job that
you specify. You can also enter the last, second to
last, or the a number for the last run.
./prfgen.sh
Server is the server machine time. Machine is the time zone of the
machine running the Operator Console. Job is the time zone specified in
the job definition (using the timezone attribute). If no time zone is set for
the job, then the server machine time is used.
Monitors and reports are simply applications that run against the
AutoSys database. Since all information is in the database, monitors and
reports that retrieve information from the database provide a complete
picture of the state of the entire system. Monitors and reports can run
with any AutoSys database, and Dual Event servers can be in use. Also,
monitors and reports can be run on any AutoSys client machine.
Monitors and reports enable you to filter and screen only the
information you are interested in from of a vast collection of data. That
is, they are tools that can give you information meaningful to you.
■ Type of event
11 Monitors
Monitors provide a real-time view of the AutoSys system. These are the
two steps necessary to use a monitor:
11 Reports
A report (or browser) is a query run against the database, based on the
selection criteria defined for that report. Its primary function is to enable
you to quickly get very specific information, such as the finish time of the
database backup for the last two weeks or all jobs that have an alarm
associated with them. In addition, all job levels in box jobs can be
reported if desired.
You can specify monitors and reports to AutoSys using either of the
following:
3 Set the various attributes and their values using the fields and buttons
in the Monitor/Browser dialog.
11 Using JIL
To define a monitor or report using JIL
} Issue the jil command, and pass it the insert_monbro sub-command
followed by a set of attribute: value pairs.
11 Chapter Organization
In this chapter, monitor and report attributes fit into two categories
(sections): essential and optional. Essential attributes must be specified
in order for a definition to be valid, and optional attributes are not
required.
For each attribute described in this chapter, the following is indicated (as
shown in the diagram below):
■ Its name
mode Mode
Attribute description...
Mode
mode Mode
As described in the next section, monitors and reports can track events by
filtering at several levels. Monitors and reports can also track events based
on selected jobs. The events to be tracked are determined by the
combination of the various event filters and the job filter, which are
specified by using any of the essential attributes.
All Events
all_events ALL EVENTS
Note • If you wish to monitor all the events for all jobs, you should
not run a monitor. Instead, you should display the Event Processor log
time in real time, using the following command:
autosyslog -e
Running a monitor adds another connection to the database, and
establishes another process that is continually polling the database.
This process will have a significant impact on system performance.
Moreover, the information logged by the Event Processor contains
much more diagnostic information than that monitor does.
Alarms
alarm Alarms
This attribute specifies whether all job status events should be tracked.
Job status events occur whenever a job’s status changes. If this attribute is
set to “yes,” the individual job status events shown below and a few
AutoSys-internal job status events, will be tracked.
success Success
failure Failure
terminated Terminated
starting Starting
restart ReStarting
Job Filter
job_filter Job Filter
This attribute specifies that only events in the current or most recent
execution of the specified job(s) will be reported. This feature is useful for
getting a sense of what is happening right now. For example, you could
select the job status event “restarting,” turn off job filtering, and set this
attribute to “yes” to see all the jobs that have been automatically restarted
by AutoSys in their current or latest run.
This attribute specifies that only events occurring after a certain date and
time for the specified job(s) will be reported. This attribute cannot be
used in a monitor definition because monitors only show events as they
occur.
Sound
sound Sound
This attribute specifies whether the sound facility should be used. If the
workstation running the monitor has sound capabilities, AutoSys will
use them to announce the events as they occur. The announced message
is pieced together from pre-recorded sound clips.
For details on recording sound and a list of machines for which AutoSys
supports sound, see the record_sounds command in Chapter 1, AutoSys
Commands, in the AutoSys Reference Guide for UNIX.
The buttons at the top of the dialog are the dialog’s control buttons. They
perform the following actions:
As indicated above, monitors and reports can be run from the Monitor/
Browser dialog. A monitor must be saved in the database before it can be
run, but reports do not need to be saved before they can be run. When a
monitor or report is run from the dialog, a new terminal window appears
to display the output. To close this window, press <Control+c>.
Defining a Monitor
First, you will define a monitor with the name “Regular.” This monitor
will monitor all alarms, plus job status events when a job changes state
to running, success, failure, or terminated for the current job run.
Your entries in the Monitor/Browser dialog should look like those shown
in Figure 11-2.
Note • If you want to run the monitor immediately, you must save it
first, then click on the Run MonBro button. When running a monitor
or a report from the GUI, an xterm window is created to display the
monitor or report output.
Defining a Report
Next, you will define a report with the name “Alarm_Rep.” This report
will report all alarms on any job, from December 22, 1997, at 12:00 to
the present.
where:
monbro_name
■ update_monbro
■ delete_monbro
The following JIL script creates a monitor that will sound an alarm
whenever a job finishes successfully:
insert_monbro: Job_Success
mode: monitor /* "m" may be specified instead */
sound: yes
success: yes
job_filter: all
Note • The JIL examples in the following sections include the monitor
and report definitions presented in the GUI section above.
For a list of machines for which AutoSys supports sound, see the
record_sounds command in Chapter 1, AutoSys Commands, in the AutoSys
Reference Guide for UNIX.
Defining Monitors
First, you will define a monitor with the name “Regular.” This monitor
will monitor all alarms, plus job status events when a job changes state
to running, success, failure, and terminated. It sounds an audible alarm
whenever any of the events occur (for a list of machines for which
AutoSys supports sound, see the record_sounds command in Chapter 1,
AutoSys Commands, in the AutoSys Reference Guide for UNIX).
Defining a Report
Next, you will define a report with the name “Alarm_Rep.” This report
will report all alarms on any job, from June 1, 1997, at 2:00 a.m., to the
present.
insert_monbro: Alarm_Rep
mode: b
alarm: y
after_time: "06/01/1997 2:00"
Notice that quotes are required in the previous example, because the time
contains a special character, the colon.
Note • Reports can only display events that are still in the database.
Archived events are inaccessible and cannot be displayed.
11 Running a Monitor
To run a monitor
} Enter the name in the Name field of the Monitor/Browser dialog, and
single-click the Run MonBro button.
Or
} Run the monitor by executing the following AutoSys command at the
UNIX command line:
monbro -N monitor_name
■ The time interval after which the Monitor/Browser GUI will drop the
connection to the database.
■ The Monitor/Browse GUI icon text and the Monitor/Browse title bar
text.
Individual users may have their own copy of the X resources files in their
$HOME directory, which will take precedence over the app-defaults files.
For most operating systems, if you are exporting the display to another
machine you must edit the appropriate files in the app-defaults
directory on the local machine.
For Solaris, you must edit the files in both the /usr/lib/X11/
app-defaults and /usr/openwin/lib/app-defaults directories. The files
in /usr/lib/X11/app-defaults control the resources when you export the
display.
Note • When changing icon text, be sure the length of the new text
string does not exceed the recommended maximum length for icon
title text for your windowing system. Some window managers can
display long icon text strings, while others will truncate them. Ensure
the text string you specify for your icons displays appropriately. Also,
some window managers allow you to change the size of icons and
icon text font.
You can start the Shadow Event Processor at the same time as the Primary
Event Processor by specifying the -M option followed by the name of the
machine on which you want the Shadow Event Processor to run, like this:
eventor -M machine_name
eventor Command
The eventor command performs these tasks:
■ Invokes a restart procedure that looks for any events that are hung in
the “processing” state. Because events are processed one at a time,
there can only be one event hung in the processing state at a time. If
there is an event in this state, it is requeued for processing. Normally,
events will only be in this state if the Event Processor was stopped
while it was processing an event.
Note • If the event being processed was a STARTJOB event, and the
job it started is still alive, it will not be started again. Also, if an
event is in the “processing” state for a long time, this does not
imply that the job associated with that event is in some unusual
state. It could be that the command is lengthy, or is waiting for
machine resources.
The purpose of the chase feature is to verify the state of AutoSys and
detect any problems upon startup.
Note • If you do not want eventor to run the tail command, you
can use the -q option when you start the Event Processor. Several
command line options allow you to start the Event Processor
without some of the checks being performed; however, these
options should be used by an experienced AutoSys administrator
for special circumstances only.
For more information about the eventor command, see its entry in
Chapter 1, AutoSys Commands of the AutoSys Reference Guide for UNIX.
When the Event Processor is in Global Auto Hold mode, it evaluates all
jobs whose starting conditions have passed and are eligible to run.
Instead of starting the jobs, however, the Event Processor puts the jobs
ON_HOLD. It does this for all types of jobs (box, command, and file
watcher). This allows you to decide which jobs should run and to start
them selectively with the Force Start Job button in the Operator Console,
or with the following command:
sendevent -E FORCE_STARTJOB
This FORCE_STARTJOB event is the only way to start a job put
ON_HOLD with Global Auto Hold; it overrides the Global Auto Hold.
To turn off Global Auto Hold, you must shut down the Event Processor,
and then start it again without the -G option.
You can start both the Primary and Shadow Event Processors with the -G
option.
If the $AUTOUSER directory is NFS mounted, you can view this output from
any machine on the network.
The Event Processor log has a file system threshold setting. The Event
Processor shuts down if there is less than 8 kilobytes of disk space
available. However, if the amount of available disk space falls below that
specified by the FileSystemThreshold parameter in the configuration file,
the Event Processor issues warnings in the Event Processor log file.
Note • Stopping the Event Processor does not affect jobs that are
already running. They continue to run to completion, at which time
the exit events are sent directly to the AutoSys database. The effect of
stopping the Event Processor is that actions triggered by incoming
events sent from the Remote Agents are not initiated until you start
the Event Processor again.
sendevent -E STOP_DEMON
This method allows the Event Processor to complete gracefully any
processing it is performing. You can assign a high priority to the
sendevent -E STOP_DEMON command by including the -P 1 argument.
If the Shadow Event Processor does not receive the signal, it does the
following:
Similarly, if the Primary Event Processor cannot locate and signal the
Shadow Event Processor, the Primary processor checks the Third
Machine for the .dibs file, and follows the same procedure as the
Shadow Event Processor (as described above).
If the Primary Event Processor and an Event Server are on the same
machine, the Event Processor failure could also mean an Event Server
failure. In this situation, if Dual Event Servers are configured, AutoSys
will roll over to the Shadow Event Processor and to Single Server mode.
AutoSys uses the Third Machine and the existence of the .dibs file to
resolve contentions and to eliminate the case where one processor takes
over because its own network is down. However, the Shadow Event
Processor is not guaranteed to take over in 100% of the cases. For
example, in the case of network problems, AutoSys might not be able to
determine which Event Processor is the “healthy” one, and it will shut
down both processors.
Note • You can specify the Shadow Event Processor and the Third
Machine by modifying the tunable parameters in the AutoSys
configuration file. For information, see Chapter 13, Configuring AutoSys.
■ If the Event Processor and the Remote Agents are installed and
configured properly. Running in test mode uses the same mechanisms
of starting jobs and sending events that AutoSys uses in its normal
mode.
You can run the Event Processor at two levels of test mode. You do this
by setting the $AUTOTESTMODE environment variable before starting the
Event Processor. The levels of test mode are determined by the value of
the $AUTOTESTMODE variable. These are the values, which are discussed in
the following sections:
■ $AUTOTESTMODE = 1
■ $AUTOTESTMODE = 2
Note • The Event Processor cannot run partially in test mode; AutoSys
does not provide a test mode for the database. Therefore, you should
exercise extreme caution when you run in test mode on a live
production system.
$AUTOTESTMODE = 1
At the first level of test mode, each job that you specify runs with the
following test mode variations:
■ Standard output and standard errors for the command are redirected
to the /tmp/autotest.$AUTO_JOB_NAME file, where $AUTO_JOB_NAME is
the job name as defined to AutoSys.
■ If the job being run in test mode is a file watcher job, it is not disabled;
it runs as it would in real mode.
$AUTOTESTMODE = 2
The second level of test mode runs with the same behaviors as the first
level with the addition of the following procedures:
chase
The chase command verifies that the expected jobs are running. It goes
to every machine that should be running a job and verifies that the
following are true:
Errors detected by chase are sent to standard output. The options used
with chase further determine what actions are taken when error
conditions are detected. chase can send alarms to AutoSys to alert you to
the problems it finds (by using the -A option). In addition, it can
automatically restart jobs that are “missing in action” and that are
defined to be restartable (by using the -E option). For more information
about the chase command, see Chapter 1, AutoSys Commands, in the
AutoSys Reference Guide for UNIX.
clean_files
The clean_files command deletes old Remote Agent log files. It
performs this task by searching the database for all machines that have
had jobs started on them, and 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). To remove only the log files older than a
specific number of days, use the following command:
clean_files -d days
Where days specifies that files older than this number of days should be
deleted.
■ calendar definitions
■ job definitions
■ machine definitions
■ global variables
We also recommend that you keep a copy of your AutoSys license keys in
case you need to reinstall them.
d Click OK.
4 To append your monitor and browser definitions to the same file that
contains your job and machine definitions, from the UNIX command
prompt, execute the following command:
monbro -N ALL -q >> /directory/autosys.jil
Where directory is the same directory where you saved your job
definitions, a directory outside of the AutoSys directory structure.
5 To save your global variables to their own file, from the UNIX
command prompt, execute the following command:
autorep -G ALL > /directory/globals.jil
Where directory is a directory outside of the AutoSys directory
structure. We recommend that you save to the same directory where
you saved your other AutoSys definitions.
Note • You can create a job that runs periodically to back up your
definitions automatically.
6 To save your license keys, run the gatekeeper command to print your
current license keys to a file.
c In the Import File Name dialog, select the directory and filename
of the text file that contains your calendar definitions.
d Click OK.
Due to the critical nature of the information stored in the database, you
can configure AutoSys to run with Dual Event Servers (two databases).
Dual databases provide redundancy in the event of an Event Server crash.
■ Job definitions
■ Events
■ Calendar information
■ Machine definitions
For a list of the database tables and views as well as the event and alarm
codes used in the database, see Chapter 6, Database Tables and Codes, in
the AutoSys Reference Guide for UNIX.
For information about installing a second Event Server, see the Installing
Dual Event Servers section of Chapter 9, Advanced Configurations, in the
AutoSys Installation and Getting Guide for UNIX.
■ How often the database is cleaned. (Every time a job runs, it generates
at least three events and an entry in the job_runs table.)
12 Database Architecture
Figure 12-1 shows the layout of databases in an AutoSys environment,
and it will help you understand AutoSys configuration options. It depicts
how AutoSys determines which database to use, and how the three
primary AutoSys components (the Event Processor, the AutoSys
database, and the Remote Agent) interact.
OS FILE:
config.$AUTOSERV
Event
Event Processor
Server 2
Instructs Remote Machine:
Command to execute and
database(s) to send events to.
Remote
Agent
database(s) Processes
Figure 12-1 • Layout of databases and primary component interaction
Figure 12-1 shows one instance of AutoSys that is configured with Dual
Event Servers, which are used only by this one instance. Both the Event
Processor and the Remote Agent ensure that events are written to the
appropriate database(s).
12 DBMaint Script
By default, AutoSys executes the $AUTOSYS/bin/DBMaint script during its
daily maintenance cycle. This script runs the dbstatistics and
archive_events commands.
■ Run the AutoSys dbspace command to check the available space in the
database. If the amount of free space is insufficient, it issues warning
messages and generates a DB_PROBLEM alarm.
■ Calculate and update the average job run statistics in the avg_job_run
table. This information is used by AutoSys/Xpert. When dbstatistics
is run, old data is overwritten with the new data.
■ Events and any alarms associated with them from the event table
When you modify the script, copy it first, and then add your
enhancements to the copied version. If you modify the script, you should
keep a backup copy of it; then, when you upgrade, you will not lose your
changes. You can use your enhanced script to modify the newly installed
script.
Upon Event Server rollover, the Event Processor edits the $AUTOUSER/
config.$AUTOSERV configuration file on only the Event Processor
machine(s). The Event Processor comments out the database that has
been taken off-line and marks the remaining database as being in Single
Server mode. The Event Processor makes these changes so that AutoSys
utilities attempting to access the database will write to or read from only
the running Event Server.
Note • Before doing this, you must have already installed and
configured your AutoSys system for Dual Event Servers, as described
in the Installing Dual Event Servers section in Chapter 9, Advanced
Configurations of the AutoSys Installation Guide for UNIX.
2 Make sure that no one is executing jil or using the AutoSys GUI
dialogs to change job definitions.
sendevent -E STOP_DEMON
After the Event Processor is stopped, no additional jobs will be started.
6 Start the Event Processor, using the eventor command on the AutoSys
Event Processor machine, like this:
eventor
Or, if you are running a Shadow Event Processor, start the Event
Processors like this:
eventor -M shadow_machine
The Event Processor should print a message indicating that it is in
Dual Server mode.
■ For unbundled Sybase only, put your data on a raw partition. This
improves access time.
WARNING • Only the database administrator should put your data
on a raw partition.
■ Tune the shared pool size. Make changes to the shared pool size by
altering the init.ora value of SHARED_POOL_SIZE.
To determine if you need to increase the shared pool size, enter the
following query in SQL*Plus:
select sum(pins) “Executions”,
sum(reloads) “Cache Misses while Executing”,
((sum(reloads)/sum(pins))*100) “Ratio of Misses”
from v$librarycache;
The Ratio of Misses should be less than 1%. (The Ratio of Misses
number is displayed as a percentage.) If it is higher than 1%, you
should increase the value of SHARED_POOL_SIZE incrementally
until the value of Executions approaches zero.
■ Tune the buffer cache. Make changes to the buffer cache by altering
the init.ora value of DB_BLOCK_BUFFERS.
The closer the hit ratio approaches 1.00, the better your system
performs. If you have free memory and the hit ratio is below .95,
increase the value of DB_BLOCK_BUFFERS. Make sure you have at
least 5% free memory.
■ Maximize disk I/O by separating the data files. If you have disk
contention, place the autodata and autoindexes data files on separate
disk drives, and if possible, different drive controllers.
■ Tune the sort area. A sort area in memory sorts records before they are
written to disk. Increasing the size of the sort area by increasing the
init.ora value of SORT_AREA_SIZE improves sort efficiency.
If disk sorts are greater than 1% of memory sorts, then increase the
value of SORT_AREA_SIZE.
12 Sybase Architecture
The Sybase database is based on a client/server architecture, with the
communications between clients and server built into the product. The
server portion is called the Sybase SQL Server. This server is a multi-
threaded, single process that runs on one machine. It listens on a specific
port for a request from a client, fulfills that request, and then returns the
information to the client.
The client communicates with the server using a C library known as Open
Client, or the DB Library. This library handles the communications
between the client application and the Sybase SQL Server as well as
sending requests and parsing results for the use of the application.
This means that all AutoSys commands and processes, including the
Event Processor, the Remote Agent, and monitors, are DB Library
applications that connect to the AutoSys database(s).
Because all AutoSys commands are merely Sybase clients, you can
execute those commands from any machine that has access to the Event
Server and is a licensed AutoSys client.
12 Sybase Environment
If you are using a Sybase, the following environment variables are used:
For more information on using xql, see its entry in Chapter 1, AutoSys
Commands of the AutoSys Reference Guide for UNIX.
Database Users
When using the bundled Sybase version of AutoSys, there are two users
defined by default in the AutoSys database: the system administrator and
the AutoSys user. Each of these users has a default user name and
password.
For information on changing the “sa” password, see the next section,
Changing the System Administrator Password. For information on changing
the “autosys” password, see autosys_secure in Chapter 1, AutoSys
Commands, of the AutoSys Reference Guide for UNIX.
Note • If you are not using the default settings, the name of your
dataserver is substituted for AUTOSYSDB.
WARNING • After you change the “sa” password, the old password is
unrecoverable. Make sure that the new password is recorded; otherwise,
the entire database will have to be re-installed.
12 Starting Sybase
Starting Sybase involves executing the command that will bring up the
AutoSys database on the machine where AutoSys has been installed. The
following example is for Sybase-bundled versions of AutoSys. If there is
a pre-existing dataserver at your site, consult your local database
administrator about how to start the database.
start_autodb
Or
$SYBASE/install/RUN_AUTOSYSDB
Both of these commands start the server in the background, then
output start-up messages.
4 To verify that the database is up and accessible, enter the following xql
command:
xql -Uautosys -Pautosys -c "select getdate()"
If this command returns the date, then the database is up.
12 Stopping Sybase
You must shut down Sybase before shutting down or rebooting the
machine. Before you shut down Sybase, however, you should shut down
the Event Processor.
To stop Sybase
1 If the Event Processor is running, stop it. To do this, log on as the Exec
Superuser and enter the following command:
sendevent -E STOP_DEMON
Note • If you are not sure whether the Event Processor is running,
do not sent the STOP_DEMON event. If the Event Processor is not
running and you send the event, it will be queued and sent when
the Event Processor is started again. Before you attempt to stop the
Event Processor, ensure that it is running by using the chk_auto_up
command.
12 Accessing Sybase
AutoSys comes with a utility named xql, which resides in the $AUTOSYS/
bin directory. Use this utility for interactive database queries and for
shell-level database access. For a detailed description of how to use xql,
see its entry in Chapter 1, AutoSys Commands, of the AutoSys Reference
Guide for UNIX.
■ $AUTOSYS/bin/chk_auto_up
Note • The xql utility functions only with the Sybase database. If you
use an Oracle database, use sqlplus instead.
■ Before you change the “autosys” user password or shut down AutoSys,
you should ensure that no processes are connected to the database.
You can identify the active processes, then shut them down.
■ Many GUI processes connected to the database can slow it down. You
can see how many and what type of processes are connected to the
database, and then ask users to shut down the GUIs they are not
currently using.
To see what processes are connected to the database and their status
} At the xql prompt, enter the following:
xql>>[AUTOSYSDB][master] 1> select program_name, hostname,
xql>>[AUTOSYSDB][master] 2> hostprocess,
xql>>[AUTOSYSDB][master] 3> status from sysprocesses;
The list of processes connected to the database is displayed, like this:
program_name hostname hostprocess status
--------------- ---------- ----------- ------------
xql Joe 14050 running
sleeping
sleeping
sleeping
sleeping
sleeping
event_demon Michelle 13448 recv sleep
jil Erik 12272 recv sleep
In the example list of processes, xql is the process running your query to
display the processes, and event_demon is the Event Processor. The
processes without names are internal Sybase processes, which you can
ignore.
The following are the most common processes you will see (there are
others):
auto_remote jobscape
This section describes how to create a backup server and dump the
AutoSys database to a file, which you can then back up to tape.
If you have not yet defined a dump device to Sybase, you must define a
disk or tape dump device, as described in Defining a Disk Dump Device on
page 12-36. Then follow the steps in Dumping the Database on
page 12-40.
For example, the following command will define a disk dump device
named “autodump,” and the database will be dumped to a file named
/backup/autodumpdata (for this example to work, the backup directory
must already exist).
xql>sp_addumpdevice "disk", autodump, "/backup/autodumpdata", 2;
For example, the following command will define a tape dump device
named “autodumptape,” and the database will be dumped to a tape with
a 40MB capacity loaded in the device named /dev/rmt8.
xql>sp_addumpdevice "tape", autodumptape, "/dev/rmt8", 3, skip, 40;
Note • If you are running on Dynix, NCR, Pyramid, SCO UNIX, SCO
UnixWare, or Solaris, skip this section and refer to Creating a Backup
Server Using autotli below.
When you are finished, you will have two entries in your interfaces file:
one for AUTOSYSDB and another for SYB_BACKUP. Your SYB_BACKUP entry
should look similar to the following:
SYB_BACKUP
query tcp sun-ether fiji 5335
master tcp sun-ether fiji 5335
console tcp sun-ether fiji 5336
The above example creates a backup server on a host named “fiji,” using
port number 5335. The backup server port can be the same as the port
used by the dataserver.
Note • The format of the interfaces file requires that a single tab (do
not use spaces) precede the first word of every line that follows the
SYB_BACKUP line (which should not have any spaces before it). A single
space is used to delimit each element in an entry line. Incorrect
formatting will prevent communication with the database.
The above command will create the following entry in the $SYBASE/
interfaces file:
xql>checkpoint;
5 To load the database backup, enter the following:
Is the name for the Sybase dump device that you already defined to
Sybase.
For example, the following will load a disk dump named “autodump”
of the database named “autosys”:
xql>load database autosys from autodump;
6 After the load has succeeded, enter the following to unset the single
user options that you set before executing the load:
xql>sp_dboption autosys, "no chkpt on recovery", FALSE;
xql>sp_dboption autosys, "dbo use only", FALSE;
xql>sp_dboption autosys, "read only", FALSE;
7 To bring the database online, enter the following:
Note • For Sybase System 11, you must put the database online.
Previous versions of Sybase did not require this.
To exit xql
} Enter the following at the xql prompt:
xql>>[AUTOSYSDB][master] 1> exit
Restarting the Event Processor
Then, you can restart the Event Processor. When you complete this
process, AutoSys will be in the state it was in when you dumped the
database to the backup file.
#EventServer=SYBSERVER2:autosys
# Oracle database example
#EventServer=ORASERVER2
# # # # # # Tunable Parameters # # # # # #
#
# # # # Database Connection Parameters # # #
#
# Database Connection Time Out (in seconds)
DBLibWaitTime=90
#
# Event Processor ERRORS
# If there are more than 20 errors in 60 seconds it
# will exit. The MAX value of EDNumErrors is 100.
EDNumErrors=20
EDErrTimeInt=60
#
# Machines for chk_auto_up to inspect to see if an
# Event Processor is running there.
#EDMachines=host1,host2,host3
EDMachines=localhost
#
# For Shadow Event Processor, the Third Machine to
# resolve contention problems between Event
# Processors
#ThirdMachine=a_hostname
#
# Minimum kbytes of space that must be available for
# the EP log file (on the partition or disk). If free
# space falls below this, the EP will issue warnings
# and shut down.
#
FileSystemThreshold=32
# Event Processor’s internal Daily Database
# Maintenance Cycle # #
#
# Daily start-time
DBMaintTime=03:30
# Command to Run to perform Maintenance
#
DBMaintCmd=$AUTOSYS/bin/DBMaint
#
# For Dual Server Mode - transfer events timeout
EvtTransferWaitTime=5
#
# Check Heartbeat every 2 minutes
#Check_Heartbeat=2
#
# Output Directory for the Remote Agent
#
# Note: Some OS’s have problems with file locks in /tmp
# If so use some directory other than /tmp.
#
AutoRemoteDir=/tmp
#
# Clean Remote Agent files: 1=Remove files if No
# Problems!
CleanTmpFiles=1
#
# Create Remote Agent Output File for Sourcing the
# Environment
# In UNIX: capture std_out & std_err from sourcing
# /etc/auto.profile
# In NT: output the Environment to the file
#
RemoteProFiles=1
#
# Host machines to send SNMP traps to. (Specifying
# a machine ENABLES traps)
#SnmpManagerHosts=host1,host2
#
# Snmp community. This is almost always "public"
#SnmpCommunity=public
# Enable sending HP Operations Center messages (opcmsg)
# for AutoSys alarms.
# This defines the message group under which
# messages will be sent.
#OpcMessageGroup=Job
#
# This parameter sets the amount of time that the
# event_demon will wait for the OpCenter message
# to be sent.
#
#OpcWaitTime=4
#
# RESTART configuration stuff
#
# Max number of times to RESTART a job due to system
# errors
MaxRestartTrys=10
#
# Formula for computing the Wait time between
# restart attempts:
# WaitTime = RestartConstant+(Num_of_Trys *
# RestartFactor)
The Event Processor reads the settings in the configuration file on startup
only. Therefore, if you make changes to the file, you must stop and restart
the Event Processor so it can read the new settings.
sendevent -E STOP_DEMON
2 Restart the Event Processor, like this:
eventor
Or, if you are running AutoSys with a Shadow Event Processor, you
can start both the Primary and the Shadow Event Processors at the
same time, like this:
eventor -M shadow_machine
The following line in the configuration file sets the timer for 90 seconds:
DBLibWaitTime=90
XInstanceDBDropTime
The XInstanceDBDropTime parameter specifies how an AutoSys instance
will connect with another AutoSys instance if it has a job defined with a
cross-instance job dependency.
If the value of this parameter is equal to zero, the Event Processor will
connect to the other instance before every new event is sent. After the
event has been sent, the connection will be dropped. Use this option for
instances that are using cross-instance job dependencies infrequently.
If the value of this parameter is equal to one, the Event Processor will
connect to the other instance before the first event is sent, and it will
maintain the connection indefinitely. Use this option for instances that
are using cross-instance job dependencies often.
13 Database Connections
AutoSys can be configured to attempt connect, and reconnect, to
databases a specified number of times. This behavior occurs when the
first attempt to connect to the database is made, and when a database
connection has been lost and there is a reconnect attempt made. This
database connection behavior also sets the rollover criteria for Dual
Server Mode.
DBEventReconnect
The DBEventReconnect parameter controls the number of times an Event
Processor should attempt to connect (or reconnect) to an Event Server
before shutting down, or before rolling over to Single Server Mode. This
parameter is used on start-up and when there is a connection problem
during runtime.
In Single Server Mode, this parameter is set to a simple number, like this:
DBEventReconnect=50
This setting specifies that the Event Processor should attempt a
connection with the Event Server 50 times. If it cannot connect after 50
attempts, it shuts down.
In Dual Server Mode, this parameter contains two values describing the
connection and rollover behaviors, like this:
DBEventReconnect=50,5
This setting specifies that the Event Processor should attempt 5
connections with the Event Servers. If after 5 times it cannot connect, it
should rollover to Single Server Mode, marking the other Event Server as
“down.” Once in Single Server Mode, the Event Processor should attempt
a connection 50 times, and if it is unsuccessful, the Event Processor shuts
down.
The primary reason for setting these two parameters to shut the Event
Processor down in this situation is to avoid starting any new processes
while there are serious problems in the system.
EDNumErrors, EDErrTimeInt
The EDNumErrors parameter specifies the maximum number of errors that
can happen within the time specified by the EDErrTimeInt parameter, in
order to determine if AutoSys should shut down the Event Processor. If
the specified Number of Errors occurs within the Error Time Interval,
AutoSys shuts down the Event Processor as a safety measure.
EDMachines
The EDMachines parameter specifies a list of valid AutoSys server
machines on the network. AutoSys checks all of the machines on this list
for running Event Processors, both when chk_auto_up is run and when a
new Event Processor is started.
The list should contain all of the machines that could have a started and
running Event Processor on them, so that a new Event Processor cannot
be started on a different machine. Having a complete list of EDMachines
is especially critical when a Shadow Event Processor takeover has
occurred, and your Primary server is configured to automatically restart
the Event Processor.
ThirdMachine
When running with a Shadow Event Processor, AutoSys uses a “Third
Machine” to resolve possible contentions between the two Event
Processors, and to ensure that only one of the processors is running at
any given time.
If the Shadow Event Processor does not receive a “ping” from the Primary
Event Processor, or if the Primary Event Processor cannot signal the
Shadow Event Processor, the processor(s) connect to this Third Machine
and create a .dibs file that locks the other processor out. The .dibs file
indicates that the one Event Processor has taken over and the other
should shut down.
Note • The Third Machine must have a Remote Agent installed on it,
and it must have a valid client license. In addition, the Third Machine
must be installed on the same type of machine as the Primary and
Shadow Event Processors, either Windows NT or UNIX.
If the amount of disk space falls below 8 kilobytes, the Event Processor
will issue an EP_SHUTDOWN alarm and shut down, issuing messages
similar to the following:
ERROR: No disk space left to write Event Processor log
EVENT: STOP_DEMON
The Event STOP_DEMON has just been received. We are going down!
In the configuration file, you can specify the time of day for this
maintenance cycle, and you can specify a maintenance command. The
time you specify should be during a time of minimal activity.
■ Calculates and updates the average job runs statistics for AutoSys/
Xpert.
■ Updates statistics for the optimizer, checks the available space in the
database, and sends a DB_PROBLEM alarm if the amount of free
space is insufficient.
■ Cleans out old information from the AutoSys database tables using
the archive_events command.
DBMaintTime, DBMaintCmd
The following entries in the configuration file instruct the Event
Processor to begin its maintenance cycle at 3:30 a.m. every day, and to
execute the $AUTOSYS/bin/DBMaint script at that time:
DBMaintTime=03:30
DBMaintCmd=$AUTOSYS/bin/DBMaint
13 Event Transfer
When in Dual Server Mode, the Event Processor will copy a missing event
from one Event Server to the other Event Server, after a time-out delay.
This time-out delay is specified by the EvtTransferWaitTime parameter in
the configuration file. The default setting of 5 does not usually need to be
modified.
EvtTransferWaitTime
To set the default behavior of 5 seconds for the time-out, the
configuration file contains the following line:
EvtTransferWaitTime=5
13 Sendevent Retries
The following two configuration file parameters control how many times
and how frequently the sendevent command will attempt to send an
event to the Event Server database.
SendeventMaxRetries
Specifies the maximum number of times that the sendevent command
will attempt to send an event to the Event Server database.
To set the number of retry attempts to 10, enter the following line in the
configuration file:
SendeventMaxRetries=10
SendeventRetryInterval
Specifies the interval, in seconds, between attempts to send an event to
the Event Server database. There is no default value.
To set the interval to 15 seconds, enter the following line in the
configuration file:
SendeventRetryInterval=5
13 Heartbeats
Heartbeats offer a method by which the continued progress of an
application can be automatically monitored. That is, you can program
your user applications to send “heartbeats” that can be monitored by
AutoSys. A heartbeat is a signal (SIGUSR2) sent from the application to
the Remote Agent that started the application. That Remote Agent then
sends a HEARTBEAT event to the AutoSys Event Server(s).
The Event Processor will check that the HEARTBEAT event has occurred
within the heartbeat interval specified for the job.
Note • The Event Processor, and not the Remote Agent, checks if there
is a HEARTBEAT between the Remote Agent and the Event Server(s),
and if the HEARTBEAT is absent, there is a problem, and an alarm is
sent. Therefore, the HEARTBEAT option also provides a good
indication of the stability of the network.
Check_Heartbeat
The Check_Heartbeat parameter specifies the interval value (in minutes)
that you want the Event Processor to use when checking for heartbeats. If
there are no applications sending heartbeats, you do not have to set this
parameter. By default, this parameter is commented out in the AutoSys
configuration file.
ShadowPingDelay
Specifies the interval, in seconds, after a succesful ping of the Shadow
Event Processor before another ping is attempted. The default is 60
seconds.
To set the interval to 30 seconds, enter the following line in the
configuration file:
ShadowPingDelay=30
AutoRemoteDir
The following entry in the configuration file specifies that the Remote
Agents should use the /tmp directory for enterprise-wide logging:
AutoRemoteDir=/tmp
13 File Maintenance
CleanTmpFiles
For every job that AutoSys runs, it creates a file in the Remote Agent Log
directory on the machine where the job runs. If CleanTmpFiles is turned
off, these files remain on each machine until they are removed with the
clean_files command.
Note • To view the Remote Agent output file, use the autosys_log
command on the client machine, like this:
autosys_log -J job_name
RemoteProFiles
When the RemoteProFiles parameter is turned on, it redirects to a file any
stderr and stdout output generated when the /etc/auto.profile file is
sourced. This parameter is “on” by default, and the entry in the
configuration file looks like this:
RemoteProFiles=1
The name of the file to which the profile output is written is based on the
log file name. This is the form of the auto_rem_pro* filename:
auto_rem_pro.joid.run_number.ntry
This output file will contain entries if anything specified in the profile file
failed (e.g., environment variables or definitions were not set). For
example, if the profile file attempts to set an environment variable using
setenv, the Bourne shell that AutoSys runs would not be able to process
this C Shell syntax, and the output file would contain the following line:
setenv: not found
Non-fatal errors when a profile file is sourced are not recorded and will
not appear in the output file.
To view the profile output file, use the autosys_log command on the
client machine, like this:
autosys_log -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 log file will
display this:
File: profile_output_file Does Not Exist.
MaxRestartTrys
AutoSys attempts to restart a job if it has problems starting the job due to
system problems, such as machine unavailability, the socket connect
timed out, the Remote Agent was unable to start another process, or the
file system space resource check failed. AutoSys attempts to restart a job
the number of times specified by the MaxRestartTrys parameter.
For example, to set the number of job restarts to 5, include the following
line in the configuration file:
MaxRestartTrys=5
RestartConstant
Is the maximum amount of time (in seconds) AutoSys will wait before
it attempts to restart a job.
For example, the entry in the configuration file might look like this:
RestartConstant=10
RestartFactor=5
MaxRestartWait=300
For example, to set the method to rstatd, enter this in the configuration
file:
MachineMethod=rstatd
If rstatd is chosen, you must ensure that this daemon is running on all
client machines.
■ Send a SIGHUP signal (kill -1) to reset the running inetd process.
13 KILLJOB Signals
KillSignals
The KillSignals parameter specifies a comma-separated list of signals to
send to a job whenever the KILLJOB event is sent. If the job is running on
a UNIX machine, the parameter specifies a single or comma-delimited
list of UNIX signals to be sent to the job. If a list of signals is specified,
the signals are sent in the order listed, with five second sleeps between
each call.
We recommend that you set this parameter to 15,9. In most cases, this
will lead AutoSys to return a TERMINATED state for a job that was killed.
If it does not, as might happen for some shells on some operating
systems, set the KillSignals parameter to 9.
AutoRemPort
The Event Processor communicates to the Remote Agent by way of a TCP/
IP socket connection, and the port number for this socket connection is
specified by the AutoRemPort parameter. The internet services daemon
(inetd) on the client machine uses the port number to point to the name
of the service (found in /etc/services). The service name is located in
the inetd configuration file (/etc/inetd.conf), where it finds the
pathname to the Remote Agent binary.
This is the entry in the configuration file, with the default setting of 5280:
AutoRemPort=5280
Note • If you are using NIS or NIS+, and wish to change AutoRemPort,
you must modify /etc/services on your NIS or NIS+ master and push
it to all client machines, and then do a kill -1 process on the inetd.
13 AutoSysAgentSupport Parameter
AutoSysAgentSupport
The AutoSysAgentSupport parameter specifies whether an AutoSys
instance can dispatch jobs on machines managed by AutoSys Connect or
AutoSys Agent.
If the value of this parameter is equal to zero, then the Event Processor
will not send jobs to AutoSys Connect and AutoSys Agent managed
machines. If the value of this parameter is equal to one, then the Event
Processor will send jobs to these machines.
By default, AutoSys Connect and AutoSys Agent job support is off, and
the entry in the configuration file looks like this:
AutoSysAgentSupport=0
For more information, see Appendix A, Integrating with the Mainframe and
AutoSys Agents for AS/400 and OpenVMS.
AutoInstWideAppendx
The AutoInstWideAppend parameter specifies whether an AutoSys
instance will overwrite or append information to the standard output
and standard error files.
If the value of this parameter is equal to zero, then the files will be
overwritten. If the value of this parameter is equal to one, then new
information will be appended to the files.
By default, new information is appended to the files, and the entry in the
configuration file looks like this:
AutoInstWideAppend=1
Each client machine can override the instance-wide setting by using the
AutoMachWideAppendvariable in the /etc/auto.profile file. If specified,
this variable would appear as shown in the following example:
#AUTOENV#AutoMachWideAppend=YES
Note • If you are running jobs across platforms, the Event Processor
of the issuing instance controls the default behavior. For Windows
NT, the default is to overwrite this file.
InetdSleepTime
The InetdSleepTime parameter controls how long the inetd waits
between job starts on the same Remote Agent machine. By default, this is
set to 2 seconds, and there is no parameter located in the configuration
file. To reduce the time the inetd waits between job starts on a machine,
you can add the InetdSleepTime parameter to the configuration file and
lower this number, which is specified in seconds.
To lower the default setting, add an entry like this to the configuration
file:
InetdSleepTime=1
The Remote Agent starts on the client machine as “root”. The Remote
Agent environment is controlled through special descriptors located in
the /etc/auto.profile file, located on the remote (client) machine.
The Remote Agent looks for the #AUTOENV# descriptors and reads the
variables that follow to set its environment. Do not remove the
#AUTOENV# descriptors from the file. They are required to enable the
Remote Agent to communicate with the AutoSys database.
Sybase
For Sybase, the descriptor looks like this:
################################################
# auto_remote environment variables
# DO NOT REMOVE
#AUTOENV#SYBASE=/usr/vendors/sadb
Note • A common symptom that results from the Remote Agent being
unable to write to the database is that jobs will remain in starting
state.
Oracle
For Oracle, the descriptors look like this:
################################################
# auto_remote environment variables
# DO NOT REMOVE
#AUTOENV#TNS_ADMIN=/etc
#AUTOENV#ORACLE_HOME=/var/opt/oracle
For example, assume you have one 3.3 Remote Agent using port number
3500. The entry in its AutoSys configuration file (e.g., config.PRD) would
look like this:
AutoRemPort=3500
On the same machine, you could have a 3.4 Remote Agent using port
number 4500. The entry in its AutoSys configuration file (e.g.,
config.DEV) would look like this:
AutoRemPort=4500
If you do this, you must also modify the /etc/services file like this:
auto_remote_333500/tcp # AutoSys Version 3.3
auto_remote_344500/tcp # AutoSys Version 3.4
Then, you would modify the internet daemon configuration file (/etc/
inetd.conf) like this:
If both are present, the Remote Agent will only run jobs submitted by
Event Processors listed in the autostuff file.
where:
The file
should contain an entry for each Event Processor you want
authorized to run jobs on the Remote Agent machine. The entries cannot
contain spaces within the Event Processor specification. You can use
pound signs (#) for comments.
In this example, PRD is an AutoSys instance name and the Event Processor
for this instance is running on the machine curly. DEV is an AutoSys
instance name and the Event Processor for this instance is running on the
machine moe. These Event Processors are authorized to issue jobs to the
Remote Agent.
13 Client-Side Security
The AUTOENV environment variable DENY_ACCESS restricts access to the
Remote Agent machine.
In the auto.profile file for the Remote Agent machine, you can specify
a list of users whose jobs are prohibited from running on that machine.
The list is a comma delimited list of user names, with no spaces. The
maximum number of characters is 512. For example:
########################################################
# auto_remote environment variables
# DO NOT REMOVE
#AUTOENV#DENY_ACCESS=root,daemon,admin
In this example, jobs owned by root, daemon, and admin will not be
launched by the Remote Agent.
Reporting
You can use the ServerVision GUIs to monitor the realtime resource
usage of an AutoSys job. This integration allows you to view AutoSys jobs
by their job name in the ServerVision GUIs. In addition, AutoSys can
archive a job’s resource usage to generate reports useful for capacity
planning and UNIX process auditing. This section describes the
configuration tasks necessary to enable this integration.
13 Library Path
A ServerVision library is shipped with this AutoSys release. It is installed
in $AUTOSYS/install/data. You must set your library path as appropriate
for your operating system to point to this library.
13 svload Requirements
To use the svload load balancing executable, the following is required:
2 The ServerVision instances file must contain entries for all machines
that you will use with the svload executable. For example, to use a
machine named “mack”, the instances file must contain the
following entry:
[mack]
type=unix
node=mack
3 The ServerVision uvroot environment variable must be set as required
by ServerVision.
#AUTOENV#AUTOSV=YesWithArchive
#AUTOENV#AUTOSV_DIR=/tmp
YES
AUTOSV_DIR must be set to tell AutoSys where to write the files for
ServerVision. This must be a full path name and it must be the same path
that you specify in your ServerVision instance configuration file.
13 ServerVision Configurations
To view AutoSys jobs in the ServerVision GUIs
1 The ServerVision product must already be installed as instructed in the
ServerVision documentation.
4 Ensure the app_group scan types are on. From the XUV GUI, select
Control } Configure } Scan.
■ CPU utilization
■ I/O reads
■ I/O writes
One file is created for each job run. These files are stored in the directory
specified by the AutoRemoteDir parameter in the AutoSys configuration
file. You must run the svarchive utility to process these files and place
the information in the svarchive database table. After the process is
complete, the svarchive utility deletes the files.
Note • You may want to create an AutoSys job to run the svarchive
utility automatically on a regular schedule.
You can configure AutoSys to call user-defined routines for the following
types of system alarms:
Notification Example
$AUTOUSER/notify.$AUTOSERV
2 Change the EP_SHUTDOWN line to this:
EP_SHUTDOWN /usr/local/bin/pager $@
Then, AutoSys will pass pager a numeric code and a text message. The
pager itself must be coded to accept these parameters.
14 Introduction
To troubleshoot AutoSys more effectively, it is essential that you
understand the stages in the life of a job, the order in which they occur,
and the roles played by the three major AutoSys components (i.e., Event
Server, Event Processor, and Remote Agent).
When a job is defined, its starting conditions are saved to the Event Server
(database), and the following occurs:
■ When its starting conditions are met, the Event Processor initiates a
Remote Agent on the client machine to execute the job.
■ The Remote Agent runs the job and sends the exit status of the job
back to the Event Server.
■ After the job completes, it is not run again until its starting conditions
are met.
For more information about job processing, see the Basic AutoSys
Functionality section in Chapter 1, Introduction to AutoSys. For information
about troubleshooting CCI, see Appendix B, Troubleshooting CCI in this
guide.
Symptoms
1 When trying to start xql, you get a message like this:
Resolution
This indicates that either the dataserver is down, or the process in
question is unable to access it. To confirm that the dataserver is down, log
onto the server machine and run the chk_auto_up utility. You can also
look at the process table (using the UNIX ps command) for the process
name “dataserver”.
If the database is indeed down, you must restart it. For directions on how
to do this, see Starting Sybase in Chapter 12, Maintaining AutoSys.
If the database is running, the problem could be that you are pointing to
the wrong dataserver. The DSQUERY environment variable points to the
name of the dataserver (typically AUTOSYSDB). If it is not set properly and
you are not specifying a dataserver name to xql (using the -S server
option), then xql will fail.
Where:
E
Means that this is an Event Server.
AUTOSYSDB
Is the name of the database (for Sybase and Microsoft SQL Server).
If the database service is up, and the environment variable is set properly,
then the Sybase interfaces file might not have the proper form, or be in
the proper location. This typically occurs on servers if the environment
has been changed, or, on clients, if the interfaces file has not been
correctly installed.
For more information about the Sybase interfaces file and connecting
to databases, see Chapter 1, Introduction to AutoSys, in the AutoSys
Installation and Getting Started Guide for UNIX.
14 Sybase Deadlock
Symptom
A message similar to the following appears in the Event Processor log
when viewed with the autosyslog -e command or in the Sybase error log
($SYBASE/install/errorlog_EventServer):
Your server command (process id #11) was deadlocked with another
process and has been chosen as deadlock victim. Re-run your
command.
Resolution
A deadlock is a Sybase condition that occurs when two users have a lock
on separate objects, and they each want to acquire an additional lock on
the other user’s object. The first user is waiting for the second user to let
go of the lock, but the second user will not let go until the lock on the
first user’s object is freed.
The dataserver detects the situation and chooses the user whose process
has accumulated the least amount of CPU time as the “victim.” The
dataserver rolls back the victim’s transaction, notifies the application
with the above error message, and allows the other user’s processes to
move forward.
Symptoms
Users cannot make connections to the database; they cannot start the
GUI or send events. When you check the Sybase error log ($SYBASE/
install/errorlog_EventServer) you see one or both of the following
errors:
Not enough User Connections (Sybase error 1601)
No Pss structures available for new process
Resolution
These messages occur because there are more users who want to run jobs
simultaneously than there are user connections; there are not enough
connections available to the database. By default, the bundled Sybase
installation of AutoSys has a limit of 25 user connections. You can
increase the number of user connections, but first you must determine
the maximum number of user connections your system can support.
3 Enter:
2 Stop and restart the Event Server. Changes will not take effect until
you stop and restart the Event Server.
Symptom
When the transaction log is full, archive_events fails. This usually occurs
because archive_events is not run regularly. We highly recommend that
you run archive_events frequently, ideally as part of the daily database
maintenance cycle by using DBMaint or as a regularly scheduled job.
You can usually avoid a full transaction log by having Sybase truncate the
transaction log during regular checkpoints.
1> sp_helpdb;
1> checkpoint;
1> exit
Resolution
5 Log out of the dataserver, and then run archive_events. Begin with a
large number of days and work down until you reach your target
number of days. For example:
archive_events -n 30
archive_events -n 10
Symptom
When starting a bundled Sybase Event Server, you get a message similar
to the following:
00: 94/08/18 10:38:37:66 kernel: kcinit:
couldn’t open error log
‘/users/sybase/stdb/install/errorlog_AUTOSYSDB’
(os error 13)
Resolution
You are not the same user who last started Sybase, and do not have
permission to write to the Sybase error log file. Become that user, change
the error log file ($SYBASE/install/errorlog_$DSQUERY) permissions, or
delete the old error log file.
Everything that the Event Processor does, in the order it was done, is in
this file. Network problems are usually reflected in this file as well. This
file is very useful for reconstructing what happened when a problem
occurs.
Symptoms
1 Jobs do not start.
Resolution
Confirm that the Event Processor is down by performing one of the
following actions:
■ Perform a tail on the log file and check for date stamps.
If the Event Processor is indeed down, log on as the Exec Superuser and
run the eventor command to restart it.
Symptom
When running the eventor command, you see an error message similar
to the following:
/usr/autotree/autosys/bin/eventor:/usr/autotree/autouser/out/
event_demon.ACE:Cannot create
Resolution
You are not the same user who last started the Event Processor. Ether
become that user, or change permissions on the Event Processor output
file, the $AUTOUSER/out/event_demon.$AUTOSERV file.
autoping
autoping is used to test the connections between the Event Processor and
the Remote Agent. If you use the autoping -M -D client_hostname
command, and it does not return an error, the Remote Agent should start
properly.
Database Verification
Use autoping to verify the Remote Agent database connection. To check
the database connections on machine, enter this:
autoping -m machine -D
Instead of a single machine, you can type -m ALL to check all machines.
Symptom
The Event Processor’s $AUTOUSER/out/event_demon.$AUTOSERV log file
contains a message similar to this:
Attempting to connect to AutoSys Remote Agent
Service on socket=5280: Connection Refused
Attempting to connect to ‘inetd’ on
socket=5280: Interrupted system call
The connection to machine: spartacus TIMED OUT.
Either that machine, or the network to it, is
having problems.
ERROR trying to start job: test
Error: Connect to socket FAILED.
Command: sleep 1
Machine: spartacus
Resolution
Either there is a network communication problem, or the client machine
is down. The network or machine problems must be resolved before jobs
can be run on that machine.
Symptom
The Event Processor’s $AUTOUSER/out/event_demon.$AUTOSERV log file
contains a message similar to this:
Attempting to connect to AutoSys Remote Agent
Service on socket=5280: Connection Refused
Attempting to connect to ‘inetd’ on
socket=5280: Interrupted system call
Could NOT connect to machine: spartacus The
internet daemon may not be configured properly.
ERROR trying to start job: test
Error: Connect to socket FAILED.
Command: sleep 1
Machine: spartacus
Resolution
There is a problem with the /etc/services file. To locate this problem,
check the following:
auto_remote 5280/tcp
2 Confirm that the Remote Agent port number, specified with
AutoRemPort in the AutoSys configuration file ($AUTOUSER/
config.$AUTOSERV), is the same number as used in the /etc/services
file.
3 If you are using NIS/NIS+, remake the services and push it out.
Symptom
In the Event Processor’s $AUTOUSER/out/event_demon.$AUTOSERV log file,
you see a message similar to the following:
[spartacus connected]
*** Remote Agent Process not started. ***
socket read <>, rc=0
ERROR trying to start job: test
Error: Auto Remote process did not start.
Command: sleep 1
Machine: spartacus
Resolution
Check that the internet daemon is properly configured on the client
(Remote Agent) machine. There should be an entry in inetd.conf for
auto_remote. If present, this line points to the Remote Agent’s executable.
Assuming that auto_remote is in the /usr/local/bin directory, and will
be run by the user “root,” the entry should look like this (on one line):
auto_remote stream tcp nowait root/usr/local/bin/auto_remote auto_remote
If the auto_remote entry exists in the inetd.conf file, follow these steps:
1 Make sure that the auto_remote binary (the Remote Agent executable)
exists in the specified directory and has “execute” permission.
3 Make sure the Remote Agent can write to the AutoRemoteDir directory
(usually /tmp), and that this directory has available space.
where:
AutoRemoteDir
auto_rem.pid
When the Remote Agent receives its instructions from the Event
Processor, it renames this file in order to give it a unique name. This is
the form of the new filename:
AutoRemoteDir/auto_rem.joid.run_num.ntry
where:
joid
This file contains all the instructions passed to the Remote Agent by the
Event Processor, the results of any resource checks, and a record of all
actions it took. Any problems experienced by the Remote Agent are
reported here, including the inability to send events to the database(s),
which is the most common problem.
To find the most recent instance of the Remote Agent Log for a given job,
you issue the following command on the machine where the job last ran:
autosyslog -J job_name
Note • If the configuration file specifies that the Remote Agent log
files are to be cleaned up at the completion of a job, and the job
completed normally, the file will have been removed. If the job failed
for some reason, the file will not be deleted, regardless of the
configuration file setting. To turn off automatic deletion of the
Remote Agent log files, set the CleanTmpFiles parameter in the
configuration file to 0.
For more information about the AutoSys configuration file and the
CleanTmpFiles parameter, see the Configuration File Parameters section of
Chapter 13, Configuring AutoSys.
Symptoms
1 The job is stuck in either the STARTING or RUNNING state as seen in
either the Event Processor log or the output resulting from issuing the
following command:
autorep -J job_name
2 The job has immediately returned as a FAILURE.
Resolution
If you have gotten to this point, the AutoRemoteDir/auto_rem* file should
be present. By looking in this file, you will see how far AutoSys was able
to get. You should check and verify the following items:
1 The correct file is being sourced before running the job command. The
default file is /etc/auto.profile. A job-specific file may be sourced
instead of the default profile.
2 The $PATH variable is setup properly, and includes the proper location
for all required executables. Variables, such as $PATH, must be exported
for the job to see them.
3 The file system that the job command is on is accessible from this
machine.
6 The profile is a Bourne shell script. Korn shell and C shell scripts will not
work.
Sent
Symptoms
1 Job is stuck in STARTING state.
2 This problem is detected either in the Event Processor window (or log)
or in the results of running the autorep command on the job, when
the following event appears, then nothing else, yet the job does run to
completion on the client machine:
CHANGE_STATUS Status: STARTING Job: test_install
Resolution
This is a common problem and is nearly always the result of the Remote
Agent being unable to contact the Event Server. First of all, ensure that
network problems are not preventing communication between the
Remote Agent and the Event Server machines. If this is not the problem,
then check the following database-specific solutions.
With Sybase, this problem usually occurs because the interfaces file is not
set up properly on the machine running the Remote Agent. With Oracle,
this problem usually occurs because the SQL*Net V2 connections are not
set up properly.
The Remote Agent must be able to connect to the Event Server in order to
send the RUNNING, SUCCESS, FAILURE, or TERMINATED status events.
If the Remote Agent cannot send the event back to the database, it will
write a message to that effect, plus some diagnostics, into this file. (The
output from the autosyslog command could provide a helpful DBMS
error number from the connect attempt.)
1 Check that the Sybase interfaces file exists and is readable by all
users. The location of the interfaces file is pointed to by an entry in
the
/etc/auto.profile, which looks like this:
#AUTOENV#SYBASE=/usr/home/sybase
2 Check that the Sybase interfaces file has an entry for the dataserver
that contains the AutoSys Event Server.
#AUTOENV#TNS_ADMIN=/usr/home/oracle
/etc/auto.profile must be readable by all users.
2 Check that the Oracle TNS names file has a SQL*Net V2 formatted
entry for the Event Server.
When testing Sybase using xql, be sure that your user environment is
looking at the same interfaces file as the auto_remote (Remote Agent).
Set SYBASE to the same value that is in /etc/auto.profile.
Note that the auto_remote only attempts to read the interfaces file once.
After a bad interfaces file has been read, correcting it will not allow a
running auto_remote to connect. After you correct the interfaces file,
you will have to kill the auto_remote and restart the job.
For Sybase, try to log onto the Event Server from the remote machine
using xql, like this:
xql -U autosys -P autosys -S AUTOSYSDB
When testing Oracle using sqlplus, be sure that your user environment
is looking at the same tnsnames.ora file as the auto_remote (Remote
Agent). Set TNS_ADMIN to the same value that is in /etc/auto.profile.
Note that the auto_remote only attempts to read the tnsnames.ora file
once. After a bad tnsnames.ora file has been read, correcting it will not
allow a running auto_remote to connect. After you correct the
tnsnames.ora file, you will have to kill the auto_remote and restart the
job.
For Oracle, try to log onto the Event Server from the remote machine
using sqlplus with a V2 connect descriptor, like this:
sqlplus autosys/autosys@AUTOSYSDB
Symptom
From the remote machine, xql returns the following message:
DB-Library error: dbproc NULL
Error in SybInit: dbopen failed
Resolution
Check the following:
Or
Run xql with the -S and -D options to specify the correct dataserver
and database.
Symptom
When trying to start a job or trying to start the Event Processor with a
Shadow Event Processor, the following message appears in the Event
Processor log when viewed with the autosyslog -e command:
Unknown Host Machine
Resolution
You may receive this message in the following situations:
Check /etc/hosts or DNS for the machine name, and add it if necessary.
2 The Remote Agent on the client starts the job, and then tries to
respond to the server.
4 The server checks if the job can be restarted, and then restarts the job.
Meanwhile, the job is running and perhaps has completed on the
client.
5 The server opens another connection to the client to run the job a
second time.
6 The Remote Agent starts the job and responds to the server in time.
Severe performance problems on the client are the main reason this
occurs. For example, the following might affect performance:
■ Running a full system backup on the client at the same time jobs are
starting might slow down the system so that it cannot respond to the
server.
■ Are there too many processes running on the client when you run
jobs?
Symptom
Jobs run from the command line, but they fail when run by AutoSys.
Resolution
This problem is nearly always the shell environment where the job runs.
The following are the possible reasons for the problem:
1 The profile in the job definition is not a Bourne shell (sh) type profile.
If this is the case, the profile fails.
2 The default AutoSys profile does not produce the proper environment
for the job to run. The default profile for all AutoSys jobs is /etc/
auto.profile, not the job owner’s logon profile $HOME/.profile. If
the job owner’s profile is not specified in the job definition, it is never
sourced.
To check the difference between the job definition and the user
environment, do the following:
client_hostname
Also, it is useful to define the std_err_file for the job that fails,
because you can check the errors from the shell for a clue about what
is missing.
A Introduction
AutoSys enterprise-wide scheduling lets you integrate AutoSys jobs with
AutoSys Agents for AS/400, OpenVMS, and with various scheduling
products on the mainframe. The following types of integration are
supported:
1 Definition of Terms
The following terms are used in this appendix::
1 Related Documentation
The information presented in this appendix supplements the following
documents:
1 Prerequisites
Before you can implement enterprise job scheduling, you must install
and configure the basic AutoSys software as instructed in the AutoSys
Installation and Getting Started Guide for UNIX. You must also install and
configure AutoSys Connect or AutoSys Agents, or both, as instructed in
the documentation for these components.
The required software and version levels are listed in the following table:
where:
INS
where:
where:
1 License Keys
AutoSys client license keys are required for agent machines in order for
AutoSys to run jobs on those machines.
For agent machines, the host name is the REMOTE_HOST and the host id is
always 0 (zero).
When you supply the above information to the TLC group, they will
provide you with a client key. You install the client key in the AutoSys
database using the gatekeeper command, as shown in the following
example:
gatekeeper <Return>
Utility to Add/Delete or Print KEYs.
Add (A) or Delete (D) or Print (P) ? a
KEY Type: [(c)lient, (s)erver, (t)ime, (x)pert]: c
Hostname: REMOTE_HOST
Hostid: 0
KEY: IIJJKKLLMMNNOOPP
***** New Key ADDED! *****
KEY Type: [(c)lient, (s)erver, (t)ime, (x)pert]:<Return>
1 About asbrokerII
Communication between AutoSys and AutoSys Connect or an AutoSys
Agent is facilitated by asbrokerII. It is a necessary component for cross-
platform communication. Letting asbrokerII handle that exchange frees
the Event Processor to handle other events.
ASBROKERII_INSTANCE
The ASBROKERII_INSTANCE environmental variable allows multiple
instances of asbrokerII program to run on the same machine, if deemed
necessary. Each instance is uniquely identified by a seven character token.
ASBROKERII_PING_INTERVAL
The ASBROKERII_PING_INTERVAL environmental variable sets the ping
interval of asbrokerII in seconds. asbrokerII pings the Unicenter TNG
Agent and AutoSys Connect machines periodically to check if they are
alive.
ASBROKERII_RECV_INTERVAL
The ASBROKERII_RECV_INTERVAL environmental variable sets the
interval, in milliseconds, between checks of the receive queue for job
status coming from the Unicenter TNG Agent and AutoSys Connect
machines.
ASBROKERII_TRKARRAY_SI ZE
The ASBROKERII_TRKARRAY_SIZE environmental variable sets the
initial number of unique external dependencies handled by asbrokerII.
ASBROKERII_CKP_PATH
The ASBROKERII_CKP_PATH environmental variable sets the location
of the asbrokerII checkpoint file. The checkpoint file contains the last
timestamp of the last record that is received from a specific agent.
Dependencies
AutoSys jobs can have dependencies on jobs managed by the AutoSys
Connect scheduling software running in the OS/390 environment. For
example, an AutoSys job defined to run on a UNIX or NT machine could
have as a starting condition the successful completion of a AutoSys
Connect job running on a mainframe system.
Event C
Server CCI CCI O
N
N Job
E
C
T
Event
Processor asbrokerII
4 The job runs as scheduled by AutoSys Connect which can run the job
on the mainframe.
7 The Event Processor starts the AutoSys job that is dependent on the
completion of the remote job.
From JIL, you enter this in the condition job attribute, as shown in the
following example:
condition: success(JOB_NAME^INS)
From the AutoSys GUIs, enter this information in the Starting Condition
field of the Job Definition screen. Use the following statuses in the
condition attribute of an AutoSys job definition dependent on a AutoSys
Connect job:
■ success
■ terminated
■ done
■ notrunning
Jobs
Because of naming limitations in the OS/390 environment, the names of
jobs specified as job dependencies between AutoSys and AutoSys
Connect must follow these guidelines:
Note • These limitations do not apply to all AutoSys jobs, only to jobs
that will be referenced to AutoSys Connect.
Event
Processor asbrokerII AGENT
Where the operating system allows, agent job names can contain up to
64 alphanumeric characters and agent user IDs can contain up to 30
alphanumeric characters. These job names and user IDs can be both
uppercase and lowercase (when the operating system allows mixed case).
Blank spaces and tabs are illegal characters.
2 asbrokerII passes the information to the agent, which starts the job.
3 The agent passes the information that the job is running (BOJ event)
to CCI on the AutoSys machine which writes it to the proper broker
instance.
5 When the job exits, the agent client traps the return code and passes
the information that the job is finished to asbrokerII.
where:
REMOTE_HOST
The owner identified in the owner attribute of the job definition must
have an account on the target agent machine. The account must match
the owner name exactly in order for the job to run. The owner of the job
definition must be specified as “user@machine.” The AutoSys Edit
Superuser must use the autosys_secure binary to add valid userids and
passwords using option 4 as follows:
$ autosys_secure
2 Select option 4 from the menu:
Statuses
The valid statuses that AutoSys can get for AutoSys Connect and AutoSys
Agent managed jobs are:
STARTING
The job has been passed from the Event Processor to asbrokerII.
RUNNING
The job has started and a BOJ (Beginning Of Job) event has been sent
back to asbrokerII.
SUCCESS
The job has ended and an EOJ (End Of Job) event has been passed
back to asbrokerII.
FAILURE
The job has ended and an AEOJ (Abnormal End Of Job) event has
been sent back to asbrokerII.
1 Cross-Platform Limitations
When you running across platforms, keep the following in mind:
• CHANGE_PRIORITY
• SEND_SIGNAL
Connections
The following are troubleshooting tools:
netstat
The netstat command allows you to check TCP/IP statistics:
Shows all connections to the local host involving a port which can be
resolved to caic(ci). The important connections are ESTABLISHED
and LISTEN. If the latter is present, you know that the kernel accepts
connections on behalf of the ccirmtd process. This means that a
remote host attempting to connect to this host should get the TCP/IP
connected state. Established connections are important because we
know that CCI transactions may not transpire between the hosts in
question if a TCP/IP Established connection does not exist.
■ netstat –i
Ping
Ping allows you to establish that a remote host can be reached. It is
important to ping by IP address as well as hostname. If you cannot ping
a host, CCI cannot establish a connection to that host.
nslookup
nslookup allows you to be sure that the name of the host to which you
wish to connect, as well as the IP address, is resolvable. If there is a
question as to the integrity of the DNS environment, you can use
nslookup to verify the IP address of the host to which you need to
communicate. You then enter the IP address back into nslookup and
verify that the same hostname is returned. Verify the IP address and
hostname for both hosts.
traceroute
The traceroute command on UNIX and the tracert command on
Windows NT allow you to determine the route taken between two hosts.
If a client cannot ping a host, this command may show where the
network path is failing.
ccinet
ccinet may be used to pass commands to the ccirmtd daemon on UNIX.
On Windows NT, this is the rmtcntrl binary. This may be used as follows:
■ ccinet ping
Can be used to send a special CCI test packet across the CCI
connection. This does not use the native ping command nor does it
operate in quite the same way.
■ ccinet status
■ ccir/ccis/ccic/ccii
On UNIX platforms the command binary for the main CCI daemon is:
$CAIGLBL0000/cci/bin/cci
■ cci show
■ cci shutdown
cci show
This allows you to view the shared memory segment where CCI stores the
RVT list. This is useful to determine general CCI information, such as:
You can also use this command to display information about a specific
receiver, such as:
■ The PID of the process that holds the semaphore for this receiver
When there is not a problem with the CCI semaphores, only the last line
is returned.
Next, you issue the following for each held semaphore in the semashow
output:
cci semaclear X
The semaclear command releases the semaphore and may allow AutoSys
to continue normal operations.
cci shutdown
Tells the main daemon to shutdown. The use of this command is not
advised if AutoSys is still running.
The binary used to pass commands to the CCI remote daemon is:
$CAIGLBL0000/cci/bin/rmt
■ ccinet show
This command will output data concerning the hosts to which the
remote daemon is or should be connected. It will also output
information about the receivers available on those remote platforms
similar to the RVT information displayed by ‘cci show’. The output
from this command is written to the ccirmtd trace file. Therefore, to
capture this output we prefer that traces have been enabled prior to its
execution. This data is also output to the system console. The output
from this command is usually important for solving all issues
involving remote communication.
$CAIGLBL0000/cci/logs/ccirmtd_<pid>.log
■ ccinet status
■ ccinet release
The commands are passed to the CCI daemon processes using the
message queue facility. Therefore, if there is a problem with these
facilities the commands may not function correctly.
2 Reinstalling CCI
If you need to reinstall CCI, for any reason, reinstall AutoSys. When the
AutoSys installation asks you if you want to install CCI, answer yes.
status M
ACTIVATED 3-10 machine
FAILURE 3-11 attribute 4-8, 4-9
INACTIVE 3-10 backing up definitions 12-14
managing 3-24 client 1-10
ON_HOLD 3-12 defining with JIL 9-4
ON_ICE 3-12 deleting
QUE_WAIT 3-11 real machines 9-9
RESTART 3-11 virtual machines 9-10
STARTING 3-10 factor attribute 9-6
SUCCESS 3-11 job runs on 4-8
TERMINATED 3-11 machine attribute 9-4
status codes 3-10 max_load attribute 9-5
time dependencies, setting permissions, edit and execute 2-13
JIL 7-12 priority job attribute 9-6
time/date dependencies 3-17 real 9-3
types 3-4 restoring definitions from backup file
variables for 4-7 12-16
JobScape 6-4 saving definitions to backup file 12-14
server 1-10
K type attribute 9-4
KILLJOB signals 13-25 virtual 9-3
KillSignals 13-25 defining 9-9
deleting 9-10
L MachineMethod 13-24
license keys A-9 maintenance
load balancing 9-11 backing up AutoSys definitions 12-13
example 9-13 calendar definitions 12-14
force starting jobs 9-14 global variables 12-15
job attributes required for 9-5 job definitions 12-14
maximum load on machine 9-5 machine definitions 12-14
method 13-24 monitor and browser definitions
ServerVision 13-38 12-15
user-defined 9-26 chase command 12-12
locking, Remote Agent log file 13-20 clean_files 12-13
commands 12-12
database 13-16
V
variables in a Command Job definition
4-7
virtual machines 9-3
defining 9-4, 9-9
deleting 9-10
example 9-9
type 9-4
using delete_machine 9-4
using insert_machine 9-4
vmstat 13-24
W
WaitTime 13-23
watch_file 4-9
watch_file_min_size 4-26
watch_interval 4-26
Windows NT
job permissions on 2-15
X
X resources, customizing Calendar Facility
8-31
XInstanceDBDropTime 13-11
xql, example scripts 12-33