Autosys

PLATINUMAutoSysUser Guide for Windows NT

Version 3.4

PLATINUM technology, inc.

This document features bookmarks for each of the chapters and major subheadings. For information about this book, select "File...Document Info...General".

PLATINUM technology, inc.

Confidential and proprietary information of PLATINUM technology, inc.

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 RoadOakbrook Terrace, Illinois60181-5235

Table of Contents

PrefacePhilosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvContacting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviAbout This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviWhat’s New . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx

Native Windows NT GUIs with Multiple Instance Support . . . . . . . . . . . xxYear 2000 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxPLATINUM ProVision Common Services Integration . . . . . . . . . . . . . . . . xxiReporting using InfoReports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiSecurity Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiiEvent Processor Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiiAutoSys Administrator Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiiiTime Zone Setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxivSet Append or Overwrite Behavior for Standard Files . . . . . . . . . . . . . . xxivExpanded Number of Entries in config.EXTERNAL File . . . . . . . . . . . . . xxivAutoSys Command Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv

Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvRelated Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvii

1 • Introduction to AutoSysAutoSys Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3

Defining Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3System Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-4

Event Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-5Event Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-6Remote Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-7Example Scenario on Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-7Interface Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-9

AutoSys Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10

PLATINUM AutoSys User Guide for Windows NT iii ■

■ Table of Contents

AutoSys Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12Basic AutoSys Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13

Explanation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14Extending AutoSys Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15

2 • AutoSys SecurityOverview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3

Security on Events Sent by Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3Security on Events Sent by the Event Processor . . . . . . . . . . . . . . . . . . . 2-5

System-Level Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7AutoSys Database Field Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8Job Definition Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8Remote Agent Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8AutoSys User and Database Administrator Passwords . . . . . . . . . . . . . 2-10

AutoSys Job-Level Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10AutoSys Job Ownership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11AutoSys User Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11AutoSys Permission Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12Job Permissions and Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13

AutoSys Superuser Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14Edit Superuser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14Exec Superuser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15

Restricting Access to AutoSys Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15Remote Agent Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17

AutoSys Security and Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17Defining Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18Starting Jobs Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20Running Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21Examples of AutoSys Security on Windows NT . . . . . . . . . . . . . . . . . . . 2-23

■ iv PLATINUM AutoSys User Guide for Windows NT

Table of Contents ■

3 • AutoSys JobsIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-3Job Types and Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-3

Basic Job Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-4Command Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-5Box Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-6File Watcher Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-7

Job Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-8Using the Job Profiles Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-9

Basic Job Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12Command Job Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13File Watcher Job Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13Box Job Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14

Job States and Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14Example State Diagram - Simple Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17Example State Diagram - Box Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19

Starting Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20Starting Parameters and Boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21Date/Time Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-22Job Dependencies Related to Job Status . . . . . . . . . . . . . . . . . . . . . . . . 3-23Event Processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-27Event Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-27Job Dependencies Based on Exit Codes . . . . . . . . . . . . . . . . . . . . . . . . 3-30Job Dependencies Based on Global Variables . . . . . . . . . . . . . . . . . . . 3-33

Job Run Numbers and Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-34Defining Jobs in AutoSys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-35

AutoSys Graphical User Interface Components . . . . . . . . . . . . . . . . . . 3-36

4 • Job AttributesJob Attributes and Job Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3

Using JIL to Create a Job Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3Using the Job Editor to Create a Job Definition . . . . . . . . . . . . . . . . . . . .4-4Chapter Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4

PLATINUM AutoSys User Guide for Windows NT v ■


Essential Job Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5Attributes Common to All Job Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5Command Jobs Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6File Watcher Job Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9Box Job Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10

Optional Job Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10Common Job Starting Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10Common General Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13Command Job Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-19File Watcher Job Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26Box Job Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-27

Date and Time Attributes and Time Changes . . . . . . . . . . . . . . . . . . . . . . . . 4-28The Time Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28AutoSys Behavior During Time Change . . . . . . . . . . . . . . . . . . . . . . . . . 4-30

5 • Box Job LogicBasic Box Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3

Default Box Job Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3When you Should Not Use a Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4What Happens when a Box Runs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4

Box Job Attributes and Terminators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6Attributes in a Box Job Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6Attributes in a Job Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7Time Conditions in a Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7Force Starting Jobs in a Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8How Job Status Changes Affect Box Status . . . . . . . . . . . . . . . . . . . . . . . 5-9

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10Advanced Conditions in Box Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11Default Box Success and Box Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13Explicit Box Success and Box Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15Using the Box Terminator Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16Using the Job Terminator Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17Advanced Job Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18

■ vi PLATINUM AutoSys User Guide for Windows NT


6 • Introduction to the Graphical User InterfaceStarting the GUI Control Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2Using the GUI Control Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2

GUI Control Panel Menu Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2GUI Control Panel Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-4

7 • Defining AutoSys Jobs using the Job EditorStarting the Job Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3Using the Job Editor Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-4

Job Editor Menu Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-5Job Editor Tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-8Job Editor Status Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-8

Creating a Simple Command Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10Creating a File Watcher Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12Creating a Dependent Command Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-15Creating a Box Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-19

Creating the EOD_box Box Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-19Modifying the EOD_post Command Job . . . . . . . . . . . . . . . . . . . . . . . . 7-21

Setting Date and Time Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-23Setting Days of the Week Starting Conditions . . . . . . . . . . . . . . . . . . . 7-25Setting Time Starting Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-26Example on Setting Date and Time Dependencies . . . . . . . . . . . . . . . 7-27

Deleting Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-29Notes on Deleting a Box Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-31

Specifying One-time Job Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-31Setting Job Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-31Deleting One-Time Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-33Enabled Job Editor Fields for One-Time Overrides . . . . . . . . . . . . . . . . 7-34

8 • Defining Jobs Using JILJob Information Language (JIL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-3

JIL Syntax Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-3JIL Sub-commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-5Submitting Job Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-6 Running JIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-6

PLATINUM AutoSys User Guide for Windows NT vii ■


Creating a Simple Command Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7Creating a File Watcher Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7Creating a Dependent Command Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8Creating a Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-10Changing a Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-11Setting Time Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-12

Additional Time Setting Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-13Deleting a Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-14

Deleting a Box Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-14Specifying One-Time Job Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-15

Setting Job Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-16Example JIL Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-17

9 • Calendar EditorIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3Using Defined Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4

Scheduling Jobs with Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4Starting the Calendar Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-6Using the Calendar Editor Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7

Using the Menu Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7Using the Navigation Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-12Using the Calendar Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14

Creating and Modifying Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-16Creating a Calendar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-16Opening an Existing Calendar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-18

Applying Rules to Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-19Using the Rule Specification Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-21Using the Rescheduling Rule Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-25

Combining Existing Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-28Combining Calendars Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-28

Using the Job Definition Reference List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-29Importing and Exporting Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-30

Importing Calendar Text Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-31Exporting Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-32

■ viii PLATINUM AutoSys User Guide for Windows NT


10 • Load Balancing and Queuing JobsReal Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3Virtual Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3Defining Machines to AutoSys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4

Specifying Machine Load (max_load) . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-5Specifying Relative Processing Power (factor) . . . . . . . . . . . . . . . . . . . . 10-6Using max_load and factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-6Machine Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7

Defining a Real Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-8Deleting Real Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-9

Defining a Virtual Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-9Deleting Virtual Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-11

Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-12Force Starting Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-15

Queuing Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-15Queuing and Simple Load Limiting . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-16Queuing with Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-17Subsets—Individual Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-19Multiple Machine Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-21

User-Defined Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-22

11 • Scheduler ConsoleUsing the Scheduler Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3

Using the Scheduler Console Menu Bar . . . . . . . . . . . . . . . . . . . . . . . . . 11-5Using the Control Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-12Using the Summary Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-12

Defining Scheduler Console Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-15Filters Editor Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-16Using the Filter Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-22

Using Scheduler Console Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-22Using the Job Dependencies Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-23Using the Run Status Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-24Using the Send Event Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-28

PLATINUM AutoSys User Guide for Windows NT ix ■


Using Scheduler Console Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-38Using the Job Detail Report Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-38Viewing Reports with InfoReports . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-41

Setting Scheduler Console Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-43Using the General Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-44Using the User Defined Buttons Dialog . . . . . . . . . . . . . . . . . . . . . . . . .11-45Using the User Defined Reports Dialog . . . . . . . . . . . . . . . . . . . . . . . . .11-47Using the Summary Area Layout Dialog . . . . . . . . . . . . . . . . . . . . . . . .11-49Using the Action Area Layout Dialog . . . . . . . . . . . . . . . . . . . . . . . . . .11-52Setting the Time Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-56

12 • Managing AlarmsUsing the Alarm Sentry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2

Using the Alarm Sentry Menu Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3Using the Alarm Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3

Using the Alarm Manager Menu Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-6Using the Alarm Manager Alarm List . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-8Viewing the Currently Selected Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-9Setting the Refresh Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-10

Filtering Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-11Selecting Alarms by Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-13Selecting Alarms by State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-14Selecting Alarms by Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-14Selecting Alarms by Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-14

13 • Monitoring and Reporting on JobsUsing AutoSys Monitors and Browsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-3

Using Monitors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-4Using Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-4

Using the Monitor/Browser Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-5Using the Monitor/Browser Editor Menu Bar . . . . . . . . . . . . . . . . . . . . . 13-6

Defining Monitors and Reports with the Editor . . . . . . . . . . . . . . . . . . . . . . 13-9Defining a Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-9Defining a Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-12Closing the Monitor/Browser Editor . . . . . . . . . . . . . . . . . . . . . . . . . . .13-13

■ x PLATINUM AutoSys User Guide for Windows NT


Setting Monitor and Report Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-13Setting Event Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-14Setting the Job Selection Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-16Setting Monitor Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-17Setting the Browser Time Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-18

Running a Monitor or Generating a Report . . . . . . . . . . . . . . . . . . . . . . . . 13-19Defining Monitors and Reports using JIL . . . . . . . . . . . . . . . . . . . . . . . . . . 13-20

Defining Monitors using JIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-21Defining Reports using JIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-22

14 • Maintaining AutoSysMaintaining the Event Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-3

Starting the Event Processor Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-3Monitoring the Event Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-5Starting the Event Processor in Global Auto Hold Mode . . . . . . . . . . . 14-7Stopping the Event Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-9Shadow Event Processor Rollover . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-10

Maintaining the Remote Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-13Starting the Remote Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-13Stopping a Remote Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-14

Running AutoSys in Test Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-14AutoSys Maintenance Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-16Backing up AutoSys Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-18Restoring AutoSys Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-20AutoSys Database Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-21

Event Server Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-21Database Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-23

General Database Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-24Daily Database Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-25DBMaint.bat Batch File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-25

Event Server Rollover Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-27Returning to Dual Server Mode After a Rollover . . . . . . . . . . . . . . . . 14-27

Improving Database Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-34Improving Sybase Database Performance . . . . . . . . . . . . . . . . . . . . . 14-35Improving Oracle Database Performance . . . . . . . . . . . . . . . . . . . . . . 14-35

PLATINUM AutoSys User Guide for Windows NT xi ■


Maintaining Bundled Sybase SQL Servers . . . . . . . . . . . . . . . . . . . . . . . . . .14-37Sybase Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-37Sybase Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-38Default Sybase Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-38Starting Sybase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-40Stopping Sybase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-41Accessing Sybase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-42Identifying Processes Connected to the Database . . . . . . . . . . . . . . .14-42Displaying the Database Date and Time . . . . . . . . . . . . . . . . . . . . . . .14-43Bundled Sybase Backup and Recovery . . . . . . . . . . . . . . . . . . . . . . . . .14-44

15 • AutoSys AdministratorAbout the AutoSys Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-3Starting the AutoSys Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-5

AutoSys Administrator Menu Bar and Toolbar . . . . . . . . . . . . . . . . . . . 15-5AutoSys Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-9

AutoSys Administrator Instance Screen . . . . . . . . . . . . . . . . . . . . . . . .15-10AutoSys Remote Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-11

AutoSys Administrator Remote Agent Screen . . . . . . . . . . . . . . . . . . .15-12AutoSys Event Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-15

Dual Event Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-15AutoSys Administrator Event Server Screen . . . . . . . . . . . . . . . . . . . . .15-16

AutoSys Event Processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-22AutoSys Administrator Event Processor Screen . . . . . . . . . . . . . . . . . .15-23

AutoSys Notification Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-37AutoSys Administrator Notifications Screen . . . . . . . . . . . . . . . . . . . . .15-37

AutoSys System Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-40AutoSys Administrator System Information Screen . . . . . . . . . . . . . . .15-41

AutoSys Sounds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-45AutoSys Administrator Sounds Screen . . . . . . . . . . . . . . . . . . . . . . . . .15-46

AutoSys Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-48User Remote Authentication Example . . . . . . . . . . . . . . . . . . . . . . . . .15-49AutoSys Administrator Security Screen . . . . . . . . . . . . . . . . . . . . . . . . .15-50

AutoSys Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-52AutoSys Administrator Services Screen . . . . . . . . . . . . . . . . . . . . . . . . .15-52

■ xii PLATINUM AutoSys User Guide for Windows NT


16 • TroubleshootingIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-3NT Services Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-4Event Server Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-5

Event Server is Down (Sybase) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-5Sybase Deadlock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-6Not Enough User Connections (Bundled Sybase) . . . . . . . . . . . . . . . . . 16-7archive_events Fails (Bundled Sybase) . . . . . . . . . . . . . . . . . . . . . . . . . . 16-9Event Server Unable to Extend Tablespace (Oracle) . . . . . . . . . . . . . . 16-11

Event Processor Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-12Event Processor is Down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-12Event Processor Will Not Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-13

Remote Agent Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-18Remote Agent Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-18Remote Agent Will Not Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-19Remote Agent Starts, Command Runs—No RUNNING Event is Sent 16-21xql Will Not Start (Sybase Only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-24

Job Failure Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-24Remote Agent Will Start - Command Will Not Run . . . . . . . . . . . . . . 16-24

A • Integrating AutoSys with Zeke and AutoSys/Team AgentIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-3

Definition of Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-3Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-4

Job Scheduling for the Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-5Installing and Configuring for Enterprise Job Scheduling . . . . . . . . . . . . . . . A-6

Install the Basic AutoSys Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-6Install AutoSuite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-7Configure the AutoSys Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-8

Initializing the Communication Components . . . . . . . . . . . . . . . . . . . . . . . . A-12License Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-14Restart the Event Processor and Start the AutoSuite Service . . . . . . . . A-14

About the oasis_broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-15

PLATINUM AutoSys User Guide for Windows NT xiii ■


AutoSys and Zeke Cross-Platform Dependencies . . . . . . . . . . . . . . . . . . . . . A-16Job Scheduler Interdependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-17Notation for Cross-Platform Job Dependencies . . . . . . . . . . . . . . . . . . . A-18Naming Conventions for AutoSys/Zeke Cross-Platform Jobs . . . . . . . A-19

Running AutoSys Jobs on the Team Agent . . . . . . . . . . . . . . . . . . . . . . . . . . A-20Running Jobs on Team Agent Managed Machines . . . . . . . . . . . . . . . . A-21Defining Team Agent Machines to AutoSys . . . . . . . . . . . . . . . . . . . . . . A-22Team Agent Machine in an AutoSys Job Definition . . . . . . . . . . . . . . . A-23

Database Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-23Logs Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-23Zeke and Team Agent Job Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-23Unsupported Attributes for Zeke or Team Agent Jobs . . . . . . . . . . . . . . . . A-24Cross-Platform Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-26

Index

■ xiv PLATINUM AutoSys User Guide for Windows NT

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 0

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.

PLATINUM AutoSys User Guide for Windows NT xv ■

■ Preface

Contacting Technical Support

nt more

Contacting Technical Support 0

You can contact us with any questions or problems you have. You will be directed to an experienced software engineer familiar with PLATINUM AutoSys.

To send Email to PLATINUM Technical Support, use:Internet [email protected] MAIL Exchange USRWNPSN

To contact PLATINUM Technical Support, use:USA or Canada, toll free 800-833-PLAT (7528)IBM Software Mall PLATSM4CompuServe GO PLATINUM

For product assistance or information, contact:USA or Canada, toll free 800-442-6861Illinois 630-620-5000FAX 630-691-0708 or 630-691-0406Internet [email protected] Wide Web http://www.platinum.com

Our Mailing Address is:PLATINUM technology, inc.1815 South Meyers RoadOakbrook Terrace, IL 60181-5235

About This Guide 0

The PLATINUM AutoSys User Guide for Windows NT explains how to define, run, monitor, manage, and control AutoSys. It has been designed to preseinformation in a natural order so that basic concepts are discussed prior to advanced topics.

■ xvi PLATINUM AutoSys User Guide for Windows NT

Preface ■

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 Content Description

1 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.

2 AutoSys Security Provides information about permissions, superusers, and security, including examples of security on Windows NT platforms running AutoSys.

3 AutoSys Jobs Describes AutoSys job types and provides information about basic job attributes, starting parameters, and job states.

4 Job Attributes 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.

PLATINUM AutoSys User Guide for Windows NT xvii ■

■ Preface

About This Guide

5 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.

6 Introduction to the Graphical User Interface

Describes how to use the AutoSys Graphical User Interface (GUI).

7 Defining AutoSys Jobs using the Job Editor

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.

8 Defining Jobs Using JIL 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.

9 Calendar Editor 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.


■ xviii PLATINUM AutoSys User Guide for Windows NT

Preface ■

About This Guide

10 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.

11 Scheduler Console 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.

12 Managing Alarms Describes how to view and manage AutoSys alarms using the Alarm Sentry and Alarm Manager.

13 Monitoring and Reporting on Jobs

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.

14 Maintaining AutoSys Describes basic AutoSys maintenance and how to maintain a bundled Sybase database.

15 AutoSys Administrator Describes the default AutoSys configuration settings and other attributes that you can modify by using the AutoSys Administrator.

16 Troubleshooting Provides useful information about troubleshooting the primary AutoSys components.


PLATINUM AutoSys User Guide for Windows NT xix ■

■ Preface

What’s New

What’s New 0

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 0

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 0

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.

A Integrating AutoSys with Zeke and AutoSys/Team Agent

Explains how to set up and implement these enterprise-wide scheduling with AutoSys, Zeke, and Team Agent components.

Index Helps you locate information within this manual.


■ xx PLATINUM AutoSys User Guide for Windows NT

Preface ■

What’s 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 0

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 0

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.

PLATINUM AutoSys User Guide for Windows NT xxi ■

■ Preface

What’s 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 0

These are the enhancements to AutoSys security:

■ 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 0

These are the enhancements to Event Processor behavior:

■ 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.

■ xxii PLATINUM AutoSys User Guide for Windows NT

Preface ■

What’s 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 0

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:

■ 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.

PLATINUM AutoSys User Guide for Windows NT xxiii ■

■ Preface

What’s New

Enable Poems

This setting enables AutoSys to communicate with PLATINUM Event Management and Data Exchange.

Time Zone Setting 0

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 0

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 0

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.

■ xxiv PLATINUM AutoSys User Guide for Windows NT

Preface ■

Conventions

AutoSys Command Changes 0

There are changes to the following AutoSys commands:

■ autosyslog

■ 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 0

Some or all of the following conventions appear in this guide:

Symbol or Type Style Represents Example

Bold a new term ...called a source object.

alternate color

(online only) hotlinked cross-references to other 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

...see Chapter 3, Data Migration.

PLATINUM AutoSys User Guide for Windows NT xxv ■

■ Preface

Conventions

Italic words that are emphasized ...the entry after the current entry...

the titles of other documents PLATINUM General Applications Guide

syntax variables COPY filename

Monospace directories, file names, command names, computer code

&HIGHLVL.SRCLIB

computer screen text, system responses, command line commands

Copy file? Y/N

Monospace bold

what a user types ...enter RUN APP.EXE in the Application field

< > the name of a key on the keyboard

Press <Enter>.

� choosing a command from a cascading menu

File � Import � Object

Symbol or Type Style Represents Example

■ xxvi PLATINUM AutoSys User Guide for Windows NT

Preface ■

Related Publications

Related Publications 0

As you use this PLATINUM AutoSys User Guide for Windows NT, you might find it helpful to have these additional books available for reference:

■ 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.

PLATINUM AutoSys User Guide for Windows NT xxvii ■

■ Preface

Related Publications

■ xxviii PLATINUM AutoSys User Guide for Windows NT

1Introduction 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

PLATINUM AutoSys User Guide for Windows NT 1-1 ■

■ 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

■ 1-2 PLATINUM AutoSys User Guide for Windows NT

Introduction to AutoSys ■

AutoSys Jobs

AutoSys Jobs 1

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 1

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:

■ 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



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 1

The following are the main AutoSys system components:

■ 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 platform-specific; 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.



System Components

Event Server 1

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.

Figure 1-1 • AutoSys Components in a Basic Configuration

AutoSys Server(UNIX or NT)

Event Processor

Event Server(database)

Remote Agent

Remote Agent

UNIX Job

NT Job

UNIX Client

NT Client



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 1

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.



System Components

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 1

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 1

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\*.*



System Components

Note • Understanding this example will help you answer many questions that might arise during your experiences with AutoSys.

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

Figure 1-2 • Interaction of the Event Server, Event Processor, and Remote Agent

PROCESS

Event Processor•Determines Actions

•Initiates Action: Start job on machine command: ’del C:\tmp\*.*’

PROCESS

Event Server

•Events

•Job Definitions

PROCESS

Remote Agent

•Receives instructions from Event Processor

•Initiates Action: Starts Process

•Waits for Exit Code (from Pro-cess)

•Sends Exit event back to Event Server

Local Area

WorkStation_2PROCESS

NT Command

•Runs NT Command: del C:\tmp\*.*

•Completes execution and exits with status

2 3

4

5

Network

1



System Components

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 command’s exit code.

5 The Remote Agent communicates the event (exit code, status, etc.) directly to the Event Server. If the AutoSys database is unavailable for any reason, the Remote Agent will go into a wait and resend cycle until it can deliver the message.

Interface Components 1

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.



AutoSys Machines

AutoSys Machines 1

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 1

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.



Events

Events 1

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:

■ 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 job’s starting condition, that job is either started immediately, or if necessary, queued for the next qualified and available machine. The completion of one job can cause another job to be started, and in this way, jobs progress in a controlled sequence.

Alarms 1

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.



Utilities

These are some important aspects of alarms:

■ 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.

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 1

To help you define, control, and report on jobs, AutoSys has its own specification language called Job Information Language, or JIL, for defining jobs, machines, monitors, and reports. This language is processed by the jil command, which reads and interprets the JIL statements that you enter and then performs the appropriate actions, such as adding a new job definition to the database.

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.



Basic AutoSys Functionality

Basic AutoSys Functionality 1

The diagram in Figure 1-3 and the numbered explanations that follow it illustrate how AutoSys performs its most basic function—starting a job (i.e., executing a command) on a client machine.

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.

Figure 1-3 • Basic AutoSys Functionality

agent

Event Processor

Remote Agent

Client Job

8

5

9

1

7

6

3

4

2

Event Server(Database) connect

AutoSys Client



Basic AutoSys Functionality

Explanation 1

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 job’s 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.



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 1

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 PLATINUM’s 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 application-specific 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.



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.

For more information, contact your sales representative.

Figure 1-4 • AutoSys Components in an Extended Configuration

Remote Agent

Remote AgentUNIX Job

NT Job

UNIX Client NT Client

Application

AutoSys/Adapter

Other OS(e.g., AS/400)

Mainframe(MVS)

Job

Team Agent

OASIS

Zeke

AutoSys Server(UNIX or NT)

Event Processor

Event Server(database)

oasis-broker

Zeke/Team AgentCommunicator

MVS Job


2AutoSys 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


■ 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


AutoSys Security ■

Overview

Overview 2

AutoSys security includes:

■ 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 2

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:

If you start a job by sending an event, the job permissions are checked as shown in Figure 2-1.

STARTJOB FORCE_STARTJOB

KILLJOB DELETEJOB

CHANGE_STATUS CHANGE_PRIORITY

JOB_ON_HOLD JOB_OFF_HOLD

JOB_ON_ICE JOB_OFF_ICE

SEND_SIGNAL



Overview

Figure 2-1 • Security when a user starts a job by sending an event



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 2

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.



Overview

Figure 2-2 • Security when an Event Processor starts a job on an NT client machine



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 2

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:

■ AutoSys database field verification

■ Job definition encryption




■ Remote Agent authentication

■ AutoSys user and database administrator passwords

AutoSys Database Field Verification 2

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 2

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 2

AutoSys provides two Remote Agent authentication methods:

■ User authentication

■ Event Processor authentication




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.



AutoSys Job-Level Security

AutoSys User and Database Administrator Passwords 2

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.

AutoSys Job-Level Security 2

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.




AutoSys Job Ownership 2

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 2

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:

■ Owner. The user who created the job.

■ World. All users.




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 2

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:

■ Edit. Users can edit, override, or delete a job definition.

■ 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.

■ Machine. Users logged onto a machine other than the one on which a job was created can edit or execute the job.

Note • In order for a job to run on a machine other than the one on which the job was defined, the owner of that job must have an account on that machine.

Granting Permissions

The owner of a job cannot override his or her ownership designation; only the Edit Superuser has the authority to change the owner job attribute. However, the owner can grant other users edit and execute permissions for a job by using the GUI or JIL to set the permission job attribute in the job definition.




The following table shows the permissions that you can set by using JIL or the Permissions settings on the Job Editor Misc tab.

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 2

If you are defining jobs and running them on different operating systems, keep the following in mind:

■ When defining a job to run on an NT machine, you can set group permissions, but they will be ignored. Group permissions will be used if a job is edited or executed on a UNIX machine.

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).

All Hosts Edit me Users, regardless of the machine logged onto, can edit the job (otherwise, the user must be logged onto the machine specified in the owner attribute, i.e., user@host_or_domain).

World Execute wx Users can execute the job if logged onto the machine where the job was created (the machine specified in the owner attribute, i.e., user@host_or_domain).

World Edit we Users can edit the job if logged onto the machine where the job was created (the machine specified in the owner attribute, i.e., user@host_or_domain).



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 2

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 2

Only the Edit Superuser has permission to:

■ 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



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 2

Only the Exec Superuser has permission to:

■ Issue commands that affect the running or the state of any AutoSys job, either using the sendevent command or the Send Event 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 2

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.



Restricting Access to AutoSys Jobs

Then, you should determine what level of security you want, for example:

■ 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 dbspace.exe sendevent.exe

autocal.exe dbstatistics.exe sendeventgui.exe

autocal_asc.exe gatekeeper.exe svarchive.exe

autocons.exe* hostscape.exe* svload.exe

autosysadmin.exe jil.exe timescape.exe*

autosys_secure.exe jobdef.exe uninstal.exe

autotimezone.exe jobdetail.exe* xql.exe

clean_files.exe jobprofiles.exe zql.exe

dbmaint.bat jobscape.exe*



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 2

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 2

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.




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 2

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.




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.




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 2

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 job’s 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 job’s 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




If the user portion is different, but the host_or_domain portion is the same, then AutoSys checks the job’s 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 job’s 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 2

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 job’s 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 The Remote Agent tries to log on as the user@host_or_domain specified by the job’s 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 job’s 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).




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:

