Autosys

PLATINUM
AutoSys
User Guide for Windows NT
Version 3.4
Title and Publication Number PLATINUM Publication Number: ATS-3-342-UG00-01 Printed: December, 1997 Information in this guide is subject to change without notice and does not constitute a commitment on the part of PLATINUM technology, inc. It is supplied on an as is basis without any warranty of any kind, either explicit or implied. Information may be changed or updated in this guide at any time. Copyright Information AutoSys is copyright 1993 - 1997 by PLATINUM technology, inc. and its subsidiaries. This guide is copyright 1993 - 1997 by PLATINUM technology, inc., and its subsidiaries and may not be reproduced in whole or in part, by any means, without the written permission of PLATINUM technology, inc. and its subsidiaries. Names marked or and other company and product names may be trademarks or registered trademarks of their respective vendors or organizations. Mailing Address PLATINUM technology, inc. 1815 South Meyers Road Oakbrook Terrace, Illinois 60181-5235
Table of Contents
Preface
Philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv Contacting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi Whats New . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx Native Windows NT GUIs with Multiple Instance Support . . . . . . . . . . . xx Year 2000 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx PLATINUM ProVision Common Services Integration . . . . . . . . . . . . . . . . xxi Reporting using InfoReports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi Security Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii Event Processor Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii AutoSys Administrator Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii Time Zone Setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiv Set Append or Overwrite Behavior for Standard Files . . . . . . . . . . . . . . xxiv Expanded Number of Entries in config.EXTERNAL File . . . . . . . . . . . . . xxiv AutoSys Command Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv Related Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvii
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 Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-7 Interface Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-9 AutoSys Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10
PLATINUM AutoSys User Guide for Windows NT
iii s
s Table of Contents
AutoSys Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11 Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11 Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12 Basic AutoSys Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13 Explanation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14 Extending AutoSys Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15
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-7 AutoSys Database Field Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8 Job Definition Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8 Remote Agent Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8 AutoSys User and Database Administrator Passwords . . . . . . . . . . . . . 2-10 AutoSys Job-Level Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10 AutoSys Job Ownership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11 AutoSys User Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11 AutoSys Permission Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12 Job Permissions and Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13 AutoSys Superuser Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14 Edit Superuser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14 Exec Superuser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15 Restricting Access to AutoSys Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15 Remote Agent Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17 AutoSys Security and Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17 Defining Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18 Starting Jobs Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20 Running Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21 Examples of AutoSys Security on Windows NT . . . . . . . . . . . . . . . . . . . 2-23
s iv
Table of Contents s
3 AutoSys Jobs
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-3 Job Types and Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-3 Basic Job Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-4 Command Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-5 Box Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-6 File Watcher Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-7 Job Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-8 Using the Job Profiles Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-9 Basic Job Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12 Command Job Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13 File Watcher Job Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13 Box Job Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14 Job States and Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14 Example State Diagram - Simple Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17 Example State Diagram - Box Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19 Starting Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20 Starting Parameters and Boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21 Date/Time Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-22 Job Dependencies Related to Job Status . . . . . . . . . . . . . . . . . . . . . . . . 3-23 Event Processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-27 Event Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-27 Job Dependencies Based on Exit Codes . . . . . . . . . . . . . . . . . . . . . . . . 3-30 Job Dependencies Based on Global Variables . . . . . . . . . . . . . . . . . . . 3-33 Job Run Numbers and Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-34 Defining Jobs in AutoSys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-35 AutoSys Graphical User Interface Components . . . . . . . . . . . . . . . . . . 3-36
4 Job Attributes
Job Attributes and Job Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3 Using JIL to Create a Job Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3 Using the Job Editor to Create a Job Definition . . . . . . . . . . . . . . . . . . . .4-4 Chapter Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4
v s
s Table of Contents
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-10 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-30
5 Box Job Logic

Basic Box Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3 Default Box Job Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3 When you Should Not Use a Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4 What Happens when a Box Runs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4 Box Job Attributes and Terminators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6 Attributes in a Box Job Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6 Attributes in a Job Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7 Time Conditions in a Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7 Force Starting Jobs in a Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8 How Job Status Changes Affect Box Status . . . . . . . . . . . . . . . . . . . . . . . 5-9 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10 Advanced Conditions in Box Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11 Default Box Success and Box Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13 Explicit Box Success and Box Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15 Using the Box Terminator Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16 Using the Job Terminator Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17 Advanced Job Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18
s vi
Table of Contents s
6 Introduction to the Graphical User Interface

Starting the GUI Control Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2 Using the GUI Control Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2 GUI Control Panel Menu Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2 GUI Control Panel Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-4
7 Defining AutoSys Jobs using the Job Editor

Starting the Job Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3 Using the Job Editor Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-4 Job Editor Menu Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-5 Job Editor Tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-8 Job Editor Status Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-8 Creating a Simple Command Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10 Creating a File Watcher Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12 Creating a Dependent Command Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-15 Creating a Box Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-19 Creating the EOD_box Box Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-19 Modifying the EOD_post Command Job . . . . . . . . . . . . . . . . . . . . . . . . 7-21 Setting Date and Time Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-23 Setting Days of the Week Starting Conditions . . . . . . . . . . . . . . . . . . . 7-25 Setting Time Starting Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-26 Example on Setting Date and Time Dependencies . . . . . . . . . . . . . . . 7-27 Deleting Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-29 Notes on Deleting a Box Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-31 Specifying One-time Job Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-31 Setting Job Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-31 Deleting One-Time Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-33 Enabled Job Editor Fields for One-Time Overrides . . . . . . . . . . . . . . . . 7-34
8 Defining Jobs Using JIL

Job Information Language (JIL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-3 JIL Syntax Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-3 JIL Sub-commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-5 Submitting Job Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-6 Running JIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-6
vii s
s Table of Contents
Creating a Simple Command Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7 Creating a File Watcher Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7 Creating a Dependent Command Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8 Creating a Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-10 Changing a Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-11 Setting Time Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-12 Additional Time Setting Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-13 Deleting a Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-14 Deleting a Box Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-14 Specifying One-Time Job Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-15 Setting Job Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-16 Example JIL Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-17
9 Calendar Editor
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3 Using Defined Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4 Scheduling Jobs with Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4 Starting the Calendar Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-6 Using the Calendar Editor Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7 Using the Menu Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7 Using the Navigation Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-12 Using the Calendar Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14 Creating and Modifying Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-16 Creating a Calendar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-16 Opening an Existing Calendar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-18 Applying Rules to Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-19 Using the Rule Specification Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-21 Using the Rescheduling Rule Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-25 Combining Existing Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-28 Combining Calendars Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-28 Using the Job Definition Reference List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-29 Importing and Exporting Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-30 Importing Calendar Text Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-31 Exporting Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-32
s viii
Table of Contents s
10 Load Balancing and Queuing Jobs

Real Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3 Virtual Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3 Defining Machines to AutoSys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4 Specifying Machine Load (max_load) . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-5 Specifying Relative Processing Power (factor) . . . . . . . . . . . . . . . . . . . . 10-6 Using max_load and factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-6 Machine Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7 Defining a Real Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-8 Deleting Real Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-9 Defining a Virtual Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-9 Deleting Virtual Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-11 Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-12 Force Starting Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-15 Queuing Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-15 Queuing and Simple Load Limiting . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-16 Queuing with Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-17 SubsetsIndividual Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-19 Multiple Machine Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-21 User-Defined Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-22
11 Scheduler Console
Using the Scheduler Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3 Using the Scheduler Console Menu Bar . . . . . . . . . . . . . . . . . . . . . . . . . 11-5 Using the Control Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-12 Using the Summary Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-12 Defining Scheduler Console Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-15 Filters Editor Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-16 Using the Filter Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-22 Using Scheduler Console Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-22 Using the Job Dependencies Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-23 Using the Run Status Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-24 Using the Send Event Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-28
ix s
s Table of Contents
Using Scheduler Console Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-38 Using the Job Detail Report Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-38 Viewing Reports with InfoReports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-41 Setting Scheduler Console Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-43 Using the General Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-44 Using the User Defined Buttons Dialog . . . . . . . . . . . . . . . . . . . . . . . . . 11-45 Using the User Defined Reports Dialog . . . . . . . . . . . . . . . . . . . . . . . . . 11-47 Using the Summary Area Layout Dialog . . . . . . . . . . . . . . . . . . . . . . . . 11-49 Using the Action Area Layout Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . 11-52 Setting the Time Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-56
12 Managing Alarms
Using the Alarm Sentry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2 Using the Alarm Sentry Menu Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3 Using the Alarm Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3 Using the Alarm Manager Menu Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-6 Using the Alarm Manager Alarm List . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-8 Viewing the Currently Selected Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-9 Setting the Refresh Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-10 Filtering Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-11 Selecting Alarms by Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-13 Selecting Alarms by State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-14 Selecting Alarms by Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-14 Selecting Alarms by Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-14
13 Monitoring and Reporting on Jobs

Using AutoSys Monitors and Browsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-3 Using Monitors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-4 Using Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-4 Using the Monitor/Browser Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-5 Using the Monitor/Browser Editor Menu Bar . . . . . . . . . . . . . . . . . . . . . 13-6 Defining Monitors and Reports with the Editor . . . . . . . . . . . . . . . . . . . . . . 13-9 Defining a Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-9 Defining a Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-12 Closing the Monitor/Browser Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-13
s x
Table of Contents s
Setting Monitor and Report Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting Event Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting the Job Selection Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting Monitor Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting the Browser Time Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running a Monitor or Generating a Report . . . . . . . . . . . . . . . . . . . . . . . . Defining Monitors and Reports using JIL . . . . . . . . . . . . . . . . . . . . . . . . . . Defining Monitors using JIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining Reports using JIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13-13 13-14 13-16 13-17 13-18 13-19 13-20 13-21 13-22
14 Maintaining AutoSys
Maintaining the Event Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-3 Starting the Event Processor Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-3 Monitoring the Event Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-5 Starting the Event Processor in Global Auto Hold Mode . . . . . . . . . . . 14-7 Stopping the Event Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-9 Shadow Event Processor Rollover . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-10 Maintaining the Remote Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-13 Starting the Remote Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-13 Stopping a Remote Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-14 Running AutoSys in Test Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-14 AutoSys Maintenance Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-16 Backing up AutoSys Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-18 Restoring AutoSys Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-20 AutoSys Database Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-21 Event Server Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-21 Database Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-23 General Database Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-24 Daily Database Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-25 DBMaint.bat Batch File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-25 Event Server Rollover Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-27 Returning to Dual Server Mode After a Rollover . . . . . . . . . . . . . . . . 14-27 Improving Database Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-34 Improving Sybase Database Performance . . . . . . . . . . . . . . . . . . . . . 14-35 Improving Oracle Database Performance . . . . . . . . . . . . . . . . . . . . . . 14-35
xi s
s Table of Contents
Maintaining Bundled Sybase SQL Servers . . . . . . . . . . . . . . . . . . . . . . . . . . 14-37 Sybase Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-37 Sybase Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-38 Default Sybase Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-38 Starting Sybase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-40 Stopping Sybase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-41 Accessing Sybase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-42 Identifying Processes Connected to the Database . . . . . . . . . . . . . . . 14-42 Displaying the Database Date and Time . . . . . . . . . . . . . . . . . . . . . . . 14-43 Bundled Sybase Backup and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . 14-44
15 AutoSys Administrator
About the AutoSys Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-3 Starting the AutoSys Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-5 AutoSys Administrator Menu Bar and Toolbar . . . . . . . . . . . . . . . . . . . 15-5 AutoSys Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-9 AutoSys Administrator Instance Screen . . . . . . . . . . . . . . . . . . . . . . . . 15-10 AutoSys Remote Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-11 AutoSys Administrator Remote Agent Screen . . . . . . . . . . . . . . . . . . . 15-12 AutoSys Event Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-15 Dual Event Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-15 AutoSys Administrator Event Server Screen . . . . . . . . . . . . . . . . . . . . . 15-16 AutoSys Event Processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-22 AutoSys Administrator Event Processor Screen . . . . . . . . . . . . . . . . . . 15-23 AutoSys Notification Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-37 AutoSys Administrator Notifications Screen . . . . . . . . . . . . . . . . . . . . . 15-37 AutoSys System Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-40 AutoSys Administrator System Information Screen . . . . . . . . . . . . . . . 15-41 AutoSys Sounds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-45 AutoSys Administrator Sounds Screen . . . . . . . . . . . . . . . . . . . . . . . . . 15-46 AutoSys Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-48 User Remote Authentication Example . . . . . . . . . . . . . . . . . . . . . . . . . 15-49 AutoSys Administrator Security Screen . . . . . . . . . . . . . . . . . . . . . . . . . 15-50 AutoSys Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-52 AutoSys Administrator Services Screen . . . . . . . . . . . . . . . . . . . . . . . . . 15-52
s xii
Table of Contents s
16 Troubleshooting
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-3 NT Services Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-4 Event Server Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-5 Event Server is Down (Sybase) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-5 Sybase Deadlock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-6 Not Enough User Connections (Bundled Sybase) . . . . . . . . . . . . . . . . . 16-7 archive_events Fails (Bundled Sybase) . . . . . . . . . . . . . . . . . . . . . . . . . . 16-9 Event Server Unable to Extend Tablespace (Oracle) . . . . . . . . . . . . . . 16-11 Event Processor Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-12 Event Processor is Down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-12 Event Processor Will Not Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-13 Remote Agent Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-18 Remote Agent Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-18 Remote Agent Will Not Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-19 Remote Agent Starts, Command RunsNo RUNNING Event is Sent 16-21 xql Will Not Start (Sybase Only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-24 Job Failure Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-24 Remote Agent Will Start - Command Will Not Run . . . . . . . . . . . . . . 16-24
A Integrating AutoSys with Zeke and AutoSys/Team Agent

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-3 Definition of Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-3 Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-4 Job Scheduling for the Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-5 Installing and Configuring for Enterprise Job Scheduling . . . . . . . . . . . . . . . A-6 Install the Basic AutoSys Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-6 Install AutoSuite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-7 Configure the AutoSys Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-8 Initializing the Communication Components . . . . . . . . . . . . . . . . . . . . . . . . A-12 License Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-14 Restart the Event Processor and Start the AutoSuite Service . . . . . . . . A-14 About the oasis_broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-15
xiii s
s Table of Contents
AutoSys and Zeke Cross-Platform Dependencies . . . . . . . . . . . . . . . . . . . . . A-16 Job Scheduler Interdependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-17 Notation for Cross-Platform Job Dependencies . . . . . . . . . . . . . . . . . . . A-18 Naming Conventions for AutoSys/Zeke Cross-Platform Jobs . . . . . . . A-19 Running AutoSys Jobs on the Team Agent . . . . . . . . . . . . . . . . . . . . . . . . . . A-20 Running Jobs on Team Agent Managed Machines . . . . . . . . . . . . . . . . A-21 Defining Team Agent Machines to AutoSys . . . . . . . . . . . . . . . . . . . . . . A-22 Team Agent Machine in an AutoSys Job Definition . . . . . . . . . . . . . . . A-23 Database Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-23 Logs Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-23 Zeke and Team Agent Job Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-23 Unsupported Attributes for Zeke or Team Agent Jobs . . . . . . . . . . . . . . . . A-24 Cross-Platform Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-26
Index
s xiv
Preface
Welcome to the world of AutoSys, the scheduling and operations automation software for distributed computing environments. This guide describes how to use AutoSys to define and run jobs. This guide is for users who are 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 Windows NT.
Philosophy
PLATINUM technology, inc. is the leading vendor of open enterprise systems management (OESM) products, which help organizations manage all the hardware and software components of the multiplatform, multi-operating system, multivendor environment called the open enterprise environment (OEE). By leveraging its expertise in relational technology, PLATINUM offers products and services that increase the efficiency of individual computing systems and databases, as well as the interoperability of these systems and databases in distributed environments.
xv s
s Preface
Contacting Technical Support
Contacting Technical Support

You can contact us with any questions or problems you have. You will be directed to an experienced software engineer familiar with PLATINUM AutoSys. To send Email to PLATINUM Technical Support, use: Internet techsup@platinum.com IBM MAIL Exchange USRWNPSN To contact PLATINU M Technical Support, use: USA or Canada, toll free 800-833-PLAT (7528) IBM Software Mall PLATSM4 CompuServe GO PLATINUM For product assistance or information, contact: USA or Canada, toll free 800-442-6861 Illinois 630-620-5000 FAX 630-691-0708 or 630-691-0406 Internet info@platinum.com World Wide Web http://www.platinum.com Our Mailing Address is: PLATINUM technology, inc. 1815 South Meyers Road Oakbrook Terrace, IL 60181-5235
About This Guide

The PLATINUM AutoSys User Guide for Windows NT explains how to define, run, monitor, manage, and control AutoSys. It has been designed to present information in a natural order so that basic concepts are discussed prior to more advanced topics.
s xvi
Preface s About This Guide
This guide assumes that the appropriate PLATINUM AutoSys components have been installed at your site. The instructions for installing the product are in the AutoSys Installation and Getting Started Guide for Windows NT. The chapters of this guide are organized in the following way.
Ch. No. Chapter Name 1 Content Description
Introduction to AutoSys
Describes AutoSys and its system architecture, system components, events, alarms, and utilities. It also includes descriptions of basic AutoSys configurations as well as an overview of basic functionality. Provides information about permissions, superusers, and security, including examples of security on Windows NT platforms running AutoSys. Describes AutoSys job types and provides information about basic job attributes, starting parameters, and job states. Describes the various attributes used to define jobs in AutoSys. It also discusses essential and optional job attributes, which govern what a job does and when and where it will run.
AutoSys Security
AutoSys Jobs
Job Attributes
xvii s
s Preface
About This Guide
Ch. No. Chapter Name 5
Content Description
Box Job Logic
Explains how Box Jobs work, including default box behavior and how to override the default behavior. It also explains what types of jobs should and should not be placed in a box. To illustrate box logic, numerous examples of Box Jobs are provided. Describes how to use the AutoSys Graphical User Interface (GUI). Describes how to use the Job Editor to define a simple Command Job, a File Watcher Job, and a dependent Command Job. It describes defining AutoSys Box Jobs, as well as changing and deleting a job. It also explains how to set time dependencies. Describes how to use the AutoSys Job Information Language or JIL to define a simple Command Job, a File Watcher Job, and a dependent Command Job. It describes defining AutoSys boxes, as well as changing and deleting a job. Also provides an example JIL script. Describes the AutoSys Calendar Editor and how to use it to create, view, and maintain AutoSys calendars. It also describes how to access and use the various features of the Calendar Editor, such as previewing a calendar before applying its dates and applying customized rules to a calendar.
6 7
Introduction to the Graphical User Interface Defining AutoSys Jobs using the Job Editor
Defining Jobs Using JIL
Calendar Editor
s xviii
Preface s About This Guide
Ch. No. Chapter Name 10
Content Description
Load Balancing and Queuing Jobs
Describes the use of real and virtual machines in the AutoSys environment. It also provides information about load balancing jobs across multiple machines, as well as queueing jobs to real and virtual machines. Describes the Scheduler Console and how to monitor and control job activity for multiple AutoSys instances in real-time. It also describes how to review and report on any AutoSys job. Describes how to view and manage AutoSys alarms using the Alarm Sentry and Alarm Manager. Describes how to use the Monitor/Browser Editor or JIL to define AutoSys monitors and browsers (reports) using essential and optional monitor and browser attributes. Describes basic AutoSys maintenance and how to maintain a bundled Sybase database. Describes the default AutoSys configuration settings and other attributes that you can modify by using the AutoSys Administrator. Provides useful information about troubleshooting the primary AutoSys components.
11
Scheduler Console
12
Managing Alarms
13
Monitoring and Reporting on Jobs
14
Maintaining AutoSys
15
AutoSys Administrator
16
Troubleshooting
xix s
s Preface
Whats New
Ch. No. Chapter Name A
Content Description
Integrating AutoSys with Zeke and AutoSys/Team Agent Index
Explains how to set up and implement these enterprise-wide scheduling with AutoSys, Zeke, and Team Agent components. Helps you locate information within this manual.
Whats New
PLATINUM AutoSys Version 3.4 offers all the functions available in Version 3.3, plus the new features in this section.
Native Windows NT GUIs with Multiple Instance Support

This AutoSys release uses all native Windows NT Graphical User Interfaces (GUIs). With these GUIs you can access multiple AutoSys Instances to define jobs, calendars, monitors, and browsers (reports), and you can view the job run activity and alarms for multiple instances. The redesign of the GUIs resulted in changes to the names and locations of some GUI components. For more information, see the AutoSys User Guide for Windows NT.
Year 2000 Support

The AutoSys 3.4.2 GUIs and command-line interfaces now support the specification and display of four-digit years. If you enter a two-digit year, AutoSys saves the setting to the database as a four-digit year using a date window rule. If you enter 79 or less, AutoSys prepends 20, and if you enter 80 or greater, AutoSys prepends 19. That is, if you enter 79, it becomes 2079, and if you enter 80, it becomes 1980.
s xx
Preface s Whats New
Note On Windows NT, the AutoSys GUIs display the date according to the setting for the local machine. If you want the AutoSys GUIs to display four-digit years, you must set your machine to do so. To change the date setting on Windows NT 3.51, go to Control Panel, open the International dialog, and change the Date Format setting. To change the setting on Windows NT 4.0, go to Control Panel, open the Regional Settings dialog, and change the setting on the Date tab.
PLATINUM ProVision Common Services Integration

You can enable AutoSys to send events to the PLATINUM Event Manager and Data Exchange. If enabled, AutoSys will send events for every AutoSys job to the Event Manger. If you have installed the PLATINUM ProVision common services, you can view these events with the PLATINUM Director. Enabling Data Exchange instructs AutoSys to write job definition and job history information to the POEMS common services repository.
Reporting using InfoReports

AutoSys bundles an InfoReports Viewer and a number of reports with details on AutoSys jobs that you can view using the InfoReports GUI. Access these reports by defining and clicking on one of the user defined buttons in the Scheduler Console. The following types of reports are available: Job List This report allows you to select the list of jobs to be reported on, or report on all jobs in the database. Job Find This report allows you to enter a pattern for the job name and report on all jobs that match the pattern.
xxi s
s Preface
Whats New
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.
Security Enhancements
These are the enhancements to AutoSys security:
s
You can now enter NT user IDs and passwords from either a UNIX or an NT machine, using autosys_secure. The autosys_secure utility now accepts NULL for an NT user password. You can now run autosys_secure in command-line mode.
Event Processor Enhancements

These are the enhancements to Event Processor behavior:
s
If you configure AutoSys to run in Dual Server mode, the Event Processor will not start unless both databases are available. The Event Processor will shut down if insufficient disk space is available to write the to the Event Processor log file. A new field, FileSystem Threshold, was added to the AutoSys Administrator Event Processor screen. This setting specifies the minimum amount of disk space that must be available, or the Event Processor will issue a warning. The default setting is 32 kilobytes. If the disk space drops below 8 kilobytes, the Event Processor will shut down.
s xxii
Preface s Whats New
On NT, you can also use the setting on the Remote Agent machines to keep track of the amount of space available for the Remote Agent log file.
AutoSys Administrator Enhancements

The AutoSys Administrator System Information screen changed, and there are new fields on the Event Processor screen. The AutoSys Administrator System Information screen now displays only AutoSys-specific environment variables; Windows NT System variables no longer appear on this screen. The environment variables that appear on the screen are the ones that are set for AutoSys processes, and they are the ones set in the AutoSys Instance Command Prompt window. With the new System Information screen, you now have the ability to add environment variables to be set for AutoSys. These new fields were added to the AutoSys Administrator Event Processor screen:
s s s
Append stdout/stderr FileSystem Threshold Enable Poems
Append stdout/stderr
This setting specifies whether to overwrite or append to standard error and standard output files.
FileSystem Threshold
This setting specifies the minimum amount of disk space that must be available, or the Event Processor will issue a warning. If the disk space drops below 8 kilobytes, the Event Processor will shut down.
xxiii s
s Preface
Whats New
Enable Poems
This setting enables AutoSys to communicate with PLATINUM Event Management and Data Exchange.
Time Zone Setting

Jobs with time-based starting conditions that do not specify a time zone are scheduled to start based on the time zone under which the Event Processor runs. This time zone is also used to report event times with the autorep command. Before you start the Event Processor, ensure that the correct time zone is specified in the NT Control Panel Date/Time dialog. The Event Processor references this setting to determine the default time zone.
Set Append or Overwrite Behavior for Standard Files

You can now configure AutoSys to either overwrite or append to standard error and standard output files. You control this behavior for each AutoSys instance by setting the Append stdout/stderr field in the AutoSys Administrator Event Processor screen. You can override the instance-wide setting for individual client machines (Remote Agents) by setting the AutoMachWideAppend variable on the AutoSys Administrator System Information screen. You can also set a behavior for a specific job by placing special notation as the first character in the standard error or standard output specification.
Expanded Number of Entries in config.EXTERNAL File

The config.EXTERNAL file can contain up to 249 entries. You use this file to implement cross-instance job dependencies within AutoSys, and to implement cross-platform dependencies for AutoSys Zeke and Team Agent integration.
s xxiv
Preface s Conventions
AutoSys Command Changes

There are changes to the following AutoSys commands:
s autosyslog s autosys_secure
autosyslog
The autolog command has been renamed to autosyslog.
autosys_secure
The autosecure command has been renamed to autosys_secure. In addition, security enhancements (discussed above) were added to facilitate security administration from both UNIX and Windows NT platforms.
Conventions
Some or all of the following conventions appear in this guide:
Symbol or Type Style Represents Example
Bold alternate color
a new term
...called a source object.
(online only) hotlinked ...see Chapter 3, Data cross-references to other Migration. sections in this guide; if you are viewing this guide online in PDF format, you can click the cross-reference to jump directly to its location
xxv s
s Preface
Conventions
Symbol or Type Style
Represents
Example
Italic
words that are emphasized
...the entry after the current entry...
the titles of other documents PLATINUM General Applications Guide syntax variables
Monospace
COPY filename
&HIGHLVL.SRCLIB directories, file names, command names, computer code
computer screen text, system Copy file? Y/N responses, command line commands
Monospace bold
what a user types the name of a key on the keyboard
...enter RUN APP.EXE in the Application field Press <Enter>.
<>
choosing a command from a File Import Object cascading menu
s xxvi
Preface s Related Publications
Related Publications
As you use this PLATINUM AutoSys User Guide for Windows NT, you might find it helpful to have these additional books available for reference:
s
Release Notes: AutoSys version 3.4 for Windows NT, which provides important information about this release. Please read this before proceeding. AutoSys Installation and Getting Started Guide for Windows NT, 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 Windows NT, which lists the AutoSys commands and job, machine, monitor, and report definition parameters. It also describes system states and the API. AutoSys Help, which provides help for many of the AutoSys interface components. You can launch the AutoSys Help from your NT program group.
xxvii s
s Preface
Related Publications
s xxviii
1
Introduction to AutoSys
AutoSys is an automated job control system for scheduling, monitoring, and reporting. These jobs can reside on any AutoSys-configured machine that is attached to a network. An AutoSys job is any single command, executable, script, or NT batch file. Each AutoSys job definition contains a variety of qualifying attributes, including the conditions specifying when and where a job should be run. 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. However, before you install and use AutoSys, it is important to understand the basic AutoSys system, its components, and how these components work together. This chapter provides a brief overview of AutoSys, its system architecture, and features.
AutoSys Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3 Defining Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
1-1 s
s Introduction to AutoSys
System Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4 Event Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5 Event Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6 Remote Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7 Example Scenario on Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7 Interface Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9 AutoSys Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10 AutoSys Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11 Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11 Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12 Basic AutoSys Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13 Explanation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-14 Extending AutoSys Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15
s 1-2
Introduction to AutoSys s AutoSys Jobs
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. For information on defining, running, managing, monitoring, and reporting on jobs, see the chapters in this guide.
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:
s s
Using the AutoSys Graphical User Interface (GUI). Using the AutoSys Job Information Language (JIL) through a command-line interface.
AutoSys Graphical User Interface

The AutoSys GUI allows you to interactively set the attributes that describe when, where, and how a job should run. You create job definitions using the GUI Control Panel and the dialogs you can launch from it. The fields in the GUIs correspond to the AutoSys JIL sub-commands and attributes. In addition, from the GUI Control Panel, you can open applications that allow you to define calendars, monitors, and reports, and that allow you to monitor and manage AutoSys jobs.
Job Information Language

AutoSys JIL is a specification language, with its own syntax, that is used to describe when, where, and how a job should run. When you enter the jil command, you get the jil command prompt, at which you can enter the job definitions one line at a time using this special language. When
1-3 s
System Components
you exit JIL, the job definition is loaded into the AutoSys database. Alternatively, you can enter the definition as a text file and re-direct the file to the jil command. In this case, the jil command activates the language processor, interprets the information in the text file, and loads this information in the AutoSys database.
System Components
The following are the main AutoSys system components:
s s s
Event Server (AutoSys database) Event Processor Remote Agent
In addition, AutoSys provides utilities to help you define, run, and maintain AutoSys instances and jobs. The included utilities are platformspecific; however, all platforms include the AutoSys GUI components and JIL. Both the GUI and JIL allow you to define, manage, monitor, and report on jobs. Figure 1-1 illustrates the AutoSys system components in a basic configuration. In addition, this figure illustrates the communication paths between the components.
s 1-4
Introduction to AutoSys s System Components
AutoSys Server (UNIX or NT)
UNIX Client Remote Agent
Event Processor UNIX Job NT Client Remote Agent Event Server (database) NT Job
Figure 1-1 AutoSys Components in a Basic Configuration
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. Occasionally, the database is called a dataserver, which actually describes a server instance. That is, it is either a UNIX or Windows NT process, and it is associated data space (or raw disk storage), which can include multiple databases or tablespaces.
Note The AutoSys database refers to the specific server instance and the autosys database for that instance. Some utilities, such as isql (Sybase) and ISQL/w (Microsoft SQL Server), allow you to specify a particular server and database.
1-5 s
System Components
High Availability Option - Dual Event Servers

AutoSys can be configured to run using two databases, or Dual Event Servers. This feature provides complete redundancy. Therefore, if you lose one Event Server due to hardware, software, or network problems, AutoSys operations can continue on the second Event Server without loss of information or functionality. For various reasons, database users often run multiple instances of servers that are unaware of the other servers on the network. When implementing AutoSys, the database can run stand-alone for AutoSys only, or it can be shared with other applications. 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 Windows NT.
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. Based on this information, the Event Processor first determines what actions are to be taken, then instructs the appropriate Remote Agent process to perform the actions. These actions might be the starting or stopping of jobs, checking for resources, monitoring existing jobs, or initiating corrective procedures.
High Availability Option - Shadow Event Processor

AutoSys lets you set up a second Event Processor, called the Shadow Event Processor. This second processor should run on a separate machine to avoid a single point of failure.
s 1-6
The Shadow Event Processor remains in an idle mode, receiving periodic messages (pings) from the Primary Event Processor. Basically, these messages indicate that all is well. However, if the Primary Event Processor fails for some reason, the Shadow Event Processor will take over the responsibility of interpreting and processing events. For more information on running a Shadow Event Processor, see Shadow Event Processor in Chapter 1, Introduction to AutoSys, of the AutoSys Installation and Getting Started Guide for Windows NT.
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.
Example Scenario on Windows NT

The example scenario in Figure 1-2 and the numbered explanations that follow it illustrate the interactions between the Event Server, the Event Processor, and Remote Agents. In the example, the following Windows NT command line is to be run on WorkStation_2, at the start date and time specified in the AutoSys job definition:
del C:\tmp\*.*
1-7 s
System Components
Note Understanding this example will help you answer many
questions that might arise during your experiences with AutoSys.

PROCESS Remote Agent
Receives instructions from Event Processor
PROCESS Event Processor
Determines Actions Initiates Action: Start job on machine command: del C:\tmp\*.*
Initiates Action: Starts Process Waits for Exit Code (from Process) Sends Exit event back to Event Server
PROCESS Event Server

Events Job Definitions
5
WorkStation_2
PROCESS NT Command
4
Local Area Network
Runs NT Command: del C:\tmp\*.* Completes execution and exits with status
Figure 1-2 Interaction of the Event Server, Event Processor, and Remote Agent
Note In the example above, the three primary components are shown running on different machines. Typically, the Event Processor and the Event Server run on the same machine.
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
s 1-8
from the database and, based on that definition, determines what action to take. In the example, it runs the del C:\tmp\*.* command on WorkStation_2.
2 The Event Processor communicates with the Remote Agent on
WorkStation_2. As soon as the Remote Agent receives the instructions from the Event Processor, the connection between the two processes is dropped. After the connection is dropped, the job will run to completion, even if the Event Processor stops running.
3 The Remote Agent performs resource checks, such as ensuring that the
minimum specified number of processes are available, then creates a process that will actually run the specified command.
4 The command completes and exits, and the Remote Agent captures
the commands 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.
Interface Components
To define, monitor, and report on jobs, you can use either the AutoSys GUI or AutoSys JIL. In addition, the Scheduler 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 Windows NT. AutoSys also provides the AutoSys Administrator, which allows you to set AutoSys configuration parameters, and the Job Profiles Manager, which allows you to set up job environment variables, or profiles, to associate with jobs within their definitions. For information on interface components and defining and monitoring AutoSys jobs, see the chapters in this guide.
1-9 s
AutoSys Machines
AutoSys Machines
From a hardware perspective, the AutoSys architecture is composed of the following two types of machines attached to a network: Server Machine The AutoSys server is the machine on which the Event Processor and/or the Event Server (database) reside. In a basic configuration, both the Event Processor and the Event Server reside on the same machine. Client Machine The AutoSys client is the machine on which the Remote Agent software resides, and where AutoSys jobs are to be run. A Remote Agent must be installed on the server machine, and it can also be installed on separate physical client machines.
AutoSys Instance
An AutoSys instance is one licensed version of AutoSys software running as an AutoSys server with one or more clients, on a single machine or on multiple machines. An AutoSys instance is defined by the instance ID, which is a capitalized three-letter identifier defined by the AUTOSERV environment variable. An instance uses its own Event Server and Event Processor and operates independently of other AutoSys instances. 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.
s 1-10
Introduction to AutoSys s Events
Events
AutoSys is completely event-driven; that is, for a job to be activated by the Event Processor, an event must occur on which the job depends. For example, a prerequisite job has completed running successfully or a required file has been received. Events can come from a number of sources, including the following:
s s s
Jobs changing states, such as starting, finishing successfully, etc. Internal AutoSys verification agents, such as detected errors. Events sent with the sendevent command, sent from the Send Event Tool, 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 jobs 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
Alarms are special events that notify operations personnel of situations requiring their attention. Alarms are integral to the automated use of AutoSys. That is, jobs can be scheduled to run based on a number of conditions, but some facility is necessary for addressing incidents that require manual intervention. For example, a set of jobs could be dependent on the arrival of a file, and the file is long overdue. It is important that someone investigate the situation, make a decision, and resolve the problem.
1-11 s
Utilities
These are some important aspects of alarms:

s
Alarms are informational only. Any action to be taken due to a problem is initiated by a separate action event. Alarms are system messages about a detected problem. Alarms are sent through the system as an event.
s s
Alarms have special monitoring features to ensure they will be noticed. For more information about these features, see Chapter 11, Scheduler Console, Chapter 12, Managing Alarms, and Chapter 13, Monitoring and Reporting on Jobs.
Utilities
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. AutoSys also provides a set of commands that run essential utility programs for defining, controlling, and reporting on jobs. For example, the autorep command allows you to generate a variety of reports about job execution, and the sendevent command allows you to manually control job processing. Additional utility programs are provided to assist you in troubleshooting, running monitors and browsers, and starting and stopping AutoSys and its components. AutoSys also provides a database maintenance utility that runs daily by default.
s 1-12
Introduction to AutoSys s Basic AutoSys Functionality
Basic AutoSys Functionality

The diagram in Figure 1-3 and the numbered explanations that follow it illustrate how AutoSys performs its most basic functionstarting a job (i.e., executing a command) on a client machine. Working through this example will be very helpful for understanding how AutoSys processes jobs.
Note In Figure 1-3, the major AutoSys components are shown as
separate entities. Typically, the Event Processor and the AutoSys Event Server are installed on the same server machine (along with a required Remote Agent), and other Remote Agents are installed on separate client machines.
Event Processor
5 AutoSys Client
Event Server (Database)
agent connect
4 7
Remote Agent
6
Client Job
Figure 1-3 Basic AutoSys Functionality
1-13 s
Basic AutoSys Functionality
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 5 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.
3 The Event Processor processes the event. If the event is a STARTJOB,
the Event Processor attempts to establish a connection with the Remote Agent on the client machine, and passes the job attributes to the client machine. The Event Processor sends a CHANGE_STATUS event marking in the Event Server that the job is in STARTING state.
4 On a UNIX machine, the inetd invokes the Remote Agent. On a
Windows NT machine, the Remote Agent logs onto the machine as the user defined as the jobs owner, using the user ID(s) and password(s) passed to it from the Event Processor.
5 The Remote Agent sends an acknowledgment back to the Event
Processor indicating that it has received the job parameters. The socket connection is terminated. At this point, the Event Processor resumes scanning the Event Server database, looking for events to process.
6 The Remote Agent starts a process and executes the command in the
job definition.
7 The Remote Agent issues a CHANGE_STATUS event marking in the
Event Server that the job is in RUNNING state.

8 The client job process runs to completion, then returns an exit code to
the Remote Agent and quits.
s 1-14
Introduction to AutoSys s Extending AutoSys Functionality
9 The Remote Agent sends the Event Server a CHANGE_STATUS event
corresponding to the completion status of the job and passes back an exit code, using the communications facilities of the database. 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 Remote Agent quits. 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.
Extending AutoSys Functionality

You can extend AutoSys with the AutoSys Zeke/Team Agent Integration components in order to integrate AutoSys jobs with Zeke and the AutoSys/Team Agent product from PLATINUMs Altai Development Lab. Using cross-platform job dependency notation, you can define AutoSys jobs to conditionally start based on the status of a Zeke job running on a mainframe, and you can define Zeke jobs to conditionally start based on the status of an AutoSys job. You can also define AutoSys jobs that will run on a Team Agent machine, if the Team Agent machine is defined to AutoSys. In addition, you can install various AutoSys/Adapters. The applicationspecific Adapters allow you to initiate, control, and report on the status of jobs related to an application using the sophisticated job scheduling capabilities of AutoSys. Contact your PLATINUM sales representative for information on supported Adapters.
1-15 s
Extending AutoSys Functionality
Figure 1-4 illustrates an extended AutoSys configuration that includes the AutoSys Zeke/Team Agent Integration components and an AutoSys/Adapter installation on a UNIX client.
AutoSys Server (UNIX or NT)
UNIX Client
UNIX Job Remote Agent
NT Client
Remote Agent
Event Server (database) NT Job
AutoSys/Adapter
Event Processor
Application oasis-broker
Mainframe (MVS)
OASIS Zeke/Team Agent Communicator
Other OS (e.g., AS/400)

Team Agent
Zeke
MVS Job Job
Figure 1-4 AutoSys Components in an Extended Configuration
For more information, contact your sales representative.
s 1-16
2
AutoSys Security
This chapter describes AutoSys security. To set up AutoSys correctly, you should understand the security features that control where and by whom a job can be edited or executed. If you are installing AutoSys on both UNIX and NT, you must understand how security is implemented on both systems. For information about AutoSys security on UNIX, see the AutoSys Security chapter in the AutoSys User Guide for UNIX.
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-7 AutoSys Database Field Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8 Job Definition Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8 Remote Agent Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8 AutoSys User and Database Administrator Passwords . . . . . . . . . . . . . . . . . . 2-10 AutoSys Job-Level Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10 AutoSys Job Ownership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11 AutoSys User Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
2-1 s
s AutoSys Security
AutoSys Permission Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-12 Job Permissions and Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-13 AutoSys Superuser Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14 Edit Superuser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-14 Exec Superuser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-15 Restricting Access to AutoSys Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15 Remote Agent Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-17 AutoSys Security and Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17 Defining Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-18 Starting Jobs Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-20 Running Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-21 Examples of AutoSys Security on Windows NT . . . . . . . . . . . . . . . . . . . . . . . .2-23
s 2-2
AutoSys Security s Overview
Overview
AutoSys security includes:
s s s s
System-level security. See System-Level Security on page 2-7. Job-level security. See AutoSys Job-Level Security on page 2-10. Superuser privileges. See AutoSys Superuser Privileges on page 2-14. UNIX and NT file permissions. See Restricting Access to AutoSys Jobs on page 2-15.
In addition, there are Windows NT-specific security considerations. For information, see AutoSys Security and Windows NT on page 2-17 and Examples of AutoSys Security on Windows NT on page 2-23. 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.
Security on Events Sent by Users

By using the sendevent command or the Send Event Tool, you can send execute events that affect the running of a job. These are the execute events that you can send, if you have the appropriate permissions: STARTJOB KILLJOB CHANGE_STATUS JOB_ON_HOLD JOB_ON_ICE SEND_SIGNAL If you start a job by sending an event, the job permissions are checked as shown in Figure 2-1. FORCE_STARTJOB DELETEJOB CHANGE_PRIORITY JOB_OFF_HOLD JOB_OFF_ICE
2-3 s
s AutoSys Security
Overview
Figure 2-1 Security when a user starts a job by sending an event
s 2-4
AutoSys Security s Overview
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? 3 Is the user the Exec Superuser as defined with autosys_secure? 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?
Security on Events Sent by the Event Processor

In addition to sending execute events on jobs, you can schedule jobs to start at certain times or under certain conditions. When a job is scheduled to start automatically, permissions are checked on the Remote Agent machine on which the job is to run. 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 and also passes the Remote Agent two encrypted user IDs and passwords: one for the job owner, user@host_or_domain, and one for user@machine. The Remote Agent will use these IDs and passwords to log onto the machine where the job will run. The Event Processor passes a null value for user IDs and passwords that it cannot locate in the database. Figure 2-2 shows the permissions and security checks that occur on a Windows NT machine before a job is allowed to start on the machine.
2-5 s
s AutoSys Security
Overview
Figure 2-2 Security when an Event Processor starts a job on an NT client machine
s 2-6
AutoSys Security s System-Level Security
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-8).
Figure 2-2 shows how AutoSys checks for the following when the Event Processor sends a STARTJOB event to a Remote Agent machine:
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 Checks the DES encrypted job definition to determine if the Event
Processor can connect to the Remote Agent machine.

3 Does the user who is defined as the job owner (user@host_or_domain)
have a user account on the Remote Agent machine? If not, does the user defined as user@machine have a user account on the Remote Agent machine?
4 If user authentication is enabled, is the user (user@machine) a Trusted
User (as defined on the AutoSys Administrator Security screen)?

5 If Event Processor authentication is enabled, does the requesting
Event Processor have permission to run jobs on this Remote Agent machine?
Note The Edit Superuser can enable remote authentication by using the autosys_secure utility.
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:
s s
AutoSys database field verification Job definition encryption
2-7 s
s AutoSys Security
System-Level Security
s s
Remote Agent authentication AutoSys user and database administrator passwords
AutoSys Database Field Verification

To secure the database, AutoSys not only encrypts some fields specified in a job definition, but also generates a checksum from fields in the job definition, and stores the checksum in the AutoSys database. Whenever a job is accessed, its checksum is regenerated and compared to the one in the database. If the checksums are different, this indicates that someone tampered with the job definition in the database, probably by using an SQL command. In this case, the job is disabled and cannot be executed. 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 Editor.
Job Definition Encryption

To secure the Remote Agent from unauthorized access, the Event Processor encrypts the information in a job definition sent over the socket to the Remote Agent. The Remote Agent then decrypts the job information and continues to process the job. If the Remote Agent receives any job information from the Event Processor that it does not recognize, it issues an error message and will not process the job. This encrypted information includes the two NT user IDs and passwords that the Remote Agent uses to log onto the machine where the job will run.
Remote Agent Authentication

AutoSys provides two Remote Agent authentication methods:
s s
User authentication Event Processor authentication
s 2-8
AutoSys Security s System-Level Security
By default, both user authentication and Event Processor authentication are disabled. The Edit Superuser must enable them by using the autosys_secure command.
User Authentication
When user authentication is enabled, the Remote Agent verifies that a job owner, defined as user@machine, is registered (on the Trusted Hosts and Trusted Users lists) on the client machine where the job will run. Being registered gives the owner permission to access and run jobs on that client machine. User authentication is used only when the Remote Agent fails to log on as the owner, user@host_or_domain, and then tries to log on as the user defined as user@machine. For information on setting the Trusted Hosts and Users, see AutoSys Administrator Security Screen in Chapter 15, AutoSys Administrator. For information on enabling user authentication, see autosys_secure in Chapter 1, AutoSys Commands, of the AutoSys Reference Guide for Windows NT.
Event Processor Authentication

When Event Processor authentication is enabled, the Remote Agent verifies that it has permission to process requests from the requesting Event Processor before starting each job. It does this by checking a list of authorized Event Processor hostnames. For information on setting the Event Processors that have permission to start processes on a Remote Agent, see AutoSys Administrator Remote Agent Screen in Chapter 15, AutoSys Administrator. For information on enabling Event Processor authentication, see autosys_secure in Chapter 1, AutoSys Commands, of the AutoSys Reference Guide for Windows NT.
Note Before enabling Event Processor authentication, you must specify the authorized Event Processor hostnames in the AutoSys Administrator Remote Agent screen.
2-9 s
s AutoSys Security
AutoSys Job-Level Security
AutoSys User and Database Administrator Passwords

When you install AutoSys and configure your database, an autosys user is added to the database with a password set to autosys. The autosys user is the owner of the AutoSys database and can make changes to AutoSys-specific information in the database. To enhance system security, we recommend that you change the autosys user password with the autosys_secure command. 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. For information on changing the autosys user password see autosys_secure, and for information on changing the sa password and querying the database, see xql in Chapter 1, AutoSys Commands, of the AutoSys Reference Guide for Windows NT.

The AutoSys security scheme provides individuals and groups of users with edit and execute permissions on a job-by-job basis. For jobs running on UNIX, AutoSys supports owner, group, and world edit and execute permissions. For jobs running on NT, AutoSys supports owner and world edit and execute permissions. 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.
s 2-10
AutoSys Security s AutoSys Job-Level Security
AutoSys Job Ownership

By default, the owner of an AutoSys job is the user who defines that job on a particular machine. When a user defines a job on NT, AutoSys defines the owner in the owner job attribute as user@host_or_domain. By default, only the owner can edit and execute the job.
Note In the case of job ownership, AutoSys treats NT domains as a type of machine. A user logged onto a domain will have an owner definition of user@domain, where domain is the domain name.
The user@host_or_domain combination must have execute permission for any command specified in a job on the machine where the job command is to run. The job owner must also have permission to access any device, resource, etc. that the command needs to access. For this process to work, the job owner must have the appropriate system permissions. When a job is run on a machine, it is run as the user specified by the owner attribute. If the job is run on a UNIX machine, the uid of the resulting process is changed to that of the specified user. If a job is run on an NT client machine, the Edit Superuser must have entered the valid NT user ID and password for the owner into the AutoSys database. For more information about the Edit Superuser, see Edit Superuser on page 2-14.
AutoSys User Types

A job definition includes the users who can edit and execute that job on the machine where it was created. AutoSys supports the following types of users for any job:
s Owner. s World.
The user who created the job. All users.
2-11 s
s AutoSys Security
Note AutoSys also supports UNIX groups for jobs that will run on
UNIX machines. 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).
AutoSys Permission Types

By default, only the owner has edit and execute permissions on a job, and all edit and execute permissions are valid only on the machine on which the job was defined. However, the owner can grant different types of permissions when defining a job. The following permissions are supported:
s Edit.
Users can edit, override, or delete a job definition.
s Execute.
Users can send an execute event that affects the running of a job by using the sendevent command or the Send Event Tool. For a list of the execute events that users can send, see Security on Events Sent by Users on page 2-3. Users logged onto a machine other than the one on which a job was created can edit or execute the job.
s Machine.
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.
s 2-12
AutoSys Security s AutoSys Job-Level Security
The following table shows the permissions that you can set by using JIL or the Permissions settings on the Job Editor Misc tab.
GUI JIL Meaning
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@host_or_domain). 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@host_or_domain). 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@host_or_domain). 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@host_or_domain).
All Hosts Edit
me
World Execute
wx
World Edit
we
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.
Job Permissions and Windows NT

If you are defining jobs and running them on different operating systems, keep the following in mind:
s
When defining a job to run on an NT machine, you can set group permissions, but they will be ignored. Group permissions will be used if a job is edited or executed on a UNIX machine.
2-13 s
s AutoSys Security
AutoSys Superuser Privileges
When editing a job from an NT machine, the group edit permission is ignored. In this case, the user editing the job must be the owner of the job, or World Edit permissions must be specified for the job. When executing a job from an NT machine, the group execute permission is ignored. In this case, the user executing the job must be the owner of the job, or World Execute permissions must be specified for the job.
AutoSys Superuser Privileges

AutoSys recognizes two users with Superuser privileges: the Edit Superuser and the Exec Superuser. You can define these Superusers by using the autosys_secure command. For information about defining the Edit and Exec Superusers, see Chapter 8, Adding the AutoSys Superusers and the NT User IDs and Passwords, in the AutoSys Installation and Getting Started Guide for Windows NT.
Edit Superuser
Only the Edit Superuser has permission to:
s s s
Edit or delete any job regardless of its owner or its permissions. Change the owner attribute of a job. Change the AutoSys database password, change the remote authentication method, and add and change NT user IDs and passwords by using the autosys_secure command.
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
s 2-14
AutoSys Security s Restricting Access to AutoSys Jobs
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.
Exec Superuser
Only the Exec Superuser has permission to:
s
Issue commands that affect the running or the state of any AutoSys job, either using the sendevent command or the Send Event Tool. Stop the Event Processor by issuing the following command:
sendevent -E STOP_DEMON
Note Exec Superuser privileges are usually granted to the night
operator.
Restricting Access to AutoSys Jobs

If you are using NTFS (NT File System), you can use NT file permissions on many AutoSys files to control which users can view jobs, execute jobs, edit jobs, and change calendars. First, you must ensure that only authorized users can change permissions on the files and directories in the AutoSys directory structure.
2-15 s
s AutoSys Security
Restricting Access to AutoSys Jobs
Then, you should determine what level of security you want, for example:
s
Only authorized users can use AutoSys.

Or
Any user can view jobs and reports about jobs, such as using autorep to see the status of a job, but only authorized users can create jobs and calendars or make changes to them.
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.
archive_events.exe autocal.exe autocal_asc.exe autocons.exe* autosysadmin.exe autosys_secure.exe autotimezone.exe clean_files.exe dbmaint.bat dbspace.exe dbstatistics.exe gatekeeper.exe hostscape.exe* jil.exe jobdef.exe jobdetail.exe* jobprofiles.exe jobscape.exe* sendevent.exe sendeventgui.exe svarchive.exe svload.exe timescape.exe* uninstal.exe xql.exe zql.exe
s 2-16
AutoSys Security s AutoSys Security and Windows NT
Note An asterisk (*) indicates files that can be executable by all users as long as sendevent.exe and jil.exe are not executable. This allows users to run simulations and use the GUI to view jobs without being able to start or create jobs.
To make the job of maintaining permissions easier, you could create an AutoSys group. In that group include the users who are allowed to create and change jobs and calendars. Then, change the file permissions on the AutoSys directory structure so that only members of the AutoSys group can execute the files. To set NT file permissions
1 Click the %AUTOSYS%\bin directory. 2 Click the right mouse button to display the popup menu. 3 Select the Properties option. 4 Use the Security tab to set the appropriate permissions.
Remote Agent Security

A Remote Agent on a UNIX machine can be configured for additional security. By adding user logons to a list called the DENY_ACCESS list, you prohibit those users from running jobs on that machine. If you define a job on an NT machine that will run on a UNIX machine, be sure the job owner is not on the DENY_ACCESS list for the Remote Agent on that UNIX machine. For more information, see Client-Side Security in Chapter 13, Configuring AutoSys of the AutoSys User Guide for UNIX.
AutoSys Security and Windows NT

When you create AutoSys jobs, you define certain job attributes that will affect security when those jobs are started and run. AutoSys defines the owner of the job, which also affects security.
2-17 s
s AutoSys Security
All users who will define and start jobs must have their NT user IDs and passwords in the AutoSys database. The Edit Superuser enters NT user IDs and passwords by using the autosys_secure command. Like other Windows NT applications, AutoSys must work within the standard NT security model. This includes the concepts of domains, hosts, logons, and passwords. To start a job on a machine, the Remote Agent logs onto that machine as the owner of the job, and then runs the job as the same user as the owner. To do this, the Event Processor passes the Remote Agent two encrypted user IDs and passwords: one for the job owner, user@host_or_domain, and one for user@machine. The Event Processor passes a null value for user IDs and passwords that it cannot locate in the database. You can enable Remote Agent user authentication so that the second user logon (user@machine) is checked against the lists of Trusted Hosts and Trusted Users before the job is run. The Edit Superuser enables Remote Agent authentication and sets the Trusted Hosts and Trusted Users. For examples of how Remote Agent authentication works, see Examples of AutoSys Security on Windows NT on page 2-23. For details on using autosys_secure to add NT user IDs and passwords and to enable Remote Agent authentication, see the autosys_secure section in Chapter 1, AutoSys Commands, of the AutoSys Reference Guide for Windows NT. For information on setting the Trusted Hosts and Trusted Users, see AutoSys Administrator Security Screen in Chapter 15, AutoSys Administrator.
Defining Jobs
In a job definition, the owner, machine, and permission job attributes are part of AutoSys security. To view a job definition, you can open it in the Job Editor, or you can print it.
s 2-18
To print a job definition

Execute the following command at an AutoSys Instance Command Prompt:
autorep -J job_name -q
In the AutoSys GUI, the Owner field is located on the Job Editor Basic Scheduling tab. For more information on these attributes, see Chapter 2, JIL/GUI Job Definitions, in the AutoSys Reference Guide for Windows NT.
owner
The owner attribute is assigned automatically to the user who defines the job with either JIL or the Job Editor. The owner is in the form of user@host_or_domain, where user is the user who logged on, and host_or_domain is the local host or network domain that the user logged onto when defining the job. Only the AutoSys Edit Superuser can change the owner attribute.
Note The purpose of the user@host_or_domain form is to prevent users from running jobs on machines where they do not have the appropriate permission. For example, administrator@host_or_domain prevents administrator on any machine from running administrator jobs on all machines.
In the AutoSys GUI, the Owner field is located on the Job Editor Basic Scheduling tab.
machine
The machine attribute specifies the machine on which the job is to run. It must be an actual machine hostname, not a network domain name. It can also be a fully qualified DNS name. In the AutoSys GUI, the Send To Machine field is located on the Job Editor Basic Scheduling tab.
2-19 s
s AutoSys Security
permission
By default, only the owner of a job has edit and execute permissions on that job, and all edit and execute permissions are valid only on the machine on which the job was defined. The permission attribute extends edit and execute capabilities to other users in addition to the owner of the job. It also extends edit and execute capabilities to machines other than the machine on which the job was defined. AutoSys checks permissions only when a user other than the owner tries to edit or execute a job. In the AutoSys GUI, the Permissions settings are located on the Job Editor Misc tab.
Starting Jobs Manually

When you attempt to manually start a job, either from the AutoSys sendevent command or the Send Event Tool, AutoSys determines what user you are currently logged on as, and then determines if you have the needed permissions to start the job by doing the following (see Figure 2-1):
1 AutoSys compares the user@host_or_domain of the user logged onto the machine to the jobs owner attribute. If the user@host_or_domain is
identical to that of the job owner, AutoSys allows you to start the job; otherwise, AutoSys moves to the next step.
2 If the user portion is the same, but the host_or_domain portion is different, AutoSys checks the jobs permission attribute. If the job
permissions allow the job to be executed from machines other than the machine on which it was defined (permission: mx), then AutoSys allows you to start the job. Otherwise, AutoSys moves to the next step.
Or
s 2-20
If the user portion is different, but the host_or_domain portion is the same, then AutoSys checks the jobs permission attribute. If the job permissions allow the job to be executed by other users in addition to the user who created the job (permission: wx), then AutoSys allows you to start the job. Otherwise, AutoSys moves to the next step.
3 If both the user and host_or_domain portions are different, then AutoSys checks the jobs permission attribute. If the job permissions
allow the job to be executed by other users from other machines (permission: mx and wx), AutoSys sends the event to start the job. Otherwise, it does not send the event. If any one of these conditions is met, you are allowed to start the job, and AutoSys checks to see if it can run the job (as described in the next section). If these conditions are not met, then AutoSys does not allow you to start the job.
Running Jobs
After a job is started, either by a user as described in the previous section, or because it was scheduled to be started by the Event Processor, the following occurs:
1 The Event Processor establishes a connection with the Remote Agent on the machine specified by the jobs machine attribute. When doing
so, the Event Processor passes to the Remote Agent the encrypted passwords for two users:
The first is based on the owner of the job. The second is based on the user specified in the owner attribute at the host specified by the machine attribute.
For user IDs and passwords that it cannot find in the AutoSys database, the Event Processor passes a null value.
2-21 s
s AutoSys Security
2 The Remote Agent tries to log on as the user@host_or_domain specified by the jobs owner attribute by using the password from the Event
Processor. If the logon is successful, the Remote Agent runs the job. If the logon is not successful, it is probably due to one of the following:
The Event Processor did not find a password for the owner in the
AutoSys database. The Edit Superuser must enter NT user IDs and passwords into the AutoSys database for all NT users on all hosts and domains where jobs will be run.
The password entered for the owner is incorrect in the AutoSys
database.
The host_or_domain portion of the owner attribute is a local or
network domain that does not have access to the machine where the job is run. If the host_or_domain portion of the owner is a local domain (hostname), and the hostname specified by the machine attribute is a different local domain, the host of the owner cannot access it.
Note If the host_or_domain of the owner is a network domain, and the machine hostname is a member of that network domain, the domain of the owner should be accessible. The AutoSys Edit Superuser changed the jobs owner attribute to
user (omitting the @host_or_domain portion). The NT user ID and password entered in the AutoSys database is associated with the owner defined as user@host_or_domain. If the logon is not successful, the Remote Agent moves to the next step.
3 The Remote Agent attempts to log on again. This time, the Remote Agent uses the user specified by the owner attribute attached to the host specified by the machine attribute (using the user@host format).
Remote Agent user authentication it is used at this time (if enabled).
s 2-22
If user authentication is successful or not enabled, the Remote Agent uses the password for this user passed from the Event Processor to log on. If the logon is successful, AutoSys runs the job. If the logon is not successful, AutoSys fails to start the job, and the Event Processor issues a STARTJOBFAIL alarm.
Notes
When running jobs on NT, keep the following in mind:
s
For a job to run on NT, the job owner must have the appropriate operating system permissions. The user who logs on to run the job (user@host_or_domain or user@machine) must have execute permission for any command specified in a job on the machine where the job command is to run. The user must also have permission to access any device, resource, etc. that the command needs to access. For jobs to run on the primary domain controller in an NT domain, the job owner must be of the form user@domain; user@host will not work. On NT, you must actually log onto the domain to log onto the domain controller machine; you cannot log onto the local host. Therefore, the job owner for jobs that will run on the domain controller should be defined as user@domain so that the Remote Agent will be able to log onto the machine.
Examples of AutoSys Security on Windows NT

The Remote Agent must log onto a machine before it runs a job. Whether it can log on is based on the job attribute settings and the AutoSys configuration. This section contains these example logon procedures:
s Example One. Describes
the procedure for a job defined on a machine to run on the same machine. Describes the procedure for a job defined outside of the network domain to run on a machine in the domain.
s Example Two.
2-23 s
s AutoSys Security
s Example Three. Describes the procedure for a job defined in the network
domain to run on a machine outside of the domain.

s Example Four.
Describes the procedure for a job defined to run on the primary domain controller.
The examples are based on the network shown in Figure 2-3.

Primary Controller for westcoast Domain oakland NT Server westcoast Domain NT Workstation seattle NT Workstation portland
boston
atlanta
NT Workstation
NT Workstation
Figure 2-3 Network example
This network has five machines: four running NT Workstation and one running NT Server. The NT Server machine, oakland, is the primary domain controller for the westcoast network domain. This domain includes the machines oakland, seattle, and portland.
s 2-24
Note The examples in this section assume that after AutoSys completes the logon procedure successfully, the logged on user will have the NT operating system permissions necessary to run that specific job on the machine. If the logged on user does not have the appropriate NT permissions, NT security will not allow the job to run.
Example One
User jane logs onto the machine seattle and creates a job to run on the machine seattle. AutoSys automatically assigns the owner attribute to jane@seattle. The job definition looks like this:
insert_job: myjob job_type: c command: echo hello machine: seattle owner: jane@seattle
When this job is to be run, AutoSys does the following:

1 The AutoSys Event Processor contacts the Remote Agent on the
machine seattle and passes it the job request and the user password for jane@seattle.
2 If Remote Agent Event Processor authentication is enabled, the
Remote Agent verifies that it has permission to process the Event Processor request. If it verifies that the Event Processor is running on an authorized machine, the Remote Agent proceeds. If the processor is not on an authorized machine, the Remote Agent issues an error and does not start the job. If Event Processor authentication is disabled, the Remote Agent skips this step.
2-25 s
s AutoSys Security
3 If the password is valid for jane on the machine seattle, the logon
succeeds and the job runs. No user authentication is required when the user trying to run a job is the same as the owner of the job.
Example Two
User mary logs onto the machine boston and creates a job to run on the machine seattle. AutoSys automatically assigns the owner attribute to mary@boston. mary@boston is not in the westcoast domain, and boston is a local host. The job definition looks like this:
insert_job: myjob job_type: c command: echo hello machine: seattle owner: mary@boston

machine seattle and passes it the job request and the two user passwordsone for mary@boston and one for mary@seattle.
Remote Agent verifies that it has permission to process the Event Processor request. If it verifies that the Event Processor is running on an authorized machine, the Remote Agent proceeds. If the processor is not on an authorized machine, the Remote Agent issues an error and does not start the job. If Event Processor authentication is disabled, the Remote Agent skips this step.
s 2-26
3 The Remote Agent tries to log on as the owner of the job,
mary@boston. Because the machine boston is a local host, however, it is not possible for the Remote Agent to log on as mary@boston, and this logon attempt fails.
4 The Remote Agent tries to log on again. This time it uses the user mary on the machine where the job is to be run, seattle; it uses
mary@seattle. If Remote Agent user authentication is not enabled, the Remote Agent moves to the next step. If Remote Agent user authentication is enabled, it will be used because the owner of the job, mary@boston, is different from the user who is now attempting to log on, mary@seattle. Using user authentication, the Remote Agent checks for user permission in the following two ways (in this order, and only one condition must be met):
If the AutoSys Edit Superuser has entered boston as a Trusted
Host on seattle.
If mary@seattle has specified mary@boston as a Trusted User
on seattle. If one of these checks is successful, the Remote Agent moves to the next step. If both of these checks fail, AutoSys issues an error and does not start the job.
5 If user authentication was successful or not enabled, the Remote Agent
attempts to log on as mary@seattle, using the password for this user from the Event Processor. If the password is valid for mary@seattle, the logon succeeds and the job is run. Otherwise, AutoSys issues an error and does not start the job.
2-27 s
s AutoSys Security
Example Three
User carol logs onto the domain westcoast on the machine oakland and creates a job to run on the machine atlanta. AutoSys automatically assigns the owner attribute to carol@westcoast. atlanta is not in the westcoast network domain. The job definition looks like this:
insert_job: myjob job_type: c command: echo hello machine: atlanta owner: carol@westcoast

machine atlanta and passes it the job request and the two user passwordsone for carol@westcoast and one for carol@atlanta.
Remote Agent verifies that it has permission to process the Event Processors request. If it verifies that the Event Processor is running on an authorized machine, it proceeds. If the processor is not on an authorized machine, AutoSys issues an error and does not start the job. If Event Processor authentication is disabled, the Remote Agent skips this step.
3 The Remote Agent first tries to log on as the owner of the job,
carol@westcoast. Because the machine atlanta is not a member of the westcoast network domain, it is not possible for the Remote Agent to log on as carol@westcoast, and this logon attempt fails.
s 2-28
4 The Remote Agent tries to log on again. This time it uses the user carol at the machine where the job is to be run, atlanta; it uses
carol@atlanta. If Remote Agent user authentication is not enabled, the Remote Agent moves to the next step. If Remote Agent user authentication is enabled, it will be used because the owner of the job, carol@westcoast, is different from the user who is now attempting to log on, carol@atlanta. Using user authentication, the Remote Agent checks for the appropriate permission in one of the following two ways (in this order, and only one condition must be met):
It checks if the AutoSys Edit Superuser entered westcoast as a
Trusted Host on atlanta.

It checks if carol@atlanta entered carol@westcoast as a
Trusted User on atlanta. If one of these checks is successful, the Remote Agent moves to the next step. If both of these checks fail, AutoSys issues an error and does not run the job.
5 If user authentication was successful or not enabled, the Remote Agent
attempts to log on as carol@atlanta, using the password for this user from the Event Processor. If the password is valid for carol@atlanta, the logon succeeds and the job runs. Otherwise, AutoSys issues an error and does not run the job.
Example Four
User joe logs onto the domain westcoast on the machine oakland and creates a job to run on the machine oakland, which is the primary domain controller. AutoSys automatically assigns the owner attribute to joe@westcoast.
2-29 s
s AutoSys Security
The job definition looks like this:

insert_job: myjob job_type: c command: echo hello machine: oakland owner: joe@westcoast

oakland machine and passes it the job request and two user passwordsone for joe@westcoast and one for joe@oakland.
Remote Agent verifies that it has permission to process the Event Processor request. The Remote Agent verifies that the Event Processor is running on an authorized machine by checking the list of machines specified on the AutoSys Administrator Remote Agent screen. If the Event Processor is not on an authorized machine, the Remote Agent issues an error and does not start the job. If Event Processor authentication is disabled, the Remote Agent skips this step.
3 The Remote Agent attempts to log on as joe@westcoast using the
password that the Event Processor passed to it for this user. If the password is valid for joe on the domain westcoast, the logon succeeds and the job runs. No remote authentication is required when the user trying to run a job is the same as the owner of the job.
4 If the logon is not successful, no other attempts to log on will be
successful.
Note For jobs to run on the primary domain controller in an NT domain, the job owner must be of the form user@domain, because NT expects users to log onto the domain controller.
s 2-30
3
AutoSys Jobs
This chapter describes AutoSys jobs and provides information about their different states and starting parameters.
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3 Job Types and Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3 Basic Job Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4 Command Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5 Box Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6 File Watcher Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7 Job Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8 Using the Job Profiles Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9 Basic Job Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12 Command Job Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13 File Watcher Job Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13 Box Job Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14 Job States and Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14 Example State Diagram - Simple Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17 Example State Diagram - Box Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19
3-1 s
s AutoSys Jobs
Starting Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20 Starting Parameters and Boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-21 Date/Time Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-22 Job Dependencies Related to Job Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-23 Event Processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-27 Event Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-27 Job Dependencies Based on Exit Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-30 Job Dependencies Based on Global Variables . . . . . . . . . . . . . . . . . . . . . . . . .3-33 Job Run Numbers and Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-34 Defining Jobs in AutoSys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-35 AutoSys Graphical User Interface Components . . . . . . . . . . . . . . . . . . . . . . . .3-36
s 3-2
AutoSys Jobs s Introduction
Introduction
All activity controlled by AutoSys is based on jobs. Other AutoSys objects, such as Monitors, Browsers (Reports), Alarm Sentry, Alarm Manager, and Scheduler Console, serve to track job progress. A job is the basic building block upon which the entire operations cycle is built. An AutoSys job is any single command or executable, UNIX shell script, or NT batch file. Each AutoSys job definition contains a variety of qualifying attributes, including the conditions specifying when and where a job should be run. 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.
Note Before continuing with this chapter, read Chapter 14, Maintaining AutoSys, for details on starting the AutoSys Event Processor, which must be running before you start any AutoSys processes.
Job Types and Structure

Figure 3-1 illustrates the structure of a job. There are three types of jobs: Command, File Watcher, and Box. These job types have a majority of job attributes in common, and AutoSys treats them all similarly. The primary differences between them are the actions that are taken when the job is run.
3-3 s
s AutoSys Jobs
Job
Name Starting Conditions Alarms Restart Conditions Current status Start time End time Exit code
Depends On
Basic Job Information
Definition
Current State
Job Types
Command
Command to execute Job Profile for environment profile Machine to run on Standard output files Standard input file
File Watcher Box

File Name Minimum File size Watch Interval
Container
Action
Run Command on Machine
Watch for File
Figure 3-1 Basic Job Information, Job Types, and Actions
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.
Basic Job Information

In Figure 3-1, the attributes listed inside the Job region comprise what is called the Basic Job Information, and are common to all jobs regardless of type. These attributes include the identifier name, the starting conditions, any specified alarms, the restart conditions, and a variety of other settings not shown (such as the box, if any, the job is in). Notice in Figure 3-1 that a jobs starting conditions can be contingent on the date, time, and the status of any other job.
s 3-4
AutoSys Jobs s Job Types and Structure
Command Jobs
The Command Job is commonly thought of (and referred to) as a job. The command can be a batch file, 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. In addition to the primary functionality described above, a Command job has the following supporting features: 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. Job Profile You can assign a job profile that specifies the user-defined environment variables needed to run the job. Use the AutoSys Profiles Manager to define profiles and the Job Editor Resource/Profile tab to assign an existing profile to a job. For information on defining profiles, see Job Profiles on page 3-8. I/O Standard Files 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 Editor Command Info tab.
3-5 s
s AutoSys Jobs
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.
Starting Conditions for Box Jobs

If no other starting conditions are specified at the job level, a job within a box will run as soon as the starting conditions for the box are satisfied. If several jobs in a box do not have job-level starting conditions, they will all run in parallel. Each time any job in a box changes state, the other jobs are checked to see if they are eligible to start running. If jobs in a box have a priority attribute setting, they will be processed in order of priority, highest to lowest. 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.
s 3-6
AutoSys Jobs s Job Types and Structure
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.
File Watcher Jobs

A File Watcher Job is similar to a Command Job. However, instead of starting a user-specified command on a client machine, it starts a process that monitors for the existence and size of a specific operating system file. When that file reaches a certain minimum size, and is no longer growing in size, the File Watcher Job completes successfully, indicating that the file has arrived. 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.
3-7 s
s AutoSys Jobs
Job Profiles
Job Profiles
Before running a Command Job, the AutoSys Remote Agent sets the assigned Job Profile on the jobs target machine. A Job Profile defines the appropriate non-system environment variables for the job. You can use the AutoSys Job Profiles Manger to define a profile that contains the environment variables that must be set for a specific job to run. Then, using the profile attribute or the Job Environment Profile field (in the Job Editor Resource/Profile tab), you can assign that profile to a job, or to multiple jobs. The Remote Agent on a machine first sets the system environment variables for the jobs execution, and then it sets the specified Job Profile variables. Only one Job Profile can be sourced for a job, and the System environment variables are set before the profile variables. Therefore, you can reference system environment variables in job profiles. However, if a variable is set more than once, the last one read is the one used. After setting the NT system environment variables, the Remote Agent searches for the assigned profile. By default, the Remote Agent searches for the profile on the machine on which the command is to run. However, when assigning the job profile, you can specify both the machine name and profile name, which allows you to run the job on one machine while using a Job Profile defined on another machine. These profiles are however instance-specific; you cannot assign a profile that is defined in one AutoSys instance to a job that is defined in another. Since only one profile is sourced before a Command Job is run, you must define all of the environment variables needed to run a job in its assigned profile. If you do not assign a profile job attribute in the job definition, the Remote Agent uses the DEFAULT Job Profile. While AutoSys supplies a DEFAULT Job Profile, it does not define any environment variables in it. You must define your own DEFAULT profile using the Job Profiles Manager.
s 3-8
AutoSys Jobs s Job Profiles
In addition, when the Remote Agent reads the profile, the environment variables in a profile are expanded. For example, if Path is a variable in the specified profile, AutoSys will expand any environment variables specified in the Path value, use this Path to search for the command, and set the new value for the %Path% variable before executing the command. You can specify the full pathname, in which case, variables set from the job profile can be used in the pathname specification. Note however that the profile variables are read in alphabetical order. Therefore, if you plan on expanding variables within the profile itself, the variables must be defined so that they are in the appropriate order when read alphabetically.
Note Although system environment variables will be set automatically in the commands environment, user environment variables will not be set. All other required environment variables must be defined in the jobs profile, either in the DEFAULT (which on NT is initially empty) or in a user-defined job profile.
For more information on the profile attribute, see profile in Chapter 2, JIL/GUI Job Definitions of the AutoSys Reference Guide for Windows NT.
Using the Job Profiles Manager

The Job Profiles Manager allows you to create, delete, and edit job profiles. To display the Job Profiles manager
Open the AutoSys Instance Job Profile Management icon from the AutoSys program group. The Profiles Manager appears as shown in Figure 3-2.
Note Profiles are instance-specific. Therefore, if you have installed multiple AutoSys instances, make sure that you launch the Job Profiles Manager for the appropriate instance.
3-9 s
s AutoSys Jobs
Job Profiles
Figure 3-2 Job Profiles Manager
At the top of the Job Profiles Manager is the Host Name field. By default, the Job Profiles Manager uses the machine that you are logged onto as the Host Name. You can also connect to any host machine and view the profiles defined there, and if you have Administrator group privileges and Registry edit privileges, you can create, delete, and edit the profiles on the specified host machine. The Profile Name field lets you specify a profile. To view all existing profiles on this current host, click on the down arrow to the right of this field. To define a new profile, type in a new name into this field. When you select a profile, its current settings appear in the Environment Variables display area. You cannot edit a variable directly in this display area. However, you can double-click on a variable setting, and it will be placed in the Variable and Value fields at the bottom of the Profiles Manager. Then, you can make changes to the settings in these fields (as described below).
s 3-10
AutoSys Jobs s Job Profiles
Note The capitalization of the variable definitions does not matter on NT. However, the Job Profiles Manager does replicate, in the Job Profile itself, the capitalization that you enter in the Variable and Value fields.
To edit or create a variable definition

1 In the Variable field, enter a variable name. You can enter a new
variable or an existing one.

2 Tab to or click the mouse button in the Value field and enter a value
for the variable.

3 Click the Set button to enter the variable definition. When you do this,
the new or changed variable appears in the Environment Variable display area.
4 Repeat these steps for additional variable definitions. 5 To accept the new or changed definitions, click the OK button in the
top right corner of the Job Profile Manager. This writes the definitions to the specified Profile Name and exits the manager.
Note Variable settings are also saved when you change to a new
profile, by selecting the new profile in the Profile Name field.

6 To cancel the changes, click the Cancel button in the top right corner
of the Job Profiles Manager. This action exits the Job Profiles Manager without updating the current profile.
Note When adding new profiles, you must either define the profile on the machine where the command will run or specify the computer name (on which the profile is defined) with the profile name when you are defining the Job Environment Profile or the profile attribute. If you do not do use one of these approaches, you will get a Profile not found error when AutoSys starts the job.
3-11 s
s AutoSys Jobs
Basic Job Attributes
For more information on specifying the profile attribute, see profile in Chapter 2, JIL/GUI Job Definitions in the AutoSys Reference Guide for Windows NT. To delete a variable definition
1 Double-click on a variable from the Environment Variables display
area.
2 Click the Delete button. This action immediately deletes the variable
from the profile, and no confirmation is required. To delete a Profile

1 Select the profile in the Profile Name field. 2 Click the Delete Profile button. This action brings up a confirmation
dialog box.
3 In the confirmation dialog, click OK to delete the profile, or click
Cancel to cancel the deletion.

Note You cannot delete the DEFAULT profile. However, you can
delete the variables in the DEFAULT profile.
Basic Job Attributes

For each of the three AutoSys job types, some job attributes are required. There are additional optional attributes that you can use for more advanced job definitions.
Note The owner attribute is required for all job types, but is
automatically assigned by AutoSys.
s 3-12
AutoSys Jobs s Basic Job Attributes
Command Job Attributes

Job Name The unique job identifier by which a job is referenced. Command The NT batch file, command, or application program to be executed. Machine Name The name of the machine on which the command is to be run. 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.)
The basic Command Job definition has the following required attributes:
File Watcher Job Attributes

The basic File Watcher Job definition has the following required attributes: Job Name The unique job identifier by which a job is referenced. File Name to Watch For The name of the file for which to watch. Machine Name The name of the machine on which the command is to be run.
3-13 s
s AutoSys Jobs
Job States and Status
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 Job Attributes

The basic Box Job definition has the following required attributes: 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.)

AutoSys keeps track of the current state, or status, of every job. The value of a jobs status is used to determine when to start other jobs that are dependent on the job. The job status is displayed in the job report generated by the autorep command, and in the job report you can view in the Scheduler Console. A job can have one of the following statuses: 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.
s 3-14
AutoSys Jobs s Job States and 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.
3-15 s
s AutoSys Jobs
TERMINATED The job terminated while in the RUNNING state. A job can be terminated if a user sends a KILLJOB event or if it was defined to terminate if the box it is in failed. If the job itself fails, it has a FAILURE status, not a TERMINATED status. A job might also be terminated if it has exceeded the maximum run time (term_run_time attribute, if one was specified for the job), or if it was killed from the command line via a UNIX kill command. AutoSys issues an alarm if a job is terminated.
Note Windows NT does not support the concept of process groups. If the job that was launched was a *.exe, a KILLJOB event will kill
the process specified in the command definition. If the job being run is not a *.exe (for example, *.bat, *.cmd, or *.com), AutoSys uses CMD.EXE to launch the job; KILLJOB will kill only the CMD.EXE process. The Job Status will be set according to the return code of the killed CMD.EXE process. This status can be any one of the following: SUCCESS, FAILURE, or TERMINATED. Any processes that were launched by user applications or batch (*.bat) files will not be killed. RESTART The job was unable to start due to hardware or application problems, and has been scheduled to 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.
s 3-16
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 holdnothing downstream from this job will run. For details on how on ice affects boxes, see Chapter 5, Box Job Logic.
Example State Diagram - Simple Jobs

Figure 3-3 (on page 3-18) depicts the states that simple jobs go through. In the diagrams, a status is depicted using the following box drawing:
STATE
When a change in job status occurs, it is reported as a CHANGE_STATUS event, and the Event Processor records it in its log when this status is processed. For example, when the job test_job changes from the STARTING state to the RUNNING state, the Event Processor log will contain the following entry:
EVENT: CHANGE_STATUS STATUS: RUNNING JOB: test_job
Figure 3-3 depicts the simplest state transition for a job, in which an event satisfies the starting conditions for the job.
3-17 s
s AutoSys Jobs
The job starts, processes, and completes with either a failure or success exit code.
Event Processor
Event is read by Event Processor
EVENT
Find jobs dependent on this event. Check Conditions

Event generated by Event Processor, indicating attempt to start job on Remote Machine.
STARTING Remote Agent
Event generated by Remote Agent indicating the job has actually been started and is now running.
RUNNING
Inspects Exit Code of the process.
Event generated by Remote Agent
SUCCESS - OR - FAILURE
Figure 3-3 State DiagramSimple Jobs
s 3-18
Example State Diagram - Box Jobs

For a job in a box, the job first goes into the ACTIVATED state when the top-level box it is in goes into the RUNNING state, as shown in Figure 3-4. After the job starts, the remainder of the scenario is the same as for simple jobs.
Event Processor
EVENT
Find jobs dependent on this event.
Check Conditions
Event sent by Event Processor indicating that the box is Running. Nothing actually RUNS. However, this EVENT may trigger Jobs within the box to run.
RUNNING
Inspects Exit Status of jobs within it to determine if box is done, and if so what the Exit Status is.
SUCCESS - OR - FAILURE
Figure 3-4 State DiagramBox Jobs
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.
3-19 s
s AutoSys Jobs
Starting Parameters
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 jobs status as RUNNING. By displaying the detail of the job (either in the Scheduler Console Event Report Tool, 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.
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:
s
Date and time scheduling parameters are met (it is or has passed the specified date and time). Starting Conditions specified in the job definition evaluate to true.
s 3-20
AutoSys Jobs s Starting Parameters
s s
For jobs in a box, the box must be in the RUNNING state. The current status of the job is not ON_HOLD or ON_ICE.
Every time an event changes any of the above conditions, AutoSys finds all the jobs that might be affected by this change, and determines whether or not to start them.
Note It is very important to keep in mind the above four conditions.
In order for a job to start, all defined starting conditions must be true.
Starting Parameters and Boxes

Be aware that for a job in a box to start, the Box Job must be running. Placing a job in a box means that the job inherits all the starting conditions of the Box Job. It also means that if there are no additional conditions on the job, it will be started as soon as the box is started. Also, a job runs only once per box execution. By default, there is no concept of sequential job processing in a box. For example, if there are three jobs inside a box, and none of them has any additional conditions, then when the box is started, all three jobs will be started. To implement a sequence within a box, you must specify additional starting conditions for each job. For example, Job1 may have no starting conditions, while Job2 is dependent on the completion of Job1, and Job3 is dependent on the completion of Job2. 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-21 s
s AutoSys Jobs
Starting Parameters
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 Job Editor. 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. For example, if you define a job to be started on Monday, Wednesday, and Friday at 8:00 a.m. and 5:00 p.m., it will be started 6 times a week: Monday at 8:00 a.m. and 5:00 p.m., Wednesday at 8:00 a.m. and 5:00 p.m., and Friday at 8:00 a.m. and 5:00 p.m. 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 Job Editor, but you can only specify actual dates through the use of custom calendars, which you can define using the Calendar Editor. 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 Job Editor (you do not have to create custom calendars).
Custom Calendars
Using the Calendar Editor 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.
s 3-22
Job Dependencies Related to Job Status

You can start jobs based on the current status of one or more jobs. These jobs must exist in the AutoSys database. These starting conditions enable you to program simple or complex prerequisites that must be met in order to initiate a job. Starting conditions can be as simple as specifying JobB to start when JobA achieves a SUCCESS status, and JobC to start when JobB achieves a SUCCESS status. In this way, you can implement a singlethreaded, batch queue-like logic.
Note If a condition is specified for an undefined job, the condition will be evaluated as FALSE, and any jobs dependent on this condition will not run. To check for this type of invalid condition statement, you can use the chk_cond stored procedure.
The syntax for defining job dependencies is the same whether the job is being defined using JIL or the Job Editor. The only difference is the JIL statement will begin with the JIL condition keyword, while the Job Editor Dependencies field will only contain the language for the dependency itself. The dependency specification can take one of the following three forms:
s s s
Based on the current AutoSys status of other jobs Based on the exit codes of other jobs Based on AutoSys global variables
This is the syntax for conditions based on AutoSys job status:

status(job_name)
3-23 s
s AutoSys Jobs
Starting Parameters
where:
status is one of the following: success
Indicates that the status condition for job_name is SUCCESS.

failure
Indicates that the status condition for job_name is FAILURE.

done
Indicates that the status condition for job_name is SUCCESS, FAILURE or TERMINATED.
terminated
Indicates that the status condition for job_name is TERMINATED.

notrunning
Indicates that the status condition for job_name is anything except RUNNING.
job_name
Is the job on which the new job is dependent. 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.
s 3-24
Note Either uppercase or lowercase can be used to specify a status.
However, the case cannot be mixed in either of the forms described.
Cross-Instance Job Dependencies

Cross-instance job dependencies can be implemented among different instances of AutoSys. An AutoSys instance is one licensed version of AutoSys software running as an AutoSys server, and as an AutoSys server/client, on a single machine or on multiple machines. It uses its own Event Server and Event Processor and operates independently of other AutoSys instances. 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 instances unique, capitalized three-character identifier. In addition, jobs can be associated with more than one instance of AutoSys. For example, a job defined to run on one instance of AutoSys could have as a starting condition the successful completion of a job running on a different instance of AutoSys. 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.
3-25 s
s AutoSys Jobs
Starting Parameters
Each time a cross-instance dependency is encountered, an EXTERNAL_DEPENDENCY event is sent from the requesting instance. If the target instance cannot be reached, an INSTANCE_UNAVAILABLE alarm is issued. Figure 3-5 shows two instances of AutoSys, each with a single Event Server, exchanging cross-instance job dependencies.
One Instance of AutoSys PRD
OS FILE : NT Registry Settings config.EXTERNAL File
One Instance of AutoSys ACE

OS FILE : NT Registry Settings config.EXTERNAL File
Event Server
Event Processor
Event Processor
Event Server
condition: success(jobB^PRD) jobE
jobB condition: success(jobEÂCE)
Figure 3-5 AutoSys Instances with Cross-Instance Dependencies
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%.
Note If you are working with multiple instances, make sure that you are operating on the correct instance when you define jobs or send events. If you are using an AutoSys GUI or the Instance Command Prompt window, make sure that it is associated with the appropriate instance of AutoSys.
s 3-26
For information on configuring AutoSys for cross-instance job dependencies, see the Running Cross-Instance Job Dependencies section in Chapter 1, Introduction to AutoSys of the AutoSys Installation and Getting Started Guide for Windows NT.
Event Processors
When cross-instance dependencies are implemented, different Event Processors can do the following:
s s s
Be run on different server machines or on the same server machine. Access the same client machines to start jobs. Send events to other AutoSys instances.
Note If the Event Server of a target instance is down, the Event Processor will try to resend an event (or events) every 5 minutes until the other instances Event Server can be reached.
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:
s
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. An entry to the req_job table of the receiving instance. The entries in this table specify the jobs that have been specified as a job dependency in a job definition on the source AutoSys instance.
In both tables above, jobs are entered using the job name, a caret symbol (^), and the instance name, as shown below.
jobB^PRD
3-27 s
s AutoSys Jobs
Starting Parameters
The use of multiple database(s) is completely independent of instances using cross-instance dependencies. You can have multiple instances of AutoSys, each using Dual Event Servers.
Note When communicating with Event Servers, Event Processors can only connect to those instances with like Event Servers. That is, instances with Sybase dataservers can only connect with other instances having Sybase dataservers. The same holds true for instances with Oracle databases, or with Microsoft SQL Server databases.
Example Job Dependencies

For a job that runs only if the job named DB_BACKUP succeeds, the job dependency specification would be written as follows:
success(DB_BACKUP) Or s(DB_BACKUP)
You can configure more complex conditions by combining a series of conditions with the AND and/or the OR logical operators. You can enter these operators in upper- or lowercase, but not in mixed case. In addition, you can use the symbol | instead of the word OR, and the symbol & instead of the word AND. Spaces between conditions and delimiters are optional. You can specify more complex conditions by grouping the expressions in parentheses. The parentheses do not imply any sort of precedence, they are simply used for grouping. For example, if JobC should only be started when both JobA and JobB complete successfully or when both JobD and JobE complete, regardless of whether they failed, succeeded, or terminated, you would specify the following dependency in the job definition for JobC:
(success(JobA) AND success(JobB)) OR (done(JobD) AND done(JobE)) Or (s(JobA)&s(JobB))|(d(JobD)&d(JobE))
s 3-28
As indicated in this example, you can use any job status as part of the specification for a specific jobs 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 arent running. You would specify the smaller jobs 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 10, Load Balancing and Queuing Jobs.
Managing Job Status

Starting conditions that are based on job status use the current (or most recent) completion status of the job. The current completion status is defined by the last execution of the job, regardless of when it last ran. However, if you wish to enforce the concept of time-based processing cycles, where the completion status of a job for some previous time period should not affect the processing of this time cycle, there are several options you can use to control statuses.
3-29 s
s AutoSys Jobs
Starting Parameters
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 Tool), 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.)
Job Dependencies Based on Exit Codes

In addition to job status, you can base job dependencies on exit codes that indicate completed tasks. In this way, you can implement even more specific branching logic for recovering from job failures. For example, if a broken communication line results in JobA failing with an exit code of 4, when this code is encountered, you want the system to execute a batch file (JobB) which redials the line. This is the syntax you would use to specify this type of job dependency:
exitcode (job_name) operator value
s 3-30
where:
job_name
Is the name of the job upon which the new job is dependent.
operator
Is one of the following exitcode comparison operators: =, != (not equal), <, >, <=, or >=
value
Is any numeric 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.
Using Exit Codes and Batch Files with Jobs Running on NT

When you are defining jobs that will run batch files on Windows NT, you should be aware of, and account for, the NT-specific behavior. NT programs return an exit values that are programmed within the executable code. This exit value is the last thing returned to NT when the program terminates. 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.
3-31 s
s AutoSys Jobs
Starting Parameters
AutoSys jobs are created using standard NT process creation techniques. After the job has been created, the Remote Agent waits for the job to complete. When the job completes, AutoSys gets the program exit code from NT and stores it in the AutoSys database for later use. 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.
s 3-32
To help handle situations like this, Autosys supplies a program called FALSE.EXE. This program is located in the AutoSys for NT %AUTOSYS%\bin directory and takes only one parameter, which is the exit code you want false to return on completion. You can use false in the above example batch file, like this:
REM test batch file test if errorlevel 1 goto bad exit :bad del test.tmp false 1
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.
Job Dependencies Based on Global Variables

Job dependencies can also be based on global variables you set using the Send Event Tool or the sendevent command. When using global variables in this way, the value of the expression must evaluate to TRUE for the job dependency to be satisfied. For example, you have a set of jobs in a box that are only supposed to run on special occasions, such as only on your managers approval. In this case, you would set the global variable named manager-ok to OK, and make the top-level Box Job dependent on this global variable. Global variables are referenced using the following expression:
VALUE(global_name) operator value
where:
VALUE
Can be upper- or lowercase.

global_name
Is the name of the global variable upon which the job is dependent.
3-33 s
s AutoSys Jobs
Job Run Numbers and Names
operator
Is one of the following: =, != (not equal), <, >, <=, or >=

value
Is any numeric value or text string (no quotes or spaces). The global_name and the value can each be a maximum of 30 characters. When using the Job Editor Dependencies field 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 jobs condition statement:
VALUE(manager-ok) = OK Or v (manager-ok) = OK
Job Run Numbers and Names

AutoSys employs the notion of run numbers for jobs. The run number is a unique integer associated with every run of a job. Consecutive run numbers are assigned every time a top-level job starts. 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.
s 3-34
AutoSys Jobs s Defining Jobs in AutoSys
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 Windows NT), these two values are displayed in the Run column as run_num/ntry. The value of run_num/ntry is defined in the runtime environment for the job, and it is accessible to those batch files or executables executed as the jobs command. This value is contained in the variable %AUTORUN%. AutoSys also maintains a value for each jobs name, which is defined in the runtime environment for the job. As with %AUTORUN%, this value is accessible to those batch files or executables executed as the jobs command. The value is contained in the variable %AUTO_JOB_NAME%.
Defining Jobs in AutoSys

You can define jobs in AutoSys using one of two methods: JIL statements or the GUI (in the Job Editor). When you use JIL statements, you can input them interactively to the jil command, or you can store them in text files, which you can redirect into the jil command. Alternatively, you can open the GUI from the AutoSys Graphical Interface icon in the AutoSys program group, and you can enter the job definition by filling in the appropriate fields of the Job Editor. 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 14, Maintaining AutoSys.
3-35 s
s AutoSys Jobs
AutoSys Graphical User Interface Components

You can use the AutoSys GUI to interactively define, run, manage, monitor, and report on jobs. AutoSys provides the following top-level windows and dialogs, which you can launch from the AutoSys GUI Control Panel: Job Editor Used to define jobs. The Job Editor and its related dialogs allow you to create, view, edit, and delete job definitions for Command Jobs, Box Jobs, and File Watcher Jobs. Calendar Editor Used to define calendar definitions. The Calendar Editor and its related dialogs allow you to create calendars in order to simplify job scheduling. It allows you to create custom rules, block certain dates, setup conflict resolution, build calendars based on combinations of other calendars, and preview calendar definitions before assigning them to jobs. Then, you can assign them to certain job, using the Job Editor. Scheduler Console Used to monitor and manage AutoSys jobs, for multiple instances. The Scheduler Console allows you to monitor AutoSys jobs, and to filter the jobs that it displays, you can use the Job Selection dialog. Alarm Sentry and Alarm Manager The Alarm Sentry alerts you when a alarm occurred for any of the instances to which it can connect, and from it, you can launch the appropriate Alarm Manager. The Alarm Manager allows you to browse and handle alarms, and to filter the alarms that it displays, you can use the Alarm Selection dialog.
s 3-36
AutoSys Jobs s Defining Jobs in AutoSys
Monitor/Browser Editor Used to define monitors and reports. The Monitor/Browser Editor allows you to define filters by which you can screen AutoSys system information. Monitors provide real-time views of the system. Browsers (reports) provide historical views of system information.
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 Windows NT.
3-37 s
s AutoSys Jobs
s 3-38
4
Job Attributes
This chapter describes the essential and optional job attributes used to define jobs in AutoSys. These attributes determine what a job does, as well as when and where it will run.
Job Attributes and Job Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3 Using JIL to Create a Job Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3 Using the Job Editor 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-10 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
4-1 s
s Job Attributes
Date and Time Attributes and Time Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28 The Time Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-28 AutoSys Behavior During Time Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-30
s 4-2
Job Attributes s Job Attributes and Job Definitions
Job Attributes and Job Definitions

You define a new job by assigning it a name and specifying any number of attributes that describe its intended behavior. This specification of a jobs behavior is called a job definition. There are two methods of creating a job definition: using JIL and using the AutoSys Job Editor. Regardless of method, the specified set of attributes is the same, and the job definition is always stored in the database. 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 14, Maintaining AutoSys.
Using JIL to Create a Job Definition

When using JIL to create a job definition, you enter the jil command to display the jil prompt. At this prompt, you define a job using the insert_job sub-command followed by any desired attribute:value statements which specify an action to be performed. You can also use JIL sub-commands to modify or delete an existing job definition. Your JIL commands will look like this:
insert_job: job_name attribute:value ...
where:
job_name
Is a unique job name.

attribute_keyword
Is one of the legal JIL attributes.
4-3 s
s Job Attributes
Job Attributes and Job Definitions
value
Is the setting to be applied to the attribute.
Using the Job Editor to Create a Job Definition

When using the AutoSys Job Editor to create a job definition, open the AutoSys GUI Control Panel from the AutoSys Graphical Interface icon in your AutoSys program group, click on the Job Editor button in the AutoSys GUI Control Panel, and set the various attributes and their values using the text fields and push-buttons in the Job Editor.
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 Job Editor object, or GUI Field Name, and a description of its use, as shown below:
Job Type job_type
New Job dialog: Job Type
Attribute description...
JIL Keyword Job Editor Field Name
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 Job Editor as the field in the New Job dialog with the name Job Type.
s 4-4
Job Attributes s Essential Job Attributes
Because Chapter 2, JIL/GUI Job Definitions, of the AutoSys Reference Guide for Windows NT 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 Job Editor field name on the right as in the example above.
Essential Job Attributes

Attributes Common to All Job Types
The following attributes are common to all job types: Command, File Watcher, and Box. Although defaults may be available, the attributes in this section are still essential due to the fact that every job definition must include them, whether by default or by explicit specification.
Job Name
insert_job
New Job and Save dialogs: 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
New Job dialog: Job Type
The job type specifies the type of job: Command (c), File Watcher (f), or Box (b).
4-5 s
s Job Attributes
Job Owner
owner
Basic Tab: 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 Job Editor to define the job, and cannot be changed except by the Edit Superuser.
Command Jobs Attributes

For Command jobs, the following attributes must be specified in addition to those listed in the Attributes Common to All Job Types section (above).
Command
command
Basic tab: Command
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 jobs 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 commands runtime arguments. To set a global variable, use the sendevent command, or use the Send Event Tool, which you can launch from several places in the GUI. If the command resides on a file system that supports NT security mechanisms (e.g., NTFS), then the jobs owner must have read and execute permission on that command. (By extension, all resources and files referenced by the commands execution must also be accessible to the jobs owner.)
s 4-6
User-defined environment variables necessary for the command to be executed are defined by a job profile; this profile is sourced before a job is executed (see the profile attribute description on page 4-19). If you want to use an AutoSys command in the Command field or for the command attribute, you must use the following syntax (when you use this syntax, the AutoSys-specific variables are set correctly):
initautosys -i Instance -r "command_line"
where:
Instance
Specifies the instance name.

"command_line"
Specifies the full command line. This command line must be in quotes. You cannot use a network drive letter in a command definition. You must use a fully qualified network name instead. For example, \\TAURUS\C$\tmp. (Also note that \\TAURUS\C$ must be shared so that no password is needed to access it.) These are additional points to keep in mind with regard to the command attribute:
s
By default, NT jobs are started in the foreground to allow Windows applications to interact with the desktop. To launch a job in the background, enter an ampersand (&) as the first character in the job command attribute. Redirection of standard input, output, and error files is not allowed in the command attribute. Job attributes, such as std_in_file for standard input, can be used to provide the necessary functionality.
4-7 s
s Job Attributes
Although system environment variables will be set automatically into the commands environment, user environment variables will not be. All other required environment variables must be defined in the jobs profile, either in the default one (which on NT is initially empty) or in a user-defined job profile. Command line arguments can be passed using global variables.
Note If a command works properly when issued at an MS-DOS command prompt, but it fails to run or run properly when specified as a command attribute, the user-defined environment variables and the variables defined in the job profile are probably different. If this is the case, make sure that all required user environment variables are defined correctly in the jobs profile. If you do not specify a profile specifically, the default profile is used. To define profiles, use the Profiles Manager, described in the Job Profiles section of Chapter 3, AutoSys Jobs.
When using JIL, if you are including a drive letter with the pathname, the colon must be escaped (for example "C:\tmp" and C\:\tmp are valid; C:\tmp is not). When using the GUI applications and dialogs, do not use escape characters.
Machine to Run On
machine
Basic tab: Send to Machine
This attribute specifies the client machine on which the command should be run. The jobs 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, a set of real machines, or a virtual machine. Real machines must be accessible over the network using the TCP/IP protocol (such as telnet or ftp).
s 4-8
Note If you have implemented the Shadow Event Processor feature, you should never set the machine attribute to localhost. localhost implies: run on the machine on which the Event Processor is currently running. The job might run normally on the Primary Event Processor machine, and yet fail on the Shadow Event Processor machine.
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 10, Load Balancing and Queuing Jobs.
For File Watcher jobs, the following attributes must be specified in addition to those listed in Attributes Common to All Job Types on page 4-5.
Machine to Run On
machine
Basic tab: Send to 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, accessible over the network using TCP/IP (such as telnet or ftp).
File to Watch For

watch_file
File to watch
The name of the file to watch for must be a legal file name and must include the full path to the file. All directories in the path must exist, but the file itself does not have to exist at the time the job is defined. Environment variables defined and exported in the profile file (the specified or default), as well as global variables, can be used in the path. Wildcards cannot be used in the file name. When using the Job Editor, this field only appears when the File Watcher type has been selected. When using JIL, if you are including a drive letter with the pathname, the colon must be escaped (for example "C:\tmp"
4-9 s
s Job Attributes
Optional Job Attributes
and C\:\tmp are valid; C:\tmp is not). When using the GUI, do not use escape characters. 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.
Box Job Attributes

There are no essential attributes for Box jobs other than those listed in Attributes Common to All Job Types on page 4-5.

Common Job Starting Attributes
The following optional attributes are common to all Job Types: Command, File Watcher, and Box. These attributes are used to specify when a job should start, and typically default to inactive or NULL if not specified. 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.
Start Date /Time Dependence

date_conditions
Date/Time tab: Date/Time Conditions
The start date/time dependencies attribute is a toggle, which specifies whether or not there are date and/or time conditions required for starting the job. If set to no, the remainder of the related date/time attributes described below will be ignored.
s 4-10
Job Attributes s Optional Job Attributes
Days of the Week

days_of_week
Date/Time tab: Run Days
The days of the week attribute specifies the days on which the job should be run. You can specify one or more days, or all for every day.
Days to Run on - via a Custom Calendar

run_calendar
Date/Time tab: Run Calendar
The days on which a job should be run can be specified by way of a custom calendar, rather than through a list of days of the week. Custom calendars, specified through the Calendar Editor, or the autocal_asc command, can include any number of dates on which the job should be run. Each calendar is stored in the database as a separate object with a unique name, and a calendar can be associated with one or more jobs, using this attribute or the exclude_calendar attribute.
Days to NOT Run onvia a Custom Calendar

exclude_calendar
Date/Time tab: Exclude Calendar
The days on which a job should not be run can be specified by way of a custom calendar. Custom calendars, specified through the Calendar Editor, or the autocal_asc command, can include any number of dates on which the job should not be run. Each calendar is stored in the database as a separate object with a unique name, and a calendar can be associated with one or more jobs, using this attribute or the run_calendar attribute.
Specific Times of Day to Run

start_times
Date/Time tab: Times of Day
This attribute specifies one or more specific times of day when the job should be started. The job will be started at each specified time of day, on every day specified in the associated date attributes. This attribute, the Minutes after Each Hour (start_mins), and the Anytime After Midnight attributes are mutually exclusive.
4-11 s
s Job Attributes
Time of Day Not to Run

run_window
Date/Time tab: Run Window
This attribute specifies a time range (or time window) during which a job can be started. When the starting conditions for a job have been met, AutoSys checks if the current time is within the specified run window. The job will not start outside of the specified window. 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 latearriving 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 Tool, or from within a shell script or batch file in another job.
Specific Times Every Hour to Run

start_mins
Date/Time tab: Minutes after Each Hour
One or more specific times per hour when the job should be started can be specified. Each time is specified in minutes past the hour. The job will be started at each specified time every hour of the day, on every day specified in the associated date attributes. This attribute, the Minutes after Each Hour (start_times), and the Anytime After Midnight attributes are mutually exclusive.
s 4-12
Job Dependencies
condition
Basic tab: Dependencies
Any number of job dependencies can be specified; however, every dependency must evaluate to true before the dependent job will be run. Examples of job dependencies include successful completion of a job, failure of a job, a jobs exit code, and the value of a global variable. Various combinations of conditions may also be specified. Job dependencies can reference jobs residing on different AutoSys instances. If a condition is specified for an undefined job, the condition will be evaluated as FALSE, and any jobs dependent on this condition will not run. To check for this type of invalid condition statement, you can use the chk_cond stored procedure (see chk_cond (SP) in Chapter 1, AutoSys Commands, of the AutoSys Reference Guide for Windows NT).
Note You should study the Starting Parameters section of Chapter 3, AutoSys Jobs, and review the JIL examples provided in Chapter 8, Defining Jobs Using JIL. This functionality opens up all sorts of possibilities for controlling jobs, and provides information that will help you when creating your own job definitions.
Common General Attributes

The following optional attributes are common to all job types: Command, File Watcher, and Box. These attributes are used to specify a variety of features, and typically default to inactive or NULL if not specified.
Description
description
Basic tab: 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 Job Editor adds quotes for you automatically.
4-13 s
s Job Attributes
Box Name
box_name
Basic tab: Box
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.
Minimum Run Time Alarm

min_run_alarm
Alarms/Terminators tab: Minimum Run Time
A minimum run time (in minutes) can be specified for a job; the job should not end in less than the specified time. This may prevent an inadvertent truncation of the file being processed before it is complete. If the job does end prior to this time, an alarm is generated to alert someone to investigate the situation and take corrective action. Alarms are informational, and they do nothing on their own. A monitor, the Alarm Sentry, or the Alarm Manager must be running and tracking alarms in order for them to be seen and acted upon in real-time.
Maximum Run Time Alarm

max_run_alarm
Alarms/Terminators tab: Maximum Run Time
A maximum runtime can be specified for a job; the job should not take longer than the specified time to finish. This reasonability test may catch an error, such as the application being stuck in a loop, or the application waiting for additional data which may never arrive. If the job runs longer than this time, an alarm is generated to alert someone to investigate the situation and take corrective action. Alarms are informational, and they do nothing on their own. A monitor, the Alarm Sentry, or the Alarm Manager must be running and tracking alarms in order for them to be seen and acted upon in real-time.
s 4-14
The attribute Terminate this job n mins after starting (term_run_time) can be used to automatically terminate a job that has been running for too long. If term_run_time is not set, the job will continue running until manually interrupted, or it completes by itself.
Terminate Due to Run Time

term_run_time
Alarms/Terminators tab: Terminate this job n mins after starting
A maximum run time (in minutes) can be specified for a job; the job should not take longer than the specified time to finish. This feature allows the job to be automatically terminated if it runs longer than the allotted time.
Send Alarm if the Job Fails

alarm_if_fail
Alarms/Terminators tab: Send Alarm if this job fails
This attribute specifies whether or not an alarm should be generated when the job fails. Failure is defined as the job completing with a FAILURE or TERMINATED status. (The Maximum Exit Code for SUCCESS attribute determines what codes are interpreted as FAILURE for a job, and the Failure Condition attribute for Box Jobs determines what constitutes a box failure.) Alarms are informational, and they do nothing on their own. A monitor, the Alarm Sentry, or the Alarm Manager must be running and tracking alarms in order for them to be seen and acted upon in real-time.
Terminate the Box if the Job Fails

box_terminator
Alarms/Terminators tab: If this Job fails, terminate the box it is in
This attribute specifies whether or not the box containing this job should be terminated if the job fails or terminates. By using this attribute in combination with the If this box fails, terminate this job attribute, you can control how nested jobs react when a job fails. This attribute only applies if the job is being placed in a box.
4-15 s
s Job Attributes
Terminate the Job if the Box Fails

job_terminator
Alarms/Terminators tab: If the box fails, terminate this job
This attribute specifies whether or not the job should be terminated if the box it is in fails or terminates. By using this attribute in combination with the If this job fails, terminate the box it is in attribute, you can control how nested jobs react when a job fails. This attribute only applies if the job is being placed in a box.
Note Windows NT does not support the concept of process groups. If the job that was launched was a *.exe, KILLJOB will kill the process specified in the command definition. If the job being run is not a *.exe (for example, *.bat, *.cmd, or *.com), AutoSys uses CMD.EXE to launch the job; KILLJOB will kill only the CMD.EXE process. The Job Status will be set according to the return code of the killed CMD.EXE process. This status can be any one of the following: SUCCESS, FAILURE, or TERMINATED. Any processes that were launched by user applications or batch (*.bat) files will not be killed.
Number of Times to Restart a Job

n_retrys
Misc tab: Number of times to restart this job after a failure
This attribute specifies how many times, if any, the job should be restarted after exiting with a FAILURE status. The default is 0, which means the job will not be automatically restarted after an application failure. This attribute applies to application failures (e.g., AutoSys is unable to find a file or a command, or permissions are not properly set); it does not apply to system or network failures (e.g., machine unavailability, the socket connect timed out, the fork in the Remote Agent failed, or the file system space resource check failed).
s 4-16
The number of restarts after system or network failures is specified using the Max Restart Trys field on the AutoSys Administrator Event Processor screen. For information on the AutoSys Administrator, see Chapter 15, AutoSys Administrator.
Time Zone for Job

timezone
Date/Time tab: Time Zone
This attribute allows you to schedule a job based on a chosen time zone. When this attribute is used, the time settings in the job are based on the specified time zone. For example, if you define a start time of 01:00 for a job running on a machine in Denver, and enter SanFrancisco in the Time Zone field, the job will start at 1:00 a.m. Pacific time, which is 2:00 a.m. in Denver. 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 time zone under which the Event Processor is running.
4-17 s
s Job Attributes
Delete Job After Completion

auto_delete
Misc tab: Delete Job after completion
This attribute indicates whether or not the job definition should be automatically deleted after successful completion. A number of hours can be specified (including 0 for immediately), or the attribute can be turned off by specifying a negative value (e.g., -1), which is the default. If auto_delete is set to 0, AutoSys will immediately delete job definitions only if the job completed successfully. 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
Misc tab: AutoHold on for jobs in boxes
This feature is only for jobs in a box. When a job is in a box, it inherits the boxs 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 Tool or the sendevent command.
Permissions
permission
Misc tab: Permissions
The AutoSys permission scheme provides users with Edit and Execute permissions on a per job basis.
s 4-18
For NT by default, only a jobs owner has Edit and Execute permission on a job. AutoSys associates different types of permissions with a job. The following levels of permissions are supported: Exec The user or the world can issue events that affect the running of the job (such as STARTJOB, KILLJOB, etc.). Edit The user or the world can edit the job definition itself, including deleting the job. Machine By default, all Edit and Execute permissions are valid only on the machine on which the job was defined (using either jil or the Job Editor). Permission attributes can allow a user or the world to edit or execute a job from a different machine. For more information about setting permissions, see the Overview section of Chapter 2, AutoSys Security.
Command Job Attributes

For Command jobs, the following optional attributes can be specified, in addition to those listed in Attributes Common to All Job Types on page 4-5. These attributes typically default to inactive if not specified.
Profile
profile
Resource Profile: Job Environment Profile
The profile attribute specifies the name of the defined job profile that contains the environment variables that should be set for the commands execution. You can add and delete job profiles using the Profiles Manager, which you can open from the AutoSys program group. (For
4-19 s
s Job Attributes
more details on the Profiles Manager, see Job Profiles in Chapter 3, AutoSys Jobs.) If no profile attribute is specified, the profile named default is used. On NT, the default profile is initially empty, but you can add variables to it using the Profiles Manager. If a profile attribute is specified, that profile_name is searched for on the machine on which the command is to run, but, in the attribute or in the Job Environment Profile field, you can specify a machine name in the path to the profile using the following syntax: \\computer_name\profile_name. If a command that normally executes when entered at the command line fails when run as an AutoSys job, it is usually due to the incomplete specification of the required environment for the command in the jobs profile. Since only system environment variables are defined by default when a job runs, verify that all required user defined environment variables are defined in the jobs associated profile.
Redirection of the Standard Input File

std_in_file
Command Info tab: File to redirect standard input
The standard input file can be redirected to any file to which the job owner has read permission on the client machine. The full pathname must be specified, although variables defined in the commands environment, as well as global variables, can be used in the pathname specification. When using JIL and including a drive letter with the pathname, you must escape the colon (for example "C:\tmp" and C\:\tmp are valid; C:\tmp is not). When using the Job Editor, do not use escape characters. The default is NUL:.
s 4-20
Redirection of the Standard Output File

std_out_file
Command Info tab: File to redirect standard output
The standard output file can be redirected to any file on the client machine to which the job owner has write permission. The full pathname must be specified, although variables defined in the commands environment, as well as global variables, can be used in the pathname specification. When using JIL, if you are including a drive letter with the pathname, the colon must be escaped (for example "C:\tmp" and C\:\tmp are valid; C:\tmp is not). When using the Job Editor, do not use escape characters. The default is NUL:. By default, the file will be overwritten with new information. By placing the following notation as the first character(s) in the std_out_file specification, you can specify if the error file should be appended to or overwritten: > Overwrite file
>> Append file This setting overrides the instance-wide setting for the Append stdout/stderr setting on the AutoSys Administrator Event Processor screen. It also overrides the machine-specific setting for the AutoMachWideAppend variable, which you can set on the AutoSys Administrator System Information screen.
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 UNIX, the default is to append this file.
For information on using the AutoSys Administrator, see Chapter 15, AutoSys Administrator.
4-21 s
s Job Attributes
Redirection of the Standard Error File

std_err_file
Command Info tab: File to redirect standard error
The standard error file can be redirected to any file on the client machine to which the job owner has write permission. The full pathname must be specified, although variables defined in the commands environment, as well as global variables, can be used in the pathname specification. When using JIL, if you are including a drive letter with the pathname, the colon must be escaped (for example "C:\tmp" and C\:\tmp are valid; C:\tmp is not). When using the Job Editor, do not use escape characters. The default is NUL:. By default, the file will be overwritten with new information. By placing the following notation as the first character(s) in the std_err_file specification, you can specify if the error file should be appended to or overwritten: > Overwrite file
>> Append file This setting overrides the instance-wide setting for the Append stdout/stderr setting on the AutoSys Administrator Event Processor screen. It also overrides the machine-specific setting for the AutoMachWideAppend variable, which you can set on the AutoSys Administrator System Information screen.
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 UNIX, the default is to append this file.
For information on using the AutoSys Administrator, see Chapter 15, AutoSys Administrator.
s 4-22
Job Load
job_load
Command Info tab: 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 jobs 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 machines 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.
For information about load balancing on machines, see Chapter 10, Load Balancing and Queuing Jobs.
Queue Priority
priority
Command Info tab: 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 jobs 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.
4-23 s
s Job Attributes
Job Overrides
override_job
File menu and Basic tab: Add One Time Override
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. The following attributes can be modified in a job override:
auto_hold command condition date_conditions days_of_week exclude_calendar machine max_run_alarm min_run_alarm n_retrys profile run_calendar run_window start_mins start_times std_err_file std_in_file std_out_file term_run_time watch_file watch_file_min_size watch_interval
For a description of how to use the Job Editor to specify job overrides, see Specifying One-time Job Overrides in Chapter 7, Defining AutoSys Jobs using the Job Editor.
Maximum Exit Code for Success

max_exit_success
Command Info tab: Maximum Exit Code for SUCCESS
The maximum exit code for success attribute indicates what exit codes will be considered by AutoSys as a success. It is used when a command can exit with more than just a single exit code, indicating either degrees of success, or other conditions that may not indicate a failure. This
s 4-24
attribute lets you define complex branching logic based on specific exit code values. AutoSys reserves exit codes greater than 120 for internal use, so do not use exit codes of 120 or greater.
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.
Heartbeat-Interval
heartbeat_interval
Command Info tab: Heartbeat interval (mins)
In AutoSys, heartbeats are a means of monitoring a jobs 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\testheart.c
The Event Processor must be configured to check for heartbeats. To do this, use the HeartBeat Interval field in the AutoSys Administrator Event Processor screen. For information on configuring AutoSys and the AutoSys Administrator, see Chapter 15, AutoSys Administrator. For information on sending heartbeats, see Sending Heartbeats in Chapter 7, AutoSys API of the AutoSys Reference Guide for Windows NT.
4-25 s
s Job Attributes
Resource Check - File Space

chk_files
Resource/Profile tab: Resource Check - File System Space...
This attribute specifies a minimum amount of file space that must be available on the designated drive(s) for the job to be started. One or more drive(s), specified with drive letters, and their corresponding sizes, can be specified. If multiple drive(s) are specified, separate them with a single space. Only drives are checked; directories, if specified, are ignored. When the Remote Agent is preparing to start the job on the client machine, it checks whether or not the required space is available before starting the job. If the requirements are not met, an alarm is generated and AutoSys automatically reschedules the job to start again after a delay. It will perform the same resource check the next time it attempts to start. This feature is intended to prevent a job that is known to require large amounts of file space from failing due to a shortage of space during processing time.

For File Watcher jobs, the following attributes can be specified in addition to those listed in File Watcher Job Attributes on page 4-9. These attributes typically default to inactive if not specified.
Watch File Minimum Size

watch_file_min_size
Basic tab: Minimum file size (in bytes)
The watch file minimum size determines when enough data has been written to the file to consider it complete. This attribute is specified in bytes. You should specify a reasonable file size to ensure that a nearly empty file isnt assumed to be complete. Use caution with this attribute. If you specify a large file size AutoSys will wait for the file to reach that size, even if the file has reached a steady state and is no longer growing.
s 4-26
Watch Interval
watch_interval
Basic tab: 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.
Resource Check - File Space

chk_files
Resource/Profile tab: Resource Check - File System Space...
This attribute specifies a minimum amount of file space that must be available on designated file systems for a Command job to be started. One or more file systems, specified with drive letters, and their corresponding sizes can be specified. When the Remote Agent is preparing to start the job on the client machine, it checks whether the required space is available before starting the job. If the requirements are not met, an alarm is generated. File Watcher jobs will still be started.
Box Job Attributes

For Box jobs, the following optional attributes can be specified, in addition to those listed in Attributes Common to All Job Types on page 4-5. These attributes typically default to inactive or NULL if not specified.
Box Successful Completion

box_success
Basic tab: Success Conditions
The default condition required for a box to be considered successful is that every job in the box must have completed with a success condition. A box can contain complex branching logic, which can take a number of different paths, all of which constitute a success. In this case, some jobs in the box may never need to run, but if the default box behavior is applied, the jobs that had not run would prevent the box from ever completing. This attribute can be used to specify what is considered a
4-27 s
s Job Attributes
Date and Time Attributes and Time Changes
success, which could be as simple as the success of a single job, or as complex as necessary. This attribute is only displayed in the Job Editor when you select a Box Job Type, and then it is located on the Basic tab.
Box Failure
box_failure
Basic tab: Failure Conditions
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 Job Editor when you select a Box Job Type, and then it is located on the Basic tab.

Date and Time attributes can be affected by the Spring and Fall time adjustments. The following sections describe the job run behavior you should expect, and thus can plan for.
The Time Change

During the changes to and from daylight saving time, your operating system automatically changes the system clock to reflect the switch to either Standard Time (ST) or Daylight Time (DT). 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.
s 4-28
Job Attributes s Date and Time Attributes and Time Changes
Daylight-saving Time 3:00 4:00 5:00
1:00
1:59 Standard Time
Figure 4-1 Change from ST to DT
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 1:00 2:00 3:00 4:00
0:00
1:00
1:59
Daylight-saving Time
Figure 4-2 Change from DT to ST
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.
4-29 s
s Job Attributes
AutoSys Behavior During Time Change

Jobs that are time dependent may have their scheduling shifted to adjust for the time change. Jobs that are not time dependent, but have other starting conditions, will run as normal. 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:
s days_of_week s exclude_calendar s run_calendar s run_window s 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:
s auto_delete s max_run_alarm s min_run_alarm s start_mins s term_run_time s watch_interval
During the time change, absolute time attributes will behave differently than relative time attributes, as described below.
s 4-30
Spring Time Change

During the change to daylight saving time in the spring, the 2:00-2:59 hour is lost, therefore AutoSys cannot schedule any jobs during that non-existent hour. The AutoSys solution is to schedule jobs with absolute time dependencies for the missing hour to start within the first minute of the 3:00 DT hour. For example, a job scheduled to run on Sundays at 2:05, will run at 3:00:05 that day; a job scheduled to run everyday at 2:45 will run at 3:00:45. Although it might not be possible to start a large number of jobs within the first minute of the hour, this feature does somewhat preserve the scheduling order. 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. Relative time dependencies, such as start_mins, will run as you would expect. For example, a job specified to run at 0, 20, and 40 minutes after the hour will be scheduled for 1:00 ST, 1:20 ST, 1:40 ST, 3:00 DT, 3:20 DT, and 3:40 DT. Relative interval calculations, such as max_run_alarm, min_run_alarm, term_run_time, and watch_interval are still calculated in minutes out from when the job started. For example, if our Sunday at 2:05 job has a term_run_time of 90 minutes, the job will start shortly after 3:00, the term_run_time will be at 4:30. 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
4-31 s
s Job Attributes
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.
Fall Time Change

During the change from daylight saving to standard time in the fall, there are two 1:00-1:59 hours. Jobs with start_times set between 1:00 and 1:59 will run only in the second, or Standard Time hour. Jobs with start_mins settings will run in both hours. 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
1:00
2:00
3:00
start_time attribute runs in second hour start_mins attribute runs in both hours
0:00
1:00
1:59
Daylight-saving Time
Figure 4-3 Scheduling between 1:00 - 1:59, DT to ST
s 4-32
Jobs that are not time-based, but have other dependencies, will still run during the first hour. Relative interval calculations, such as max_run_alarm, min_run_alarm, term_run_time, and watch_interval are still calculated in minutes out from when the job started. For example, if a job is scheduled to run on Sunday at 0:30, and has a term_run_time of 120 minutes, the job would normally be terminated at 2:30. On the day of the fall time change, it will terminate at 1:30 Standard Time, which is 120 minutes after the job started. 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.
4-33 s
s Job Attributes
s 4-34
5
Box Job Logic
This chapter explains how Box Jobs work, including default box behavior and how to override the default behavior. It also explains what types of jobs should and should not be placed in a box. To illustrate box logic, several examples of Box Job definitions and job streams are provided in Examples on page 5-10.
Basic Box Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3 Default Box Job Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3 When you Should Not Use a Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4 What Happens when a Box Runs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4 Box Job Attributes and Terminators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6 Attributes in a Box Job Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6 Attributes in a Job Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7 Time Conditions in a Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7 Force Starting Jobs in a Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8 How Job Status Changes Affect Box Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10 Advanced Conditions in Box Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11 Default Box Success and Box Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13 Explicit Box Success and Box Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15
5-1 s
s Box Job Logic
Using the Box Terminator Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-16 Using the Job Terminator Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-17 Advanced Job Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-18
s 5-2
Box Job Logic s Basic Box Concepts
Basic Box Concepts

A box is a container of jobs with like starting conditions (either date/time conditions or job dependency conditions). Use boxes to group jobs with like scheduling parameters, not as means of grouping jobs organizationally. For example, if you have a number of jobs that run daily at 1:00 a.m., you could put all these jobs in a box and assigning a daily start condition to the box. However, a variety of account processing jobs with diverse starting conditions should not be grouped in the same box.
Default Box Job Behavior

Some important rules to remember about boxes are:
s s s
Jobs run only once per box execution. Jobs in a box will start only if the box itself is running. As long as any job in a box is running, the box remains in RUNNING state; the box cannot complete until all jobs have run. By default, a box will return a status of SUCCESS only when all the jobs in the box have run and the status of all the jobs is success. Default SUCCESS is described in Default Box Success and Box Failure on page 5-13.
By default, a box will return a status of FAILURE only when all jobs in the box have run and the status of one or more of the jobs is failure. Default FAILURE is described in Default Box Success and Box Failure on page 5-13.
Unless otherwise specified, a box will run indefinitely until it reaches a status of SUCCESS or FAILURE. For a description of how to override this behavior, see Box Job Attributes and Terminators on page 5-6. Changing the state of a box to INACTIVE (via the sendevent command) changes the state of all the jobs in the box to INACTIVE.
5-3 s
s Box Job Logic

Basic Box Concepts
When you Should Not Use a Box

The fact that all jobs in a box change status when a box starts running has lead some to use boxes to implement job cycle behavior. Be aware that placing jobs in a box to achieve this end may bring with it undesired behavior due to the nature of boxes. Avoid the temptation to put jobs in a box as a short cut for performing events (such as ON_ICE or ON_HOLD) on a large number of jobs at once. You will most likely find that the default behavior of boxes inhibits the expected execution of the jobs you placed in the box. Likewise, you should not place jobs in a box solely because you want to run reports on all of them. When you run autorep on a box, you will get a report on the box and all the jobs in the box (unless you use the -L0 option). In addition, if you use wildcarding when specifying a job name, you could get duplicate entries in your report. For example, suppose you have a box named acnt_box containing three jobs named acnt_job1, acnt_job2, and daily_rep. If you specify acnt% as the job name for the autorep report, the report will have an entry for the box acnt_box and an entry for each job in the box. Then autorep will continue searching for all job names matching the wildcard characters and, thus, will list acnt_job1 and acnt_job2 a second time.
What Happens when a Box Runs

As soon as a box starts running, all the jobs in the box (including sub-boxes) change to status ACTIVATED, meaning they are eligible to run. (Because of this, jobs in boxes do not retain their statuses from previous box cycles.) Then each job is analyzed for additional starting conditions. All jobs with no additional starting conditions are started, without any implied ordering or prioritizing. Jobs with additional starting conditions remain in the ACTIVATED state until those additional dependencies have been met. The box remains in the RUNNING state as long as there are activated or running jobs in the box. If a box is terminated before a job in it was able to start, the status of that job will change directly from ACTIVATED to INACTIVE.
s 5-4
Box Job Logic s Basic Box Concepts
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 on page 5-9.) If a box changes to TERMINATED state, for example, if a user sends a KILLJOB event, it will stay in TERMINATED state until the next time it is started, regardless of any later state changes of jobs within the box.
Simple Box Job

In this example, a box named simple_box contains three jobs: job_a, job_b, and job_c. job_a and job_b have no starting conditions; the starting condition for job_c is the success of job_b.
job_a job_b SUCCESS job_b job_c
simple_box
Figure 5-1 Example Box Job
When simple_box starts running, all jobs change to state ACTIVATED. Because job_a and job_b have no additional starting conditions, they will start running. After job_b completes successfully, job_c will start. When job_c completes successfully, the box completes with status of SUCCESS.
5-5 s
s Box Job Logic

Box Job Attributes and Terminators
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 following sections describe how to use various job attributes to control the behavior of Box Jobs and their contained jobs.
Attributes in a Box Job Definition

Two Box Job attributes override the default success or failure of a box. They are box_success and box_failure. If included in a Box Job definition, they determine what conditions must be met to put the box in a state of SUCCESS or FAILURE. If you specify conditions for success of a box you should also specify failure conditions; otherwise the default failure conditions are applied.
Example of a Non-Default Success Condition

Using the above simple box example, assume you defined the following success condition for simple_box:
box_success: success(job_a)
If job_a runs successfully, and job_b is still running, job_c would pass from ACTIVATED state directly to INACTIVE state without ever running because the box it is in would no longer be running. When overriding default box terminators, be careful that you do not define conflicting success and failure conditions. For information, see Figure 5-6 on page 5-15.
s 5-6
Box Job Logic s Box Job Attributes and Terminators
Attributes in a Job Definition

There are two attributes you can add to the definition of a job within a box to force either the job or the box to stop running. They are box_terminator and job_terminator. 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 on page 5-16. 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 on page 5-17.
Time Conditions in a Box

Each job in a box will run only once per box execution. Therefore, you should not define more than one time attribute for any job in a box because the job will only run the first time. If you want to put a job in a box, but you also want it to run more than once, you must assign multiple start time conditions to the box itself, and define no time conditions for the job. Remember also that the box must be running before the job can start. Do not assign a start time for a job in a box if the box will not be running at that time. If you do, the next time the box starts, the job will start immediately. The following example illustrates a scenario that would not work properly if placed in a box. job_a is defined to run repeatedly until it succeeds. job_report has one starting conditionthe success of job_a.
5-7 s
s Box Job Logic

bx_stat 3:00 a.m. Daily
job_a run until succeed job_report success(job_a) Report success of job_a
Figure 5-2 Box Job with Time Conditions
At 3:00 a.m., bx_stat starts running, which causes job_a to start running. If job_a is successful, job_report runs and all goes as expected. However, if job_a fails, it will not be able to run again until the next time the box starts, because jobs run only once per box execution. job_report will still be ACTIVATED waiting for the success of job_a, and the status of the box will be RUNNING. The box will remain in this state indefinitely.
Force Starting Jobs in a Box

The FORCE_STARTJOB command forces a job to start even if its starting conditions have not been met. The command has the form:
sendevent -E FORCE_STARTJOB -J job_name
You can also execute this by selecting the Force Start Job option from the Actions menu in the Scheduler Console, or by using the Send Event Tool.
s 5-8
Box Job Logic s Box Job Attributes and Terminators
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 job_Fwatch run_stats success(job_Fwatch) box_terminator: y Run Statistics report_stats success(run_stats)
Watch for file
Report Statistics
Figure 5-3 Example Box Job
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.
How Job Status Changes Affect Box Status
If a box that is not running contains a job that changes status, as a result of a FORCE_STARTJOB or CHANGE_STATUS event, the new job status could change the status of its container box. A change of status of the box could trigger the start of downstream jobs that are dependent on the box. If a box contained only one job, and the job changed status, the box status would change as shown in Table 5-1.
5-9 s
s Box Job Logic

Examples
Table 5-1 How Job Status Changes Impact Box Status Current Box Status New Job Status New Box Status
SUCCESS SUCCESS FAILURE FAILURE INACTIVE INACTIVE TERMINATED
TERMINATED or FAILURE SUCCESS SUCCESS FAILURE SUCCESS TERMINATED or FAILURE any change
FAILURE Box status does not change SUCCESS Box status does not change SUCCESS FAILURE Box status does not change
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 userassigned). 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.
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.
s 5-10
Box Job Logic s Examples
Advanced Conditions in Box Jobs

In the following example, conditions are defined to address different situations where the box might complete with a FAILURE status. The logic of this job flow is as follows:
s
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. The Command Job named job_update updates a set of files. It is defined as being inside bx_daily_update. It will run as soon as bx_daily_update starts because it has no other starting conditions. This job has a box_terminator attribute; therefore, if this job fails, the box containing this job will be terminated. The Command Job named job_run_stats runs statistics on the updated files. It is defined as being inside bx_daily_update. It will run only on the successful completion of the job named job_update. This job has a box_terminator attribute; therefore, if this job fails, the box containing this job will be terminated. The Command Job named job_report_stats reports on the statistics generated by job_run_stats. It is defined as being inside bx_daily_update. It has a job dependency condition specified for its starting parameter. It will run only on the successful completion of the job named job_run_stats. The Command Job named job_trigger_msg has a job dependency condition specified for its starting parameter. It will run only on the FAILURE of the Box Job named bx_daily_update. This job will page an operator in order that the problem be investigated.
Figure 5-4 illustrates this job stream.
5-11 s
s Box Job Logic

Examples
bx_daily_update 3:00 a.m. daily
job_update box_terminator: y Update files
SUCCESS job_update job_run_stats success(job_update) box_terminator: y Run statistics
FAILURE job_update
SUCCESS job_run_stats FAILURE job_run_stats
job_report_stats success(job_run_stats) Report statistics
SUCCESS job_report_stats FAILURE job_report_stats SUCCESS bx_daily_update FAILURE bx_daily_update job_trigger_msg failure(bx_daily_update) Page operator SUCCESS job_trigger_msg
Figure 5-4 Advanced Box Job Example
s 5-12
Default Box Success and Box Failure

The Box Job do_statistics runs every day at 3:00 a.m. It contains three jobs. update_accounts updates files; it has no other starting conditions so it starts as soon as the box starts running. run_stats runs statistics; its only starting condition is the success of update_accounts. report_stats reports statistics; its only starting condition is the success of run_stats. No conditions for success or failure of the box have been defined, therefore the default conditions are applied. That is, box success is when all jobs in the box have run and successfully completed; box failure is when all jobs in the box have run and at least one has failed. The box will remain in the RUNNING state until all jobs in the box have run. Figure 5-5 illustrates this job stream logic.
5-13 s
s Box Job Logic

Examples
Job Stream
update_accounts
Job Status FAILURE
SUCCESS
run_stats success(update_accounts) FAILURE ACTIVATED
SUCCESS
report_stats success(run_stats)
FAILURE ACTIVATED ACTIVATED
SUCCESS
Box SUCCESS
Box FAILURE Box Still RUNNING
Figure 5-5 Box Success and Failure
s 5-14
Explicit Box Success and Box Failure

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 success(update_accounts) Update Files Run Statistics report_stats success(run_stats) Report Statistics Job Status
Job Stream
do_statistics
update_accounts
FAILURE
SUCCESS
run_stats
FAILURE INACTIVE
SUCCESS
report_stats FAILURE INACTIVE INACTIVE SUCCESS
Box
SUCCESS
FAILURE FAILURE FAILURE
Figure 5-6 Success and Failure Conditions
5-15 s
s Box Job Logic

Examples
Using the Box Terminator Attribute

Job Definitions
daily_accounts 3:00 a.m. Daily daily_receipts box_terminator: y Process Receipts daily_payables box_terminator: y Process Payables daily_balance success(daily_reciepts) AND success(daily_payables) Calculate Balance
Job Stream
daily_accounts
daily_receipts
daily_payables
SUCCESS
SUCCESS
FAILURE
FAILURE
Box
TERMINATED
SUCCESS
TERMINATED
daily_balance
Figure 5-7 Using box_terminator
s 5-16
Using the Job Terminator Attribute

Job Definitions
daily_accounts 3:00 a.m. Daily daily_receipts Process Receipts daily_payables job_terminator y : Process Payables daily_balance success(daily_reciepts) AND success(daily_payables) Calculate Balance
Job Stream
daily_accounts
daily_receipts
daily_payables
TERMINATE
SUCCESS
SUCCESS
FAILURE
FAILURE
Box
FAILURE
FAILURE
daily_balance
Figure 5-8 Using job_terminator
5-17 s
s Box Job Logic

Examples
Advanced Job Streams

Scenario on the first of the month
The first time cycle is run (e.g., January 1), statuses behave as expected.
Job Definitions
job_Fwatch 1:00 a.m. First Day of Month term_run_time: 90 Watch for File job_monthly 2:00 a.m. First Day of Month success(job_Fwatch) Re-index, Organize, Purge job_daily 3:00 a.m. Daily success(job_monthly) Generate Report
Job Stream
Date/Time Conditions Met Job Dependency Condition Met Start job_Fwatch File from Mainframe
SUCCESS
Date/Time Conditions Met
Start
job_monthly Event Status in AutoSys Database = SUCCESS
SUCCESS
Job Dependency Condition Met Start Date/Time Conditions Met SUCCESS job_daily
Figure 5-9 Jobs Run the First of Month
s 5-18
Scenario on the second of month

On days of the month other than the 1st, job_Fwatch and job_monthly do not run. They still have a status of SUCCESS in the AutoSys database from the previous run on the first of the month. As a result, job_daily will still run.
Job Definitions
job_Fwatch 1:00 a.m.First Day of Month term_run_time: 90 Watch for File job_monthly 2:00 a.m. First Day of Month success(job_Fwatch) Re-index, Organize, Purge job_daily 3:00 a.m. Daily success(job_monthly) Generate Report
Job Stream
Date/Time NOT Conditions Met Job Dependency Condition NOT Met Event Status in AutoSys Database = SUCCESS (from Jan 1) NOT RUN job_Fwatch File from Mainframe
NOT RUN Date/Time NOT Conditions Met
job_monthly
Job Dependency Condition Met Start Date/Time Conditions Met SUCCESS job_daily
Figure 5-10 Jobs Run the Second of Month
5-19 s
s Box Job Logic

Examples
Scenario I on first of the month

On the first of the next month (e.g., February 1), the file from the mainframe fails to arrive; therefore, job_monthly does not run for the month. However, its event status in the AutoSys database is still SUCCESS from the previous month, and as a result, job_daily runs in error.
Job Definitions
Job Stream
Date/Time Conditions Met Start job_Fwatch File from Mainframe
term_run_time: 90 Job Dependency Condition NOT Met NOT RUN Date/Time Conditions Met TERMINATED
job_monthly
Event Status in AutoSys Database = SUCCESS (from Jan 1)
Job Dependency Condition Met Start Date/Time Conditions Met job_daily
Undesirable Result
Figure 5-11 Incorrect Job Stream Logic
SUCCESS
s 5-20
Scenario II on first of the month

To fix statuses that are time-related, you can use a sendevent command to change them to INACTIVE at the end of their valid time period. You can create another job to do this automatically.
Job Definitions
At 1:00 a.m. on first day of month, issue a CHANGE_STATUS on job_monthly using GUI Send Event dialog or by issuing the following command:
sendevent -E CHANGE_STATUS -S INACTIVE -J job_monthl
Job Stream
Date/Time Conditions Met Start File from
job_Fwatch
term_run_time: 90 TERMINATED Condition NOT Met Job Dependency Date/Time Conditions Met NOT RUN job_monthly Event Status in AutoSys Database = INACTIVE Mainframe
Job Dependency Condition NOT Met NOT RUN Date/Time Conditions Met job_daily
Desirable Result
Figure 5-12 Changing Job Status
5-21 s
s Box Job Logic

Examples
Scenario III on first of the month

Instead of issuing a sendevent command to change the status of the jobs, you could put the monthly process in a box, and set box_failure or box_terminator appropriately.
box_monthly job_Fwatch 1:00 a.m.First Day of Month box_terminator: y Watch for File job_monthly success(job_Fwatch) job_terminator: y Re-index, Organize, Purge job_daily 3:00 a.m. Daily success(box_monthly) Generate Report
box_monthly Start job_Fwatch
Date/Time Conditions Met
File from Mainframe
SUCCESS FAILURE job_monthly
SUCCESS
TERMINATED
Job Dependency Condition Met
Job Dependency Condition NOT Met job_daily NOT RUN Date/Time Conditions Met
Start Date/Time Conditions Met
job_daily
SUCCESS
Figure 5-13 Changing Status using Box Jobs
s 5-22
6
Introduction to the Graphical User Interface
In AutoSys, the GUI refers to a set of windows and dialogs that you can use to define, monitor, and manage jobs. This chapter provides an introduction to the Graphical User Interface (GUI) components. You can access these components from the GUI Control Panel, which is also described in this chapter.
Starting the GUI Control Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2 Using the GUI Control Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2 GUI Control Panel Menu Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2 GUI Control Panel Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
6-1 s
s Introduction to the Graphical User Interface

Starting the GUI Control Panel
Starting the GUI Control Panel

To start the GUI Control Panel
Open the AutoSys Graphical Interface from its icon in the AutoSys program group.
This action opens the GUI Control Panel as shown in Figure 6-1.
Figure 6-1 GUI Control Panel
Using the GUI Control Panel

The GUI Control Panel has a menu bar and several buttons.
GUI Control Panel Menu Bar

The GUI Control Panel has the following menus:
s s s s
File Tools Preferences Help
s 6-2
Introduction to the Graphical User Interface s Using the GUI Control Panel
File Menu
The File menu contains the following options: Iconize All Exit Minimizes all the open AutoSys Graphical User Interface windows and dialogs. Closes all of the Graphical User Interface windows and dialogs, as well as the GUI Control Panel.
Tools Menu
The Tools menu contains the following options: Send Event Opens the Send Event Tool, which you can use to send AutoSys events, as well as cancel those previously sent events. For more information, see Using the Send Event Tool in Chapter 11, Scheduler Console. Opens the Run Status Tool, which you can use to view comprehensive information about the most recent run (or the current run) of a job. Opened from the GUI Control Panel, the Run Status Tool displays the job selected in the Scheduler Console, Alarm Manager, or in the AutoSys/Xpert windows. For more information on the Run Status Tool, see Using the Run Status Tool in Chapter 11, Scheduler Console.
Run Status Tool
Job Detail Report Opens the Job Detail Report tool, which displays an event or summary report for a job. Opened from the GUI Control Panel, the Job Detail Report tool displays the job selected in the Scheduler Console, Alarm Manager, or in the AutoSys/Xpert windows. For more information on the Job Detail Report tool, see Using the Job Detail Report Tool in Chapter 11, Scheduler Console.
6-3 s

Preferences Menu
The Preferences menu contains the following options: General Opens the General dialog, which you can use to set the DB Retry Count and the Alarm Color. In the DB Retry Count field, you can specify the number of times each GUI component tries to connect to the database. After the specified number of tries, the GUI stops trying to connect, and you must close and restart the GUI component to restart the retry count. The Alarm Color setting is used to indicate alarms in the Scheduler Console, Alarm Sentry, and Alarm Manager. The No Alarm Color is used in the Alarm Sentry to indicate there are no alarms for the instance. Removes all user settings for closed windows and dialogs. If you want to remove all user settings and return to the default settings, you must first close all GUI windows and dialogs, then select this option.
Remove All User Settings
Help Menu
The Help menu contains the following options: Contents About Displays the on-line help table of contents. Displays GUI Control Panel version number.
GUI Control Panel Buttons

These are the Control Panel buttons and the actions they perform: Scheduler Console Displays the Scheduler Console, which allows you to monitor AutoSys jobs and alarms across multiple instances. For information, see Chapter 11, Scheduler Console.
s 6-4
Introduction to the Graphical User Interface s Using the GUI Control Panel
Job Editor
Displays the Job Editor, which allows you to define AutoSys jobs. For information, see Chapter 7, Defining AutoSys Jobs using the Job Editor. Displays the Calendar Editor window, which allows you to define AutoSys run and exclude calendars. For information, see Chapter 9, Calendar Editor. Displays the Alarm Manager application, which allows you to view and respond to alarms across multiple instances. For information, see Chapter 12, Managing Alarms. Displays the Alarm Sentry dialog, which indicates if there is an alarm for any instance you are monitoring. For information, see Chapter 12, Managing Alarms.
Calendar Editor
Alarm Manager
Alarm Sentry
Monitor/Browser Displays the Monitor/Browser Editor, which allows Editor you to define and run monitors and reports (or browsers). For information, see Chapter 13, Monitoring and Reporting on Jobs. HostScape Displays the AutoSys/Xpert HostScape window, used for viewing AutoSys machines (and their jobs) in real-time or simulated mode. Displays the AutoSys/Xpert JobScape window, used for viewing job progressions (and their dependencies) in real-time or simulated mode. Displays the AutoSys/Xpert TimeScape window, used for viewing job progressions (across time) in real-time, real-time with projection, or simulated mode. Exits the GUI Control Panel.
JobScape
TimeScape
Exit
6-5 s

Note If you purchased and installed the AutoSys/Xpert product, the HostScape, JobScape, and TimeScape buttons are enabled. For information on using AutoSys/Xpert, see the AutoSys/Xpert User Guide.
s 6-6
7
Defining AutoSys Jobs using the Job Editor
This chapter provides a description of the Job Editor interface and its usage.
Starting the Job Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3 Using the Job Editor Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4 Job Editor Menu Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5 Job Editor Tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8 Job Editor Status Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8 Creating a Simple Command Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10 Creating a File Watcher Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12 Creating a Dependent Command Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-15 Creating a Box Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-19 Creating the EOD_box Box Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-19 Modifying the EOD_post Command Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-21
7-1 s
s Defining AutoSys Jobs using the Job Editor
Setting Date and Time Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-23 Setting Days of the Week Starting Conditions . . . . . . . . . . . . . . . . . . . . . . . . .7-25 Setting Time Starting Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-26 Example on Setting Date and Time Dependencies . . . . . . . . . . . . . . . . . . . . .7-27 Deleting Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-29 Notes on Deleting a Box Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-31 Specifying One-time Job Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-31 Setting Job Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-31 Deleting One-Time Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-33 Enabled Job Editor Fields for One-Time Overrides . . . . . . . . . . . . . . . . . . . . . .7-34
s 7-2
Defining AutoSys Jobs using the Job Editor s Starting the Job Editor
Starting the Job Editor

Use the Job Editor to create, modify, and delete job definitions for Command, File Watcher, and Box Jobs. To open the Job Editor
Single-click the Job Editor button in the GUI Control Panel.
This action opens the Job Editor for a Command Job, as shown in Figure 7-1. By default, the Job Editor opens in Command Job format. If you want to define a File Watcher or Box Job, choose New from the File menu, and indicate the Job Type, along with the Name and Instance, in the New Job dialog.
Note Not all of the Job Editor fields are described in this chapter, but the fields, based on their corresponding job attributes, are discussed in detail in Chapter 2, JIL/GUI Job Definitions in the AutoSys Reference Guide for Windows NT.
7-3 s

Using the Job Editor Interface
Figure 7-1 Job Editor

The Job Editor has a menu bar, a tabbed area, and a status area. The number of and type of tabs that are displayed are based on the type of job you are defining. The Job Editor displays different tabs and fields based on whether you are defining a Command Job, File Watcher Job, or Box Job. The Job Editor shown in Figure 7-1 is based on a Command Job.
s 7-4
Defining AutoSys Jobs using the Job Editor s Using the Job Editor Interface
Job Editor Menu Bar

The Job Editor menu bar includes the following menus: File, Edit, Options, and Help.
File Menu
The File menu includes the following options: New Displays the New Job dialog in which you enter the Name of the job, the Instance to which you are defining it, and the Job Type. The job Name must be unique to the instance. It must be from 1 to 30 alphanumeric characters, and it is terminated with white space (embedded white space is invalid). Job names cannot have the same names within an instance, but they can have the same name as a calendar definition in the instance. The Job Type can be a Command, Box, or File Watcher Job. After you indicate the required information in the New Job dialog, click OK to open the appropriate Job Editor display for the new job. Open Displays the Open dialog, which you can use to search for existing job definitions. In the Pattern field of this dialog, you can specify any string, including the % wildcard character, and then click Search to display a list of those jobs with names that include the string. The default % filter displays a list of all job names. You can also type the Job Name and click OK. Stores the currently displayed job in the database, either modifying a pre-existing job or creating a new definition. When you save a new job definition, this option displays the Save As dialog.
Save
7-5 s

Save As
Displays the Save As dialog, in which you can enter the Instance to which you want the definition saved and the new name for the job definition. If you are saving the definition to another instance, you can keep the same job definition name, if desired. Displays a Delete dialog, which you can use to search the database for all job definitions, and then select the definitions that you want to delete.
Delete
Delete Overrides Deletes overrides defined for the current job. This option is enabled only if there are one-time overrides defined for the job. You can also access this option from the Delete Override button on the Basic Scheduling tab. Add Overrides Enables the fields in the Job Editor that you can modify for one-time overrides. It disables all other fields. You can apply one-time overrides to a job, and they are for the next run only. You can also access this option from the Add One Time Override button on the Basic Scheduling tab. Displays the Save As dialog, which you can use to indicate a directory and file name to which the JIL definition for the current job is to be written. Prints the JIL definition for the current job. Displays a new, empty Job Editor window. Closes the Job Editor.
Export
Print New Job Editor Exit
Note When you first open a Job Editor, and when you use any of the dialogs to connect to another instance, AutoSys establishes a connection to that instances database and maintains that connection until you close the Job Editor.
s 7-6
Edit Menu
The Edit menu contains the following option: Clear Clears the Job Editor without affecting the database, but maintains the current job name.
Options Menu
The Options menu contains the following option: Adopt Session Context Toggles the session context feature on and off. The default setting is to have Adopt Session Context on (checked). When you select a job from the Scheduler Console or Alarm Manager, the open Job Editor updates to reflect the selected job. If you toggle this option to off, the open Job Editor does not update.
Help Menu
The Help menu contains the following option: Contents About Displays the Contents of the AutoSys Help. Displays the Job Editor version number.
7-7 s

Job Editor Tabs

The Job Editor displays all or part of the following tabs, depending on what job type you are defining: Basic Scheduling Date/Time Contains the job description and basic job attribute fields. Contains the date and time start-job condition and contains the time zone setting. Instead of setting specific date and time starting conditions, you can specify any run or exclude calendars for the job.
Alarms/Terminators Contains the minimum and maximum runtime, alarm behavior, and the box terminator settings. Misc Contains the settings for job restart, delete job after completion, and automatic hold for jobs in a Box Job, and it contains job-specific execute and edit permissions. Contains the queuing and load balancing, exit code, heartbeat interval, and file redirect settings. Contains the resource check and the path to the job profile settings.
Command Info Resource/Profile
Job Editor Status Area

The bottom portion, or status area, of the Job Editor lists the fields that require values for the job type you are defining. That is, each job type requires that you set specific attributes, and those attributes are listed in the status area of the window. Figure 7-1 (on page 7-4) shows a Job Editor for a Command Job, with the required settings displayed in the status area. In addition, the status area indicates syntax errors and other problems with the job definition.
s 7-8
All jobs require a Name, Job Type, and Owner. You indicate the Name and Job Type when you open a new Job Editor, or when you save a job definition. The Owner of the job is defined as the logged-on user who started the AutoSys GUI. In addition, each Job Type requires a set of values.
Required Values for Command Jobs

In addition to the Name, Job Type, and Owner, you must supply the following values for Command Jobs on the Job Editor Basic Scheduling tab: Command Indicates the command to run. When issuing commands that are to run on a different operating system, you must use the syntax appropriate to the operating system of the client machine on which the job will run. The job Owner must be able to log onto the specified client Machine and have operating system permissions to execute the specified command. Indicates the client machine on which to run the job. The job Owner must have permission to access this machine and to execute the specified command at this machine.
Machine
Required Values for Box Jobs

Name, Job Type, and Owner are the only required values for Box Jobs.
7-9 s

Creating a Simple Command Job
Required Values for File Watcher Jobs

In addition to the Name, Job Type, and Owner, you must supply the following values for File Watcher Jobs on the Job Editor Basic Scheduling tab: Machine Indicates the client machine on which to run the job. The job Owner must have permission to access this machine and to execute the specified command at this machine. For jobs running on NT machines, the owner must have a user account on the machine, and the associated logon ID and password must be entered into the AutoSys database (using the autosys_secure command). Indicates the name of the file to watch for. This must be a legal filename and full path to the file.
File to watch
Note You can use the File to watch setting in combination with the optional values Time Interval (in seconds) to determine steady state and Minimum file size (in bytes), which indicate when a file has arrived.

This section describes how to define a basic Command Job. These are the steps to define a job named test_run. This job has no starting parameters; when manually started, it echoes a message to standard output. To create the test_run example Command Job
1 In the GUI Control Panel, single-click the Job Editor button.
The Job Editor dialog opens for a Command Job.

2 In the Command field, enter the following command to be executed: echo AUTOSYS install test run
s 7-10
Defining AutoSys Jobs using the Job Editor s Creating a Simple Command Job
3 In the Send to Machine field, enter the machine on which the
command will be executed, by doing one of the following:

Click Add, enter a machine name, and click OK. Or Select localhost from the drop-down list, which specifies to run the
job on the Event Processor machine.

Note In the Send to Machine field, you must enter a valid, licensed client machine. If you Add a machine at this time, you should add your own machine name. In addition, for NT, you must have already entered into the AutoSys database a valid NT user ID and password for the Owners user account on the machine. If you use localhost, you must have an NT user ID and password in the AutoSys database for user@localhost (entered using the autosys_secure command). However, if you are running AutoSys with a Shadow Event Processor, you should not use the localhost machine setting. 4 From the File menu, choose Save.
The Save As dialog opens.

5 In the Save As dialog, select an Instance and enter the new job name, test_run. Then, click OK.
When the definition is written to the database, a confirmation dialog is displayed.

6 Click OK to dismiss the dialog.
Your entries in the Job Editor should look similar to those in Figure 7-2. Leave the Job Editor open and use it for the next example.
7-11 s

Creating a File Watcher Job
Figure 7-2 Job Editor for Command Job test_run
WARNING For the host portion of the Owner field, AutoSys uses the Host Name on the DNS tab of the TCP/IP Protocol dialog; it does not use the Computer Name on the Identification tab of the NT Control Panel Network dialog. Note The Owner field for the job defaults to the currently logged-on user, not the user shown in these examples. The Instance is the instance that you chose in the Save As dialog.

File Watcher jobs do not actually execute commands; they signal the arrival of files. Typically, File Watcher Jobs are used to initiate the execution of Command Jobs.
s 7-12
Defining AutoSys Jobs using the Job Editor s Creating a File Watcher Job
This section describes how to create a basic File Watcher Job. This job will watch for an end-of-day transaction file called EOD_trans_file, and it will have specific file watching criteria. To define a File Watcher Job Follow these steps using the open Job Editor:
1 Choose File New.
A New Job dialog opens, in which you can enter the Name, Instance, and Job Type.
2 In the New Job dialog: a Enter EOD_watch for the Name. b Select the appropriate Instance. c Select File Watcher from the Job Type drop-down list. d Click OK.
A Job Editor opens for this File Watcher Job.

3 In the File to watch field, enter this file name: c:\users\default\EOD_trans_file 4 In the Machine field, select either localhost (i.e., Event Processor
machine) or the machine you entered for the previous example. You must use a valid, licensed client machine, and you must have already entered into the AutoSys database a valid NT user ID and password for the Owners user account on the machine.
5 In the Time Interval (secs) to determine steady state field, enter the
following time interval:

60
7-13 s

This setting indicates that AutoSys will check for the files existence every 60 seconds, and it will check if the file has grown between checks. If the file has not changed in size, it is considered to be in a steady state.
6 In the Minimum file size (in bytes) field, enter the following: 50000
This setting indicates the minimum file size that should be reached before the file can be considered complete. Therefore, the file must reach 50000 bytes and be in a steady state before the File Watcher Job will complete with a SUCCESS status.
7 To save the job, choose File Save, which opens the Save As dialog,
and click OK. When the definition is written to the database, a confirmation dialog is displayed.
Your entries in the Job Editor should look similar to those in Figure 7-3. Leave the Job Editor open to use in the next example.
s 7-14
Defining AutoSys Jobs using the Job Editor s Creating a Dependent Command Job
Figure 7-3 Job Editor for File Watcher Job EOD_watch
Note The Owner field for the job defaults to the currently logged-on user, not the user shown in these examples. The Instance is the instance that you chose in the New Job dialog.
Creating a Dependent Command Job

This section describes how to create a Command Job that is dependent on the successful completion of the File Watcher Job you just created. Unlike the simple Command Job you created earlier, this Command Job is dependent on another job.
7-15 s

To create a Command Job with dependencies Follow these steps using the open Job Editor:
1 Choose File New.
A New Job dialog opens, in which you can enter the Name, Instance, and Job Type.
2 In the New Job dialog: a Enter EOD_post for the Name. b Select the appropriate Instance. c Leave the default Command setting for the Job Type. d Click OK.
A Job Editor opens for this Command Job.

3 In the Command field, enter the command that runs when the File
Watcher completes, for example:

%HOMEPATH%\post.exe
In this example, assume that the environment variable %HOMEPATH% means that the post executable is located in the job owners home directory.
4 In the Dependencies field, enter the starting condition, in this case the
successful completion of the file watcher job:

success(EOD_watch) Note If you want to add a list of Dependencies, you can click the button to the right of the field and enter the job dependencies in the Conditions dialog.
s 7-16
Defining AutoSys Jobs using the Job Editor s Creating a Dependent Command Job
5 In the Machine field, select either localhost (i.e., Event Processor
machine) or the machine you entered for the first example. You must use a valid, licensed client machine, and you must have already entered into the AutoSys database a valid NT user ID and password for the Owners user account on the machine.
6 Choose File Save, which opens the Save As dialog opens, and click
OK. When the definition is written to the database, a confirmation dialog is displayed.
The Job Editor should look similar to Figure 7-4. Leave the Job Editor open to use for the next example. For more information on defining job profiles, see Job Profiles in Chapter 3, AutoSys Jobs. For information on the profile job attribute, see Chapter 2, JIL/GUI Job Definitions in the AutoSys Reference Guide for Windows NT.
Note On NT, the jobs execution environment automatically includes NT System Variables and AutoSys-specific environment variables, but it does not include the NT User Variables. If you want to set the User Variables or any other variables for the job, you must define them in an AutoSys job profile using the Job Profiles Manager. Then you must indicate the appropriate profile on the Job Editor Resource/Profile tab in the Job Environment Profile field. The profile you indicate is used to set the variables immediately before the job is started.
7-17 s

Figure 7-4 Job Editor with Dependent Command Job EOD_post
s 7-18
Defining AutoSys Jobs using the Job Editor s Creating a Box Job
Creating a Box Job

A Box Job contains jobs with like starting conditions. For example, if you wanted to schedule a group of jobs to start running after a File Watcher Job completes successfully, you could create a Box Job to contain those jobs. Instead of making each individual job dependent on the File Watcher Job, you create a Box Job that is dependent on the File Watcher, and place all of the jobs in the Box. This section describes how to do the following:
s s
Create the EOD_box Box Job Modify the EOD_post job that you just created to put it in the box and make it no longer individually dependent on the File Watcher Job.
For detailed information on Box Jobs, see Chapter 5, Box Job Logic.
Creating the EOD_box Box Job

To define a Box Job Follow these steps using the open Job Editor:
1 Choose File New.
The New Job dialog opens.

2 In the New Job dialog: a Enter EOD_box for the Name. b Select the appropriate Instance. c From the Job Type drop-down list, select Box. d Click OK.
A Job Editor opens in which you can define this Box Job.
7-19 s

Creating a Box Job
3 In the Dependencies field, enter the following starting condition,
which is the successful completion of the File Watcher job:

success(EOD_watch) 4 Choose File Save, which opens the Save As dialog, and then click
OK. When the definition is written to the database, a confirmation dialog displays.
5 Click OK to dismiss the confirmation dialog.
The Job Editor should look similar to Figure 7-5. Leave the Job Editor open.
Figure 7-5 Job Editor for Box Job EOD_box
s 7-20
Defining AutoSys Jobs using the Job Editor s Creating a Box Job
Modifying the EOD_post Command Job

This section describes how to modify the existing EOD_post job to remove its dependencies and place it in the EOD_box Box Job you just created.
Note Before you modify any job, you must ensure that the job is not
running. To modify the EOD_post job Follow these steps using the open Job Editor:
1 Choose File Open.
The Open dialog opens, which you can use to search for and select existing job names.
2 In the Open Dialog, enter EOD% in the Pattern field. 3 Click Search.
The names of the jobs you defined in this chapter should be displayed, as shown in Figure 7-6.
7-21 s

Creating a Box Job
Figure 7-6 Open Dialog
Note In the Pattern field, 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. Typing just the % wildcard character will display all the jobs defined in the database. In addition, to open an existing job, you can enter the full job name directly into the Job Name field and click OK. 4 From the list of job names in the Open dialog, select EOD_post and
click OK. A Job Editor opens for this job.

5 In the Job Editor, delete the Dependencies setting. When you place
this job in a Box Job, it will inherit the Dependencies (starting conditions) of that box.
6 Click the Search button next to the Box field.
The Box Selection dialog opens, as shown in Figure 7-7.
s 7-22
Defining AutoSys Jobs using the Job Editor s Setting Date and Time Dependencies
Figure 7-7 Box Selection Dialog
7 In the Box Selection dialog, enter EOD_box in the Box Name field and
click OK. This Box Job is entered in the Job Editor Box field, placing the EOD_post Command Job in the Box Job.
Note You can also enter the Box Job name directly into the Box
field of the Job Editor.

8 Choose File Save.
When the job definition is written to the database, a confirmation dialog displays.
Leave the Job Editor open.
Setting Date and Time Dependencies

You can use the Job Editor Date/Time tab to set starting conditions based on calendars, days of the week, and times of the day.
7-23 s

To bring the Job Editor Date/Time tab to the front, click the tab. To enable the fields, click the Date/Time Conditions checkbox, as shown in Figure 7-8.
Figure 7-8 Job Editor Date/Time Tab
After you enable the tab, you must select both a Day setting and a Time setting. The Day settings are on the left side of the dialog, and the Time settings are on the right side. In addition, you can set the Time Zone for the job. The Time Zone indicates that the selected time settings should be based on that particular zone setting. If you do not set a Time Zone for the job, AutoSys uses the time zone of the Event Server. You can also assign a specific run window. The Run Window setting is in a 24-hour format, and it indicates the span of time during which the job will be allowed to start.
s 7-24
Setting Days of the Week Starting Conditions

When setting Date conditions, you can indicate that a job should run on specific days of the week or on all days of the week. You can also use a custom calendar to indicate that a job should run on the days defined in the calendar, or that it should not run on the days indicated in the calendar. When you set Date conditions, you must also set Time conditions to indicate the time of day the job should run.
Note You can set only one of the Run Days or Run Calendar Date options. They are exclusive settings. However, you can set an Exclude Calendar in combination with either of these Date options.
Setting the Run Days Option

You can define a job to run one or more days a week. To define your job to run on one or more days of the week
Select the Run Days radio button, and then click the checkboxes next to the days of the week on which you want the job to run.
To define your job to run on all the days of the week

Select the Run Days radio button, and then click the All button.
To clear the selected days

Click the None button.
Setting Run Calendar and Exclude Calendar Options

You can define jobs to run on specific dates, rather than specific days of the week. To do this, you must define a calendar by using the Calendar Editor, and then you set that calendar as the Run Calendar.
7-25 s

To define a job to use an existing calendar and run on specific dates

Click the Run Calendar radio button, and then select a calendar name from the Run Calendar drop-down list.
Alternatively, you can specify a calendar that defines days on which the job must not run. To do this, you must define a calendar, by using the Calendar Editor, and then you set that calendar as the Exclude Calendar. To define a job to use an existing calendar to not run on specific dates
Click the Exclude Calendar radio button, and then select a calendar name from the Exclude Calendar drop-down list.
To modify an existing calendar or create a new calendar

Click the Edit Calendars button. This action opens the Calendar Editor.
For information on using the Calendar Editor, see Chapter 9, Calendar Editor.
Setting Time Starting Conditions

After you set the date condition, you must set a time starting condition. The time starting condition indicates that AutoSys should run the job at that time, or times, on the days or dates on which the job is defined to run. To indicate that the job should run anytime after midnight
Select the Anytime After Midnight radio button.
To define a job to run at a specific time of day

Select the Times of Day radio button and indicate the time of day in the field below it.
Separate multiple time settings with commas. The times you indicate in this field must be in a 24-hour format.
s 7-26
To define a job to run at specific times past every hour

Select the Minutes after Each Hour radio button and indicate the number of minutes past that time in the field below.
The minute values you indicate in this field must be a number between 1 and 59. You can use a comma-separated list to indicate more than one setting. To define a job to run at regular intervals past every hour
Select the Minutes after Each Hour radio button, enter a minute setting in the Every Minutes field, and click Apply.
This sets the minutes interval in the Minutes after Each Hour field. The Every Minutes settings must be a number between 1 and 59.
Setting Time Zones

You can base the time settings for a job on a specific time zone. To do this, you enter a valid time zone in the Time Zone field (above the time settings on this tab). For information on specifying a time zone in a job definition, see timezone in Chapter 2, JIL/GUI Job Definitions in the AutoSys Reference Guide for Windows NT.
Example on Setting Date and Time Dependencies

The test_run job you created at the beginning of the chapter can only be executed if it is started manually, by using the Send Event Tool or the sendevent command. However, you could define this job to run on certain days at certain times. This section describes how to modify the job to run at 10:00 a.m. and 2:00 p.m. on Mondays, Wednesdays, and Fridays.
7-27 s

To modify the test_run job to add time and date dependencies Follow these steps using the open Job Editor.
1 Choose File Open.
The Open dialog opens.

2 In the Open dialog, enter test_run in the Job Name field, and then
click OK. A Job Editor opens with the test_run job definition.
3 Click the Date/Time tab to bring it to the front. 4 Click the Date/Time Conditions checkbox to enable the fields on this
tab.
5 Select the Run Days radio button and single-click the Monday,
Wednesday, and Friday checkboxes. You can toggle the day checkboxes on and off; they are not mutually exclusive.
6 Select the Times of Day radio button, then enter the following times
(in a 24 hour format) in the enabled field:

10:00, 14:00 Note The times do not have to be enclosed in quotes when they
are entered in the Job Editor, unlike jobs entered using the Job Information Language (JIL).
7 Choose File Save.
A confirmation dialog is displayed to indicate the next start time.

After the definition is written to the database, another confirmation dialog is display.
9 Click OK to dismiss the second confirmation dialog.
s 7-28
Defining AutoSys Jobs using the Job Editor s Deleting Jobs
The Job Editor Time/Date tab should look similar to Figure 7-9. Leave the Job Editor open to use in the next example.
Figure 7-9 Date/Time Tab for test-run
Deleting Jobs
You can use the Job Editor to delete job definitions from the database. You can delete any jobs, regardless of type, in the same way. To delete a job definition, however, you must be either the Owner of the job or the AutoSys Edit Superuser. To delete a job, follow these steps using the open Job Editor
1 Choose File Delete.
The Delete Jobs dialog opens. It should look similar to Figure 7-10.
7-29 s

Deleting Jobs
Figure 7-10 Delete Jobs Dialog
2 Ensure that you are operating on the correct Instance. Then, in the
Pattern field, enter a name, partial name with the % wildcard character, or the % wildcard character. Click Search. A list of job names based on your search is displayed.
3 From the list of job names, select one or more jobs to delete. To select
one job, click it. To select a continuous section of jobs, click a job, press <Shift> and click the ending of the list. To select several jobs in the list, press <Control> and click each job. You must select at least one job.
4 Click OK.
A confirmation dialog displays.

5 Click OK to close the dialog and delete the job(s).
s 7-30
Defining AutoSys Jobs using the Job Editor s Specifying One-time Job Overrides
Note If you have a job open, and you delete it using the Delete Jobs dialog, it will still be in the Job Editor. If you change any setting and try to open another definition, you are asked if you want to save the current (deleted) definition. If you choose to save it, the job definition is written to the database (as if it is a new definition).
Notes on Deleting a Box Job

When using the Job Editor to delete a Box Job, AutoSys will delete the box and all jobs within that box. Currently, there is no way to delete just the box itself and not its contents when using the Job Editor. For information on deleting Box Jobs with JIL, see Deleting a Job in Chapter 8, Defining Jobs Using JIL.
Specifying One-time Job Overrides

Using the Job Editor, you can specify a one-time job override for the next run of a particular job. That is, if you specify an override, the job definition and the job run behavior are changed only for the next time a job runs.
Setting Job Overrides

To enter a one-time override
1 Open a job in the Job Editor. 2 Turn on the override mode by doing one of the following: Choose File Add Override. Or On the Basic Scheduling Tab, click the Add One Time Override
button.
7-31 s

Both of these actions disable the fields that you cannot modify for one-time overrides. The Job Editor fields that you can use in a job override definition are listed in Table 7-1 through Table 7-3, starting on page 7-34.
3 Use the Job Editor to specify overrides. Enter new values into the
fields, or enter NULL to turn off the set value.

Note To specify a date or time override, bring the Date/Time tab to the front and select one of the choices from the drop-down list. This action will enable the appropriate fields. 4 Choose File Save.
When the modified definition is written to the database, a confirmation dialog is displayed.
Notes on One-time Overrides

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 reissue a job override until the job actually runs once, or until the maximum number of retries limit is met. After this, the override is deleted. One-time job overrides are applied to jobs that are restarted due to system problems, but are not applied to jobs restarted because of application failures. System problems include machine unavailability, media failures, and insufficient disk space. Application failures include inability to read or write a file, command not found, exit status greater than the defined maximum exit status for success, and various syntax errors.
s 7-32
You cannot submit an override if it results in an invalid job definition. For example, if you enter NULL in the Times of Day field only, and not in the specified Time setting, the definition becomes invalid, because removing only one of the Date/Time start condition makes the job definition invalid. The Job Editor fields that you can use in a job override definition are listed in Table 7-1 through Table 7-3, starting on page 7-34.
Note The maximum number of job restarts after system or network failures is specified in the Max Restart Trys field on the AutoSys Administrator Event Processor screen.
Deleting One-Time Overrides

To delete the one-time job overrides
1 In the Job Editor, open the job for which you want to delete the
overrides.
Note If the job is already open in the Job Editor, you must save it
before you can delete the defined overrides.

2 Do one of the following: Click the Delete Override button on the Basic Scheduling tab. Or Choose File Delete Overrides.
Both of these actions displays a confirmation dialog. Click Yes in this dialog to delete the defined overrides.
3 Choose File Save. When the job definition is written to the database,
a confirmation dialog is displayed. Click OK to dismiss the dialog.
7-33 s

Enabled Job Editor Fields for One-Time Overrides

The tables in this section list the fields that are enabled for one-time overrides.
Table 7-1 Job Editor Fields for Command Job Overrides Tab Basic Scheduling
s s s
Fields
Command Dependencies Send To Machine All conditions, except the Time Zone setting Minimum Run Time (Alarms) Maximum Run Time (Alarms) Terminate this job minutes after starting (Terminators) Number of times to restart this job after failure Delete Job after completion AutoHold for jobs in boxes File to redirect standard input File to redirect standard output File to redirect standard error Job Environment Profile
Date/Time Alarms/Terminators
s s s s
Misc
s s
Command Info
s s s
Resource/Profile
s 7-34
Table 7-2 Job Editor Fields for Box Job Overrides Tab Basic Scheduling Date/Time Alarms/Terminators
s s s s s
Fields
Dependencies All conditions, except the Time Zone setting Minimum Run Time (Alarms) Maximum Run Time (Alarms) Terminate this job minutes after starting (Terminators) Number of times to restart this job after failure Delete Job after completion AutoHold for jobs in boxes
Misc
s s
7-35 s

Table 7-3 Job Editor Fields for File Watcher Job Overrides Tab Basic Scheduling
s s s s s
Fields
File to watch Dependencies Send To Machine Time interval (secs) to determine steady state Minimum file size (in bytes) All conditions, except the Time Zone setting Minimum Run Time (Alarms) Maximum Run Time (Alarms) Terminate this job minutes after starting (Terminators) Number of times to restart this job after failure Delete Job after completion AutoHold for jobs in boxes Job Environment Profile
Date/Time Alarms/Terminators
s s s s
Misc
s s
Resource/Profile
s 7-36
8
Defining Jobs Using JIL
This chapter describes how to define jobs using the AutoSys Job Information Language or JIL. It also provides information about creating various types of AutoSys jobs. It discusses changing and deleting a job, and how to set time dependencies. An example JIL script is provided.
Job Information Language (JIL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3 JIL Syntax Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3 JIL Sub-commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5 Submitting Job Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-6 Running JIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-6 Creating a Simple Command Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7 Creating a File Watcher Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7 Creating a Dependent Command Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8 Creating a Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-10 Changing a Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-11 Setting Time Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-12 Additional Time Setting Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-13
8-1 s
s Defining Jobs Using JIL
Deleting a Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-14 Deleting a Box Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-14 Specifying One-Time Job Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-15 Setting Job Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-16 Example JIL Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-17
s 8-2
Defining Jobs Using JIL s Job Information Language (JIL)
Job Information Language (JIL)

Job Information Language JIL) is a scripting language which provides a way to specify how AutoSys jobs should behave. JIL scripts contain one or more JIL sub-commands and one or more attribute statements; these elements constitute a job definition. When you are using JIL commands you must use the AutoSys Instance Command Prompt window, which is located in the instances AutoSys program group. This window sets several environment variables that are needed to run the AutoSys commands.
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.
JIL Syntax Rules

When writing a JIL script, you must follow the syntax rules listed below.
Rule 1
Each sub-command uses the following form:
sub_command: job_name
where:
sub_command
Is one of the sub-commands listed in Table 8-1.

job_name
Is the user-specified name of the job to be acted upon.
8-3 s

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
Is one of the legal JIL attributes.

value
Is the setting to be applied to the attribute.
Rule 3
Multiple attribute statements can be entered on the same line, 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: upperand 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 statements 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.
s 8-4
Defining Jobs Using JIL s Job Information Language (JIL)
Note When specifying drive letters in commands, the colon ( : ) must be escaped. That is, "C:\tmp" and C\:\tmp are valid; C:\tmp is not.
Rule 7
Comments are indicated using one of the following two methods:
s
An entire line can be commented by placing a pound sign # in the first column.
Or
The C programming syntax used for beginning a comment with /* and ending it with */ may be used; this allows comments to span multiple lines. The following is an example:
/* this is a comment */
JIL Sub-commands
JIL sub-commands are used to create, modify, override, or delete a job definition. These sub-commands are listed in Table 8-1.
Table 8-1 Primary JIL Sub-commands for Defining Jobs Sub-command insert_job update_job delete_job delete_box override_job Action
Add a new job to AutoSys. Edit fields on an existing job. Delete an existing job from the AutoSys database. Delete an existing Box job, and recursively delete all the jobs which are contained in the box. Apply overrides on indicated job attributes for the next run of this job.
8-5 s

Submitting Job Definitions

As stated earlier, a completed JIL script is called a job definition. This job definition must be submitted to the AutoSys database before the job it defines can be run. You can submit a job to the AutoSys database using one of the following methods (at the AutoSys Instance Command Prompt window that is associated with the AutoSys instance for which you are defining this job):
s
Submit it by redirecting a JIL script file to the jil command, for example:
jil < my_jil_script
Interactively submit it by issuing the jil command and pressing Return. Then entering JIL statements at the provided jil>> prompts. To exit interactive mode, enter exit at the prompt, or press <Control+d>.
Both of these methods are analogous to saving a job definition in the GUI, using the Job Editor.
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.
s 8-6
Defining Jobs Using JIL s Creating a Simple Command Job
For more information about the sendevent command, see its definition in Chapter 1, AutoSys Commands in the AutoSys Reference Guide for Windows NT.

To create the most basic Command Job, you only need to specify a few attributes. For example, the JIL script required to define a simple Command Job named test_run is given below:
insert_job: test_run job_type: c /*(optional, it is the default) */ machine: tibet command: "C:\MYAPPS\DOREPORTS.BAT"
This JIL script instructs AutoSys:

s s s s
To add a new job named test_run. That the new job is a Command Job. To run the job on the client machine named tibet. To execute the C:\MYAPPS\DOREPORTS.BAT batch file.

File Watcher Jobs do not execute commands themselves; they are used to signal the arrival of files, and typically set off the execution of a Command Job. For example, the JIL script required to define a File Watcher Job named EOD_watch is given below:
insert_job: EOD_watch job_type: f machine: tibet watch_file: "C:\tmp\EodTransFile" watch_interval: 60 watch_file_min_size: 50000
8-7 s


s s s s
To add a new job named EOD_watch. That the new job will be a File Watcher Job. To run the job on the client machine named tibet. To watch for a file named EodTransFile in the C:\tmp directory (this file will contain end of day transactions). Check the file every 60 seconds. Determine if the file has reached the minimum file size of 50,000 bytes.
s s
Until the minimum file size of 50,000 bytes has been reached, the file wont 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.

Command Jobs can be dependent on the successful completion of other jobs, such as the File Watcher Job created in the previous section. The only difference between a dependent Command Job and a simple Command Job is its dependency on another job.
s 8-8
Defining Jobs Using JIL s Creating a Dependent Command Job
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: %HOMEPATH%\POST.EXE

s s s s
To add a new job named EOD_post. That the new job will be a Command Job. To run the job on the client machine named tibet. To run the job only if the File Watcher Job named EOD_watch completes with a SUCCESS status. To set the %HOMEPATH% variable, set all environment variables in the default job profile, then execute POST.EXE, which resides in the owners home directory. (%HOMEPATH% and NT system variables are the only variables that are automatically set. All other non-system variables must be set in the default or user-defined job profile. You can define these profiles using the Profiles Manager, which is in the AutoSys program group.)
8-9 s

Creating a Box
Note The jobs execution environment automatically includes NT system environment variables, but NT user defined environment variables are not set automatically. All other variables must be defined by a job profile; the jobs execution environment is determined by the profile, which contains the user defined environment variables that are necessary to run the job. The profile is sourced immediately before the job is started. By default, the default profile is sourced. However, on NT, the default is initially blank; you must define the default profile. You can define the default profile and other profiles using the Profiles Manager, which you can open from the AutoSys program group. To associate a profile, other than the default, with a job, use the profile attribute, or use the Job Environment Profile field in the Job Editor, on the Resource/Profile tab.
For more information on defining job profiles, see Job Profiles in Chapter 3, AutoSys Jobs. For information on the profile job attribute, see its entry in Chapter 2, JIL/GUI Job Definitions in the AutoSys Reference Guide for Windows NT.
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.
s 8-10
Defining Jobs Using JIL s Changing a Job
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)

s s s
To add a new job named EOD_box. That the new job will be a Box Job. To run the job only if the File Watcher Job named EOD_watch completes with a SUCCESS status.
For information on Box Jobs, see Chapter 5, Box Job Logic.
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, youll have to respecify any of the attributes that need to remain the same. So, in the
8-11 s

Setting Time Dependencies
example below, youll 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

s s
To update the job named EOD_post. Remove the starting condition from the job definition, because the job will inherit the starting condition of the box in which it is placed. Put the job named EOD_post in the box named EOD_box.
The EOD_post Command Job is now in the EOD_box Box Job, and has inherited the boxs starting parameters.
Setting Time Dependencies
The test_run job you specified at the beginning of the chapter has no starting conditions. Therefore, it will only run if it is started using the sendevent command. To set the job to run automatically on certain days at a certain time, such as 10:00 a.m. and 2:00 p.m. on Mondays, Wednesdays, and Fridays, you would modify the job using this JIL script:
update_job: test_run date_conditions: y days_of_week: mo, we, fr start_times: "10:00, 14:00"

s s
To update the job named test_run. Activate the conditions based on date.
s 8-12
Defining Jobs Using JIL s Setting Time Dependencies
s s
Set the job to run on Mondays, Wednesdays, and Fridays. 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
Additional Time Setting Features

If you wanted the time settings for the job to be based on a specific time zone, you would use the timezone attribute. If you specify a time zone that includes a colon, you must quote the time zone name like this:
timezone: "IST-5:30"
If you do not quote a time zone that contains a colon, the colon will be interpreted as a delimiter, producing unexpected results. 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 Calendar Editor, 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
8-13 s

Deleting a Job
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
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).
Deleting a Box Job

To delete a box, and recursively delete every job in that box
Use the delete_box sub-command, like this:
delete_box: EOD_box
To delete a box, but leave its contents intact

Use the delete_job sub-command on the box, like this:
delete_job: EOD_box
Using JIL, there are a number of other attributes which you can configure. These attributes are described in detail in Chapter 2, JIL/GUI Job Definitions in the AutoSys Reference Guide for Windows NT. This reference chapter provides complete information on all job attributes specified using JIL.
s 8-14
Defining Jobs Using JIL s Specifying One-Time Job Overrides
Specifying One-Time Job Overrides

Using JIL, you can specify a job override for the next run of a particular job. In other words, the next time a job runs, you can change its behavior. Job overrides are applied only once. 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.
Note The maximum number of job restarts after system or network failures is specified in the Max Restart Trys field on the AutoSys Administrator Event Processor screen. One-time job overrides will be applied to jobs restarted due to system problems, but will not be applied to jobs restarted because of application failures. System problems include such things as machine unavailability, media failures, or insufficient disk space. Application failures include such things as inability to read or write a file, command not found, exit status greater than the defined maximum exit status for success, or various syntax errors.
The following attributes can be modified in a job override:

auto_hold command condition date_conditions days_of_week exclude_calendar machine max_run_alarm min_run_alarm n_retrys profile run_calendar run_window start_mins start_times std_err_file std_in_file std_out_file term_run_time watch_file watch_file_min_size watch_interval
8-15 s

Specifying One-Time Job Overrides
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).
Setting Job Overrides

To set job overrides, you use the override_job sub-command; you only need to specify those attributes that you want to override. Using this command, you can also temporarily delete a job attribute. For example, if you wanted to run a job named RunData with no conditions (where some had been previously specified) and you wanted to output the results to a different output file, you would enter a JIL script like this:
override_job: RunData condition: NULL std_out_file: "C:\tmp\SpecialRun.out"
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 Job Editor. However, the original override (i.e., the first over_num) remains stored in the overjob table in the AutoSys database.
s 8-16
Defining Jobs Using JIL s Example JIL Script
Example JIL Script

The following is a full example of an AutoSys JIL script. It incorporates the creation and use of a Command Job, a File Watcher Job, and a Box Job. This is the processing scenario:
s
A file named C:\DOWNLOAD\MAINFRAME\SALE.RAW is expected to arrive from the mainframe sometime after 2:00 a.m. When the file arrives, it is processed by the command file named filter_mainframe_info, and the results are placed in the file named C:\DOWNLOAD\MAINFRAME\SALES.SQL. When the above functions are completed, the file named C:\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: "C:\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: "C:\DOWNLOAD\MAINFRAME\SALES.RAW" std_out_file: "C:\DOWNLOAD\MAINFRAME\SALES.SQL" std_err_file: "C:\LOG\FilterMFLog.err"
8-17 s

Example JIL Script
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: "C:\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 NT.
s 8-18
9
Calendar Editor
This chapter describes how to create calendars by using the Calendar Editor and how to use the calendars you create with jobs.
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3 Using Defined Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4 Scheduling Jobs with Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4 Starting the Calendar Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-6 Using the Calendar Editor Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7 Using the Menu Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7 Using the Navigation Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-12 Using the Calendar Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14 Creating and Modifying Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-16 Creating a Calendar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-16 Opening an Existing Calendar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-18 Applying Rules to Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-19 Using the Rule Specification Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-21 Using the Rescheduling Rule Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-25
9-1 s
s Calendar Editor
Combining Existing Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-28 Combining Calendars Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-28 Using the Job Definition Reference List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-29 Importing and Exporting Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-30 Importing Calendar Text Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-31 Exporting Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-32
s 9-2
Calendar Editor s Introduction
Introduction
The Calendar Editor provides a method of defining and maintaining AutoSys calendars using a point and click approach on a graphical display of a conventional calendar. After defining a calendar, you can apply it to jobs through the job definition, either using JIL or the Job Editor. The Calendar Editor allows you to do the following:
s s
Define simple calendars. Set, unset, or block certain dates, such as holidays, when editing calendars. Apply custom rules to a calendar, such as the first weekday of every month, rather than selecting the individual dates by hand. Select options that will automatically reschedule conflicting dates when applying a rule. Conflicting dates are those that are blocked out but also meet the qualifications of the rule being applied. A number of alternatives for rescheduling are provided. Build a new calendar by overlaying multiple, pre-existing calendars, and allowing you to further customize the new calendar manually. Preview a calendar before applying it to another calendar. Import and export text definitions for calendars.
s s
9-3 s
s Calendar Editor
Using Defined Calendars
Using Defined Calendars

After you define a calendar using the Calendar Editor, you can use it to schedule jobs. Using defined calendars simplifies job scheduling by letting you group any collection of dates into a single entity.
Scheduling Jobs with Calendars

In the job definition, use one of the following methods to apply a calendar:
s
With the GUI, go to the Job Editor Date/Time tab, select either Run Calendar or Exclude Calendar, and select a calendar from the drop-down list. With JIL, use a single attribute in the job definition: either run_calendar or exclude_calendar.
You can set the calendar in conjunction with other time attributes to precisely control when a job will or will not start. For example, you could create a calendar called holidays containing the dates of all corporate holidays. Then, you could define the job with the Job Editor, you would do the following:
1 On the Date/Time tab, click the Date/Time Conditions checkbox.
This action checks the box and enables the fields on the Date/Time tab.
2 Do one of the following
For a job that you want to start on holidays, click on the Run Calendar radio button.
Or
For a job that you do not want to start on holidays, click on the Exclude Calendar checkbox.
s 9-4
Calendar Editor s Using Defined Calendars
3 Select the defined holiday calendar from the calendar drop-down list
that is to the right of the option you selected.

4 Define the other attributes for the job appropriately. 5 Choose File Save to save the new job definition.
When using these attributes, or their Job Editor field equivalents, keep the following in mind.
s
Jobs scheduled with a Run Calendar are scheduled to start on every day specified in the calendar, at the times specified in the calendar or in the Times of Day or Minutes after Each Hour attribute. If present in the job definition, both of these attributes override the times specified for the defined Run Calendar. If no start time is specified, jobs scheduled by a calendar start at midnight, by default.
Note You can only assign times to calendars when using the command-line calendar definition tool, autocal_asc. For information, see autocal_asc in Chapter 1, AutoSys Commands, of the AutoSys Reference Guide for Windows NT.
Jobs scheduled with the Run Calendar are scheduled to run on the next available date in that calendar. Dates previous to the current date are ignored. Jobs scheduled with an Exclude Calendar can make use of other starting conditions in the job definition. In this case, AutoSys evaluates the start conditions and, if they are true, checks if the date is set in the Exclude Calendar. If the date is in the defined calendar, the job will not be started, and its status will be changed to INACTIVE.
For information on using the Job Editor, see Chapter 7, Defining AutoSys Jobs using the Job Editor. For information on these attributes, see their reference pages in Chapter 2, JIL/GUI Job Definitions in the AutoSys Reference Guide for Windows NT.
9-5 s
s Calendar Editor
Starting the Calendar Editor
Starting the Calendar Editor

To start the Calendar Editor
1 Open the GUI Control Panel from the AutoSys Graphical Interface
icon in the AutoSys program group.

2 Click the Calendar Editor button in the GUI control panel. This opens
the Calendar Editor, as shown in Figure 9-1.
Figure 9-1 Calendar Editor
s 9-6
Calendar Editor s Using the Calendar Editor Interface
Using the Calendar Editor Interface

The Calendar Editor is divided into the following regions:
s s s
Menu Bar Navigation Controls Calendar Display
Using the Menu Bar

At the top of the Calendar Editor is the menu bar that contains the following menus: File, Edit, Utilities, Preferences, and Help.
File Menu
The File menu contains the following options: New Displays the New Calendar dialog in which you enter the Instance and new Calendar Name, then click OK. The new Calendar Name must be a unique job name for the specific instance. The name must be from 1 to 30 alphanumeric characters, and white space indicates the end of the name. Embedded spaces and tabs are illegal. When you click OK, an empty Calendar Editor displays. Displays the Calendar Selection dialog that you can use to open an existing calendar. Saves the calendar currently being edited and writes it to the AutoSys database, using its current name. The first time you save a calendar, this option displays the Save As dialog.
Open Save
9-7 s
s Calendar Editor
Save As
Displays the Save As dialog in which you can enter both the name of the Instance to which you want the calendar saved and the new calendar name for the calendar. If you want to save a definition to another instance and keep the definition for the current instance, you can use this option to do so, and you can keep the same calendar name for the new instance. Displays the Delete Calendar dialog in which you can search for and select the calendar or calendars to delete. Displays the Rename dialog in which you can enter a different instance and/or a new name for the calendar you are saving. Before you can use this option, the calendar definition must be saved to the defining instance. When you rename a calendar, it is saved to the new name, and the old calendar definition is deleted from the database. If you want to keep the current definition in the database, use the Save As option. Displays the Open dialog that allows you to select the directory and filename of a text file that contains calendar definitions that you want to import into the AutoSys database. Displays the Save As dialog that permits you to select the directory and name of the file to which you want to save all the calendars in the database, in text form. You can export all definitions at once only. Prints the current calendar in text format. Prints the current calendar in a graphical format, as it appears on the screen.
Delete
Rename
Import
Export All
Print Graphical Print
s 9-8
New Calendar Editor Exit
Opens another Calendar Editor window. When you open other Calendar Editors, each window is numbered sequentially. Exits the application.
Note When you first select an instance in any of the Calendar Editor dialogs, AutoSys establishes a connection to that instances database. It maintains that connection until you close the Calendar Editor.
Edit Menu
The Edit menu contains the following options: Apply Rule Displays the Term Calendar Rule dialog in which you can set multiple dates using a variety of rule options. For more information, see Applying Rules to Calendars on page 9-19. Resets the state of all the dates in the current calendar to those last saved to the AutoSys database. Clears the calendar settings; all dates are returned to the unset state.
Revert Clear
9-9 s
s Calendar Editor
Utilities Menu
The Utilities menu contains the following option: Job Definition Reference List Displays the Job Definition Reference List dialog, which contains a list of all the jobs that reference the calendar you are currently editing, either as their Run Calendar or Exclude Calendar. This list is read only, and it indicates which jobs will be affected by any changes you make to the current calendar. For more information, see Using the Job Definition Reference List on page 9-29.
Note When you update a calendar, AutoSys recomputes the starting
times for all jobs that use that calendar.
Preferences Menu
The Preferences menu contains the following options: Months in View Displays a submenu that allows you to choose how many months are displayed on one calendar screen. You can choose one of the following options: One, Four, Six, Nine, or Twelve.
s 9-10
Colors
Displays a submenu that allows you to choose one of the following date selection types: Selected, Blocked, or Conflicting. When you choose one of these options, a Selected Color dialog displays, and you can use this dialog to set the color for the date selection type. The following colors are used by default:
s
Unset dates use the background color of the Calendar Editor application Selected dates use green Conflicting dates use red Blocked dates use black
s s s
Years
Displays a submenu that allows you to select the number of years that the current calendar should include and that the Calendar Editor should display. The default range is the current year. You can extend the calendar to include additional years by selecting one of the following options:
s s
OneIndicates one year, or the default setting. TwoIndicates to include through the next year, two years. ThreeIndicates to include three years. FourIndicates to include four years. FiveIndicates to include five years. TenIndicates to include ten years.
s s s s
The Years option limits how far into the future you can set dates in the current calendar. You can increase and decrease the date range of a calendar. Also, when you open an existing calendar, its date range, or the current date range, whichever is greater, becomes the new date range for the current Calendar Editor session.
9-11 s
s Calendar Editor
Note The Calendar Editor allows you to set dates in the current year that have already past, if you do so, however, AutoSys ignores these dates.
Help Menu
The Help menu contains the following options: Contents About Displays the table of contents for the AutoSys Help. Displays the Calendar Editor version number.
Using the Navigation Controls

The Navigation controls area of the window contains the following: Selections area Conflicts area Instance drop-down list Calendar drop-down list Allows you to navigate through and select dates. Allows you to view the number of Conflicts and navigate through them. Allows you to select the instance to which you want to connect. Allows you to select a defined calendar to be displayed in the Calendar Editor.
Selections Area
You can use the buttons in the Selections area to move to a particular date whose state has been set. You can use the arrow buttons to do the following:
s s
Move focus to the first date in the calendar that has been set. Move focus to the previous date in the calendar that has been set relative to the date that currently has the focus.
s 9-12
Move focus to the next date in the calendar that has been set relative to the date that currently has the focus. Move focus to the last date in the calendar that has been set.
When you use the Selections buttons and the focus changes to a date that is not currently displayed, the calendar display shifts to bring that date into view.
Note A black box surrounds the date with focus.
Conflicts Area
The Conflicts area displays the number of conflicts and allows you to navigate among those conflicts. When there are 0 Conflicts, the navigation buttons are disabled. The Conflicts field is updated each time you apply a rule or manually change a Conflicting date to another state. If there are Conflicts, the number of conflicts is displayed, and the navigation buttons are enabled. You can move to the First, Previous, Next, or Last conflict.
Note When you save a calendar containing unresolved conflicts to the AutoSys database, you are prompted that conflicts exist. If you choose to ignore the prompt and save anyway, the Conflicting dates are lost; they are not written to the database. All other date states are saved.
Instance Area
To the right of the Conflicts area is the Instance drop-down list. When you select an instance, the Calendars drop-down list contains the appropriate defined calendars.
Calendars Area
The Calendars drop-down list contains all of the defined calendars for the selected instance (in the Instance drop-down list).
9-13 s
s Calendar Editor
Using the Calendar Display

The Calendar Editor by default displays six months of the calendar currently being edited. You can change the display from the Preferences Months in View menu. To scroll to the next six months
Click in the lower portion of the scrollbar.
To advance a month at a time

Click the down arrow on the scrollbar.
To move to the previous six months (if it is part of the calendar)

Click in the upper portion of the scrollbar.
To move back a month

Click the up arrow on the scrollbar.
The title bar of the window displays the name of the current calendar.
Date States
You can set the dates on the calendar to one of the following states: Unset Selected Blocked Indicates the date is not set. When you open a new calendar, all of the dates are unset. Indicates the date is set for that calendar. Indicates the date is ineligible for setting when applying a rule.
You can cycle through these three states by single-clicking a date multiple times. If you single-click, the date is Selected; if you click again, the date is Blocked; and if you click the date a third time, the date is Unset. The current state of each date is indicated by its color, as indicated from the Preferences Colors submenu.
s 9-14
In addition to these three user-selectable states, there is a fourth, systemgenerated state called the Conflicting state. This state occurs when both of the following are true:
s s
A rule is applied to a calendar. A date that qualifies for setting by the rule was previously set to the Blocked state, and rescheduling has not occurred. (Rescheduling may not have occurred if either a rescheduling rule has not been applied, or an applied rescheduling rule cannot find a nonconflicting date to move to.)
For example, you marked all holidays as Blocked, including January 1st, and, you want to apply a rule to set the first day of each month. The rule would conflict with the January 1st Blocked date. If there is no rescheduling rule in effect, such as move to the next weekday, or if the rescheduling rule specifies to move backwards, which results in falling off the calendar, a Conflicting state is generated. In this case, you must manually correct the situation before attempting to save the calendar to the database. You can ignore the Conflicting state when you save, but if you do so, all Conflicting dates are lostthey are not written to the database. For more information about rules, see Applying Rules to Calendars on page 9-19.
Note Calendars created with the Calendar Editor are stored in the AutoSys database. Only the Selected dates are stored. Dates designated as Blocked are only in effect while editing a calendar. That is, the Blocked state is only useful while applying rules. Blocked dates and rules are not stored in the AutoSys database.
9-15 s
s Calendar Editor
Creating and Modifying Calendars

Using the basic features of the Calendar Editor, you can define calendars and open existing calendars to create and modify calendars.
Creating a Calendar
This example demonstrates how to create a calendar containing 1998 U.S. holidays. This type of calendar might be useful as an exclude calendar, so that jobs do not run on holidays. To create a simple calendar containing all 1998 holidays
1 Choose File New.
A New Calendar dialog is displayed.

2 In the New Calendar dialog, select the Instance. 3 In the Enter the new Calendar field, enter this: us_hol_98 4 Click OK to close the New Calendar dialog.
The us_hol_98 calendar is open for editing in the Calendar Editor.

5 From the Preferences menu, select Years, and select Two (assuming it
is 1997). Then, using the scrollbar, scroll down to 1998 in the calendar display area.
6 In the Calendar Editor, select the holiday dates by single-clicking each
date. If the desired dates are not displayed, use the scrollbar to bring them into view.
7 Choose File Save. Then click OK in the Save As dialog.
Your calendar will resemble the one shown in Figure 9-2.
s 9-16
Calendar Editor s Creating and Modifying Calendars
Figure 9-2 Example Calendar Definition
Setting Dates Prior to Todays Date

Calendars exist to simplify the scheduling of job runs; therefore, only current and future dates are applicable. While the Calendar Editor allows you to set dates in the past, they are ignored. Moreover, when you merge calendars to create a new calendar, any dates prior to today are dropped from the new calendar.
9-17 s
s Calendar Editor
Opening an Existing Calendar

To open a saved calendar
1 Choose File Open.
The Calendar Selection dialog appears, as shown in Figure 9-3.
Figure 9-3 Calendar Selection Dialog
The Calendar Selection dialog allows you to select which calendar to open.
2 Click Search.
The Calendar Selection dialog contains a list of all the calendars that currently exist in the AutoSys database for this instance. In the Pattern field of the Calendar Selection dialog, you can specify any string, including the % wildcard character, and click Search to list those calendars whose names include the string. The default filter, %, lists all of the calendar names.
s 9-18
Calendar Editor s Applying Rules to Calendars
For example, to list only those calendar names starting with the string holiday, such as holiday_all and holiday_company, you specify the filter holiday%, and click the Search button. The list displays only the matching calendar names.
3 Select a calendar in the list, and click OK. This action opens the
calendar and exits the Calendar Selection dialog.

Or
Click the Cancel button to exit the Calendar Selection dialog without opening a calendar.
Applying Rules to Calendars

Using the Term Calendar Rule dialog, you can apply rules to calendars. Instead of selecting each date individually to set a state, you can apply a rule to set the state for multiple dates. To open the Term Calendar Rule dialog from the Calendar Editor
From the Edit menu, choose the Apply Rule option. This action opens the Term Calendar Rule dialog, as shown in Figure 9-4.
9-19 s
s Calendar Editor
Figure 9-4 Term Calendar Rule Dialog
The Term Calendar Rule dialog is divided into the following regions: Rule Specification Apply Rescheduling Rule Control The top portion of the dialog. The lower portion of the dialog. The bottom portion of the dialog containing the OK, Apply, and Cancel buttons. The OK button applies the current rule and dismisses the dialog. The Apply button applies the rule and does not dismiss the dialog. The Cancel button dismisses the dialog without applying the rule.
s 9-20
Using the Rule Specification Area

The Rule Specification region provides a wide variety of options for specifying which dates in the currently selected calendar you want to affect, and to what states those dates should be set. This region consists of the following three areas: Action Date Range Date Selection Rule Allows you to set the action the rule will initiate. Allows you to set the range of dates the rule will include. Allows you to set the Occurrences, Day, and Period for the rule.
To specify and apply a rule for a calendar

Select the appropriate Action, Date Range, Occurrences, Day, and Period, and click Apply, or click OK.
Action Area
In the Action Area, you can select an action, which is one of the following states to which the selected dates will be set, and or each rule, you can select only one of these actions: Set Dates Unset Dates Block Dates Changes the state of the selected dates to Selected. Changes the state of the selected dates to Unset. Changes the state of the selected dates to Blocked, so that this date will not be set during any subsequent rule applications.
9-21 s
s Calendar Editor
Date Range Area

In the Date Range area, you can specify the date range over which the rule should apply. By default, the entire date range of the selected calendar is listed, starting with the current date; however, you can limit the date range by selecting an option from either the All Year pull-down menu, or by specifying an actual date range in the All Days in Range Starting and Ending edit fields. When you enter a date range, the dates must fall within the display range set in the Years option of the Preferences menu. The Range Starting date must be on or after the current date.
Note Rules are not applied to any date prior to todays date.
Date Selection Rule Area

The Date Selection Rule area contains the following three subareas: Occurrences, Day, and Period. The settings you select in these three areas must make sense together. For usage examples, see the Date Selection Rule Examples section below. Occurrences Allows you to specify the occurrence of a day for which the rule should be applied (e.g., First, Last, Every nth). Select one or more options by clicking the corresponding checkbox. Allows you to specify on what days of the week the rule should be applied. Select one of the following three options: Day (Any), Weekday, or Specific Day(s). If you select Specific Day(s), you must also select one or more of the specific days of the week.
Day
s 9-22
Period
Allows you to specify the period during which the rule should be applied. Select only one of the following options: No Period, Monthly, Quarterly, Every n weeks, or the days in a specified Calendar. The No Period option is used for nonrepeating periods. Usually, you would use the No Period option with the Every or Every nth option in the Occurrences subarea. You could choose the First/Monday Quarterly to indicate the first Monday of each quarter. If you select the Calendar Period option, only the dates specified in the indicated calendar are used when applying the rule. You can enter the calendar name directly, or you can click the Calendar drop-down list button to display a list of existing calendars from which you can choose a calendar for the period.
Date Selection Rule Examples

The examples in this section illustrate the use of the Date Selection Rule options.
Note When you first start applying rules to your calendars, it is recommended that you experiment a little bit. Remember, you can always revert to the last saved version of a calendar by using the Revert option from the Edit menu, or you can clear everything using the Clear option from the Edit menu.
Example One To set the 3rd Tuesday of every month throughout the entire currently selected calendar
1 Open the Term Calendar Rule dialog by choosing Edit Apply Rule. 2 In the Action area of the Term Calendar Rule dialog, do not change the
default Set Dates selection.
9-23 s
s Calendar Editor
3 In the Date Range area, do not change the default All Days in Range
setting, which indicates the calendars entire range.

4 In the Occurrences subarea, select either the Third option, or type 3
in the nth option field.

5 In the Day subarea, select Tuesday, which automatically selects the
Specific Day(s) option.

6 In the Period subarea, select Monthly. 7 Click OK to apply the rule to the calendar you are currently editing,
and to close the dialog. Example Two To block every holiday date and prevent those days from being scheduled Using the calendar named us_hol_98, which you defined in Creating a Calendar on page 9-16, follow these steps:
1 Open the Term Calendar Rule dialog by choosing Edit Apply Rule. 2 In the Action area of the Term Calendar Rule dialog, select Block
Dates.
3 In the Date Range area, do not change the default All Days in Range
setting, which indicates the calendars entire range.

4 In the Occurrences subarea, select Every. 5 In the Day subarea, leave the default selection of Day. 6 In the Period subarea, select Calendar and, using the drop-down list,
select the us_hol_98 calendar. The calendar name should appear in the Calendar field.
7 Click Apply to apply the rule to the current calendar (in the Calendar
Editor). In the current calendar, all the holidays that were selected in your us_hol_98 calendar are set to Blocked. Use the open Term Calendar Rule dialog in the next example.
s 9-24
Example Three Continuing with the above example, you want to change the state of every Thursday to Selected. To do this, follow these steps, using the open Term Calendar Rule dialog:
1 In the Action area, select Set Dates. 2 In the Date Range area, do not change the default All Day in Range
setting.
3 In the Occurrences subarea, leave Every selected. 4 In the Day subarea, select Thursday, which also selects the Specific
Day(s) radio button.

5 In the Period subarea, select No Period. 6 Click OK to apply the rule to the current calendar.
When you apply this rule, the Conflicting state is assigned to the Thursdays that were previously Blocked, because they were selected using the us_hol_98 calendar. As a result, you could reset these conflicting dates manually, by clicking them until they are either Unset, Selected, or Blocked, or you could specify a Rescheduling Rule to accommodate this type of conflict (as described in Rescheduling Rule Example on page 9-27). Rescheduling Rules are described in the next section.
Using the Rescheduling Rule Area

The Rescheduling Rule region allows you to specify how date conflicts should be resolved when applying a rule. To specify a rescheduling rule using the Term Calendar Rule dialog
1 Create the rule in the Date Selection Rule area by selecting the Action,
Date Range, Occurrences, Day, and Period.

2 Select the Apply Rescheduling Rule checkbox. This action enables the
Move Direction and To Day options.
9-25 s
s Calendar Editor
3 Select the appropriate Move Direction and To Day options. These
settings indicate how the Conflicting dates should be rescheduled.

4 Click OK.
If you intend to apply a Rescheduling Rule, you should set it up at the same time you set up the Date Selection Rule, rather than wait for conflicts to occur.
Note Conflicts can also occur if a date is both Selected and Blocked. When a conflict occurs, the Selected state is moved when rescheduling, and the Blocked date is maintained.
Move Direction Area

You can select one of the following Move Direction options: To Previous To Following Moves the Selected state backward in the calendar. Moves the Selected state forward in the calendar.
To Day Area
In addition to specifying the Move Direction, you must specify one of the following To Day options: Any Day Weekday In Calendar Indicates the next available date. Indicates the next available weekday date. Indicates the next available date in the specified calendar. Use the drop-down list to select an existing calendar. Indicates to use the next available date not Selected in the specified calendar. Use the drop-down list to select an existing calendar.
Not in Calendar
s 9-26
Rescheduling Rule Example

This example describes how to remedy the conflict situation in the last example (when you applied the rule, Conflicting states will be assigned to Thursdays that were Blocked because they were selected in the us_hol_98 calendar). In this example, you apply a Rescheduling Rule that specifies any day following the date in conflict that is not also a holiday. To do this, follow these steps (as opposed to those given in Example Three above):
1 In the Action area, select Set Dates. 2 In the Date Range area, do not change the default All Days in Range
setting.
3 In the Occurrences subarea, leave Every selected. 4 In the Day subarea, select Thursday, which also selects the Specific
Day(s) radio button.

5 In the Period subarea, select No Period. 6 Click the Apply Rescheduling Rule checkbox. This action enables the
other fields.
7 In the Move Direction area, select To Following. This selection will
reschedule Conflicting dates to the appropriate following date.

8 In the To Day area, select Weekday. This selection, along with the To
Following selection, will reschedule the Conflicting dates to the following weekday.
9 Click OK to apply the rule to the current calendar and to close the
dialog. In the Calendar Editor, the Conflicting dates should be set to Blocked, and the Selected dates should be rescheduled to the following weekday. If you intend to apply a Rescheduling Rule, you should set it up at the same time you set up the Date Selection Rule, rather than wait for conflicts to occur.
9-27 s
s Calendar Editor
Combining Existing Calendars
Note Many conflict dates can be rescheduled to the same new date. For example, if you block all weekend dates, then apply a rule to set every day, with rescheduling to the previous weekday, both the Saturday and Sunday conflicts will be resolved to the preceding Friday. If you want separate runs for Saturday and Sunday, turn off the Rescheduling Rule and resolve the conflicts manually.
Combining Existing Calendars

You can combine calendars 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. Likewise, 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.
Combining Calendars Example

For example, you could combine your existing us_hol_98 calendar with your company holiday calendar. To do this you must first create a calendar named co_hol_98, select the holiday dates, and save the calendar. Then, you can combine the two calendars following these steps by using the Calendar Editor:
1 From the File menu, choose the New option. This action opens the
New Calendar dialog.

2 In the New Calendar dialog, select the Instance and, in the Enter the new calendar field, enter holidays 3 Click OK to close the New Calendar dialog. The holidays calendar is
open for editing in the Calendar editor.

4 From the Preferences menu, choose Years, then choose Two from the
submenu. If necessary, scroll down to the 1998 calendar.

5 From the Edit menu, choose the Apply Rule option.
s 9-28
Calendar Editor s Using the Job Definition Reference List
6 In the Term Calendar Rule dialog, select Set Dates in the Action area,
Every in the Occurrences area, and Day in the Day area.

7 In the Period subarea, click the Calendar radio button, and select
us_hol_98 from drop-down list.

8 In the Term Calendar Rule dialog, click Apply. 9 Repeat steps 5 and 6, except select the co_hol_98 calendar from the
drop-down list. Then, click OK to dismiss the Term Calendar Rule dialog.
10 From the File menu, select the Save option.
This new calendar will include and combine the dates that are the two previously defined calendars. This process of combining calendars can be repeated for any number of calendars.
Note When combining calendars, any dates prior to the current date
are dropped from the new calendar.
Using the Job Definition Reference List

From the Calendar Editor Utilities menu, you can open the Job Definition Reference List. You can use the Job Definition List to see what jobs will be affected by any changes you make to the current calendar. To open the Job Definition Reference List dialog
Choose Utilities Job Definition List.
This action opens the Job Definition Reference List dialog as shown in Figure 9-5.
9-29 s
s Calendar Editor
Importing and Exporting Calendars
Figure 9-5 Job Definition Reference List
When you open the Job Definition Reference List, it displays a list of jobs that reference the current calendar either as a run calendar or an exclude calendar. These are the jobs that will be affected by any changes that you make to the current calendar. When you save the current calendar, the start dates for the job will be recomputed.

Using the Calendar Editor, you can import calendars from and export them to text files. You perform calendar imports and exports by using the standard Open or Save dialogs.
s 9-30
Calendar Editor s Importing and Exporting Calendars
Importing Calendar Text Files

You can import calendars contained in ASCII text files into the AutoSys database. These text files may contain multiple calendars, each of which must be delimited with the calendar:calendar_name attribute. This is a sample calendar text file:
calendar: Q1paydays 01/01/1997 01/15/1997 02/01/1997 02/15/1997 03/01/1997 calendar: Q1holidays 01/01/1997
You can include comments following a space after the calendar name or after each date. This is the same format that is written by the Export function. To import a file
Choose File Import. The standard Open dialog opens, which you use to select the file to import.
Note AutoSys will not automatically overwrite the existing calendar definitions. If you have calendars within a text file that have names identical to calendars existing in the database, a warning dialog will notify you that a calendar name is duplicated and that the import of this calendar will not occur. In addition, after the import has completed, an information dialog will tell you how many calendars were imported.
9-31 s
s Calendar Editor
Exporting Calendars
You can export all calendars defined in the AutoSys database to an ASCII text file. To export the calendars
Select File Export All. The standard Save As dialog opens, which you can use to select a location and filename to which the calendar definition should be saved.
When you use the Export All option, all the calendars in the AutoSys database are exported to a single ASCII text file.
Note There is no way to export individual calendar definitions;
however, you can edit the text file created by File Export All.
s 9-32
10
Load Balancing and Queuing Jobs
This chapter describes the use of real and virtual machines in the AutoSys environment to provide load balancing and queueing functionality. It provides information about load balancing jobs across multiple machines, as well as queueing jobs to real and virtual machines.
Real Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3 Virtual Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3 Defining Machines to AutoSys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4 Specifying Machine Load (max_load) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-5 Specifying Relative Processing Power (factor) . . . . . . . . . . . . . . . . . . . . . . . . . 10-6 Using max_load and factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-6 Machine Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7 Defining a Real Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-8 Deleting Real Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-9 Defining a Virtual Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-9 Deleting Virtual Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-11
10-1 s
s Load Balancing and Queuing Jobs
Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-12 Force Starting Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-15 Queuing Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-15 Queuing and Simple Load Limiting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-16 Queuing with Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-17 SubsetsIndividual Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-19 Multiple Machine Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-21 User-Defined Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-22
s 10-2
Load Balancing and Queuing Jobs s Real Machines
Real Machines
s
10
In the AutoSys environment, a real machine is any network host that has: Been identified in the appropriate network database and is accessible over the network using the TCP/IP protocol so that AutoSys can access it. Undergone a client software installation (and is licensed) so that AutoSys can run jobs on it.
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.
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.
10
By defining virtual machines to AutoSys, and then submitting jobs to run on those machines, you can specify:
s s
Runtime resource policies (or constraints) at a high level. That AutoSys automatically execute those policies in a multi-machine environment.
10-3 s

Defining Machines to AutoSys

Define both real and virtual machines to AutoSys by using machine attribute statements within a JIL script. The following JIL sub-command defines a real or virtual machine to AutoSys:
insert_machine: machine_name
10
The following JIL machine attributes are used when defining machines:
type
Specifies a machine type, which can be one of the following:

r for UNIX real v for UNIX virtual n for NT (real or virtual) machine
Specifies a real machine name to be inserted in a virtual machine.

max_load
For real machines only, and used for load balancing.

factor
For real machines only, and used for load balancing. Real machines only need to be defined to AutoSys if they meet one of the following criteria:
s
Require a max_load or factor attribute to be set for them. (These attributes are discussed in the next section.) Are to be included in a virtual machine.
Virtual machines must be defined before you can use them.
s 10-4
Load Balancing and Queuing Jobs s Defining Machines to AutoSys
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. For more information about the JIL sub-commands and attributes pertaining to machines, see Chapter 3, JIL Machine Definitions in the AutoSys Reference Guide for Windows NT.
Specifying Machine Load (max_load)
10
The max_load attribute can be defined only for real machines. It describes how much of a load can be placed on a real machine, and it is specified with an arbitrary unit called a load unit. Any weighting scheme desired by the user can be used. For example, a load unit with a range of 10-100 would specify that machines with limited processing power are expected to carry a load of only 10, while machines with ample processing power can carry a load of 100. There is no direct relationship between the load unit value and any of the machines physical resources. Therefore, you should develop conventions that are meaningful to you. Zero and negative numbers cannot be used.
Job Attributes and Load Balancing and Queuing

For load balancing to work, every defined job that will impact the load on a machine must be assigned a job_load job attribute, which defines the relative load the job will place on a machine. Thus, a machines current load can be tracked, and overloading of a machine can be prevented. For example, if the max_load on a machine is 100 and the job_load for one job is 10, then that job will use 10 percent of the machines resources.
10-5 s

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.
Specifying Relative Processing Power (factor)

The factor machine attribute can be defined only for real machines. It is another arbitrary value that describes the relative processing power of a machine. This attributes value is a real number that can contain a decimal. It is used to weigh available cycles on one machine against that of another machine. When AutoSys checks the available cycles on each machine, it multiplies the percent of free CPU cycles by the factor in order to determine which machine has more relative processing power available. Therefore, the factor value is typically a number between 0.0 and 1.0.
10
Using max_load and factor
10
The max_load attribute is primarily used to limit the loading of a machine. As long as a jobs load will not cause a machines max_load to be exceeded, the max_load attribute does not influence the decision of on which machine a job should be run. Conversely, the factor attribute is primarily intended to be used when deciding between machines for running a job, if more than one machine is available. If these attributes are not specified in a real machine definition, they default to the values shown below:
max_load: none/* no limit */ factor: 1.0 Note A virtual machine is comprised of real machines. Therefore you do not specify max_load and factor attributes explicitly in a virtual machine definition. They are specified in the definitions of the real machines that make up the virtual machine.
s 10-6
Load Balancing and Queuing Jobs s Defining Machines to AutoSys
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.
Real UNIX insert_machine: toad max_load: 100 factor: .8 Real NT insert_machine: tiger type: n max_load: 100 factor: .8
10
Virtual UNIX insert_machine: pond machine: toad machine: frog
Virtual NT insert_machine: jungle type: n machine: tiger machine: monkey
10-7 s

Defining a Real Machine
To help you understand virtual machines and their capabilities, the following sections provide a series of examples that demonstrate the different combinations of real machines that can constitute a virtual machine. These examples include the JIL statements used to define these machines.
Defining a Real Machine

To define a real machine to AutoSys
1 Assign a machine name, this must be its hostname. 2 Assign a machine type: r for real UNIX or n for NT. 3 Optionally, assign a max_load and a factor attribute value.
10
Figure 10-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 factor: 1.0
jaguar 100 1.0
max_load factor
Figure 10-1 Real UNIX Machine with max_load 100 and factor 1.0
To define a real NT machine named tiger, enter the following JIL statements:
insert_machine: tiger type: n max_load: 100 factor: 1.0
s 10-8
Load Balancing and Queuing Jobs s Defining a Virtual Machine
Deleting Real Machines

The following JIL statement deletes the real machine definition for the machine named jaguar:
delete_machine: jaguar
10
Defining a Virtual Machine

To define a virtual machine to AutoSys
1 Assign a machine name. 2 Assign a machine type: v for virtual UNIX or n for virtual NT. 3 Specify the real machines that will make up the virtual machine.
10
Figure 10-2 defines a virtual UNIX machine named modena, which is composed of two real UNIX machines named ferrari and lambo. Because the real machines do not specify a max_load and factor, they will have the default values for these attributes: a factor of 1.0 and unlimited load units.
insert_machine: modena type: v machine: ferrari machine: lambo
modena ferrari lambo
Figure 10-2 Virtual Machine with Two Real UNIX Machine Components
The following JIL statements define two real UNIX 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.)
10-9 s

Defining a Virtual Machine
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
Figure 10-3 defines a virtual NT machine named garden comprised of two real NT machines named rose and lily.
insert_machine: garden type: n machine: rose machine: lily
garden rose 100 1.0 lily 80 .9
Figure 10-3 Virtual Machine with Two Real NT Machine Components
The following JIL statements define the two real NT machines.

insert_machine: rose type: n max_load: 100 factor: 1 insert_machine: lily type: n max_load: 80 factor: .9
s 10-10
Load Balancing and Queuing Jobs s Defining a Virtual Machine
The following JIL statements define a virtual UNIX machine named mustang which is composed of slices, or subsets, of the real machines named fiat and lotus. Even though the real machines have been previously defined, only the reduced load portion (or slices) will be used in the virtual machine mustang.
insert_machine: mustang type: v machine: fiat max_load: 10 machine: lotus max_load: 9
fiat 10
lotus 9
Figure 10-4 Virtual UNIX Machine Comprised of Subsets of Real Machines
In the following example, a virtual NT machine named cats is composed of subsets of the real machines named puma and lion. Even though the real machines have been previously defined, only the reduced load portion (or slices) will be used in the virtual machine cats.
insert_machine: cats type: n machine: puma max_load: 10 factor: 1.0 machine: lion max_load: 9 factor: .85
Deleting Virtual Machines
10
To delete a real machine component of a virtual machine, you specify the virtual machine and the desired component. The following JIL statements delete only the real machine named lambo found within the virtual machine named modena:
delete_machine: modena machine: lambo
10-11 s

Load Balancing
If the machine lambo had been individually defined outside of the virtual machine, its individual definition still remains in effect. To delete the entire virtual machine, you dont have to specify any of the component real machines. The real machines are still definedonly 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.
Load Balancing
By specifying a virtual machine or a list of real machines in a jobs 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 machines 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. When a job is ready to start, AutoSys will determine which of the specified machines is best suited to run the job. The following JIL example shows the job definition statements for such a job:
insert_job: test_load machine: modena command: echo "Test Load Balancing" job_load: 50 priority: 1
10
Where modena is a virtual machine.
s 10-12
Load Balancing and Queuing Jobs s Load Balancing
Alternatively, if all machines are NT or UNIX not a combination of the two, you can specify a list of real machines in the jobs 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:
1 Determines the percentage of CPU cycles available on each real
machine in the specified virtual machine. This is accomplished by opening a special key named HKEY_PERFORMANCE_DATA in the NT Registry, which provides a variety of system performance data, including available CPU cycles.
2 Multiplies it by the machines factor value. 3 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. If the machines have equal max_load and factor values, it is equivalent to defining a job and specifying the following in the machine field:
machine: ferrari, lambo
The advantages of building a virtual machine are that it can be changed, and the new construct is immediately applied globally. Also, the values can vary between machines. Even when a set of real machines that have not been explicitly defined to AutoSys are specified in a jobs machine attribute, the available CPU cycles are used to determine which machine will run the job. In all likelihood, your system configuration will include machines of varying processing power, so you will need to specify the factor attribute value for each real machine.
10-13 s

Load Balancing
Figure 10-5 illustrates three machines having different capabilities, which are grouped into a virtual machine.
italia ferrari 1.0 alfa_romeo 0.8 lambo 0.3 factors
Figure 10-5 Load Balancing on a Virtual Machine
The following JIL statements can be used to define this machine:

insert_machine: italia machine: ferrari factor: 1 machine: alfa_romeo factor: .8 machine: lambo factor: .3
To start a job on this virtual machine, simply specify italia as the machine attribute for the job. The Event Processor will perform the necessary calculations to determine on which machine to run the job, and reflect these calculations in its output log. The output is similar to this:
EVENT: STARTJOB JOB: test_mach Checking Machine usages using NT Performance Method :<ferrari=78*[1.00]=78> <alfa_romeo=80*[.80]=64> <lambo=2*[.30]=06> [ferrari connected] EVENT: CHANGE_STATUS STATUS: STARTING JOB: test_mach
s 10-14
Load Balancing and Queuing Jobs s Queuing Jobs
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.
Force Starting Jobs

If you force start a job, AutoSys will start the job right away on the machine specified in the job definition, regardless of the current load on the machine or the job_load specified for the job. If the job was defined to run on a virtual machine, or a list of real machines, AutoSys will determine which machine has the most processing power available and will run the job on that machine, even if the job_load of the job exceeds the max_load defined for the machine.
10
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. Queuing policies in AutoSys are established through the use, and subsequent interaction, of the two job attributes job_load and priority, and the two machine attributes max_load and factor. 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.
10
10-15 s

Queuing Jobs
Queuing and Simple Load Limiting
10
If a job has been assigned a job_load value (the load limiting feature), and a max_load attribute is assigned to every real machine comprising a virtual machine, AutoSys will first determine whether each machine has sufficient available load units before running the job. If each real machine has sufficient load units, AutoSys employs the load balancing and factor algorithms to determine on which machine it should start. However, if only one of the machines has sufficient load units, the job will be run on that machine. If no machines have sufficient load units, the job will be placed on queue for both (or all) machines. When one machine becomes available, the job is run on that machine, and removed from all other queues. 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 jobs 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.
s 10-16
Using a previously defined machine named fiat with a max_load of 100, a simple queuing example would be as follows:
insert_job: jobA machine: fiat job_load: 80 priority: 1 insert_job: jobB machine: fiat job_load: 90 priority: 1
If jobA was running when jobB started, jobB would be in a QUE_WAIT state until jobA completed and jobB could run.
Note If a job is in the QUE_WAIT state and you want to run it immediately, do not force start the job. To change the job queue priority, use the sendevent command with the -E CHANGE_PRIORITY option.
Queuing with Priority
10
When more than one job is queued, the priority value is considered first when deciding which job to run next. If there are insufficient load units (job_load value) available to run the highest priority job, it will remain in the queue, and lower priority jobs will be considered subsequently. When there is no priority value assigned to a job (default is 0), there is no queuing and AutoSys starts the job immediately. Therefore, the job will never go into the QUE_WAIT state. If the jobs priority was set to run immediately, the job would run regardless of the current load on the machine. Obviously, this interferes with the load limiting feature, so when load limiting is in use, the priority attribute should always be set. 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.
10-17 s

Queuing Jobs
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 10-6 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.
QUE_WAIT
EXECUTE
JobA 50 JobD 30
JobB 50 JobC 30
80 ferrari
max_load
Figure 10-6 Schematic of Queuing with Priority
s 10-18
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. If JobB finishes first, 50 load units become available, so either JobA or JobD could be run. Since JobA has a higher priority (lower value = higher priority), it will run first. However, if JobC finishes first, only 30 load units become available, so only JobD could be run.
SubsetsIndividual 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
10
10-19 s

Queuing Jobs
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. Figure 10-7 depicts a virtual machine functioning as a queue. The JIL statements to define the queue, called ferrari_printQ follow the graphic. Note that ferrari is a real machine.
ferrari_printQ ferrari 15 80
Figure 10-7 Virtual Machine used to Construct an Individual Queue
To implement the schema in Figure 10-7, 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
s 10-20
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.
Load Units and Virtual Machines

It is important to note that the load units associated with a virtual machine have no interaction with the load units for the real machine. In the above example, this means that the virtual load of 15 does not subtract from the load units of 80 for the real machine. Load units are simply a convention which allows the user to constrict concurrent jobs running on any one machine.
Multiple Machine Queues

Virtual machines can also be constructed to allow subsets (or slices) of real machines to be combined into one virtual machine. A possible need for this would be if there were two machines that were print servers, on each of which only one print job was to run at a time. Figure 10-8 illustrates this situation.
p ferrari lambo
10
15
80
15
120
Figure 10-8 Virtual Machine Comprised of Subsets of Real Machines
10-21 s

User-Defined Load Balancing
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
As a job is logically ready to start on printQ, AutoSys will determine if there are enough load units available on either machine. If there are not, it will place the job in the QUE_WAIT state, and start it when there are enough load units. If there are enough units on only one machine, it will start it on that machine. In the case that there are enough available load units on both machines, AutoSys will determine the usage on each, and start the job on the machine with the most available CPU resources.
10
As an alternative to using the provided load balancing methods described in this chapter, you can write your own programs or batch files to determine which machine to use at runtime. If you specify the name of a program or batch file as the machine name in the jobs machine specification, the Event Processor will execute the batch file at job runtime, and it will substitute its output for the machine name. For example, you might supply the following:
insert_job: run_free machine: "C:\USERS\DEFAULT\PICK_MACHINE.BAT" command: %HOME%\DEL_STUFF.BAT
At runtime, the "C:\USERS\DEFAULT\PICK_MACHINE.BAT" batch file is run on the Event Processor machine. The standard output will be substituted for the name of the machine, and the job will be run on that machine.
s 10-22
Load Balancing and Queuing Jobs s User-Defined Load Balancing
Note If you specify a user-defined load balancing script in the machine attribute, you cannot use the priority or job_load job
attributes.
10-23 s

s 10-24
11
Scheduler Console
This chapter describes how to use the Scheduler Console to monitor and control job runs in real-time. The Scheduler Console allows you to access job information from multiple AutoSys instances.
Using the Scheduler Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3 Using the Scheduler Console Menu Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-5 Using the Control Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-12 Using the Summary Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-12 Defining Scheduler Console Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-15 Filters Editor Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-16 Using the Filter Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-22 Using Scheduler Console Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-22 Using the Job Dependencies Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-23 Using the Run Status Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-24 Using the Send Event Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-28 Using Scheduler Console Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-38 Using the Job Detail Report Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-38 Viewing Reports with InfoReports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-41
11-1 s
s Scheduler Console
Setting Scheduler Console Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-43 Using the General Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-44 Using the User Defined Buttons Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-45 Using the User Defined Reports Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-47 Using the Summary Area Layout Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-49 Using the Action Area Layout Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-52 Setting the Time Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-56
s 11-2
Scheduler Console s Using the Scheduler Console
Using the Scheduler Console

The Scheduler Console provides a sophisticated method of monitoring AutoSys jobs from multiple instances in realtime. The Scheduler Console lets you view any jobs that are defined to AutoSys, whether or not they are currently active.
11
You can create filters that allow you to control the jobs displayed in the Scheduler Console. These filters are based on various parameters, such as the current job state, the job name, and the machine on which the job runs. You can change the current filter to change the jobs displayed in the console. In addition, from the Scheduler Console you can select any job and view more detailed information about it, including its starting conditions, dependent jobs, and autorep reports. You can also open several utilities and tools from the Scheduler Console. To open the Scheduler Console
Click the Scheduler Console button on the GUI Control Panel. This action opens a window similar to the one shown in Figure 11-1.
If you are opening the Scheduler Console for the first time, you will be prompted to choose whether you want to open the Scheduler Console using the Default Filter. If you choose No, the Filter Editor is opened, and you can define a filter to use in the Scheduler Console. For information on using the Filter Editor, see Defining Scheduler Console Filters on page 11-15.
11-3 s
s Scheduler Console
Figure 11-1 Scheduler Console
s 11-4
The Scheduler Console has the following three areas: Menu bar Control area The area which is at the top of the window. The area below the menu bar which contains the drop-down list of defined filters and the action buttons you have selected to display. You can populate this action area with AutoSys action buttons and user-defined action buttons.
Summary area or The area at the center of the window which displays job list a list of all jobs stored in the database, subject to the filter currently in effect.
Note By default, the Scheduler Console starts up with Auto Refresh on, and the job list is updated every 60 seconds. For information on setting the interval for Auto Refresh, see Using the General Dialog on page 11-44.
Using the Scheduler Console Menu Bar

At the top of the Scheduler Console is the menu bar, which contains the following menus: File, Filters, Actions, Tools, Applications, Reports, Preferences, and Help.
11
File Menu
The File menu has the following options: New Scheduler Console Exit Opens another Scheduler Console window. Exits the Scheduler Console and closes all database connections that it has established.
11-5 s
s Scheduler Console
Note The first time you connect to an instance in a session, a database connection is established, and it is maintained until you close the Scheduler Console.
Filters Menu
The Filters menu has the following option: Filter Editor Opens the Filter Editor dialog. Use this dialog to define, modify, and delete filters. Filters define the jobs you want to appear in the job list area. For information on defining filters, see Filters Editor Dialog
on page 11-16.
Actions Menu
The Actions menu contains a list of actions that you can perform on the selected jobs in the job list area. These are the Actions menu options: Start Job Starts the selected jobs if the Dependencies starting conditions are met. This action ignores Date/Time starting conditions, but it does not ignore job dependency starting conditions. You can only use this option to start top-level jobs; do not use it on jobs in boxes. Choosing this option is equal to sending a STARTJOB event. Kills the selected jobs. Choosing this option is equal to sending a KILLJOB event, and its action depends on the job type and the type of machine (UNIX or Windows NT) on which the job is running. Starts the selected jobs regardless of whether the starting conditions have been met. Choosing this option is equal to sending a FORCE_STARTJOB event.
Kill Job
Force Start Job
s 11-6
On Hold
Places the selected jobs on hold, which means they cannot be started. You cannot place a job on hold if it is in STARTING or RUNNING state. Choosing this option is equal to sending a JOB_ON_HOLD event. Takes the selected jobs off hold. If you choose this option and the selected jobs starting conditions have been met, the jobs will be started. Choosing this option is equal to sending a JOB_OFF_HOLD event. Places the selected jobs on ice, which is the functional equivalent of deactivating the job definition. You cannot place a job on ice if it has a STARTING or RUNNING status. Choosing this option is equal to sending a JOB_ON_ICE event. Takes the selected jobs off ice, which is the functional equivalent of reactivating the job definition. When you take a job off ice, it will start the next time the starting conditions are met. Choosing this option is equal to sending a JOB_OFF_ICE event.
Off Hold
On Ice
Off Ice
For more information on any of these events, see sendevent in Chapter 1, AutoSys Commands, of the AutoSys Reference Guide for Windows NT.
11-7 s
s Scheduler Console
Tools Menu
The Tools menu allows you to open AutoSys windows and dialogs that give you more information on a job, or allow you to modify a job. The menu has the following options: Dependent Jobs Opens the Job Dependencies dialog for the selected job. This dialog shows the Current Job Name and the Predecessor Jobs and Successor Jobs. When you select a job in this dialog, the starting Condition also displays. For information, see Using the Job Dependencies Dialog on page 11-23. Opens a Job Editor for the selected job. For information on the Job Editor, see Chapter 7, Defining AutoSys Jobs using the Job Editor. Opens the Run Status Tool for the selected job. The Run Status Tool displays a job summary, including information about the most recent, or current, run of the job. You can also open a Run Status Tool for a specific Job by double-clicking on the job in the summary area. For information, see Using the Run Status Tool on page 11-24. Opens the Send Event Tool for the selected job. Using this dialog, you can send events, and you can cancel events that have been scheduled for a later time. For information, see Using the Send Event Tool on page 11-28.
Job Editor
Run Status Tool
Send Event
s 11-8
Applications Menu
The Applications menu has the following option: Alarm Manager Opens the Alarm Manager, which you can use to view alarms and change their status from Open to Acknowledged or Closed. When you open the Alarm Manager from the Scheduler Console, it contains the alarms for all instances it can access. For information on the Alarm Manager, see Chapter 12, Managing Alarms.
Reports Menu
The Reports menu allows you to run and view various job reports. The menu has the following options: Job Detail Report Opens the Job Detail Report tool for the selected job. This dialog displays a real-time report of the job run information (in the format of the autorep command output). For information, see Using the Job Detail Report Tool on page 11-38. Job Find Generates an InfoReports job report that includes the jobs that match the pattern for a job name that you enter. For information, see Viewing Reports with InfoReports on page 11-41. Generates an InfoReports job list report based on a list of jobs you select, or based on the entire list of jobs in that instances database. For information, see Viewing Reports with InfoReports on page 11-41.
Job List
11-9 s
s Scheduler Console
Last Run
Generates an InfoReports based on the last run of the selected job. For information, see Viewing Reports with InfoReports on page 11-41. Generates an InfoReports based on the specified run (n) since the last run of the selected job. You can also enter the last, second to last, or a number for the nth run since the last run. For information, see Viewing Reports with InfoReports on page 11-41.
Last N Run
Preferences Menu
The Preferences menu allows you to set user preferences and customize the Scheduler Console display. The menu has the following options: General Opens the General dialog in which you can set the refresh interval (the default setting is 60 seconds), the confirm action behavior, and the button display. For information, see Using the General Dialog on page 11-44. Opens the User Defined Buttons dialog, in which you can enter button names and the commands they execute. When you enter a button Name and Command, the button is placed in the control area at the top of the Scheduler Console window. For information, see Using the User Defined Buttons Dialog on page 11-45. Opens the User Defined Reports dialog, in which you can enter Report menu items and the command that they execute. For information, see Using the User Defined Reports Dialog on page 11-47. Opens the Summary Area Layout dialog, in which you can set column length, column order, and sort order for the summary area. For information, see Using the Summary Area Layout Dialog on page 11-49.
User Defined Commands
User Defined Reports
Summary Area Layout
s 11-10
Action Area Layout
Opens the Action Area Layout dialog, in which you can select the buttons that you want in the control area at the top of the Scheduler Console. These buttons are shortcuts to sending events and opening tools. For information, see Using the Action Area Layout Dialog on page 11-52.
Time Perspective Allows you to select one of the following time perspectives, which controls the time zone used in the display: Local Time, Currently Selected Job, or Currently Selected Instance. For more information, see Setting the Time Perspective on page 11-56.
Note The Time Perspective affects the Start Time and Last Change display in the summary area.
AutoRefresh
Indicates whether or not the Scheduler Console summary area should be updated automatically. By default, AutoRefresh is selected (set to on). This setting indicates that the Scheduler Console should be updated based on the Refresh Interval setting in the General dialog. If you uncheck the AutoRefresh option, setting it to off, the Console display is not updated automatically. To update the display, you can check the AutoRefresh option, or you can click the Refresh button (if you indicated to have the button in the action area).
Help Menu
The Help menu contains the following options: Contents About Displays the table of contents for the AutoSys Help. Displays the Scheduler Console version number.
11-11 s
s Scheduler Console
Using the Control Area

The control area is located below the Scheduler Console menu bar. The control area contains the following items:
s
11
The drop-down list of defined filters. To change the summary display, basing it on a different filter, click on the filter name in the filter list. To define or modify a filter, use the Filter Editor (described in Defining Scheduler Console Filters on page 11-15). The Refresh button, which you can click to update the display with the most current database information. The action area, which you can populate with the following:
AutoSys buttons that open tools or send events on the selected
jobs. You define the set of buttons that appear in the area using the Action Area Layout dialog. By default, all buttons are displayed the first time you open the Scheduler Console. For information, see Using the Action Area Layout Dialog on page 11-52.
User-defined buttons that execute assigned commands. You define
the set of buttons that appear in the area and the commands that they execute, by using the User Defined Button dialog, which you can open from Preferences User Defined Commands. For information, see Using the User Defined Buttons Dialog on page 11-45.
Using the Summary Area

The summary area displays a list of all the jobs that are defined to AutoSys, subject to the currently selected filter. The list of jobs in the summary area provide a snapshot of the system, across multiple machines and multiple instances.
11
s 11-12
When a job generates an alarm, its line turns the color specified in the AutoSys Control Panel Colors dialog, which you can open from the AutoSys Control Panel Preferences Colors menu item. The default color for alarms is red. An alarm is generated when a job completes with FAILURE or TERMINATED status.
Summary Area information

Each entry in the summary area contains the following job-specific information:
s s s s s s s s
Job Name Instance (to which the job is defined) Status (Current) Last Change (based on the Time Perspective) Machine (on which it last ran or is currently running) Type (Job, FW, or Box) Start Time (based on the Time Perspective) Job ID
Selecting Jobs
When you select a job from the list, the highlighted job becomes the currently selected job, and you can open the dialogs and applications located on the Tools and Applications menus to get more information on the selected job. In addition, you can select multiple jobs from the list and perform actions on them, by using the Actions menu options, the Send Event Tool, or any buttons you have added to the action area at the top of the Scheduler Console.
11-13 s
s Scheduler Console
You can right-click on any job to get a menu of actions you can perform on that job and tools you can open. This menu will also contain a list of your user defined buttons that allow you to execute the command from this menu. For information on user defined buttons, see Using the User Defined Buttons Dialog on page 11-45. You can double-click on a job to open the Run Status Tool to view the job information (see Using the Run Status Tool on page 11-24).
Note When you select a job from the list, the status bar of the Scheduler Console shows the appropriate time, based on the Time Perspective. For more information, see Setting the Time Perspective on page 11-56. When the Scheduler Console is reading the database (refreshing or changing filters) an asterisk appears at the end of the date time statement.
To select a job
Single-click the job in the summary area job list display.
To select contiguous multiple jobs

Press and hold the mouse button and drag to select a group of jobs.
To select noncontiguous multiple jobs

Press the <Control> key and click each job you want to select. Pressing the <Control> key and single-clicking a selected job deselects that job.
To deselect all the currently-selected jobs

Single-click anywhere in the job list.
Note The summary area has a scroll bar along the right-side for scrolling through the job list. Using the Summary Area Layout dialog, on the Preferences menu, you can resize the columns and change the sort order. For more information, see Using the Summary Area Layout Dialog on page 11-49. In addition, you can resize the titles by dragging the edges.
s 11-14
Scheduler Console s Defining Scheduler Console Filters
Defining Scheduler Console Filters

If you are opening the Scheduler Console for the first time, you will be prompted to choose whether you want to open the Scheduler Console using the Default Filter. The Default Filter includes all jobs, with all statuses, on all defined machines, and for all locally-defined (installed) instances.
11
You can define any number of filters to control the jobs that are displayed in the Scheduler Console summary area. To do this, you use the Filter Editor, which allows you to filter by the following criteria:
s s s s
Names of jobs Status of jobs Machine on which jobs are to run Instances to which jobs belong
You can use the Filter Editor to create, delete, and modify filter definitions. To open the Filter Editor
Choose Filters Filter Editor. This action opens a dialog similar to the one shown in Figure 11-2.
11-15 s
s Scheduler Console
Figure 11-2 Filter Editor
Filters Editor Dialog

The Filter Editor has a File menu and the following tabs:
s s s
11
Names Status Machine/Instance
s 11-16
File Menu
The File menu has the following options: New Open Opens a new Filter Editor. Opens the Open Filter Criteria dialog, which lists the defined filters. You can select a filter to open, and click OK. Saves the filter definition. These filters apply to all installed instances, but they are user-specific, so they are saved. When you save for the first time, this option opens the Save As dialog. Opens the Save As dialog, in which you can enter a new filter name and saves it. Opens the Deleting Filters dialog, which displays a list of defined filters. To delete a filter, select it from the list, and click OK. This deletes the Filter definition. Closes the Filter Editor, displaying a dialog asking you if you want to save your last modifications when necessary.
Save
Save As Delete
Exit
Names Tab
Using the Filter Editor Names tab, you can select the jobs you want to view by name. You can click one of the following radio buttons: All Jobs Jobs named Selects all jobs that meet the other filtering criteria. Selects the jobs with the name or names you enter in the scrollable text box to the right of the button. After entering each name, press <Enter>.
11-17 s
s Scheduler Console
Jobs in Boxes named
Selects the jobs with the name or names you enter in the scrollable text box to the right of the button. In addition, this selection enables the Maximum Depth field, which allows you to indicate how many levels of nesting you want to view for all selected Box Jobs. When selecting jobs based on box name, each contained level will be indented two spaces to indicate the nesting. You can select one of the following settings:
s
AllIndicates that the box specified in the scrollable text box and all of its direct descendents (including nested boxes and the jobs in those boxes) are to be displayed. This is the default. 0Indicates that only the top-level box specified in the scrollable text box is to be displayed. 1 through 20Indicates that the box specified in the scrollable text box and the selected number of levels of nesting are to be displayed.
When specifying a job name in the scrollable text box, you can enter the asterisk ( * ) wildcard character, the entire job 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. At the end of each entry, press <Enter>. 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 summary area.
s 11-18
Note If you have selected a Sort Key for the Summary Area Layout that is different from the default order (which is no sort order), the levels of Box Jobs will not display indentation correctly; the indentation will display, but the order will not be based on the jobs relationship to the containing Box Job.
Status Tab
From the Filter Editor Status Tab (shown in Figure 11-3), you can select the jobs that you want displayed based on their current status. You can select All Statuses, or you can select individual statuses, such as STARTING, RUNNING, or INACTIVE. The All Statuses selection is the default setting, and it is automatically deselected when you deselect any of the statuses listed below it (when all statuses are no longer selected). You can select any combination of the statuses.
Figure 11-3 Filter Editor Status Tab
11-19 s
s Scheduler Console
Machines/Instances Tab
From the Filter Editor Machine/Instance tab (shown in Figure 11-4), you can select jobs based on the name of the machine on which they ran (or they are currently running). On the left side of this tab is a list of all the machines that are referenced in any job or machine definition for the instance, or which have run an AutoSys job. In addition, you can select the instance or instances you want included in this filter. On the right side of this tab, is a list of instances to which this Scheduler Console can connect. By default, All Instances is selected, but you can uncheck the checkbox and select specific instances from the list of instances.
Note Virtual machines appear on the Machine list, but you cannot
use them to select jobs, because jobs can run only on real machines.
Figure 11-4 Filter Editor Machine/Instance Tab
s 11-20
Selecting Machines or Instances From the Machine or Instance list, you can choose one or several names to include in the filter. To specify Machines from the list
Click the All Machines checkbox to uncheck it, and then select the machines you want to include in the filter.
To specify Instances from the list

Click the All Instances checkbox to uncheck it, and then select the instances you want to include in the filter.
When you are selecting machines or instances, the behavior is the same. You can select a single name, a range of names, or multiple names. To choose a single name
Single-click that name.
To choose a range of names

Press the mouse button and hold on the first name, and then drag the cursor to the last name and release the mouse button.
To choose multiple names, or more names after your initial selection

Press the <Control> key and click each name.
11-21 s
s Scheduler Console
Using Scheduler Console Tools
Using the Filter Editor

To define a filter
1 Choose Filters Filter Editor. This action opens a dialog similar to the
11
one shown in Figure 11-2 on page 11-16.

2 In the Filter Editor, use the Names, Status, and Machine/Instance tabs
to specify the filter definition.

3 Choose File Save. This opens a Save As dialog in which you can enter
the name of the filter, then click OK. This action saves the filter definition. To select a defined filter on which to base the summary area display
Select the name from the filter drop-down list at the top left of the Scheduler Console.
Note Sorting order of the jobs listed in the summary area is controlled by the settings in the Summary Area Layout dialog. For information on changing the settings, see Using the Summary Area Layout Dialog on page 11-49.

The Tools menu contains the following options:
s s s s
11
Dependent Jobs (opens the Job Dependencies dialog) Job Editor Run Status Tool Send Event
The following sections describe these tools, with the exception of the Job Editor, which is described in Chapter 7, Defining AutoSys Jobs using the Job Editor.
s 11-22
Scheduler Console s Using Scheduler Console Tools
Using the Job Dependencies Dialog

The Job Dependencies dialog allows you to view the defined Dependencies of the selected job, and to move between the displayed dependent jobs to see their defined Dependencies. To open the Job Dependencies dialog
Select a job, and choose Tools Dependent Jobs. This action opens a dialog like the one shown in Figure 11-5.
11
When you open this dialog, it stays on top, but you can select other jobs from the summary area, and that newly selected job and its dependencies will be displayed in the dialog. To close the Job Dependencies dialog
Click OK.
Figure 11-5 Job Dependencies Dialog
11-23 s
s Scheduler Console
In the Job Dependencies dialog, the defined Dependencies for the selected job are listed in the Condition area. In the area below that, you can view lists of the Predecessor Jobs and the Successor Jobs, which include their status. To move to one of these jobs and see its Conditions and dependent jobs, double-click on the job name in the list. This dialog allows you to move quickly up and down the flow of dependent jobs in order to locate the problem in a job run, or to see what effect a problem might have. For example, if a job has not run within the time frame it was expected to, you could select the job from the job list and check its starting conditions to quickly determine what predecessor jobs might be preventing it from running.
Using the Run Status Tool

You can use the Run Status Tool to view comprehensive information about the most recent run (or the current run) of the selected job. To open the Run Status Tool
Select a job, and choose Tools Run Status Tool.
Or
11
Double-click a job.
These actions open a dialog similar to the one shown in Figure 11-6.
Note If you selected multiple jobs, the first job you selected will be the currently selected job. In addition, Auto Refresh must be on in order for the information in the Run Status Tool to update in real time.
s 11-24
Figure 11-6 Run Status Tool
Run Status Tool Menu Bar

The Run Status Tool has the following menus: File, Tools, Applications, Options, and Help. File Menu The File menu has the following options: New Run Status Tool Exit Opens a new Run Status Tool. This new Run Status Tool will update when you select a job. Closes the Run Status Tool.
11-25 s
s Scheduler Console
Tools Menu The Tools menu has the following option: Send Event Tool Opens the Send Event Tool for the selected job. Using this dialog, you can send events, and you can cancel events that you have scheduled for a later time. For information, see Using the Send Event Tool on page 11-28.
Applications Menu The Applications menu contains the following option: Job Editor Opens a Job Editor for the current job. For more information, see Chapter 7, Defining AutoSys Jobs using the Job Editor.
Options Menu The Options menu has the following option: Adopt Session Context Toggles the session context feature on or off. The default setting is on, and when this is the case and you select a job from the Scheduler Console or the Alarm Manager, the open Run Status Tool updates to reflect the selected job. If you toggle this option to off (unchecked), the Run Status Tool does not update with new selections.
Help Menu The Help menu has the following options: Contents About Displays the table of contents for the AutoSys Help. Displays the Run Status Tool version number.
s 11-26
Run Status Tool Display Fields

The following sections describe the fields in this dialog: Job Name Instance Description The name of the selected job. The name of the AutoSys instance for which this job is defined. The description text entered in the Job Editor Description field or with the description job attribute with JIL. The command to be executed for Command Jobs. If the job is a File Watcher Job, the file it is watching for appears here. If the job is a Box Job, this field is blank. The jobs entire starting condition, as specified in its job definition as well as the atomic conditions, which are the most basic components of an overall condition. This information is very useful when troubleshooting a job. The start time of the current, or the most recent run of the job. 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 is blank. The name of the machine on which the job ran or is currently running. If a job is defined to run on a virtual machine, the name of the real machine component on which it actually ran will appear here. The exit code from the most recent run of the job. If the job had to be restarted, the number of times it was started appears here.
Command
Starting Conditions
Start Time Run Time
Run Machine
Exit Code Try Count
11-27 s
s Scheduler Console
End Time Status Priority Queue Name Next Start
The end time of the most recent run of the job. If the job is currently running, this field will be blank. The current status of the job. If the job is queued to start on a machine, its priority in the queue appears here. If the job is queued to start on a machine, the name of that machine appears here. If the job has date and time starting conditions, this field shows when the next run of the job is scheduled to start. A list of Predecessor Jobs and Successor Jobs and their conditions and status. This information is in addition to the Starting Conditions information (above). For more job flow information, use the Job Dependencies dialog (described on Using the Job Dependencies Dialog on page 11-23).
Predecessor and Successor Jobs
Using the Send Event Tool

Using the Send Event Tool, you can do the following:
s s
11
Send any event that can be sent manually in AutoSys. Select the various event parameters you want to specify when sending the event. Cancel an event that has been scheduled to occur in the future.
Note To send an event on a job, you must have execute permission
on the selected job.
s 11-28
Opening the Send Event Tool

To open the Send Event Tool
Select a job and choose Tools Send Event. This action opens a dialog like the one shown in Figure 11-7. The Send Event Tool has a menu bar and several fields.
Note If you do not select a job before you open choose Send Event, a Send Event Tool opens that does not have an associated job. You can enter a Job Name in the Send Event Tool, or, if the Send Event Tool is set to Adopt Session Context (on its Options menu), you can click on a job in the Scheduler Console to associate a job with the tool.
For basic Send Event Tool usage information, see Sending an Event on page 11-35 and Cancelling a Sent Event on page 11-36.
11-29 s
s Scheduler Console
Figure 11-7 Send Event Tool
Send Event Tool Menu Bar

The menu bar contains the following menus: File, Options, and Help. File Menu The File menu contains the following options: New Send Event Tool Opens a new Send Event Tool that is not associated with a job. Exit Closes the tool.
s 11-30
Options Menu The Options menu contains the following option: Adopt Session Context Determines if the Send Event Tool will associate with the selected job in any open Scheduler Console or Alarm Manager window. If this option is selected (checked), the Send Event Tool updates to reflect the selected job. If the option is off (unchecked), the Send Event Tool does not update, and you must manually change the name or open a new tool for other jobs. Help Menu The Help menu contains the following options: Contents About Displays the table of contents for the AutoSys Help. Displays the Send Event Tool version number.
Send Event Tool Fields

Using the Send Event Tool, you can send one event at a time, selecting the event from the list in the Event Type area. You can send the event now, or you can determine a future date to send it. By default, the Job Name field at the top of the tool contains the name of the currently selected job, which is the job on which you will send the event. If you have selected multiple jobs, the name of the first one you selected appears in the Job Name field, but all selected jobs will be affected by the event sent. If desired, you can enter the name of a different job in this field, or you can select another job from the Scheduler Console summary area.
11-31 s
s Scheduler Console
These are the Event Types you can send: Start Job Starts the selected jobs if their Dependencies are satisfied. That is, this event ignores time and date conditions, but it does not ignore dependencies on other jobs (set in the Job Editor Dependencies field, or with the condition JIL attribute). Choosing this option is equal to sending a STARTJOB event. If you want to start a job immediately, regardless of its starting conditions, use the Force Start Job option. Places the selected jobs on hold, which means they cannot be started. You cannot place a job on hold if it has a STARTED or RUNNING status. Choosing this option is equal to sending a JOB_ON_HOLD event. Takes the selected jobs off hold. If you choose this option and the selected jobs have starting conditions that have been met, the jobs will be started. Choosing this option is equal to sending a JOB_OFF_HOLD event. Attaches the message in the Comment field of the Send Event Tool to the specified job for its next run. Choosing this option is equal to sending a COMMENT event. Stops the Event Processor for the selected Instance. This does not stop the database service. Choosing this option is equal to sending a STOP_DEMON event. Starts the selected jobs regardless of whether any of the starting conditions have been met. Choosing this option is equal to sending a FORCE_STARTJOB event.
Job On Hold
Job Off Hold
Comment
Stop Demon
Force Start Job
s 11-32
Job On Ice
Places the selected jobs on ice, which is the functional equivalent of deactivating the job definitions. You cannot place a job on ice if it has a STARTED or RUNNING status. Choosing this option is equal to sending a JOB_ON_ICE event. Takes the selected jobs off ice, which is the functional equivalent of reactivating the job definitions. When you take a job off ice, it will start the next time the starting conditions are met. Choosing this option is equal to sending a JOB_OFF_ICE event. Kills the selected jobs. Choosing this option is equal to sending a KILLJOB event, and its action depends on the type of the job on which you are sending the event. Forces a change in the status of the selected jobs. Ordinarily this option should not be used because AutoSys manages job state changes internally. In addition, if you use this option, you will need to send another Change Status event to change the status back to what it was. If you do select this option, you must also select the status to change to from the Send Event Tool Status drop-down list. Choosing this option is equal to sending a CHANGE_STATUS event. Changes the priority of the selected jobs to the one specified in the Send Event Tool Queue Priority field. Queue priority is the relative priority of all jobs in the queue. The lower the number, the higher the priority; zero means to run the job right away. If a job has not been started, the priority is changed for the next run only. If a job has been started, and is in a queue, the priority is changed immediately. Choosing this option is equal to sending a CHANGE_PRIORITY event.
Job Off Ice
Kill Job
Change Status
Change Priority
11-33 s
s Scheduler Console
Set Global
Sets an AutoSys global variable to the variable indicated in the Send Event Tool Global Name and Global Value fields. The Global Name and Global Value can each be a maximum of 30 characters. This event is sent with a high priority so that the Event Processor will process the variable before it is referenced by any jobs at runtime. Choosing this options is equal to sending a SET_GLOBAL event. Sends the UNIX signal specified in the Send Event Tool Signal field to the selected jobs that are running on UNIX machines. This event is ignored if the AutoSys job is running on an NT machine. Choosing this option is equal to sending a SEND_SIGNAL event.
Send Signal
For more information on any of these events, see sendevent in Chapter 1, AutoSys Commands, of the AutoSys Reference Guide for Windows NT. These are the other Send Event Tool fields: Cancel Previously Sent Event Cancel one or more events scheduled to occur sometime in the future. You can do this in one of two ways. You can either cancel a specific event (by choosing an event from the Event Types list), or cancel a specific event (or events) by scheduled time (by selecting an Event Type and the Match On Time checkbox, then indicating a time). For information, see Cancelling a Sent Event on page 11-36. Indicates that the event or events you are cancelling are based on the Time you indicate in the Future field area. For information, see Cancelling a Sent Event on page 11-36.
Match On Time
s 11-34
Now or Future
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. The Time entry must be in 24-hour format. 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 AUTOSERV instance name for the currently selected job. When events need to be sent to a different AutoSys instance, choose another instance from the drop-down list. Indicates whether the selected event should be sent with a Normal or High priority.
Comment
Instance
Send Priority
At the bottom of the Send Event Tool, there are two buttons: Send and Close. The Send button of the dialog executes, or sends, the event. The Close button closes the dialog without sending the event. If you click on either button, the Send Event Tool is closed.
Sending an Event
To send an event using the Send Event Tool
1 Make sure you have the appropriate job in the Job Name field. Note You can select multiple jobs in the Scheduler Console before you open the Send Event Tool. If you do so, the Send Event Tool will send the chosen event on all of the selected jobs. 2 Choose an Event Type.
11-35 s
s Scheduler Console
3 Choose Now or Future. If you choose Future, enter a Date and Time.
The Time entry should be in a 24-hour format.

4 Enter a Comment if desired. 5 Make sure that you have the appropriate Instance selected. 6 Choose the Send Priority from the drop-down list, either the Normal
or High.
7 Click Send.
This action sends the Event Type you selected at the Date and Time you indicated. This event is sent to the database for the selected job.
Cancelling a Sent Event

From the Send Event Tool, you can cancel one or more events scheduled to occur sometime in the future. You can do this in one of two ways: by cancelling a specific event or by cancelling a specific event by its scheduled time.
Note You should use this feature to cancel events that you have sent from the Send Event Tool. 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 Editor or from JIL.
To cancel a specific event

1 Make sure you have the appropriate job in the Job Name field. Note You can select multiple jobs in the Scheduler Console before you open the Send Event Tool. If you do so, the Send Event Tool will send this cancel event on all of the selected jobs that meet the Event Type criteria. 2 In the Event Type region, specify an event type by selecting one of the
radio buttons.
s 11-36
3 Select the Cancel Previously Sent Event checkbox. 4 Click the Send button. This process cancels all pending events of the
specified Event Type for the selected jobs. To cancel an event by its scheduled time
1 Make sure you have the appropriate job in the Job Name field. Note You can select multiple jobs in the Scheduler Console before you open the Send Event Tool. If you do so, the Send Event Tool will send this cancel event on all of the selected jobs that meet the Event Type and Time criteria. 2 Select an Event Type radio button, indicating the type of event to be
cancelled.
3 Select the Cancel Previously Sent Event checkbox. 4 Select the Match on Time check box. 5 In the Time field, indicate the scheduled event time you want to
match. The Time entry must be in 24-hour format.

6 Click the Send button. This process cancels all pending events of the
specified Event Type at the specified Time for the selected jobs. Notes on Cancelling a Send Event The Cancel Previously Sent Event feature is designed to be used primarily on events the that you have sent from the Send Event Tool. 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 Editor or from JIL. 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
11-37 s
s Scheduler Console
Using Scheduler Console Reports
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.

The Reports menu contains the following options: Job Detail Report Opens the Job Detail Report tool. Job Find Job List Last Run Last N Run Opens an InfoReports defined report. Opens an InfoReports defined report. Opens an InfoReports defined report. Opens an InfoReports defined report.
11
Using the Job Detail Report Tool
11
The Job Detail Report tool displays a real-time report for one currently selected job. This report presents job run information in the same format produced by the autorep command. It presents the following two types of reports, which you can select from the drop-down list on the bottom right of the tool: Summary Event Displays a one-line synopsis of the last or current execution of the job. Displays a detailed report listing all the events and statuses from the last or current execution of the selected job.
To open the Job Detail Report tool

Choose Reports Job Detail Report. This action opens a dialog similar to the one shown in Figure 11-8.
s 11-38
Scheduler Console s Using Scheduler Console Reports
The Job Detail Report tool has a menu bar and a display area. To dismiss the tool
Click OK.
Figure 11-8 Job Detail Report Tool
Job Detail Report Menu Bar

The Job Detail Report tool has the following menus: File, Tools, Applications, Options, and Help. File Menu The File menu has the following options: New Job Detail Report Exit Opens another Job Detail Report tool for the selected job. Closes the Job Detail Report tool.
11-39 s
s Scheduler Console
Tools Menu The Tools menu has the following options: Send Event Opens a Send Event Tool for the selected job. For information, see Using the Send Event Tool on page 11-28. Opens a Run Status Tool for the selected job. For information, see Using the Run Status Tool on page 11-24.
Run Status Tool
Applications Menu The Applications menu has the following option: Job Editor Opens a Job Editor for the selected job. For information, see Chapter 7, Defining AutoSys Jobs using the Job Editor.
Options Menu The Options menu has the following option: Adopt Session Context Determines if the Job Detail Report tool will associate with the selected job in any open Scheduler Console or Alarm Manager windows. If this option is selected (checked), the Job Detail Report tool updates to reflect the selected jobs Job Name. If the option is off (unchecked), the Job Detail Report tool does not update, and you must open a new tool to view other job information.
Help Menu The Help menu has the following options: Contents About Displays the table of contents for the AutoSys Help. Displays the version for the Job Detail Report.
s 11-40
Scheduler Console s Using Scheduler Console Reports
Viewing Reports with InfoReports

AutoSys provides a number of reports that you can view using the InfoReports Viewer. When you install AutoSys Console Utilities, the program installs the InfoReports Viewer and a set of defined reports. The Reports menu contains the following defined InfoReports-based reports: Job Find Generates a job report that includes the jobs that match the pattern for a job name that you enter. Figure 11-9 shows a job find report for the testjob1 job. Generates a job list report based on a list of selected jobs, or based on the entire list of jobs in that instances database. Generates a last run report on the selected job. The report contains information on the last run of the job. Generates a report for the specified run (n) since the last run of the selected job. You can enter the last, second to last, or a number for the nth run since the last run.
11
Job List
Last Run
Last N Run
When you select one of these options, the InfoReports Database Login dialog opens, and you can select the database (for the AutoSys instance) to which you want to connect. When you complete the process, a report similar to the one shown in Figure 11-9 displays. For information on using InfoReports, see the InfoReports documentation.
11-41 s
s Scheduler Console
Figure 11-9 InfoReports Job Find Report (for testjob1)
s 11-42
Scheduler Console s Setting Scheduler Console Preferences
Setting Scheduler Console Preferences

General User Defined Commands User Defined Reports Summary Area Layout Action Area Layout Opens the General dialog (see Using the General Dialog on page 11-44). Opens the User Defined Buttons dialog (see Using the User Defined Buttons Dialog on page 11-45). Opens the User Defined Reports dialog (see Using the User Defined Reports Dialog on page 11-47). Opens the Summary Area Layout dialog (see Using the Summary Area Layout Dialog on page 11-49). Opens the Action Area Layout dialog (see Using the Action Area Layout Dialog on page 11-52).
11
The Scheduler Console Preferences menu contains the following options:
Time Perspective Presents three submenu options (see Setting the Time Perspective on page 11-56). AutoRefresh You can toggle the AutoRefresh setting to determine if the Scheduler Console updates automatically. By default, AutoRefresh is selected (set to on). This setting indicates that the Scheduler Console should be updated based on the Refresh Interval setting in the General dialog. If you uncheck the AutoRefresh option, setting it to off, the Console display is not updated automatically. To update the display, you can check the AutoRefresh option, or you can click the Refresh button.
11-43 s
s Scheduler Console
Using the General Dialog

Using the General dialog, you can set the following for the Scheduler Console:
s
11
The Refresh interval, in seconds. This setting indicates how often the Scheduler Console should refresh. To refresh, it reads the database(s) and updates the summary area job list. The default setting is every 60 seconds. The Confirm action function. This setting indicates whether or not you want confirmation dialogs displayed when you click on any Action Area Layout buttons, or choose any Action menu options. The default setting is on, which indicates that a confirmation dialog should be displayed before the execution of the actions. The Button Appearence. You can set the action area and user-defined buttons to display Text Only, Icon Only, or Both. If you choose Icon Only, the user-defined buttons will all have the same icon, and the tool tip will contain the name of the button.
To open the General dialog

Choose Preferences General. This action opens a dialog like the one shown in Figure 11-10.
To close the General dialog

Click OK to set the modified settings and dismiss the dialog.
Or
Click Cancel to make no changes and dismiss the dialog.
s 11-44
Figure 11-10 General Dialog
Using the User Defined Buttons Dialog

You can use the User Defined Buttons dialog to implement shortcuts to commands you use often.
Note You can create up to 20 user-defined buttons.
11
Creating Command Buttons

To create buttons
1 Choose Preferences User Defined Commands. This action opens a
dialog like the one shown in Figure 11-11.

2 In the dialog, click in the Name field, and enter the name you want to
appear on the button.

Note The button text can be 15 characters or less. 3 Click in the Command field, and enter the command line.
11-45 s
s Scheduler Console
Note The command line can contain environment variables, and it can contain $JOB and $INST. Use the $JOB variable for arguments that take a job name, and the selected job will be used when you click the button. Use the $INST variable for arguments that take the AutoSys instance name, and the selected instance will be used when you click the button. 4 Click OK. This action puts a button with the specified name in the
action area. When you click the new button in the action area, it executes the specified command.
Figure 11-11 User Defined Buttons Dialog
Using AutoSys-specific Commands

If you want to use an AutoSys command in the Command field of this dialog, you must use the following syntax:
initautosys -i $INST -r "command_line"
s 11-46
where:
"command_line"
Specifies the full command line. This command line must be in quotes. The command line can contain environment variables, and it can contain $JOB and $INST. Use the $JOB variable for arguments that take a job name, and the selected job will be used when you click the button. Use the $INST variable for arguments that take the AutoSys instance name, and the selected instance will be used when you click the button.
Note When you choose AutoSys commands to execute from a user-
defined button, you should use only persistent commands.
Using the User Defined Reports Dialog

You can use the User Defined Reports dialog to implement a menu item on the Reports menu.
11
Creating Reports Menu Items

To create report menu items
1 Choose Preferences User Defined Reports. This action opens a dialog
like the one shown in Figure 11-12.

Note When you open this dialog, the predefined InfoReports are already defined. These are the reports that appear on the Reports menu. If you want to remove a report from the menu, you can delete it in this dialog. 2 In the dialog, click in the Name field, and enter the name you want to
appear on the Reports menu.
11-47 s
s Scheduler Console
Note The text can be 15 characters or less. 3 Click in the Command field, and enter the command line. Note The command line can contain environment variables, and it can contain $JOB and $INST. Use the $JOB variable for arguments that take a job name, and the selected job will be used when you click the button. Use the $INST variable for arguments that take the AutoSys instance name, and the selected instance will be used when you click the button. 4 Click OK. This action puts the option with the specified name on the
Reports menu. When you choose the new Reports menu item, it executes the specified command.
Figure 11-12 User Defined Reports Dialog
s 11-48
Using the Summary Area Layout Dialog
11
Using the Summary Area Layout dialog, you can customize the summary area display. You can set the Column Size, Column Order, and Sort Order. By default, jobs appear in the summary area in the order they are pulled from the database. In addition to using the Summary Area Layout dialog to customize the display of the Scheduler Console, you can modify the layout area in the window.
Customizing the Summary Area in the Scheduler Console

To resize the summary area columns in the Scheduler Console
Drag the edges of the titles.
To select the primary sorting order

Click the title name by which you want the job list sorted. (You can only choose the first, or primary, category by which the list is sorted.)
You can, customize the summary area further by using the Summary Area Layout dialog.
Customizing the Display with the Summary Area Layout Dialog

To open the Summary Area Layout dialog
Choose Preferences Summary Area Layout. This action opens a dialog like the one shown in Figure 11-13.
11-49 s
s Scheduler Console
Figure 11-13 Summary Area Layout Dialog
Using this dialog, you can set the Column Length, Column Order, and Sort Key. Each setting is based on the Column Name, indicated on the left side of the dialog. The Column Length setting corresponds to the size of the column, and the Column Order and Sort Key settings are relative to the other settings. To save the settings you make in the Summary Area Layout dialog
Click OK.
To return to the default settings

Click Default.
To close the dialog without saving the settings

Click Cancel.
s 11-50
Note If you select a Sort Key for the Summary Area Layout that is different from the default order (which is no sort order), the levels of Box Jobs will not display indentation correctly; the indentation will display, but the order will not be based on the jobs relationship to the containing Box Job.
Sort Key Settings

The Summary Area Layout dialog allows you to specify the sort order in which the jobs should be listed. By default, there is no sort order; the jobs are displayed in the order they are returned from the database. However, you can modify this order. To modify the sort order, you can choose one of the following as primary sort criteria, and you can choose other levels of priority that will be used when appropriate: Job Name Instance Status Last Change Machine Type Jobs will be sorted by name in ascending alphanumeric order. Jobs will be sorted by their instance name, in ascending alphabetical order. Jobs will be sorted by their current status, in ascending alphabetical order. Jobs will be sorted by the date of their last change. Jobs will be sorted by the machine on which they run or have run, in ascending alphabetical order. Jobs will be sorted by the type of job, in ascending alphabetical order.
11-51 s
s Scheduler Console
Start Time
Jobs will be sorted by the starting time for the most recent execution of the job, or if there is no recent run data, the time that it is scheduled to run. Jobs will be sorted in the order in which they were created.
Job ID
Note If you want to view levels of Box Jobs, you should use the default sort order, which is no sort order. If you choose a sort order, the indenting of the various Box Job nesting levels has no meaning, and there is no indication of which jobs are in which Box Job.
Using the Action Area Layout Dialog
11
The Action Area Layout dialog allows you to select the AutoSys-specific buttons you want to appear in the control area at the top of the Scheduler Console. By default, all of the buttons are selected to be displayed. To open the Action Area Layout dialog
Choose Preferences Action Area Layout. This opens a dialog like the one shown in Figure 11-14.
s 11-52
Figure 11-14 Action Area Layout Dialog
To have buttons in the action area for any of these tools or actions
Select the tools or actions, and click OK. This puts the appropriate buttons in the action area.
When you click a tool button in the action area, the related dialog opens. When you click an action button, a confirmation dialog displays, and after you click OK, the associated event is sent. If you have initiated an action on multiple jobs, the confirmation dialog will display the list of jobs you have selected.
11-53 s
s Scheduler Console
Action Area Layout Tool and Action Buttons

From the Action Area Layout dialog, you can select from the following tool and action buttons: Send Event... Opens the Send Event Tool, which allows you to send any type of event. For information, see Using the Send Event Tool on page 11-28.
Job Detail Report... Opens the Job Detail Report tool for the selected jobs. This dialog displays a real-time report of the job run information (in the format of the autorep command output). For information, see Using the Job Detail Report Tool on page 11-38. Dependent Jobs... Opens the Job Dependencies dialog for the selected jobs. This dialog shows the Current Job Name and the Predecessor Jobs and Successor Jobs. When you select a job in this dialog, the starting Condition also displays. You can also double-click on the displayed jobs, to see their dependencies. For information, see Using the Job Dependencies Dialog on page 11-23. Opens a Job Editor with the selected jobs. For information on the Job Editor, see Chapter 7, Defining AutoSys Jobs using the Job Editor. Starts the selected jobs if the defined Dependencies are met. This action ignores Date/Time starting conditions, but it does not ignore defined Dependencies. You can only use this option to start top-level jobs; do not use it on jobs in boxes. Choosing this option is equal to sending a STARTJOB event. Kills the selected jobs. Choosing this option is equal to sending a KILLJOB event.
Job Editor...
Start Job
Kill Job
s 11-54
Force Start Job
Starts the selected jobs regardless of whether the starting conditions have been met. Choosing this option is equal to sending a FORCE_STARTJOB event. Places the selected jobs on hold, which means they cannot be started. You cannot place a job on hold if it has a STARTED or RUNNING status. Choosing this option is equal to sending a JOB_ON_HOLD event. Takes the selected jobs off hold. If you choose this option and the selected jobs have starting conditions that have been met, the jobs will be started. Choosing this option is equal to sending a JOB_OFF_HOLD event. Places the selected jobs on ice, which is the functional equivalent of deactivating the job definitions. You cannot place a job on ice if it has a STARTED or RUNNING status. Choosing this option is equal to sending a JOB_ON_ICE event. Takes the selected jobs off ice, which is the functional equivalent of reactivating the job definitions. When you take a job off ice, it will start the next time the starting conditions are met. Choosing this option is equal to sending a JOB_OFF_ICE event.
On Hold
Off Hold
On Ice
Off Ice
Note If you want to add your own buttons, see Using the User Defined
Buttons Dialog on page 11-45.
11-55 s
s Scheduler Console
Setting the Time Perspective

The Time Perspective option has the following submenu options that control the time perspective of the summary area display: Server Time Displays the time based on the time zone of the AutoSys database.
11
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, Local Machine Time is used. Local Machine Time Displays the time in the time zone of the machine on which your Scheduler Console is running.
The Time Perspective that you choose appears in the status bar at the bottom of the Scheduler Console. If it is based on a job, the job name appears before the time in the display. If it is based on an instance, the instance name appears before the time. If you do either of the following, the Local Machine Time is used:
s s
Do not select a job. Select multiple jobs with different or no time zone settings.
s 11-56
12
Managing Alarms
This chapter describes how to use the Alarm Sentry and the Alarm Manager to manage alarms. Alarms are information events, and they invoke no action on their own.
Using the Alarm Sentry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2 Using the Alarm Sentry Menu Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2 Using the Alarm Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3 Using the Alarm Manager Menu Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-6 Using the Alarm Manager Alarm List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-8 Viewing the Currently Selected Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-9 Setting the Refresh Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-10 Filtering Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-11 Selecting Alarms by Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-13 Selecting Alarms by State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-14 Selecting Alarms by Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-14 Selecting Alarms by Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-14
12-1 s
s Managing Alarms
Using the Alarm Sentry
Using the Alarm Sentry
12
The Alarm Sentry window displays a button for each instance that it can access. These buttons serve both as alarm indicators and as a way to open the Alarm Manager for the specific instance. When an alarm event occurs, the button for an the appropriate instance changes color. You can then click the button to open an Alarm Manager for that instance. To open the Alarm Sentry
Click the Alarm Sentry button in the GUI Control Panel. This action opens a window similar to the one shown in Figure 12-1. Your Alarm Sentry will have a button for each instance it can access.
Figure 12-1 Alarm Sentry for Two Instances
In addition to the button area display, the Alarm Sentry has a menu bar. In the button display area, there is a button for each instance to which the Alarm Sentry can connect. The number that follows the instance name specifies the number of open alarms that instance has. The status area at the bottom of the window indicates whether the Alarm sentry is updating or done updating.
s 12-2
Managing Alarms s Using the Alarm Manager
Using the Alarm Sentry Menu Bar

The Alarm Sentry has the following menus: File, Preferences, and Help.
12
File Menu
The File menu contains the following option: Exit Closes the Alarm Sentry.
Preferences Menu
The Preferences menu contains the following option: Refresh Interval Opens the Refresh Interval dialog that you can use to set the time in seconds between refresh (updating the buttons based on the database information). You set the interval in seconds, and the default setting is every 60 seconds.
Help Menu
The Help menu contains the following options: Contents About Displays the table of contents for the AutoSys Help. Displays the Alarm Sentry version number.
Using the Alarm Manager

The Alarm Manager lets you view alarms as they arrive, acknowledge them, and change their status from Open to Acknowledged or Closed. This feature provides a useful tracking mechanism for all the alarms issued on your system.
12
12-3 s
s Managing Alarms
To display the Alarm Manager dialog

Click an instance-specific button in the Alarm Sentry. This action opens an instance-specific Alarm Manager, one that displays alarms for the invoking instance only.
Or
Click the Alarm Manager button in the GUI Control Panel. This action opens an Alarm Manager that displays the alarms for all instances to which it can connect.
Either of these actions open an Alarm Manager dialog similar to the one shown in Figure 12-2.
Note In addition, you can open the Alarm Manager from the Scheduler Console by choosing Alarm Manager from the Applications menu.
s 12-4
Figure 12-2 Alarm Manager
The Alarm Manager dialog has a menu bar and the following three regions, which are described in the sections below:
s s s
Alarm List at the top of the dialog Currently Selected Alarm in the middle of the dialog Refresh area at the bottom of the dialog
12-5 s
s Managing Alarms
Using the Alarm Manager Menu Bar
12
The Alarm Manager menu bar contains the following menus: File, Filters, Tools, Preferences, and Help.
File Menu
The File menu contains the following options: New Alarm Manager Exit Opens a New Alarm Manager. Closes the Alarm Manager.
Filters Menu
The Filters menu contains the following options: Default Alarm Criteria Select Alarms Resets the filter criteria to the default and updates the Alarm Manager Alarm List to reflect this. Displays the Alarm Selection dialog (described on page 12-11). Use this dialog to define the filter by which you want to view alarms.
Tools Menu
The Tools menu contains the following options: Run Status Tool Opens the Run Status Tool for the Currently Selected Job. The Run Status Tool displays a job summary, including information about the most recent, or current, run of the job for which the alarm was generated. For information, see Using the Run Status Tool in Chapter 11, Scheduler Console.
s 12-6
Send Event
Opens the Send Event Tool for the selected job (the job for which the alarm was generated). Using this dialog, you can send events, and you can cancel events that have been scheduled for a later time. For information, see Using the Send Event Tool in Chapter 11, Scheduler Console.
Job Detail Report Opens the Job Detail Report tool for the selected job (the job for which the alarm was generated). This dialog displays a real-time report of the job run information (in the format of the autorep command output). For information, see Using the Job Detail Report Tool in Chapter 11, Scheduler Console.
Preferences Menu
The Preferences menu contains the following option: General Opens the Preferences dialog in which you can set the Time between refreshes in seconds, and you can enable Sound. The default refresh interval time is 60 seconds, and for refresh to work, you must select the Auto Refresh checkbox (which is the default setting). If you select the Sound checkbox in the Preferences dialog, the running Alarm Manager plays sound clips associated with alarms each time a new alarm is generated. This Sound setting overrides the Enable Sound setting on the AutoSys Administrator Sounds screen.
12-7 s
s Managing Alarms
Help Menu
The Help menu contains the following option: Contents About Displays the table of contents for the AutoSys Help. Displays the Alarm Manager version number.
Using the Alarm Manager Alarm List
12
The Alarm List region of the dialog displays a list of all the alarms that are currently in the system and that meet the specified viewing criteria, either the default or the one specified in the Alarm Selection dialog. 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:
s s s
Alarm Type, or the type of Alarm generated. Job Name, which is the job for which the alarm was generated. Time, which is composed of the date and time at which the alarm was generated. State, which is the alarms current state. Comment, which is any comment associated with the alarm at the time it was generated. Instance, which is the name of the instance for which the job is defined.
s s
Alarms are displayed in reverse order of occurrence; the newest alarms appear at the top of the list and older ones appear farther down.
s 12-8
To make an alarm the Currently Selected Alarm

Click on its line in the alarm list. When you do this, you can view more information about the alarm.
You can also select multiple alarms, which allows you to perform actions on all of the selected alarms multiple alarms at the same time. To select multiple alarms
Press the <Control> key and single-click on each alarm that you want to select. Pressing the <Control> key and single-clicking on a selected alarm will deselect the alarm.
Or
Click on one alarm, press the <Shift> key, and click on another alarm. This will select the two alarms and all the alarms in the list between them.
Single-clicking anywhere in the alarm list will deselect the currently selected alarms.
Viewing the Currently Selected Alarm
12
The Currently Selected Alarm region of the dialog displays more information about the currently selected alarm and allows you to enter a response in the Response scrollable text box. The Response scrollable text 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. Once you enter your Response, click Apply to write it to the database. The User field, beneath the Response scrollable text box, shows the user who invoked the Alarm Manager. This read-only field shows which user responded to the alarm field.
12-9 s
s Managing Alarms
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 return it to the Open state. To change the Currently Selected Alarm to Acknowledged or Closed
Select the appropriate radio button, and click Apply.
If you change the alarm to Acknowledged, it remains on the list. If you change the alarm to Closed, it is removed from the list.
Registering Responses and Changing Alarm States

To register a response or change the state of an alarm in the AutoSys database, you must explicitly save the alarm. Because the Alarm Manager will probably run on a continual basis, use the Apply button to register changes that you make to any alarms. That is, when you enter a response or change alarm states, you must click Apply to save the change to the database.
Setting the Refresh Behavior

At the bottom of the Alarm manager is the Refresh area, and it contains the Auto Refresh setting, which you can turn off or on, and the Refresh button. By default Auto Refresh is selected (set to on). The on setting indicates that the Alarm Manager should be updated based on the setting in the General dialog, which you can open from the Preferences menu. The default refresh interval is 60 seconds. With this setting, the Alarm Manager reads from the database to update the alarm list every 60 seconds. If you uncheck the Auto Refresh checkbox, setting it to off, the Console display is not updated.
12
s 12-10
Managing Alarms s Filtering Alarms
To update the display

Check the Auto Refresh checkbox.
Or
Click the Refresh button.
Filtering Alarms
Alarms and their responses are stored in the AutoSys database, from which you can retrieve them for viewing or for adding additional responses. To control dynamically which alarms are displayed in the Alarm Manager, use the Alarm Selection dialog.
12
Using the Alarm Selection dialog, you can select alarms by the following:
s s s s
Type of alarm State of alarm (Open, Acknowledged, or Closed) Date and time of the alarms occurrence Instance name
Note Alarms that have been archived cannot be displayed.
12-11 s
s Managing Alarms
Filtering Alarms
To display the Alarm Selection dialog

Choose Filters Select Alarms. The Alarm Selection dialog appears with the defaults set, as shown in Figure 12-3.
Figure 12-3 Alarm Selection Dialog
The Alarm Selection dialog is divided into the following regions, described in the sections below:
s s s s
Select by Type Select by State Select by Instance Select by Time
After you define your filter, you can view it in the Alarm Manager.
s 12-12
Managing Alarms s Filtering Alarms
To view the selection criteria in the Alarm Manager

Click OK. This action sets your selections and dismisses the Alarm Selection dialog.
To dismiss the dialog without applying the selections

Click Cancel.
Selecting Alarms by Type
12
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 Types of alarms. To choose a single alarm from the list
Single-click the alarm name.
To choose a range of alarms

Click and hold the mouse button on the first alarm name, drag the cursor to the last alarm in the range, and release the mouse button.
To choose noncontiguous alarms

Press the <Control> key and single click the desired alarms. To deselect an alarm, press the <Control> key and single-click the selected alarm.
To choose all alarm types

Select the All Types option, which overrides any specific or individual selections.
For information on the Alarm Types, see the Alarms section in Chapter 5, System States, of the AutoSys Reference Guide for Windows NT.
12-13 s
s Managing Alarms
Filtering Alarms
Selecting Alarms by State

You can also select alarms by the state of the alarm. You can select All States, or you can select individual states. To do so, you click on, and check, the appropriate checkboxes. The default setting is to display all Open and Acknowledged alarms.
12
Selecting Alarms by Instance

You can select which AutoSys instances you want included in this filter. The instances on this list are the ones to which this Alarm Manager can connect.
12
Selecting Alarms 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. To indicate a specific date and time window
Uncheck the All Times checkbox, and fill in the From Date, From Time, To Date, and To Time fields. You can specify dates without times, but you cannot specify times without dates. You must use a 24-hour format when specifying times.
12
For your convenience, the current system date and time are filled in automatically.
s 12-14
13
Monitoring and Reporting on Jobs
This chapter describes how to define and create monitors and browsers (reports).
Using AutoSys Monitors and Browsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-3 Using Monitors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-4 Using Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-4 Using the Monitor/Browser Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-5 Using the Monitor/Browser Editor Menu Bar . . . . . . . . . . . . . . . . . . . . . . . . . . 13-6 Defining Monitors and Reports with the Editor . . . . . . . . . . . . . . . . . . . . . . . . . . 13-9 Defining a Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-9 Defining a Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-12 Closing the Monitor/Browser Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-13 Setting Monitor and Report Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-13 Setting Event Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-14 Setting the Job Selection Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-16 Setting Monitor Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-17 Setting the Browser Time Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-18
13-1 s
s Monitoring and Reporting on Jobs
Running a Monitor or Generating a Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-19 Defining Monitors and Reports using JIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-20 Defining Monitors using JIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-21 Defining Reports using JIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-22
s 13-2
Monitoring and Reporting on Jobs s Using AutoSys Monitors and Browsers
Using AutoSys Monitors and Browsers
13
You can define and create monitors and browsers to view the state of the AutoSys system. Monitors provide a real-time view of the system. Browsers are reports that provide historical information about job executions. Monitors and reports enable you to filter and screen only the information you are interested in from a vast collection of data. That is, they are tools that can give you the information you want. Because browsers are reports, and because report is a common term, this document uses the term report, except when talking about the Monitor/Browser interface components. Monitors and reports are simply applications that retrieve data from the AutoSys database. Because 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 they work with Dual Event Servers. Also, you can run monitors and reports on any AutoSys client machine. You can define monitors and reports to display events by using the following:
s s s
Event type Job type Job name
In addition, you can define reports to display events based on the time the events occurred. You cannot define monitors to display based on event time because they provide real-time information. You can define monitors and reports by using the Monitor/Browser Editor, which you open from the GUI Control Panel. In the Monitor/Browser Editor, you can define a new monitor or report by assigning a name and specifying a number of attributes that define its behavior.
13-3 s

Using AutoSys Monitors and Browsers
In addition, you can define monitors and reports to AutoSys by passing Job Information Language (JIL) statements to the jil command. For information, see Defining Monitors and Reports using JIL on page 13-20. In either case, the monitor or report definitions are stored in the database. Because the definitions are stored in the database, you can run defined monitors or reports at any time without redefining the criteria.
Using Monitors
Monitors provide a real-time view of the AutoSys system. These are the two steps necessary to use a monitor:
1 Define the events to monitor. 2 Run the defined monitor.
13
A running monitor is an application that polls the database for new events that meet the selection criteria. Monitors are strictly informational. They provide an up-to-the-minute window to AutoSys events as they occur. For Box Jobs, you can specify to track all job levels.
Note Monitors provide a picture of the systems state in real-time. If the Event Processor is down, monitors will not provide any information.
Using Reports
13
A report (or browser) provides historical information about job executions. A report is a customized query run against the database, and it is based on the selection criteria you define for the specific report. Its primary function is to enable you to get very specific information quickly. Reports can display only the events still in the database; archived events are inaccessible and cannot be displayed.
s 13-4
Monitoring and Reporting on Jobs s Using the Monitor/Browser Editor
For example, you could create a report based on the finish time of the database backup for the last two weeks, or one based on all jobs that have an alarm associated with them. You can also create reports that contain all the job levels in Box Jobs. Report definitions are also stored in the database, enabling you to run defined reports at any time, without redefining the criteria.
Using the Monitor/Browser Editor

To define a monitor or report using the Monitor/Browser Editor
1 Open the GUI Control Panel from the AutoSys Graphical Interface
13
icon in the AutoSys program group.

2 In the GUI Control Panel, click the Monitor/Browser Editor button,
which displays the Monitor/Browser Editor shown in Figure 13-1.

3 Select Monitor or Browser from the drop-down list at the top of the
editor window.
4 Set the various attributes and their values using the fields and
checkboxes.
5 Save the monitor or report definition to the database. When you do
this you can select the instance you want to save the definition to, and you can specify the name of the monitor or report.
Note When you first select an instance in any of the Monitor/Browser Editor dialogs, AutoSys establishes a connection to that instances database, and it maintains that connection until you close the Monitor/Browser Editor.
13-5 s

Figure 13-1 Monitor/Browser Editor
The Monitor/Browser Editor contains fields that represent all the information you need to define a monitor or report. For more information on these fields, see Setting Monitor and Report Attributes on page 13-13.
Using the Monitor/Browser Editor Menu Bar

At the top of the Monitor/Browser Editor is a menu bar that contains the following menus: File, Edit, and Help.
13
s 13-6
Monitoring and Reporting on Jobs s Using the Monitor/Browser Editor
File Menu
The File menu contains the following options: New Opens the New Monitor/Browser dialog, which allows you to select an instance and enter a unique name for the new monitor or report you are going to define. The monitor or report name identifies the monitor or report to AutoSys, and must be unique within an AutoSys instance. A monitor and report cannot have the same name, but a monitor or report can have the same name as a job. A monitor or report name can be from 1-30 alphanumeric characters. Embedded spaces are illegal. Open Opens the Open dialog, which allows you to search for and select an existing monitor or report. In the Pattern field of this dialog, you can specify any string, including the % wildcard character, then click Search to display a list of those monitors and reports whose names include the string. The default filter, %, displays a list of all monitor and report names. Stores the currently displayed monitor or report in the database. When you Save a definition for the first time, this option opens the Save As dialog. Opens the Save As dialog, which allows you to select an instance and enter a new name for the monitor or report. You can use this option to save a definition to a different instance and/or a different name.
Save
Save As
13-7 s

Delete
Displays the Delete Monitor/Browser dialog, which allows you to search for existing monitors and reports. In this dialog, you can select one or more monitors or reports, and click OK. This action deletes the selected definition(s) from the database. Runs the current monitor or report and displays output in an AutoSys Instance Command Prompt window. Monitor and report definitions must be saved in the database before they can be run. Opens a new Monitor/Browser Editor. Closes the Monitor/Browser Editor. If you have unsaved work, you are prompted to choose whether or not to save it before the editor is closed.
Run Monitor/Browser
New Monitor/Browser Editor Exit
Note When you first open a Monitor/Browser Editor, and when you select a new instance in any of the Monitor/Browser dialogs, AutoSys establishes a connection to that instances database, and it maintains that connection until you close the Monitor/Browser Editor.
s 13-8
Monitoring and Reporting on Jobs s Defining Monitors and Reports with the Editor
Edit Menu
The Edit menu contains the following option: Clear Clears the Monitor/Browser Editor without affecting the database. Use this button to clear all fields before you begin defining a new monitor or report.
Help Menu
The Help menu contains the following options: Contents About Displays the table of contents for the AutoSys Help. Displays the Monitor/Browser Editor version number.
Defining Monitors and Reports with the Editor
13
This section contains examples of creating a monitor and a report. To follow the steps in these exercises, you must first open a Monitor/Browser Editor by opening the AutoSys GUI Control Panel and clicking the Monitor/Browser Editor button.
Note The examples in this section demonstrate how to use the Monitor/Browser Editor. There are corresponding examples that demonstrate using JIL statements to create monitors and reports in Defining Monitors and Reports using JIL on page 13-20.
Defining a Monitor
This example describes how to 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.
13
13-9 s

To define the example monitor Follow these steps using the open Monitor/Browser Editor:
1 In the drop-down list at the top, leave the Monitor setting. 2 In the Event Types area, select the Alarm checkbox. 3 In the Job Change Status Events subarea, select the Running, Success,
Failure, and Terminated checkboxes.

4 In the Job Selection Criteria area, select the All Jobs radio button. 5 Choose File Save, which opens the Save As dialog. 6 In the Save As dialog, select an Instance, and enter the following name
for the new monitor:

Regular 7 In the Save As dialog, click OK. A message is displayed when the
monitor definition is successfully written to the database. Your entries in the Monitor/Browser Editor should look like those shown in Figure 13-2. You can leave the Monitor/Browser Editor open to do the next example.
s 13-10
Monitoring and Reporting on Jobs s Defining Monitors and Reports with the Editor
Figure 13-2 Monitor/Browser Editor for Example Monitor
For information on running a monitor, see Running a Monitor or Generating a Report on page 13-19.
Note If you want to run the monitor, you must save it first, and then choose File Run Monitor/Browser. When you run a monitor or a report from the Monitor/Browser Editor, an AutoSys Instance Command Prompt window opens to display the monitor or report output.
13-11 s

Defining a Report
This example describes how to define a report with the name Alarm_Rep. This definition will create a report that contains all alarms on any job, from May 22, 1997, at 2:00 a.m. to the present. To define the example report Follow these steps using the open Monitor/Browser Editor:
13
1 Choose File New. This action opens a New Monitor/Browser dialog. 2 In the dialog, select an Instance, and enter the following report name: Alarm_Rep 3 Click OK in the New Monitor/Browser dialog. This action returns you
to the Monitor/Browser Editor.

4 From the drop-down list at the top of the window, select Browser. 5 In the Event Types area, select the Alarm checkbox. 6 In the Job Selection Criteria area, select the All Jobs radio button. 7 In the Browser Time Criteria area, enter the date and time in the Events
After Date/Time text field as follows (or you can enter a different, more appropriate, time):
05/22/1997 2:00 8 Choose File Save, and click OK in the Save As dialog. A message is
displayed when the report definition is successfully written to the database. Your entries in the Monitor/Browser Editor should look like those shown in Figure 13-3.
s 13-12
Monitoring and Reporting on Jobs s Setting Monitor and Report Attributes
Figure 13-3 Monitor/Browser Editor for Example Report
Closing the Monitor/Browser Editor

To close the Monitor/Browser Editor
Choose File Exit.
13
Setting Monitor and Report Attributes

To set the monitor or report attributes, use the fields on the Monitor/Browser Editor. The Monitor/Browser Editor is divided into the following areas:
s s
13
Event Types Job Selection Criteria
13-13 s

s s
Monitor Options Browser Time Criteria
You can define several different filters by which monitors and reports will track events. When you complete a definition, the events that are tracked are determined by the combination of the Event Types and the Job Selection Criteria settings.
Setting Event Types

The Event Types you specify determine which AutoSys events will be monitored or reported. Events include the following:
s s s
13
Changes in the state of AutoSys jobs AutoSys-generated occurrences, such as alarms Manually-generated events, such as starting a job, placing a job on hold, or killing a job
Note For each event type described in this section, the
corresponding JIL attribute is provided on the right.

.
All Events
all_events
Selecting the All Events checkbox specifies that all events will be tracked for the selected jobs. Any other Event Types filtering settings are ignored. All Events include job status events and alarms. If you do not select this checkbox, the other Event Types settings are used.
s 13-14
Note If you want to monitor all the events for all jobs, you should not run a monitor. Instead, you should display the Event Processor log in real time, by using the following command at an AutoSys Instance Command Prompt: autosyslog -e
Running a monitor adds another connection to the database and establishes another process that is continually polling the database. This has a significant impact on system performance. Moreover, the information logged by the Event Processor contains more diagnostic information than the monitor does. Reports connect to the database only once to get the information, so they do not have the same impact on system performance as monitors do.
.
Alarm
alarm
Selecting the Alarm checkbox specifies that AutoSys-generated alarms should be tracked. If you select the All Events checkbox, alarms are already tracked. To limit the events that are tracked, however, you can select both Alarm and All Change Status Events, or choose specific Job Change Status Events as filters (described below). All Change Status Events
all_status
Selecting the All Change Status Events checkbox specifies that all job status events should be tracked. Job status events occur whenever a jobs status changes. If this attribute is checked all of the Job Change Status Events shown below as well as a few AutoSys-internal job status events are tracked. You can select both All Change Status Events and Alarms as filters. If you select the All Events checkbox, change status events are automatically tracked.
13-15 s

Job Change Status Events Instead of selecting All Change Status Events, you can select the following Job Change Status Events (JIL attribute values are in parentheses):
s s s s s s
Running (running) Success (success) Failure (failure) Terminated (terminated) Starting (starting) ReStarting (restart)
Note If you select All Change Status Events, any Job Change Status Events that you select are ignored, because they are already included in the All Change Status Events filter.
Setting the Job Selection Criteria
13
In the Job Selection Criteria area you can indicate the AutoSys jobs to track. The events to be tracked are determined by the combination of the Event Types that you set as filters and the Job Selection Criteria you set in this area. Job Filter
job_filter
You can set the Job Filter to one of three settings: All jobs (no job filtering), all Jobs in a Box Job with a specified name, or a single job with a specified name. If you select either the Jobs in Box named or Single Job named radio buttons, you must enter the job name in the field to the right of these choices.
s 13-16
Setting Monitor Options

The monitor attributes in the Monitor Options area are optional.
Note For each of the following monitor options, the corresponding
13
JIL attribute is provided on the right. Sound

sound
Selecting the Sound checkbox specifies that the sound facility should be used. If the NT machine running the monitor has sound capabilities and you have enabled sound using the AutoSys Administrator, AutoSys uses sound to announce the events as they occur. The announcement is from pre-recorded sound clips. For more information on enabling AutoSys sounds, see the AutoSys Sounds section of Chapter 15, AutoSys Administrator.
Note It is strongly recommended that you use the sound attribute for monitoring AutoSys, especially alarms. It frees you from needing to look through output files to see if there were any problems. However, for the sound attribute to work, the monitor must be running.
Alarm Verification Required
alarm_verif
Selecting the Alarm Verification Required checkbox specifies that personnel must respond to alarms in order to turn the alarms off. This verification feature prompts users (in the window running the monitor) for their initials and a comment. This information is time stamped and recorded in the database, along with the alarm event. When you turn on this option, the log provides an account of the alarms that were responded to, and at what time they were responded to.
13-17 s

An important feature of this attribute is the alarm sound is repeated every 20 seconds until there is a response. Therefore, if you momentarily step out of the room and there is an alarm, it keeps playing the sound clip until someone responds.
Setting the Browser Time Criteria
13
When defining reports, you must specify one of the Browser Time Criteria options. Reports are based on all events in the database, and the Browser Time Criteria allows you to select events that occurred within a particular span of time. The two choices are mutually exclusive.
Note These settings are disabled for monitors because time is not
used in monitors; monitors only show events as they occur. Current Run Only
currun
Selecting the Current Run Only checkbox specifies that only events in the current or most recent execution of the specified job(s) will be reported. This option allows you to get a report on what happened most recently. This is the default selection. For example, to get a report on all the jobs that AutoSys restarted in its last run, select Restart in the Job Change Status Events area, select All Jobs in the Job Selection Criteria area, and select this checkbox. Events After Date/Time
after_time
Entering a date and time in the Events After Date/Time field specifies that only the events occurring after that date and time for the specified job(s), are in the report. To use this option, you must first deselect the Current Run Only checkbox. This entry must be in the date time format set locally, which is displayed under the field. The setting is typically the mm/dd/[yy]yy hh:mm format.
s 13-18
Monitoring and Reporting on Jobs s Running a Monitor or Generating a Report
Note If your local setting uses a two digit year, you must enter the year in that format. AutoSys however saves the setting to the database using a four digit year. If you enter 79 or less, AutoSys prepends 20, and, if you enter 80 or greater, AutoSys prepends 19.
Running a Monitor or Generating a Report

To run a monitor or report
In the Monitor/Browser Editor, open a monitor or report and choose File Run Monitor/Browser, and the current monitor or report will run.
Or
13
From an AutoSys Instance Command Prompt, execute the following AutoSys command:
monbro -N monbro_name
where:
monbro_name
Is the defined monitor or report name. To close a monitor or report

Press <Control+c>.
13-19 s

Defining Monitors and Reports using JIL
13
In addition to using the Monitor/Browser Editor, you can use the Job Information Language (JIL) to define monitors and reports. To define a monitor or report with JIL, you use the same syntax as you do to define a job, however you use different sub-commands. For defining monitors or reports, use these JIL sub-commands:
s insert_monbro s update_monbro s delete_monbro
To define a monitor or report using JIL interactively

1 Open an AutoSys Instance Command Prompt window. 2 At the AutoSys Instance Command Prompt, issue the following
command:
jil
This command will return the following prompt:

jil>> 3 At the jil prompt, enter the insert_monbro: name_value JIL sub-command followed by a set of attribute: value pairs.
To define a monitor or report using JIL by redirecting a file containing jil definitions
At the AutoSys Instance Command Prompt, submit the JIL script file, like this:
jil < jil_script
where: jil_script is the name of the file containing the jil monitor and report definitions.
s 13-20
Monitoring and Reporting on Jobs s Defining Monitors and Reports using JIL
The examples in the following sections include the JIL versions of the monitor and report examples in Defining Monitors and Reports with the Editor on page 13-9.
Note For a complete listing and description of the JIL commands and sub-commands that you can use to define monitors and reports, see Chapter 4, JIL/GUI Monitor/Report Definitions, in the AutoSys Reference Guide for Windows NT.
Defining Monitors using JIL
13
The first example in this section defines a monitor with the name Regular. This monitor will track all alarms, plus job status events when a job changes state to running, success, failure, and terminated:
/* Monitor for all ALARMS, and * Job EVENTS: RUNNING,SUCCESS,FAILURE & TERMINATED */ insert_monbro: Regular mode: m alarm: y running: y success: y failure: y terminated: y
13-21 s

The following JIL statements define a monitor that catches alarms, generates a sound, and repeats the sound until someone responds:
/* Monitor for JUST ALARMS! * Verification Required is ON so someone must * type in a response. * Sound is ON! */ insert_monbro: Alarm mode: m sound: y alarm: y alarm_verif: y Note The file named %AUTOSYS%\install\data\monbro.jil contains example JIL statements. For more information on enabling sound, see the AutoSys Sounds section of Chapter 15, AutoSys Administrator.
Defining Reports using JIL

This example defines a report with the name Alarm_Rep. This report will report all alarms on any job from April 1, 1997, at 2:00 a.m. to the present.
insert_monbro: Alarm_Rep mode: b alarm: y after_time: "05/22/1997 2:00"
13
In this example, quotes are required because the time contains a special character, the colon.
Note Reports can display only events that are still in the database.
Archived events are inaccessible and cannot be displayed.
s 13-22
14
Maintaining AutoSys
This chapter describes the procedures for maintaining AutoSys and the AutoSys database.
Maintaining the Event Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-3 Starting the Event Processor Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-3 Monitoring the Event Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-5 Starting the Event Processor in Global Auto Hold Mode . . . . . . . . . . . . . . . . 14-7 Stopping the Event Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-9 Shadow Event Processor Rollover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-10 Maintaining the Remote Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-13 Starting the Remote Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-13 Stopping a Remote Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-14 Running AutoSys in Test Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-14 AutoSys Maintenance Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-16 Backing up AutoSys Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-18 Restoring AutoSys Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-20
14-1 s
s Maintaining AutoSys
AutoSys Database Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-21 Event Server Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-21 Database Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-23 General Database Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-24 Daily Database Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-25 DBMaint.bat Batch File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-25 Event Server Rollover Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-27 Returning to Dual Server Mode After a Rollover . . . . . . . . . . . . . . . . . . . . . .14-27 Improving Database Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-34 Improving Sybase Database Performance . . . . . . . . . . . . . . . . . . . . . . . . . . .14-35 Improving Oracle Database Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-35 Maintaining Bundled Sybase SQL Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-37 Sybase Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-37 Sybase Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-38 Default Sybase Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-38 Starting Sybase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-40 Stopping Sybase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-41 Accessing Sybase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-42 Identifying Processes Connected to the Database . . . . . . . . . . . . . . . . . . . . .14-42 Displaying the Database Date and Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-43 Bundled Sybase Backup and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-44
s 14-2
Maintaining AutoSys s Maintaining the Event Processor
Maintaining the Event Processor

The Event Processor is the engine of AutoSys. When the Event Processor is not running, you cannot initiate new actions. You can stop the Event Processor, however, and the actions that have already started will run to completion.
14
Starting the Event Processor Service
14
The AutoSys database that is designated as the Event Server must be available, running, and properly identified before you can start the Event Processor. To start the Event Processor service
1 Open the AutoSys Administrator from the AutoSys program group. 2 On the Instance screen, specify the Computer and AutoSys Instance
you are modifying and click OK. The Computer should be the machine on which the Event Processor is installed.
3 Do one of the following to display the Services screen: Choose AutoSys Event Processor. Or Click the Services button on the toolbar (it is the traffic light icon). 4 On the Services screen, select the AutoSys Event Processor from the
Service drop-down menu.

5 Click the Start Service button.
If you set up a Shadow Event Processor, it starts automatically when you start the Primary Event Processor.
WARNING Do not log onto the Shadow Event Processor machine and start the Shadow Event Processor manually. Doing this will cause the Shadow Event Processor to act as the Primary Event Processor, which will cause a failure.
14-3 s
Note Most AutoSys services, including the AutoSys Remote Agent and the Event Server (database service), start automatically at boot time. We recommend that you start the Event Processor manually after booting your system. If you lose several systems at once due to power failure, this approach allows the Remote Agents to start on their respective machines before you start the Event Processor.
Event Processor Starting Processes

After you start the Event Processor, but before it begins processing, it performs the following tasks:
s
Verifies that no other Event Processor is running on that machine.

Note If you want it to also check that no other Event Processors are running on other machines, add the machine names to the Network Machine List field in the AutoSys Administrator Event Processor screen.
Invokes the chase -A -E command. The chase utility determines from the AutoSys database which jobs are in the STARTING or RUNNING state, and on which machine. For each client machine, chase passes the Remote Agent a list of jobs that are supposed to be running there and instructs the Remote Agent to verify that the processes actually are running. chase also verifies that the Remote Agent is running. If chase locates anomalies, it sends an alarm. If a job is not running as expected, the Event Processor sends the necessary corrective event for the job, if the job definition allows this. If the event being processed is a STARTJOB event, and the job it started is still alive, the Event Processor will not start it again. The purpose of running the chase utility is to guarantee that the Event Processor starts with all AutoSys processes in a known state. Problems are detected upon Event Processor startup. This method is similar to database checkpointing and rolling forward or backward upon recovery.
s 14-4
Note You can turn off this Event Processor startup behavior by deselecting the Chase On Startup check box located on the AutoSys Administrator Event Processor screen. For information on using the AutoSys Administrator, see AutoSys Administrator Event Processor Screen in Chapter 15, AutoSys Administrator.
Monitoring the Event Processor

The output of the Event Processor (event_demon.exe executable) is written to the following log file:
%AUTOUSER%\out\event_demon.%AUTOSERV%
14
This log file contains a record of all the actions taken by the Event Processor, including startup and shutdown information. To view the log file
Execute the AutoSys autosyslog utility like this:
autosyslog -e
When you execute this command, the last ten lines of the log file are displayed, and then all additions to the log are automatically displayed as they occur. To terminate the autosyslog process
Press <Control+c>.
Note We recommend that you use the autosyslog -e command to
follow the behavior of the Event Processor. It displays the log file, which generates information on all Event Processor activity.
14-5 s
Location of the Event Processor Log File

When the Event Processor has problems starting, the error log is written to different place, which is dependent upon when the starting process fails. You can locate the error description in one of the following locations:
s
If the Event Processor fails early in startup, the error is written to the Windows NT Event Log. If the Event Processor fails during the startup procedure, the error is written to the designated Enterprise Wide Directory, in the event_demon.%AUTOSERV%.out file. If the Event Processor has problems while running, the error is written to the %AUTOUSER%\out\event_demon.%AUTOSERV% file.
Event Processor Log File Size

The Maximum Log Size setting on the Administrator Event Processor screen specifies the maximum size of the Event Processor log file. The Event Processor reads this setting on startup and checks the file size. If the file is the indicated maximum size, the Event Processor deletes it. 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 FileSystem Threshold setting in the Administrator Event Processor screen, the Event Processor issues warnings in the Event Processor log file. For information on the FileSystem Threshold setting, see the AutoSys Administrator Event Processor Screen section in Chapter 15, AutoSys Administrator.
s 14-6
Starting the Event Processor in Global Auto Hold Mode

If you restart an Event Processor after a period of downtime, you might want to start it in Global Auto Hold mode. In Global AutoHold mode, the Event Processor starts without simultaneously starting all the jobs whose starting conditions are met. Starting the Event Processor in Global Auto Hold mode prevents the system from being flooded with jobs that were scheduled to run during the downtime. When you select Global Auto Hold, the Event Processor evaluates all jobs whose starting conditions have passed and are eligible to run, but instead of starting the jobs, the Event Processor puts them ON_HOLD. It does this for all types of jobs (Box, Command, and File Watcher Jobs).
14
This approach allows you to decide which jobs should run by selectively starting them with the Force Start Job event. The only way to start a job when Global Auto Hold is on is to send the FORCE_STARTJOB event. To start the Event Processor in Global Auto Hold mode
3 Do one of the following to display the Event Processor screen: Choose AutoSys Event Processor. Or Click the Event Processor button on the toolbar. 4 Click the Global Auto Hold checkbox to select it, and click OK.
14-7 s
5 Do one of the following to display the Services screen: Choose AutoSys Services. Or Click the Services button on the toolbar. 6 On the Services screen, select the AutoSys Event Processor from the

To send a Force Start Job event

Use the Scheduler Console.
Or
Use the Send Event Tool.

Or
Execute the following command:

sendevent -E FORCE_STARTJOB -J job_name
To turn off Global Auto Hold mode

1 Shut down the Event Processor, using the following command:
4 Do one of the following to display the Event Processor screen: Choose AutoSys Event Processor. Or Click the Event Processor button on the toolbar.
s 14-8
5 Click the Global Auto Hold checkbox to deselect it, and click OK. 6 Do one of the following to display the Services screen: Choose AutoSys Services. Or Click the Services button on the toolbar. 7 On the Services screen, select the AutoSys Event Processor from the

8 Click the Start Service button. Note If you have AutoSys configured with a Shadow Event Processor, and you start the Event Processor in Global Auto Hold mode, the Shadow Event Processor will also be in Global Auto Hold mode.
Stopping the Event Processor

It is safe to stop the Event Processor at any time, if it is stopped properly. Only the Exec Superuser can stop the Event Processor.
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.
14
14-9 s
To stop the Event Processor properly

1 Log onto any AutoSys configured machine as the AutoSys Exec
Superuser.
2 Issue the following command at an AutoSys Instance Command
Prompt:
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. When you issue the sendevent command, the STOP_DEMON event is sent to the AutoSys database. The Event Processor then reads the STOP_DEMON event, goes into an orderly shutdown cycle, and exits. There might be a delay between when you send the STOP_DEMON event and when the Event Processor reads it and shuts down. If the Event Processor does not shut down immediately, do not send another STOP_DEMON event, because the event Processor will process that event the next time it starts, and it will promptly shut down. For more information about the sendevent command, see sendevent in Chapter 1, AutoSys Commands, of the AutoSys Reference Guide for Windows NT.
WARNING Do not attempt to stop the Event Processor by using a utility such as pview or by using the NT Control Panel Services dialog. These methods stop the Event Processor no matter what it is doing; it might be in the middle of processing an event. Also, if you are using Dual Event Servers and use these methods, the databases can lose synchronization.
Shadow Event Processor Rollover
14
You can configure a Shadow Event Processor to act as a backup Event Processor. The Shadow Event Processor is normally idle; it listens for the periodic signals (every 90 seconds) from the Primary Event Processor that indicate the Primary processor is still functioning.
s 14-10
If the Shadow Event Processor does not receive the signal, it does the following:
1 Checks the Third Machine for the .dibs file. 2 Does one of the following: If it cannot connect to the Third Machine, the Shadow Event
Processor shuts down.

Or If it can connect but cannot locate the .dibs file, the Shadow Event
Processor creates the file, attempts to signal the Primary Event Processor to stop, and takes over processing the events.
Or If it can connect and the .dibs file already exists, the Shadow Event
Processor shuts down. 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.
14-11 s
Note You can specify the Shadow Event Processor and the Third Machine using the AutoSys Administrator Event Processor screen (accessed from the AutoSys program group). For information, see Chapter 15, AutoSys Administrator.
Restoring the Primary Event Processor

To restore the Event Processor service following a rollover
1 Stop the Shadow Event Processor by logging on as the AutoSys Exec
Superuser, and issuing the following command:

sendevent -E STOP_DEMON 2 On the Primary Event Processor machine, open the AutoSys
Administrator from the AutoSys program group.

3 Specify the Computer and the AutoSys Instance you are modifying,
and click OK.

4 Go to the Services screen by clicking the Services button on the toolbar
(the traffic light icon).

5 On the Services screen, select the AutoSys Event Processor from the

The Shadow Event Processor starts automatically when you start the Primary Event Processor.
Note If you attempt to start the Primary and Shadow Event Processors without having a Third Machine specified in the AutoSys Administrator, the Shadow Event Processor will not start.
s 14-12
Maintaining AutoSys s Maintaining the Remote Agent
Maintaining the Remote Agent
14
A Remote Agent is an NT service that runs on a remote machine. The Event Processor directs the Remote Agent to perform specific tasks. The Remote Agent starts the command specified for a given job, sends running and completion information about a task as an event to the database, and then exits. If the Remote Agent is unable to transfer the information, it waits and tries again. It will continue to try to connect to the database until it can successfully transfer the information.
Starting the Remote Agent

The Remote Agent service should start automatically when the machine is started (this is set in the NT Control Panel Services dialog), so under normal circumstances you should not need to start the Remote Agent manually. If for some reason the Remote Agent service is stopped, any user with NT Administrators group privileges can restart it. To restart the Remote Agent
1 Open the AutoSys Administrator from the AutoSys program group.
14
2 On the Instance screen, specify the Computer and AutoSys Instance of
the Remote Agent you want to start, and click OK.

3 Go to the Services screen by doing one of the following: Click the Services (traffic light) toolbar button. Or Choose AutoSys Services.
14-13 s
Running AutoSys in Test Mode
4 On the Services screen, select the AutoSys Remote Agent service from
the Service drop-down list. The red, yellow, or green light of the traffic light icon and the field under it indicate the status of the Remote Agent. In addition, if the Remote Agent is not running, the Start Service button is enabled (if it is running, the Stop Services button is enabled and the Start Services button is disabled).
5 Click the Start Service button. Note If the Remote Agent does not start, see the Remote Agent
Troubleshooting section in Chapter 16, Troubleshooting. For information on using the AutoSys Administrator, see Chapter 15, AutoSys Administrator, or see the AutoSys Help on-line.
Stopping a Remote Agent

You should not stop the Remote Agent service. If it is inadvertently stopped, see the previous section for directions on how to restart it.
14
Running AutoSys in Test Mode
14
If you want to check your AutoSys configuration, you can run AutoSys in test mode. This process is helpful for troubleshooting problems. Running the Event Processor in test mode allows you to test the set up as well as the execution of logic by the jil command, without having to run the defined jobs. A simple job is run in place of the defined job. When running in test mode, you can determine the following:
s
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.
s 14-14
Maintaining AutoSys s Running AutoSys in Test Mode
If the conditional logic for jobs, including nested boxes, is functioning correctly.
You can run the Event Processor at two levels of test mode. You do this by setting the %AUTOTESTMODE% system variable before starting the Event Processor. You can set this system variable from the Control Panel System Properties dialog. You must restart your machine for this setting to take effect. 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:
s %AUTOTESTMODE% = 1 s %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:
s
The ntgetdate command is executed on the remote machine instead of the command specified in the job definition. 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.
The following functions are disabled:

s
Minimum and Maximum Run Alarms
14-15 s
AutoSys Maintenance Commands
s s
Sourcing a user-specified job profile All resource checks
%AUTOTESTMODE% = 2
The second level of test mode runs with the same behaviors as the first level with the addition of the following procedures:
s s s
Resource checks are performed. A user defined job profile is sourced. Output from the ntgetdate command goes to the user defined standard output and standard error files, if they are defined; otherwise, output goes to the file named
\tmp\autotest.%AUTO_JOB_NAME%
AutoSys Maintenance Commands

The maintenance commands described below are located in the %AUTOSYS%\bin directory. You can execute these commands from the AutoSys Instance Command Prompt window or as an AutoSys job.
14
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:
s s
The Remote Agent is running. The job is running.
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
s 14-16
Maintaining AutoSys s AutoSys Maintenance Commands
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 Windows NT.
Note There is no way for chase to tell if a machine is down;
therefore, it cannot tell if jobs on that machine are running, or if the network connection to the machine is down. If you run chase with the -E option, jobs that have already run, or are running on the machine with the failed network connection might be restarted if the network connection is re-established.
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 machines Remote Agent Log directory (specified during the installation process or in the Local Agent Logging Directory field of the AutoSys Administrator Remote Agent screen). 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. For more information about the clean_files command, see Chapter 1, AutoSys Commands, in the AutoSys Reference Guide for Windows NT.
14-17 s
Backing up AutoSys Definitions
Backing up AutoSys Definitions

We recommend that you back up the following AutoSys definitions periodically to ensure that you have files to restore from in case of a system failure:
s s s s s
14
calendar definitions job definitions machine definitions monitor and browser definitions global variables
For information about restoring the backed up definitions, see Restoring AutoSys Definitions on page 14-20. We also recommend that you keep a copy of your AutoSys license keys in case you need to reinstall them. To back up AutoSys definitions
1 To save your calendar definitions: a Open a Calendar Editor window. b Choose File Export All.
The Save As dialog is displayed.

c In the Save As dialog, select a directory that is outside of the
AutoSys directory structure and select or enter a file name.

d Click Save. Note The calendar definitions are saved as text.
s 14-18
Maintaining AutoSys s Backing up AutoSys Definitions
2 To save your job definitions, from an AutoSys Instance Command
Prompt window, execute the following command:

autorep -J ALL -q > c:\directory\autosys.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 calendar definitions. This command saves your job definitions to a file named autosys.jil.
3 To append your machine definitions to the same file that contains
your job definitions, from the AutoSys Instance Command Prompt window, execute the following command:
autorep -M ALL -q >> c:\directory\autosys.jil
Where directory is the same directory where you saved your job definitions, a directory outside of the AutoSys directory structure.
Note To append definitions to an existing file, you enter >> instead of >. We recommend that you append your job, machine, and monitor and browser definitions to the same file. Then you have only one file to restore following a system failure. 4 To append your monitor and browser definitions to the same file that
contains your job and machine definitions, from the AutoSys Instance Command Prompt window, execute the following command:
monbro -N ALL -q >> c:\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 AutoSys
Instance Command Prompt window, execute the following command:

autorep -G ALL > c:\directory\globals.jil
14-19 s
Restoring AutoSys Definitions
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. This command saves your global variables to a file named globals.jil. This file is simply a record of what you must redefine following a system failure.
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.
Restoring AutoSys Definitions

The procedure in this section assumes that you backed up your AutoSys definitions by following the procedure in Backing up AutoSys Definitions on page 14-18. To restore AutoSys definitions
1 To restore your calendar definitions: a Open a Calendar Editor window. b Choose File Import.
14
The Open dialog is displayed.

c In the Open dialog, select the directory and filename of the text file
that contains your calendar definitions.

d Click Open.
s 14-20
Maintaining AutoSys s AutoSys Database Overview
2 To restore your job, machine, and monitor and browser definitions,
from an AutoSys Instance Command Prompt window, execute the following command:
jil < c:\directory\autosys.jil
Where directory is the directory where you saved your definitions.

3 To restore your global variables, reference your backup file and
redefine any global variables and reset the necessary AutoSys Administrator settings.
AutoSys Database Overview
14
All AutoSys information is stored in a relational database known as the Event Server or AutoSys database. For this database, you can use a Sybase, an Oracle, or a Microsoft SQL Server database. An Event Server contains all of the information about a particular instance of AutoSys. The Event Processor reads from the Event Server to determine what actions to take. The Remote Agents send starting, running, and completion information about jobs to the Event Server. 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.
Note While AutoSys uses the database solely as an SQL engine, it does use Sybase Open Client C Library communications protocol, Oracle SQL*Net V2, and Microsoft SQL Server Multi-Protocol Net-Library to send events around the system.
Event Server Overview

An Event Server can be associated with only one instance of AutoSys and one running Event Processor.
14
14-21 s
AutoSys Database Overview
An Event Server contains the following objects:

s s s s s
Job definitions Events Monitor and report (browser) definitions 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 Windows NT.
Using Dual Event Server Mode

When you configure AutoSys with Dual Event Servers, all of the data is duplicated on two Event Servers. In Dual Server mode both servers are peers, and the Event Processor is responsible for keeping the databases synchronized. The Event Processor continually reads from both databases as it processes events. For information about installing a second Event Server, see the Installing Dual Event Servers section of Chapter 6, Advanced Configurations, in the AutoSys Installation and Getting Guide for Windows NT.
Database Storage Requirements

The standard sizes for AutoSys databases are 64MB (Sybase and Microsoft SQL Server) and 100MB (Oracle). The standard sizes for AutoSys databases are the recommended sizes. If your job load is large, you should create a larger database. The size requirements for your database depend on the following:
s s
The number of jobs you define. How many of the jobs have dependencies.
s 14-22
Maintaining AutoSys s AutoSys Database Overview
s s
How often the jobs are run. 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.)
Database Architecture
14
Figure 14-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.
One Instance of AutoSys - %AUTOSERV%
Define Jobs Read Registry to determine which database(s) to use.
Event Server 1
OS FILE AutoSys Administrator settings Event Server 2 Event Processor Instructs Remote Machine: Command to execute and database(s) to send events to. Remote Agent
Database(s)
Processes
Figure 14-1 Layout of databases and primary component interaction
14-23 s
General Database Maintenance
Figure 14-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). The controlling variable in the architecture is the environment variable named AUTOSERV, which is the instance name. You define the configuration for an instance at installation and by using the AutoSys Administrator. In the AutoSys Administrator, you can specify which database(s) to use. This information is stored in the NT Registry. All AutoSys commands access it. This variable along with other AutoSys-specific variables are set in the AutoSys Instance Command Prompt window, and thus, you must execute AutoSys commands in these windows. For information on configuring AutoSys instances, see Chapter 15, AutoSys Administrator.
14
You can configure AutoSys to maintain itself as it runs. In fact, there are defaults in place that provide frequent, automatic maintenance. You can customize the settings by using the AutoSys Administrator. In addition to this regularly scheduled maintenance, you can issue general and AutoSys database maintenance commands from the AutoSys Instance Command Prompt. Periodic maintenance is essential to keeping AutoSys working correctly. Several AutoSys events are generated for each run of each job. If these events are not pruned from the database periodically, the database will eventually fill up, bringing AutoSys and its jobs to a halt. Therefore, we recommend that you use the suggested periodic maintenance practices described in this section.
s 14-24
Maintaining AutoSys s General Database Maintenance
Daily Database Maintenance
14
Once a day, the Event Processor performs internal database maintenance. During this time, it does not process any events; it waits for the maintenance activities to complete before resuming normal operations. By default, this maintenance cycle starts at 3:30 a.m. If it is necessary to change the start time, reset it to a time of minimal activity. You can specify the Database Maintenance Command and Database Maintenance Time in their fields on the AutoSys Administrator Event Processor screen. Use a 24-hour format for the time entry. For information on setting the database maintenance time and using the AutoSys Administrator, see AutoSys Administrator Event Server Screen in Chapter 15, AutoSys Administrator.
DBMaint.bat Batch File
14
By default, AutoSys executes the %AUTOSYS%\bin\DBMaint.bat batch file during its daily maintenance cycle. This batch file runs the dbstatistics and archive_events commands.
DBMaint runs the dbstatistics command to perform the following tasks:
s
Update statistics in the database for optimal performance. For Sybase and Microsoft SQL Server databases, it updates statistics for the event, job, job_status, and job_cond tables. For Oracle, it computes statistics for all of the AutoSys tables. 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.
Note If you use an Oracle database, running DBMaint may report
that your database is close to full when this is not the case. This can occur because DBMaint calculates how much space is not allocated for extents. The extents may be nearly empty, but DBMaint reports the whole extent as used space.
14-25 s
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.
DBMaint runs the archive_events command to remove old information from the various AutoSys database tables. Specifically, archive_events removes the following:
s s
Events and any alarms associated with them from the event table Job run information from the job_runs table. information from the audit_info and audit_msg tables
s autotrack log
The output from DBMaint, %AUTOUSER%\out\DBMaint.out, tells you how much space is left in your database, so that you can check (and monitor) if the event tables are filling up. This is a good way to calculate how many events in a single day can be maintained safely in the database before they should be archived. For more information on the dbstatistics and archive_events commands, see their entries in Chapter 1, AutoSys Commands, of the AutoSys Reference Guide for Windows NT. For a list of the database tables and views, as well as the event and alarm codes used in the tables, see Chapter 6, Database Tables and Codes, in the AutoSys Reference Guide for Windows NT.
Modifying the DBMaint.bat File

You can modify the %AUTOSYS%\bin\DBMaint.bat batch file. For example, you might want to modify the batch file to perform database backups also. For information on backing up bundled Sybase, see Bundled Sybase Backup and Recovery on page 14-44. 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 batch file to modify the newly installed file.
s 14-26
Maintaining AutoSys s Event Server Rollover Recovery
The batch file name is specified in the Database Maintenance Command field on the AutoSys Administrator Event Processor screen.
Event Server Rollover Recovery
14
When AutoSys runs in Dual Server mode, and the Event Processor detects an unrecoverable error condition on one of the Event Servers, it automatically rolls over to Single Server mode. An unrecoverable error is defined as one of the following:
s
The connection to the database is lost, and after the configured number of reconnect attempts, the database remains unconnected. A database had an unrecoverable error (e.g., corrupt database or media failure).
If one Event Server is lost, AutoSys automatically rolls over to the functioning server and continues to run in Single Server mode. If there was a rollover and a switch to Single Server mode, the Administrator Event Server screen indicates this in two ways: the Status field shows which Event Server is DOWN, and the Database Rollover Has Occurred check box is checked. AutoSys makes these changes so that you and the AutoSys utilities trying to access the database will know that it is now running in Single Server mode, and so that AutoSys client processes will not try to write to the down Event Server.
Returning to Dual Server Mode After a Rollover

When an Event Server is down, do not, under any circumstances, simply bring that Event Server back on-line and run in Dual Server mode. After you recover the crashed server, you can reconfigure AutoSys to run with Dual Event Servers. Before you can start AutoSys with both Event Servers however, you must make sure that they are synchronized.
14
14-27 s
To restore a down Event Server and Dual Server Mode

1 Stop the Event Processor by entering the following command in an
AutoSys Instance Command Prompt window (which you open from the AutoSys program group):
sendevent -E STOP_DEMON 2 Synchronize the Event Servers by using the autobcp.NT Perl script as
described in Synchronizing the Databases on page 14-29.

Note AutoSys provides the autobcp.NT Perl script to synchronize
the databases. You will use this script both when you install a second Event Server after running AutoSys in single mode and when you want to re-enable Dual Server mode after rolling over to Single Server mode.
3 Enable the second database: a Open the AutoSys Administrator from the AutoSys program group. b Specify the appropriate Computer and AutoSys Instance, and click
OK.
c Choose AutoSys Event Server to go to the Event Server screen. d Click Enable to start the disabled server. 4 Start the Event Processor: a In the open AutoSys Administrator, choose AutoSys Services. b Select the Event Processor service from the drop-down list. c Click Start Services.
s 14-28
Note The Event Processor marks both Event Servers as being in Dual Server mode. AutoSys client processes and commands check the flags in both Event Servers for consistency, therefore, you must start the Event Processor before running any other AutoSys commands. 5 Exit the AutoSys Administrator.
Synchronizing the Databases

The autobcp.NT Perl script identifies one database as the source and the other database as the destination for the synchronization process. It deletes all of the data in the destination database and replaces it with the data in the source database. Therefore, if you want to save the data in the destination database, archive it before you run this Perl script. Before you run the autobcp.NT script, check the following:
s
Ensure that you have enough disk space for the temporary file created by autobcp.NT. The temporary file will be the size of your database, and the standard sizes for AutoSys databases are 64MB (Sybase and Microsoft SQL Server) and 100MB (Oracle). If you have made your database larger, you will need more disk space for the temporary file. The script deletes this temporary file after the synchronization is complete. Ensure that the AUTOSYS variable and either the SYBASE or ORACLE_HOME variables are set correctly. (For Oracle, you are asked to supply the path to the Oracle software before the script runs.) Ensure that both Event Servers are running. Ensure that no AutoSys clients (e.g., Event Processor, AutoSys GUI) are running.
s s
14-29 s
Note When you stop the Event Processor, the jobs that are running will run to completion. You can run the autobcp.NT script while jobs are running on remote machines. In the worst case scenario, there might be events on the source Event Server that are not stored on the destination Event Server. This is not a problem, however, because the Event Processor always reads from both Event Servers. If it finds an event on one server that is not on the other, it copies that event to the database that is missing it. If one Event Server missed an event due to recovery or network problems, this feature also dynamically synchronizes both servers.
To synchronize the databases

1 In an AutoSys Instance Command Prompt window, type the
following:
cd %AUTOSYS%\DBOBJ 2 Then, enter the following command: For Sybase databases: perl autobcp.NT source_server source_db destination_server destination_db autosys_password dump_file For Oracle databases: perl autobcp.NT source_instance destination_instance autosys_password dump_file oracle_path For Microsoft SQL Server databases: perl autobcp.NT source_server source_db destination_server destination_db autosys_password dump_file MSSQL_path
s 14-30
where:
source_server
Specifies the name of the source Sybase or Microsoft SQL Server (e.g., AUTOSYSDB). For Sybase this is defined in the SQL.INI file. For Microsoft SQL Server, see the Microsoft SQL Enterprise Manager.
source_db
Specifies the source Sybase or Microsoft SQL Server database (e.g., autosys).
destination_server
Specifies the destination Sybase or Microsoft SQL Server database (e.g., AUTOSYSDB2). For Sybase this is defined in the SQL.INI file.
destination_db
Specifies the destination Sybase or Microsoft SQL Server database (e.g., autosys).
source_instance
Specifies the source Oracle instance (e.g., AUTOSYSDB).

destination_instance
Specifies the destination Oracle instance (e.g., AUTOSYSDB2).

autosys_password
Specifies the password for the autosys user (by default, the autosys user password is autosys).
dump_file
Specifies the temporary file used in the transfer of data from one database to the other.
oracle_path
Specifies the path to the Oracle import and export executables set in ORACLE_HOME.
14-31 s
MSSQL_path
Specifies the local path to the Microsoft SQL Server directory. autobcp.NT must be able to locate the Microsoft binn\BCP.EXE program. If you enter the information correctly, the script runs. After the script starts, it checks for the existence of both databases before it begins moving the data. If the script completes successfully, you see descriptive messages on your screen. When it completes, continue with the steps described in Returning to Dual Server Mode After a Rollover on page 14-27. If the script is not successful, see Handling Errors on page 14-34. If you enter any information incorrectly, the script prompts you with questions and requests confirmation, as described in the following database-specific sections. Synchronizing Sybase Databases If you are synchronizing two Sybase databases, you are prompted to answer the following questions, and then the script runs:
AUTOBCP.NT: Source server [SourceServer]? >source_server AUTOBCP.NT: Source database [autosys]? > autosys AUTOBCP.NT: Destination server [DestinationServer]? > destination_server AUTOBCP.NT: Destination database [autosys]? autosys AUTOBCP.NT: Autosys password [password]? > autosys_password AUTOBCP.NT: Dump file name [dump.fil]? > dump.file AUTOBCP.NT: Moving data from source_server:autosys to destination_server:autosys AUTOBCP.NT: Are you sure? ([y]|n)> y ... autobcp: complete
If the script runs successfully, you see messages on your screen. When it completes, continue with the steps described in Returning to Dual Server Mode After a Rollover on page 14-27. If the script is not successful, see Handling Errors on page 14-34.
s 14-32
Synchronizing Oracle Databases If you are synchronizing two Oracle databases, you are prompted to answer the following questions, and then the script runs:
autobcp: Source instance [SourceInst]? > source_path autobcp: Destination instance [DestinationInst]? > destination_path autobcp: Autosys password [password]? > autosys_password autobcp: Dump file name [dump.fil]? > dump.file autobcp: Path for Oracle (ie. ORACLE_HOME) [c:\orant]? > c:\path autobcp: Moving data from source_path to destination_path autobcp: Are you sure? ([y]|n)> y ... autobcp: complete
If the script runs successfully, you see messages on your screen. When it completes, continue with the steps described in Returning to Dual Server Mode After a Rollover on page 14-27. If the script is not successful, see Handling Errors on page 14-34. Synchronizing Microsoft SQL Server Databases If you are synchronizing two Microsoft SQL Server databases, you are prompted to answer the following questions, and then the script runs:
AUTOBCP.NT: Source server [SourceServer]? >source_server AUTOBCP.NT: Source database [autosys]? > autosys AUTOBCP.NT: Destination server [DestinationServer]? > destination_server AUTOBCP.NT: Destination database [autosys]? > autosys AUTOBCP.NT: Autosys password [password]? > autosys_password AUTOBCP.NT: Dump file name [dump.fil]? > dump.file AUTOBCP.NT: Path for MicroSoft SQL [c:\mssql]? > c:\path AUTOBCP.NT: Moving data from source_server:autosys to destination_server:autosys AUTOBCP.NT: Are you sure? ([y]|n)> y ... autobcp: complete
14-33 s
Improving Database Performance
If the script runs successfully, you see descriptive messages on your screen. When it completes, continue with the steps described in Returning to Dual Server Mode After a Rollover on page 14-27. If the script is not successful, see the following section, Handling Errors on page 14-34. Handling Errors If the autobcp.NT process detects an error, it exits and displays an error message. If this happens, check the following:
s
Did you correctly specify the source and the destination databases in the Perl script command? Do you have the correct Event Server ports set for the databases? For Sybase, this setting is in the SQL.INI file, and for Oracle it is in the TNSNAMES.ORA file. For Microsoft SQL Server, the port is specified at installation time with the Microsoft SQL Server Setup program. Are both Event Servers started? To verify this, look at the NT Control Panel Services dialog. For bundled Sybase, verify that the status of SYBSQL_LOCAL is started. If you run unbundled Sybase, the service has a different name. If you run an Oracle database, verify the status of the following services (substitute your Oracle SID for the asterisk): OracleService*, OracleStart*, and OracleTNSListener. For a Microsoft SQL Server, the service name is MSSQLServer.

This section contains information about improving your database performance with AutoSys.
14
s 14-34
Maintaining AutoSys s Improving Database Performance
Improving Sybase Database Performance

These are ways to improve your Sybase database performance:
s
14
Increase the amount of memory that Sybase can use.

WARNING Only the database administrator should increase Sybase memory.
s s
Upgrade your processor, memory, and/or hard disks. Install the Sybase server and the Event Processor on a dedicated machine or machines. Do not share machine resources with other processes. Use the Sybase server for AutoSys only. 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.
s s
Improving Oracle Database Performance

Tuning Oracle to improve its performance with AutoSys is complicated. The following are some suggestions for the database administrator:
s
14
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;
14-35 s
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.
s
Tune the buffer cache. Make changes to the buffer cache by altering the init.ora value of DB_BLOCK_BUFFERS. To determine if you need to allocate more memory, enter the following query as the sys user in SQL*Plus:
select name, value from v$sysstat where name in (db block gets, consistent gets, physical reads);
Monitor the statistics from the query while AutoSys is running. Calculate the hit ratio for the buffer cache by using this formula: hit ratio = 1 - (physical reads/(db block gets + consistent gets)) 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.
s
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. To determine if sorting is affecting the performance of your system, monitor the sorting disk activity in your system by entering the following query in SQL*Plus:
select name, value from v$sysstat where name in (sorts (memory), sorts (disk));
s 14-36
Maintaining AutoSys s Maintaining Bundled Sybase SQL Servers
If disk sorts are greater than 1% of memory sorts, then increase the value of SORT_AREA_SIZE.
Maintaining Bundled Sybase SQL Servers

Because you can purchase AutoSys with a bundled Sybase database, this section is specific to Sybase Event Server maintenance. It contains information to help you query the database as well as to perform basic maintenance procedures on Sybase SQL Server databases.
14
Note The following sections are specifically for bundled Sybase users. If you are using an existing Sybase, Oracle, or Microsoft SQL Server database with AutoSys, consult your database administrator for details on starting, stopping, and configuring your database.
Sybase Architecture
14
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 multithreaded, 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.
14-37 s
Note The DB Library allows a client to maintain multiple connections to the same server or multiple servers. It is through this mechanism that the Dual Event Servers are maintained.
Sybase Environment
If you are using a Sybase, the following environment variables are used:
DSQUERY SYBASE
14
Defines the name of the Sybase dataserver. Specifies the complete path to the Sybase software directory.
The Sybase software directory contains the Sybase configuration file, which on UNIX is the interfaces file and on Windows NT is the SQL.INI file. AutoSys uses the Sybase configuration file to look up database information. It is the means by which the network is navigated to find the Sybase dataserver.
Default Sybase Users
14
To perform many administrative tasks on your bundled Sybase database, you use the xql utility, which is an AutoSys-supplied utility that can access the Sybase dataserver from any properly configured client machine. In most cases, you must log onto Sybase as sa using the sysadmin password, or the appropriate password. You can log onto Sybase within a command line, or you can log onto Sybase as sa, then operate interactively at the xql prompt. You do most of the Sybase administration through system-stored procedures. All system-stored procedures start with the sp_ prefix. For more information on using xql, see its entry in Chapter 1, AutoSys Commands of the AutoSys Reference Guide for Windows NT.
s 14-38
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.
User System Administrator AutoSys User User Name Default Password
sa autosys
sysadmin autosys
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 Windows NT.
Changing the System Administrator Password

You can change the system administrator password from its initial value of sysadmin to a new value. To change the system administrator password
1 Execute the following xql command in an AutoSys Instance
Command Prompt window:

xql -Usa -Psysadmin
The following prompt appears:

xql>>[AUTOSYSDB][master] 1> Note If you are not using the default settings, the name of your dataserver is substituted for AUTOSYSDB.
14-39 s
2 Enter the following command sequence (replacing newPassword with
the new password):

xql>>[AUTOSYSDB][master] 1> sp_password xql>>[AUTOSYSDB][master] 2> sysadmin, newPassword;
The new password must be at least six characters.

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.
Starting Sybase
14
When you reboot the machine after installing AutoSys, the bundled Sybase database is started. It is a service that is started automatically with subsequent startups. To verify that the database is up and accessible, enter the following command at the AutoSys Instance Command Prompt (assuming autosys is the AutoSys user, and autosys is the user password):
xql -Uautosys -Pautosys -c "select getdate()"
If this command returns the date, the database is running. If the database is not running, you can start it from the NT Control Panel Services dialog on the machine where the database is installed. If you are using bundled Sybase, the name of the Service is SYBSQL_LOCAL. If you are using a pre-existing dataserver at your site, it has a different name, and your database administrator can start it.
s 14-40
Stopping Sybase
14
If you perform a Windows NT Shutdown, the Sybase service is shut down correctly as part of that process, and it is restarted automatically with the Restart process. If you need to stop the Sybase service, you must stop the Event Processor first. 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 at the AutoSys Instance Command Prompt:
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, or by checking its status on the AutoSys Administrator Services screen. 2 Stop the Sybase service by entering the following command (the sa_password is initially installed as sysadmin): xql -Usa -Psa_password -c "shutdown"
This command allows any database processes to complete, and then shuts the database down. If you must shut down the database immediately, use this command:
xql -Usa -Psa_password -c "shutdown with no_wait" Note In addition, you can stop the Sybase service from the NT Control Panel Services dialog. If you are using bundled Sybase, the name of the Service is SYBSQL_LOCAL. If you are using a pre-existing dataserver at your site, it has a different name, and your database administrator can stop it.
14-41 s
For information on changing the sa password, see Changing the System Administrator Password on page 14-39.
Accessing Sybase
AutoSys comes with a utility named xql, which resides in the %AUTOSYS%\bin directory. Use this utility for interactive database queries. For a detailed description of how to use xql, see its entry in Chapter 1, AutoSys Commands, of the AutoSys Reference Guide for Windows NT.
Note The xql utility functions only with the Sybase database. If you
14
use an Oracle database, use the SQL*Plus command language interface. If you use a Microsoft SQL Server, use the ISQL/w graphical query interface.
Identifying Processes Connected to the Database

These are reasons you might want to identify the processes that are connected to the database:
s
14
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;
s 14-42
The list of processes connected to the database is displayed, like this:

program_name hostname --------------- ---------xql Joe hostprocess ----------14050 status -----------running sleeping sleeping sleeping sleeping sleeping recv sleep recv sleep
event_demon jil
Michelle Erik
13448 12272
status 0, rows affected 8
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):
autocal autocons autosc auto_remote event_demon hostscape jil jobscape sendevent timescape xql
Displaying the Database Date and Time

AutoSys jobs are scheduled and run based on the date and time for the machine on which the database is running. If your jobs do not run when you expect them to, you can check the database clock.
14
14-43 s
To display the database date and time

At the xql prompt, enter the following:
xql>>[AUTOSYSDB][master] 1> select getdate();
Bundled Sybase Backup and Recovery
14
You must back up the AutoSys database periodically, so that you can recover it in the event of catastrophic system or media failure. You should decide on a routine for backing up the AutoSys database so that you will have no trouble recovering a lost database, using the backup database dump. This section describes how to dump the AutoSys database to a file, which you can then back up to tape along with the rest of your production system. Before dumping a database to a file, you must configure a backup server by using the Sybase Configure Sybase SQL Server dialog, and then you must identify a dump file to the AutoSys database by running the Sybase system sp_addumpdevice procedure. The sp_addumpdevice procedure requires a logical name for the dump file (the dump and load database commands use this name) as well as a physical name (the files full pathname).
Configuring a Backup Server

To configure a Sybase backup server
1 Enter the following command at an AutoSys Instance Command
Prompt:
syconfig
This command runs the Sybase Configure Sybase SQL Server dialog.
2 In the dialog, select Backup Server under Products, and click
Configure New Backup Server under Backup Server. This action opens the Backup Server Name dialog.
s 14-44
3 In the Backup Server Name dialog, enter the Name of the Backup
Server, which should be AUTOSYSDB_BS (if you are not using the default Event Server name, then use DATABASENAME_BS). Then, click Continue.
4 In the Configure Backup Server dialog, click Network Addresses. This
action opens the Network Connections dialog.

5 In the Network Connections dialog, click Add. This action opens the
Enter Connection dialog.

6 In the Enter Connection dialog, change the Protocol to NLWNSCK
WinSock TCP/IP Driver, which is located on the drop-down list, and enter any unused port number in the Connection Info field. Then, click OK.
Note The port number must be one not already in use at your site;
do not use your Event Server port number for this value.
7 In the Network Connection dialog, check the information that you
just entered, and if it is correct, click OK.

8 In the Configure Backup Server dialog, click Continue. At this time,
the process to create the backup server runs. When it completes, the New Backup Server Complete prompt appears, and you can click Continue.
9 In the Configure Sybase SQL Server dialog, click Exit. 10 To ensure that the backup server service was created and is running,
check the Control Panel Services dialog. The backup service that you named should be Started. That is, if you supplied the AUTOSYSDB_BS name as the Default Name of Backup Server, the Sybase BCKServer_AUTOSYSDB_BS service should appear as a Service with a Status of Started. After this process is done, you can back up the database to a file anytime.
14-45 s
Backing up the Database to a File

To backup, or dump, the database to a file
1 Execute the following xql command at the AutoSys Instance
Command Prompt (assuming that the sa password is sysadmin):

xql -Usa -Psysadmin 2 To define the dump device to Sybase, enter the following at the xql
prompt:
xql>>[AUTOSYSDB][master] 1> sp_addumpdevice 'disk', autodump, xql>>[AUTOSYSDB][master] 2> 'C:\tmp\autodump', 2;
This should return the following message:

'Disk' device added. Note For this example to work, the C:\tmp directory must already
exist on the database machine.

3 To back up the AutoSys database, enter the following: xql>>[AUTOSYSDB][master] 1> dump database autosys to autodump;
When the process completes, check the C:\tmp directory for the new autodump file. Your system administrator can now archive the autodump file, and you can use the file for restoring the AutoSys database, when necessary.
Recovering a Bundled Sybase Database

To recover a damaged AutoSys database using the backup file
1 Stop the Event Processor. 2 Drop the damaged database. 3 Re-create the database.
s 14-46
4 Reload the database. 5 Restart the Event Processor. WARNING You should drop the database and re-create it only in extreme situations. Before using this process to recover a damaged database, investigate all other options.
Stopping the Event Processor To stop the Event Processor

Log on as the Exec Superuser and issue the following command at an AutoSys Instance Command Prompt:
Dropping the Damaged Database You can drop the damaged AutoSys database by using the drop database command. Before you drop the damaged database, however, you should ensure that you have a database dump file to use to restore the database. To drop the damaged database
1 Enter the following xql command at the AutoSys Instance Command
Prompt (assuming that the sa password is sysadmin):

xql -Usa -Psysadmin 2 At the xql prompt, enter the following: xql>>[AUTOSYSDB][master] 1> drop database autosys;
If the AutoSys database is so damaged that drop database does not work, contact your Technical Support representative.
Note The semicolon at the end of the command line is an end-of-statement delimiter in xql, replacing the Sybase go.
14-47 s
Re-Creating the AutoSys Database After dropping the damaged database, you must recreate a new AutoSys database. This new database is used to load the database dump file (e.g., the autodump file) that you are recovering. Use the create database command to create the new AutoSys database. To re-create the AutoSys database
1 To create the new database, at the xql prompt, enter the following: xql>>[AUTOSYSDB][master] 1> create database xql>>[AUTOSYSDB][master] 2> autosys on default xql>>[AUTOSYSDB][master] 3> = 50; Note The above size of 50MB is only an example.
The output generated by this command will look similar to this:

Msg 1805, Level 0, State 1, Line 1 CREATE DATABASE: allocating 15360 pages on disk default 2 To change the owner of the new AutoSys database to autosys, enter the following at the xql prompt: xql>>[AUTOSYSDB][master] 1> use autosys; xql>>[AUTOSYSDB][autosys] 1> sp_changedbowner xql>>[AUTOSYSDB][autosys] 2> autosys;
When the procedure has completed successfully, a message similar to this should be returned:
Database owner changed.
s 14-48
Reloading the Database You are now ready to execute the load database command to restore the database you originally dumped to autodump. To reload the database and put it online
Enter the following at the xql prompt:
xql>>[AUTOSYSDB][master] 1> load database autosys xql>>[AUTOSYSDB][master] 2> from autodump; xql>>[AUTOSYSDB][master] 1> online database autosys;
The AutoSys database is now restored and online.

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 using the AutoSys Administrator Services screen. When you complete this process, AutoSys will be in the state it was in when you dumped the database to the backup file.
14-49 s
s 14-50
15
AutoSys Administrator
This chapter describes the AutoSys Administrator and how to use its various screens to configure AutoSys instances. In addition, this chapter describes how to use the AutoSys Administrator to implement several AutoSys advanced configurations, including cross-instance job dependencies, Dual Event Servers, and Shadow Event Processors.
About the AutoSys Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-3 Starting the AutoSys Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-5 AutoSys Administrator Menu Bar and Toolbar . . . . . . . . . . . . . . . . . . . . . . . . 15-5 AutoSys Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-9 AutoSys Administrator Instance Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-10 AutoSys Remote Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-11 AutoSys Administrator Remote Agent Screen . . . . . . . . . . . . . . . . . . . . . . . . 15-12 AutoSys Event Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-15 Dual Event Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-15 AutoSys Administrator Event Server Screen . . . . . . . . . . . . . . . . . . . . . . . . . . 15-16 AutoSys Event Processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-22 AutoSys Administrator Event Processor Screen . . . . . . . . . . . . . . . . . . . . . . . 15-23
15-1 s
s AutoSys Administrator
AutoSys Notification Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-37 AutoSys Administrator Notifications Screen . . . . . . . . . . . . . . . . . . . . . . . . . .15-37 AutoSys System Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-40 AutoSys Administrator System Information Screen . . . . . . . . . . . . . . . . . . . .15-41 AutoSys Sounds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-45 AutoSys Administrator Sounds Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-46 AutoSys Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-48 User Remote Authentication Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-49 AutoSys Administrator Security Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-50 AutoSys Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-52 AutoSys Administrator Services Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-52
s 15-2
AutoSys Administrator s About the AutoSys Administrator
About the AutoSys Administrator

The AutoSys Administrator is installed as part of the AutoSys Console Utilities, and you can use it to view and modify the configuration parameters for each AutoSys instance you install. Once set, these configuration parameters are loaded into the Windows NT Registry. On startup, AutoSys reads this information to determine runtime behavior. AutoSys reads this configuration information to determine the database(s) to which to connect, as well as how to react to certain error conditions. In particular, the Event Processor bases much of its runtime behavior on the parameters that are defined in the AutoSys Administrator. The Administrator has the following screens, which contain the associated configuration parameters:
s s s s s s s s s
15
Instance Remote Agent Event Server Event Processor Notifications System Information Sounds Security Services
15-3 s
About the AutoSys Administrator
To modify many of these settings, you must have NT Administrators group privileges. If you do not have these privileges, but you do have NT Power User or User group privileges, you have access to only the following screens and actions:
s
Instance screen, which allows you to specify the Computer and Instance to which the settings belong. Sounds screen, which allows you specify the sounds associated with certain AutoSys alarms and events. Security screen, which allows you to set up your own Trusted Users for remote authentication. Services screen, which allows you to view the status of AutoSys Remote Agent and Event Processor services (but you cannot change the status without the correct permissions).
WARNING The Event Processor reads the settings in the AutoSys Administrator on startup only. Therefore, if you make a change to an Administrator setting that you want implemented immediately, you must stop the Event Processor using the sendevent -E STOP_DEMON command, and then restart it using the Administrator Services screen (which is described in on page 15-55). Note Many of the configuration parameters that you set on NT using the AutoSys Administrator have a corresponding configuration parameter on UNIX. However, on UNIX you set these parameters in the $AUTOUSER/config.$AUTOSERV configuration file. When appropriate, this chapter provides both the Administrator field name and its UNIX configuration file parameter equivalent. For information on the AutoSys configuration file on UNIX platforms, see the Chapter 13, Configuring AutoSys, in the AutoSys User Guide for UNIX.
s 15-4
AutoSys Administrator s Starting the AutoSys Administrator
For information while using the AutoSys Administrator, see the AutoSys Help. Open the AutoSys Help from the AutoSys Help icon in the AutoSys program group, or open help from the Administrator. To open help for the Administrator, press <F1> while the Administrator has focus. To open help on a specific Administrator screen, press <Shift+F1> while that screen has focus.
Starting the AutoSys Administrator

To start the AutoSys Administrator
15
Select the AutoSys Administrator icon in the AutoSys program group.
Once you have started the AutoSys Administrator, you must select an instance before you can use the various Administrator screens. For information on selecting an instance, see AutoSys Administrator Instance Screen on page 15-10.
AutoSys Administrator Menu Bar and Toolbar

The AutoSys Administrator has a basic menu bar and toolbar that is available with all Administrator screens. The toolbar buttons are menu item accelerators (see Figure 15-1).
15
15-5 s
Remote Agent Event Server Event Processor Notification Instance
Export Cut Copy Paste
Help About AutoSys Administrator System Sounds Information Security Services
Figure 15-1 AutoSys Administrator Toolbar
AutoSys Administrator Menu Bar

The Administrator menu bar contains the File, Edit, View, AutoSys, and Help menus. File Menu The file menu contains the following options: Export Export As Exit Exports the configuration settings to a text file. Writes the configuration settings to a text file that you specify. Exits the AutoSys Administrator.
s 15-6
AutoSys Administrator s Starting the AutoSys Administrator
Edit Menu The Edit menu contains the following options: Undo Cut Copy Paste Undoes the last operation. Removes the selected text and places it on the clipboard. Copies the selected text to the clipboard. Pastes the contents of the clipboard at the location of the cursor.
View Menu The View menu contains the following options: Toolbar Status Bar Toggles to show or hide the toolbar. Toggles to show or hide the status bar.
AutoSys Menu The AutoSys menu contains the following options: Instance Displays the Instance screen, which you can use to select the computer and installed instance. Once you select a computer and instance, you can view and modify instance settings using the other Administrator screens. Displays the Remote Agent screen, which you can use to set the Remote Agent port number and its list of authorized Event Processors (used in remote authentication). Displays the Event Server screen, which you can use to specify Event Servers, either for Single Server or Dual Server Mode.
Remote Agent
Event Server
15-7 s
Notifications
Displays the Notifications screen, which you can use to specify user-defined alarm callbacks for certain types of system alarms. Displays the Event Processor screen, which you can use to define the Event Processor behavior, as well as the information needed to run a Shadow Event Processor. Displays the System Information screen, which you can use to view the settings for certain AutoSys variables. This information is helpful when troubleshooting. You can modify the settings on this screen, but you should do so with caution. Displays the Sounds screen, which you can use to view and set the sounds that are associated with certain AutoSys events. You can also use this screen to enable and disable sound. Displays the Security screen, which you can use to set the Trusted Hosts and Trusted Users for remote authentication. Displays the Services screen, which you can use to view and alter the status of Remote Agent and Event Processor services.
Event Processor
System
Sounds
Security
Services
Help Menu The Help menu contains the following options: Help Topics About AutoSysAdmin Displays the Help Index and Find utility. Displays release information on AutoSys Administrator.
s 15-8
AutoSys Administrator s AutoSys Instances
AutoSys Instances
When you start the AutoSys Administrator, the Instance screen is displayed (see Figure 15-2 on page 15-10). This screen lets you select a computer and AutoSys instance, which you can view or modify using the other screens of the Administrator.
15
An AutoSys instance is one licensed version on AutoSys software running as an AutoSys server and as one or more an AutoSys clients, on one or multiple machines. An instance uses its own Event Processor and Event Server and operates independently of other AutoSys instances. An instance is defined by the following:
s s s
A definition in the AutoSys Administrator. An Event Processor. The value of the %AUTOSERV% variable defined in the environment in which the Event Processor is running. (The %AUTOSERV% value is indicated on the Administrator System Information screen.) At least one Event Server (specified in the Administrator Event Server screen).
Events are associated with a specific instance. They have a unique ID, called an eoid, that is prefixed by the three letter instance ID specified by the %AUTOSERV% variable. This naming convention ensures an events uniqueness and traceability across multiple instances. The use of multiple databases is completely independent of multiple instances of AutoSys. You can have multiple instances of AutoSys, each using Dual Event Servers. In addition, you can configure AutoSys to run with cross-instance job dependencies.
Note You can set the instance ID only during the installation
process.
15-9 s
AutoSys Instances
For information on installing multiple instances see the Installing Multiple Instances section in Chapter 6, Advanced Configurations, of the AutoSys Installation and Getting Started Guide for Windows NT. For information on running multiple instances and running cross-instance job dependencies, see Chapter 1, Introduction to AutoSys, in the AutoSys Installation and Getting Started Guide for Windows NT.
AutoSys Administrator Instance Screen

When you start the AutoSys Administrator, the Instance screen is displayed (see Figure 15-2). To view the various AutoSys Administrator screens, you must first select a computer and installed AutoSys instance on which to operate.
15
Figure 15-2 AutoSys Administrator Instance Screen
The AutoSys Instance screen allows you to select a Computer and AutoSys Instance, so you can view or modify that instances configuration settings.
s 15-10
AutoSys Administrator s AutoSys Remote Agents
Computer
The Computer setting specifies the hostname of the computer on which AutoSys is installed and to which you are connected. By default, this field contains the name of the machine that you are logged onto, but you can connect to a remote machine to administer the instance information. To connect to a remote machine:
Type the hostname in the Computer field and click Connect.
AutoSys Instance
The capitalized three-letter name that identifies a specific AutoSys server installation. By default, the Instance ID is ACE, but you can specify another name during the installation process. You can have multiple instances running on the same machine, as long as they have different instance IDs. The Instance ID is referenced by the %AUTOSERV% environment variable. To select an instance
1 If necessary, select a computer by typing in the Computer name and
clicking Connect. The hostname of the computer that you are logged onto is already selected when you open the window.
2 If necessary, select an instance from the AutoSys Instance drop-down
list. The instance that appears in the Instance field is selected.

3 Click OK.
After you select an instance, the AutoSys menu items and their corresponding toolbar buttons are enabled, which allows you to move from screen to screen.
AutoSys Remote Agents
15
The Remote Agent is an NT service running on a remote machine, and the Event Processor directs the Remote Agent to perform specific tasks. When the Event Processor starts a job, the Remote Agent logs onto the machine,
15-11 s
starts the command specified for a given job, sends running and completion information about a task as events to the database, and then exits. If the Remote Agent is unable to transfer the information, it waits and tries again until it successfully communicates with the database.
AutoSys Administrator Remote Agent Screen

The Administrator Remote Agent screen (see Figure 15-3) allows you to set the Remote Agent Port number, local logging directory, and Event Processors that have permission to start processes on this Remote Agent (when remote authentication is turned on). To move to the Remote Agent screen
Select Remote Agent from the AutoSys menu.
Or
15
Click the Remote Agent button on the toolbar.
Figure 15-3 AutoSys Administrator Remote Agent screen
s 15-12
AutoSys Administrator s AutoSys Remote Agents
Note To modify the settings on this screen, you must have NT
Administrators group privileges. For information on turning on remote authentication, see the autosys_secure section in Chapter 1, AutoSys Commands in the AutoSys Reference Guide for Windows NT.
Defining Remote Agent Configuration Parameters

This section lists and describes the configuration parameters located on the Remote Agent screen. TCP/ IP Port # AutoRemPort
The Remote Agent TCP/IP Port Number specifies the port number for the Remote Agent, and it should be the same number for all Remote Agents associated with an instance. The Event Processor communicates to the Remote Agent by way of this TCP/IP socket connection. The default number is 5280. You set the TCP/ IP Port number at installation time, but you can change this number using the AutoSys Administrator. This number must be different from the Event Server Port number, and all AutoSys Remote Agents for an instance must use the same port number. The internet service on the client machine uses the port number to point to the name of the service in the following file:
%SYSTEMROOT%\system32\drivers\etc\SERVICES
On NT, you must supply unique Remote Agent port numbers for each instance that you install. That is, if you are running an ACE and a PRD instance, each instance must have a unique Remote Agent port number. For information on the Event Server Port Number, see Defining Event Server Configuration Parameters on page 15-18.
15-13 s
Local Agent Logging Directory The Local Agent Logging Directory field specifies the local directory, on the Remote Agent machine, in which AutoSys should write that Remote Agent log files for jobs. This setting overrides the Enterprise Wide Logging Directory. For information on the Enterprise Wide Logging Directory, see its description on page 15-26. Authorized Event Processor Host Names The Authorized Event Processor Host Names list specifies the hostnames of the Event Processors from which this Remote Agent can accept job processing requests. AutoSys uses this list only if remote authentication is turned on, which you can do using the autosys_secure command. If you turn on the Event Processor remote authentication, the Remote Agent verifies that the requesting Event Processor is on this list before it will process job requests. To add an Event Processor to this list
Type the Event Processor machine hostname, and click the Add EP button.
To delete an Event Processor from this list

Select the Event Processor, and when it appears in the top field, click the Remove EP button.
Note On NT, each Remote Agent installation is associated with an instance; therefore, the machine hostname is all that is required in this field. When setting up Event Processor remote authentication on a UNIX machine, however, this list is located in the /etc/.autostuff file, and the entries are in the Instance:Machine_hostname format.
For information on turning on remote authentication, see the autosys_secure section in Chapter 1, AutoSys Commands in the AutoSys Reference Guide for Windows NT.
s 15-14
AutoSys Administrator s AutoSys Event Servers
AutoSys Event Servers
15
The Event Server is the AutoSys database that contains all of the events and job definitions that are used by the Event Processor. The Event Server is an NT process and its associated data space (or raw disk storage), which can include multiple databases. As a safeguard, you can configure AutoSys to run with two Event Servers, in Dual Server Mode. The Event Server screen (see Figure 15-4 on page 15-17) allows you to view and modify database-specific configuration parameters. Using this screen, you can enable Dual Server Mode, by defining and enabling the second Event Server. In addition, you can use this screen to determine if there has been a database rollover, and you can use it to restart the down Event Server and re-enable Dual Server Mode.
Dual Event Servers
15
AutoSys can run with two Event Servers. AutoSys keeps these two servers synchronized, and this configuration provides complete recovery when a disaster occurs on one of the two servers. These two Event Servers contain identical information, including job definitions and events; AutoSys reads and writes to both servers simultaneously. When processing events, the Event Processor reads from both Event Servers. If it detects an event on one server and not the other, it will copy the missing event to the other server. In this way, a temporary problem in getting events to one of the servers will not interrupt processing. In addition, the Remote Agent sends events and writes to both Event Servers.
Note To avoid a single point of failure, the two Event Servers should
reside on two different dataservers, running on different machines. 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 Windows NT. For information on installing and
15-15 s
configuring Dual Event Servers, see Installing Dual Event Servers in Chapter 6, Advanced Configurations, of the AutoSys Installation and Getting Started Guide for Windows NT.
AutoSys Administrator Event Server Screen

Using the Event Server screen, you can view and modify the databasespecific settings, and you can configure AutoSys for Dual Event Servers. In addition, you can use this screen to determine if there has been a database rollover, and to enable the down Event Server, and Dual Server Mode. Figure 15-4 shows the Event Server screen for Sybase and Microsoft SQL Server installations. shows the screen for Oracle installations. To move to the Event Server screen
Select Event Server from the AutoSys menu.
Or
15
Click the Event Server button on the toolbar.
s 15-16
Figure 15-4 AutoSys Administrator Event Server screen
15-17 s
Figure 15-5 AutoSys Administrator Event Server screen for Oracle
Administrators group privileges.
Defining Event Server Configuration Parameters

This section lists and describes configuration parameters located on the Event Server screen. Event Server A defines a server for Single Server Mode. You can also define a second Event Server (using the Event Server B area) and enable Dual Server Mode. The largest single reason for things not working is that AutoSys cannot determine which RDBMS to connect to or where to find the executables or configuration files. Therefore, it is very important to make sure that all of the database information is set up correctly on every machine.
s 15-18
WARNING When you enter the Event Server information, it must be exactly as it is defined for the database, including case. Note You can enable and define either Event Server A or Event
Server B to be in Single Server Mode. Name or Alias

EventServer
The name parameter specifies a logical name used to locate the AutoSys database. When performing database queries, AutoSys uses this Name to locate the Event Servers. For Sybase, the logical names are stored in the SQL.INI Sybase interface file. For Microsoft SQL Server, the logical name is the same as the host machine name, and you can check the database settings using the Microsoft SQL Enterprise Manager. For Oracle, the Alias, or logical name, is stored in the Oracle TNSNAMES.ORA file. For Dual Server Mode, the Event Servers should have different Name values.
Note In the UNIX configuration file, the EventServer parameter is defined by the Name:Database combination.
Enable Use the Enable button to enable the associated Event Server, either when enabling a down server or when implementing Dual Server Mode. Disable Use the Disable button to stop an Event Server and return to Single Server Mode. If you click this button, it sets the associated Event Server Status to DOWN. If you disable a Server, you must stop and restart the Event Processor, so that it is restarted in Single Server Mode.
15-19 s
Host The Host parameter specifies the name of the machine on which the associated Event Server runs. For Dual Server Mode, it is recommended that the two Event Servers reside on two different databases, running on different Host machines, to avoid a single point of failure. For Oracle installations, this field is disabled. Port The Port parameter specifies the port number for the TCP/IP socket connection between the Event Server and the Remote Agent. This is the port number on which the Event Server listens when waiting for requests. Note that this number should be different than the TCP/IP Remote Agent Port. For information on the Remote Agent port number, see Defining Remote Agent Configuration Parameters on page 15-13. Database
EventServer
The Database parameter specifies the particular AutoSys database for the associated Event Server instance. Typically, this name is autosys, and for Dual Server Mode, this can be the same value for both Event Servers. For Oracle installations, this field is disabled.
Note In the UNIX configuration file, the EventServer parameter is defined by the Event Server Name:Database combination.
Status The Status field indicates whether the associated database is UP or DOWN. For information on Dual Server Mode and how to re-enable a DOWN Event Server, see Event Server Rollover Recovery in Chapter 14, Maintaining AutoSys.
s 15-20
Database Provider Specifies the provider (manufacturer) of the Relational Database Manager System (RDBMS) that is being used for the AutoSys database. This is a read-only field; it is for informational purposes only. Database Rollover Has Occurred The Database Rollover Has Occurred check box is checked when there has been a rollover from Dual Server Mode to Single Server Mode. For information on how to re-enable Dual Server Mode, see Event Server Rollover Recovery in Chapter 14, Maintaining AutoSys. DB Event Reconnect
DBEventReconnect
The Reconnect parameter specifies the number of times that an Event Processor should attempt to connect to the Event Server before shutting down, or before rolling over to Single Server Mode. In Single Server Mode, the DB Event Reconnect value is a number, with a default setting of 50. This setting specifies that the Event Processor should attempt to connect to the Event Server 50 times before shutting down. That is, the Event Processor attempts to reconnect 50 times both on startup and when there is a connection problem. In Dual Server Mode, DB Event Reconnect contains two values, such as the default setting of 50,5 (which is set only if you initially install dual severs). If you add a second server after completing the installation process, you must set the DB Event Reconnect value appropriately. The 50,5 value specifies that the Event Processor should attempt to connect to the Event Servers 5 times before rolling over to Single Server Mode, and using only the remaining Event Server. Once AutoSys is in Single Server Mode, the Event Processor will attempt to reconnect to the remaining Event Server 50 times before shutting down. Similarly, upon start-up, the Event Processor attempts to connect to an Event Servers 5 times, and if unsuccessful, it will immediately rollover to Single Server Mode, and to the Event Server to which it can connect.
15-21 s
AutoSys Event Processors
Database Wait Time
DBLibWaitTime
The Database Wait Time parameter indicates the amount of time the Event Processor waits before it breaks a connection with an Event Server that is in an unknown state. That is, the Event Processor maintains and checks its connections with the database(s), and if an Event Server is in an unknown state, the Event Processor breaks the connection after the indicated time. Typically, the database should never time out. However, if it does, AutoSys will attempt to reconnect to the database a specified number of times. If you see the database connections timing out at a frequent rate, it probably indicates some kind of machine or Event Server contention problem.
Note If you set this value to 0, it means that no time-out value is to be applied. In other words, there are infinite connections. Because it can cause the Event Processor to hang, using the value of 0 is not recommended.
Database Alarm Reconnect
DBAlarmReconnect
Specifies the number of times that the Event Server should try to reconnect to the alarm server (if installed).
15
The Event Processor interprets and processes all the events it reads from the AutoSys database. The Event Processor is the program, running as an NT service, which actually controls AutoSysit schedules and starts jobs. The Event Processor is an NT service you must start that 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. Based on this information, the Event Processor first determines what actions are to be taken, then instructs the appropriate Remote Agent
s 15-22
AutoSys Administrator s AutoSys Event Processors
process to perform the actions. These actions include starting or stopping jobs, checking for resources, monitoring existing jobs, and initiating corrective procedures. As a safeguard, you can configure AutoSys with a second Event Processor, called the Shadow Event Processor. This second processor must run on a separate machine, and it will take over if the Primary Event Processor fails.
Note Shadow Event Processors and Dual Event Servers are independent features. Usually they run together, but they do not have to.
For information on running a Shadow Event Processor, see Shadow Event Processor in Chapter 1, Introduction to AutoSys, of the AutoSys Installation and Getting Started Guide for Windows NT. For information on installing Dual Event Servers, see Installing a Shadow Event Processor in Chapter 6, Advanced Configurations, of the AutoSys Installation and Getting Started Guide for Windows NT.
AutoSys Administrator Event Processor Screen
15
The Event Processor screen (see Figures 15-6) contains the Event Processor-specific configuration parameters, including the parameters necessary for setting up a Shadow Event Processor and the values used in calculating the Wait Time between job restart attempts To move to the Event Processor screen
Select Event Processor from the AutoSys menu.
Or
Click on the Event Processor button on the toolbar.
15-23 s
Figure 15-6 AutoSys Administrator Event Processor screen
Defining Event Processor Configuration Parameters

This section lists and describes the configuration parameters located on the Event Processor screen.
WARNING The Event Processor reads the settings in the AutoSys Administrator on startup only. Therefore, if you make a change that you want implemented immediately, you must stop the Event Processor using the sendevent -E STOP_DEMON command, then restart it using the Administrator Services screen (as described in on page 15-55).
s 15-24
Shadow Machine The Shadow Machine parameter specifies the hostname of the machine on which a Shadow Event Processor runs. If the Primary Event Processor fails, the Shadow Event Processor takes over. The Shadow Event Processor is optional. If used, it must be run on a different machine than the one on which the Event Processor is running. However, both the Shadow Machine and the Primary Event Processor must be installed on the same type of machine, either Windows NT or UNIX. You must install an Event Processor and a Remote Agent on the Shadow Machine.
Note Both the Primary and the Shadow Event Processor machines
require valid server licenses. Third Machine

ThirdMachine
When running a Shadow Event Processor, the Third Machine is used to resolve possible contentions between the two Event Processors, and to ensure that only one of the processors is running at any given time. Before the Shadow Event Processor takes over, or if the Primary Event Processor cannot signal the Shadow Event Processor, the processor that is taking over connects to this third machine and creates a dibs file that will lock the other processor out.
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 defined by the same AutoSys instance and installed on the same type of machine as the Primary and Shadow Event Processors are installed on, either Windows NT or UNIX.
15-25 s
Network Machine List
EDMachines
The Network Machine List parameter contains a comma-separated list of valid AutoSys server machines on the network where Event Processors might have been started, or might be running. The machines in this list are checked both when the chk_auto_up command is run and when a new Event Processor is started. The machines are checked to see if there are existing Event Processors running on them. This list should contain all the possible machines on which an Event Processor might be started, so that a new Event Processor is not started on a different machine. Having a complete list of Network Machines is especially critical when a Shadow Event Processor takeover occurs and your Primary server is configured to automatically restart the Event Processor. Enterprise Wide Logging Directory
AutoRemoteDir
The Enterprise Wide Logging Directory parameter specifies the path and directory to which enterprise-wide Event Processor log output files should be written. If you are using the Enterprise Wide Logging Directory, it must exist and be writable on every machine running a Remote Agent. However, you can override this setting at the Remote Agent level by setting the Local Agent Logging Directory on the Remote Agent screen. If specified, the Remote Agent writes log files to its Local Agent Logging Directory instead. In a cross-platform environment where a UNIX Event Processor starts an NT Remote Agent (or vice versa), the path to the log files directory is translated into the format expected by the recipient platform. A UNIX Remote Agent removes the drive letter, if present, and replace \ characters with / characters. For example, C:\tmp becomes /tmp. An NT Remote Agent will prepend the system drive letter and colon, if no drive letter is present, and replace all / characters with \ characters. For example, /tmp becomes C:\tmp. For information on the Local Logging Directory, see Defining Remote Agent Configuration Parameters on page 15-13.
s 15-26
Database Maintenance Command
DBMaintCmd
The Database Maintenance Command parameter specifies the location of the provided DBMaint.bat batch file. The DBMaint.bat process cleans out old events and job_runs information using the archive_events command. It also uses the dbstatistics command to update statistics for the optimizer, check for available free space, and send a DB_PROBLEM alarm if the amount of free space is insufficient. This command is run once a day. You can specify the time of day for this maintenance cycle in the Database Maintenance Time field of the Event Processor screen. Upon installation, the DBMaint.bat file is located in the %AUTOSYS%\bin\DBMaint.bat directory. For more information on the DBMaint.bat batch file, see Chapter 14, Maintaining AutoSys. Database Maintenance Time
DBMaintTime
The Database Maintenance Time parameter specifies the time of day that the Database Maintenance Command is run. Each day at the time you specify, the Event Processor goes into a database maintenance cycle. During this time, it does not process any events, and it waits for the maintenance activities to complete before resuming normal operations. You should schedule the Maintenance Command to run during a time of minimal activity, and it is highly recommend that you configure your system to backup the database during this maintenance cycle. Maximum Log Size The Maximum Log Size parameter specifies the maximum size of the Event Processor log file. The Event Processor reads this setting on startup and checks the file size. If the file is the indicated maximum size, the Event Processor deletes it. When you change this number the new size does not affect until you start the Event Processor again. The Event Processor will read the new number only on the subsequent startup processes.
15-27 s
Note If you have an autosyslog process running on the file, start the
Event Processor, and the file is its maximum size, the Event Processor will not start because it cannot delete the log file (because it has a lock on it). Event Transfer Wait Time
EvtTransferWaitTime
The Event Transfer Wait Time parameter specifies the time-out delay for transferring events while in Dual Server Mode. That is, when in Dual Server Mode, an event that is missing from one Event Server is copied over to the Second Server after this time-out delay. Error Time Interval
EDErrTimeInt
The Error Time Interval parameter specifies the time interval that is used with the Number of Errors setting (see below) 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. This is implemented as a safety measure. By default, the Error Time Interval is 60 seconds, and the Number of Errors is 20. These settings specify to shut the processor down if more than 20 errors occur within 60 seconds. These two settings together guard against cascading Event Processor errors, which are caused by the Event Processor automatically re-issuing failed directives. The primary reason for setting these parameters, and shutting the Event Processor down, is to avoid starting any new processes while there are serious problems in the system. Number Errors
EDNumErrors
The Number Errors parameter specifies the maximum number of Errors that can happen within the Error Time Interval (see above) when determining 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.
s 15-28
By default, the Error Time Interval is 60 seconds, and the Number of Errors is 20. These settings specify to shut the processor down if more than 20 errors occur within 60 seconds. HeartBeat Interval
Check_Heartbeat
The HeartBeat Interval parameter specifies the time interval (in minutes) that the Event Processor should use when checking for heartbeats. Heartbeats offer a method by which the continued progress of an application can be automatically monitored. User applications can be programmed to send heartbeats that are monitored by AutoSys. A heartbeat is a signal 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). Finally, the Event Processor checks that the HEARTBEAT event has occurred within the Heartbeat Interval specified for the instance. If you are not using this feature, you do not need to set this parameter.
Note The reason that the Event Processor (not the Remote Agent) performs the checking is that if there is a problem between the Remote Agent and the Event Server(s), the HEARTBEAT will be absent, and thus an alarm will be sent. Therefore, the HEARTBEAT is a good indicator of the stability of the network.
FileSystem Threshold
FileSystemThreshold
If the amount of available disk space falls below that specified by the FileSystem Threshold setting, the Event Processor issues a warning in the Event Processor log file similar to the following:
WARNING: The disk partition containing the EP log file is too full! WARNING: EP will shutdown if partition has less than 8192 bytes available!
15-29 s
If the amount of disk space falls below 8 kilobytes, the Event Processor issues an EP_SHUTDOWN alarm and shuts 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!
The default FileSystem Threshold setting is 32 kilobytes. Valid settings must be less than 10 MB and greater than 8192 bytes. If you set the FileSystem Threshold setting on a Remote Agent machine, the setting applies to the space available for the Remote Agent log file. The default FileSystem Threshold setting on Remote Agent machines is -1. This -1 setting indicates that the Remote Agent should use the size set for the Event Processor (set in the AutoSys Administrator for the Event Processor machine). You can change the FileSystem Threshold setting on any Remote Agent machine to override the Event Processor setting. To do this, connect to the appropriate instance and machine, move to the Event Processor screen, and change the setting to a number greater than -1. You can set this to a different value on each Remote Agent machine. Valid settings must be less than 10MB and greater than 8192 bytes. If the amount of available disk space falls below that specified by the FileSystem Threshold setting, the Remote Agent writes dots to the Remote Agent log file. If the available space drops below 8 kilobytes, the Remote Agent issues a warning and stops writing to the Remote Agent log file, but the Remote Agent service keeps running. Chase On Startup The Chase On Startup setting indicates whether the AutoSys chase utility program should run when the Event Processor is started. The chase utility checks to see if jobs and Remote Agents are actually running. For information on the chase utility, see the chase section in Chapter 1, AutoSys Commands of the AutoSys Reference Guide for Windows NT.
s 15-30
Remote Profile Logging
RemoteProFiles
The Remote Profile Logging setting indicates whether the Event Processor should redirect to the auto.rem* log file all standard error and standard output information that is generated when the UNIX /etc/auto.profile file is sourced. Since job profiles are defined differently on NT, no profile related standard error and output information is generated. Therefore, this parameter applies only to jobs that the Event Processor is sending to run on a UNIX machine. For information on how Remote Profile Logging is handled on UNIX machines, see RemoteProFiles in Chapter 13, Configuring AutoSys. Clean Temporary Files
CleanTmpFiles
The Clean Temporary Files setting indicates whether the Remote Agent should remove its temporary log file upon successfully completing a job. For every job AutoSys runs, a file is created in the Remote Agent log directory. If you check the Clean Temporary Files box, AutoSys removes the temporary log file upon the successful running a job. By doing this, the Remote Agent, upon the successful completion of its tasks, removes the C:\tmp\auto_rem* file (assuming the default C:\tmp Local Logging Directory is being used). If you deselect the Clean Temporary Files box, the files remain in the directories until you run the clean_files process. If a job is not successful, the files remain in the directory for diagnostic purposes regardless of the setting. Therefore, with either setting, you should run the clean_files process periodically to remove files from unsuccessful job completions. Global Auto Hold The Global Auto Hold setting indicates whether Global Auto Hold mode is on or off. You should turn on Global Auto Hold when you are going to restart an Event Processor after a shut-down period. Then, when you start the Event Processor, it is in Global Auto Hold mode, and you have time to evaluate all jobs whose starting conditions have passed and are thus eligible to run.
15-31 s
This option allows you to manually start jobs in a controlled manner so that the system is not overloaded with job start events. You can use the Scheduler Console screens to help you decide which jobs to start, and to then start them. For more information on Global Auto Hold, see the Starting the Event Processor Service section in Chapter 14, Maintaining AutoSys. For information on using the Scheduler Console, see Chapter 11, Scheduler Console. Z/Team Job Support
ZTeamJobSupport
The Z/Team Job Support setting indicates whether or not an AutoSys instance can start jobs on AutoSys/Team Agent machines. If the Z/Team Job Support check box is checked on, the Event Processor can send jobs to Team Agent machines. If the check box is not checked (the default setting), the Event Processor will not send jobs to Team Agents. For information on Zeke and Team Agent support, see Appendix A, Integrating AutoSys with Zeke and AutoSys/Team Agent. Append stdout/stderr
AutoInstWideAppend
The Append stdout/stderr setting specifies whether the AutoSys instance will overwrite or append information to the standard output and standard error files. If this checkbox is not selected, then the files are overwritten, which is the default behavior. If this checkbox is selected, the new output and error information is appended to the files When determining its behavior, AutoSys checks the following (in this order):
1 Checks the AutoSys job definition for an append or overwrite
notation. If there is a notation, AutoSys uses the indicated behavior, and does not check other settings.
s 15-32
To set the behavior at the job definition level, place the appropriate notation as the first character(s) in the std_err_file or std_out_file specification in JIL, or in the File to redirect standard output and File to redirect standard error fields on the Job Editor Command Info tab. Use the following notation to specify whether the files should be appended to or overwritten:
> >>
Overwrite file Append file
2 Checks the AutoMachWideAppend variable setting, which you can set in
the AutoSys Administrator System Information screen (see page 15-44). If this variable is set for the specific machine, AutoSys uses the indicated behavior, and does not check other settings.
3 Checks the Append stdour/stderr setting, and uses this setting. Note If you are running jobs across platforms, the Event Processor of the issuing instance controls the default behavior. For UNIX, the default Event Processor behavior is to append this file.
Enable External Events
AutoPems
Specifies whether or not you want to enable support for ProVision common services. If you check this option, you enable AutoSys to send events to the Event Manager and Data Exchange. By default, this option is not selected. If you select this option, AutoSys will send events for every AutoSys job to the Event Manager, and they will be displayed in the Events Window or the Alarm Window of the PLATINUM Director. Events include alarms and job status changes (job start, job running, job complete, and completion status). The Event Manager makes available, via subscription, the entire range of events and messages supported by each POEMS-enabled application. The Event Manager can be used to automate enterprise communication and integration.
15-33 s
Enabling Event Management integration also enables integration with Data Exchange. This instructs AutoSys to write job definition and job history information to the common services repository. For information on the Event Manager, Data Exchange, and the output browser, see your ProVision Common Services documentation. Machine Method
MachineMethod
The Machine Method parameter specifies the method AutoSys will use to determine the percentage of CPU cycles available on a real machine belonging to a virtual machine. This method is used to achieve load balancing. The default setting, and only choice on NT, is vmstat (on UNIX, rstatd is also supported). For information on rstatd, see Chapter 13, Configuring AutoSys, in the AutoSys User Guide for UNIX. XInstance DB Drop Time
XInstanceDBDropTime
The XInstance DB Drop Time parameter specifies how an AutoSys instance will connect with a different AutoSys instance when it has a job defined with a cross-instance job dependency. If this parameter is set to zero, then 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. This option is preferable when you use cross-instance job dependencies infrequently. If the value of this parameter is equal to one, then the Event Processor will connect to the other instance before the first event is sent and maintain the connection indefinitely. This option is preferable when you use cross-instance job dependencies intensively.
s 15-34
Max Restart Trys
MaxRestartTrys
The Max Restart Trys parameter specifies the maximum number of times that AutoSys will try to start a job. AutoSys might be unable to start a job due to system problems including machine unavailability, a timed-out socket connect, an inability to create new processes, or failure of the file system space resource check.
Note This parameter governs retries that result because of system or network problems. It is different from the n_retrys job definition attribute, which controls restarts when a job fails due to application failure (e.g., AutoSys is unable to find a file or a command, or permissions are not properly set).
For information on the n_retrys job definition attribute, see the n_retrys section in Chapter 2, JIL/GUI Job Definitions, of the AutoSys Reference Guide for Windows NT. Max Restart Wait
MaxRestartWait
The Max Restart Wait parameter specifies the maximum amount of time (in seconds) AutoSys will wait before it attempts to restart a job. This value is used in calculating the Wait Time, which is the interval in seconds that AutoSys will wait before attempting the start a job again. The following is the formula used for calculating the Wait Time:
WaitTime=RestartConstant+(Num_of_Trys*RestartFactor) if WaitTime > MaxRestartWait, then WaitTime = MaxRestartWait
The Num_of_Trys value is the value specified by the AutoSys counter, which indicates the number of times AutoSys has already tried to start the job. If the calculated Wait Time is greater than the specified value for the Max Restart Wait parameter, then the Wait Time is set to the value of the Max Restart Wait parameter. The Restart Factor and Restart Constant parameters are described below.
15-35 s
Restart Factor
RestartFactor
The Restart Factor parameter specifies a factor. This value is used in calculating the Wait Time, which is the interval in seconds that AutoSys will wait before attempting to start a job again. The formula used for calculating the Wait Time is described in the Max Restart Wait parameter, above. The Restart Constant parameter is described below. Restart Constant
RestartConstant
The Restart Constant parameter specifies a constant value. This value is used in calculating the Wait Time, which is the interval in seconds that AutoSys will wait before attempting to start a job again. The formula used for calculating the Wait Time is described in the Max Restart Wait parameter, on page 15-35. Kill Signals
KillSignals
The Kill Signals parameter specifies a comma-separated list of signals to send to a job whenever the KILLJOB event is sent. If the job to be killed is running on a Windows NT machine, this list is ignored and the job is simply terminated. 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. Microsoft Windows NT does not support the concept of process groups. If the launched job is a *.exe, KILLJOB kills the process specified in the command definition. If the job being run is not a *.exe (e.g., *.bat, *.cmd, or *.com), AutoSys uses CMD.EXE to launch the job, and then, KILLJOB kills only the CMD.EXE process. The Job Status is then set according to the return code of the killed CMD.EXE process, and this status can be any one of the following: SUCCESS, FAILURE, or TERMINATED. Any processes that were launched by user applications or batch (*.bat) files cannot be killed.
Note The KillSignals listed in the configuration file are overridden when issuing the sendevent command with the -k option.
s 15-36
AutoSys Administrator s AutoSys Notification Mechanism
AutoSys Notification Mechanism
15
The AutoSys notification mechanism provides a method for communicating problems to administrators in a manner that is external to the AutoSys event system. That is, for certain types of AutoSys alarms, you can configure AutoSys to call user-defined routines that communicate the problem to specific members of your company. For example, by using electronic mail or a command line pager utility, your administrator can be notified as soon as certain AutoSys events occur. You can configure AutoSys to call user-defined routines for the following types of system alarms:
s s s s s
Database Rollover Database Problem Event Processor Rollover Event Processor Shutdown Event Processor High Availability
To specify that AutoSys should invoke a user-defined callback for one of these alarms, enter the path and executable name in the appropriate field on the AutoSys Administrator Notifications screen.
AutoSys Administrator Notifications Screen

Using the AutoSys Administrator Notifications screen (see Figure 15-7), you can enter the path and executable name to the user-defined routines that you want associated with the events. For the Notification mechanism to work, the specified executable file must exist in the specified path.
15
15-37 s
AutoSys Notification Mechanism
To move to the Notifications screen

Select Notifications from the AutoSys menu.
Or
Click the Notifications button on the toolbar.
Figure 15-7 AutoSys Administrator Notifications screen
s 15-38
AutoSys Administrator s AutoSys Notification Mechanism
Notification Example
If you want AutoSys to call the program C:\utils\pager.bat when the Event Processor shuts down, you would enter the following in the Event Processor Shutdown field:
C:\utils\pager.bat
Then, if the Event Processor shuts down, AutoSys will pass pager a numeric code and a text message. You must code pager to accept these parameters.
Defining Notifications Configuration Parameters

This section lists and describes the configuration parameters located on the Notifications screen. When specifying a user-defined routine, you must enter the complete path and executable name in the appropriate field. Database Rollover
DB_ROLLOVER
The Database Rollover parameter specifies the user-defined routine that AutoSys should call when it has rolled over from Dual Server Mode to Single Server Mode. Database Problem
DB_PROBLEM
The Database Problem parameter specifies the user-defined routine that AutoSys should call when there is a problem with one of the AutoSys databases. Event Processor Rollover
EP_ROLLOVER
The Event Processor Rollover parameter specifies the user-defined routine that AutoSys should call when the Shadow Event Processor is taking over processing.
15-39 s
AutoSys System Information
Event Processor Shutdown
EP_SHUTDOW
The Event Processor Shutdown parameter specifies the user-defined routine that AutoSys should call when the Event Processor is shutting down, either as a result of a normal shutdown process or as a result of an error condition. Event Processor High Availability
EP_HIGH_AVAIL
The Event Processor High Availability parameter specifies the userdefined routine that AutoSys should call when the Event Processor is shutting down. This occurs when the Shadow Event Processor cannot reach the Third Machine to determine the availability of the Primary Event Processor, or when there are other types of Event Processor takeover problems.
15
Access to AutoSys software is controlled by three environment variables and the NT Registry settings that you enter through the AutoSys Administrator. In addition, the AutoSys database often has associated environment variables and configuration files. For AutoSys to work properly, all of these variables and files must be present in each working environment. During the installation procedures, variables are set both at the NT system level and at the AutoSys level. The AutoSys Administrator System Information screen displays the variables that are set at the AutoSys level; these variables are set when you run the AutoSys software. You can modify and add to these standard environment variables.
Note The environment variables for the AutoSys database and, if you installed AutoSys/Xpert, the NuTCRACKER X Server are set at the NT system level.
s 15-40
AutoSys Administrator s AutoSys System Information
AutoSys Administrator System Information Screen

Using the AutoSys Administrator System Information screen (shown in Figure 15-8), you can view and modify the settings of environment variables that are necessary for AutoSys. In addition, the System Information screen provides Version and Build information on the AutoSys that you are running. The Administrator System Information screen reflects the information that AutoSys is using. This information is supplied primarily for informational purposes. That is, while you can modify these standard System settings, you should be very careful if you decide to do so. To move to the System Information screen
Select System Information from the AutoSys menu.
Or
15
Click the System Information button on the toolbar.
15-41 s
Figure 15-8 AutoSys Administrator System Information screen
Using the System Information Screen

To add an environment variable
Enter a Variable and Value, and click Set. Then, click Apply or OK.
To modify an existing environment variable

1 Double-click on the Environment Variable in the list that you want to
modify.
2 Modify the Variable or Value, or both. 3 Click Set, and click Apply or OK.
s 15-42
AutoSys Administrator s AutoSys System Information
To delete an environment variable

1 Double-click on the Environment Variable in the list that you want to
delete.
2 Click Delete, and click Apply or OK. Note To modify the settings on this screen, you must have NT
System Information Configuration Parameters

This section lists and describes the AutoSys-specific variable settings that are located on the System Information screen by default. These are the environment variables that are set in the AutoSys Instance Command Prompt windows. In addition to the default environment variable settings, the System Information screen includes the AutoMachWideAppend variable. You can set this to control output and error writing behavior on a machinespecific basis.
Note The variables that appear on this screen are set when you open
an AutoSys Instance Command Prompt window. AUTOSYS

$AUTOSYS
The %AUTOSYS% environment variable specifies the full path to the AutoSys software directory. AUTOROOT
$AUTOROOT
The %AUTOROOT% environment variable specifies the top-level AutoSys directory.
15-43 s
AUTOSERV
$AUTOSERV
The %AUTOSERV% environment variable specifies the AutoSys instance ID. The instance ID is the capitalized three-letter name that identifies a specific AutoSys server installation on a particular machine. By default, the instance ID is ACE, but you can specify another name during the installation process. You cannot change this variable using the AutoSys Administrator. To change the instance ID, you must uninstall AutoSys, and reinstall it using the new ID. For more information on AutoSys instances, see AutoSys Instances on page 15-9. AUTOUSER
$AUTOUSER
The %AUTOUSER% environment variable specifies the full path to the directory containing the AutoSys users directory, which holds the user external configurations file (the config.EXTERNAL file), the Event Processor output files, and the archive output files generated during database maintenance. For more information on the config.EXTERNAL file, see the Configuring Cross-instance Job Dependencies section in Chapter 6, Advanced Configurations of the AutoSys Installation and Getting Started Guide for Windows NT. DSQUERY The %DSQUERY% environment variable specifies the name of the Sybase Event Server. The default setting is AUTOSYSDB. If you are using an Oracle or Microsoft SQL Server database, this field is not displayed. AutoMachWideAppend You can set the %AutoMachWideAppend% variable to override, at the machine level, the Append stdout/stderr configuration parameter, which is set in the AutoSys Administrator Event Processor screen (see page 15-32). Using this variable, you can set up each client machine to override global behavior.
s 15-44
AutoSys Administrator s AutoSys Sounds
If you set this variable to yes, the log files are appended. If you set it to no, the log files are replaced. If you do not set this variable, the behavior set by the Append stdout/stderr global configuration parameter is used.
Note On UNIX, the AutoMachWideAppend parameter is located in the /etc/auto.profile file.
Version The Version field indicates the AutoSys for Windows NT version number (for information purposes only). Build The Build field indicates the AutoSys for Windows NT build number. This field is read-only; it is for informational purposes only.
AutoSys Sounds
15
If you have an AutoSys Monitor/Browser Editor running on an NT system that supports sound, you can associate sounds with specific AutoSys events, such as AutoSys alarms or job success and failure. You can use the Administrator Sounds screen to turn sound on and off as well as specify the sounds you want played for AutoSys-specific events. Then, once you have enabled and defined these sounds, AutoSys uses the defined sounds to announce the events as they occur.
Note All sounds also can be managed using the Sound option of the NT Control Panel. In addition, you can record new sounds with the NT Sound Recorder in the Accessories program group. For instructions on how to record sounds, see your NT documentation.
For information on the Monitor/Browser Editor, see Chapter 13, Monitoring and Reporting on Jobs.
15-45 s
AutoSys Sounds
AutoSys Administrator Sounds Screen

Using the AutoSys Administrator Sounds screen (see Figure 15-9), you can turn sound on and off as well as specify the sounds you want played for AutoSys-specific events. In each Sounds field, you can specify the *.wav file that you want played for that event. To move to the Sounds screen
Select Sounds from the AutoSys menu.
Or
15
Click on the Sounds button on the toolbar.
Figure 15-9 AutoSys Administrator Sounds screen
Note Changes you make to the sound settings are saved for the current, logged on NT user. If you log on as a different user, these modified settings will not be in effect.
s 15-46
AutoSys Administrator s AutoSys Sounds
Defining Sounds Configuration Parameters

This section lists and describes the configuration parameters located on the Sounds screen. AutoSys Alarm The AutoSys Alarm setting specifies the location of the *.wav file that is played for AutoSys Alarm events. For a list of AutoSys Alarms, see the Alarms section in Chapter 5, System States, of the AutoSys Reference Guide for Windows NT. AutoSys Big Alarm The AutoSys Big Alarm setting specifies the location of the *.wav file that is played for the AutoSys Big Alarm. An AutoSys Big Alarm announces an event that is not a job CHANGE_STATUS event, but still returns a FAILURE or TERMINATED status. AutoSys Default The AutoSys Default setting specifies the location of the *.wav file that is played for all events that do not fit in the other Sounds categories (i.e., Alarm, Big Alarm, Success, and Failure). AutoSys Success The AutoSys Success setting specifies the location of the *.wav file that is played for an AutoSys job SUCCESS event. A SUCCESS event occurs when a job exits and AutoSys considers it successful, based on the exit code for a Command Job or the success conditions for a Box Job. AutoSys Failure The AutoSys Failure setting specifies the location of the *.wav file that is played for an AutoSys job FAILURE status event. A FAILURE event occurs when a job exits and AutoSys considers it a failure. A job is considered a failure when the exit code for a Command Job is greater than the maximum success value specified for the job, or when the failure conditions for a Box Job evaluated to true.
15-47 s
AutoSys Security
AutoSys Security
15
AutoSys supplies you with several security features. One of these features is remote authentication. There are two types of remote authentication, Event Processor authentication and user authentication. You can configure your Remote Agents so they verify access permission for Event Processors and for users. The Administrator Security screen allows you to define the Trusted Hosts and Trusted Users for User remote authentication. By default, both types of remote authentication are turned off, but you can turn them on using the autosys_secure command. If Event Processor remote authentication is on, the Remote Agent will verify that the requesting Event Processor is on the list of Authorized Event Processor Host Names, which is specified on the AutoSys Administrator Remote Agent screen. If user remote authentication is turned on, the Remote Agent will check the Trusted Hosts and Trusted Users lists to see if the job request is coming from an authorized host or user. The Security screen allows you specify AutoSys Trusted Hosts and Users, which are used when remote authentication is turned on. Remote authentication supplies additional security measures, and you can turn it on using the autosys_secure utility. For information on specifying Authorized Event Processors, see Defining Remote Agent Configuration Parameters on page 15-13. For information on other types of AutoSys security features, see Chapter 2, AutoSys Security. For information on using autosys_secure to turn on remote authentication, see the autosys_secure section in Chapter 1, AutoSys Commands, of the AutoSys Reference Guide for Windows NT.
s 15-48
AutoSys Administrator s AutoSys Security
User Remote Authentication Example

With user remote authentication turned on, the Remote Agent follows this procedure when trying to log onto a machine to run a job. To log onto a machine to run a job
1 The Event Processor tries to log on as the user@host_or_domain specified by the owner job attribute, using the password that the Event Processor has passed with that owner value. If this logon is successful,
15
the job is started.

2 If the first log on does not work, the Remote Agent tries to log on as the user owner at the machine on which the job is to be run (the hostname specified by the machine job attribute), using the user@host
format. The Remote Agent uses the password that the Event Processor has passed to it for this user. However, since the job owner is now different from the user that is trying to log on, Remote Agent User Authentication is required. Therefore, the Remote Agent checks for one of the following two things (in this order, and only one condition must be met):
If the host_or_domain specified in the owner attribute is on the
Trusted Hosts list.

If the user@host_or_domain specified by the owner attribute is on
the Trusted Users list.

3 If one of these conditions is met, the Remote Agent attempts to log on
as this user (user@host) by using the database password entered for that user. If this logon succeeds, the job is started. Otherwise, the Remote Agent does not start the job and issues an error.
15-49 s
AutoSys Security
Note In addition to checking the permissions of these various users, the Remote Agent makes sure that the NT user has a valid ID and password entered in the AutoSys database. The AutoSys Edit Superuser can enter and modify passwords using the autosys_secure command, and any AutoSys user that knows an existing user ID and password can change the password or delete the user and password using the autosys_secure command.
For more examples of security on NT, see Examples of AutoSys Security on Windows NT in Chapter 2, AutoSys Security. For information on entering your NT user IDs and passwords, see Chapter 8, Adding the AutoSys Superusers and the NT User IDs and Passwords in the AutoSys Installation and Getting Started Guide for Windows NT. For information on autosys_secure and turning on remote authentication, see the autosys_secure section in Chapter 1, AutoSys Commands, of the AutoSys Reference Guide for Windows NT.
AutoSys Administrator Security Screen
15
Using the AutoSys Administrator Security screen (see Figure 15-10), you can specify the Trusted Hosts and Trusted Users lists (which are only used when remote authentication is turned on, using the autosys_secure utility). To move to the Security screen
Select Security from the AutoSys menu.
Or
Click on the Security button on the toolbar.
s 15-50
AutoSys Administrator s AutoSys Security
Figure 15-10 AutoSys Administrator Security screen
Note To modify the Trusted Host setting, you must be the AutoSys Edit Superuser, and you must have NT Administrators group privileges.
Defining Security Configuration Parameters

This section lists and describes the configuration parameters located on the Security screen. Trusted Hosts The Trusted Hosts list defines the machine hostnames or domain names that are allowed to log onto the client machine to run jobs. You must be the AutoSys Edit Superuser to modify the Trusted Hosts settings. Use the Add Host and Remove Host buttons to enter or remove the hostname in the top field of the Trusted Hosts list.
15-51 s
AutoSys Services
Exercise caution when modifying this list, since any user on a designated Trusted Host host_or_domain is granted AutoSys logon access, and thus can run jobs on the client machine. Trusted Users The Trusted Users list is a group of user@host_or_domain entries that define who can log on and run jobs on the defining client machine. Trusted Users permissions are owned and administered by individual users on client machines. All users can define their own set of Trusted Users on their own machines. As the current, logged on NT user, you can make changes to the Trusted Users settings, and they are saved under your specific user ID only. Then, all users listed as Trusted Users are allowed to log onto the defining client machine, as long as they have a valid user ID and password in the AutoSys database. Use the Add User and Remove User buttons to enter or remove the user names in the top field of the Trusted Users list.
AutoSys Services
AutoSys has the following primary components, or services:
s s
15
Remote Agent Event Processor
The Services screen allows to you check the status of the AutoSys Services that are associated with the instance that you selected in the Instance screen.
AutoSys Administrator Services Screen
15
Using the AutoSys Administrator Services screen (see Figure 15-11), users with NT Administrators group privileges can start and stop the Remote Agent service, and start the Event Processor service. Other users can only view the status of these Services.
s 15-52
AutoSys Administrator s AutoSys Services
Note You cannot stop the Event Processor Service from this screen. To stop the Event Processor, you must be the AutoSys Exec Superuser, and you must execute the sendevent -E STOP_DEMON command at an AutoSys Instance Command Prompt. When you are ready to start the Event Processor again, you can do so from the Services screen.
To move to the Services screen

Select Services from the AutoSys menu.
Or
Click on the Services button on the toolbar.
Figure 15-11 AutoSys Administrator Services screen
15-53 s
AutoSys Services
Services Screen Components

This section lists and describes the components of the Services screen. Service The Service drop-down list shows the Services that are installed on the selected instance. You can select a Service from the drop-down list, and then you can view and change the Status of the Service. Status The Status traffic light and the field below indicate the status of the selected Service. The traffic light indicates the status of the selected AutoSys Service. A red light indicates that the service is Stopped; a yellow light indicates that the service is Updating or Pausing; and a green light indicates that the service is Running. The field below the traffic light also indicates the status of the selected AutoSys Serviceit corresponds to the traffic light. This value can be Stopped, Updating, or Running. Start Service If the Start Service button is enabled, you can click it to start the selected AutoSys Service. Stop Service If the Stop Service button is enabled, you can click it to stop the selected AutoSys Remote Agent Service. (The Event Processor service cannot be stopped from this screen. See the note in the next section.)
s 15-54
AutoSys Administrator s AutoSys Services
Using the Services Screen

Using the AutoSys Administrator Services screen, users with NT Administrators group privileges can start and stop the Remote Agent service, and start the Event Processor service To start the Remote Agent
Select the Remote Agent service from the Service drop-down list and click Start Service.
To stop the Remote Agent

Select the Remote Agent service from the Service drop-down list and click Stop Service.
To start the Event Processor

Select the Event Processor service from the Service drop-down list and click Start Service.
Note You cannot stop the Event Processor Service from this screen. To stop the Event Processor, you must be the AutoSys Exec Superuser, and you must execute the sendevent -E STOP_DEMON command at an AutoSys Instance Command Prompt. When you are ready to start the Event Processor again, you can do so from the Services screen.
15-55 s
AutoSys Services
s 15-56
16
Troubleshooting
Problems with AutoSys usually involve the interactions between the major AutoSys components, rather than with the individual components themselves. This chapter presents a number of common AutoSys problems, their symptoms, and how to resolve them. It provides very useful information about troubleshooting the primary AutoSys components.
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-3 NT Services Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-4 Event Server Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-5 Event Server is Down (Sybase) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-5 Sybase Deadlock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-6 Not Enough User Connections (Bundled Sybase) . . . . . . . . . . . . . . . . . . . . . . 16-7 archive_events Fails (Bundled Sybase) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-9 Event Server Unable to Extend Tablespace (Oracle) . . . . . . . . . . . . . . . . . . . 16-11 Event Processor Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-12 Event Processor is Down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-12 Event Processor Will Not Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-13
16-1 s
s Troubleshooting
Remote Agent Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-18 Remote Agent Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-18 Remote Agent Will Not Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-19 Remote Agent Starts, Command RunsNo RUNNING Event is Sent . . . . . .16-21 xql Will Not Start (Sybase Only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-24 Job Failure Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-24 Remote Agent Will Start - Command Will Not Run . . . . . . . . . . . . . . . . . . . .16-24
s 16-2
Troubleshooting s Introduction
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).
16
When a job is defined, its starting conditions are saved to the Event Server (database), and the following occurs:
s
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.
This is the basic cycle for all jobs.

Note If you are using an Oracle or a Microsoft SQL Server database as your Event Server, you must install the appropriate, databasespecific Oracle Client Products (specifically SQL*Net Release 2.2 or higher) or Microsoft SQL Server client utilities on each AutoSys Event Processor and Remote Agent machine, and you must ensure that you have database connectivity between the Event Server, Event Processor, and Remote Agent machines.
For more information about job processing, see the Basic AutoSys Functionality section in Chapter 1, Introduction to AutoSys.
16-3 s
s Troubleshooting
NT Services Troubleshooting
NT Services Troubleshooting
16
You can start the AutoSys Event Processor and Remote Agents from the AutoSys Administrator Services screen, and you can start the Event Server (the Sybase, Oracle, or Microsoft SQL Server service) from the NT Control Panels Services dialog. You can find details as to why the service did not start in the NT Event Viewer in the Administrative Tools program group. Typically, problems with starting AutoSys Services, using the AutoSys Administrator Services screen, indicate that the AutoSys software was not successfully installed. In these cases, often the best approach to remove the existing AutoSys installation and re-install it. To verify that the Event Server service (the database service) is started, look at the NT Control Panels Services dialog. For bundled Sybase, verify that the status of SYBSQL_LOCAL is started. If you are running unbundled Sybase, the service will have a different name. If you are running an Oracle database, verify the status of the following services (substitute your Oracle SID for the asterisk): OracleService*, OracleStart*, and OracleTNSListener. If you are running a Microsoft SQL Server, verify the status of the MSSQLServer service.
Note To remove AutoSys, follow the instructions in Appendix B, Removing AutoSys 3.4, in the AutoSys Installation and Getting Started Guide for Windows NT.
For information on starting services with the AutoSys Administrator, see AutoSys Services in Chapter 15, AutoSys Administrator.
s 16-4
Troubleshooting s Event Server Troubleshooting
Event Server Troubleshooting

Event Server is Down (Sybase)
Symptoms
1 When trying to start xql, you get a message like this: DB-Library error: dbproc NULL Error in SybInit: dbopen failed 2 When running programs like autorep or autosc, you get a messages
16
16
like this:
Client ERROR: Net-Lib protocol driver call to connect to two end points failed. 3 When you run chk_auto_up, you receive a message similar to this: Couldnt connect with Server: AUTOSYS:autosys 4 You are unable to insert keys with gatekeeper.
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. If you are running AutoSys with an unbundled Sybase database, verify that the database services have been started. Or, if your database resides on a UNIX platform, verify that the processes for your database are running. If you have installed the AutoSys bundled Sybase database on an NT machine, you can check the status of the database using the NT Control Panels Services dialog on that machine. The name of the bundled Sybase Service is SYBSQL_LOCAL. In addition, you can use the NT Services dialog to start the Sybase Service.
16-5 s
s Troubleshooting
If the database service is running, the problem could be that you are pointing to the wrong dataserver. The system 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. You can view and modify the setting of the DSQUERY environment variable using the AutoSys Administrator, which you can open from the AutoSys program group. The DSQUERY field is located on the Administrator System Information screen. If the database service is up, and the environment variable is set properly, then the Sybase SQL.INI 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 SQL.INI file has not been correctly installed. This file is located in %SYBASE%\INI. For more information about the Sybase SQL.INI file and connecting to databases, see Chapter 1, Introduction to AutoSys, in the AutoSys Installation and Getting Started Guide for Windows NT. For information on using the AutoSys Administrator, see Chapter 15, AutoSys Administrator.
Sybase Deadlock
Symptom
16
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 (Autosys.instance\sql10\log\sqlsrvr.log):
Your server command (process id #11) was deadlocked with another process and has been chosen as deadlock victim. Re-run your command.
s 16-6
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 users 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 users 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 victims transaction, notifies the application with the above error message, and allows the other users processes to move forward.
sendevent will try to rerun the command until it is successful or until it reaches the maximum number of tries specified by the -M option.
Not Enough User Connections (Bundled Sybase)

Symptoms
Users cannot make connections to the database; they cannot start the GUI or send events. When you check the Sybase error log (Autosys.instance\sql10\log\sqlsrvr.log) you see one or both of the following errors:
Not enough User Connections (Sybase error 1601) No Pss structures available for new process
16
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.
16-7 s
s Troubleshooting
To determine the maximum number of user connections you can set for your system
1 Log into the database as the sa. 2 At the isql or xql prompt, enter: 1> select @@max_connections;
Results similar to the following are displayed:

------------253 return status 0, rows affected 1 3 Enter: 1> select count(*) from master..sysdevices where cntrltype = 0;

-------------3 return status 0, rows affected 1 4 Enter:
1> select count(*) from master..sysdevices where mirrorname is not NULL;

-------------0 return status 0, rows affected 1 5 Enter: 1> select count(*) from master..sysservers where srvname != @@servername;
s 16-8

-------------1 return status 0, rows affected 1
The maximum number of user connections that you can set is @@max_connections minus the sum of the results of the last three queries. In the example results to the above queries, the maximum number of user connections is 249. To increase the number of user connections:
1 At the isql or xql prompt, enter the following command to specify
the number of user connections you want:

1> sp_configure user connections, number;
Where number is the number of user connections you want.

WARNING If you set the number of user connections too high, the database will be unusable. At this point, you might not be able to rerun sp_configure to lower the number of user connections. To return the database to working order, you must run buildmaster or recover the database from backups. 2 Stop and restart the Event Server. Changes will not take effect until
you stop and restart the Event Server.
archive_events Fails (Bundled Sybase)

Symptom
16
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.
16-9 s
s Troubleshooting
To have Sybase truncate the transaction log

1 Log into the database server as the sa by entering the following
command (if you changed the sa password, use that one instead of sysadmin):
xql -Usa -Psysadmin 2 To check if the truncate option is set, enter the following commands: 1> sp_helpdb; 3 If trunc.log on chkpt is not set, enter one of the following commands
depending on your version of Sybase:

1> sp_dboption autosys, trunc log on chkpt, true; Or 1> sp_dboption autosys, trunc. log on chkpt., true; 4 Enter the following commands: 1> checkpoint; 1> exit
Resolution
To resolve the full transaction log problem
1 Log into the database server as the sa by entering the following
command (if you changed the sa password, use that one instead of sysadmin):
xql -Usa -Psysadmin 2 Use the autosys database by entering the following command: 1> use autosys; 3 Dump the transaction log by entering the following command: 1> dump transaction autosys with no_log;
s 16-10
4 If this fails, enter the following commands: 1> set rowcount 1; 1> dump transaction autosys with no_log;
Repeat step 4 and each time increase the rowcount incrementally. To begin with try doubling the number. If this fails at any time, decrease the rowcount and try again. When the rowcount is large, log out of the dataserver.
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
Event Server Unable to Extend Tablespace (Oracle)

Symptom
While running, AutoSys reports an error similar to the following, and then the Event Processor shuts down:
-- ORACLE error -01654: unable to extend index AUTOSYS.EVENT_GET1 by 512 in tablespace AUTOIN-06512: at "AUTOSYS.EVENT_STATE", line 34-06512: at line 1 OCI function OEXEC, OEXN (34) event: GRO0000mct02 Could NOT be marked as processed. ...
16
This error indicates that the Oracle tablespace it too small.
16-11 s
s Troubleshooting
Event Processor Troubleshooting
Resolution
Ask your database administrator to increase the size of the tablespace in your Oracle database. Then, restart your Event Processor.

%AUTOUSER%\out\event_demon.%AUTOSERV%
16
Output from the Event Processor is redirected into the following log file:
To view this file, issue the autosyslog -e command in an AutoSys Instance Command Prompt (which you open from the AutoSys program group). This command displays the Event Processors log file and shows each job-related event as it occurs. You can terminate this reporting at any time by pressing <Control+c>. 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.
Event Processor is Down

Symptoms
1 Jobs do not start. 2 When chk_auto_up is run, it returns a message similar to this
16
(assuming your Event Processor was installed on the machine EPhost):

Checking machine: EPhost No Event Processor is running on machine: EPhost. 3 The Event Processor log viewed with the autosyslog -e command has
not registered a date and time stamp for a period of time. The Event Processor log should register date and time stamps every minute.
s 16-12
Troubleshooting s Event Processor Troubleshooting
Resolution
Confirm that the Event Processor is down by performing one of the following actions:
s s s
Run the chk_auto_up utility. Execute an autosyslog -e command and check for date stamps. Look at the AutoSys Administrator Services screen. On the screen, select the Event Processor from the Service drop-down list, and check the Status traffic light icon and field.
If the Event Processor is indeed down, use the AutoSys Administrator Services screen to start the Event Processor. To do so, on the Services screen, select the Event Processor from the Service drop-down list, then click the Start Service button. (The Status field should change to Running, and the traffic light icon should turn green.) For information on the AutoSys Administrator, see Chapter 15, AutoSys Administrator.
Event Processor Will Not Start

Symptom
The autosyslog -e command displays a message indicating that the Time Key is not valid.
16
Resolution
Install your Time Key as described in Chapter 7, Entering License Keys in the AutoSys Installation and Getting Started Guide for Windows NT.
16-13 s
s Troubleshooting
Symptom
The autosyslog -e command displays messages indicating that it cannot connect to the AutoSys database.
Resolution
The AutoSys database service is down or there are problems with the Sybase installation. To fix the problem, follow the steps in the Resolution section of Event Server is Down (Sybase) on page 16-5. After you have done this, and the database service is accessible, the Event Processor should be able to connect.
Symptom
1 The autosyslog -e command displays messages indicating that the
Event Processor log file does not exist, or that no entries were made when the Event Processor service was started.
2 The Event Processor service does not remain running or never starts.
Resolution
Check for a file named event_demon.%AUTOSERV% in the directory specified in the Enterprise Wide Logging Directory field on the AutoSys Administrator Event Processor screen (by default, this directory is C:\tmp). If the file exists, view it by entering the following command:
type EVENT_DEMON.%AUTOSERV% | more
Correct the problems identified at the end of this file, and restart the Event Processor.
Note This file is appended to each time the Event Processor is
started.
s 16-14
Symptom
The Event Processor will not remain started and does not write log output to the %AUTOUSER%\out\event_demon.%AUTOSERV% file or to the event_demon.%AUTOSERV%.out file that is located in the directory specified in the Enterprise Wide Logging Directory field on the AutoSys Administrator Event Processor screen (by default, this directory is C:\tmp).
Resolution
This symptom could be attributed to a number of causes; therefore, the resolution depends on the NT Event Log message. The Event Log Viewer is located in the Administrative Tools program group.
NT Event Log Message Resolution
The log file %AUTOUSER%\out\event_demon.%AUTOSERV% is missing!
The Event Processor on the machine must have been started at least once or this message appears. If the Event Processor has been started, ensure that permissions are set on the log file that will allow a system program to read and write to the file.
Incorrect options have been set to event_demon. It must not have been set properly.
This occurs if you have modified the NT Registry so that the -A option is not used when starting the Event Processor service. To fix this problem with the NT Registry settings, you must uninstall AutoSys, and then reinstall AutoSys.
16-15 s
s Troubleshooting
The environment variable AUTOSYS is not set.
The %AUTOSYS% system environment variable is not available to the Event Processor. In the NT Control Panel, click on the System icon and ensure that the %AUTOSYS% environment variable is set properly in the System Environment Variables region. (You can also check the setting of this variable on the AutoSys Administrator System Information screen.)
The environment variable AUTOSYS is too long.
The %AUTOSYS% environment variable value is set to a path that is longer than 80 characters. Uninstall AutoSys, and reinstall it into a directory path that is fewer than 80 characters.
chk_auto_up process is missing. EP not operational. Call Tech support.
The Event Processor launches chk_auto_up upon initialization. That process has terminated without proper notification to the Event Processor. When this occurs, something is seriously wrong with your local system account. Try setting the Event Processor to log on as the administrator. If this is successful, you can run the Event Processor. However, it is recommended that you consider uninstalling AutoSys and reinstalling the software.
s 16-16
chk_auto_up is taking a while to complete...
The Event processor launches chk_auto_up upon initialization. That process is taking longer than 5 minutes to complete. This might occur on large or slow networks where chk_auto_up has to query every machine in the Authorized Event Processor Host Names list (which is located on the AutoSys Administrator Remote Agent screen). To test for this problem, run chk_auto_up in an AutoSys Instance Command Prompt window, and check how long it takes to complete. This event is only a warning, and the Event Processor will wait for this to complete before starting.
Wait for chk_auto_up process failed. <NT Error Code>
The Event processor launches chk_auto_up upon initialization. That process terminated prematurely with an NT error code. Verify that chk_auto_up.exe is located in the %AUTOSYS%\bin directory and has the proper permissions for system programs to execute.
The AutoSys environment has not been installed correctly.
The Event processor launches chk_auto_up upon initialization. That process reported that the AutoSys setup is incorrect. Uninstall AutoSys and reinstall the software.
An event processor is already running. We will not start another one.
When the Event Processor was started, it detected another Event Processor running with the same instance ID. Only one Event Processor can run in an instance. Either stop the other Event Processor, or do not attempt to start this Event Processor.
16-17 s
s Troubleshooting
Remote Agent Troubleshooting
Event processor cannot open its log file <EP logfile name>. Some directory in the path is not accessible to the SYSTEM.
The Event Processor was unable to create the normal log file named in the message. Ensure that the log file has permissions that will allow a system program to read and write to the file. Also check if the disk drive has run out of space.
Could not rename the LARGE event processor file:<EPFILENAME> to backup archive file:<EPBACKUPFILENAME>. Fix file and directory permissions so accessible by SYSTEM, or remove the files.
NT Event Log Message
Resolution
When the Event processor starts it looks at the size of the EPFILENAME log file. If this file is greater than 256Kb, the Event Processor will attempt to rename it to EPBACKUPFILENAME and create a new EPFILENAME log file. If the Event Processor is unable to do this, check that EPFILENAME has permissions that will allow a system program to Read and Write the file. Also check if the disk drive has run out of space.

Remote Agent Verification
If you suspect problems with the Remote Agent, you can use autoping to verify your suspicions.
16
16
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.
s 16-18
Troubleshooting s Remote Agent Troubleshooting
The Remote Agent writes RUNNING and completion statuses directly to the Event Server.
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. This command captures the output from the attempted database connection, displays it, and includes it in the alarm, if one is generated (use the -A argument to generate an alarm if problems are found).
autoping -m venice -D AutoPinging Machine [venice] AND checking the Remote Agent's DB Access. AutoPing WAS SUCCESSFUL!
Remote Agent Will Not Start

The symptoms in this section are similar and result from network problems.
16
Symptom
The autosyslog -e command displays a message like this:
Attempting to connect to AutoSys Remote Agent Service on socket=5280: Interrupted function. Could NOT connect to machine: spartacus
Resolution
Either there is a network communication problem, or the client machine is down. You must resolve the network or machine problems before jobs can run on that machine.
16-19 s
s Troubleshooting
Symptom
The autosyslog -e command displays a message like this:
Attempting to connect to AutoSys Remote Agent Service on socket=5280: Connection Refused Could NOT connect to machine: spartacus. The Remote Agent may not be installed properly.
Resolution
Either the Remote Agent Service is not started, or AutoSys was not installed or configured properly so that the Remote Agent and Event Processor use different port numbers. First, verify that the Remote Agent Service is started. To do this, open the AutoSys Administrator from the AutoSys program group, and follow these steps:
1 Select the Computer and AutoSys Instance, and click OK. This action
enables the AutoSys menu items, and their corresponding tool bar buttons.
2 Move to the Services screen by selecting Services from the AutoSys
menu, or clicking the Services button (traffic light) on the tool bar.
3 Select the Remote Agent from the Service drop-down list. Check the
Status using the traffic light icon and the Status field.
4 If the status is Stopped, click the Start Service button.
After the Remote Agent Service is started, verify that the port numbers are synchronized using the AutoSys Administrator. To do so, follow these steps:
1 On the machine where the Remote Agent Service is located, start the
AutoSys Administrator and check the Remote Agent Port Number, which is located on the Remote Agent screen.
s 16-20
2 On the Event Processor machine, check the Remote Agent Port
Number in the same fashion.

3 If the Port Number settings are different, synchronize the numbers by
modifying the incorrect one. For information on the AutoSys Administrator, see Chapter 15, AutoSys Administrator.
Remote Agent Starts, Command RunsNo RUNNING Event is Sent

Symptoms
1 Job is stuck in STARTING state.
16
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 and Microsoft SQL Server databases, this connection problem is usually because the specified database settings are different from those used by the AutoSys Event Processor. 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.
16-21 s
s Troubleshooting
To verify the problem, look in the AutoRemoteDir\auto_rem* file for this job (the AutoRemoteDir value is the Local Agent Logging Directory value, specified in the AutoSys Administrator Remote Agent screen). You can accomplish this by issuing the following command on the machine where the job is supposed to have run (using an AutoSys Instance Command Prompt window):
autosyslog -J job_name
where job_name is the name of the job in question. 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.) To determine that all the database settings are correct, check the settings on the AutoSys Administrator Event Server screen for both the Remote Agent and the Event Processor machines. Verify that the Remote Agents Event Server Name, Database, and Port number settings are the same as those on the Event Processor machine settings. In addition, make sure that the database settings (as determined by Sybase, Oracle, or Microsoft SQL Server) are the same as the settings AutoSys is using. That is, check the database settings against the settings on the AutoSys Administrator Event Server screen. For Sybase, first make sure that the Sybase SQL.INI file exists, then make sure that the settings are the same as the settings AutoSys is using. This file is located in the %SYBASE%\INI directory. To determine the setting AutoSys is using for the %SYBASE% variable, look at the Control Panel System dialog.
s 16-22
For Microsoft SQL Server databases, check the Microsoft SQL Server database settings using the SQL Enterprise Manager. In addition, for Microsoft SQL Server database, you must make sure that one of the following is true:
s s
All AutoSys machines are on the same NT domain. User accounts have been added on the database machine(s) for all AutoSys users.
If you do not configure your Microsoft SQL Server(s) in one of these ways, your jobs will go into Starting state, and will seem to remain in this condition. This behavior results from the fact that the Remote Agent cannot write the status back to the Microsoft SQL Server database(s), because the owner of the job does not have proper permissions on that database machine. If you are using Oracle, check for the following:
1 Check that the Oracle TNS names file, TNSNAMES.ORA, exists, is
readable, and contains the correct information for the Event Server. By default, the TNS names file is in the following location:
\ORANT\NETWORK\ADMIN\TNSNAMES.ORA 2 Check that the Oracle TNS names file has a SQL*Net V2 formatted
entry for the Event Server. For information on using the AutoSys Administrator, see Chapter 15, AutoSys Administrator. Testing the Setup To test that everything is set up properly, try to log onto the Event Server from the client machine, using the xql utility (for Sybase), the SQL*Plus command language interface (for Oracle), or the ISQL/w graphical query interface (for Microsoft SQL Server). When you log onto the Event Server, use the autosys user and password.
16-23 s
s Troubleshooting
Job Failure Troubleshooting
xql Will Not Start (Sybase Only)

Symptom
From the remote machine, xql returns the following message:
DB-Library error: dbproc NULL Error in SybInit: dbopen failed
16
Resolution
Check the following:
1 Determine if the dataserver is started and running, and start it if it is
not running.
2 Verify that the DSQUERY environment is set to the proper dataserver. Or
Run xql with the -S and -D options to specify the correct dataserver and database.
3 If a fully qualified xql statement still fails, then it is a problem with
the interfaces file. For more information about dealing with this file, see the Resolution section of Remote Agent Starts, Command RunsNo RUNNING Event is Sent on page 16-21.

Remote Agent Will Start - Command Will Not Run
Each time the Remote Agent is started on a machine, it creates the following log file:
AutoRemoteDir\auto_rem.pid
16
16
s 16-24
Troubleshooting s Job Failure Troubleshooting
where:
AutoRemoteDir
Is the Remote Agent Local Agent Logging Directory specified in the AutoSys Administrator Remote Agent screen, or at installation time. By default, this directory is the C:\AUTOSYS.INSTANCE\tmp for single instance installations, or C:\AUTOSYS\INSTANCE.tmp for multiple instance installations.
auto_rem.pid
Is the process ID of the Remote Agent. After the Remote Agent receives its instructions from the Event Processor, it renames this file to give it a unique name. This is the form of the new filename:
AutoRemoteDir\auto_rem.joid.run_num.ntry
where:
joid
Is the job object ID.

run_num
Is the run job run number.

ntry
Is the number of tries or restarts. 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.
16-25 s
s Troubleshooting
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 The Clean Temporary Files setting in the AutoSys Administrator Event Processor screen specifies whether the Remote Agent log files are to be cleaned up at the completion of a job. If this setting is on (the default setting), the file is removed when a job completes normally. If the job fails for some reason, the log file is not deleted, regardless of the setting. To turn off automatic deletion of the Remote Agent log files, deselect the Clean Temporary Files box on the AutoSys Administrator Event Processor screen.
For information on the AutoSys Administrator, see Chapter 15, AutoSys Administrator.
Symptoms
The Event Processor log as viewed with the autosyslog -e command displays a message like this:
Agent remote authentication! Error:<Remote Authentication has FAILED for User: USER@HOST on machine:RAHOST.>
In addition, the Remote Agent agent log as viewed with the autorep -J job_name command might display the following message:
Remote Authentication has FAILED for User:USER@HOST on machine:RAHOST. Message: Couldnt find valid entry in security key.
Resolution
The job is trying to run on a host which is different than the host or domain on which the job was defined, and AutoSys security (Remote Agent User Authentication) has denied access for the host or domain on
s 16-26
which the job was defined. In this case, the job was defined on the HOST host, and is trying to run on the RAHOST host. For this example, you can resolve the problem in one of the following ways:
s
The AutoSys Edit Superuser can log on to the RAHOST machine and add a Trusted Host entry for the HOST host to the Trusted Hosts list on the AutoSys Administrator Security screen. The USER user can log on to the RAHOST machine and add a Trusted User entry for the USER@HOST user to the Trusted Users list on the AutoSys Administrator Security screen.
Symptoms
The Event Processor log as viewed with the autosyslog -e command displays a message similar to one of the following:
Owner UserId/Password error! ERROR: The password specified for USER@HOSR_OR_DOMAIN is invalid! Run "autosys_secure" to enter the correct password. Or Owner UserId/Password error! ERROR: No valid password was found for USER@HOST or USER@DOMAIN. Cannot run job for user USER! Run "autosys_secure" to enter the user password.
In addition, the Remote Agent agent log as viewed with the autorep -J job_name command could displays a message similar to one of the following:
The password specified for USER@DOMAIN is invalid! Run "autosys_secure" to enter the correct password. Or No valid password was found for USER@HOST or USER@DOMAIN. Cannot run job for user USER! Run "autosys_secure" to enter the user password.
16-27 s
s Troubleshooting
Resolution
In this example the password for the user@host_or_domain either does not exist or is not valid. To fix this problem, run the autosys_secure command to enter or change the user ID and password. For more information, see the autosys_secure section in Chapter 1, AutoSys Commands, of the AutoSys Reference Guide for Windows NT.
Symptoms
The Event Processor log as viewed with the autosyslog -e command indicates that the job immediately returned as FAILURE.
Resolution
A variety of things could be wrong. To determine what is wrong, look for error messages by running the autosyslog -e command on the Event Processor machine, and the autorep -J job_name command on the machine where the job was supposed to have run. For example, if the jobs standard out file was not writable, a message indicating this would appear in the Event Processor log. You should also verify the following items:
s
The default profile or the jobs specified user-defined profile has defined the proper job environment. In particular, ensure that the path variable, if defined in a job profile, is correct. It is always a good idea to include %PATH% in any job profile that defines a path variable. This will ensure that all system path directories are accessible. The file system that the job command is on is accessible from this machine. The system permissions are correct for the job command to be executed. The permissions are correct on any standard input and output files specified for re-direction.
s 16-28
Note A valuable debugging technique is to specify a file to be used for standard output and standard error for a job that is having run problems. If there are any command problems, most error messages will be in that file.
For information on defining job profiles, see the Job Profiles section in Chapter 3, AutoSys Jobs.
Symptoms
When a job starts, the Event Processor log as viewed with the autosyslog -e command displays a message similar to the following:
Read Stream Socket Failed
You can also see this message with the Event Report tool (which you can open from the Scheduler Console or Alarm Manager).
Resolution
There are three possible causes of this error:
1 An invalid Path statement 2 Performance problems with the network or machine 3 Network problems
Almost always, a read stream socket failure error is caused by an invalid Path statement for the AutoSys directory. In the NT Control Panel System dialog, select the Environment tab and check that all the directories in the System Variables list for the Path are valid on the hard drive. Also, check for invalid characters and syntax in the Path statement. A semicolon, which separates individual directories, is often entered incorrectly. Check for two semicolons in a row or for a trailing semicolon at the end of the Path. A network drive before the AutoSys directory is also considered an invalid character in the Path. The AutoSys directory
16-29 s
s Troubleshooting
must precede any network drives. Correct any Path problems and reboot the machine. You must reboot the machine after making changes to the Path. Occasionally, performance problems on the network or machine might cause the read stream socket failure error. The network might be down or slow due to too much traffic. The machine might be under powered or you are trying to do too much on the machine at one time.
s 16-30
A
Integrating AutoSys with Zeke and AutoSys/Team Agent
This appendix describes how to integrate AutoSys with Zeke and AutoSys/Team Agent components for an advanced AutoSys configuration.
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-3 Definition of Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-3 Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-4 Job Scheduling for the Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-5 Installing and Configuring for Enterprise Job Scheduling . . . . . . . . . . . . . . . . . A-6 Install the Basic AutoSys Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-6 Install AutoSuite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-7 Configure the AutoSys Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-8 Initializing the Communication Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-12 License Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-14 Restart the Event Processor and Start the AutoSuite Service . . . . . . . . . . . . . A-14
A-1 s
s Integrating AutoSys with Zeke and AutoSys/Team Agent
About the oasis_broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-15 AutoSys and Zeke Cross-Platform Dependencies . . . . . . . . . . . . . . . . . . . . . . . .A-16 Job Scheduler Interdependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-17 Notation for Cross-Platform Job Dependencies . . . . . . . . . . . . . . . . . . . . . . . .A-18 Naming Conventions for AutoSys/Zeke Cross-Platform Jobs . . . . . . . . . . . . .A-19 Running AutoSys Jobs on the Team Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-20 Running Jobs on Team Agent Managed Machines . . . . . . . . . . . . . . . . . . . . .A-21 Defining Team Agent Machines to AutoSys . . . . . . . . . . . . . . . . . . . . . . . . . . .A-22 Team Agent Machine in an AutoSys Job Definition . . . . . . . . . . . . . . . . . . . . .A-23 Database Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-23 Logs Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-23 Zeke and Team Agent Job Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-23 Unsupported Attributes for Zeke or Team Agent Jobs . . . . . . . . . . . . . . . . . . .A-24 Cross-Platform Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-26
s A-2
Integrating AutoSys with Zeke and AutoSys/Team Agent s Introduction
Introduction
AutoSys enterprise-wide scheduling lets you integrate AutoSys jobs with Zeke and the AutoSys/Team Agent. The following types of integration are supported:
s
AutoSys jobs can be defined to conditionally start based on the status of a Zeke job. AutoSys can schedule jobs to run on a Team Agent machine.
Using cross-platform job dependency notation, AutoSys jobs can be defined to conditionally start based on the status of a Zeke job running on a mainframe. You can also create AutoSys jobs that will run on a Team Agent machine (if the Team Agent machine is defined to AutoSys).
Definition of Terms
The following terms are used in this appendix: AutoSys Zeke Team Agent A job scheduler that runs on UNIX and NT. A mainframe scheduler that runs on MVS and VSE environments.
Team Agent is similar in function to an AutoSys client machine (Remote Agent). Jobs from Zeke or AutoSys can directly schedule cross-platform jobs on a machine that is running Team Agent. AutoSys supports Zeke and Team Agent integration on a subset of the operating platforms on which Team Agent runs, as specified in the AutoSys release notes. The term Team Agent is used as an abbreviation for the AutoSys/Team Agent product.
A-3 s

Introduction
Cross-instance job dependency Cross-platform job dependency
A dependency between jobs running on different instances of AutoSys. A dependency between jobs running on different platforms. For example, an AutoSys job running on a UNIX or NT machine can be dependent on a Zeke job running on a mainframe.
Related Documentation
The information presented in this appendix supplements the following documents:
s s
PLATINUM AutoSys User Guide for Windows NT PLATINUM AutoSys Installation and Getting Started Guide for Windows NT PLATINUM AutoSys/Team Agent Reference Guide (PLATINUM AutoAction Reference Guide) PLATINUM Zeke Product Reference Guide PLATINUM Zeke Users Guide
s s
s A-4
Integrating AutoSys with Zeke and AutoSys/Team Agent s Job Scheduling for the Enterprise
Job Scheduling for the Enterprise

PLATINUM AutoSys with Zeke and Team Agent let you schedule or reroute jobs from multiple sources throughout the enterprise. To accomplish this, the following elements must be present on the AutoSys machine: oasis_broker communication components An AutoSys process that communicates with Zeke or Team Agent. A collection of executables used to route information from Zeke or Team Agent back to the AutoSys Event Processor. These executables are listed in the Configure the Communication Components on page A-12.
In addition, to utilize cross-platform job dependencies with a Zeke machine, the following must be present on your Zeke machine: OASIS Open Architecture System Integration Solution (OASIS) is a network interface between the Zeke software and TCP/IP transport mechanisms. It provides cross-platform communication between Zeke and AutoSys.
The next section explains how to install and configure these components. To learn how to implement enterprise job scheduling, see AutoSys and Zeke Cross-Platform Dependencies on page A-16 and Running AutoSys Jobs on the Team Agent on page A-20.
A-5 s

Installing and Configuring for Enterprise Job Scheduling

Before you can install and configure the components that must be present to implement enterprise job scheduling, you must have installed the Zeke and Team Agent components as instructed by your Zeke and Team Agent installation documentation, and the AutoSys software as instructed in the AutoSys Installation and Getting Started Guide for Windows NT. The required software and version levels are listed in the following table:
AutoSys
s
Zeke
s
Team Agent
s s
AutoSys version 3.4 for Windows NT AutoSuite media
OASIS version 1.1 or later ACF/VTAM level V3R4M0 Zeke version 4.2 PTF193 or later
TCP/IP AutoSys/Team Agent version 1.2
Note AutoSys does not support Zeke or Team Agent licensing and security, or the Team Agent GUIs, as implemented in Team Agent version 1.2.
Install the Basic AutoSys Release

If it is not already installed, install the basic AutoSys product as described in the AutoSys Installation and Getting Started Guide for Windows NT.
s A-6
Integrating AutoSys with Zeke and AutoSys/Team Agent s Installing and Configuring for Enterprise Job Scheduling
Install AutoSuite
To install the components required for AutoSys integration with Zeke and Team Agent, you must run the AutoSuite setup program. You must run this setup program on the machine where you installed the AutoSys Event Processor for the instance. Each installation must be associated with a specific AutoSys instance. AutoSuite works with a specific Event Processor to manage the communication between AutoSys and Zeke or Team Agent.
Note If you have multiple instances of AutoSys for NT installed on the same machine, be sure that you are operating on the correct instance. Be sure that you are using the appropriate AutoSys Instance Command Prompt, and that you are connecting to the appropriate instance when using the AutoSys Administrator.
To install AutoSuite
1 Shutdown the AutoSys Event Processor by issuing the following
command in an AutoSys Instance Command Prompt (you must be the AutoSys Exec Superuser to do this):
sendevent -E STOP_DEMON 2 If any Windows NT programs are currently running, exit them. 3 Log onto this machine as a user with NT Administrators group
privileges.
4 Insert the media into the appropriate drive and start the AutoSuite setup program (setup.exe), located on Disk 1. You can run setup by double-clicking the setup.exe file or you can run it from the File
Manager by entering the command in the Run dialogs Command Line field.
A-7 s

Note For help while installing this program, refer to the Installing Team Agent chapter of the PLATINUM AutoSys/Team Agent for Windows NT Reference Guide on the PLATINUM documentation CD. 5 Follow the directions on the setup program screens, and enter the
requested information.
Note On the AutoSys Instance Information screen, supply the name of the AutoSys instance that you want to associate with the integration components. 6 Run the installation process and, when prompted, supply the
appropriate disk.
7 When the installation process is complete you must reboot the
machine.
8 After you reboot the machine, use the AutoSys Administrator Event
Processor to change the ZTeam Job Support setting to on (checked).

9 From the AutoSys Administrator Services screen, start the Event
Processor.
Configure the AutoSys Machine

In addition to the basic AutoSys installation, the following procedures must be performed on the AutoSys machine (that is, the machine on which the AutoSys Event Processor was installed):
s A-8
The following entries were set by default when you ran the AutoSuite setup program:
netregid: defprotocol: network: node: NETREGID tcp na na
autosys_communications:AutoSys-OASIS.INS
where:
NETREGID
Is the first 8 characters of the hostname, in uppercase.

INS
Is the three-letter uppercase ID (for example, ACE) for the AutoSys instance that will communicate with the Zeke scheduling software. If you want to change any of these default settings, you must directly edit the Windows NT Registry, in the following location:
HKEY_LOCAL_MACHINE\SOFTWARE\Platinum\AutoSuite
s
The ZTEAMDIR environment variable is set when you run the AutoSuite setup program. By default, it is set to the AutoSys install directory specified when you installed AutoSys (for example, for an instance name of ACE, ZTEAMDIR would be set to AutoSys.ACE\AutoSuite).
Note If you are using an existing installation of Team Agent for NT, the ZTEAMDIR environment variable is set to the value set during the Team Agent installation. For example: set ZTEAMDIR C:\user\team
A-9 s

Set the ZTeam Job Support Parameter

To run jobs directly on a Team Agent, enable Team Agent job support by going to the AutoSys Administrator Event Processor Maintenance screen and selecting the ZTeam Job Support option. This indicates that this AutoSys instance can dispatch jobs to a Team Agent.
Create the config.EXTERNAL File

To enable cross-platform dependencies with Zeke, create a file named config.EXTERNAL in the %AUTOUSER% directory. In config.EXTERNAL, add an entry similar to the following for each Zeke scheduling system for which cross-platform dependencies will be exchanged:
INS:ZEKE=OASIShost
where:
INS
Is the three-letter uppercase identifier for the Zeke instance; for example, ZEK. This is the name by which the Zeke application will be known to AutoSys.
ZEKE
Is a constant.
OASIShost
Is the OASIS network registration identifier (NETREGID) for the Zeke scheduling system. This identifier can be up to eight uppercase alpha/numeric characters. For example:
ZEK:ZEKE=TESTZEKE Note The config.EXTERNAL file can contain a maximum of 249
entries.
s A-10
Ensure Consistent Integration Settings

When the Event Processor starts up, it checks the setting of the ZTeam Job Support field in the AutoSys Administrator Event Processor Maintenance screen. If the parameter setting is inconsistent with the other integration settings, the Event Processor will detect this disparity and shut down. Therefore it is important to ensure the settings are consistent. That is, to enable communication with Zeke and Team Agent, the following must be true:
s
ZTeam Job Support must be selected in the AutoSys Administrator Event Processor Maintenance screen. variable is defined.
s ZTEAMDIR environment s
Zeke instance(s) are defined in the config.EXTERNAL file (if you want to communicate with Zeke).
If you want to disable only Zeke communication, you must:

s
Comment out any Zeke instances in the config.EXTERNAL file.
If you want to disable both Team Agent and Zeke communication, you must do the following:
s
Uncheck the ZTeam Job Support checkbox on the AutoSys Administrator Event Processor Maintenance screen. Unset the ZTEAMDIR environment variable. Comment out any Zeke instances in the config.EXTERNAL file.
s s
A-11 s

Initializing the Communication Components
Configure the Communication Components

The following communication components are installed when you run the AutoSuite setup program on the machine on which the AutoSys Event Processor was installed:
anetping anetjob anetcmd aappls zteamsrv autoactionnt
Refer to the PLATINUM AutoSys/Team Agent Reference Guide for details on the usage of these commands. Refer to the PLATINUM AutoSys/Team Agent for Windows NT Reference Guide for details on AutoSuite. When you ran the AutoSuite setup program, the following entries were added to the %SYSROOT%\system32\drivers\etc\services directory.
zteamclnt zteamsrvr oasisbroker 7701/tcp 7702/tcp 7998/tcp zclnt zsrvr oasibrkr
You do not have to modify these settings, unless you want to change the default values. The AutoSuite service must be manually started. To make this service start automatically, go to the Program Manager Control Panel and change the AutoSuite setting in the Services applet. (You must reboot your machine for the change to take effect.)

The communication components on the AutoSys machine (the machine on which the AutoSys Event Processor was installed) must be registered in the Application Registry Table. The aappls command allows you to monitor or browse the current list of applications registered with the local Team Agent system.
s A-12
Integrating AutoSys with Zeke and AutoSys/Team Agent s Initializing the Communication Components
Note We recommend that you always stop the AutoSys Event Processor before running the aappls -i command.
To initialize the communication components

1 To clear all applications from the Application Registry Table and
restore the local Team Agent product to the local system, execute the following command:
%AUTOSYS%\bin\aappls -i 2 Register the adjacent Team Agent or Zeke by executing the following
command:
%AUTOSYS%\bin\anetping -p tcp -t ADDRESS
Where ADDRESS is the Zeke mainframes TCP/IP address or the UNIX or NT hostname.
3 Confirm that the NETREGID (or Team Agent Application) that you want
to register is recorded in the Application Registry Table by executing the following command:
%AUTOSYS%\bin\aappls
This displays the Application Registry Table, as shown in Figure A-1

Application | Prod | Last Activity | In | Out =================================================================== PLATHPUX ZTEM Thu June 05 12:08:20 1997 0 0
Figure A-1 Example Application Registry Table display
A-13 s

License Keys
AutoSys client license keys are required for Team Agent machines in order for AutoSys to run jobs on those machines. The client license key is tied to a specific machine. It is generated by the Customer Service department at the AutoSystems Development Lab based on the host name and host id of the client machine. For Team Agent machines, the host name is the NETREGID and the host id is always 0 (zero). When you supply the above information to the Customer Service department, 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: NETREGID Hostid: 0 KEY: IIJJKKLLMMNNOOPP ***** New Key ADDED! ***** KEY Type: [(c)lient, (s)erver, (t)ime, (x)pert]:<Return>
Restart the Event Processor and Start the AutoSuite Service

Now you can start the Event Processor using the AutoSys Administrator Services screen and start the AutoSuite service from the Services applet.
s A-14
Integrating AutoSys with Zeke and AutoSys/Team Agent s About the oasis_broker
About the oasis_broker

Communication between AutoSys and Zeke or a Team Agent is facilitated by the oasis_broker. It is a necessary component for cross-platform communication because contacting and passing information to Zeke or a Team Agent could take several minutes. Letting the oasis_broker handle that exchange frees the Event Processor to handle other events. The Event Processor inserts entries into the ext_job and req_job tables in the AutoSys database for completion events communicated to it by the oasis_broker. When the Event Processor is started, it checks if the ZTeam Job Support field in the AutoSys Administrator Event Processor Maintenance screen is enabled and if the ZTEAMDIR variable is set. If they are, the Event Processor starts the oasis_broker automatically. If the Event Processor is stopped, or goes down for any reason, the oasis_broker will also stop running. The only way to bring up the oasis_broker is to restart the Event Processor. If the Event Processor and the oasis_broker go down while a Team Agent or Zeke job finishes, the completion event will be lost. That information is sent only once and is not saved. If this happens, the only way to change the status of the job is to change it manually. (You must have execute permission on a job in order to change its status.) To change the status of a job, use the AutoSys sendevent command, as shown in the following example:
sendevent -E CHANGE_STATUS -J job_name -s status
You can also use the Send Event dialog to change the status of a job. This dialog is accessed from the AutoSys Scheduler Console.
A-15 s

AutoSys and Zeke Cross-Platform Dependencies

AutoSys jobs can have dependencies on jobs managed by PLATINUMs Zeke scheduling software running in the MVS and VSE environments. 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 Zeke job running on a mainframe system.
AutoSys UNIX or NT NETREGID: MYMACHIN Instance: ACE
Communication Components * O A S I Z E K E Job
MVS NETREGID: MVSZEKE
Event Server
Event Processor
S oasis_broker
Team Agent (Remote)
* Communication components are listed in Configure the Communication Components on page A-12.
Figure A-2 AutoSys and Zeke (MVS) cross-platform configuration
s A-16
Integrating AutoSys with Zeke and AutoSys/Team Agent s AutoSys and Zeke Cross-Platform Dependencies
In Figure A-2, communication between AutoSys and Zeke is handled by the oasis_broker and the communication components.
s
The AutoSys Event Processor communicates with Zeke through an AutoSys process called the oasis_broker, which communicates with Zeke through the OASIS network interface. OASIS routes Zeke job information back to AutoSys via the communication components.
In addition, a file named config.EXTERNAL is present on the machine on which the AutoSys Event Processor was installed. In this file, the mainframe has been identified with a three-letter uppercase instance name, as described in Create the config.EXTERNAL File on page A-10.
Job Scheduler Interdependencies

AutoSys jobs can be dependent on the status of Zeke jobs and Zeke jobs can be dependent on the status of AutoSys jobs. For details on how to implement this with the Zeke job scheduler, refer to your Zeke documentation. For AutoSys jobs, this type of cross-platform dependency is described below. To create job scheduler interdependencies
1 AutoSys sends a request to the oasis_broker for the status of a Zeke
job running on a mainframe.

2 The oasis_broker passes the request to the MVS OASIS. 3 The MVS OASIS informs Zeke of the request. Zeke registers the
request.
4 The job runs as scheduled by the Zeke job scheduler. Zeke can run the
job on the mainframe or remotely through a Team Agent.

5 The completion status of the job is passed to the MVS OASIS by the
jobs parent (Zeke or the remote Team Agent).
A-17 s

6 The MVS OASIS sends the status of the job to the communication
component on the AutoSys machine.

7 The communication component sends the status to the oasis_broker. 8 The oasis_broker communicates the status to the Event Processor. 9 The Event Processor starts the AutoSys job that is dependent on the
completion of the Zeke job.
Notation for Cross-Platform Job Dependencies

To define a cross-platform job dependency, you use the following notation:
job_nameÎNS
Where INS is a three-letter uppercase identifier of the instance on which the job is running. The caret symbol (^) before the instance name indicates that the job resides on a different instance of AutoSys. From JIL, you enter this in the condition job attribute, as shown in the following example:
condition: success(job_nameÎNS)
From the AutoSys GUIs, you enter this information in the Dependencies field of the Job Editor screen. You can use the following statuses in the condition attribute of an AutoSys job definition dependent on a Zeke job:
s s s s
success terminated done notrunning
s A-18
Integrating AutoSys with Zeke and AutoSys/Team Agent s AutoSys and Zeke Cross-Platform Dependencies
AutoSys and Zeke Cross-Platform Dependency Example

Below is an example of an AutoSys job that will start only upon the successful completion of jobA which is a Zeke job that runs on a mainframe:
condition: success(jobA^ZEK)
where: success(jobA^ZEK) specifies the successful completion of a Zeke job named jobA running on a mainframe specified with the three-letter ID of ZEK.
Naming Conventions for AutoSys/Zeke Cross-Platform Jobs

Because of naming limitations in the MVS, VSE, and AS/400 environments, the names of jobs specified as job dependencies between AutoSys and Zeke must follow these guidelines:
s
The first character of a job name must be an uppercase alpha character or one of the following characters: #, @ $. The remaining characters in the job name can be any combination of uppercase alphabetic characters, numbers, or #, @ $ characters. Job names can be no longer than eight characters. All alphabetic characters must be in uppercase.
s s
Note These limitations do not apply to all AutoSys jobs, only to jobs
that will be referenced to Zeke. For more information on cross-instance job dependencies, see the Cross-Instance Job Dependencies section of Chapter 3, AutoSys Jobs.
A-19 s

Running AutoSys Jobs on the Team Agent

AutoSys can directly schedule jobs on a machine that is running the Team Agent, assuming the machine running the Team Agent has been defined to AutoSys. In the following example configuration, the Team Agent is running on an AS/400 machine. The AutoSys and Team Agent integration is supported on other operating platforms as well.
AutoSys UNIX or NT NETREGID: MYMACHIN Instance: ACE
Communication Components * T E A M A G E N T Job
AS/400 NETREGID = ZASYS400
Event Server
Event Processor
oasis_broker
* Communication components are listed in the Configure the Communication Components on page A-12.
Figure A-3 AutoSys and Team Agent configuration
In Figure A-3, communication between AutoSys and the Team Agent is handled by the oasis_broker and the communication components.
s
The AutoSys Event Processor communicates with the Team Agent through an AutoSys process called the oasis_broker. The communication components running on the AutoSys machine receive information from the Team Agent and pass it to the oasis_broker. Team Agent (which in this example is running on the AS/400 platform) is analogous to an AutoSys Remote Agent.
s A-20
Integrating AutoSys with Zeke and AutoSys/Team Agent s Running AutoSys Jobs on the Team Agent
Running Jobs on Team Agent Managed Machines

The process by which AutoSys can run jobs directly on a Team Agent managed machine is described below. To run jobs on Team Agent managed machine
1 The Event Processor sends the job information to the oasis_broker
and the job changes to STARTING status.

2 The oasis_broker passes the information to the Team Agent, which
starts the job.

3 The Team Agent passes the information that the job is running (BOJ
event) to the communication component on the AutoSys machine.

4 The communication component on the AutoSys machine informs the oasis_broker of the change. 5 The oasis_broker informs the Event Processor; the job changes to
RUNNING status.
6 When the job exits, the Team Agent client traps the return code and
passes the information that the job is finished to the communication component on the AutoSys machine.
7 The communication component on the AutoSys machine informs the oasis_broker of the change. 8 The oasis_broker informs the Event Processor; the job changes to a
status of either SUCCESS (if the job exited with a normal end of job code, EOJ) or TERMINATED (if the job exited with an abnormal end of job code, AEOJ).
A-21 s

Defining Team Agent Machines to AutoSys

Before you can run AutoSys jobs on a Team Agent machine, you must first define the Team Agent machine to AutoSys using the insert_machine sub-command. This command adds a new machine definition to the AutoSys database. It is described in detail in Chapter 10, Load Balancing and Queuing Jobs. This section pertains specifically to defining a Team Agent machine. To define a Team Agent machine, follow this example:
insert_machine: NETREGID type: z
where:
NETREGID
Is the Team Agents NETREGID, which must be recorded in the Application Registry Table.
type: z
Indicates that the machine type is a Team Agent.

Note Team Agent managed machines cannot be part of a virtual machine. job_load, max_load, and factor attributes are not supported
for Team Agent managed machines. For example, to define the machine shown in Figure A-3 on page page A-20, which has a NETREGID of ZASYS400, you would specify the following:
insert_machine: ZASYS400 type: z
s A-22
Integrating AutoSys with Zeke and AutoSys/Team Agent s Database Tables
Team Agent Machine in an AutoSys Job Definition

Once you have defined a Team Agent machine to AutoSys and that machine is recorded in the Application Registry Table, you can specify that machine in an AutoSys job definition, using the machine job attribute. For example:
insert_job: TEAMJOB owner: bob@sahara machine: ZASYS400 command: echo test
The owner identified in the owner attribute of the job definition must have an account on the target Team Agent machine. The account must match the owner name exactly in order for the job to run. If the owner is specified as user@host_or_domain), everything after the @ is ignored. (If necessary, the AutoSys Edit Superuser can change the owner of a job.)
Database Tables
To implement cross-platform functionality, two new AutoSys tables were created: ext_job and req_job. These tables contain job status events for jobs that are shared between instances.
Logs Information
Log information is written to the Log folder in %AUTOSYS%\AutoSuite.
Zeke and Team Agent Job Statuses

The valid statuses that AutoSys can get for Zeke and Team Agent managed jobs are: STARTING The job has been passed from the Event Processor to the
oasis_broker.
A-23 s

Unsupported Attributes for Zeke or Team Agent Jobs
RUNNING The job has started and a BOJ (Beginning Of Job) event has been sent back to the oasis_broker. SUCCESS The job has ended and an EOJ (End Of Job) event has been passed back to the oasis_broker. TERMINATED The job has ended and an AEOJ (Abnormal End Of Job) event has been sent back to the oasis_broker. Any Zeke or Team Agent managed job without a return code of zero will be considered TERMINATED.
Unsupported Attributes for Zeke or Team Agent Jobs

The following AutoSys attributes are not supported for Zeke or Team Agent managed jobs. If specified, they will be ignored. The jil attribute is listed on the left and the corresponding Job Editor field is shown on the right.
chk_files
Resource/Profile tab: Resource Check - File System Space... Command Info tab: Heartbeat Interval (mins) Command Info tab: Job Load Alarms/Terminators tab: If this box fails, terminate the job New Job or Save dialogs: Job Type File Watcher
heartbeat_interval job_load job_terminator
job_type:f
s A-24
Integrating AutoSys with Zeke and AutoSys/Team Agent s Unsupported Attributes for Zeke or Team Agent Jobs
max_exit_success
Command Info tab: Maximum Exit Code for SUCCESS Misc tab: Number of times to restart this job after a fAILURE Command Info tab: Que Priority Resource/Profile tab: Job Environment Profile Command Info tab: File to redirect to standard error Command Info tab: File to redirect to standard input Command Info tab: File to redirect to standard output Alarms/Terminators tab: Terminate this job n minutes after starting Basic Scheduling tab for File Watcher Jobs: File to watch Minimum file size (in bytes)
n_retrys
priority profile std_err_file
std_in_file
std_out_file
term_run_time
watch_file
watch_file_min_size Basic Scheduling tab for File Watcher Jobs: watch_interval
Basic Scheduling tab for File Watcher Jobs: Time Interval (secs) to determine steady state
A-25 s

Cross-Platform Limitations
Cross-Platform Limitations
When you running across platforms, keep the following in mind:
s
If you are running a Shadow Event Processor, cross-platform dependencies will be lost if the Shadow Event Processor takes over. The chase and autoping commands cannot return any information on Zeke or Team Agent jobs and machines. Remote Authentication is not supported for Zeke or Team Agent jobs. The following events cannot be executed on a Zeke or Team Agent job:
KILLJOB CHANGE_PRIORITY SEND_SIGNAL
s s
s A-26
Index
A
Action Area Layout dialog 11-52 ACTIVATED status 3-15 after_time report attribute 13-18 Alarm Manager 6-5 about 12-3 acknowledging alarms 12-3 Alarm List 12-5 Alarm Selection dialog 12-11 Select by State region 12-14 Select by Time region 12-14 Select by Type region 12-13 changing alarm states 12-10 closing alarms 12-3 Currently Selected Alarm acknowledging 12-10 closing 12-9 Response edit box 12-9 menu bar 12-6 registering responses 12-10 alarm monitor/report attribute 13-15 Alarm Sentry 6-5, 12-2 alarm_if_fail job attribute 4-15 alarm_verif monitor attribute 13-17 alarms about 1-11 AutoSys 15-47 AutoSys Big 15-47 AutoSys Default 15-47 DB_PROBLEM 15-39 DB_ROLLOVER 15-39 EP_HIGH_AVAIL 15-40 EP_ROLLOVER 15-39 EP_SHUTDOWN 15-40 sounds for 15-47 all_events monitor/report attribute 13-14 all_status monitor/report attribute 13-15 attributes job alarm_if_fail 4-15 auto_delete 4-18 auto_hold 4-18 avg_runtime 4-25 basic 3-12 box_failure 4-28 box_name 4-14
Index-1 s
s Index
attributes (contd.) job (contd.) box_success 4-27 box_terminator 4-15 chk_files 4-26, 4-27 command 4-5, 4-6 condition 4-13 date_conditions 4-10 days_of_week 4-11 description 4-13 essential all jobs 4-5 Box Jobs 4-10 Command Jobs 4-6 File Watcher Jobs 4-9 exclude_calendar 4-11 heartbeat_interval 4-25 job_load 4-23 job_name 4-5 job_terminator 4-16 machine 4-8, 4-9 max_exit_success 4-24 max_run_alarm 4-14 min_run_alarm 4-14 n_retrys 4-16 optional Box Jobs 4-27 Command Jobs 4-19 File Watcher Jobs 4-26 non-starting parameters 4-13 starting parameters 4-10 override_job 4-24 permission 2-20, 4-18 priority 4-23, 10-6 run_calendar 4-11 run_window 4-12 start_mins 4-12
start_times 4-11 std_err_file 4-22 std_in_file 4-20 std_out_file 4-21 term_run_time 4-15 timezone 4-17 watch_file 4-9 watch_file_min_size 4-26 watch_interval 4-27 job dependencies 3-23 job security 2-18 machine factor attribute 10-6 max_load 10-5 machine (job attribute) 2-19 monitor alarm_verif 13-17 sound 13-17 monitor/report alarm monitor/report attribute 13-15 all_status 13-15 job_filter 13-16 owner 2-19 permission 2-20 report after_time 13-18 currun 13-18 starting conditions 3-23 auto_delete 4-18 auto_hold 4-18 auto_rem file 15-31 AUTOBCP.NT Perl script 14-29 autohold 15-31 autohold job attribute 4-18 AutoInstWideAppend, configuration parameter 15-32 AutoPems 15-33
s Index-2
Index s
autoping 16-18, 16-19 AutoRemoteDir, configuration parameter 15-26 AutoRemPort, configuration parameter 15-13 AUTOROOT variable 15-43 AUTORUN 3-35 AUTOSERV variable 15-44 AutoSys build information 15-45 components 1-4 database name 15-44 database, defined 1-5 directory 15-43 environment variables 15-40 Graphical User Interface, see GUI instance ID 15-44 instances, defined 1-10 machines 1-10 root directory 15-43 security 2-1, 15-48 services 15-52 user directory 15-44 version 15-45 AutoSys Administrator 15-1 to 15-55 Authorized Event Processor Host Names 15-14 AUTOROOT 15-43 AUTOSERV 15-44 AUTOSYS 15-43 AutoSys Alarm 15-47 AutoSys Big Alarm 15-47 AutoSys Default Alarm 15-47 AutoSys Failures 15-47 AutoSys Success 15-47 AUTOUSER 15-44 Build 15-45
Chase On Startup 15-30 Clean Temporary Files 15-31 Database Maintenance Command 15-27 Database Maintenance Time 15-27 Database Problem 15-39 Database Rollover 15-39 Database Wait Time 15-22 DB Event Reconnect 15-21 DSQUERY 15-44 EDMachines 15-26 Enable External Events 15-33 Enterprise Wide Logging Directory 15-26 Error Time Interval 15-28 Event Processor High Availability 15-40 Event Processor screen 15-23 Event Processor Shutdown 15-40 Event Server Database 15-20 Event Server Disable 15-19 Event Server Host 15-20 Event Server Name 15-19 Event Server Port 15-20 Event Server screen 15-16 Event Server Status 15-20 Event Transfer Wait Time 15-28 FileSystem Threshold 15-29 Global Auto Hold 15-31 HeartBeat Interval 15-29 Instance screen 15-10 Kill Signals 15-36 Local Agent Logging Directory 15-14 Machine Method 15-34 Max Restart Trys 15-35 Max Restart Wait 15-35 Maximum Log Size 15-27 menu bar 15-5
Index-3 s
s Index
AutoSys Administrator (contd.) Network Machine List 15-26 Notifications Screen 15-37 Number of Errors 15-28 Remote Agent parameters 15-13 Remote Agent screen 15-12 Remote Profile Logging 15-31 Restart Constant 15-36 Security screen 15-50 Service 15-54 Services 16-13 Services screen 15-52 Shadow Machine 15-25 Sounds screen 15-46 Start Service 15-54 Status 15-54 Stop Service 15-54 System Information Screen 15-41 TCP/IP Port # field 15-13 Third Machine 15-25 toolbar 15-5 Version 15-45 XInstance DB Drop Time 15-34 Z/Team Job Support 15-32 AUTOSYS variable 15-43 AutoSys/Xpert 6-5 autosys_secure command 15-48 autosyslog command 14-5 autosyslog, monitoring Remote Agent log 16-26 autotest 14-15 AUTOTESTMODE 14-15 AUTOUSER variable 15-44 avg_runtime 4-25
B
backups bundled Sybase 14-44 calendar definitions 14-18 global variables (using autorep) 14-19 job definitions (using autorep) 14-19 machine definitions (using autorep) 14-19 monitor and browser definitions (using monbro) 14-19 batch files database maintenance 15-27 DBMaint.bat 14-25 batch files and exit codes 3-31 big alarms, defining sound for 15-47 Box Jobs 3-6, 5-1 basic job definition 3-14 default behavior 5-3 diagram 3-19 examples 5-10 force starting jobs in a box 5-8 guidelines 5-4 non-default terminators 5-6 placing job in GUI 7-19 JIL 8-11 starting conditions 3-6, 3-21 status changes 5-9 box_failure 4-28 box_name 4-14 box_success 4-27 box_terminator 4-15 browsers backing up definitions 14-19 defined 13-3 restoring definitions from backup file 14-21
s Index-4
Index s
C
Calendar Editor 6-5, 9-1 to 9-32 See also calendars applying rules 9-19 Calendar Selection dialog 9-18 date states 9-14 Edit menu 9-9 exporting definitions 9-32 File menu 9-7 Help menu 9-12 importing text files 9-31 merging calendars 9-28 navigation controls 9-12 Preferences menu 9-10 rescheduling rules 9-25 rule specification 9-21 starting 9-6 Utilities menu 9-10 calendars 9-1 to 9-32 applying rules 9-9 backing up definitions 14-18 blocked dates 9-14 blocking dates 9-21 combining 9-28 conflicting dates 9-13, 9-15 custom 3-22 date range 9-22 date states 9-14 deleting 9-8 exiting 9-9 exporting 9-32 exporting definitions to file 14-18 exporting to text 9-8 importing 9-8, 9-31 importing definitions from file 14-20 Job Definition Reference List 9-10 merging 9-28
navigation controls 9-12 opening 9-7 opening new 9-7 periods 9-23 printing 9-8 renaming 9-8 rescheduling rules 9-25, 9-27 restoring definitions 14-20 reverting to last saved 9-9 rule specification 9-21 saving 9-7 saving to other instances 9-8 selecting 9-18 setting dates 9-21 Term Calendar Rule 9-19 unsetting dates 9-21 CHANGE_PRIORITY 11-33 CHANGE_STATUS 11-33 chase command 14-4, 14-16, 15-30 check file space 4-26, 4-27 Check_Heartbeat, configuration parameter 15-29 chk_auto_up 15-26 chk_files 4-26 clean_files 14-17, 15-31 CleanTmpFiles, configuration parameter 15-31 client machine 1-10 command job attribute 4-5, 4-6 Command Jobs 3-5, 3-13 COMMENT 11-32 components Event Processor 1-6 Event Server 1-5 Remote Agent 1-7 condition job attribute 4-13 conditions, starting 3-23
Index-5 s
s Index
configuration file for UNIX 15-4 configuration file, FileSystemThreshold 15-29 Control Panel, GUI 6-2 conventions, typographical xxv cpu, using available cycles to select machine to run on 10-13 crash recovery, database 14-27, 14-46 cross-instance database drop time 15-34 currun report attribute 13-18 custom calendars, overview 3-22
D
database 15-39 accessing interactively 14-42 administration 14-38 architecture 14-23 backup, bundled Sybase 14-44 breaking connection 15-22 changing the sa password 14-39 checking if Sybase running 14-40 connection to Monitor/Browser Editor 13-22 crash recovery 14-27 cross-instance drop time 15-34 defined 14-21 defining which to use 14-23 disabling 15-19 dumping 14-44 environment variables 15-40 host machine 15-20 identifying connected processes 14-42 maintenance batch file 15-27 maintenance time 14-25, 15-27 name 15-19, 15-20 passwords 2-10 reconnect numbers 15-21
recovery 14-27, 14-46 reloading 14-49 rollover 14-27 rollover notification 15-39 shutdown 14-41 starting 14-40 status 15-20 stopping service 14-41 storage requirements 14-22 tablespace error, Oracle 16-11 unrecoverable error 14-27 verifying connection 16-19 dataserver, defined 1-5 date dependency 3-22 date range in calendars 9-22 date/time job dependencies 3-22 date_conditions 4-10 days to run job, setting GUI 7-27 JIL 8-12 days_of_week 4-11 DB Library 14-37 DB_PROBLEM, configuration parameter 15-39 DB_ROLLOVER, configuration parameter 15-39 DBAlarmReconnect, configuration parameter 15-22 DBEventReconnect, configuration parameter 15-21 DBLibWaitTime, configuration parameter 15-22 DBMaint.bat batch file 14-25 DBMaintCmd, configuration parameter 15-27 DBMaintTime configuration parameter 15-27
s Index-6
Index s
dbstatistics script 14-25 default owner of job 2-11 delete job GUI 7-29 JIL 8-14 dependency, job date/time 3-22 exit code 3-30 global variables 3-33 job status 3-23 dependent jobs creating - GUI 7-15 creating -JIL 8-8 example 3-28 description job attribute 4-13 done condition in job definition 3-24 DSQUERY variable 14-38 Dual Event Servers defined 1-6 mode 14-21 running 15-15 dump command 14-44
E
EDErrTimeInt, configuration parameter 15-28 edit permissions 2-12 Edit Superuser 2-14 EDMachines, configuration parameter 15-26 EDNumErrors, configuration parameter 15-28 environment variables See also profiles AutoSys 15-40 AutoSys directory 15-43 AutoSys instance 15-44
AutoSys root directory 15-43 AutoSys user directory 15-44 DSQUERY 14-38, 15-44 NuTCRACKER 15-40 setting for jobs 3-5 SYBASE 14-38 user defined 3-8 EP_HIGH_AVAIL, configuration parameter 15-40 EP_ROLLOVER, configuration parameter 15-39 EP_SHUTDOWN, configuration parameter 15-40 errors Event Processor handling 15-28 Event Processor time interval 15-28 Event Server, detection 14-27 essential job attributes 4-5 Event Processor 15-22 See also event_demon autohold 15-31 automatic shutdown 15-28 configuration parameters 15-24 connecting to databases 15-21 defined 1-6 error handling 15-28 error interval 15-28 global autohold 15-31 heartbeat checking 15-29 job restarting wait time 15-35 log file, space needed for 15-29 log size limit 15-27 logging directory 15-26 machine list 15-26 monitoring 14-5 remote authentication 15-14 restarting jobs 15-35, 15-36
Index-7 s
s Index
Event Processor (contd.) restoring 14-12 running chase with 15-30 running in test mode 14-14 Shadow Machine 15-25 shutdown notification 15-40 shutdown, automatic 15-28 starting 14-3, 15-55 status 16-13 stopping 14-9, 15-55 terminating jobs 15-36 third machine configuration 15-25 troubleshooting 16-12 Event Server 15-15 See also database See also Dual Event Servers breaking connection 15-22 configuration parameters 15-18 crash recovery 14-27 database name 15-20 defined 1-5 disabling 15-19 dual 14-21, 14-23, 15-15 error detection 14-27 errors, unrecoverable 14-27 host machine 15-20 name 15-19, 15-44 port number 15-20 reconnect numbers 15-21 recovery 14-27 restarting Dual Server Mode 14-28 rollover 14-27 rollover recovery 14-27 single 14-27 status 15-20 synchronizing 14-28
transferring events 15-28 troubleshooting 16-5 event_demon See also Event Processor events about 1-11 cancelling 11-36 copying to Event Servers 15-28 HEARTBEAT 15-29 job failure, sound for 15-47 job success, sound for 15-47 transferring missing 15-28 EventServer parameter 15-19, 15-20 EvtTransferWaitTime, configuration parameter 15-28 examples calendar rescheduling rule 9-27 individual queues 10-19 JIL 8-17 job dependencies 3-28 load balancing 10-14 monitor/report definition 13-9 monitors, defining in JIL 13-21 multiple machine queues 10-22 NT security 2-23 queuing with priority 10-18 real machine definition 10-8 reports, defining in JIL 13-22 system architecture 1-8 Trusted Hosts 15-49 Trusted Users 15-49 user remote authentication 15-49 virtual machine definition 10-9 exclude_calendar 4-11 exclusive condition 3-29 Exec Superuser 2-15 execute permissions 2-11, 2-12
s Index-8
Index s
exit codes batch files, with 3-31 FALSE.EXE 3-33 job dependencies 3-30 maximum for success 3-24 exitcode 3-30 exporting calendars 9-32, 14-18
F
factor attribute 10-6 failure condition in job definition 3-24 FAILURE status 3-15 FALSE.EXE 3-33 File Watcher Jobs 3-7 basic job definition 3-13 creating 7-12 files UNIX configuration 15-4 users directory, in 15-44 FileSystem Threshold 15-29 FileSystemThreshold 15-29 Filter Editor 11-16 Machine/Instance tab 11-20 Names tab 11-17 Status tab 11-19 using 11-22 force starting jobs impact on load balancing 10-15 FORCE_STARTJOB 11-6, 11-32, 11-55
setting in the Send Event Tool 11-34 Graphical User Interface See also GUI introduction 6-1 GUI alarm color setting 6-4 Alarm Manager 6-5 Alarm Sentry 6-5 Calendar Editor 6-5 connect to database 6-4 Control Panel 6-2 defined 1-3 HostScape 6-5 introduction 6-1 Job Editor 6-5 Job Editor menu bar 7-5 JobScape 6-5 Monitor/Browser Editor 6-5 one-time job overrides 7-31 removing user preferences 6-4 Scheduler Console 6-4 time dependencies, setting 7-23 TimeScape 6-5 using to create a job definition 4-4
H
heartbeat interval 15-29 heartbeat.c file 4-25 heartbeat_interval 4-25 heartbeats code to include 4-25 interval 4-25 sending from C program 4-25 high availability Dual Event Servers 1-6, 15-15 Shadow Event Processor 1-6 HostScape 6-5
G
General Dialog 11-44 global autohold 15-31 global variables backing up definitions 14-19 job dependencies 3-33 restoring definitions 14-21
Index-9 s
s Index
I
importing calendars 9-31, 14-20 INACTIVE status 3-14 InfoReports job find report 11-41 job list report 11-41 last n run report 11-41 last run report 11-41 InfoReports Viewer 11-41 inherit, jobs starting conditions 3-21 initautosys command 11-46 instances 15-9 Administrator screen 15-10 cross-instance dependencies 15-34 IDs 15-44 instances of AutoSys 1-10
J
JIL creating a job definition 4-3 defined 1-3 defining jobs 8-3 defining monitor 13-21 defining report 13-22 example 8-17 running 8-6 sub-commands 8-5 syntax rules 8-3 Job Definition Reference List 9-10 Job Dependencies dialog 11-23 Job Detail Report 11-38 Job Editor 6-5, 7-1 to 7-36 creating Box Jobs 7-19 creating Command Jobs 7-10 creating File Watcher Jobs 7-12 creating jobs with dependencies 7-15 deleting definition 7-6
deleting jobs 7-29 menu bar 7-5 modifying job definitions 7-21 one-time overrides 7-31 opening definitions 7-5 opening new job 7-5 Owner field 7-12 saving job as 7-6 saving jobs 7-5 setting days to run 7-27 setting time dependencies 7-23 Job Information Language 1-12 See also JIL job overrides, setting 8-15, 8-16 Job Profiles Manager 3-8, 3-9 job profiles, creating 3-8 Job Selection dialog Box Levels field 11-18 Job Name field 11-18 job status, as job dependency 3-23 job_filter monitor/report attribute 13-16 job_load 4-23 job_name 4-5 JOB_OFF_HOLD 11-7, 11-32, 11-55 JOB_OFF_ICE 11-7, 11-33, 11-55 JOB_ON_HOLD 11-7, 11-32, 11-55 JOB_ON_ICE 11-7, 11-33, 11-55 job_terminator 4-16 jobs attributes, basic 3-12 backing up definitions 14-19 basic job information 3-4 Box Jobs 5-1 creating - GUI 7-19 creating - JIL 8-10 defined 3-6 calendar reference list 9-10
s Index-10
Index s
jobs (contd.) changing - GUI 7-21 changing - JIL 8-11 Command Jobs creating - GUI 7-10 creating - JIL 8-7 defined 3-5 creating Box Jobs - GUI 7-19 Box Jobs - JIL 8-10 Command Jobs - GUI 7-10 Command Jobs - JIL 8-7 File Watcher Jobs - GUI 7-12 File Watcher Jobs - JIL 8-7 creating a job definition 4-3 creating profiles for 3-8 cross-instance dependencies 15-34 custom calendars 3-22 cycles of processing 16-3 date/time dependencies setting in GUI 7-23 setting in JIL 8-12 days to run, setting 7-27 defined 1-3 defining in AutoSys 3-35 definition Box 3-14 Command 3-13 File Watcher 3-13 deleting GUI 7-29 JIL 8-14 dependencies creating with GUI 7-15 creating with JIL 8-8 exit codes 3-30 global variables 3-33
job status 3-23 time GUI 7-23 JIL 8-12 edit permissions 2-12 environment 3-5 environment variables for 3-8 execute permssions 2-12 exit code 3-30 File Watcher creating - GUI 7-12 creating - JIL 8-7 defined 3-7 force starting 10-15 heartbeats from 4-25 holding globally 15-31 list in Scheduler Console 11-12 overrides GUI 7-31 JIL 8-15 owner, default 2-11 permissions on NT 2-13 profiles 3-5 queuing 10-6, 10-15 restart constant 15-36 restart tries 15-35 restarting wait time 15-35 restoring definitions from backup file 14-21 run number 3-34 running 2-21 saving definitions to backup file 14-19 security attributes 2-18 selection list 7-22 sound for failure 15-47 sound for success 15-47
Index-11 s
s Index
jobs (contd.) starting conditions 3-20 done 3-24 failure 3-24 notrunning 3-24 success 3-24 terminated 3-24 starting manually 2-20 states 3-14 status ACTIVATED 3-15 FAILURE 3-15 INACTIVE 3-14 managing 3-29 ON_HOLD 3-16 ON_ICE 3-17 QUE_WAIT 3-16 RESTART 3-16 STARTING 3-15 SUCCESS 3-15 TERMINATED 3-16 status codes 3-14 Team Agent 15-32 terminating 15-36 time dependencies, setting JIL 8-12 time/date dependencies 3-22 types 3-3 variables 3-5 Zeke 15-32 JobScape 6-5
L
load balancing 10-12 example 10-14 force starting jobs 10-15 job attributes required for 10-5 maximum load on machine 10-5 user-defined 10-22 load balancing, machine method 15-34 load database command 14-44 log files cleanup 15-31 Event Processor size 15-27 Remote Agent 16-25 Remote Agent directory 15-26 logging setting enterprise-wide directory 15-26 setting local directory 15-14
M
machine attribute 4-8, 4-9 backing up definitions 14-19 client 1-10 defining with JIL 10-4 deleting real machines 10-9 virtual machines 10-11 factor attribute 10-6 job runs on 4-8 machine attribute 10-4 max_load attribute 10-5 permissions, edit and execute 2-12 priority job attribute 10-6 real 10-3 restoring definitions from backup file 14-21 saving definitions to backup file 14-19
K
KILLJOB 11-6, 11-33, 11-54 KILLJOB Signals 15-36 KillSignals, configuration parameter 15-36
s Index-12
Index s
machine (contd.) server 1-10 type attribute 10-4 virtual 10-3 defining 10-9 deleting 10-11 machine attribute 2-19 Machine Method 15-34 MachineMethod 15-34 maintenance backing up AutoSys definitions 14-18 calendar definitions 14-18 global variables 14-19 job definitions 14-19 machine definitions 14-19 monitor and browser definitions 14-19 chase command 14-16 clean_files 14-17 commands 14-16 database 15-27 database time 14-25 restoring AutoSys definitions 14-20 managing job status 3-29 max_exit_success 4-24 max_load machine attribute 10-5 max_run_alarm 4-14 maximum exit code for success 3-24 maximum system load 10-5 MaxRestartTrys, configuration parameter 15-35 MaxRestartWait, configuration parameter 15-35 Microsoft SQL Server 16-3, 16-21 min_run_alarm 4-14
Monitor/Browser Editor 6-5, 13-1 to 13-22 Alarm field 13-15 Alarm Verification Required field 13-17 All Change Status Events field 13-15 All Events field 13-14 Current Run Only field 13-18 Events After Date/Time field 13-18 Job Change Status Events field 13-16 Job Filter field 13-16 naming 13-7 Sound field 13-17 sounds, defining 15-45 monitors 13-1 to 13-22 about 13-4 alarm_verif 13-17 backing up definitions 14-19 defined 13-3 defining 13-9, 13-20, 13-21 restoring definitions from backup file 14-21 sound 13-17 multiple machine queues 10-21
N
n_retrys 4-16 notification configuration parameters 15-39 database problem 15-39 database rollover 15-39 Event Processor shutdown 15-40 mechanism 15-37 user-defined notification routines 15-37 notrunning condition in job definition 3-24 ntgetdate command 14-15
Index-13 s
s Index
ntrys 3-34 NuTCRACKER environment variable 15-40
O
ON_HOLD 3-16 ON_HOLD vs. ON_ICE 3-17 ON_ICE 3-17 one-time job overrides 7-31 Open Client C Library 14-21 optional job attributes 4-10 Oracle 16-3 improving database performance 14-35 SQL*Net V2 14-21 SQL*Plus 14-42 tablespace error 16-11 troubleshooting 16-4 override_job 4-24 overrides, job GUI 7-31 JIL 8-15 owner attribute 2-19 owner, default 2-11
user 2-10 user types 2-11 Windows NT 2-13 POEMS common services, enabling 15-33 port number Event Server 15-20 Remote Agent 15-13 preferences alarm color 6-4 removing user 6-4 retry count 6-4 primary domain controller, running jobs on 2-23, 2-30 priority job attribute 4-23, 10-6 problem notification 15-39 profiles creating variables 3-11 deleting 3-12 deleting variables 3-12 editing variables 3-11 job 3-5 managing 3-8 remote logging 15-31
P
passwords autosys user 2-10 database 2-10 database system administrator 14-39 permission attribute 2-20, 4-18 permissions 2-3, 4-18 edit 2-12, 4-19 execute 2-12, 4-19 granting 2-12 job execute 2-11 machine 2-12 types 2-12, 4-19
Q
QUE_WAIT status 3-16 queuing and simple load limiting 10-16 as subset of virtual machine 10-19 jobs 10-15 multiple machine 10-21, 10-22 policies 10-15 with priority 10-17, 10-18
s Index-14
Index s
R
real machines 10-3 defining 10-4 deleting 10-9 example 10-8 type 10-4 recovery database 14-46 Sybase database 14-46 Remote Agent 15-11 configuration parameters 15-13 database connectivity 16-21 defined 1-7 Event Processor authentication 2-9 heartbeat interval 15-29 log cleanup 15-31 log name, assigning 16-25 logging directory 15-26 port number 15-13 security 2-17 starting 14-13, 15-55 stopping 14-14, 15-55 TCP/IP port number 15-13 troubleshooting 16-18 user authentication 2-9 remote authentication Event Processor 2-9, 15-14 examples on NT 2-30 user 2-9 user example 15-49 RemoteProFiles, configuration parameter 15-31 reports 13-1 to 13-22 about 13-4 all_status 13-15 defined 13-3 defining 13-9, 13-12, 13-20, 13-22
InfoReports 11-41 naming 13-7 rescheduling rules 9-25 resource check, file space 4-26, 4-27 restart attempts, maximum number 15-35 RESTART status 3-16 RestartConstant, configuration parameter 15-36 RestartFactor, configuration parameter 15-36 restoring calendar definitions 14-20 global variables (using autorep) 14-21 job definitions (using autorep) 14-21 machine definitions (using autorep) 14-21 monitor and browser definitions 14-21 Primary Event Processor 14-12 rollover Event Server 14-27 Shadow Event Processor 14-10 rstatd 15-34 Rule Specification region 9-21 Run MonBro button 13-8 run number 3-34 Run Status Tool 11-24 Command field 11-27 Description field 11-27 End Time field 11-28 Exit Code field 11-27 Instance field 11-27 Job Name field 11-27 Next Start field 11-28 Predecessor and Successor Jobs fields 11-28 Priority field 11-28 Queue Name field 11-28
Index-15 s
s Index
Run Status Tool (contd.) Run Machine field 11-27 Run Time field 11-27 Start Time field 11-27 Starting Conditions field 11-27 Status field 11-28 Try Count field 11-27 run_calendar 4-11 run_num/ntry, defined 3-35 run_window 4-12 RUNNING status 3-15
S
Scheduler Console 6-4, 11-1 to 11-56 buttons 11-54 cancelling a sent event 11-36 Control Area 11-12 Filter Editor 11-15, 11-16 Machine/Instance tab 11-20 Names Tab 11-17 Names tab 11-17 Status tab 11-19 filters 11-15 InfoReports 11-41 Job Dependencies dialog 11-23 Job Detail Report 11-38 job list 11-12 menu bar 11-5 Preferences Action Area Layout 11-52 AutoRefresh 11-43 General 11-44 Summary Area Layout 11-49 Time Perspective 11-56 User Defined Commands 11-45 User Defined Reports 11-47 refresh interval, setting for 11-44
Reports Job Detail Report 11-38 Job Find 11-41 Job List 11-41 Last N Run 11-41 Last Run 11-41 Send Event Tool 11-28, 11-31 AUTOSERV instance 11-35 Close button 11-35 Comment field 11-35 opening 11-29 Send button 11-35 sorting specified jobs 11-51 summary area 11-12 time perspective 11-56 Tools Dependent Jobs 11-23 Run Status Tool 11-24 Send Event Tool 11-28 Tools menu 11-22 user defined commands 11-45 viewing job dependencies 11-23 security 2-1, 2-3, 15-48 AutoSys and Windows NT 2-17 configuration parameters 15-51 examples for NT 2-23 granting permissions 2-12 job attributes 2-18 job execute permissions 2-11 permission types 2-12 preventing unauthorized access 2-7 Remote Agent 2-17 running jobs 2-21 starting jobs manually 2-20 superusers, AutoSys 2-14 Trusted Hosts 2-9, 15-48, 15-51 Trusted Users 2-9, 15-48, 15-52
s Index-16
Index s
security (contd.) user permissions 2-10 user types 2-11 select getdate, command 14-40 Send Event Tool 11-28, 11-31 AUTOSERV instance 11-35 cancelling an event 11-36 Change Priority 11-33 Change Status 11-33 Close button 11-35 Comment 11-32 Comment field 11-35 Force Start Job 11-32 Job Off Hold 11-32 Job Off Ice 11-33 Job On Hold 11-32 Job On Ice 11-33 Kill Job 11-33 opening 11-29 Send button 11-35 Send Signal 11-34 Set Global 11-34 Start Job 11-32 Stop Demon 11-32 SEND_SIGNAL 11-34 sendevent command 2-15 server instance 1-5 server machine 1-10 services AutoSys 15-52 AutoSys Administrator screen 15-52 determining status 15-54 list in AutoSys Administrator 15-54 starting 15-54 stopping 15-54 SET_GLOBAL 11-34 Shadow Event Processor
defined 1-6 rollover 14-10 setting up 15-23 signals, UNIX kill 15-36 socket time-out 15-35 sound monitor attribute 13-17 sounds alarms 15-47 AutoSys 15-45 defining 15-45 job failure, for 15-47 job success, for 15-47 sounds, defining 15-45 sp_addumpdevice 14-44 SQL*Net V2 14-21 SQL.INI file 15-19 start_mins 4-12 start_times 4-11 starting conditions 3-20, 3-23 STARTING status 3-15 STARTJOB 8-6, 11-6, 11-32, 11-54 states See also status job 3-14 status job ACTIVATED 3-15 as job dependency 3-23 FAILURE 3-15 INACTIVE 3-14 ON_HOLD 3-16 ON_ICE 3-17 QUE_WAIT 3-16 RESTART 3-16 RUNNING 3-15 STARTING 3-15 SUCCESS 3-15
Index-17 s
s Index
status (contd.) job (contd.) TERMINATED 3-16 tracking changes 13-15 monitor/report failure 13-16 restart 13-16 running 13-16 starting 13-16 success 13-16 terminated 13-16 processed vs. unprocessed 3-20 using in job dependencies 3-23 std_err_file 4-22 std_in_file 4-20 std_out_file 4-21 STOP_DEMON 11-32, 14-10, 14-41, 14-47 success condition in job definition 3-24 maximum exit code 3-24 SUCCESS status 3-15 Summary Area Layout Dialog 11-49 superusers 2-14 Edit Superuser, defined 2-14 Exec Superuser, defined 2-15 Sybase accessing interactively 14-42 architecture 14-37 bundled 14-37 checking if running 14-40 communication with 14-37
database displaying date and time 14-43 identifying connected processes 14-42 improving performance 14-35 name 15-19 DB Library 14-37 disabling 15-19 DSQUERY variable 14-38 environment 14-38 environment variable 14-38 interfaces file 14-38 server 14-37 shutdown command 14-41 SQL.INI file 14-38 starting 14-40 stopping 14-41 users 14-38 SYBASE variable 14-38 synchronizing Event Servers 14-28 syntax rules, JIL 8-3 system configuration parameters 15-43 system administrator, database 14-39 system information, AutoSys 15-41, 15-44 system load, maximum 10-5
T
target machine 4-8 Team Agent 15-32 Team Agent support A-1 Term Calendar Rule dialog 9-19 term_run_time 4-15 terminated condition in job definition 3-24
s Index-18
Index s
TERMINATED status 3-16 test mode output file 14-15 running in 14-14 ThirdMachine, configuration parameter 15-25 time dependencies in job definition 4-10 overview 3-22 setting GUI 7-23 JIL 8-12 time perspective in the Scheduler Console 11-56 TimeScape 6-5 timezone 4-17 troubleshooting 16-1 Event Processor 16-12 Event Servers 16-5 Microsoft SQL Server 16-4, 16-23 Oracle 16-4 Remote Agent 16-18 Sybase 16-4 Truste Hosts 15-49 Truste Users 15-50 Trusted Hosts 15-48, 15-50, 15-51 Trusted Users 15-48, 15-49, 15-52 typographical conventions xxv
user-defined load balancing 10-22 users, bundled Sybase 14-38 utilities, provided with AutoSys 1-12
V
virtual machines 10-3 defining 10-4, 10-9 deleting 10-11 example 10-9 type 10-4 using delete_machine 10-4 using insert_machine 10-4 vmstat 15-34
W
WaitTime, configuration parameter 15-35 watch_file 4-9 watch_file_min_size 4-26 watch_interval 4-27 Windows NT job permissions on 2-13 remote authentication examples 2-30 world, user types 2-11
X
XInstanceDBDropTime, configuration parameter 15-34
U
UNIX remote profile logging 15-31 unrecoverable error, database 14-27 User Defined Buttons dialog 11-45 User Defined Reports dialog 11-47 user types owner 2-11 world 2-11
Z
Zeke 15-32 Zeke and AutoSys/Team Agent support A-1 to A-26 ZTeamJobSupport, parameter 15-32
Index-19 s
s Index
s Index-20

Autosys

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Autosys

Caricato da

Copyright:

Formati disponibili

PLATINUM

PLATINUM AutoSys User Guide for Windows NT

PLATINUM AutoSys User Guide for Windows NT

PLATINUM AutoSys User Guide for Windows NT

5 Box Job Logic

PLATINUM AutoSys User Guide for Windows NT

6 Introduction to the Graphical User Interface

7 Defining AutoSys Jobs using the Job Editor

8 Defining Jobs Using JIL

PLATINUM AutoSys User Guide for Windows NT

PLATINUM AutoSys User Guide for Windows NT

10 Load Balancing and Queuing Jobs

PLATINUM AutoSys User Guide for Windows NT

13 Monitoring and Reporting on Jobs

PLATINUM AutoSys User Guide for Windows NT

13-13 13-14 13-16 13-17 13-18 13-19 13-20 13-21 13-22

PLATINUM AutoSys User Guide for Windows NT

PLATINUM AutoSys User Guide for Windows NT

A Integrating AutoSys with Zeke and AutoSys/Team Agent

PLATINUM AutoSys User Guide for Windows NT

PLATINUM AutoSys User Guide for Windows NT

PLATINUM AutoSys User Guide for Windows NT

Contacting Technical Support

About This Guide

PLATINUM AutoSys User Guide for Windows NT

Preface s About This Guide

PLATINUM AutoSys User Guide for Windows NT

Ch. No. Chapter Name 5

Box Job Logic

Defining Jobs Using JIL

PLATINUM AutoSys User Guide for Windows NT

Preface s About This Guide

Ch. No. Chapter Name 10

Load Balancing and Queuing Jobs

Monitoring and Reporting on Jobs

PLATINUM AutoSys User Guide for Windows NT

Ch. No. Chapter Name A

Integrating AutoSys with Zeke and AutoSys/Team Agent Index

Native Windows NT GUIs with Multiple Instance Support

Year 2000 Support

PLATINUM AutoSys User Guide for Windows NT

Preface s Whats New

PLATINUM ProVision Common Services Integration

Reporting using InfoReports

PLATINUM AutoSys User Guide for Windows NT

Event Processor Enhancements

PLATINUM AutoSys User Guide for Windows NT

Preface s Whats New

AutoSys Administrator Enhancements

Append stdout/stderr FileSystem Threshold Enable Poems

PLATINUM AutoSys User Guide for Windows NT

Time Zone Setting

Set Append or Overwrite Behavior for Standard Files

Expanded Number of Entries in config.EXTERNAL File

PLATINUM AutoSys User Guide for Windows NT

AutoSys Command Changes

Bold alternate color

...called a source object.

PLATINUM AutoSys User Guide for Windows NT

Symbol or Type Style

words that are emphasized

...the entry after the current entry...

&HIGHLVL.SRCLIB directories, file names, command names, computer code

what a user types the name of a key on the keyboard