■ 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 2

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:

■ Example One. Describes the procedure for a job defined on a machine to run on the same machine.

■ Example Two. Describes the procedure for a job defined outside of the network domain to run on a machine in the domain.




■ Example Three. Describes the procedure for a job defined in the network domain to run on a machine outside of the domain.

■ 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.

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.”

Figure 2-3 • Network example

portland

atlantaboston

seattle

NT Workstation

oaklandNT Server

NT Workstation

NT WorkstationNT Workstation

Primary Controllerfor westcoast

Domain

westcoastDomain




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.




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.


insert_job: myjob

job_type: c

command: echo hello

machine: seattle

owner: mary@boston


1 The AutoSys Event Processor contacts the Remote Agent on the machine “seattle” and passes it the job request and the two user passwords—one for “mary@boston” and one for “mary@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.





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.




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.


insert_job: myjob

job_type: c

command: echo hello

machine: atlanta

owner: carol@westcoast


1 The AutoSys Event Processor contacts the Remote Agent on the machine “atlanta” and passes it the job request and the two user passwords—one for “carol@westcoast” and one for “carol@atlanta.”

2 If Remote Agent Event Processor authentication is enabled, the Remote Agent verifies that it has permission to process the Event Processor’s 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.


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.




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.”





insert_job: myjob

job_type: c

command: echo hello

machine: oakland

owner: joe@westcoast


1 The AutoSys Event Processor contacts the Remote Agent on the “oakland” machine and passes it the job request and two user passwords—one for “joe@westcoast” and one for “joe@oakland.”

2 If Remote Agent Event Processor authentication is enabled, the 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.


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.


3AutoSys 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


■ 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


AutoSys Jobs ■

Introduction

Introduction 3

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 3

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.


■ AutoSys Jobs

Job Types and Structure

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 3

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 job’s starting conditions can be contingent on the date, time, and the status of any other job.

Figure 3-1 • Basic Job Information, Job Types, and Actions

NameStarting ConditionsAlarmsRestart Conditions

Current statusStart timeEnd timeExit code

Definition

Current State

Command

Command to executeJob Profile for environment profileMachine to run onStandard output filesStandard input file

File Watcher

File NameMinimum File sizeWatch Interval

Container

Depends On

JobTypes

Basic JobInformation

Run Commandon Machine

Watch for FileAction

Box

Job


AutoSys Jobs ■


Command Jobs 3

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.


■ AutoSys Jobs


Box Jobs 3

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.


AutoSys Jobs ■


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 3

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.


■ AutoSys Jobs

Job Profiles

Job Profiles 3

Before running a Command Job, the AutoSys Remote Agent sets the assigned Job Profile on the job’s 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 job’s 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.


AutoSys Jobs ■

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 command’s environment, user environment variables will not be set. All other required environment variables must be defined in the job’s 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 3

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.


■ AutoSys Jobs

Job Profiles

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).

Figure 3-2 • Job Profiles Manager


AutoSys Jobs ■

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.


■ 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 3

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.


AutoSys Jobs ■

Basic Job Attributes

Command Job Attributes 3

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

File Watcher Job Attributes 3

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.


■ 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 3

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.)

Job States and Status 3

AutoSys keeps track of the current state, or status, of every job. The value of a job’s 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.


AutoSys Jobs ■


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.


■ 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.


AutoSys Jobs ■


ON_ICE

This job is removed from all conditions and logic, but is still defined to AutoSys. Operationally, this condition is like deactivating the job. It will remain on ice until it receives the JOB_OFF_ICE event.

The difference between “on hold” and “on ice” is that when an “on hold” job is taken off hold, if its starting conditions are already satisfied, it will be scheduled to run, and it will run. On the other hand, if an “on ice” job is taken “off ice”, it will not start, even if its starting conditions are already satisfied. This job will not run until its starting conditions re-occur.

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

For details on how “on ice” affects boxes, see Chapter 5, Box Job Logic.

Example State Diagram - Simple Jobs 3

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:

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.

STATE


■ AutoSys Jobs


The job starts, processes, and completes with either a failure or success exit code.

Figure 3-3 • State Diagram—Simple Jobs

FAILURESUCCESS

STARTING

EVENT

Find jobs dependenton this event.

Check Conditions

Event generated by Event Proces-sor, indicating attempt to start job on Remote Machine.

Event generated by Remote Agent indicating the job has actually been started and is now running.

Inspects Exit Code

RUNNING

Event is read by Event Processor

Event generated byRemote Agent

Event Processor

Remote Agent

- OR -

of the process.


AutoSys Jobs ■


Example State Diagram - Box Jobs 3

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.

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.

Figure 3-4 • State Diagram—Box Jobs

FAILURESUCCESS

Find jobs dependenton this event.

Check Conditions

Event sent by Event Processor indicat-ing that the box is “Running.” Nothing actually RUNS. However, this EVENT may trigger Jobs within the box to run.

Inspects Exit Status of jobs within it to determine if box is done, and if so what the Exit Status is.

Event Processor

RUNNING

EVENT

- OR -


■ 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 job’s 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 3

AutoSys determines whether or not it should start a job based on the evaluation of the starting conditions (or starting parameters) defined for the job. These conditions can be one or more of the following:

■ Date and time scheduling parameters are met (it is or has passed the specified date and time).

■ Starting Conditions specified in the job definition evaluate to true.


AutoSys Jobs ■

Starting Parameters

■ 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 3

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).


■ AutoSys Jobs

Starting Parameters

Date/Time Dependencies 3

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.


AutoSys Jobs ■

Starting Parameters

Job Dependencies Related to Job Status 3

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 single-threaded, 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:

■ 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)


■ 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.


AutoSys Jobs ■

Starting Parameters

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 instance’s 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.


■ 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.

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.

Figure 3-5 • AutoSys Instances with Cross-Instance Dependencies

Event Server

One Instance of AutoSys

Event Server

EventProcessor

OS FILE:NT Registry Settings

One Instance of AutoSys

EventProcessor

ACE PRD

condition: success(jobB^PRD) jobB

condition: success(jobE^ACE)jobE

config.EXTERNAL File

OS FILE:NT Registry Settings

config.EXTERNAL File


AutoSys Jobs ■

Starting Parameters

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 3

When cross-instance dependencies are implemented, different Event Processors can do the following:

■ 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 instance’s Event Server can be reached.

Event Servers 3

Event Servers keep track of the cross-instance job dependencies. Each time a job definition with a cross-instance job dependency is submitted to the AutoSys database, the following entries are made:

■ An entry to the ext_job table of the issuing instance. The entries in this table specify the status of jobs in other instances in which this instance has an interest.

■ 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


■ 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))


AutoSys Jobs ■

Starting Parameters

As indicated in this example, you can use any job status as part of the specification for a specific job’s starting conditions. With this latitude, you can program branching paths that must be taken and that will provide alternate actions for error conditions.

For example, if “JobB” fails after processing only partially, you might want to call a routine titled “Backout” that backs out of the changes that were made. You would specify the following job dependency in the job definition for “Backout”:

failure(JobB)

Or

f(JobB)

You use the notrunning operator to keep multiple jobs from running simultaneously (i.e., running one job is exclusive of any others). For example, it might be best not to run a database dump (“DB_DUMP”) and a file backup (“BACKUP”) at the same time. This would cause the hard disk to be accessed very frequently. However, you might have a smaller job that can run as long as both of these resource-intensive jobs aren’t running. You would specify the smaller job’s dependency like this:

notrunning(DB_DUMP) AND notrunning(BACKUP)

Note • If you have jobs that you want to run exclusively, use the virtual machine and job queueing feature described in Chapter 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.


■ 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 3

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


AutoSys Jobs ■

Starting Parameters

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.


■ 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 testif errorlevel 1 goto badgoto good:baddel test.tmp:goodexit

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.


AutoSys Jobs ■

Starting Parameters

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 filetestif errorlevel 1 goto badexit:baddel test.tmpfalse 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 3

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 manager’s 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.


■ 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 job’s condition statement:

VALUE(manager-ok) = OK

Or

v (manager-ok) = OK

Job Run Numbers and Names 3

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.


AutoSys Jobs ■

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 job’s command. This value is contained in the variable %AUTORUN%.

AutoSys also maintains a value for each job’s name, which is defined in the runtime environment for the job. As with %AUTORUN%, this value is accessible to those batch files or executables executed as the job’s command. The value is contained in the variable %AUTO_JOB_NAME%.

Defining Jobs in AutoSys 3

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.


■ AutoSys Jobs


AutoSys Graphical User Interface Components 3

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.


AutoSys Jobs ■


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.


■ AutoSys Jobs



4Job 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


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



■ Job Attributes

Date and Time Attributes and Time Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28

The Time Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-28

AutoSys Behavior During Time Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-30


Job Attributes ■

Job Attributes and Job Definitions

Job Attributes and Job Definitions 4

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 job’s 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 4

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_nameattribute:value...

where:

job_name

Is a unique job name.

attribute_keyword

Is one of the legal JIL attributes.


■ 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 4

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 4

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:

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”.

Job Type

job_type

Attribute description...

New Job dialog: Job Type

JIL Keyword Job Editor Field Name


Job Attributes ■

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 4

Attributes Common to All Job Types 4

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

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

The job type specifies the type of job: Command (c), File Watcher (f), or Box (b).

insert_job New Job and Save dialogs: Job Name

job_type New Job dialog: Job Type


■ Job Attributes


Job 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 4

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

The command attribute can be the name of any command, executable, UNIX shell script or batch file, and its arguments. When issuing commands that are to be run on a different operating system, you must use the syntax appropriate to the operating system of the client machine. The job’s owner must have execute permission for this command on the client machine. Input and output redirection cannot be part of the command. Redirection is specified by other job attributes. AutoSys global variables can be used as part of the command name itself, or as part of the command’s runtime arguments. To set a global variable, use the sendevent command, or use the Send Event 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 job’s owner must have read and execute permission on that command. (By extension, all resources and files referenced by the command’s execution must also be accessible to the job’s owner.)

owner Basic Tab: Owner

command Basic tab: Command


Job Attributes ■


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:

■ 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.


■ Job Attributes


■ Although system environment variables will be set automatically into the command’s environment, user environment variables will not be. All other required environment variables must be defined in the job’s 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 job’s 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

This attribute specifies the client machine on which the command should be run. The job’s owner must have permission to access this machine and to execute the specified command at this machine. The machine can be a specific real machine, 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).

machine Basic tab: Send to Machine


Job Attributes ■


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

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

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"

machine Basic tab: Send to Machine

watch_file File to watch


■ 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.


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

Optional Job Attributes 4

Common Job Starting Attributes 4

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

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.

date_conditions Date/Time tab: Date/Time Conditions


Job Attributes ■


Days of the Week

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

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 on—via a Custom 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

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.

days_of_week Date/Time tab: Run Days

run_calendar Date/Time tab: Run Calendar

exclude_calendar Date/Time tab: Exclude Calendar

start_times Date/Time tab: Times of Day


■ Job Attributes


Time of Day Not to Run

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 late-arriving file from causing a job to run at an inopportune time. The run window range cannot span more than 24 hours. jobs that are not in a box must have starting conditions in addition to the run_window attribute in order for the job to be automatically started.

Note • You can also block out times of day when you do not want a job to start by putting the job on hold, then taking it off hold later. The sendevent command can be used to accomplish this, executed either from the command line, through the Send Event Tool, or from within a shell script or batch file in another job.

Specific Times Every Hour to Run

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.

run_window Date/Time tab: Run Window

start_mins Date/Time tab: Minutes after Each Hour


Job Attributes ■


Job 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 job’s 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 4

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

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.

condition Basic tab: Dependencies

description Basic tab: Description


■ Job Attributes


Box Name

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

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

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.

box_name Basic tab: Box

min_run_alarm Alarms/Terminators tab: Minimum Run Time

max_run_alarm Alarms/Terminators tab: Maximum Run Time


Job Attributes ■


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

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

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

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.

term_run_time Alarms/Terminators tab: Terminate this job n mins after starting

alarm_if_fail Alarms/Terminators tab: Send Alarm if this job fails

box_terminator Alarms/Terminators tab: If this Job fails, terminate the box it is in


■ Job Attributes


Terminate the Job if the Box Fails

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

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).

job_terminator Alarms/Terminators tab: If the box fails, terminate this job

n_retrys Misc tab: Number of times to restart this job after a failure


Job Attributes ■


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

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.

timezone Date/Time tab: Time Zone


■ Job Attributes


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

This feature is only for jobs in a box. When a job is in a box, it inherits the box’s starting conditions. This means that when a box goes into the RUNNING state, the Box job will start all the jobs within it (unless other conditions are not satisfied). This is typically the desired behavior; however, there are occasions when it is not.

For example, you might want to place a job in a box, but not start the job until a non-job (i.e., operating system level) event arrives. By specifying “yes” to Autohold On, AutoSys automatically changes the job state to ON_HOLD when the box it is in begins RUNNING. At this point, the job is in exactly the same state as if it were manually placed on hold. To start the job, take the job off hold by sending the JOB_OFF_HOLD event via the Send Event Tool or the sendevent command.

Permissions

The AutoSys permission scheme provides users with Edit and Execute permissions on a per job basis.

auto_delete Misc tab: Delete Job after completion

auto_hold Misc tab: AutoHold on for jobs in boxes

permission Misc tab: Permissions


Job Attributes ■


For NT by default, only a job’s 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 4

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

The profile attribute specifies the name of the defined job profile that contains the environment variables that should be set for the command’s execution. You can add and delete job profiles using the Profiles Manager, which you can open from the AutoSys program group. (For

profile Resource Profile: Job Environment Profile


■ 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 job’s 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 job’s associated profile.

Redirection of the Standard Input File

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 command’s 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:.

std_in_file Command Info tab: File to redirect standard input


Job Attributes ■


Redirection of the Standard Output File

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 command’s 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.

std_out_file Command Info tab: File to redirect standard output


■ Job Attributes


Redirection of the Standard Error File

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 command’s 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.


std_err_file Command Info tab: File to redirect standard error


Job Attributes ■


Job Load

Machines can be assigned “maximum job loads,” which is a measure of the CPU load that is desirable for a machine at any given time. Similarly, jobs can be assigned loads, indicating the relative amount of processing power they consume. This scheme allows for machine loading to be controlled, and prevents a machine from being overloaded. If a job is ready to run on a designated machine, but the current load on that machine is too large to accept the new job’s load, the job will be “queued” for that machine, to be run when sufficient resources are available. For load balancing to function properly, all jobs to be run on a controlled machine must have job loads specified; otherwise, their impact on a machine cannot be measured.

Note • If you force a job to start, it will run even if its load exceeds the machine’s max_load. Also, if job_load is specified for a job and no priority attribute (described below) is set, AutoSys uses the default priority of 0, which means ignore the job_load and run the job immediately.

For information about load balancing on machines, see Chapter 10, Load Balancing and Queuing Jobs.

Queue Priority

The queue priority establishes the relative priority of all jobs queued for a given machine, with the lower number indicating higher priority. If a job is ready to run on a designated machine, but the current load on that machine is too large to accept the new job’s load, the job will be “queued” for that machine.

priority only influences the starting of jobs that are queued, unless the jobs are in a box. If jobs in a box have a priority attribute setting, they will be processed in order of priority, highest to lowest.

job_load Command Info tab: Job Load

priority Command Info tab: Que priority


■ Job Attributes


Job Overrides

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:

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

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

override_job File menu and Basic tab: Add One Time Override

auto_hold min_run_alarm std_in_file

command n_retrys std_out_file

condition profile term_run_time

date_conditions run_calendar watch_file

days_of_week run_window watch_file_min_size

exclude_calendar start_mins watch_interval

machine start_times

max_run_alarm std_err_file

max_exit_success Command Info tab: Maximum Exit Code for SUCCESS


Job Attributes ■


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

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

In AutoSys, heartbeats are a means of monitoring a job’s progress. It automates the common practice of outputting characters, similar to displaying “progress” asterisks across the screen as a process runs. If a job does not send a heartbeat within this specified interval, a HEARTBEAT alarm is generated. The heartbeat interval is specified in minutes.

To send a heartbeat from a C program, you call the routine found in the following source file:

%AUTOSYS%\code\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.

avg_runtime (JIL only)

heartbeat_interval Command Info tab: Heartbeat interval (mins)


■ Job Attributes


Resource Check - File 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

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 isn’t 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.

chk_files Resource/Profile tab: Resource Check - File System Space...

watch_file_min_size Basic tab: Minimum file size (in bytes)


Job Attributes ■


Watch Interval

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

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.


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

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

watch_interval Basic tab: Time Interval (secs) to determine steady state


box_success Basic tab: Success Conditions


■ 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

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 and Time Changes 4

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 4

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.

box_failure Basic tab: Failure Conditions


Job Attributes ■


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.

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.

Figure 4-1 • Change from ST to DT

Figure 4-2 • Change from DT to ST

1:00 1:59

3:00 4:00 5:00

Daylight-saving Time

Standard Time

1:00 1:59

3:00


Standard Time

1:00 2:00 4:00

0:00


■ Job Attributes


AutoSys Behavior During Time Change 4

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:

■ days_of_week

■ exclude_calendar

■ run_calendar

■ run_window

■ start_times

Relative times are specified with respect to either the current time, or relative to the start of the hour. For example, start a job at 10 and 20 minutes after the hour, or terminate a job after it has run for 90 minutes. Relative time dependent job attributes include:

■ auto_delete

■ max_run_alarm

■ min_run_alarm

■ start_mins

■ term_run_time

■ watch_interval

During the time change, absolute time attributes will behave differently than relative time attributes, as described below.


Job Attributes ■


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 WindowsRun 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


■ 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).

Figure 4-3 • Scheduling between 1:00 - 1:59, DT to ST

1:00 1:59

3:00


Standard Time

1:00 2:00

0:00

start_time attributeruns in second hour

start_mins attribute runs in both hours


Job Attributes ■


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 WindowsRun 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.


■ Job Attributes



5Box 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


■ Box Job Logic

Using the Box Terminator Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-16

Using the Job Terminator Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-17

Advanced Job Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-18


Box Job Logic ■

Basic Box Concepts

Basic Box Concepts 5

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 5

Some important rules to remember about boxes are:

■ Jobs run only once per box execution.

■ Jobs in a box will start only if the box itself is running.

■ As long as any job in a box is running, the box remains in RUNNING state; the box cannot complete until all jobs have run.

■ By default, a box will return a status of SUCCESS only when all the jobs in the box have run and the status of all the jobs is “success.”

Default SUCCESS is described in Default Box Success and Box Failure on page 5-13.

■ By default, a box will return a status of FAILURE only when all jobs in the box have run and the status of one or more of the jobs is “failure.”

Default FAILURE is described in Default Box Success and Box Failure on page 5-13.

■ Unless otherwise specified, a box will run indefinitely until it reaches a status of SUCCESS or FAILURE. For a description of how to override this behavior, see Box Job Attributes and Terminators on page 5-6.

■ Changing the state of a box to INACTIVE (via the sendevent command) changes the state of all the jobs in the box to INACTIVE.


■ Box Job Logic

Basic Box Concepts

When you Should Not Use a Box 5

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 5

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.


Box Job Logic ■

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”.

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.

Figure 5-1 • Example Box Job

job_a

job_c

simple_box SUCCESS

job_b

job_b


■ 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.

Box Job Attributes and Terminators 5

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 5

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.


Box Job Logic ■


Attributes in a Job Definition 5

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 5

Each job in a box will run only once per box execution. Therefore, you should not define more than one time attribute for any job in a box because the job will only run the first time. If you want to put a job in a box, but you also want it to run more than once, you must assign multiple start time conditions to the box itself, and define no time conditions for the job.

Remember also that the box must be running before the job can start. Do not assign a start time for a job in a box if the box will not be running at that time. If you do, the next time the box starts, the job will start immediately.

The following example illustrates a scenario that would not work properly if placed in a box.

“job_a” is defined to run repeatedly until it succeeds. “job_report” has one starting condition—the success of “job_a”.


■ Box Job Logic


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 5

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.

Figure 5-2 • Box Job with Time Conditions

job_a

job_reportsuccess(job_a)

Report success of job_a

bx_stat3:00 a.m. Daily

run until succeed


Box Job Logic ■


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.

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 5

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.

Figure 5-3 • Example Box Job

job_Fwatch run_statssuccess(job_Fwatch)

Run Statistics

report_statssuccess(run_stats)

Report Statistics

bx_report3:00 a.m. Daily

Watch for file

box_terminator: y


■ Box Job Logic

Examples

If another AutoSys job is dependent on the status of the box, the status change could trigger the job to start. If the box status does not change, dependent jobs are not affected.

If the box contains other jobs in addition to the job that changed status, the status of the box will be re-evaluated according to the success or failure conditions assigned to the box (either the default or user-assigned). Any jobs in the box with a status of INACTIVE are ignored when the status of the box is being re-evaluated. For example, consider an INACTIVE box that contains four jobs, all with a status of INACTIVE (this is typical of a newly created box). If one of the jobs is force started and completes successfully, the status of the box will change to SUCCESS even though none of the other jobs ran.

Examples 5

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.

Table 5-1 • How Job Status Changes Impact Box Status

Current Box Status New Job Status New Box Status

SUCCESS TERMINATED or FAILURE FAILURE

SUCCESS SUCCESS Box status does not change

FAILURE SUCCESS SUCCESS

FAILURE FAILURE Box status does not change

INACTIVE SUCCESS SUCCESS

INACTIVE TERMINATED or FAILURE FAILURE

TERMINATED any change Box status does not change


Box Job Logic ■

Examples

Advanced Conditions in Box Jobs 5

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:

■ 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.


■ Box Job Logic

Examples

Figure 5-4 • Advanced Box Job Example

SUCCESS

bx_daily_update

job_update

job_update

SUCCESS job_run_stats

job_report_stats

FAILURE job_update

FAILURE job_run_stats

FAILURE bx_daily_update

SUCCESS job_trigger_msg

SUCCESS bx_daily_update

3:00 a.m. daily

box_terminator: yUpdate files

success(job_run_stats)Report statistics

job_run_statssuccess(job_update)box_terminator: yRun statistics

job_trigger_msgfailure(bx_daily_update)Page operator

SUCCESS job_report_stats FAILURE job_report_stats


Box Job Logic ■

Examples

Default Box Success and Box Failure 5

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.


■ Box Job Logic

Examples

Figure 5-5 • Box Success and Failure

SUCCESS

update_accounts

SUCCESS

run_stats

SUCCESS

report_stats

Job Stream

FAILURE

FAILURE

FAILURE

Box FAILURE Box Still RUNNINGBox SUCCESS

ACTIVATED

ACTIVATED

ACTIVATED

Job Status

success(update_accounts)

success(run_stats)


Box Job Logic ■

Examples

Explicit Box Success and Box Failure 5

Figure 5-6 • Success and Failure Conditions

SUCCESS

update_accounts

SUCCESS

run_stats

SUCCESS

report_stats

Job Definitions

Job Streamdo_statistics

FAILURE

FAILURE

FAILURE

FAILURE

INACTIVE

FAILURE FAILURE

INACTIVE

Job Status

Box

do_statistics3:00 a.m. Daily

INACTIVE

box_success: success(update_accounts) AND success(run_stats) ANDsuccess(report_stats)box_failure: failure(update_accounts) OR failure(run_stats) ORfailure(report_stats)

SUCCESS

update_accounts run_stats

success(update_accounts)

Run Statistics

report_stats

success(run_stats)

Report StatisticsUpdate Files


■ Box Job Logic

Examples

Using the Box Terminator Attribute 5

Figure 5-7 • Using box_terminator

daily_receipts

daily_receipts daily_payables

Process Payables

daily_balancesuccess(daily_reciepts)

Calculate Balance

SUCCESS

daily_payables

daily_accounts3:00 a.m. Daily

daily_balance

Process Receipts

Job Definitions

Job Stream

daily_accounts

box_terminator: ybox_terminator: yAND success(daily_payables)

SUCCESS

FAILURE FAILURE

TERMINATED TERMINATEDBox SUCCESS


Box Job Logic ■

Examples

Using the Job Terminator Attribute 5

Figure 5-8 • Using job_terminator

daily_receipts

daily_receipts daily_payables

Process Payables

daily_balancesuccess(daily_reciepts)

Calculate Balance

SUCCESS

daily_payables

daily_accounts3:00 a.m. Daily

daily_balance

Process Receipts

Job Stream

daily_accounts

job_terminator: yAND success(daily_payables)

SUCCESS

FAILURE

FAILURE

FAILURE

FAILUREBox

TERMINATE

Job Definitions


■ Box Job Logic

Examples

Advanced Job Streams 5

Scenario on the first of the month

The first time cycle is run (e.g., January 1), statuses behave as expected.

Figure 5-9 • Jobs Run the First of Month

SUCCESS

SUCCESS

Date/Time Met

job_monthly

Job Dependency

job_daily

Job Stream

ConditionsStart

Condition Met

Start

Job Definitions

Date/Time MetConditions

SUCCESS

Event Status inAutoSys Database =

File fromMainframe


Start

SUCCESS

job_Fwatch

job_monthly job_daily

2:00 a.m. First Daysuccess(job_monthly)

Generate ReportRe-index, Organize, Purge

3:00 a.m. Daily

job_Fwatch

1:00 a.m. First Day

Watch for File

of Month of Monthsuccess(job_Fwatch)

Job DependencyCondition Met

term_run_time: 90


Box Job Logic ■

Examples

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.

Figure 5-10 • Jobs Run the Second of Month

Date/Time job_monthly

Job Stream

NOT Conditions Met



Generate Report

NOT RUN

Job Definitions

Re-index, Organize, Purge

3:00 a.m. Daily

File fromMainframe

job_Fwatch

1:00 a.m.First Day

Watch for File

Date/Time

NOT Conditions Metjob_Fwatch

of Month of Month

SUCCESS

Job Dependency

job_daily

Condition Met

Start


SUCCESS (from Jan 1)


success(job_Fwatch)

Job DependencyCondition NOT Met

NOT RUN

term_run_time: 90


■ 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.

Figure 5-11 • Incorrect Job Stream Logic

Date/Time job_monthly

Job Stream

Conditions Met



Generate Report

NOT RUN

Job Definitions


3:00 a.m. Daily

File fromMainframe

job_Fwatch

1:00 a.m.First Day

Watch for File

Date/Time Conditions Met

job_Fwatch

of Month of Month

SUCCESS

Job Dependency

job_daily

Condition Met

Start


SUCCESS (from Jan 1)


success(job_Fwatch)


term_run_time: 90

Start

TERMINATED

term_run_time: 90

Undesirable Result


Box Job Logic ■

Examples

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.

Figure 5-12 • Changing Job Status

Date/Time

job_monthly

Job Stream

Conditions Met



Generate Report

NOT RUN

Job Definitions


3:00 a.m. Daily

File from

Mainframe

job_Fwatch

1:00 a.m.First Day

Watch for File

Date/Time Conditions Met

job_Fwatch

of Month of Month

Job Dependency

job_daily

Condition NOT Met


INACTIVE


success(job_Fwatch)

Job Dependency

Condition NOT Met

term_run_time: 90

Start

TERMINATED

term_run_time: 90

Desirable Result

using GUI Send Event dialog or by issuing the following command:

NOT RUN

sendevent -E CHANGE_STATUS -S INACTIVE -J job_monthl

At 1:00 a.m. on first day of month, issue a CHANGE_STATUS on “job_monthly”


■ 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.

Figure 5-13 • Changing Status using Box Jobs

job_monthly

File fromMainframe


Start

SUCCESS

job_Fwatch

SUCCESS

SUCCESS

Job Dependency

job_daily

Condition Met

Start



success(box_monthly)


3:00 a.m. Dailyjob_Fwatch1:00 a.m.First Day

Watch for File

of Month success(job_Fwatch)box_terminator: y

box_monthly

box_monthly

FAILURE

TERMINATED

Generate Report



NOT RUNjob_daily

job_terminator: y


6Introduction 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


■ Introduction to the Graphical User Interface

Starting the GUI Control Panel

Starting the GUI Control Panel 6

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.

Using the GUI Control Panel 6

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

GUI Control Panel Menu Bar 6

The GUI Control Panel has the following menus:

■ File

■ Tools

■ Preferences

■ Help

Figure 6-1 • GUI Control Panel


Introduction to the Graphical User Interface ■

Using the GUI Control Panel

File Menu

The File menu contains the following options:

Tools Menu

The Tools menu contains the following options:

Iconize All Minimizes all the open AutoSys Graphical User Interface windows and dialogs.

Exit Closes all of the Graphical User Interface windows and dialogs, as well as the GUI Control Panel.

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.

Run Status Tool 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.

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.




Preferences Menu

The Preferences menu contains the following options:

Help Menu

The Help menu contains the following options:

GUI Control Panel Buttons 6

These are the Control Panel buttons and the actions they perform:

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.

Remove All User Settings

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.

Contents Displays the on-line help table of contents.

About Displays GUI Control Panel version number.

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.


Introduction to the Graphical User Interface ■


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.

Calendar Editor Displays the Calendar Editor window, which allows you to define AutoSys run and exclude calendars. For information, see Chapter 9, Calendar Editor.

Alarm Manager Displays the Alarm Manager application, which allows you to view and respond to alarms across multiple instances. For information, see Chapter 12, Managing Alarms.

Alarm Sentry 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.

Monitor/Browser Editor

Displays the Monitor/Browser Editor, which allows 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.

JobScape Displays the AutoSys/Xpert JobScape window, used for viewing job progressions (and their dependencies) in real-time or simulated mode.

TimeScape Displays the AutoSys/Xpert TimeScape window, used for viewing job progressions (across time) in real-time, real-time with projection, or simulated mode.

Exit Exits the GUI Control Panel.




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.


7Defining 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


■ 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


Defining AutoSys Jobs using the Job Editor ■

Starting the Job Editor

Starting the Job Editor 7

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.



Using the Job Editor Interface

Using the Job Editor Interface 7

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.

Figure 7-1 • Job Editor




Job Editor Menu Bar 7

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.

Save 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.




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 instance’s database and maintains that connection until you close the Job Editor.

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.

Delete 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 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.

Export 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.

Print Prints the JIL definition for the current job.

New Job Editor Displays a new, empty Job Editor window.

Exit Closes the Job Editor.




Edit Menu

The Edit menu contains the following option:

Options Menu

The Options menu contains the following option:

Help Menu

The Help menu contains the following option:

Clear Clears the Job Editor without affecting the database, but maintains the current job name.

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.

Contents Displays the Contents of the AutoSys Help.

About Displays the Job Editor version number.




Job Editor Tabs 7

The Job Editor displays all or part of the following tabs, depending on what job type you are defining:

Job Editor Status Area 7

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.

Basic Scheduling Contains the job description and basic job attribute fields.

Date/Time 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.

Command Info Contains the queuing and load balancing, exit code, heartbeat interval, and file redirect settings.

Resource/Profile Contains the resource check and the path to the job profile settings.




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:

Required Values for Box Jobs

Name, Job Type, and Owner are the only required values for Box Jobs.

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.

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.



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:

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.

Creating a Simple Command Job 7

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

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).

File to watch Indicates the name of the file to watch for. This must be a legal filename and full path to the file.




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 Owner’s 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.



Creating a File Watcher Job

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.

Creating a File Watcher Job 7

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.

Figure 7-2 • Job Editor for Command Job “test_run”




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 Owner’s user account on the machine.

5 In the Time Interval (secs) to determine steady state field, enter the following time interval:

60




This setting indicates that AutoSys will check for the file’s 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.



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.



Creating a Dependent Command Job

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 7

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.

Figure 7-3 • Job Editor for File Watcher Job “EOD_watch”




To create a Command Job with dependencies



A New Job dialog opens, in which you can enter the Name, Instance, and Job Type.


a Enter EOD_post for the Name.


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 owner’s 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.




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 Owner’s user account on the machine.

6 Choose File � Save, which opens the Save As dialog opens, and click OK.



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 job’s 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.





Figure 7-4 • Job Editor with Dependent Command Job “EOD_post”



Creating a Box Job

Creating a Box Job 7

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:

■ 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 7

To define a Box Job



The New Job dialog opens.


a Enter EOD_box for the Name.


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.



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



Creating a Box Job


Modifying the EOD_post Command Job 7

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


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.



Creating a Box Job

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.

Figure 7-6 • Open Dialog



Setting Date and Time Dependencies

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 7

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.

Figure 7-7 • Box Selection Dialog




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.

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.

Figure 7-8 • Job Editor Date/Time Tab




Setting Days of the Week Starting Conditions 7

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.




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 7

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.




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 7

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.




To modify the test_run job to add time and date dependencies

Follow these steps using the open Job Editor.


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).


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.



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.

Deleting Jobs 7

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.

Figure 7-9 • Date/Time Tab for test-run



Deleting Jobs

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).

Figure 7-10 • Delete Jobs Dialog



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 7

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 7

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 7

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.




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.


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 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 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.




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 7

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.




Enabled Job Editor Fields for One-Time Overrides 7

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 Fields

Basic Scheduling ■ Command

■ Dependencies

■ Send To Machine

Date/Time ■ All conditions, except the Time Zone setting

Alarms/Terminators ■ Minimum Run Time (Alarms)

■ Maximum Run Time (Alarms)

■ Terminate this job minutes after starting (Terminators)

Misc ■ Number of times to restart this job after failure

■ Delete Job after completion

■ AutoHold for jobs in boxes

Command Info ■ File to redirect standard input

■ File to redirect standard output

■ File to redirect standard error

Resource/Profile ■ Job Environment Profile




Table 7-2 • Job Editor Fields for Box Job Overrides

Tab Fields

Basic Scheduling ■ Dependencies











Table 7-3 • Job Editor Fields for File Watcher Job Overrides

Tab Fields

Basic Scheduling ■ File to watch

■ Dependencies

■ Send To Machine

■ Time interval (secs) to determine steady state

■ Minimum file size (in bytes)








Resource/Profile ■ Job Environment Profile


8Defining 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


■ 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


Defining Jobs Using JIL ■

Job Information Language (JIL)

Job Information Language (JIL) 8

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 instance’s 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 8

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.




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: upper- and lowercase letters, hyphens, underscores, numbers, colons (if the colon is escaped with quotes or a preceding backslash), and the special character “@”.

Rule 6

Any colons used in an attribute statement’s value setting must be escaped, because JIL parses on the combination of keyword followed by a colon. For example, to specify the time to start a job, specify 10:00. The colon may also be escaped with a preceding backslash “\”, as in 10\:00.




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:

■ 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 8

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 Action

insert_job Add a new job to AutoSys.

update_job Edit fields on an existing job.

delete_job Delete an existing job from the AutoSys database.

delete_box Delete an existing Box job, and recursively delete all the jobs which are contained in the box.

override_job Apply overrides on indicated job attributes for the next run of this job.




Submitting Job Definitions 8

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):

■ 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 8

After a job definition has been submitted to the AutoSys database, it will be started according to the starting parameters specified in its JIL script. That is, the Event Processor will continually poll the database and when it determines that the starting parameters have been met, it will run the job.

If a JIL script does not specify any starting parameters for a job, the job will not be started automatically by the Event Processor; it will start only if you issue the sendevent command. For example, assume a job named “test_install” has no starting parameters specified in its JIL script. The only way to start it would be to issue the following command:

sendevent -E STARTJOB -J test_install

This command tells the Event Processor to start the job named “test_install”.




For more information about the sendevent command, see its definition in Chapter 1, AutoSys Commands in the AutoSys Reference Guide for Windows NT.

Creating a Simple Command Job 8

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_runjob_type: c /*(optional, it is the default) */machine: tibetcommand: "C:\MYAPPS\DOREPORTS.BAT"

This JIL script instructs AutoSys:

■ 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.

Creating a File Watcher Job 8

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_watchjob_type: fmachine: tibetwatch_file: "C:\tmp\EodTransFile"watch_interval: 60watch_file_min_size: 50000





■ To add a new job named “EOD_watch”.

■ That the new job will be a File Watcher Job.


■ 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.

Until the minimum file size of 50,000 bytes has been reached, the file won’t be considered by AutoSys as “complete.” When the file reaches this minimum size and does not change between check intervals (60 seconds in this example) it is considered compslete (also known as “steady state”). When this occurs, the File Watcher Job will end with a SUCCESS condition.

Creating a Dependent Command Job 8

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.




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_postjob_type: cmachine: tibetcondition: success(EOD_watch)command: %HOMEPATH%\POST.EXE


■ To add a new job named “EOD_post”.

■ That the new job will be a Command Job.


■ 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 owner’s 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.)



Creating a Box

Note • The job’s 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 job’s 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 8

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.



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_boxjob_type: b condition: success(EOD_watch)


■ 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 8

To place an existing job in a box, you need to change the “EOD_post” Command Job that was created above. You will place the “EOD_post” job in the newly-created box.

You should make sure a job is not running before you modify or delete it.

To change a job, you can either use the update_job sub-command, or you can delete the job definition, using the delete_job sub-command, then redefine the job using the insert_job sub-command. The latter scenario is particularly useful when many non-default attributes have been specified, and you want to “unset” them rather than “reset” them; in other words, you want to de-activate them. However, you’ll have to re-specify any of the attributes that need to remain the same. So, in the



Setting Time Dependencies

example below, you’ll use the update method. The JIL script required to change the “EOD-post” job and to put it in the “EOD_box” is given below:

update_job: EOD_postcondition: NULLbox_name: EOD_box


■ 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 box’s starting parameters.

Setting Time Dependencies 8

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_rundate_conditions: ydays_of_week: mo, we, frstart_times: "10:00, 14:00"


■ To update the job named “test_run”.

■ Activate the conditions based on date.



Setting Time Dependencies

■ 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 8

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



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 8

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 8

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.



Specifying One-Time Job Overrides

Specifying One-Time Job Overrides 8

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 min_run_alarm std_in_file

command n_retrys std_out_file

condition profile term_run_time

date_conditions run_calendar watch_file

days_of_week run_window watch_file_min_size

exclude_calendar start_mins watch_interval

machine start_times

max_run_alarm std_err_file



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 8

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: RunDatacondition: NULLstd_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.



Example JIL Script

Example JIL Script 8

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”:

■ 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_Downloadjob_type: bdate_conditions: yesdays_of_week: allstart_times: "02:00"

insert_job: Watch_4_filejob_type: fbox_name: Nightly_Downloadwatch_file: "C:\DOWNLOAD\MAINFRAME\SALES.RAW"machine: gateway

insert_job: filter_datajob_type: cbox_name: Nightly_Downloadcondition: success(Watch_4_file)command: filter_mainframe_infomachine: gatewaystd_in_file: "C:\DOWNLOAD\MAINFRAME\SALES.RAW"std_out_file: "C:\DOWNLOAD\MAINFRAME\SALES.SQL"std_err_file: "C:\LOG\FilterMFLog.err"



Example JIL Script

insert_job: update_DBMSjob_type: cbox_name: Nightly_Downloadcondition: success(filter_data)machine: gatewaycommand: isql -U mutt -P jeffstd_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.


9Calendar 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


■ 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


Calendar Editor ■

Introduction

Introduction 9

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:

■ 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.


■ Calendar Editor

Using Defined Calendars

Using Defined Calendars 9

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 9

In the job definition, use one of the following methods to apply a calendar:

■ 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.


Calendar Editor ■

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.

■ 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.


■ Calendar Editor

Starting the Calendar Editor

Starting the Calendar Editor 9

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


Calendar Editor ■

Using the Calendar Editor Interface

Using the Calendar Editor Interface 9

The Calendar Editor is divided into the following regions:

■ Menu Bar

■ Navigation Controls

■ Calendar Display

Using the Menu Bar 9

At the top of the Calendar Editor is the menu bar that contains the following menus: File, Edit, Utilities, Preferences, and Help.

File Menu


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.

Open Displays the Calendar Selection dialog that you can use to open an existing calendar.

Save 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.


■ 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.

Delete Displays the Delete Calendar dialog in which you can search for and select the calendar or calendars to delete.

Rename 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.

Import 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.

Export All 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.

Print Prints the current calendar in text format.

Graphical Print Prints the current calendar in a graphical format, as it appears on the screen.


Calendar Editor ■


Note • When you first select an instance in any of the Calendar Editor dialogs, AutoSys establishes a connection to that instance’s database. It maintains that connection until you close the Calendar Editor.

Edit Menu

The Edit menu contains the following options:

New Calendar Editor

Opens another Calendar Editor window. When you open other Calendar Editors, each window is numbered sequentially.

Exit Exits the application.

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.

Revert Resets the state of all the dates in the current calendar to those last saved to the AutoSys database.

Clear Clears the calendar settings; all dates are returned to the unset state.


■ Calendar Editor


Utilities Menu

The Utilities menu contains the following option:

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:

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.

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.


Calendar Editor ■


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:

■ Unset dates use the background color of the Calendar Editor application

■ Selected dates use green

■ Conflicting dates use red

■ Blocked dates use black

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:

■ One—Indicates one year, or the default setting.

■ Two—Indicates to include through the next year, two years.

■ Three—Indicates to include three years.

■ Four—Indicates to include four years.

■ Five—Indicates to include five years.

■ Ten—Indicates to include ten years.

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.


■ 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


Using the Navigation Controls 9

The Navigation controls area of the window contains the following:

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:

■ 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.

Contents Displays the table of contents for the AutoSys Help.

About Displays the Calendar Editor version number.

Selections area Allows you to navigate through and select dates.

Conflicts area Allows you to view the number of Conflicts and navigate through them.

Instance drop-down list

Allows you to select the instance to which you want to connect.

Calendar drop-down list

Allows you to select a defined calendar to be displayed in the Calendar Editor.


Calendar Editor ■


■ 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).


■ Calendar Editor


Using the Calendar Display 9

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:

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.

Unset Indicates the date is not set. When you open a new calendar, all of the dates are unset.

Selected Indicates the date is set for that calendar.

Blocked Indicates the date is ineligible for setting when applying a rule.


Calendar Editor ■


In addition to these three user-selectable states, there is a fourth, system-generated state called the “Conflicting” state. This state occurs when both of the following are true:

■ 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 lost—they 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.


■ Calendar Editor

Creating and Modifying Calendars

Creating and Modifying Calendars 9

Using the basic features of the Calendar Editor, you can define calendars and open existing calendars to create and modify calendars.

Creating a Calendar 9

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


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.


Calendar Editor ■


Setting Dates Prior to Today’s 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.

Figure 9-2 • Example Calendar Definition


■ Calendar Editor


Opening an Existing Calendar 9

To open a saved calendar


The Calendar Selection dialog appears, as shown in Figure 9-3.

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.

Figure 9-3 • Calendar Selection Dialog


Calendar Editor ■

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 9

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.


■ Calendar Editor


The Term Calendar Rule dialog is divided into the following regions:

Figure 9-4 • Term Calendar Rule Dialog

Rule Specification The top portion of the dialog.

Apply Rescheduling Rule

The lower portion of the dialog.

Control 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.


Calendar Editor ■


Using the Rule Specification Area 9

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:

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:

Action Allows you to set the action the rule will initiate.

Date Range Allows you to set the range of dates the rule will include.

Date Selection Rule

Allows you to set the Occurrences, Day, and Period for the rule.

Set Dates Changes the state of the selected dates to Selected.

Unset Dates Changes the state of the selected dates to Unset.

Block Dates Changes the state of the selected dates to Blocked, so that this date will not be set during any subsequent rule applications.


■ 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 today’s 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.

Day 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.


Calendar Editor ■


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.

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.


■ Calendar Editor


3 In the Date Range area, do not change the default All Days in Range setting, which indicates the calendar’s 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 calendar’s 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.


Calendar Editor ■


Example ThreeContinuing 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 9

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.


■ 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 Day Area

In addition to specifying the Move Direction, you must specify one of the following To Day options:

To Previous Moves the Selected state backward in the calendar.

To Following Moves the Selected state forward in the calendar.

Any Day Indicates the next available date.

Weekday Indicates the next available weekday date.

In Calendar Indicates the next available date in the specified calendar. Use the drop-down list to select an existing calendar.

Not in Calendar Indicates to use the next available date not Selected in the specified calendar. Use the drop-down list to select an existing calendar.


Calendar Editor ■


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.


■ 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 9

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 9

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.


Calendar Editor ■

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 9

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.


■ Calendar Editor

Importing and Exporting Calendars

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.

Importing and Exporting Calendars 9

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.

Figure 9-5 • Job Definition Reference List


Calendar Editor ■


Importing Calendar Text Files 9

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.


■ Calendar Editor


Exporting Calendars 9

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.


10Load 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


■ 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

Subsets—Individual Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-19

Multiple Machine Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-21

User-Defined Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-22


Load Balancing and Queuing Jobs ■

Real Machines

Real Machines 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 10

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.

By defining virtual machines to AutoSys, and then submitting jobs to run on those machines, you can specify:

■ Runtime resource policies (or constraints) at a high level.

■ That AutoSys automatically execute those policies in a multi-machine environment.



Defining Machines to AutoSys

Defining Machines to AutoSys 10

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

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:

■ 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.




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 machine’s 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 machine’s 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 machine’s resources.




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) 10

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 attribute’s 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.

Using max_load and factor 10

The max_load attribute is primarily used to limit the loading of a machine. As long as a job’s load will not cause a machine’s 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.




Machine Definitions 10

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 Real NT

insert_machine: toad insert_machine: tiger

max_load: 100 type: n

factor: .8 max_load: 100

factor: .8

Virtual UNIX Virtual NT

insert_machine: pond insert_machine: jungle

machine: toad type: n

machine: frog machine: tiger

machine: monkey



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 10

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.

Figure 10-1 defines a real UNIX machine named “jaguar” with a max_load of 100 and a factor of 1.0.

To define a real NT machine named “tiger”, enter the following JIL statements:

insert_machine: tigertype: n max_load: 100factor: 1.0

Figure 10-1 • Real UNIX Machine with max_load 100 and factor 1.0

insert_machine: jaguartype: rmax_load: 100factor: 1.0

jaguar1001.0

max_loadfactor



Defining a Virtual Machine

Deleting Real Machines 10

The following JIL statement deletes the real machine definition for the machine named “jaguar”:

delete_machine: jaguar

Defining a Virtual Machine 10

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.

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.

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.)

Figure 10-2 • Virtual Machine with Two Real UNIX Machine Components

modenainsert_machine: modenatype: vmachine: ferrarimachine: lambo

lamboferrari




insert_machine: fiattype: rmax_load: 100factor: 1

insert_machine: lotustype: r max_load: 80factor: .9

insert_machine: capritype: vmachine: fiatmachine: lotus

Figure 10-3 defines a virtual NT machine named “garden” comprised of two real NT machines named “rose” and “lily”.

The following JIL statements define the two real NT machines.

insert_machine: rosetype: n max_load: 100factor: 1insert_machine: lilytype: n max_load: 80factor: .9

Figure 10-3 • Virtual Machine with Two Real NT Machine Components

gardeninsert_machine: gardentype: nmachine: rosemachine: lily

rose1001.0

lily80.9




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”.

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: nmachine: pumamax_load: 10factor: 1.0machine: lionmax_load: 9factor: .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: modenamachine: lambo

Figure 10-4 • Virtual UNIX Machine Comprised of Subsets of Real Machines

fiat lotus

10 9

insert_machine: mustangtype: v machine: fiatmax_load: 10machine: lotusmax_load: 9



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 don’t have to specify any of the component real machines. The real machines are still defined—only the virtual machine they were in is deleted. The following JIL statement deletes the virtual machine named “mustang”:

delete_machine: mustang

Because the real machines “fiat” and “lotus” had been individually defined outside of the virtual machine, their individual definitions remain in effect.

Load Balancing 10

By specifying a virtual machine or a list of real machines in a job’s machine attribute, rather than a single real machine, you can implement simple load balancing. That is, you can cause the work load to be spread across multiple machines, based on each machine’s capabilities. In addition to load balancing, this feature is useful way to ensure reliable job processing. For example, if one of the machines is down, load balancing will run the job on another machine.

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_loadmachine: modenacommand: echo "Test Load Balancing"job_load: 50priority: 1

Where “modena” is a virtual machine.



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 job’s machine attribute, as shown below:

machine: ferrari, lambo

If the max_load attribute was not defined for either real machine (as in our example), or both machines had ample load units available, AutoSys would choose the machine to run on based solely on available processing power. To accomplish this, AutoSys does the following:

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 machine’s 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 job’s 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.



Load Balancing

Figure 10-5 illustrates three machines having different capabilities, which are grouped into a virtual machine.

The following JIL statements can be used to define this machine:

insert_machine: italiamachine: ferrarifactor: 1machine: alfa_romeofactor: .8machine: lambofactor: .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

Figure 10-5 • Load Balancing on a Virtual Machine

ferrari

1.0

lambo

0.3

alfa_romeo

0.8 factors

italia



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 10

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.

Queuing Jobs 10

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.



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 job’s starting conditions to ensure it is still okay to run the job. If any of the starting conditions are no longer true, the following message is generated:

Job: job_name Starting Conditions are no longer TRUE.

De-Queuing this Job and setting to ACTIVATED.

Note • In order for any queuing to take place, all jobs must have their priority attribute set. By default, the priority attribute is set to 0 indicating that the job should not be queued, but be run immediately. When this is the case, even jobs whose job load would push the machine over its load limit will be run. However, it is important to note that even when jobs have a priority of 0, job loads will still be tracked on each machine. This is done so that jobs that do have non-zero priorities will still be queued.



Queuing Jobs

Using a previously defined machine named “fiat” with a max_load of “100”, a simple queuing example would be as follows:

insert_job: jobAmachine: fiatjob_load: 80priority: 1insert_job: jobBmachine: fiatjob_load: 90priority: 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 job’s 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.



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.

Figure 10-6 • Schematic of Queuing with Priority

JobC

30

EXECUTEQUE_WAIT

JobB

50ferrari

80JobD

30

JobA

50 max_load



Queuing Jobs

insert_machine: ferrarimax_load: 80

insert_job: JobAmachine: ferrarijob_load: 50priority: 60

insert_job: JobBmachine: ferrarijob_load: 50priority: 50

insert_job: JobCmachine: ferrarijob_load: 30priority: 80

insert_job: JobDmachine: ferrarijob_load: 30priority: 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.

Subsets—Individual Queues 10

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



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.

To implement the schema in Figure 10-7, you would first create the virtual machine named “ferrari_printQ”, like this:

insert_machine: ferrari_printQmachine: ferrari max_load: 15

Next, you would define the three print jobs, like this:

insert_job: Print1machine: ferrari_printQjob_load: 15priority: 1



Figure 10-7 • Virtual Machine used to Construct an Individual Queue

ferrari

80

ferrari_printQ

15



Queuing Jobs

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 10

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.

Figure 10-8 • Virtual Machine Comprised of Subsets of Real Machines

ferrari lambo

p

1208015 15



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: printQtype: vmachine: ferrarimax_load: 15machine: lambomax_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.

User-Defined Load Balancing 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 job’s 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_freemachine: "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.




Note • If you specify a user-defined load balancing script in the machine attribute, you cannot use the priority or job_load job attributes.


11Scheduler 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


■ 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


Scheduler Console ■

Using the Scheduler Console

Using the Scheduler Console 11

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.

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.




Figure 11-1 • Scheduler Console




The Scheduler Console has the following three areas:

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 11

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.

File Menu

The File menu has the following options:

Menu bar The area which is at the top of the window.

Control area 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 job list

The area at the center of the window which displays a list of all jobs stored in the database, subject to the filter currently in effect.

New Scheduler Console

Opens another Scheduler Console window.

Exit Exits the Scheduler Console and closes all database connections that it has established.




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:

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:

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.

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.

Kill Job 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.

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.




For more information on any of these events, see sendevent in Chapter 1, AutoSys Commands, of the AutoSys Reference Guide for Windows NT.

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.

Off Hold 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.

On Ice 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.

Off Ice 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.




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.

Job Editor Opens a Job Editor for the selected job. For information on the Job Editor, see Chapter 7, Defining AutoSys Jobs using the Job Editor.

Run Status Tool 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.

Send Event 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.




Applications Menu

The Applications menu has the following option:

Reports Menu

The Reports menu allows you to run and view various job reports. The menu has the following options:

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.

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.

Job List Generates an InfoReports job list report based on a list of jobs you select, or based on the entire list of jobs in that instance’s database. For information, see Viewing Reports with InfoReports on page 11-41.




Preferences Menu

The Preferences menu allows you to set user preferences and customize the Scheduler Console display. The menu has the following options:

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.

Last N Run 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.

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.

User Defined Commands

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.

User Defined Reports

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.

Summary Area Layout

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.




Help Menu


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).


About Displays the Scheduler Console version number.




Using the Control Area 11

The control area is located below the Scheduler Console menu bar. The control area contains the following items:

■ 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 11

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.




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:

■ 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.




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.



Defining Scheduler Console Filters

Defining Scheduler Console Filters 11

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.

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:

■ 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.




Filters Editor Dialog 11

The Filter Editor has a File menu and the following tabs:

■ Names

■ Status

■ Machine/Instance

Figure 11-2 • Filter Editor




File Menu

The File menu has the following options:

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:

New Opens a new Filter Editor.

Open Opens the Open Filter Criteria dialog, which lists the defined filters. You can select a filter to open, and click OK.

Save 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.

Save As Opens the Save As dialog, in which you can enter a new filter name and saves it.

Delete 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.

Exit Closes the Filter Editor, displaying a dialog asking you if you want to save your last modifications when necessary.

All Jobs Selects all jobs that meet the other filtering criteria.

Jobs named 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>.




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.

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:

■ All—Indicates 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.

■ 0—Indicates that only the top-level box specified in the scrollable text box is to be displayed.

■ 1 through 20—Indicates that the box specified in the scrollable text box and the selected number of levels of nesting are to be displayed.




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




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




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.



Using Scheduler Console Tools

Using the Filter Editor 11

To define a filter

1 Choose Filters � Filter Editor. This action opens a dialog similar to the 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.

Using Scheduler Console Tools 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.




Using the Job Dependencies Dialog 11

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.

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




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 11

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

� 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.




Run Status Tool Menu Bar

The Run Status Tool has the following menus: File, Tools, Applications, Options, and Help.

File MenuThe File menu has the following options:

Figure 11-6 • Run Status Tool

New Run Status Tool

Opens a new Run Status Tool. This new Run Status Tool will update when you select a job.

Exit Closes the Run Status Tool.




Tools MenuThe Tools menu has the following option:

Applications MenuThe Applications menu contains the following option:

Options MenuThe Options menu has the following option:

Help MenuThe Help menu has the following options:

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.

Job Editor Opens a Job Editor for the current job. For more information, see Chapter 7, Defining AutoSys Jobs using the Job Editor.


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.


About Displays the Run Status Tool version number.




Run Status Tool Display Fields

The following sections describe the fields in this dialog:

Job Name The name of the selected job.

Instance The name of the AutoSys instance for which this job is defined.

Description The description text entered in the Job Editor Description field or with the description job attribute with JIL.

Command 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.

Starting Conditions

The job’s 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.

Start Time The start time of the current, or the most recent run of the job.

Run Time How much time elapsed between the start and end of the most recent run of the job. If the job is currently running, this field is blank.

Run Machine 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.

Exit Code The exit code from the most recent run of the job.

Try Count If the job had to be restarted, the number of times it was started appears here.




Using the Send Event Tool 11

Using the Send Event Tool, you can do the following:

■ 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.

End Time The end time of the most recent run of the job. If the job is currently running, this field will be blank.

Status The current status of the job.

Priority If the job is queued to start on a machine, its priority in the queue appears here.

Queue Name If the job is queued to start on a machine, the name of that machine appears here.

Next Start If the job has date and time starting conditions, this field shows when the next run of the job is scheduled to start.

Predecessor and Successor Jobs

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).




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.




.

Send Event Tool Menu Bar

The menu bar contains the following menus: File, Options, and Help.

File MenuThe File menu contains the following options:

Figure 11-7 • Send Event Tool

New Send Event Tool Opens a new Send Event Tool that is not associated with a job.

Exit Closes the tool.




Options MenuThe Options menu contains the following option:

Help MenuThe Help menu contains the following options:

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.

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.


About Displays the Send Event Tool version number.




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.

Job On Hold 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.

Job Off Hold 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.

Comment 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.

Stop Demon 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.

Force Start Job 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 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.

Job Off Ice 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.

Kill Job 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.

Change Status 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.

Change Priority 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.




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:

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.

Send Signal 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.

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.

Match On Time 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.




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.

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.

Comment 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.

Instance 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.

Send Priority Indicates whether the selected event should be sent with a Normal or High priority.




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


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.




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


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



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.

Using Scheduler Console Reports 11

The Reports menu contains the following options:

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:

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.

Job Detail Report Opens the Job Detail Report tool.

Job Find Opens an InfoReports defined report.

Job List Opens an InfoReports defined report.

Last Run Opens an InfoReports defined report.

Last N Run Opens an InfoReports defined report.

Summary Displays a one-line synopsis of the last or current execution of the job.

Event Displays a detailed report listing all the events and statuses from the last or current execution of the selected job.




The Job Detail Report tool has a menu bar and a display area.

To dismiss the tool

� Click OK.

Job Detail Report Menu Bar

The Job Detail Report tool has the following menus: File, Tools, Applications, Options, and Help.

File MenuThe File menu has the following options:

Figure 11-8 • Job Detail Report Tool

New Job Detail Report

Opens another Job Detail Report tool for the selected job.

Exit Closes the Job Detail Report tool.




Tools MenuThe Tools menu has the following options:

Applications MenuThe Applications menu has the following option:

Options MenuThe Options menu has the following option:

Help MenuThe Help 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.

Run Status Tool Opens a Run Status Tool for the selected job. For information, see Using the Run Status Tool on page 11-24.

Job Editor Opens a Job Editor for the selected job. For information, see Chapter 7, Defining AutoSys Jobs using the Job Editor.


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 job’s 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.


About Displays the version for the Job Detail Report.




Viewing Reports with InfoReports 11

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:

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.

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.

Job List Generates a job list report based on a list of selected jobs, or based on the entire list of jobs in that instance’s database.

Last Run Generates a last run report on the selected job. The report contains information on the last run of the job.

Last N Run 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.




Figure 11-9 • InfoReports Job Find Report (for testjob1)



Setting Scheduler Console Preferences

Setting Scheduler Console Preferences 11

The Scheduler Console Preferences menu contains the following options:

General Opens the General dialog (see Using the General Dialog on page 11-44).

User Defined Commands

Opens the User Defined Buttons dialog (see Using the User Defined Buttons Dialog on page 11-45).

User Defined Reports

Opens the User Defined Reports dialog (see Using the User Defined Reports Dialog on page 11-47).

Summary Area Layout

Opens the Summary Area Layout dialog (see Using the Summary Area Layout Dialog on page 11-49).

Action Area Layout

Opens the Action Area Layout dialog (see Using the Action Area Layout Dialog on page 11-52).

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.




Using the General Dialog 11

Using the General dialog, you can set the following for the Scheduler Console:

■ 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.




Using the User Defined Buttons Dialog 11

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.

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.

Figure 11-10 • General Dialog




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.

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"

Figure 11-11 • User Defined Buttons Dialog




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 11

You can use the User Defined Reports dialog to implement a menu item on the Reports menu.

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.




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




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.




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.

Figure 11-13 • Summary Area Layout Dialog




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 Jobs will be sorted by name in ascending alphanumeric order.

Instance Jobs will be sorted by their instance name, in ascending alphabetical order.

Status Jobs will be sorted by their current status, in ascending alphabetical order.

Last Change Jobs will be sorted by the date of their last change.

Machine Jobs will be sorted by the machine on which they run or have run, in ascending alphabetical order.

Type Jobs will be sorted by the type of job, in ascending alphabetical order.




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.

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.

Job ID Jobs will be sorted in the order in which they were created.




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.

Figure 11-14 • Action Area Layout Dialog




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.

Job Editor... Opens a Job Editor with the selected jobs. For information on the Job Editor, see Chapter 7, Defining AutoSys Jobs using the Job Editor.

Start Job 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.

Kill Job Kills the selected jobs. Choosing this option is equal to sending a KILLJOB event.




Note • If you want to add your own buttons, see Using the User Defined Buttons Dialog on page 11-45.

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.

On Hold 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.

Off Hold 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.

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.

Off Ice 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.




Setting the Time Perspective 11

The Time Perspective option has the following submenu options that control the time perspective of the summary area display:

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:

■ Do not select a job.

■ Select multiple jobs with different or no time zone settings.

Server Time Displays the time based on the time zone of the AutoSys database.

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.


12Managing 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


■ 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.

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.

Figure 12-1 • Alarm Sentry for Two Instances


Managing Alarms ■

Using the Alarm Manager

Using the Alarm Sentry Menu Bar 12

The Alarm Sentry has the following menus: File, Preferences, and Help.

File Menu

The File menu contains the following option:

Preferences Menu

The Preferences menu contains the following option:

Help Menu


Using the Alarm Manager 12

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.

Exit Closes the Alarm Sentry.

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.


About Displays the Alarm Sentry version number.


■ 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.


Managing Alarms ■


The Alarm Manager dialog has a menu bar and the following three regions, which are described in the sections below:

■ 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

Figure 12-2 • Alarm Manager


■ 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


Filters Menu

The Filters menu contains the following options:

Tools Menu


New Alarm Manager

Opens a New Alarm Manager.

Exit Closes the Alarm Manager.

Default Alarm Criteria

Resets the filter criteria to the default and updates the Alarm Manager Alarm List to reflect this.

Select Alarms Displays the Alarm Selection dialog (described on page 12-11). Use this dialog to define the filter by which you want to view alarms.

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.


Managing Alarms ■


Preferences Menu

The Preferences menu contains the following option:

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.

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.


■ Managing Alarms


Help Menu

The Help menu contains the following option:

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:

■ 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 alarm’s 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.

Alarms are displayed in reverse order of occurrence; the newest alarms appear at the top of the list and older ones appear farther down.


About Displays the Alarm Manager version number.


Managing Alarms ■


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.


■ 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 12

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.


Managing Alarms ■

Filtering Alarms

To update the display

� Check the Auto Refresh checkbox.

Or

� Click the Refresh button.

Filtering Alarms 12

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.

Using the Alarm Selection dialog, you can select alarms by the following:

■ Type of alarm

■ State of alarm (Open, Acknowledged, or Closed)

■ Date and time of the alarm’s occurrence

■ Instance name

Note • Alarms that have been archived cannot be displayed.


■ 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.

The Alarm Selection dialog is divided into the following regions, described in the sections below:

■ 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.

Figure 12-3 • Alarm Selection Dialog


Managing Alarms ■

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.


■ Managing Alarms

Filtering Alarms

Selecting Alarms by State 12

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.

Selecting Alarms by Instance 12

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.

Selecting Alarms by Time 12

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.

For your convenience, the current system date and time are filled in automatically.


13Monitoring 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


■ 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


Monitoring and Reporting on Jobs ■

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:

■ 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.



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 13

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.

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 system’s 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.



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 13

To define a monitor or report using the Monitor/Browser Editor

1 Open the GUI Control Panel from the AutoSys Graphical Interface 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 instance’s database, and it maintains that connection until you close the 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 13

At the top of the Monitor/Browser Editor is a menu bar that contains the following menus: File, Edit, and Help.

Figure 13-1 • Monitor/Browser Editor




File Menu


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.

Save 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.

Save As 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.




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 instance’s database, and it maintains that connection until you close the Monitor/Browser Editor.

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.

Run Monitor/Browser 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.

New Monitor/Browser Editor

Opens a new Monitor/Browser Editor.

Exit 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.



Defining Monitors and Reports with the Editor

Edit Menu

The Edit menu contains the following option:

Help Menu


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 13

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.

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.


About Displays the Monitor/Browser Editor version number.




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.




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.

Figure 13-2 • Monitor/Browser Editor for Example Monitor




Defining a Report 13

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:

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.



Setting Monitor and Report Attributes

Closing the Monitor/Browser Editor 13

To close the Monitor/Browser Editor

� Choose File � Exit.

Setting Monitor and Report Attributes 13

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:

■ Event Types

■ Job Selection Criteria

Figure 13-3 • Monitor/Browser Editor for Example Report




■ 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 13

The Event Types you specify determine which AutoSys events will be monitored or reported. Events include the following:

■ 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.

.

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.

All Events all_events




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 -eRunning 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.

.

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).

Selecting the All Change Status Events checkbox specifies that all job status events should be tracked. Job status events occur whenever a job’s 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.

Alarm alarm

All Change Status Events all_status




Instead of selecting All Change Status Events, you can select the following Job Change Status Events (JIL attribute values are in parentheses):

■ 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.

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.

Job Change Status Events

Job Filter job_filter




Setting Monitor Options 13

The monitor attributes in the Monitor Options area are optional.

Note • For each of the following monitor options, the corresponding JIL attribute is provided on the right.

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.

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.

Sound sound

Alarm Verification Required alarm_verif




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.

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.

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.

Current Run Only currun

Events After Date/Time after_time



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 13

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

� 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>.



Defining Monitors and Reports using JIL

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:

■ insert_monbro

■ update_monbro

■ 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.




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: Regularmode: malarm: yrunning: ysuccess: yfailure: yterminated: y




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: Alarmmode: msound: yalarm: yalarm_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 13

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_Repmode: balarm: yafter_time: "05/22/1997 2:00"

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.


14Maintaining 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


■ 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


Maintaining AutoSys ■

Maintaining the Event Processor

Maintaining the Event Processor 14

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.

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.




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:

■ 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.




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 14

The output of the Event Processor (event_demon.exe executable) is written to the following log file:

%AUTOUSER%\out\event_demon.%AUTOSERV%

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.




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:

■ 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.




Starting the Event Processor in Global Auto Hold Mode 14

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).

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:


Or

• Click the Event Processor button on the toolbar.

4 Click the Global Auto Hold checkbox to select it, and click OK.





• Choose AutoSys � Services.

Or

• Click the Services button on the toolbar.



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:


Or

• Click the Event Processor button on the toolbar.




5 Click the Global Auto Hold checkbox to deselect it, and click OK.



Or

• Click the Services button on the toolbar.



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 14

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.




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.




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.




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:


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).



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.



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 14

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


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




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).


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 14

You should not stop the Remote Agent service. If it is inadvertently stopped, see the previous section for directions on how to restart it.

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:

■ 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.



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:

■ %AUTOTESTMODE% = 1

■ %AUTOTESTMODE% = 2

Note • The Event Processor cannot run partially in test mode; AutoSys does not provide a test mode for the database. Therefore, you should exercise extreme caution when you run in test mode on a live production system.

%AUTOTESTMODE% = 1

At the first level of test mode, each job that you specify runs with the following test mode variations:

■ 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:

■ Minimum and Maximum Run Alarms



AutoSys Maintenance Commands

■ 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:

■ 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 14

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.

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:

■ 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



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 machine’s 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.



Backing up AutoSys Definitions

Backing up AutoSys Definitions 14

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:

■ 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.



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



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 14

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.

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.



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 14

An Event Server can be associated with only one instance of AutoSys and one running Event Processor.




An Event Server contains the following objects:

■ 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:

■ The number of jobs you define.

■ How many of the jobs have dependencies.




■ 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.

Figure 14-1 • Layout of databases and primary component interaction

EventProcessor

Agent

One Instance of AutoSys - %AUTOSERV%

Instructs Remote Machine: Command to execute and database(s) to send events to.

OS FILEAutoSys Administrator

Read Registry to determine which database(s) to use.

ProcessesDatabase(s)

Remote

settings

JobsDefine

Event Server 1

EventServer 2



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.

General Database Maintenance 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.




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:

■ 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.




■ 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:

■ Events and any alarms associated with them from the event table

■ Job run information from the job_runs table.

■ autotrack log information from the audit_info and audit_msg tables

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.



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:

■ 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 14

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.




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):


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.




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:

■ 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.




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_serverdestination_db autosys_password dump_file

• For Oracle databases:

perl autobcp.NT source_instance destination_instanceautosys_password dump_file oracle_path

• For Microsoft SQL Server databases:

perl autobcp.NT source_server source_db destination_serverdestination_db autosys_password dump_file MSSQL_path




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.




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 DatabasesIf 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_serverAUTOBCP.NT: Source database [autosys]? > autosysAUTOBCP.NT: Destination server [DestinationServer]? > destination_serverAUTOBCP.NT: Destination database [autosys]? autosysAUTOBCP.NT: Autosys password [password]? > autosys_passwordAUTOBCP.NT: Dump file name [dump.fil]? > dump.fileAUTOBCP.NT: Moving data from source_server:autosys to destination_server:autosysAUTOBCP.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.




Synchronizing Oracle DatabasesIf you are synchronizing two Oracle databases, you are prompted to answer the following questions, and then the script runs:

autobcp: Source instance [SourceInst]? > source_pathautobcp: Destination instance [DestinationInst]? > destination_pathautobcp: Autosys password [password]? > autosys_passwordautobcp: Dump file name [dump.fil]? > dump.fileautobcp: Path for Oracle (ie. ORACLE_HOME) [c:\orant]? > c:\pathautobcp: Moving data from source_path to destination_pathautobcp: 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 DatabasesIf 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_serverAUTOBCP.NT: Source database [autosys]? > autosysAUTOBCP.NT: Destination server [DestinationServer]? > destination_serverAUTOBCP.NT: Destination database [autosys]? > autosysAUTOBCP.NT: Autosys password [password]? > autosys_passwordAUTOBCP.NT: Dump file name [dump.fil]? > dump.fileAUTOBCP.NT: Path for MicroSoft SQL [c:\mssql]? > c:\pathAUTOBCP.NT: Moving data from source_server:autosys to destination_server:autosysAUTOBCP.NT: Are you sure? ([y]|n)> y...autobcp: complete



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 ErrorsIf the autobcp.NT process detects an error, it exits and displays an error message. If this happens, check the following:

■ 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.

Improving Database Performance 14

This section contains information about improving your database performance with AutoSys.




Improving Sybase Database Performance 14

These are ways to improve your Sybase database performance:

■ Increase the amount of memory that Sybase can use.

WARNING • Only the database administrator should increase Sybase memory.

■ 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.

Improving Oracle Database Performance 14

Tuning Oracle to improve its performance with AutoSys is complicated. The following are some suggestions for the database administrator:

■ Tune the shared pool size. Make changes to the shared pool size by altering the init.ora value of SHARED_POOL_SIZE.

To determine if you need to increase the shared pool size, enter the following query in SQL*Plus:

select sum(pins) “Executions”,sum(reloads) “Cache Misses while Executing”,((sum(reloads)/sum(pins))*100) “Ratio of Misses”from v$librarycache;




The Ratio of Misses should be less than 1%. (The Ratio of Misses number is displayed as a percentage.) If it is higher than 1%, you should increase the value of SHARED_POOL_SIZE incrementally until the value of Executions approaches zero.

■ Tune the buffer cache. Make changes to the buffer cache by altering the init.ora value of DB_BLOCK_BUFFERS.

To determine if you need to allocate more memory, enter the following query as the “sys” user in SQL*Plus:

select name, valuefrom v$sysstatwhere 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.

■ 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$sysstatwhere name in (‘sorts (memory)’, ‘sorts (disk)’);



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 14

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.

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 multi-threaded, single process that runs on one machine. It listens on a specific port for a request from a client, fulfills that request, and then returns the information to the client.

The client communicates with the server using a C library known as Open Client, or the DB Library. This library handles the communications between the client application and the Sybase SQL Server as well as sending requests and parsing results for the use of the application.

This means that all AutoSys commands and processes, including the Event Processor, the Remote Agent, and monitors, are DB Library applications that connect to the AutoSys database(s).

Because all AutoSys commands are merely Sybase clients, you can execute those commands from any machine that has access to the Event Server and is a licensed AutoSys client.




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 14

If you are using a Sybase, the following environment variables are used:

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.

DSQUERY Defines the name of the Sybase dataserver.

SYBASE Specifies the complete path to the Sybase software directory.




Database Users

When using the bundled Sybase version of AutoSys, there are two users defined by default in the AutoSys database: the system administrator and the AutoSys user. Each of these users has a default user name and password.

For information on changing the “sa” password, see the next section, Changing the System Administrator Password. For information on changing the “autosys” password, see autosys_secure in Chapter 1, AutoSys Commands, of the AutoSys Reference Guide for 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.

User User Name Default Password

System Administrator sa sysadmin

AutoSys User autosys autosys




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.




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:


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.




For information on changing the “sa” password, see Changing the System Administrator Password on page 14-39.

Accessing Sybase 14

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 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 14

These are reasons you might want to identify the processes that are connected to the database:

■ Before you change the “autosys” user password or shut down AutoSys, you should ensure that no processes are connected to the database. You can identify the active processes, then shut them down.

■ Many GUI processes connected to the database can slow it down. You can see how many and what type of processes are connected to the database, and then ask users to shut down the GUIs they are not currently using.

To see what processes are connected to the database and their status

� At the xql prompt, enter the following:

xql>>[AUTOSYSDB][master] 1> select program_name, hostname,

xql>>[AUTOSYSDB][master] 2> hostprocess,

xql>>[AUTOSYSDB][master] 3> status from sysprocesses;




The list of processes connected to the database is displayed, like this:

program_name hostname hostprocess status --------------- ---------- ----------- ------------

xql Joe 14050 runningsleepingsleepingsleepingsleepingsleeping

event_demon Michelle 13448 recv sleepjil Erik 12272 recv sleep

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):

Displaying the Database Date and Time 14

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.

autocal event_demon sendevent

autocons hostscape timescape

autosc jil xql

auto_remote jobscape




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 file’s 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.




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.




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.




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 DatabaseYou 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”.




Re-Creating the AutoSys DatabaseAfter 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.




Reloading the DatabaseYou 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 ProcessorThen, 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.


15AutoSys 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


■ 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


AutoSys Administrator ■

About the AutoSys Administrator

About the AutoSys Administrator 15

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:

■ Instance

■ Remote Agent

■ Event Server

■ Event Processor

■ Notifications

■ System Information

■ Sounds

■ Security

■ Services



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:

■ 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.



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 15

To start the AutoSys Administrator

� 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 15

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).




AutoSys Administrator Menu Bar

The Administrator menu bar contains the File, Edit, View, AutoSys, and Help menus.

File MenuThe file menu contains the following options:

Figure 15-1 • AutoSys Administrator Toolbar

Export

Cut Copy Paste About AutoSys Administrator

Help

InstanceEvent ServerRemote Agent Event Processor Notification

SystemInformation

Sounds Security Services

Export Exports the configuration settings to a text file.

Export As Writes the configuration settings to a text file that you specify.

Exit Exits the AutoSys Administrator.




Edit MenuThe Edit menu contains the following options:

View MenuThe View menu contains the following options:

AutoSys MenuThe AutoSys menu contains the following options:

Undo Undoes the last operation.

Cut Removes the selected text and places it on the clipboard.

Copy Copies the selected text to the clipboard.

Paste Pastes the contents of the clipboard at the location of the cursor.

Toolbar Toggles to show or hide the toolbar.

Status Bar Toggles to show or hide the status bar.

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.

Remote Agent 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).

Event Server Displays the Event Server screen, which you can use to specify Event Servers, either for Single Server or Dual Server Mode.




Help MenuThe Help menu contains the following options:

Notifications Displays the Notifications screen, which you can use to specify user-defined alarm callbacks for certain types of system alarms.

Event Processor 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.

System 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.

Sounds 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.

Security Displays the Security screen, which you can use to set the Trusted Hosts and Trusted Users for remote authentication.

Services Displays the Services screen, which you can use to view and alter the status of Remote Agent and Event Processor services.

Help Topics Displays the Help Index and Find utility.

About AutoSysAdmin

Displays release information on AutoSys Administrator.



AutoSys Instances

AutoSys Instances 15

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.

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:

■ 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 event’s 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.



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 15

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.

The AutoSys Instance screen allows you to select a Computer and AutoSys Instance, so you can view or modify that instance’s configuration settings.

Figure 15-2 • AutoSys Administrator Instance Screen



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,




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 15

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

� Click the Remote Agent button on the toolbar.

Figure 15-3 • AutoSys Administrator Remote Agent screen




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.

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.

TCP/IP Port #AutoRemPort




Local Agent Logging DirectoryThe 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 NamesThe 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.



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




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 15

Using the Event Server screen, you can view and modify the database-specific 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

� Click the Event Server button on the toolbar.




Figure 15-4 • AutoSys Administrator Event Server screen





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.

Figure 15-5 • AutoSys Administrator Event Server screen for Oracle




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.

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.

EnableUse the Enable button to enable the associated Event Server, either when enabling a down server or when implementing Dual Server Mode.

DisableUse 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.

Name or Alias EventServer




HostThe 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.

PortThe 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.

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.

StatusThe 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.

Database EventServer




Database ProviderSpecifies 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 OccurredThe 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.

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.

DB Event Reconnect DBEventReconnect



AutoSys Event Processors

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.

Specifies the number of times that the Event Server should try to reconnect to the alarm server (if installed).

AutoSys Event Processors 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 AutoSys—it 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

Database Wait Time DBLibWaitTime

Database Alarm Reconnect DBAlarmReconnect




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.





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).

Figure 15-6 • AutoSys Administrator Event Processor screen




Shadow MachineThe 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.

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.

Third Machine ThirdMachine




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.

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.

Network Machine List EDMachines

Enterprise Wide Logging Directory AutoRemoteDir




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.

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 SizeThe 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.

Database Maintenance Command DBMaintCmd

Database Maintenance Time DBMaintTime




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).

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.

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.

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.

Event Transfer Wait Time EvtTransferWaitTime

Error Time Interval EDErrTimeInt

Number Errors EDNumErrors




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.

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.

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!

HeartBeat Interval Check_Heartbeat

FileSystem Threshold FileSystemThreshold




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.

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.

Chase On Startup




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.

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 HoldThe 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.

Remote Profile Logging RemoteProFiles

Clean Temporary Files CleanTmpFiles




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.

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.

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.

Z/Team Job Support ZTeamJobSupport

Append stdout/stderr AutoInstWideAppend




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:

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.

.

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.

> Overwrite file>> Append file

Enable External Events AutoPems




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.

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.

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.

Machine Method MachineMethod

XInstance DB Drop Time XInstanceDBDropTime




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.

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.

Max Restart Trys MaxRestartTrys

Max Restart Wait MaxRestartWait




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.

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.

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.

Restart Factor RestartFactor

Restart Constant RestartConstant

Kill Signals KillSignals



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:

■ 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 15

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.




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




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.

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.

The Database Problem parameter specifies the user-defined routine that AutoSys should call when there is a problem with one of the AutoSys databases.

The Event Processor Rollover parameter specifies the user-defined routine that AutoSys should call when the Shadow Event Processor is taking over processing.

Database Rollover DB_ROLLOVER

Database Problem DB_PROBLEM

Event Processor Rollover EP_ROLLOVER



AutoSys System Information

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.

The Event Processor High Availability parameter specifies the user-defined 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.

AutoSys System Information 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.

Event Processor Shutdown EP_SHUTDOW

Event Processor High Availability EP_HIGH_AVAIL




AutoSys Administrator System Information Screen 15

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

� Click the System Information button on the toolbar.




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.

Figure 15-8 • AutoSys Administrator System Information screen




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.


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 machine-specific basis.

Note • The variables that appear on this screen are set when you open an AutoSys Instance Command Prompt window.

The %AUTOSYS% environment variable specifies the full path to the AutoSys software directory.

The %AUTOROOT% environment variable specifies the top-level AutoSys directory.

AUTOSYS $AUTOSYS

AUTOROOT $AUTOROOT




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.

The %AUTOUSER% environment variable specifies the full path to the directory containing the AutoSys user’s 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.

DSQUERYThe %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.

AutoMachWideAppendYou 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.

AUTOSERV $AUTOSERV

AUTOUSER $AUTOUSER



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.

VersionThe Version field indicates the AutoSys for Windows NT version number (for information purposes only).

BuildThe 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.



AutoSys Sounds

AutoSys Administrator Sounds Screen 15

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

� Click on the Sounds button on the toolbar.

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.

Figure 15-9 • AutoSys Administrator Sounds screen



AutoSys Sounds

Defining Sounds Configuration Parameters

This section lists and describes the configuration parameters located on the Sounds screen.

AutoSys AlarmThe 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 AlarmThe 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 DefaultThe 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 SuccessThe 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 FailureThe 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.



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.



AutoSys Security

User Remote Authentication Example 15

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, 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.



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.



AutoSys Security

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 HostsThe 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.

Figure 15-10 • AutoSys Administrator Security screen



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 UsersThe 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 15

AutoSys has the following primary components, or services:

■ 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.



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



AutoSys Services

Services Screen Components

This section lists and describes the components of the Services screen.

ServiceThe 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.

StatusThe 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 Service—it corresponds to the traffic light. This value can be “Stopped”, “Updating”, or “Running”.

Start ServiceIf the Start Service button is enabled, you can click it to start the selected AutoSys Service.

Stop ServiceIf 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.)



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.



AutoSys Services


16Troubleshooting

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


■ Troubleshooting

Remote Agent Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-18

Remote Agent Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-18

Remote Agent Will Not Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-19

Remote Agent Starts, Command Runs—No 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


Troubleshooting ■

Introduction

Introduction 16

To troubleshoot AutoSys more effectively, it is essential that you understand the stages in the life of a job, the order in which they occur, and the roles played by the three major AutoSys components (i.e., Event Server, Event Processor, and Remote Agent).

When a job is defined, its starting conditions are saved to the Event Server (database), and the following occurs:

■ When its starting conditions are met, the Event Processor initiates a Remote Agent on the client machine to execute the job.

■ The Remote Agent runs the job and sends the exit status of the job back to the Event Server.

■ After the job completes, it is not run again until its starting conditions are met.

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, database-specific 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.


■ 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 Panel’s 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 Panel’s 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.


Troubleshooting ■

Event Server Troubleshooting

Event Server Troubleshooting 16

Event Server is Down (Sybase) 16

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 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:

Couldn’t 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 Panel’s 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.


■ 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 16

Symptom

A message similar to the following appears in the Event Processor log when viewed with the autosyslog -e command or in the Sybase error log (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.


Troubleshooting ■


Resolution

A deadlock is a Sybase condition that occurs when two users have a lock on separate objects, and they each want to acquire an additional lock on the other user’s object. The first user is waiting for the second user to let go of the lock, but the second user will not let go until the lock on the first user’s object is freed.

The dataserver detects the situation and chooses the user whose process has accumulated the least amount of CPU time as the “victim.” The dataserver rolls back the victim’s transaction, notifies the application with the above error message, and allows the other user’s processes to move forward.

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) 16

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

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.


■ 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


4 Enter:

1> select count(*) from master..sysdevices where mirrorname is not NULL;


--------------

0


5 Enter:

1> select count(*) from master..sysservers where srvname != @@servername;


Troubleshooting ■



--------------

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) 16

Symptom

When the transaction log is full, archive_events fails. This usually occurs because archive_events is not run regularly. We highly recommend that you run archive_events frequently, ideally as part of the daily database maintenance cycle by using DBMaint or as a regularly scheduled job.

You can usually avoid a full transaction log by having Sybase truncate the transaction log during regular checkpoints.


■ 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;


Troubleshooting ■


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) 16

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.

...

This error indicates that the Oracle tablespace it too small.


■ 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.

Event Processor Troubleshooting 16

Output from the Event Processor is redirected into the following log file:

%AUTOUSER%\out\event_demon.%AUTOSERV%

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 Processor’s 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 16

Symptoms

1 Jobs do not start.

2 When chk_auto_up is run, it returns a message similar to this (assuming your Event Processor was installed on the machine “EPhost”):

Checking machine: EPhostNo 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.


Troubleshooting ■


Resolution

Confirm that the Event Processor is down by performing one of the following actions:

■ 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 16

Symptom

The autosyslog -e command displays a message indicating that the Time Key is not valid.

Resolution

Install your Time Key as described in Chapter 7, Entering License Keys in the AutoSys Installation and Getting Started Guide for Windows NT.


■ 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.


Troubleshooting ■


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

The log file %AUTOUSER%\out\event_demon.%AUTOSERV% is missing!

Resolution 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.

Resolution 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.


■ Troubleshooting



The environment variable AUTOSYS is not set.

Resolution 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.

Resolution 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.

Resolution 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.


Troubleshooting ■



chk_auto_up is taking a while to complete...

Resolution 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>

Resolution 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.

Resolution 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.

Resolution 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.


■ Troubleshooting

Remote Agent Troubleshooting

Remote Agent Troubleshooting 16

Remote Agent Verification 16

If you suspect problems with the Remote Agent, you can use autoping to verify your suspicions.

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.


Event processor cannot open its log file <EP logfile name>. Some directory in the path is not accessible to the SYSTEM.

Resolution 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.

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.


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 16

The symptoms in this section are similar and result from network problems.

Symptom

The autosyslog -e command displays a message like this:

Attempting to connect to AutoSys Remote AgentService 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.


■ Troubleshooting


Symptom

The autosyslog -e command displays a message like this:

Attempting to connect to AutoSys Remote AgentService on socket=5280: Connection RefusedCould 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.


Troubleshooting ■


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.


Remote Agent Starts, Command Runs—No RUNNING Event is Sent 16

Symptoms

1 Job is stuck in STARTING state.

2 This problem is detected either in the Event Processor window (or log) or in the results of running the autorep command on the job, when the following event appears, then nothing else, yet the job does run to completion on the client machine:

CHANGE_STATUS Status: STARTING Job: test_install

Resolution

This is a common problem and is nearly always the result of the Remote Agent being unable to contact the Event Server. First of all, ensure that network problems are not preventing communication between the Remote Agent and the Event Server machines. If this is not the problem, then check the following database-specific solutions.

With Sybase 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.


■ 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 Agent’s 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.


Troubleshooting ■


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:

■ 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.


Testing the SetupTo 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.


■ Troubleshooting

Job Failure Troubleshooting

xql Will Not Start (Sybase Only) 16

Symptom

From the remote machine, xql returns the following message:

DB-Library error: dbproc NULL

Error in SybInit: dbopen failed

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 Runs—No RUNNING Event is Sent on page 16-21.

Job Failure Troubleshooting 16

Remote Agent Will Start - Command Will Not Run 16

Each time the Remote Agent is started on a machine, it creates the following log file:

AutoRemoteDir\auto_rem.pid


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.


■ 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.


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@HOSTon machine:RAHOST.

Message: Couldn’t 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


Troubleshooting ■


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:

■ 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.


■ 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 job’s standard out file was not writable, a message indicating this would appear in the Event Processor log.

You should also verify the following items:

■ The default profile or the job’s 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.


Troubleshooting ■


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


■ 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.


AIntegrating 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

PLATINUM AutoSys User Guide for Windows NT A-1 ■

■ 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

■ A-2 PLATINUM AutoSys User Guide for Windows NT

Integrating AutoSys with Zeke and AutoSys/Team Agent ■

Introduction

Introduction A

AutoSys enterprise-wide scheduling lets you integrate AutoSys jobs with Zeke and the AutoSys/Team Agent. The following types of integration are supported:

■ 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 A

The following terms are used in this appendix:

AutoSys A job scheduler that runs on UNIX and NT.

Zeke A mainframe scheduler that runs on MVS and VSE environments.

Team Agent 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.



Introduction

Related Documentation A

The information presented in this appendix supplements the following documents:

■ 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 User’s Guide

Cross-instance job dependency

A dependency between jobs running on different instances of AutoSys.

Cross-platform job dependency

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.



Job Scheduling for the Enterprise

Job Scheduling for the Enterprise A

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:

In addition, to utilize cross-platform job dependencies with a Zeke machine, the following must be present on your Zeke machine:

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.

oasis_broker An AutoSys process that communicates with Zeke or Team Agent.

communication components

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.

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.



Installing and Configuring for Enterprise Job Scheduling

Installing and Configuring for Enterprise Job Scheduling A

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:

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 A

If it is not already installed, install the basic AutoSys product as described in the AutoSys Installation and Getting Started Guide for Windows NT.

AutoSys Zeke Team Agent

■ 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




Install AutoSuite A

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):


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 dialog’s Command Line field.




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 A

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):




■ The following entries were set by default when you ran the AutoSuite setup program:

netregid: NETREGID

defprotocol: tcp

network: na

node: 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

■ 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




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.




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:

■ ZTeam Job Support must be selected in the AutoSys Administrator Event Processor Maintenance screen.

■ ZTEAMDIR environment variable is defined.

■ 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:

■ 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:

■ 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.



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 aappls

anetjob zteamsrv

anetcmd 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 7701/tcp zclnt

zteamsrvr 7702/tcp zsrvr

oasisbroker 7998/tcp 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.)

Initializing the Communication Components A

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.




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 mainframe’s 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




License Keys A

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) ? aKEY Type: [(c)lient, (s)erver, (t)ime, (x)pert]: c

Hostname: NETREGIDHostid: 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 A

Now you can start the Event Processor using the AutoSys Administrator Services screen and start the AutoSuite service from the Services applet.



About the oasis_broker

About the oasis_broker A

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.



AutoSys and Zeke Cross-Platform Dependencies

AutoSys and Zeke Cross-Platform Dependencies A

AutoSys jobs can have dependencies on jobs managed by PLATINUM’s 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.

Figure A-2 • AutoSys and Zeke (MVS) cross-platform configuration

Event Server

Event

Processor oasis_broker

Z

E

K

E

O

A

S

I

S

Job

Team Agent(Remote)

AutoSys UNIX or NT

CommunicationComponents *

* Communication components are listed in Configure the Communication Components on page A-12.

NETREGID: MYMACHINMVS

NETREGID: MVSZEKEInstance: ACE




In Figure A-2, communication between AutoSys and Zeke is handled by the oasis_broker and the communication components.

■ 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 A

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 job’s parent (Zeke or the remote Team Agent).




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 A

To define a cross-platform job dependency, you use the following notation:

job_name^INS

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^INS)

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:

■ success

■ terminated

■ done

■ notrunning




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 A

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:

■ 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.

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.



Running AutoSys Jobs on the Team Agent

Running AutoSys Jobs on the Team Agent A

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.

In Figure A-3, communication between AutoSys and the Team Agent is handled by the oasis_broker and the communication components.

■ 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.

Figure A-3 • AutoSys and Team Agent configuration

Event Server

EventProcessor oasis_broker

AS/400

Job

AutoSys UNIX or NTNETREGID = ZASYS400

TEAM

AGENT

CommunicationComponents *

* Communication components are listed in the Configure the Communication Components on page A-12.

NETREGID: MYMACHINInstance: ACE




Running Jobs on Team Agent Managed Machines A

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).




Defining Team Agent Machines to AutoSys A

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 Agent’s 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



Database Tables

Team Agent Machine in an AutoSys Job Definition A

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: TEAMJOBowner: bob@saharamachine: ZASYS400command: 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 A

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 A

Log information is written to the Log folder in %AUTOSYS%\AutoSuite.

Zeke and Team Agent Job Statuses A

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.



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 A

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.


heartbeat_interval Command Info tab: Heartbeat Interval (mins)

job_load Command Info tab: Job Load

job_terminator Alarms/Terminators tab: If this box fails, terminate the job

job_type:f New Job or Save dialogs: Job Type � File Watcher



Unsupported Attributes for Zeke or Team Agent Jobs

max_exit_success Command Info tab: Maximum Exit Code for SUCCESS

n_retrys Misc tab: Number of times to restart this job after a fAILURE

priority Command Info tab: Que Priority

profile Resource/Profile tab: Job Environment Profile

std_err_file Command Info tab: File to redirect to standard error

std_in_file Command Info tab: File to redirect to standard input

std_out_file Command Info tab: File to redirect to standard output

term_run_time Alarms/Terminators tab: Terminate this job n minutes after starting

watch_file Basic Scheduling tab for File Watcher Jobs: File to watch

watch_file_min_size Basic Scheduling tab for File Watcher Jobs: Minimum file size (in bytes)

watch_interval Basic Scheduling tab for File Watcher Jobs: Time Interval (secs) to determine steady state



Cross-Platform Limitations

Cross-Platform Limitations A

When you running across platforms, keep the following in mind:

■ 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


Index

AAction Area Layout dialog 11-52ACTIVATED status 3-15after_time report attribute 13-18Alarm Manager 6-5

about 12-3acknowledging alarms 12-3Alarm List 12-5Alarm Selection dialog 12-11

Select by State region 12-14Select by Time region 12-14Select by Type region 12-13

changing alarm states 12-10closing alarms 12-3Currently Selected Alarm

acknowledging 12-10closing 12-9Response edit box 12-9

menu bar 12-6registering responses 12-10

alarm monitor/report attribute 13-15Alarm Sentry 6-5, 12-2alarm_if_fail job attribute 4-15

alarm_verif monitor attribute 13-17alarms

about 1-11AutoSys 15-47AutoSys Big 15-47AutoSys Default 15-47DB_PROBLEM 15-39DB_ROLLOVER 15-39EP_HIGH_AVAIL 15-40EP_ROLLOVER 15-39EP_SHUTDOWN 15-40sounds for 15-47

all_events monitor/report attribute 13-14all_status monitor/report attribute 13-15attributes

jobalarm_if_fail 4-15auto_delete 4-18auto_hold 4-18avg_runtime 4-25basic 3-12box_failure 4-28box_name 4-14

PLATINUM AutoSys User Guide for Windows NT Index-1 ■

■ Index

attributes (contd.)job (contd.)

box_success 4-27box_terminator 4-15chk_files 4-26, 4-27command 4-5, 4-6condition 4-13date_conditions 4-10days_of_week 4-11description 4-13essential

all jobs 4-5Box Jobs 4-10Command Jobs 4-6File Watcher Jobs 4-9

exclude_calendar 4-11heartbeat_interval 4-25job_load 4-23job_name 4-5job_terminator 4-16machine 4-8, 4-9max_exit_success 4-24max_run_alarm 4-14min_run_alarm 4-14n_retrys 4-16optional

Box Jobs 4-27Command Jobs 4-19File Watcher Jobs 4-26non-starting parameters 4-13starting parameters 4-10

override_job 4-24permission 2-20, 4-18priority 4-23, 10-6run_calendar 4-11run_window 4-12start_mins 4-12

start_times 4-11std_err_file 4-22std_in_file 4-20std_out_file 4-21term_run_time 4-15timezone 4-17watch_file 4-9watch_file_min_size 4-26watch_interval 4-27

job dependencies 3-23job security 2-18machine

factor attribute 10-6max_load 10-5

machine (job attribute) 2-19monitor

alarm_verif 13-17sound 13-17

monitor/reportalarm monitor/report attribute 13-15all_status 13-15job_filter 13-16

owner 2-19permission 2-20report

after_time 13-18currun 13-18

starting conditions 3-23auto_delete 4-18auto_hold 4-18auto_rem file 15-31AUTOBCP.NT Perl script 14-29autohold 15-31autohold job attribute 4-18AutoInstWideAppend, configuration

parameter 15-32AutoPems 15-33

■ Index-2 PLATINUM AutoSys User Guide for Windows NT

Index ■

autoping 16-18, 16-19AutoRemoteDir, configuration parameter

15-26AutoRemPort, configuration parameter

15-13AUTOROOT variable 15-43AUTORUN 3-35AUTOSERV variable 15-44AutoSys

build information 15-45components 1-4database name 15-44database, defined 1-5directory 15-43environment variables 15-40Graphical User Interface, see GUIinstance ID 15-44instances, defined 1-10machines 1-10root directory 15-43security 2-1, 15-48services 15-52user directory 15-44version 15-45

AutoSys Administrator 15-1 to 15-55Authorized Event Processor Host

Names 15-14AUTOROOT 15-43AUTOSERV 15-44AUTOSYS 15-43AutoSys Alarm 15-47AutoSys Big Alarm 15-47AutoSys Default Alarm 15-47AutoSys Failures 15-47AutoSys Success 15-47AUTOUSER 15-44Build 15-45

Chase On Startup 15-30Clean Temporary Files 15-31Database Maintenance Command

15-27Database Maintenance Time 15-27Database Problem 15-39Database Rollover 15-39Database Wait Time 15-22DB Event Reconnect 15-21DSQUERY 15-44EDMachines 15-26Enable External Events 15-33Enterprise Wide Logging Directory

15-26Error Time Interval 15-28Event Processor High Availability 15-40Event Processor screen 15-23Event Processor Shutdown 15-40Event Server Database 15-20Event Server Disable 15-19Event Server Host 15-20Event Server Name 15-19Event Server Port 15-20Event Server screen 15-16Event Server Status 15-20Event Transfer Wait Time 15-28FileSystem Threshold 15-29Global Auto Hold 15-31HeartBeat Interval 15-29Instance screen 15-10Kill Signals 15-36Local Agent Logging Directory 15-14Machine Method 15-34Max Restart Trys 15-35Max Restart Wait 15-35Maximum Log Size 15-27menu bar 15-5


■ Index

AutoSys Administrator (contd.)Network Machine List 15-26Notifications Screen 15-37Number of Errors 15-28Remote Agent parameters 15-13Remote Agent screen 15-12Remote Profile Logging 15-31Restart Constant 15-36Security screen 15-50Service 15-54Services 16-13Services screen 15-52Shadow Machine 15-25Sounds screen 15-46Start Service 15-54Status 15-54Stop Service 15-54System Information Screen 15-41TCP/IP Port # field 15-13Third Machine 15-25toolbar 15-5Version 15-45XInstance DB Drop Time 15-34Z/Team Job Support 15-32

AUTOSYS variable 15-43AutoSys/Xpert 6-5autosys_secure command 15-48autosyslog command 14-5autosyslog, monitoring Remote Agent log

16-26autotest 14-15AUTOTESTMODE 14-15AUTOUSER variable 15-44avg_runtime 4-25

Bbackups

bundled Sybase 14-44calendar definitions 14-18global variables (using autorep) 14-19job definitions (using autorep) 14-19machine definitions (using autorep)

14-19monitor and browser definitions (using

monbro) 14-19batch files

database maintenance 15-27DBMaint.bat 14-25

batch files and exit codes 3-31big alarms, defining sound for 15-47Box Jobs 3-6, 5-1

basic job definition 3-14default behavior 5-3diagram 3-19examples 5-10force starting jobs in a box 5-8guidelines 5-4non-default terminators 5-6placing job in

GUI 7-19JIL 8-11

starting conditions 3-6, 3-21status changes 5-9

box_failure 4-28box_name 4-14box_success 4-27box_terminator 4-15browsers

backing up definitions 14-19defined 13-3restoring definitions from backup file

14-21


Index ■

CCalendar Editor 6-5, 9-1 to 9-32

See also calendarsapplying rules 9-19Calendar Selection dialog 9-18date states 9-14Edit menu 9-9exporting definitions 9-32File menu 9-7Help menu 9-12importing text files 9-31merging calendars 9-28navigation controls 9-12Preferences menu 9-10rescheduling rules 9-25rule specification 9-21starting 9-6Utilities menu 9-10

calendars 9-1 to 9-32applying rules 9-9backing up definitions 14-18blocked dates 9-14blocking dates 9-21combining 9-28conflicting dates 9-13, 9-15custom 3-22date range 9-22date states 9-14deleting 9-8exiting 9-9exporting 9-32exporting definitions to file 14-18exporting to text 9-8importing 9-8, 9-31importing definitions from file 14-20Job Definition Reference List 9-10merging 9-28

navigation controls 9-12opening 9-7opening new 9-7periods 9-23printing 9-8renaming 9-8rescheduling rules 9-25, 9-27restoring definitions 14-20reverting to last saved 9-9rule specification 9-21saving 9-7saving to other instances 9-8selecting 9-18setting dates 9-21Term Calendar Rule 9-19unsetting dates 9-21

CHANGE_PRIORITY 11-33CHANGE_STATUS 11-33chase command 14-4, 14-16, 15-30check file space 4-26, 4-27Check_Heartbeat, configuration

parameter 15-29chk_auto_up 15-26chk_files 4-26clean_files 14-17, 15-31CleanTmpFiles, configuration parameter

15-31client machine 1-10command job attribute 4-5, 4-6Command Jobs 3-5, 3-13COMMENT 11-32components

Event Processor 1-6Event Server 1-5Remote Agent 1-7

condition job attribute 4-13conditions, starting 3-23


■ Index

configuration file for UNIX 15-4configuration file, FileSystemThreshold

15-29Control Panel, GUI 6-2conventions, typographical xxvcpu, using available cycles to select

machine to run on 10-13crash recovery, database 14-27, 14-46cross-instance database drop time 15-34currun report attribute 13-18custom calendars, overview 3-22

Ddatabase 15-39

accessing interactively 14-42administration 14-38architecture 14-23backup, bundled Sybase 14-44breaking connection 15-22changing the “sa” password 14-39checking if Sybase running 14-40connection to Monitor/Browser Editor

13-22crash recovery 14-27cross-instance drop time 15-34defined 14-21defining which to use 14-23disabling 15-19dumping 14-44environment variables 15-40host machine 15-20identifying connected processes 14-42maintenance batch file 15-27maintenance time 14-25, 15-27name 15-19, 15-20passwords 2-10reconnect numbers 15-21

recovery 14-27, 14-46reloading 14-49rollover 14-27rollover notification 15-39shutdown 14-41starting 14-40status 15-20stopping service 14-41storage requirements 14-22tablespace error, Oracle 16-11unrecoverable error 14-27verifying connection 16-19

dataserver, defined 1-5date dependency 3-22date range in calendars 9-22date/time job dependencies 3-22date_conditions 4-10days to run job, setting

GUI 7-27JIL 8-12

days_of_week 4-11DB Library 14-37DB_PROBLEM, configuration parameter

15-39DB_ROLLOVER, configuration parameter

15-39DBAlarmReconnect, configuration

parameter 15-22DBEventReconnect, configuration

parameter 15-21DBLibWaitTime, configuration parameter

15-22DBMaint.bat batch file 14-25DBMaintCmd, configuration parameter

15-27DBMaintTime configuration parameter

15-27


Index ■

dbstatistics script 14-25default owner of job 2-11delete job

GUI 7-29JIL 8-14

dependency, jobdate/time 3-22exit code 3-30global variables 3-33job status 3-23

dependent jobscreating - GUI 7-15creating -JIL 8-8example 3-28

description job attribute 4-13done condition in job definition 3-24DSQUERY variable 14-38Dual Event Servers

defined 1-6mode 14-21running 15-15

dump command 14-44

EEDErrTimeInt, configuration parameter

15-28edit permissions 2-12Edit Superuser 2-14EDMachines, configuration parameter

15-26EDNumErrors, configuration parameter

15-28environment variables

See also profilesAutoSys 15-40AutoSys directory 15-43AutoSys instance 15-44

AutoSys root directory 15-43AutoSys user directory 15-44DSQUERY 14-38, 15-44NuTCRACKER 15-40setting for jobs 3-5SYBASE 14-38user defined 3-8

EP_HIGH_AVAIL, configuration parameter 15-40

EP_ROLLOVER, configuration parameter 15-39

EP_SHUTDOWN, configuration parameter 15-40

errorsEvent Processor handling 15-28Event Processor time interval 15-28Event Server, detection 14-27

essential job attributes 4-5Event Processor 15-22

See also event_demonautohold 15-31automatic shutdown 15-28configuration parameters 15-24connecting to databases 15-21defined 1-6error handling 15-28error interval 15-28global autohold 15-31heartbeat checking 15-29job restarting wait time 15-35log file, space needed for 15-29log size limit 15-27logging directory 15-26machine list 15-26monitoring 14-5remote authentication 15-14restarting jobs 15-35, 15-36


■ Index

Event Processor (contd.)restoring 14-12running chase with 15-30running in test mode 14-14Shadow Machine 15-25shutdown notification 15-40shutdown, automatic 15-28starting 14-3, 15-55status 16-13stopping 14-9, 15-55terminating jobs 15-36third machine configuration 15-25troubleshooting 16-12

Event Server 15-15 See also database See also Dual Event Serversbreaking connection 15-22configuration parameters 15-18crash recovery 14-27database name 15-20defined 1-5disabling 15-19dual 14-21, 14-23, 15-15error detection 14-27errors, unrecoverable 14-27host machine 15-20name 15-19, 15-44port number 15-20reconnect numbers 15-21recovery 14-27restarting Dual Server Mode 14-28rollover 14-27rollover recovery 14-27single 14-27status 15-20synchronizing 14-28

transferring events 15-28troubleshooting 16-5

event_demon See also Event Processor

eventsabout 1-11cancelling 11-36copying to Event Servers 15-28HEARTBEAT 15-29job failure, sound for 15-47job success, sound for 15-47transferring missing 15-28

EventServer parameter 15-19, 15-20EvtTransferWaitTime, configuration

parameter 15-28examples

calendar rescheduling rule 9-27individual queues 10-19JIL 8-17job dependencies 3-28load balancing 10-14monitor/report definition 13-9monitors, defining in JIL 13-21multiple machine queues 10-22NT security 2-23queuing with priority 10-18real machine definition 10-8reports, defining in JIL 13-22system architecture 1-8Trusted Hosts 15-49Trusted Users 15-49user remote authentication 15-49virtual machine definition 10-9

exclude_calendar 4-11exclusive condition 3-29Exec Superuser 2-15execute permissions 2-11, 2-12


Index ■

exit codesbatch files, with 3-31FALSE.EXE 3-33job dependencies 3-30maximum for success 3-24

exitcode 3-30exporting calendars 9-32, 14-18

Ffactor attribute 10-6failure condition in job definition 3-24FAILURE status 3-15FALSE.EXE 3-33File Watcher Jobs 3-7

basic job definition 3-13creating 7-12

filesUNIX configuration 15-4user’s directory, in 15-44

FileSystem Threshold 15-29FileSystemThreshold 15-29Filter Editor 11-16

Machine/Instance tab 11-20Names tab 11-17Status tab 11-19using 11-22

force starting jobsimpact on load balancing 10-15

FORCE_STARTJOB 11-6, 11-32, 11-55

GGeneral Dialog 11-44global autohold 15-31global variables

backing up definitions 14-19job dependencies 3-33restoring definitions 14-21

setting in the Send Event Tool 11-34Graphical User Interface

See also GUIintroduction 6-1

GUIalarm color setting 6-4Alarm Manager 6-5Alarm Sentry 6-5Calendar Editor 6-5connect to database 6-4Control Panel 6-2defined 1-3HostScape 6-5introduction 6-1Job Editor 6-5Job Editor menu bar 7-5JobScape 6-5Monitor/Browser Editor 6-5one-time job overrides 7-31removing user preferences 6-4Scheduler Console 6-4time dependencies, setting 7-23TimeScape 6-5using to create a job definition 4-4

Hheartbeat interval 15-29heartbeat.c file 4-25heartbeat_interval 4-25heartbeats

code to include 4-25interval 4-25sending from C program 4-25

high availabilityDual Event Servers 1-6, 15-15Shadow Event Processor 1-6

HostScape 6-5


■ Index

Iimporting calendars 9-31, 14-20INACTIVE status 3-14InfoReports

job find report 11-41job list report 11-41last n run report 11-41last run report 11-41

InfoReports Viewer 11-41inherit, job’s starting conditions 3-21initautosys command 11-46instances 15-9

Administrator screen 15-10cross-instance dependencies 15-34IDs 15-44

instances of AutoSys 1-10

JJIL

creating a job definition 4-3defined 1-3defining jobs 8-3defining monitor 13-21defining report 13-22example 8-17running 8-6sub-commands 8-5syntax rules 8-3

Job Definition Reference List 9-10Job Dependencies dialog 11-23Job Detail Report 11-38Job Editor 6-5, 7-1 to 7-36

creating Box Jobs 7-19creating Command Jobs 7-10creating File Watcher Jobs 7-12creating jobs with dependencies 7-15deleting definition 7-6

deleting jobs 7-29menu bar 7-5modifying job definitions 7-21one-time overrides 7-31opening definitions 7-5opening new job 7-5Owner field 7-12saving job as 7-6saving jobs 7-5setting days to run 7-27setting time dependencies 7-23

Job Information Language 1-12See also JIL

job overrides, setting 8-15, 8-16Job Profiles Manager 3-8, 3-9job profiles, creating 3-8Job Selection dialog

Box Levels field 11-18Job Name field 11-18

job status, as job dependency 3-23job_filter monitor/report attribute 13-16job_load 4-23job_name 4-5JOB_OFF_HOLD 11-7, 11-32, 11-55JOB_OFF_ICE 11-7, 11-33, 11-55JOB_ON_HOLD 11-7, 11-32, 11-55JOB_ON_ICE 11-7, 11-33, 11-55job_terminator 4-16jobs

attributes, basic 3-12backing up definitions 14-19basic job information 3-4Box Jobs 5-1

creating - GUI 7-19creating - JIL 8-10defined 3-6

calendar reference list 9-10


Index ■

jobs (contd.)changing - GUI 7-21changing - JIL 8-11Command Jobs


creatingBox Jobs - GUI 7-19Box Jobs - JIL 8-10Command Jobs - GUI 7-10Command Jobs - JIL 8-7File Watcher Jobs - GUI 7-12File Watcher Jobs - JIL 8-7

creating a job definition 4-3creating profiles for 3-8cross-instance dependencies 15-34custom calendars 3-22cycles of processing 16-3date/time dependencies

setting in GUI 7-23setting in JIL 8-12

days to run, setting 7-27defined 1-3defining in AutoSys 3-35definition

Box 3-14Command 3-13File Watcher 3-13

deletingGUI 7-29JIL 8-14

dependenciescreating with GUI 7-15creating with JIL 8-8exit codes 3-30global variables 3-33

job status 3-23time

GUI 7-23JIL 8-12

edit permissions 2-12environment 3-5environment variables for 3-8execute permssions 2-12exit code 3-30File Watcher


force starting 10-15heartbeats from 4-25holding globally 15-31list in Scheduler Console 11-12overrides

GUI 7-31JIL 8-15

owner, default 2-11permissions on NT 2-13profiles 3-5queuing 10-6, 10-15restart constant 15-36restart tries 15-35restarting wait time 15-35restoring definitions from backup file

14-21run number 3-34running 2-21saving definitions to backup file 14-19security attributes 2-18selection list 7-22sound for failure 15-47sound for success 15-47


■ Index

jobs (contd.)starting conditions 3-20

done 3-24failure 3-24notrunning 3-24success 3-24terminated 3-24

starting manually 2-20states 3-14status

ACTIVATED 3-15FAILURE 3-15INACTIVE 3-14managing 3-29ON_HOLD 3-16ON_ICE 3-17QUE_WAIT 3-16RESTART 3-16STARTING 3-15SUCCESS 3-15TERMINATED 3-16

status codes 3-14Team Agent 15-32terminating 15-36time dependencies, setting

JIL 8-12time/date dependencies 3-22types 3-3variables 3-5Zeke 15-32

JobScape 6-5

KKILLJOB 11-6, 11-33, 11-54KILLJOB Signals 15-36KillSignals, configuration parameter

15-36

Lload balancing 10-12

example 10-14force starting jobs 10-15job attributes required for 10-5maximum load on machine 10-5user-defined 10-22

load balancing, machine method 15-34load database command 14-44log files

cleanup 15-31Event Processor size 15-27Remote Agent 16-25Remote Agent directory 15-26

loggingsetting enterprise-wide directory 15-26setting local directory 15-14

Mmachine

attribute 4-8, 4-9backing up definitions 14-19client 1-10defining with JIL 10-4deleting

real machines 10-9virtual machines 10-11

factor attribute 10-6job runs on 4-8machine attribute 10-4max_load attribute 10-5permissions, edit and execute 2-12priority job attribute 10-6real 10-3restoring definitions from backup file

14-21saving definitions to backup file 14-19


Index ■

machine (contd.)server 1-10type attribute 10-4virtual 10-3

defining 10-9deleting 10-11

machine attribute 2-19Machine Method 15-34MachineMethod 15-34maintenance

backing up AutoSys definitions 14-18calendar definitions 14-18global variables 14-19job definitions 14-19machine definitions 14-19monitor and browser definitions

14-19chase command 14-16clean_files 14-17commands 14-16database 15-27database time 14-25restoring AutoSys definitions 14-20

managing job status 3-29max_exit_success 4-24max_load machine attribute 10-5max_run_alarm 4-14maximum exit code for success 3-24maximum system load 10-5MaxRestartTrys, configuration parameter

15-35MaxRestartWait, configuration parameter

15-35Microsoft SQL Server 16-3, 16-21min_run_alarm 4-14

Monitor/Browser Editor 6-5, 13-1 to 13-22

Alarm field 13-15Alarm Verification Required field 13-17All Change Status Events field 13-15All Events field 13-14Current Run Only field 13-18Events After Date/Time field 13-18Job Change Status Events field 13-16Job Filter field 13-16naming 13-7Sound field 13-17sounds, defining 15-45

monitors 13-1 to 13-22about 13-4alarm_verif 13-17backing up definitions 14-19defined 13-3defining 13-9, 13-20, 13-21restoring definitions from backup file

14-21sound 13-17

multiple machine queues 10-21

Nn_retrys 4-16notification

configuration parameters 15-39database problem 15-39database rollover 15-39Event Processor shutdown 15-40mechanism 15-37user-defined notification routines

15-37notrunning condition in job definition

3-24ntgetdate command 14-15


■ Index

ntrys 3-34NuTCRACKER environment variable

15-40

OON_HOLD 3-16ON_HOLD vs. ON_ICE 3-17ON_ICE 3-17one-time job overrides 7-31Open Client C Library 14-21optional job attributes 4-10Oracle 16-3

improving database performance 14-35SQL*Net V2 14-21SQL*Plus 14-42tablespace error 16-11troubleshooting 16-4

override_job 4-24overrides, job

GUI 7-31JIL 8-15

owner attribute 2-19owner, default 2-11

Ppasswords

autosys user 2-10database 2-10database system administrator 14-39

permission attribute 2-20, 4-18permissions 2-3, 4-18

edit 2-12, 4-19execute 2-12, 4-19granting 2-12job execute 2-11machine 2-12types 2-12, 4-19

user 2-10user types 2-11Windows NT 2-13

POEMS common services, enabling 15-33port number

Event Server 15-20Remote Agent 15-13

preferencesalarm color 6-4removing user 6-4retry count 6-4

primary domain controller, running jobs on 2-23, 2-30

priority job attribute 4-23, 10-6problem notification 15-39profiles

creating variables 3-11deleting 3-12deleting variables 3-12editing variables 3-11job 3-5managing 3-8remote logging 15-31

QQUE_WAIT status 3-16queuing

and simple load limiting 10-16as subset of virtual machine 10-19jobs 10-15multiple machine 10-21, 10-22policies 10-15with priority 10-17, 10-18


Index ■

Rreal machines 10-3

defining 10-4deleting 10-9example 10-8type 10-4

recoverydatabase 14-46Sybase database 14-46

Remote Agent 15-11configuration parameters 15-13database connectivity 16-21defined 1-7Event Processor authentication 2-9heartbeat interval 15-29log cleanup 15-31log name, assigning 16-25logging directory 15-26port number 15-13security 2-17starting 14-13, 15-55stopping 14-14, 15-55TCP/IP port number 15-13troubleshooting 16-18user authentication 2-9

remote authenticationEvent Processor 2-9, 15-14examples on NT 2-30user 2-9user example 15-49

RemoteProFiles, configuration parameter 15-31

reports 13-1 to 13-22about 13-4all_status 13-15defined 13-3defining 13-9, 13-12, 13-20, 13-22

InfoReports 11-41naming 13-7

rescheduling rules 9-25resource check, file space 4-26, 4-27restart attempts, maximum number 15-35RESTART status 3-16RestartConstant, configuration parameter

15-36RestartFactor, configuration parameter

15-36restoring

calendar definitions 14-20global variables (using autorep) 14-21job definitions (using autorep) 14-21machine definitions (using autorep)

14-21monitor and browser definitions 14-21Primary Event Processor 14-12

rolloverEvent Server 14-27Shadow Event Processor 14-10

rstatd 15-34Rule Specification region 9-21Run MonBro button 13-8run number 3-34Run Status Tool 11-24

Command field 11-27Description field 11-27End Time field 11-28Exit Code field 11-27Instance field 11-27Job Name field 11-27Next Start field 11-28Predecessor and Successor Jobs fields

11-28Priority field 11-28Queue Name field 11-28


■ Index

Run Status Tool (contd.)Run Machine field 11-27Run Time field 11-27Start Time field 11-27Starting Conditions field 11-27Status field 11-28Try Count field 11-27

run_calendar 4-11run_num/ntry, defined 3-35run_window 4-12RUNNING status 3-15

SScheduler Console 6-4, 11-1 to 11-56

buttons 11-54cancelling a sent event 11-36Control Area 11-12Filter Editor 11-15, 11-16

Machine/Instance tab 11-20Names Tab 11-17Names tab 11-17Status tab 11-19

filters 11-15InfoReports 11-41Job Dependencies dialog 11-23Job Detail Report 11-38job list 11-12menu bar 11-5Preferences

Action Area Layout 11-52AutoRefresh 11-43General 11-44Summary Area Layout 11-49Time Perspective 11-56User Defined Commands 11-45User Defined Reports 11-47

refresh interval, setting for 11-44

ReportsJob Detail Report 11-38Job Find 11-41Job List 11-41Last N Run 11-41Last Run 11-41

Send Event Tool 11-28, 11-31AUTOSERV instance 11-35Close button 11-35Comment field 11-35opening 11-29Send button 11-35

sorting specified jobs 11-51summary area 11-12time perspective 11-56Tools

Dependent Jobs 11-23Run Status Tool 11-24Send Event Tool 11-28

Tools menu 11-22user defined commands 11-45viewing job dependencies 11-23

security 2-1, 2-3, 15-48AutoSys and Windows NT 2-17configuration parameters 15-51examples for NT 2-23granting permissions 2-12job attributes 2-18job execute permissions 2-11permission types 2-12preventing unauthorized access 2-7Remote Agent 2-17running jobs 2-21starting jobs manually 2-20superusers, AutoSys 2-14Trusted Hosts 2-9, 15-48, 15-51Trusted Users 2-9, 15-48, 15-52


Index ■

security (contd.)user permissions 2-10user types 2-11

select getdate, command 14-40Send Event Tool 11-28, 11-31

AUTOSERV instance 11-35cancelling an event 11-36Change Priority 11-33Change Status 11-33Close button 11-35Comment 11-32Comment field 11-35Force Start Job 11-32Job Off Hold 11-32Job Off Ice 11-33Job On Hold 11-32Job On Ice 11-33Kill Job 11-33opening 11-29Send button 11-35Send Signal 11-34Set Global 11-34Start Job 11-32Stop Demon 11-32

SEND_SIGNAL 11-34sendevent command 2-15server instance 1-5server machine 1-10services

AutoSys 15-52AutoSys Administrator screen 15-52determining status 15-54list in AutoSys Administrator 15-54starting 15-54stopping 15-54

SET_GLOBAL 11-34Shadow Event Processor

defined 1-6rollover 14-10setting up 15-23

signals, UNIX kill 15-36socket time-out 15-35sound monitor attribute 13-17sounds

alarms 15-47AutoSys 15-45defining 15-45job failure, for 15-47job success, for 15-47

sounds, defining 15-45sp_addumpdevice 14-44SQL*Net V2 14-21SQL.INI file 15-19start_mins 4-12start_times 4-11starting conditions 3-20, 3-23STARTING status 3-15STARTJOB 8-6, 11-6, 11-32, 11-54states

See also statusjob 3-14

statusjob

ACTIVATED 3-15as job dependency 3-23FAILURE 3-15INACTIVE 3-14ON_HOLD 3-16ON_ICE 3-17QUE_WAIT 3-16RESTART 3-16RUNNING 3-15STARTING 3-15SUCCESS 3-15


■ Index

status (contd.)job (contd.)

TERMINATED 3-16tracking changes 13-15

monitor/reportfailure 13-16restart 13-16running 13-16starting 13-16success 13-16terminated 13-16

processed vs. unprocessed 3-20using in job dependencies 3-23

std_err_file 4-22std_in_file 4-20std_out_file 4-21STOP_DEMON 11-32, 14-10, 14-41,

14-47success

condition in job definition 3-24maximum exit code 3-24

SUCCESS status 3-15Summary Area Layout Dialog 11-49superusers 2-14

Edit Superuser, defined 2-14Exec Superuser, defined 2-15

Sybaseaccessing interactively 14-42architecture 14-37bundled 14-37checking if running 14-40communication with 14-37

databasedisplaying date and time 14-43identifying connected processes

14-42improving performance 14-35name 15-19

DB Library 14-37disabling 15-19DSQUERY variable 14-38environment 14-38environment variable 14-38interfaces file 14-38server 14-37shutdown command 14-41SQL.INI file 14-38starting 14-40stopping 14-41users 14-38

SYBASE variable 14-38synchronizing Event Servers 14-28syntax rules, JIL 8-3system

configuration parameters 15-43system administrator, database 14-39system information, AutoSys 15-41,

15-44system load, maximum 10-5

Ttarget machine 4-8Team Agent 15-32Team Agent support A-1Term Calendar Rule dialog 9-19term_run_time 4-15terminated condition in job definition

3-24


Index ■

TERMINATED status 3-16test mode

output file 14-15running in 14-14

ThirdMachine, configuration parameter 15-25

time dependenciesin job definition 4-10overview 3-22setting

GUI 7-23JIL 8-12

time perspective in the Scheduler Console 11-56

TimeScape 6-5timezone 4-17troubleshooting 16-1

Event Processor 16-12Event Servers 16-5Microsoft SQL Server 16-4, 16-23Oracle 16-4Remote Agent 16-18Sybase 16-4

Truste Hosts 15-49Truste Users 15-50Trusted Hosts 15-48, 15-50, 15-51Trusted Users 15-48, 15-49, 15-52typographical conventions xxv

UUNIX remote profile logging 15-31unrecoverable error, database 14-27User Defined Buttons dialog 11-45User Defined Reports dialog 11-47user types

owner 2-11world 2-11

user-definedload balancing 10-22

users, bundled Sybase 14-38utilities, provided with AutoSys 1-12

Vvirtual machines 10-3

defining 10-4, 10-9deleting 10-11example 10-9type 10-4using delete_machine 10-4using insert_machine 10-4

vmstat 15-34

WWaitTime, configuration parameter 15-35watch_file 4-9watch_file_min_size 4-26watch_interval 4-27Windows NT

job permissions on 2-13remote authentication examples 2-30

world, user types 2-11

XXInstanceDBDropTime, configuration

parameter 15-34

ZZeke 15-32Zeke and AutoSys/Team Agent support

A-1 to A-26ZTeamJobSupport, parameter 15-32


■ Index


Autosys

Documents

Transcript of Autosys