£ £

Unicenter AutoSys Job

Management for Windows

User Guide
4.5
This documentation and related computer software program (hereinafter referred to as the “Documentation”) is for
the end user’s informational purposes only and is subject to change or withdrawal by Computer Associates
International, Inc. (“CA”) at any time.

This documentation may not be copied, transferred, reproduced, disclosed or duplicated, in whole or in part,
without the prior written consent of CA. This documentation is proprietary information of CA and protected by the
copyright laws of the United States and international treaties.

Notwithstanding the foregoing, licensed users may print a reasonable number of copies of this documentation for
their own internal use, provided that all CA copyright notices and legends are affixed to each reproduced copy. Only
authorized employees, consultants, or agents of the user who are bound by the confidentiality provisions of the
license for the software are permitted to have access to such copies.

This right to print copies is limited to the period during which the license for the product remains in full force and
effect. Should the license terminate for any reason, it shall be the user’s responsibility to return to CA the reproduced
copies or to certify to CA that same have been destroyed.

To the extent permitted by applicable law, CA provides this documentation “as is” without warranty of any kind,
including without limitation, any implied warranties of merchantability, fitness for a particular purpose or
noninfringement. In no event will CA be liable to the end user or any third party for any loss or damage, direct or
indirect, from the use of this documentation, including without limitation, lost profits, business interruption,
goodwill, or lost data, even if CA is expressly advised of such loss or damage.

The use of any product referenced in this documentation and this documentation is governed by the end user’s
applicable license agreement.

The manufacturer of this documentation is Computer Associates International, Inc.

Provided with “Restricted Rights” as set forth in 48 C.F.R. Section 12.212, 48 C.F.R. Sections 52.227-19(c)(1) and (2) or
DFARS Section 252.227-7013(c)(1)(ii) or applicable successor provisions.

” 2003 Computer Associates International, Inc.

All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.
 Contents

Chapter 1: Introduction
Related Publications .......................................................................... 1–2
Jobs ......................................................................................... 1–2
Defining Jobs ............................................................................. 1–2
Graphical User Interface ............................................................... 1–3
Job Information Language ............................................................. 1–3
System Components .......................................................................... 1–4
Event Server .............................................................................. 1–5
High-Availability Option: Dual-Event Servers ........................................... 1–5
Event processor ........................................................................... 1–6
High-availability Option: Shadow Event Processor ....................................... 1–6
Remote Agent ............................................................................ 1–7
Example Scenario on Windows ............................................................. 1–8
Explanation ........................................................................... 1–9
Interface Components .................................................................... 1–10
Machines ................................................................................... 1–10

Instance ..................................................................................... 1–10

Events ...................................................................................... 1–11
Alarms ..................................................................................... 1–11

Utilities ..................................................................................... 1–12

Basic Functionality ........................................................................... 1–12
Explanation ............................................................................. 1–13

Extending Functionality ...................................................................... 1–15

Contacting Technical Support ................................................................. 1–16

Contents iii
Chapter 2: Security
Overview .....................................................................................2–1
Native Security ...............................................................................2–2

Security On Events Sent By Users ...........................................................2–2

Security On Events Sent By the Event Processor ..............................................2–4

System-Level Security .........................................................................2–7

Database Field Verification .................................................................2–7

Job Definition Encryption ..................................................................2–7

Remote Agent Authentication ..............................................................2–8

User Authentication....................................................................2–8
Event processor Authentication .........................................................2–9
User and Database Administrator Passwords ................................................2–9

Job-Level Security ........................................................................... 2–10

Job Ownership .......................................................................... 2–10
User Types.............................................................................. 2–11
Permission Types ........................................................................ 2–11
Granting Permissions ................................................................ 2–12
Job Permissions and Windows ............................................................ 2–13
Security Control ......................................................................... 2–13
Superuser Privileges ......................................................................... 2–14
Edit Superuser .......................................................................... 2–14
Exec Superuser .......................................................................... 2–15
Restricting Access to Jobs .................................................................... 2–16
Remote Agent Security ................................................................... 2–17
eTrust Access Control ....................................................................... 2–17
Policy Manager ......................................................................... 2–19
Security Access .......................................................................... 2–19
Disable Security ..................................................................... 2–20
Controlling the Event Processor ........................................................... 2–20
Asset-Level Security ..................................................................... 2–21
eTrust Resource Classes .............................................................. 2–22
eTrust Access Modes ................................................................. 2–23
Security Enabled Applications ............................................................ 2–33
Security Call Logic....................................................................... 2–34

iv User Guide
Chapter 3: Jobs
Job Types and Structure ....................................................................... 3–2
Basic Job Information ...................................................................... 3–2
Command Jobs ........................................................................... 3–3
Box Jobs .................................................................................. 3–3
Starting Conditions for Box Jobs ........................................................ 3–4
File Watcher Jobs ......................................................................... 3–5
Job Profiles ................................................................................... 3–6
Using the Job Profiles Manager ............................................................. 3–8
Basic Job Attributes .......................................................................... 3–11
Command Job Attributes ................................................................. 3–11

File Watcher Job Attributes ............................................................... 3–11

Box Job Attributes ........................................................................ 3–12

Job States and Status ......................................................................... 3–13
Example State Diagram: Simple Jobs ....................................................... 3–15
Example State Diagram: Box Jobs .......................................................... 3–17
Starting Parameters .......................................................................... 3–19
Starting Parameters and Boxes ............................................................ 3–19

Date/Time Dependencies ................................................................. 3–20

TZ Environment Variable ............................................................. 3–20
Custom Calendars.................................................................... 3–21
Job Dependencies Related to Job Status .................................................... 3–21

Cross-Instance Job Dependencies ...................................................... 3–23

Event processors ......................................................................... 3–25

Event Servers ............................................................................ 3–25
Example Job Dependencies ............................................................ 3–26
Managing Job Status .................................................................. 3–27
Job Dependencies Based on Exit Codes ..................................................... 3–28
Using Exit Codes and Batch Files with Jobs Running on Windows ........................ 3–29

Job Dependencies Based on Global Variables ............................................... 3–30

Job Run Numbers and Names................................................................. 3–31

Defining Jobs ................................................................................ 3–32
Graphical User Interface Components...................................................... 3–32

Contents v
Chapter 4: Job Attributes
Job Attributes and Job Definitions ..............................................................4–1

Using JIL to Create a Job Definition .........................................................4–2

Using the Job Editor to Create a Job Definition ...............................................4–2

Organization ..............................................................................4–3
Essential Job Attributes ........................................................................4–4
Attributes Common to All Job Types ........................................................4–4
Job Name .............................................................................4–4
Job Type ..............................................................................4–4
Job Owner ............................................................................4–4

Command Jobs Attributes ..................................................................4–5

Command ............................................................................4–5

Machine to Run On ....................................................................4–7

File Watcher Job Attributes .................................................................4–8

Machine to Run On ....................................................................4–8

File to Watch For ......................................................................4–8

Box Job Attributes .........................................................................4–8

Optional Job Attributes ........................................................................4–9

Common Job Starting Attributes ............................................................4–9

Start Date /Time Dependence...........................................................4–9
Days of the Week ......................................................................4–9
Days to Run on —Using a Custom Calendar .............................................4–9

Days to NOT Run on—Using a Custom Calendar ....................................... 4–10

Specific Times of Day to Run.......................................................... 4–10
Time of Day Not to Run .............................................................. 4–10
Specific Times Every Hour to Run ..................................................... 4–11
Job Dependencies .................................................................... 4–11
Common General Attributes .............................................................. 4–12
Description.......................................................................... 4–12
Box Name ........................................................................... 4–12
Minimum Run Time Alarm ........................................................... 4–12
Maximum Run Time Alarm .......................................................... 4–13
Terminate Due to Run Time .......................................................... 4–13
Send Alarm if the Job Fails ............................................................ 4–13
Terminate the Box if the Job Fails ...................................................... 4–14

vi User Guide
 Terminate the Job if the Box Fails ...................................................... 4–14

Number of Times to Restart a Job ...................................................... 4–15

Time Zone for Job .................................................................... 4–15
Delete Job After Completion........................................................... 4–16
Autohold ............................................................................ 4–16
Permissions .......................................................................... 4–17
Command Job Attributes ................................................................. 4–18

Profile ............................................................................... 4–18

Redirection of the Standard Input File .................................................. 4–19
Redirection of the Standard Output File ................................................ 4–19
Redirection of the Standard Error File .................................................. 4–20
Job Load............................................................................. 4–21
Queue Priority ....................................................................... 4–21
Job Overrides ........................................................................ 4–22
Maximum Exit Code for Success ....................................................... 4–22
Average Runtimes.................................................................... 4–23
Heartbeat-Interval .................................................................... 4–23
Resource Check - File Space ........................................................... 4–24
File Watcher Job Attributes ............................................................... 4–25

Watch File Minimum Size ............................................................. 4–25

Watch Interval ....................................................................... 4–25
Resource Check - File Space ........................................................... 4–25
Box Job Attributes ........................................................................ 4–26
Box Successful Completion ............................................................ 4–26
Box Failure .......................................................................... 4–26

Date and Time Attributes and Time Changes ................................................... 4–27

The Time Change ........................................................................ 4–27
Behavior During Time Change ............................................................ 4–28
Spring Time Change .................................................................. 4–29
Fall Time Change .................................................................... 4–31

Testing the Fall Time Change .......................................................... 4–32

Contents vii
Chapter 5: Box Job Logic
Basic Box Concepts ............................................................................5–1
Default Box Job Behavior ...................................................................5–1
When You Should Not Use a Box ...........................................................5–2

What Happens When a Box Runs ...........................................................5–3

Simple Box Job ........................................................................5–4

Box Job Attributes and Terminators .............................................................5–5

Attributes in a Box Job Definition ...........................................................5–5

Example of a Non-Default Success Condition .............................................5–5

Attributes in a Job Definition ...............................................................5–6

Time Conditions in a Box...................................................................5–6

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–10
Default Box Success and Box Failure ...................................................... 5–12
Explicit Box Success and Box Failure ...................................................... 5–13
Using the Box Terminator Attribute ....................................................... 5–14
Using the Job Terminator Attribute ........................................................ 5–15
Advanced Job Streams ................................................................... 5–16
Scenario On the First of the Month .................................................... 5–16
Scenario On the Second of Month ..................................................... 5–17
Scenario I On First of the Month ....................................................... 5–18
Scenario II On First of the Month ...................................................... 5–19
Scenario III On First of the Month ..................................................... 5–20

viii User Guide

Chapter 6: Introduction to the Graphical User Interface
Starting the GUI Control Panel ................................................................. 6–1
Using the GUI Control Panel ................................................................... 6–2
GUI Control Panel Menu Bar ............................................................... 6–2
File Menu ............................................................................ 6–2
Tools Menu ........................................................................... 6–3
Preferences Menu ..................................................................... 6–3
Help Menu ........................................................................... 6–4
GUI Control Panel Buttons ................................................................. 6–4

Chapter 7: Defining Jobs Using the Job Editor

Starting the Job Editor ......................................................................... 7–1
Using the Job Editor Interface .................................................................. 7–3
Job Editor Menu Bar....................................................................... 7–3
File Menu ............................................................................ 7–3
Edit Menu ............................................................................ 7–4
Options Menu ........................................................................ 7–5
Help Menu ........................................................................... 7–5
Job Editor Tabs ........................................................................... 7–5
Job Editor Status Area ..................................................................... 7–6
Required Values for Command Jobs .................................................... 7–6
Required Values for Box Jobs ........................................................... 7–7
Required Values for File Watcher Jobs................................................... 7–7
Creating a Simple Command Job ............................................................... 7–8
Creating a File Watcher Job ................................................................... 7–10
Creating a Dependent Command Job .......................................................... 7–12
Creating a Box Job ........................................................................... 7–14

Creating the EOD_box Box Job ............................................................ 7–14

Modifying the EOD_post Command Job ................................................... 7–16

Setting Date and Time Dependencies .......................................................... 7–18

Setting Days of the Week Starting Conditions ............................................... 7–19
Setting the Run Days Option .......................................................... 7–19

Setting Run Calendar and Exclude Calendar Options .................................... 7–20

Setting Time Starting Conditions .......................................................... 7–20

Contents ix
 Setting Time Zones .................................................................. 7–21
Example on Setting Date and Time Dependencies .......................................... 7–22
Deleting Jobs ............................................................................... 7–24
Notes on Deleting a Box Job .............................................................. 7–25
Specifying One-Time Job Overrides ........................................................... 7–26
Setting Job Overrides .................................................................... 7–26
Notes on One-Time Overrides ........................................................ 7–27
Deleting One-Time Overrides............................................................. 7–28
Enabled Job Editor Fields for One-Time Overrides .......................................... 7–28

Chapter 8: Defining Jobs Using JIL

Job Information Language (JIL) .................................................................8–1
JIL Syntax Rules ...........................................................................8–2
Rule 1 ................................................................................8–2

Rule 2 ................................................................................8–2

Rule 3 ................................................................................8–2

Rule 4 ................................................................................8–2

Rule 5 ................................................................................8–3

Rule 6 ................................................................................8–3

Rule 7 ................................................................................8–3

JIL Sub-commands ........................................................................8–4

Submitting Job Definitions .................................................................8–4

Running JIL ...............................................................................8–5

Creating a Simple Command Job ...............................................................8–5

Creating a File Watcher Job ....................................................................8–6

Creating a Dependent Command Job............................................................8–7

Creating a Box ................................................................................8–9

x User Guide
Changing a Job .............................................................................. 8–10
Setting Time Dependencies ................................................................... 8–11
Additional Time Setting Features .......................................................... 8–11
Deleting a Job ............................................................................... 8–12

Deleting a Box Job .................................................................... 8–12

Specifying One-Time Job Overrides ........................................................... 8–13

Setting Job Overrides ..................................................................... 8–14

Example JIL Script ........................................................................... 8–15

Chapter 9: Calendar Editor

Using Defined Calendars ...................................................................... 9–2
Scheduling Jobs with Calendars ............................................................ 9–2
Starting the Calendar Editor ................................................................... 9–4
Using the Calendar Editor Interface ............................................................ 9–5
Using the Menu Bar ....................................................................... 9–5
File Menu ............................................................................ 9–5
Edit Menu ............................................................................ 9–7
Utilities Menu ........................................................................ 9–7
Preferences Menu ..................................................................... 9–7
Help Menu ........................................................................... 9–9
Using the Navigation Controls ............................................................. 9–9
Selections Area ........................................................................ 9–9
Conflicts Area ....................................................................... 9–10

Instance Area ........................................................................ 9–10

Calendars Area ...................................................................... 9–10

Using the Calendar Display ............................................................... 9–11

Date States........................................................................... 9–11
Creating and Modifying Calendars ............................................................ 9–13
Creating a Calendar ...................................................................... 9–13
Setting Dates Prior to Today’s Date .................................................... 9–14

Opening an Existing Calendar............................................................. 9–15

Applying Rules to Calendars ................................................................. 9–17

Using the Rule Specification Area ......................................................... 9–18

Action Area.......................................................................... 9–18

Contents xi
 Date Range Area..................................................................... 9–19
Date Selection Rule Area ............................................................. 9–19
Date Selection Rule Examples ......................................................... 9–20
Using the Rescheduling Rule Area ........................................................ 9–22
Move Direction Area ................................................................. 9–22
To Day Area ........................................................................ 9–23
Rescheduling Rule Example .......................................................... 9–23
Combining Existing Calendars ............................................................... 9–24
Combining Calendars Example ........................................................... 9–24
Using the Job Definition Reference List ........................................................ 9–26
Importing and Exporting Calendars ........................................................... 9–27
Importing Calendar Text Files ............................................................ 9–27
Exporting Calendars ..................................................................... 9–28

Chapter 10: Load Balancing and Queing Jobs

Real Machines .............................................................................. 10–1
Virtual Machines ............................................................................ 10–2
Defining Machines .......................................................................... 10–2
Specifying Machine Load (max_load) ......................................................... 10–3
Job Attributes and Load Balancing and Queuing ........................................... 10–4
Specifying Relative Processing Power (factor) .............................................. 10–4
Using max_load and factor ............................................................... 10–5
Machine Definitions ......................................................................... 10–6
Defining a Real Machine ..................................................................... 10–7
Deleting Real Machines .................................................................. 10–7
Defining a Virtual Machine .................................................................. 10–8
Deleting Virtual Machines ............................................................... 10–10
Load Balancing ............................................................................ 10–11

xii User Guide

Force Starting Jobs .......................................................................... 10–13
Queuing Jobs ............................................................................... 10–13
Queuing and Simple Load Limiting....................................................... 10–14
Queuing with Priority ................................................................... 10–15
Subsets—Individual Queues ............................................................. 10–17
Load Units and Virtual Machines ......................................................... 10–18
Multiple Machine Queues ............................................................... 10–18

User-Defined Load Balancing ................................................................ 10–19

Chapter 11: Scheduler Console

Using the Scheduler Console .................................................................. 11–1
Using the Scheduler Console Menu Bar .................................................... 11–3

File Menu ........................................................................... 11–3

Filters Menu ......................................................................... 11–3

Actions Menu ........................................................................ 11–3
Tools Menu .......................................................................... 11–5
Applications Menu ................................................................... 11–5
Reports Menu ........................................................................ 11–6
Preferences Menu .................................................................... 11–6

Help Menu .......................................................................... 11–7

Using the Control Area ................................................................... 11–8

Using the Summary Area ................................................................. 11–8
Summary Area Information ........................................................... 11–9
Selecting Jobs ........................................................................ 11–9
Defining Scheduler Console Filters ........................................................... 11–11
Filters Editor Dialog ..................................................................... 11–12
File Menu .......................................................................... 11–12

Names Tab ......................................................................... 11–13

Status Tab .......................................................................... 11–14

Machines/Instances Tab ............................................................. 11–15
Using the Filter Editor ................................................................... 11–16
Using Scheduler Console Tools .............................................................. 11–17

Using the Job Dependencies Dialog ....................................................... 11–18

Using the Run Status Tool ............................................................... 11–20

Contents xiii
 Run Status Tool Menu Bar ........................................................... 11–21
Run Status Tool Display Fields ....................................................... 11–22
Using the Send Event Tool .............................................................. 11–23
Opening the Send Event Tool ........................................................ 11–24
Send Event Tool Menu Bar .......................................................... 11–25
Send Event Tool Fields .............................................................. 11–26
Sending an Event ................................................................... 11–29
Canceling a Sent Event .............................................................. 11–30
Using Scheduler Console Reports ............................................................ 11–32
Using the Job Detail Report Tool ......................................................... 11–32
Job Detail Report Menu Bar .......................................................... 11–33
Setting Scheduler Console Preferences ....................................................... 11–34
Using the General Dialog ................................................................ 11–35
Using the User-Defined Buttons Dialog ................................................... 11–36
Creating Command Buttons ......................................................... 11–36
Using AutoSys-Specific Commands .................................................. 11–37
Using the User Defined Reports Dialog ................................................... 11–38
Creating Reports Menu Items ........................................................ 11–38
Using the Summary Area Layout Dialog .................................................. 11–39
Customizing the Summary Area in the Scheduler Console .............................. 11–39
Customizing the Display with the Summary Area Layout Dialog ........................ 11–40
Sort Key Settings ................................................................... 11–41
Using the Action Area Layout Dialog..................................................... 11–42
Action Area Layout Tool and Action Buttons .......................................... 11–43
Setting the Time Perspective ............................................................. 11–44

Chapter 12: Managing Alarms

Using the Alarm Sentry ...................................................................... 12–1
Using the Alarm Sentry Menu Bar ........................................................ 12–2
File Menu ........................................................................... 12–2
Preferences Menu .................................................................... 12–2
Help Menu .......................................................................... 12–2
Using the Alarm Manager .................................................................... 12–3
Using the Alarm Manager Menu Bar ...................................................... 12–4

xiv User Guide

 File Menu ........................................................................... 12–4

Filters Menu ......................................................................... 12–4

Tools Menu .......................................................................... 12–5
Preferences Menu .................................................................... 12–5

Help Menu .......................................................................... 12–6

Using the Alarm Manager Alarm List ...................................................... 12–6

Viewing the Currently Selected Alarm ..................................................... 12–7
Registering Responses and Changing Alarm States ...................................... 12–8
Setting the Refresh Behavior .............................................................. 12–8

Filtering Alarms ............................................................................. 12–9

Selecting Alarms by Type ................................................................ 12–10
Selecting Alarms by State ................................................................ 12–11
Selecting Alarms by Instance ............................................................. 12–11
Selecting Alarms by Time ................................................................ 12–11

Chapter 13: Monitoring and Reporting on Jobs

Using AutoSys Monitors and Browsers ........................................................ 13–1

Using Monitors .......................................................................... 13–2

Using Reports ........................................................................... 13–3

Using the Monitor/Browser Editor ............................................................ 13–4

Using the Monitor/Browser Editor Menu Bar............................................... 13–5
File Menu ........................................................................... 13–5

Edit Menu ........................................................................... 13–6

Help Menu .......................................................................... 13–6

Defining Monitors and Reports with the Editor ................................................. 13–7

Defining a Monitor ....................................................................... 13–7
Defining a Report ........................................................................ 13–9
Closing the Monitor/Browser Editor ...................................................... 13–10

Contents xv
Setting Monitor and Report Attributes ....................................................... 13–11
Setting Event Types ..................................................................... 13–11
Setting the Job Selection Criteria ......................................................... 13–13
Setting Monitor Options................................................................. 13–14
Setting the Browser Time Criteria ........................................................ 13–15
Running a Monitor or Generating a Report ................................................... 13–16
Defining Monitors and Reports Using JIL ..................................................... 13–17
Defining Monitors Using JIL ............................................................. 13–18

Chapter 14: Maintaining

Maintaining the Event Processor .............................................................. 14–1
Starting the Event Processor .............................................................. 14–1
Event Processor Starting Processes .................................................... 14–2
Monitoring the Event Processor ........................................................... 14–3
Location of the Event Processor Log File ............................................... 14–4
Event Processor Log File Size ......................................................... 14–4
Starting the Event Processor in Global Auto Hold Mode ........................................ 14–5
Stopping the Event Processor ............................................................. 14–7
Shadow Event Processor Rollover ......................................................... 14–8
Restoring the Primary Event Processor................................................. 14–9
Maintaining the Remote Agent .............................................................. 14–10
Starting the Remote Agent............................................................... 14–10
Stopping a Remote Agent ............................................................... 14–11
Running in Test Mode ...................................................................... 14–12
%AUTOTESTMODE% = 1............................................................... 14–13
%AUTOTESTMODE% = 2............................................................... 14–13
Maintenance Commands .................................................................... 14–14
chase .................................................................................. 14–14
clean_files ............................................................................. 14–15
Backing up Definitions...................................................................... 14–16
Restoring Definitions ....................................................................... 14–18
Database Overview ......................................................................... 14–19
Event Server Overview ..................................................................... 14–20
Using Dual Event Server Mode .......................................................... 14–20

xvi User Guide

 Database Storage Requirements .......................................................... 14–21

Database Architecture ....................................................................... 14–22

General Database Maintenance............................................................... 14–23
Daily Database Maintenance ............................................................. 14–23
DBMaint.bat Batch File .................................................................. 14–24
Modifying the DBMaint.bat File .......................................................... 14–25
Data Locking ........................................................................... 14–25
Event Server Rollover Recovery .............................................................. 14–26
Returning to Dual Server Mode After a Rollover ........................................... 14–27
Synchronizing the Databases ............................................................. 14–28
To synchronize the databases ......................................................... 14–29
Synchronizing Sybase Databases...................................................... 14–30
Synchronizing Oracle Databases ...................................................... 14–31
Synchronizing Microsoft SQL Server Databases ........................................ 14–31
Handling Errors ..................................................................... 14–32
Improving Database Performance ............................................................ 14–33
Improving Sybase Database Performance ................................................. 14–33

Improving Oracle Database Performance .................................................. 14–33

Maintaining Bundled Sybase SQL Servers ..................................................... 14–35
Sybase Architecture ..................................................................... 14–35
Sybase Environment .................................................................... 14–35

Default Sybase Users .................................................................... 14–36

Database Users...................................................................... 14–36
Changing the System Administrator Password ......................................... 14–37
Starting Sybase ......................................................................... 14–37

Stopping Sybase ........................................................................ 14–38

Accessing Sybase ....................................................................... 14–39

Identifying Processes Connected to the Database ........................................... 14–40

Displaying the Database Date and Time ................................................... 14–41

Contents xvii
 Bundled Sybase Backup and Recovery.................................................... 14–41
Configuring a Backup Server ........................................................ 14–42
Backing up the Database to a File ..................................................... 14–43
Recovering a Bundled Sybase Database ............................................... 14–43
Stopping the Event Processor ........................................................ 14–44
Dropping the Damaged Database .................................................... 14–44
Re-Creating the Database ............................................................ 14–44
Reloading the Database ............................................................. 14–45
Restarting the Event Processor ....................................................... 14–45

Chapter 15: Administrator

About the Administrator ..................................................................... 15–1
Starting the Administrator ................................................................... 15–3
Administrator Menu Bar and Toolbar ..................................................... 15–3
Administrator Menu Bar ............................................................. 15–4
Instances ................................................................................... 15–6
Administrator Instance Screen ............................................................ 15–7
Remote Agents .............................................................................. 15–9
Administrator Remote Agent Screen ...................................................... 15–9
Defining Remote Agent Configuration Parameters ..................................... 15–10
Event Servers .............................................................................. 15–12
Dual-Event Servers ..................................................................... 15–12
Administrator Event Server Screen ....................................................... 15–13
Defining Event Server Configuration Parameters ...................................... 15–14
Event Processors ........................................................................... 15–18
Administrator Event Processor Screen .................................................... 15–19
Defining Event Processor Configuration Parameters ................................... 15–20
Event Processor Options ............................................................. 15–31
Broker Options ..................................................................... 15–34
Notification Mechanism .................................................................... 15–35
Administrator Notifications Screen ....................................................... 15–36
Notification Example................................................................ 15–37
Defining Notifications Configuration Parameters ...................................... 15–37
System Information ........................................................................ 15–38

xviii User Guide

 Administrator System Information Screen ................................................. 15–39
Using the System Information Screen ................................................. 15–40

System Information Configuration Parameters ......................................... 15–40

Sounds .................................................................................... 15–43

Administrator Sounds Screen ............................................................ 15–43

Defining Sounds Configuration Parameters ............................................ 15–44

Security .................................................................................... 15–46
User Remote Authentication Example..................................................... 15–47
Administrator Security Screen ............................................................ 15–48
Defining Security Configuration Parameters ........................................... 15–49
Services .................................................................................... 15–50
Administrator Services Screen ............................................................ 15–50
Services Screen Components ......................................................... 15–52

Using the Services Screen ............................................................ 15–53

Chapter 16: Troubleshooting

Introduction ................................................................................. 16–2
Windows Services Troubleshooting ........................................................... 16–3

Event Server Troubleshooting ................................................................. 16–4

Event Server Is Down (Sybase) ............................................................ 16–4
Sybase Deadlock ......................................................................... 16–5
Not Enough User Connections (Bundled Sybase) ............................................ 16–6
archive_events Fails (Bundled Sybase) ..................................................... 16–8

Event Server Unable to Extend Tablespace (Oracle) ......................................... 16–9

Event Processor Troubleshooting .............................................................. 16–9

Event Processor Is Down ................................................................ 16–10

Event Processor Will Not Start ........................................................... 16–10

Contents xix
Remote Agent Troubleshooting .............................................................. 16–15
Remote Agent Verification .............................................................. 16–15
autoping ........................................................................... 16–15
Database Verification ............................................................... 16–15
Remote Agent Will Not Start ............................................................ 16–16
Remote Agent Starts, Command Runs: No RUNNING Event Is Sent ........................ 16–17
xql Will Not Start (Sybase Only) ......................................................... 16–20
Job Failure Troubleshooting ................................................................. 16–21
Remote Agent Will Start: Command Will Not Run ......................................... 16–21

Appendix A: Integrating with the Mainframe and Unicenter

AutoSys Agents for AS/400 and OpenVMS
Definition of Terms ........................................................................... A–2
Related Documentation ................................................................... A–3
Job Scheduling for the Enterprise .............................................................. A–4

Prerequisites ............................................................................. A–4

Configuring for Enterprise Job Scheduling ...................................................... A–5
Stop the Event Processor .................................................................. A–5

Configure the Machine .................................................................... A–5

Set the AutoSysAgentSupport Parameter ............................................... A–5

Set the Receive Remote Job Submissions Parameter ...................................... A–5

Create the config.EXTERNAL File ...................................................... A–6

config.EXTERNAL Examples: .......................................................... A–7
Ensure Consistent Integration Settings .................................................. A–7
Configure the Communication Components ............................................. A–8
Restart the Event Processor ................................................................ A–8
About asbIII ................................................................................. A–9

Environment Variable for asbIII ........................................................... A–10

PRIMARYCCISYSID ................................................................. A–10
Bi-Directional Scheduling ................................................................ A–11

Running Jobs on Behalf of a Workload Manager ........................................ A–11

Unicenter AutoSys JM Connect Cross-Platform Dependencies ................................... A–12
Job Scheduler Interdependencies .......................................................... A–13
Notation for Cross-Platform Job Dependencies ............................................. A–14

xx User Guide
 Unicenter AutoSys JM Connect Cross-Platform Dependency Example .................... A–15
Naming Conventions for Unicenter AutoSys JM Connect Cross-Platform Jobs ................ A–15
Running Jobs on Agents ..................................................................... A–16
Agent Job Names and User IDs ........................................................... A–17
Running Jobs On Agent Managed Machines ............................................... A–17
Defining Agent Machines ................................................................ A–18
Job Definition Examples ............................................................. A–19
Unicenter AutoSys Agent Machine In an Job Definition ..................................... A–20
Log and Trace Information .................................................................. A–20
Unicenter AutoSys JM Connect and Unicenter AutoSys Agent Job Statuses ....................... A–21
Unsupported Attributes for Unicenter AutoSys JM Connect or Unicenter AutoSys Agent Jobs ..... A–22
Cross-Platform Limitations .................................................................. A–23

Appendix B: Troubleshooting CCI

Troubleshooting Tools for Remote CCI Connections ............................................. B–1

netstat ................................................................................... B–1

ping ..................................................................................... B–2

nslookup ............................................................................. B–2

traceroute and tracert .................................................................. B–3
ccinet ................................................................................ B–3

CCI Command Line Controls .................................................................. B–4

ccicntrl ................................................................................... B–4

ccicntrl [start | stop] [tpd, nrs, nrc, rmt] ................................................. B–4

ccicntrl install [tpd | nrs | nrc | rmt ] PATH ............................................. B–4

ccicntrl status ......................................................................... B–4
rmtcntrl .................................................................................. B–5
rmtcntrl status ........................................................................ B–5

rmtcntrl debugon and rmtcntrl debugoff ................................................ B–5

rmtcntrl hats .......................................................................... B–5

rmtcntrl rrt ........................................................................... B–5

rmtcntrl ping sysid .................................................................... B–6

rmtcntrl reconnect [All] sysid ........................................................... B–6
rmtcntrl disconnect sysid .............................................................. B–6

rmtcntrl release ....................................................................... B–6

Contents xxi
Appendix C: General Debugging
Values ...................................................................................... C–1

Appendix D: Unicenter Integration

Running Unicenter AutoSys JM 4.5/Unicenter NSM Framework Integration Utility ............ D–1

Modifying Admin Configuration to Publish Events to the Unicenter Console................... D–4

After the Integration Process ........................................................... D–5
Removing Icons from WorldView ...................................................... D–6

xxii User Guide

Chapter

Introduction
1
This guide is for users responsible for defining jobs to Unicenter AutoSys Job
Management (Unicenter AutoSys JM) 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 Unicenter AutoSys JM
using the procedures described in the Unicenter AutoSys Job Management for
Windows Installation Guide.

Unicenter AutoSys JM is an automated job control system for scheduling,

monitoring, and reporting. These jobs can reside on any configured machine that
is attached to a network.

Note: In this guide, the term Windows refers to Microsoft Windows operating
systems, Windows NT and higher. Unless specifically designated, Windows
refers to any Microsoft Windows operating system supported by AutoSys.

A job is any single command, executable, script, or Windows batch file. Each 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 Unicenter AutoSys JM to
address your distributed computing needs will evolve over time. As you become
more familiar with both the features of Unicenter AutoSys JM and the
characteristics of your own jobs, you will also refine your use of Unicenter
AutoSys JM.

However, before you install and use Unicenter AutoSys JM, it is important to
understand the basic system, its components, and how these components work
together.

This chapter provides a brief overview of Unicenter AutoSys JM, its system
architecture, and features.

Introduction 1–1
Related Publications

Related Publications
As you use this Unicenter AutoSys Job Management for Windows User Guide,
you may find it helpful to have these additional books available for reference:

■ Unicenter AutoSys Job Management Release Summary, which provides

important information about this release. Please read this before proceeding.

■ Unicenter AutoSys Job Management for Windows Installation Guide, which

describes the basic configurations, how to install Unicenter AutoSys JM,
including how to configure components, databases, and high-availability
features. In addition, this guide describes how to enter license keys.

■ Unicenter AutoSys Job Management for Windows and UNIX Reference

Guide, which lists the commands and job, machine, monitor, and report
definition parameters. It also describes system states, database tables and
views, and the API.

Jobs
In the Unicenter AutoSys JM environment, a job is a single action that can be
performed on a valid client machine. On UNIX, this action can be any single
command or shell script, and on Windows, this action can be any single
command, executable, or batch file. In addition, job definitions include a set of
qualifying attributes.

For information on defining, running, managing, monitoring, and reporting on

jobs, see the chapters in this guide.

Defining Jobs

Using 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
job definition. You can use the following methods to create job definitions:

■ Using the graphical user interface (GUI).

■ Using the Job Information Language (JIL) through a command-line interface.

1–2 User Guide

 Jobs

Graphical User Interface

The 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 JIL subcommands 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 jobs.

Job Information Language

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 you exit JIL, the job definition is
loaded into the 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 database.

Introduction 1–3
System Components

System Components
The following are the main system components:

■ Event server (database)

■ Event processor

■ Remote agent

In addition, Unicenter AutoSys JM provides utilities to help you define, run, and
maintain instances and jobs. The included utilities are platform-specific;
however, all platforms include the GUI components and JIL. Both the GUI and
JIL allow you to define, manage, monitor, and report on jobs.

The following illistration shows the system components in a basic configuration.

In addition, this displays the communication paths between the components.

1–4 User Guide

 System Components

Event Server

The event server or 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 information, events, and job
definitions are stored.

Occasionally, the database is called a data server, which actually describes a

server instance. That is, it is either a UNIX or Windows process, and it is
associated data space (or raw disk storage), which can include multiple
databases or tablespaces.

Note: The 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.

High-Availability Option: Dual-Event Servers

Unicenter AutoSys JM 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, 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 Unicenter
AutoSys JM, the database can run stand-alone for Unicenter AutoSys JM only, or
it can be shared with other applications.

For more information about using dual-event servers, see Dual-event Servers in
the chapter “Introduction” in the Unicenter AutoSys Job Management for
Windows Installation Guide.

Introduction 1–5
System Components

Event processor

The event processor is the heart of Unicenter AutoSys JM; it interprets and
processes all the events it reads from the database. Sometimes called the
event_demon, the event processor is the program, running either as a UNIX
process or as a Windows service that actually runs Unicenter AutoSys JM. 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 may be the starting or stopping of jobs, checking for
resources, monitoring existing jobs, or initiating corrective procedures.

High-availability Option: Shadow Event Processor

Unicenter AutoSys JM 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.

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 about running a shadow event processor, see Shadow
Event processor in the chapter “Introduction,” in the Unicenter AutoSys Job
Management for Windows Installation Guide.

1–6 User Guide

 System Components

Remote Agent

On a UNIX machine, the remote agent is a temporary process started by the

event processor to perform a specific task on a remote (client) machine. On a
Windows machine, the remote agent is a Windows 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, and 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.

Introduction 1–7
System Components

Example Scenario on Windows

The following example scenario and the numbered explanations illustrate the
interactions between the event server, the event processor, and remote agents.

In the example, the following Windows command line is to be run on

“WorkStation_2,” at the start date and time specified in the job definition:
del C:\tmp\*.*

Note: Understanding this example will help you answer many questions that
may arise during your experiences with Unicenter AutoSys JM.

PROCESS PROCESS
PROCESS

Event Processor Remote Agent

1
• Determines Actions • Receives instructions from
Event Processor
2 3
• Initiates Action: Start
job on machine • Initiates Action: Starts Child
command: Process
'del C:\tmp\*.*'
• Waits for Exit Code
(From Child Process)

• Sends Exit event back to

Event Server

PROCESS
5 WorkStation_2
PROCESS Windows NT/2000
Command
Event Server 4
• Runs NT/2000
• Events command:
'del C:\tmp\*.*'
• Job Definitions
Local Area • Completes execution
Network and exits with status

Note: In this illistration, the three primary components are shown running on
different machines. Typically, the event processor and the event server run on
the same machine.

1–8 User Guide

 System Components

Explanation

The following numbered steps explain the interactions in the example scenario:

1. From the event server, the event processor reads a new event, which is a
start job event with a start time condition that has been met. Then the event
processor reads the appropriate job definition from the database and, based
on that definition, determines what action to take. In the example, it runs the
following command on “WorkStation_2”:
del C:\tmp\*.*

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 “forks” a child
process that will actually run the specified command.

4. The command completes and exits, and the remote agent captures the
command’s exit code.

5. The remote agent communicates the event (exit code, status, and so forth)
directly to the event server. If the database is unavailable for any reason, the
remote agent will go into a wait and resend cycle until it can deliver the
message.

Only two processes need to be running: the event processor and the event server.
When these two components are running, Unicenter AutoSys JM is fully
operational. The remote agent process is started on a client machine once per job.
As soon as the job ends and the remote agent process sends a completion event
to the database, the remote agent exits.

Note: The remote agent is started on the client machine by the event processor
talking to the Remote Agent Service on the client machine. For this to happen,
Remote Agent Service must also be running on the client machine.

Introduction 1–9
Machines

Interface Components

To define, monitor, and report on jobs, you can use either the GUI or JIL. In
addition, the Scheduler Console and its dialogs provide a sophisticated method
of monitoring jobs in real time. This feature lets you view all jobs that are
defined, whether or not they are currently active.

Unicenter AutoSys JM also provides the Unicenter AutoSys Administrator,

which allows you to set 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 jobs, see
the chapters in this guide.

Machines
From a hardware perspective, the architecture is composed of the following two
types of machines attached to a network:

■ Server Machine

The server is the machine on which the event processor 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 client is the machine on which the remote agent software resides, and
where jobs are to run. A remote agent must be installed on the server
machine and can also be installed on separate physical client machines.

Instance
An instance is one licensed version of software running as an server with one or
more clients, on a single machine or on multiple machines. An 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 instances.

1–10 User Guide

 Events

You may want to install multiple instances. For example, you may 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
Unicenter AutoSys JM 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, and so forth

■ Internal 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
Alarms are special events that notify operations personnel of situations requiring
their attention. Alarms are integral to the automated use of Unicenter AutoSys
JM. 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.

These are some important aspects of alarms:

Introduction 1–11
Utilities

■ 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 the chapters “Scheduler Console,”
“Managing Alarms,” and “Monitoring and Reporting on Jobs,” in this guide.

Utilities
To help you define, control, and report on jobs, Unicenter AutoSys JM 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.

Unicenter AutoSys JM 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 Unicenter AutoSys
JM and its components. Unicenter AutoSys JM also provides a database
maintenance utility that runs daily by default.

Basic Functionality
The following figure and the numbered explanations that follow it illustrate how
Unicenter AutoSys JM performs its most basic function—starting a job (that is,
executing a command) on a client machine.

Working through this example will be very helpful for understanding how
Unicenter AutoSys JM processes jobs.

1–12 User Guide

 Basic Functionality

Note: In the following illistration, the major components are shown as separate
entities. Typically, the event processor and the event server are installed on the
same server machine (along with a required remote agent), and other remote
agents are installed on separate client machines.

Event Processor

5
3
1 2
Unicenter
AutoSys JM
Client
Event Server agent
(Database) connect

4
7

Remote Agent

9 6 8

Client Job

Explanation
1. The event processor scans the event server for the next event to process. If no
event is ready, the event processor scans again in 5 seconds.

2. The event processor reads from the event server that an event is ready. If the
event is a STARTJOB event, the job definition and attributes are retrieved
from the event server, including the command and the pointer (full path
name on the client machine) to the profile file to be used for the job. In
addition, for jobs running on Windows machines, the event processor
retrieves from the database the user IDs and passwords 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.

Introduction 1–13
Basic Functionality

4. On a UNIX machine, the inetd invokes the remote agent. On a Windows

machine, the remote agent logs onto the machine as the user defined as the
job’s owner, using the user IDs and passwords 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.

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 configuration file on UNIX or with the Unicenter AutoSys
Administrator on Windows).

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.

1–14 User Guide

 Extending Functionality

Extending Functionality
You can extend jobs with the Unicenter AutoSys JM Connect and Unicenter
AutoSys Agent integration components. Using cross-platform job dependency
notation, you can define jobs to conditionally start based on the status of an
Unicenter AutoSys JM Connect job running on a mainframe, and you can define
Unicenter AutoSys JM Connect jobs to conditionally start based on the status of
an job. You can also define jobs that will run on an Unicenter AutoSys Agent
machine, if the Unicenter AutoSys Agent machine is defined to Unicenter
AutoSys JM.

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 Unicenter
AutoSys JM.

The following illistration shows an extended configuration that includes the

Unicenter AutoSys JM Connect and Unicenter AutoSys Agent integration
components and an Unicenter AutoSys JM/Adapter installation on a UNIX
client.

Unicenter AutoSys JM Server

UNIX Client (UNIX or Windows) Windows Client

UNIX Job Remote Agent

Event Server
(Database)
Remote Agent NT Job

Event Processor
Adapter

asbIII
Application

Other OS CCI Mainframe

(for example:
(OS/390)
AS/400)

CCI CCI

AutoSys Agent AutoSys Connect

AS/400 Job AS/390 Job

Introduction 1–15
Contacting Technical Support

Contacting Technical Support

You can contact us with any questions or problems you have. You will be
directed to an experienced software engineer familiar with Unicenter AutoSys
JM. You can contact Computer Associates Technical Support at esupport.ca.com.

1–16 User Guide

 Chapter

Security
2
To set up Unicenter AutoSys JM correctly, you should understand the security
features that control where and by whom certain secured activities can be edited
or executed. If you are installing on both UNIX and Windows, you must
understand how security is implemented on both systems.

For information about security on UNIX, see the chapter “Security” in the
Unicenter AutoSys Job Management for UNIX User Guide.

Overview
Unicenter AutoSys JM is able to run in either eTrust™ secured mode or native
security mode. External security (eTrust) can be enabled during the installation
of the product, or later on by an authorized EXEC superuser. Once external
security is enabled, the eTrust security package will be called to authorize the
user, and to determine if they can turn off security in the product.

Note: While external security is enabled, native security is not enforced.

For more information on enabling eTrust security, see Security Control, in this
chapter.

For more information on controlling the security setting with the Unicenter
AutoSys Secure utility, see autosys_secure in the Unicenter AutoSys Job
Management for UNIX and Windows Reference Guide.

Security 2–1
Native Security

Native Security
Unicenter AutoSys JM native security includes the following:

■ Job-level security

■ Superuser privileges

■ System-level security

■ UNIX and Windows file permissions (See Restricting Access to Jobs in this
chapter.)

Security is initiated when either a user sends events that affect the running of a
job or the event processor sends events that affect a job.

Security On Events Sent By Users

By using the sendevent command or the Send Event dialog, 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:

Security Events
CHANGE_PRIORITY JOB_ON_HOLD

CHANGE_STATUS JOB_ON_ICE

DELETEJOB KILLJOB

FORCE_STARTJOB SEND_SIGNAL

JOB_OFF_HOLD STARTJOB

JOB_OFF_ICE

2–2 User Guide

 Native Security

If you start a job by sending an event, the job permissions are checked as shown
in the following figure.

The previous figure shows how Unicenter AutoSys JM 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?

Security 2–3
Native Security

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 permission as indicated by the job definition?

Security On Events Sent By the Event Processor

In addition to sending execute events on jobs, you can schedule jobs to start at
certain times or under certain conditions. When a job is scheduled to start
automatically, permissions are checked on the remote agent machine on which
the job is to run.

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

2–4 User Guide

 Native Security

The following figure shows the permissions and security checks that occur on a
UNIX machine before a job is allowed to start on the machine.

Note: In the figure, an asterisk indicates checks that are made only if the specific
method of remote authentication is enabled (see Remote Agent Authentication in
this chapter).

Security 2–5
Native Security

The previous figure shows how Unicenter AutoSys JM 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@machine) have a logon
account on the remote agent machine?

4. If user authentication is enabled, is the user a trusted user (as defined in the
/etc/hosts.equiv and $HOME/.rhosts files)?

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.

2–6 User Guide

 System-Level Security

System-Level Security
The security scheme prevents unauthorized access to facilities, which in turn
prevents unauthorized access to jobs. The following features handle system
security:

■ Database field verification

■ Job definition encryption

■ Remote agent authentication

■ User and database administrator passwords

Note: On UNIX, the database field and control string encryption features
provide a level of security comparable to the security provided in the native
UNIX environment.

Database Field Verification

To secure the database, Unicenter AutoSys JM 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 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 Definition dialog.

Job Definition Encryption

To secure the remote agent from unauthorized access, the event processor
encrypts the information in a job definition sent over the socket to the remote
agent. The remote agent then decrypts the job information and continues to
process the job. If the remote agent receives any job information from the event
processor that it does not recognize, it issues an error message and will not
process the job.

Security 2–7
System-Level Security

Remote Agent Authentication

Unicenter AutoSys JM 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

This remote authentication method uses UNIX ruserok() authentication to verify

that a user has permission to start a job on an client machine. It accomplishes this
by telling the client’s remote agent to make the ruserok() UNIX system call to
check the client machine’s /etc/hosts.equiv and the user’s .rhosts file to validate
that the requesting user is registered in that environment. This function call
performs a “local” verification, and it is not related in any way to rshd or
rlogind. To activate this type of remote authentication, use the autosys_secure
command.

The hosts.equiv or .rhosts file entries must match the job owner and machine
name field exactly. For example, if the owner is tarzan@jungle, the hosts.equiv or
.rhosts file must contain “jungle.” Similarly, if the owner is
[email protected], the hosts.equiv or .rhosts file must contain
“jungle.vine.com.” If they do not match, jobs will fail to run on that machine
when ruserok() remote authentication is in use.

For information on enabling this type of remote authentication, see

autosys_secure in the chapter “Commands” in the Unicenter AutoSys Job
Management for Windows and UNIX Reference Guide.

2–8 User Guide

 System-Level Security

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 reading the /etc/.autostuff file on the machine
on which the remote agent is running. For information on enabling event
processor authentication, see autosys_secure in the chapter “Commands” in the
Unicenter AutoSys Job Management for Windows and UNIX Reference Guide.

Note: Before enabling event processor authentication, you must set up and
properly configure the /etc/.autostuff file on every client machine that will
participate in this authentication method, as described in Configuring Remote
Authentication in the chapter “Configuring,” in this guide.

User and Database Administrator Passwords

When you install Unicenter AutoSys JM 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 database and can make changes to 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 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 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 the chapter “Commands” in the Unicenter AutoSys Job Management
for Windows and UNIX Reference Guide.

Security 2–9
Job-Level Security

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

Job Ownership

By default, the owner of an job is the user who defines that job on a particular
machine. When a user defines a job on UNIX, the user ID is retrieved from the
UNIX environment and attached to the job in the form of user@machine. The
owner is defined by the owner job attribute. By default, only the owner can edit
and execute the job.

The user@machine 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, and so forth
that the command needs to access. For this process to work, the job owner must
have the appropriate system permissions.

The owner’s umask “write” permission is used as the default “edit” permission
of the job, and the umask “execute” permission is used as the default “execute”
permission of the job.

If a job is run on a Windows client machine, the edit superuser must have
entered the valid Windows user ID and password for the owner into the
database. For more information about the edit superuser, see Edit Superuser in
this chapter.

2–10 User Guide

 Job-Level Security

User Types

Like UNIX, Unicenter AutoSys JM uses the notion of these three types of users
for any job:

Owner
The user who created the job.

Group
Any user who is in the same primary group as the owner.

World
Every user.

Unicenter AutoSys JM uses the UNIX user ID (uid) and group ID (gid) of a job’s
owner to control the following:

■ Who can edit, override, or delete a job definition.

■ Who can execute the UNIX command specified in a job.

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

Permission Types

By default, only the owner has edit and execute permissions on a job, and all edit
and execute permissions are valid only on the machine on which the job was
defined. However, the owner can grant different types of permissions when
defining a job.

Similar to UNIX, Unicenter AutoSys JM associates different types of permissions

with each job. Every job has the following permission types:

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 dialog. For a list of the execute
events that users can send, see Security On Events Sent By Users in this
chapter.

Security 2–11
Job-Level Security

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

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

Granting Permissions

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

The following table shows the permissions that you can set by using JIL or the
Permission toggle buttons on the Job Definitions Advanced Features dialog.

GUI JIL Meaning

Group Execute gx Users assigned to the job owner’s primary group
can execute the job if logged onto the machine
where the job was created (the machine specified in
the owner attribute, that is, user@machine).

Group Edit ge Users assigned to the job owner’s primary group

can edit the job if logged onto the machine where
the job was created (the machine specified in the
owner attribute, that is, user@machine).

All Hosts m Users, regardless of the machine logged onto, can

Execute x execute the job (otherwise, the user must be logged
onto the machine specified in the owner attribute,
that is, user@machine).

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

World Execute w Users can execute the job if logged onto the machine
x where the job was created (the machine specified in
the owner attribute, that is, user@machine).

2–12 User Guide

 Job-Level Security

GUI JIL Meaning

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, that is, user@machine).

Note: A job and the command it executes will always run as the user specified in
the owner attribute of the job definition. Execute permissions determine who can
execute events against the job, but not who the job runs as. Even if World
Execute permissions are granted, the job will still run as the user.

Job Permissions and Windows

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

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

■ When editing a job from a Windows 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 a Windows 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.

Security Control

External security is controlled by a setting in the Unicenter AutoSys JM database.

You can turn external security on or off by using the autosys_secure binary.

Security 2–13
Superuser Privileges

Superuser Privileges
Unicenter AutoSys JM provides you the ability to create more than one EDIT or
EXEC Super User. You can define these superusers by using the autosys_secure
command. For information about defining the edit and exec superusers, see the
chapters “Server Installation for Sybase” or “Server Installation for Oracle” in the
Unicenter AutoSys Job Management for UNIX Installation Guide.

Edit Superuser

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 database password, change the remote authentication method,

and add and change Windows user IDs and passwords by using the
autosys_secure command.

The edit superuser can override user authentication (if enabled) on a job-by-job
basis by changing the owner of the job from the form user@machine to the form
user. User authentication of the job at execution time is not performed on the
client machine. For more information about changing the job owner, see owner
attribute in the chapter “JIL/GUI Job Definitions” in the Unicenter AutoSys Job
Management Reference Guide.

Note: The purpose of the user@machine form is to prevent users from running
jobs on machines where they do not have the appropriate permission. For
example, root@machine prevents root on any machine from running root jobs on
all machines.

2–14 User Guide

 Superuser Privileges

The edit superuser must enter valid Windows user IDs and passwords into the
database. These user IDs and passwords are required to log onto and run jobs on
Windows client machines. When a remote agent runs a job on a machine, it logs
on as the user defined in the owner attribute for the job. To do this, the event
processor retrieves encrypted versions of the IDs and passwords for the
user@host_or_domain and the user@machine from the event server and passes
them to the remote agent. For information about entering and changing
Windows user IDs and passwords, see autosys_secure in the chapter
“Commands” in the Unicenter AutoSys Job Management for Windows and
UNIX Reference Guide.

Note: Any user who knows an existing user ID and password can change that
password or delete that user and password.

Exec Superuser

Only the exec superuser has permission to:

■ Issue commands that affect the running or the state of any job, either using
the sendevent command or the Send Event dialog.

■ Enable eTrust Access Control

■ Set the Subscriber Authentication Security Word

■ Stop the event processor by issuing the following command:

sendevent -E STOP_DEMON

Note: Exec superuser privileges are usually granted to the night operator.

Security 2–15
Restricting Access to Jobs

Restricting Access to Jobs

Using the UNIX chmod command, you can change permissions on many 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 directory structure.

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

■ Only authorized users can use Unicenter AutoSys JM.

■ 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 Unicenter AutoSys JM, ensure that
only those users have execute permissions on the files in the 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 files in the
%AUTOSYS%/bin directory are executable only by the authorized users. This
will also prevent unauthorized users from making changes to the configuration.

Secure the following files:

File Names
archive_events DBMaint sendevent

autocal dbspace timescape*

autocal_asc dbstatistics xql

autocons* Hostscape* zappls

autotimezone jil zql

clean_files jobscape*

Note: An asterisk (*) indicates files that can be executable by all users as long as
sendevent and jil are not executable. This allows users to use the GUI to view job
states, but does not allow them to add new jobs or calendars or start jobs (even if
the job has world execute permissions).

2–16 User Guide

 eTrust Access Control

You should also protect the files in the %AUTOUSER% directory from
modification by ensuring that only users authorized to change the configuration
have write permission on the files. Read permission is necessary to source the
environment files.

Remote Agent Security

In the auto.profile file for the remote agent machine, you can specify a list of
users whose jobs are prohibited from running on that machine. For information
on this, see Client-Side Security in the chapter “Configuring,” in this guide.

eTrust Access Control

Unicenter AutoSys JM provides you with Asset Level Security, if selected during
installation. This is accomplished through integration with eTrust Access Control
(eTrust AC). All GUI applications and all Command Line Interfaces will have
call outs to security. User defined classes within eTrust AC will be used to
govern what types of resources can be controlled by which users.

Since the event processor and remote agent will not enforce security, policy
changes will not affect resources which were entered into the database. For
example; if the security administrator withdraws a users permission to create
jobs, Unicenter AutoSys JM will continue to run jobs created by the user before
the change.

If you turn on eTrust AC security, the job-level security and superuser security
supported in native mode will no longer be adhered to.

Note: Wherever Unicenter AutoSys JM binaries are installed, a local eTrust

database will be created called seosdb. This database will subscribe to the
machine where the eTrust PMDB was created to ensure that security policies are
pushed out to each machine. Any security calls made by these binaries will go
against the local seosdb, rather than a remote security database, to avoid
unnecessary network traffic.

Security 2–17
eTrust Access Control

If eTrust security is enabled, you must establish a subscriber authentication

security word before any secured executables will work properly. Before
establishing your security word is a good opportunity to define your enterprise
security policy since Unicenter AutoSys JM is effectively locked down until you
establish the security word.

When you are ready to establish your security word, run autosys_secure as a
user and from a host that are authorized to administer the eTrust pmdb. Choose
menu item 7 followed by item 2. You will be prompted for your security word.
The only time you will ever be prompted for this word again is if you decide to
change your security word.

Note: To provide cross-platform compatibility, the security word is stored in the

eTrust database and the Unicenter AutoSys JM database in upper case. This
renders the security word case-insensitive. For example, if you create the
security word 'my_word' and then decide to change it, when you are prompted
for the existing security word, you could successfully enter 'My_Word' or
'my_WORD'; and Unicenter AutoSys JM will see them as the same.

If you have reason to believe that your security word has been compromised,
you should change it using autosys_secure. With that information it would be
possible for a malicious user to setup a local eTrust policy and circumvent
Unicenter AutoSys JM security.

The security word you provide is stored in the Unicenter AutoSys JM database
and the eTrust database. Before checking security, all secured Unicenter AutoSys
JM executables will read the security word from the Unicenter AutoSys JM
database and compare it to the security word in the eTrust database. It will only
be present in eTrust if the local installation is a valid subscriber to the enterprise
security policy. If there are problems verifying the security word, access to
secured assets will be denied.

Note: The eTrust AC audit log may have failed to check the security word
resource each time you run a secured binary. This is expected behavior. If you
would rather not see these failures, you can do one of two things.

■ You can create a filter that will not include these entries. For more
information see the section Audit Filters in the eTrust Access Control
Administrator Guide.

2–18 User Guide

 eTrust Access Control

■ You can change your user resources so that these failures will not be logged.
By default, all users are configured to cause log entries to be generated on
access failures (regardless of which resource the failure occurred with).
However, the security word resource has been created to not cause log
entries to be generated on failure (since that is expected behavior in this
case). You can change (or create) your users to not create an audit log entry
when a failure occurs. This leaves it up to the individual resources to create
failure entries in the audit log (the default behavior for resources). You can
change the audit rules using either selang or the Policy Manager GUI. For
more information on configuring audit rules see the eTrust Access Control
Administrator Guide.

You can globally enable or disable eTrust using autosys_secure. In order to

disable eTrust, you must be granted execute access to the SECADM resource.

Policy Manager

All modifications to security access of any Unicenter AutoSys resource can easily
be done through the eTrust Policy Manager on Windows. You can also modify
security access using the selang command line utility. For more information on
selang, see the eTrust Access Control for UNIX Reference Guide. The eTrust
Policy Manager allows you to modify and set security levels for all user-defined
classes provided by Unicenter AutoSys JM.

Security Access

The Policy Manager is used to modify security.

To modify security do the following:

1. Click, Start, Programs, Computer Associates, eTrust, Access Control, Policy

Manager.

The eTrust Policy Manager opens

2. Select File, Connect

3. Click Add (Insert) in the Host Selection dialog.

4. Enter the hostname where the autosys PMDB was installed.

5. Check the Connect to PMDB check-box and enter autosys as the PMDB
name.

Security 2–19
eTrust Access Control

A new entry appears in the Host Selection dialog

6. Select the new entry, and click OK.

7. Once connected, click Resources in the left program bar Access Control.

8. To view Unicenter AutoSys JM security classes, expand the User-Defined

classes folder.

Selecting a class will list the available policies governing access to a specific
resource.

Disable Security
To access Disable Security use the autosys_secure command.

For more information about autosys_secure, see the Unicenter AutoSys Job
Management for Windows and UNIX Reference Guide.

Controlling the Event Processor

If eTrust security has been enabled through autosys_secure, the user will be
prevented from using the Windows Service Control Manager to stop the Event
Processor Service by default. The user must use the AutoSys Administrator tool
or the “sendevent –e STOP_DEMON” command to stop the Event Processor
Service. Alternatively, if control of the Event Processor Service through the
Service Control Manager is desired, then the service must be configured to log
on as a certain user. In all cases, an eTrust security call will be issued to see if the
user in question has been given as-control/STOP_DEMON execute rights to shut
down the Event Processor Service.

The sendevent command or the Administrator Tool should be used to shutdown

the event demon.

Access to shutting down the event demon can be restricted through the eTrust
Policy Manager by setting access to the STOP_DEMON resource in the as-control
class. Doing this will prevent users from using the sendevent command, or the
Administrator tool to stop the event demon.

2–20 User Guide

 eTrust Access Control

Asset-Level Security

If selected during installation, Unicenter AutoSys JM provides you asset-level

security through integration with eTrust AC release 5.2. All Unicenter AutoSys
JM GUI applications and Command Line Interfaces will call out to the security
engine bundled with the installation program if eTrust AC is currently enabled.
User defined classes within eTrust will be used to govern what types of
resources can be controlled by which users.

For more information on eTrust Access Control see the eTrust Access Control for
UNIX User guide.

Since the event processor and remote agent will not enforce security, policy
changes will not affect resources which were entered into the database under the
previous policy. For example, if the security administrator withdraws a user’s
permission to create jobs, Unicenter AutoSys JM will continue to run jobs the
user created before the change.

During the installation of eTrust AC, a Local Policy Model Database (PMDB)
was created called autosys, on what will be considered the master security
server. On the master security server, eTrust AC will subscribe a client
subscriber to the autosys PMDB. The install will ask for the users that will be
defined as administrators to the eTrust database, but will not import existing OS
users into the eTrust AC database.

Unicenter AutoSys JM will be able to run in either eTrust secured mode or

regular mode. External security can be enabled during the installation of the
product, or later on by an authorized EXEC super user. Once security is enabled,
the external security package will be called to authorize the user to determine if
they can turn off security in the product.

Important! When working in a mixed environment (UNIX, Windows) and using

eTrust AC security only, you must be vigilant as to how resources are added to
an eTrust Access Control database. Since UNIX is case-sensitive and Windows is
case-preserving, it is easy to enter a name with the wrong case which will then
not be correctly recognized.

Security 2–21
eTrust Access Control

For example, you might want to create a user 'Administrator' that you will allow
to administer the 'autosys' PMDB from a Windows machine. If you create the
user as 'administrator' (lowercase 'a') and then try to run the policy manager
from a Windows box where you are logged in as 'Administrator' you will be
denied access. This can be confusing because Windows will let you login to the
'Administrator' account as 'administrator'. The key is that the user in the PMDB
must follow the case as it is preserved on the Windows machine.

For more information on enabling security see Security control, in this chapter.

eTrust Resource Classes

To secure the product, a set of classes will be defined that pertain to Unicenter
AutoSys JM. These classes are used to control access to jobs, calendars, cycles,
machines, global variables, and the owner field of a job. There are also classes to
prevent unauthorized users from starting or shutting down Unicenter AutoSys
JM, disabling security, and to prevent unauthorized users from accessing
Unicenter AutoSys JM Web Interface.

Unicenter AutoSys JM will use the following eTrust User Defined Classes. These
classes will be created in the eTrust database and the PMDB autosys. The classes
are eTrust enabled and will make security call outs prior to performing an action
on a specified object.
as-job as-calendar as-machine

as-gvar as-owner as-control

as-view as-list

The name of each eTrust resource will be the name of the corresponding AutoSys
object, a period, and the name of the instance.

For example, Unicenter AutoSys JM will query eTrust about

as-job payroll.ACE

when a user tries to update job payroll in instance ACE.

Note: The security administrator must use the object. instance convention when
creating policies. You may use wild cards to create policies which apply to
multiple objects among different instances.

2–22 User Guide

 eTrust Access Control

For more information on Resource Classes, see the eTrust Access Control for
UNIX Reference Guide.

eTrust Access Modes

Unicenter AutoSys JM will utilize the following access modes on each of the
various resource classes. The use of these access modes is explained in more
detail with the description of each class.

■ READ

■ CREATE

■ DELETE

■ EXECUTE

■ WRITE

as-job Class

The as-job class will control access to job objects. All of the eTrust access modes
will be applied to this object.

READ
Prevents users from being able to view jobs or their contents.
Binary Security Checkpoints
autocons.exe If as-list\AUTOCONS denied

autorep.exe If as-list\AUTOREP denied,

otherwise -J job, -q

autostatad.exe If as-list\AUTOSTAT denied,

otherwise –J job

autostatus.exe -J job

eventreport.exe Launch from autocons

jobdetails.exe Launch form autocons

jobdef.exe If as-list\JOBDEF denied,

otherwise file-open, change tabs

job_depends If as-list\JOBDEP denied,

otherwise –J job

Security 2–23
eTrust Access Control

Binary Security Checkpoints

monbro.exe If as-list\MONBRO denied

CREATE
Prevents users from creating a job object.
Binary Security Checkpoints
jil.exe update_job

jobdef.exe File - save

DELETE
Prevents users from deleting jobs, including deleting the job using the
sendevent command.
Binary Security Checkpoints
jil.exe delete_job

jobdef.exe File - delete

sendevent.exe -e DELETEJOB

EXECUTE
Controls whether a user is allowed to issue a sendevent against the job
object.
Binary Security Checkpoints
sendevent -e STARTJOB
-e KILLJOB
-e FORCE_STARTJOB
-e JOB_ON_ICE
-e JOB_OFF_ICE
-e JOB_ON_HOLD
-e JOB_OFF_HOLD
-e COMMENT (not global)

WRITE
Prevents unauthorized users from updating an existing job object.
Binary Security Checkpoints
jil.exe insert_job

jobdef.exe File - save as

sendevent -e CHANGE_PRIORITY

2–24 User Guide

 eTrust Access Control

as-calendar Class

The as-calendar class will control access to calendar objects.

READ
Prevents users from being able to view calendars or their contents.
Binary Security Checkpoints
autocal.exe If as-list\AUTOCAL denied,
otherwise File- open

autocal_asc.exe PRINT

CREATE
Prevents users from creating a calendar object.
Binary Security Checkpoints
autocal.exe File - save

autocal_asc.exe ADD (new)

DELETE
Prevents users from deleting a calendar.
Binary Security Checkpoints
autocal.exe File – delete

autocal_asc.exe DELETE

EXECUTE
Controls whether a user is allowed to specify the given calendar to run or to
exclude within a job object.
Binary Security Checkpoints
jil.exe run_calendar, exclude_calendar

WRITE
Prevents unauthorized users from updating existing calendar objects.
Binary Security Checkpoints
autocal.exe File – save as

autocal_asc.exe ADD (existing)

Security 2–25
eTrust Access Control

as-machine Class

The as-machine class will control access to machine objects. This will control
who can do what to the machine object including whether or not it can be used
by a user in a job definition. All of the eTrust access modes will be applied to this
object.

READ
Prevents users from being able to view machines or their contents.
Binary Security Checkpoints
autorep.exe If as-list\AUTOREP denied,
otherwise –m machine

jobdef.exe File – open, change tabs

CREATE
Prevents users from creating machine objects.
Binary Security Checkpoints
jil.exe insert_machine

DELETE
Prevents users from deleting machine objects.
Binary Security Checkpoints
jil.exe delete_machine

2–26 User Guide

 eTrust Access Control

EXECUTE
Unless authorized, EXEC controls whether a user is allowed to specify that
machine inside a job object.
Binary Security Checkpoints
jil.exe machine

jobdef.exe File – save as

sendevent -e STARTJOB
-e KILLJOB
-e FORCE_STARTJOB
-e JOB_ON_ICE
-e JOB_OFF_ICE
-e JOB_ON_HOLD
-e JOB_OFF_HOLD
-e COMMENT (not global)

WRITE
Prevents unauthorized users from updating existing machine objects.

Security 2–27
eTrust Access Control

as-gvar Class

The as-gvar class will control access to global variable objects. Since this object is
only controlled through the sendevent binary, the access modes will be checked
during sendevent execution. All of the eTrust access modes will be applied to
this object.

READ
Prevents users from being able to view specific global variable objects.
Binary Security Checkpoints
autorep.exe -g variable

autostatus.exe -g variable

CREATE
Prevents users from creating specific global variable objects.
Binary Security Checkpoints
sendevent.exe -g (new variable)

DELETE
Prevents users from deleting specific global variable objects.
Binary Security Checkpoints
sendevent -g variable=DELETE

EXECUTE
Prevents users from using sendevent all together against global variables.
Binary Security Checkpoints
sendevent -e SET_GLOBAL, all-g options

WRITE
Prevents unauthorized users from updating an existing specific global
variable objects.
Binary Security Checkpoints
sendevent -g (existing variable)

2–28 User Guide

 eTrust Access Control

as-owner Class

The as-owner class will control access to the job owner field in the job object.
This will be used to control what owner can be specified in a job definition. For
example, when a new job is created, by default the user-id of the job creator is
automatically used. However, when a different user is to be used, security will
be called to determine if the owner specified is allowed to be used by the current
user.

EXECUTE
Prevents users from using unauthorized user-id’s.
Binary Security Checkpoints
jil.exe owner

jobdef.exe File – save as

Security 2–29
eTrust Access Control

as-control Class

The as-control class will control access to critical services within Unicenter
AutoSys JM.

EXECUTE
Control critical resources through the following:
Binary Security Checkpoints
sendevent.exe -e STOP_DEMON

STOP_DEMON
Controls who can stop the event processor. Applies to both the
sendevent command, and the service control manager on Windows.

Note: If eTrust security has been enabled then by default, the user
will be prevented from stopping the event processor from the Service
Control Manager and can only use sendevent.
Binary Security Checkpoints
autosysadmin.exe Services screen, Event Processor, Stop Button

eventsysd.exe Service Control Manager Stop

SECADM
For Internal Use only.

WEBLOG
For Internal Use only.

WEBADM
For Internal Use only.

2–30 User Guide

 eTrust Access Control

as-view Class

The as-view class will control access to the various views defined in the
Unicenter AutoSys JM Web Interface GUIs, including preventing graphical
representations of certain jobs.

Note: For performance reasons, it is not feasible to call security for each
individual object that is to be displayed on the web browser.

READ
Prevents users from being able to bring up a particular view, preventing
access to jobs they are not authorized to see.

CREATE
Prevents users from creating views defined and maintained by Unicenter
AutoSys JM Web Interface.

DELETE
Prevents users from deleting views defined and maintained by Unicenter
AutoSys JM Web Interface.

WRITE
Prevents unauthorized users from updating views defined and maintained
by Unicenter AutoSys JM Web Interface.

as-list Class

The as-list class will control telling programs to bypass security for read only
operation, as in autocons or autorep, where the information displayed does not
constitute a security violation.

Notes:

By using the default of this class Unicenter AutoSys JM will not incur the
tremendous overhead of issuing a security call for each individual line item
displayed.

This class is provided for those users that do not believe that status or report
type functions that do not display the detail of the asset warrant a security call
on each object.

In an environment where there are thousands of jobs, issuing a security call

against each individual job, just to see status type or summary, may cause
unnecessary security overhead.

Security 2–31
eTrust Access Control

READ
Control security bypass through the following:

AUTOREP
Controls read access for the autorep program. This value will
ignored for any autorep report that specifies the –q option.
Binary Security Checkpoints
autorep.exe -m ALL
-J ALL
-J box
-g ALL

AUTOCONS
Controls read access to the console type programs including the
Unicenter AutoSys JM Web Interface GUI.
Binary Security Checkpoints
autocons.exe on refresh, select filter from dropdown list

AUTOCAL
Controls read access within the Calendar Definition GUI.
Binary Security Checkpoints
autocal.exe File – open search
File – delete search
cal dropdown listbox

AUTOSTAT
Controls read access to ????
Binary Security Checkpoints
autostatad.exe -J %

MONBRO
Controls read access to the monitor/browser GUI.

JOBDEP
Controls read access to the job_depends GUI.
Binary Security Checkpoints

2–32 User Guide

 eTrust Access Control

Binary Security Checkpoints

jobdep.exe -c –J ALL
-c –J %
[-t, -d] %
[-t, -d] ALL
[-t, -d] box

jobdef.exe File – open search

File – delete - search

Security Enabled Applications

Example 1

If read access to the autocons resource belonging to the as-list class has been
granted to the Unicenter AutoSys JM instance, then the individual read access
checks for each job is ignored and the entire list of jobs is displayed.

To disable list access for autocons, open the eTrust Policy Manager to the as-list
class, and select AUTOCONS*.

Note: The owner of the AUTOCONS* resource has been set to nobody. This
is necessary as all security checks will automatically pass if called by the
owner.

Before re-launching autocons, read access to the job ‘goodtest’ will be disabled.
From the Policy Manager a resource has now been created for any job beginning
with good. All access has been disabled for these jobs.

Now when autocons starts up, a warning message will be displayed indicating
that as-list access failed, and a read access check will be performed for each job
before displaying it.

Note: The resource that Unicenter AutoSys JM used to check for read access
is AUTOCONS.INSTANCE.

Since read access was denied for all jobs beginning with good, the job goodtest
no longer appears in the display list.

As eTrust access rights are changed, autocons will update the display
accordingly during the refresh cycle.

Security 2–33
eTrust Access Control

Example 2

A similar behavior is exhibited when running autorep from the command

prompt.

First list access will be checked for the AUTOREP resource in the as-list class. If
access is granted the requested jobs will be reported without performing read
access checks.

However, if list access has been denied, then read access checks will be
performed for each job before displaying job information.

Notes:

If a job in a box fails read access, but the box passes read access, the failed job
will not be displayed.

If a box job fails read access none of the jobs within the box, and the box will not
be displayed.

Security Call Logic

This section walks through the logical flow of creating, updating, and deleting
an object.

Creating an Object

The following represents a logical flow for the creation of any object:

1. Call security to validate user has authority to assign the object in the
specified security group by calling security with execute permission on the
security group.

2. Call security to validate user can create the object by passing in the security
group name and specifying create authority.

3. For Job objects only — call security again and validate the owner field using
an asset of as-owner and a permission of execute.

4. For Job only — call security passing in the security group of the machine
with an execute permission if that machine can be used.

2–34 User Guide

 eTrust Access Control

Updating an Object

The following represents a logical flow for updating any object:

1. Call security to validate user has authority to update objects in the security
group using the original security group of the object.

2. If the security group is being modified, call security to ensure that the user
has update authority to objects in the security group.

3. For Jobs only — Call security on the owner field and machine field as if on a
create object.

Deleting an Object

The following represents a logical flow for deleting any object.

Call security to validate user authority to delete objects from the specified
security group.

Security 2–35
Chapter

Jobs
3
All activity controlled by Unicenter AutoSys JM is based on jobs. Other objects,
such as Monitors, Browsers (Reports), and the Operator Console, serve to track
job progress. A job is the basic building block upon which the entire operations
cycle is built.

A job is any single command or executable, UNIX shell script, or Windows batch
file. Each 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 Unicenter AutoSys JM to
address your distributed computing needs will evolve over time. As you become
more familiar with both the features of and the characteristics of your own jobs,
you will also refine your use of Unicenter AutoSys JM.

Note: Before continuing with this chapter, read the chapter “Maintaining ,” for
details on starting the event processor, which must be running before you start
any processes.

Jobs 3–1
Job Types and Structure

Job Types and Structure

The following illistration shows 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 Unicenter AutoSys JM treats them all similarly. The
primary differences between them are the actions that are taken when the job is
run.

Job
Name
Starting Conditions
Depends On
Definition
Alarm
Basic Job Restart Conditions

Information
Current Status
Start time
Current State End Time
Exit code

File Watcher
Job
Types Command File Name Box Container
Minimum File size
Command to execute Watch Interval
File to source
Machine to run on
Standard output files
Standard input file

Watch for File

Action Run Command

on Machine

As their names imply, command jobs execute commands, box jobs are
containers, which hold other jobs (including other boxes), and file watcher jobs
watch for the arrival of a specified file.

Basic Job Information

In the previous figure, 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).

3–2 User Guide

 Job Types and Structure

Notice that a job’s starting conditions can be contingent on the date, time, and
the status of any other job.

Command Jobs

The command job is commonly thought of (and referred to) as “a job.” The
command can be a shell script, an executable program, a file transfer, and so
forth. When this type of job is run, the result is the execution of a specified
command on a client machine. When all the starting conditions are met,
Unicenter AutoSys JM 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 previously, a command job

has the following supporting features:

■ Resource Criteria

Unicenter AutoSys JM will check that a certain amount of free file space is
available before starting a process. If it is not available, an alarm is sent and
the job is rescheduled to start after a suitable delay.

■ Profile Script

For each job, you can specify a script to be sourced before the execution of
the command that defines the environment in which the command is to be
run. All commands are run under the Bourne shell (/bin/sh). Therefore, all
statements in the profile must use /bin/sh syntax.

■ 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
Definition Advanced Features dialog.

Box Jobs

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

Jobs 3–3
Job Types and Structure

Note: Box jobs are very powerful tools for organizing, managing, and
administering large numbers of jobs that have similar starting conditions or have
complex logic flows. Knowing how and when to use boxes is often the result of
some experimentation.

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.

Unicenter AutoSys JM 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.

3–4 User Guide

 Job Types and Structure

File Watcher Jobs

A file watcher job is similar to a command job. However, instead of starting a

user-specified command on a client machine, it starts a process that monitors for
the existence and size of a specific operating system file. When that file reaches a
certain minimum size, and is no longer growing in size, the file watcher job
completes successfully, indicating that the file has arrived.

Using file watcher jobs provides a means of integrating events that are external
to Unicenter AutoSys JM into the processing conditions of 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, and then exit. You could also set up the batch job so that the
completion of the file watcher job is its only starting condition.

Jobs 3–5
Job Profiles

Job Profiles
Before running a command job, the 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 Job Profiles Manager 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 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 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 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 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.

3–6 User Guide

 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, Unicenter AutoSys JM will expand any environment variables specified
as the value of Path, 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 path name, in which case, variables set from the job profile can be used
in the path name 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 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 Windows is initially empty) or in a user-defined job
profile.

For more information about the profile attribute, see profile in the chapter
“JIL/GUI Job Definitions,” in the Unicenter AutoSys Job Management for
Windows and UNIX Reference Guide.

Jobs 3–7
Job Profiles

Using the Job Profiles Manager

The Job Profiles manager allows you to create, delete, and edit job profiles.

To display the Job Profiles manager, do the following:

Open the AutoSys Instance Job Profile Management icon from the program
group. The Profiles Manager appears.

Note: Profiles are instance-specific. Therefore, if you have installed multiple

instances, make sure that you launch the Job Profiles Manager for the
appropriate instance.

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 on to 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 the down arrow to the right of this field. To define a new
profile, type in a new name into this field.

3–8 User Guide

 Job Profiles

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 the following changes to the settings in these fields.

Note: The capitalization of the variable definitions does not matter on Windows.
However, the Job Profiles Manager does replicate, in the Job Profile itself, the
capitalization that you enter in the Variable and Value fields.

Edit or create a variable definition, by the following:

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 Set 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 OK in the upper-right corner

of the Job Profiles 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 Cancel in the upper-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 use one of
these approaches, you will get a “Profile not found” error when starting the
job.

For more information about specifying the profile attribute, see profile in the
chapter “JIL/GUI Job Definitions,” in the Unicenter AutoSys Job
Management for Windows and UNIX Reference Guide.

Jobs 3–9
Job Profiles

Delete a variable definition:

1. Double-click on a variable from the Environment Variables display area.

2. Click Delete. This action immediately deletes the variable from the profile,
and no confirmation is required.

Delete a Profile:

1. Select the profile in the Profile Name field.

2. Click Delete Profile. 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.

3–10 User Guide

 Basic Job Attributes

Basic Job Attributes

For each of the three 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.

Command Job Attributes

The basic command job definition has the following required attributes:

Job Name
The unique job identifier by which a job is referenced.

Command
The UNIX shell script, 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 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

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.

Starting Conditions
The date/time 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.)

Jobs 3–11
Basic Job Attributes

Box Job Attributes

The basic box job definition has the following required attributes:

Box Name
The unique job identifier by which the box is referenced. This name is used
by other jobs as the name of their parent box.

Starting Conditions
The date/time 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.)

3–12 User Guide

 Job States and Status

Job States and Status

Unicenter AutoSys JM 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 Job Activity
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.

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

Jobs 3–13
Job States and Status

■ FAILURE

The job exited with an exit code greater than the “maximum exit code for
success.” By default, any number greater than zero is interpreted as
“failure.” If the job is a box job, a FAILURE status means either that at least
one job within the box exited with the status FAILURE (the default), or that
the “Exit Condition for Box Failure” evaluated to true. AutoSys issues an
alarm if a job fails.

■ TERMINATED

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 through a UNIX kill command. Unicenter
AutoSys JM issues an alarm if a job is terminated.

■ 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 (that is, 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.

3–14 User Guide

 Job States and Status

■ ON_ICE

This job is removed from all conditions and logic, but is still defined.
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 the chapter “Box Job Logic,” in this
guide.

Example State Diagram: Simple Jobs

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

Note: In the following diagrams, a status is depicted using the following box
drawing:

Jobs 3–15
Job States and Status

The following illistration depicts the simplest state transition for a job, in which
an event satisfies the starting conditions for the job.

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

Event Processor

Event is read by Event Processor EVENT

Finds jobs dependent

on this event.

Check Conditions

Event generated by Event Processor,

STARTING
indicating attempt to start job on
Remote Machine.

Remote Agent
Event generated by Remote Agent
indicating the job has actually been RUNNING
started andis now running.

Inspects Exit Code

of the process

Event generated
by Remote Agent
SUCCESS - OR - FAILURE

3–16 User Guide

 Job States and Status

Example State Diagram: Box Jobs

For a job in a box, the job first goes into the ACTIVATED state when the top-
level box it is in goes into the RUNNING state, as shown in the following
illistration. After the job starts, the remainder of the scenario is the same as for
simple jobs.

Event Procesor

EVENT

Finds jobs dependent

on this event.

Check Conditions

Event sent by Event Processor indicating tht the box

is "Running." Nothing actually RUNS. However, this RUNNING
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.

SUCCESS - OR - FAILURE

In the case of a box, the box always goes into the RUNNING state as soon as all
its starting conditions are met. This RUNNING event usually triggers jobs within
the box to also start.

If the job has a priority associated with it, all its starting conditions have been
met, and there are not enough machine resources available, it goes into the
QUE_WAIT state. Once the resources become available, it goes into the
STARTING state, and then runs.

Jobs 3–17
Job States and Status

The value of status reflects the event processing. Therefore, a job might have
actually completed on a machine and if the event processor has not processed
that event yet, Unicenter AutoSys JM will still show the job’s status as
RUNNING. By displaying the detail of the job (either in the Job Activity Console,
or in the output of the autorep command), you can see all the events for a job,
including those that have not processed yet.

In addition, the status always reflects the most recent event that was processed.
Therefore, after a job has completed, the status will remain as it is on completion.
If it ended successfully, the status will remain as SUCCESS until the job is run
again.

Note: When a box job starts, all jobs within the box change state to ACTIVATED
before they run. Jobs will then run immediately, unless other conditions apply. If
a box completes before a job is run, the job is set to INACTIVE at the time of box
completion. As a result, jobs do not retain their statuses from previous box
processing cycles once a new box cycle has begun.

3–18 User Guide

 Starting Parameters

Starting Parameters
Unicenter AutoSys JM 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.

■ 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, Unicenter AutoSys JM
finds all the jobs that might be affected by this change, and determines whether
or not to start them.

Note: It is very important to keep in mind the above four conditions. In order for
a job to start, all defined starting conditions must be true.

Starting Parameters and Boxes

Be aware that for a job in a box to start, the box job must be running. Placing a
job in a box means that the job inherits all the starting conditions of the box job. It
also means that if there are no additional conditions on the job, it will be started
as soon as the box is started. Also, a job runs only once per box execution.

By default, there is no concept of sequential job processing in a box. For example,

if there are three jobs inside a box, and none of them has any additional
conditions, then when the box is started, all three jobs will be started.

To implement a sequence within a box, you must specify additional starting

conditions for each job. For example, “Job1” may have no starting conditions,
while “Job2” is dependent on the completion of “Job1,” and “Job3” is dependent
on the completion of “Job2.”

Be aware that if this scenario were implemented and “Job2” were placed
ON_ICE, then “Job1” and “Job3” would start simultaneously as soon as the box
they are in started running. (Jobs that are dependent on a job that is ON_ICE run
as if that starting condition has been satisfied.)

Jobs 3–19
Starting Parameters

Date/Time Dependencies

Unicenter AutoSys JM jobs can be automatically scheduled to start at a certain

date and time, based on the information you supply using JIL statements or the
GUI. You define these dependencies by specifying the days or dates and times
for time-based job starts. Unicenter AutoSys JM 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 GUI, but you can only
specify actual dates through the use of custom calendars, which you can define
using the Graphical Calendar Facility.

You can specify times as certain times of the day, or hourly, denoted in minutes
past the hour. Again, the two formats are mutually exclusive. You can specify
either form using JIL or the GUI (you do not have to create custom calendars).

TZ Environment Variable

By default, jobs with time-based starting conditions that do not specify a time
zone are scheduled to start based on the time zone of the TZ environment
variable (the same time zone under which the event processor runs).

Before you start the event processor, ensure that the TZ environment variable is
set. The 3.4.4 event processor must be started once after you upgrade your
database to insert the value of the TZ environment variable into the database. Do
this before executing jil, autosc, autocons, or autorep.

3–20 User Guide

 Starting Parameters

Custom Calendars

Using the Graphical Calendar Facility or the autocal_asc utility, you can define
any number of custom calendars, each with a unique name and containing any
number of dates or date/time combinations. You can use these calendars in one
of two ways: as days on which to run the jobs with which they are associated, or
as days on which to not run the jobs with which they are associated. Calendars
exist independently of any jobs that may be associated with them; they are
referenced by jobs through job definitions.

Job Dependencies Related to Job Status

You can start jobs based on the current status of one or more jobs. These jobs
must exist in the 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.

You can configure more complex conditions by combining a series of conditions

with the AND or the OR logical operators. You may use the pipe symbol (|)
instead of the word “OR,” and the ampersand symbol (&) instead of the word
AND. Spaces between conditions and delimiters are optional. You can specify
even more complex conditions by grouping the expressions in parentheses. The
parentheses force precedence, and the equation is evaluated from left to right.

Given the sample script of:

(success(JobA) and success(JobB)) or (done(JobD) AND done(Job E))

would be evaluated, and the results would be A and B or D and E, reading from
left to right.

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 chk_cond, the
stored procedure.

Jobs 3–21
Starting Parameters

The syntax for defining job dependencies is the same whether the job is being
defined using JIL or the GUI. The only difference is the JIL statement will begin
with the JIL condition keyword, while the GUI field will only contain the
language for the dependency itself. The dependency specification can take one of
the following three forms:

■ Based on the current status of other jobs

■ Based on the UNIX exit codes of other jobs

■ Based on global variables

This is the syntax for conditions based on job status:

status(job_name)

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 exit code with
the letter e and VALUE (of a global variable) with the letter v. These
abbreviations can be upper- or lowercase.

3–22 User Guide

 Starting Parameters

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

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.

An instance is one licensed version of Unicenter AutoSys JM software running as

an server, and as an server/client, on a single machine or on multiple machines.
It uses its own event server and event processor and operates independently of
other instances.

Multiple instances 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 can send events to each other by way of a
sendevent command line like:
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.

Jobs 3–23
Starting Parameters

In addition, jobs can be associated with more than one instance. For example, a
job defined to run on one instance could have as a starting condition the
successful completion of a job running on a different instance.

The specification for such a job dependency might look like:

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

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.

The following illistration shows two instances, each with a single event server,
exchanging cross-instance job dependencies.

One Instance of AutoSys One Instance of AutoSys

ACE PRD

Event Event
Server Server

config.ACE config.PRD File

config.EXTERNAL config.EXTERNAL

Event Event
Processor Processor

condition: success (jobB^PRD) jobB

jobE condition: success (jobE^ACE)

Different instances 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%.

For information on configuring for cross-instance job dependencies, see Running

Cross-Instance Job Dependencies in the chapter “Introduction,” in the Unicenter
AutoSys Job Management for UNIX Installation Guide.

3–24 User Guide

 Starting Parameters

Event processors

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 five minutes until the other instance’s event
server can be reached.

Event Servers

Event servers keep track of the cross-instance job dependencies. Each time a job
definition with a cross-instance job dependency is submitted to the 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 instance.

In both tables above, jobs are entered using the job name, a caret symbol (^), and
the instance name, as shown following:
jobB^PRD

The use of multiple databases is completely independent of instances using

cross-instance dependencies. You can have multiple instances, 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 data servers can only connect with other instances having Sybase data
servers. The same holds true for instances with Oracle databases.

Jobs 3–25
Starting Parameters

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 or the OR logical operators. You can enter these operators in
uppercase 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))

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)

3–26 User Guide

 Starting Parameters

You use the notrunning operator to keep multiple jobs from running
simultaneously (that is, 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 queuing feature described in the chapter “Load Balancing and Queuing
Jobs,” in this guide.

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.

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.

Jobs 3–27
Starting Parameters

When a job is first entered into the database, and prior to its being run for the
first time, its status is set to INACTIVE. By changing to INACTIVE the status of
jobs that have completed, but whose completion status should no longer be used
in dependent job conditions, the completion status from the last run will no
longer be the current status, and it will not be used.

To change a job status to INACTIVE, use the GUI (Send Event dialog), or use the
sendevent command. Of course, you can create an AutoSys job to accomplish
this as well. If you change the status of a top-level box to INACTIVE, all the jobs
in the box are recursively set to INACTIVE.

Deleting and reinserting the job using JIL will accomplish the same thing.
However, the past reporting history on the job will no longer be available.
(Updating a job using JIL does not change the status of the job.)

Job Dependencies Based on Exit Codes

In addition to job status, you can base job dependencies on exit codes that
indicate completed tasks. In this way, you can implement even more specific
branching logic for recovering from job failures. For example, if a broken
communication line results in “JobA” failing with an exit code of “4”, when this
code is encountered, you want the system to execute a shell script (“JobB”)
which redials the line. This is the syntax you would use to specify this type of job
dependency:
exitcode (job_name) operator value

where:

job_name Is the name of the job upon which the “new” job is dependent.

operator Is one of the following exitcode comparison operators:

=, != (not equal), <, >, <=, or >=

value Is any numeric value.

3–28 User Guide

 Starting Parameters

You can abbreviate the dependency specification exit code with the letter e
(uppercase or lowercase).

For the previous 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 Windows

When you are defining jobs that will run batch files on Windows, you should be
aware of, and account for, the Windows-specific behavior.

Windows programs return any exit values that are programmed within the
executable code. This exit value is the last thing returned to Windows 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.

Jobs are created using standard Windows process creation techniques. After the
job has been created, the remote agent waits for the job to complete. When the
job completes, Unicenter AutoSys JM gets the program exit code from Windows
and stores it in the database for later use.

Jobs 3–29
Starting Parameters

When launching programs directly, 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 to start *.BAT batch files.

The exit code returned from a batch file is the return code from the last operation
executed from within that particular batch file. Consider the following example:
REM test batch file
test
if errorlevel 1 goto bad
goto good
:bad
del test.tmp
:good
exit

This example batch file will return a 0 exit code as long as test.tmp exists. If
test.tmp does not exist, the return code is from the del line and not from the line
that executes test. Therefore, this batch file will return a 0 (successful) exit code,
even if test failed to execute as intended.

To help handle situations like this, Unicenter AutoSys JM supplies a program

called FALSE.EXE. This program is located in the Windows %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:
REM test batch file
test
if errorlevel 1 goto bad
exit
:bad
del test.tmp
false 1

When test fails with errorlevel 1, this batch file will return an exit code of 1 from
false, whether the test.tmp file exists or not.

Job Dependencies Based on Global Variables

Job dependencies can also be based on global variables you set using the Send
Event dialog 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:

3–30 User Guide

 Job Run Numbers and Names

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.

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 Definition dialog to define a job, enter the above expression
in the Starting Condition field. When using JIL, enter the above expression in the
appropriate JIL script using the condition attribute.

You can abbreviate the dependency specification VALUE with the letter v
(uppercase 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

Unicenter AutoSys JM 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.

Jobs 3–31
Defining Jobs

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 the chapter
“Commands,” in the Unicenter AutoSys Job Management for Windows and
UNIX Reference Guide), 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 shell scripts or executables executed as the job’s
command. This value is contained in the variable $AUTORUN.

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

Defining Jobs
You can define jobs using one of two methods: JIL statements or the GUI (in the
Job Definition dialog). 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 by using the autosc command, and you can
enter the job definition by filling in the appropriate fields of the Job Definition
dialog and its associated dialogs.

You should back up your job definitions periodically, so you can have a file to
restore from in case of system failure. This process is explained in Backing up
Definitions in the chapter “Maintaining,” in this guide.

Graphical User Interface Components

You can use the GUI to interactively define, run, manage, monitor, and report on
jobs. Unicenter AutoSys JM provides the following top-level Windows and
dialogs, which you can launch from the GUI Control Panel:

3–32 User Guide

 Defining Jobs

■ Job Definition dialog

Used to define jobs. The Job Definition dialog and its related dialogs allow
you to create, view, edit, and delete job definitions for command jobs, box
jobs, and file watcher jobs.

■ Graphical Calendar Facility

Used to define calendar definitions. The Graphical Calendar Facility 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 a certain job, using the Job Definition dialog.

■ Operator Console

Used to monitor and manage jobs. The Operator Console consists of the
following components: Job Activity Console, Job Selection dialog, Alarm
Manager dialog, and Alarm Selection dialog. The Job Activity Console
allows you to monitor jobs, and to filter the jobs that it displays, you can use
the Job Selection dialog. 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.

Monitor/Browser Used to define monitors and reports. The

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

Jobs 3–33
 Chapter

Job Attributes
4
This chapter describes the essential and optional job attributes used to define
jobs. These attributes determine what a job does, including when and where it
will run.

Job Attributes and Job Definitions

You define a new job by assigning it a name and specifying any number of
attributes that describe its intended behavior. This specification of a job’s
behavior is called a job definition. There are two methods of creating a job
definition: using JIL and using the 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. For more information see the chapter
“Maintaining,” in this guide.

Job Attributes 4–1

Job Attributes and Job Definitions

Using JIL to Create a Job Definition

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

where:

job_name Is a unique job name.

attribute_keyword Is one of the legal JIL attributes.

value Is the setting to be applied to the attribute.

Using the Job Editor to Create a Job Definition

When using the Job Editor to create a job definition, open the GUI Control Panel
from the Graphical Interface icon in your program group, click on the Job Editor
button in the GUI Control Panel, and set the various attributes and their values
using the text fields and push-buttons in the Job Editor.

4–2 User Guide

 Job Attributes and Job Definitions

Organization

In this chapter, job attributes are organized into two categories: Essential and
Optional. Essential attributes are those that must be specified in order for the job
definition to be accepted. As the name implies, optional attributes are not
necessarily required for a job definition to be accepted. For each attribute
described in this chapter, as in the following illustration, we indicate its name, its
JIL attribute keyword, its corresponding Job Editor object, or GUI Field Name,
and a description of its use.

For more information see the chapter JIL/GUI Job Definitions, of the Unicenter
AutoSys Job Management for Windows and UNIX Reference Guide.

Job Attributes 4–3

Essential Job Attributes

Essential Job Attributes

Attributes Common to All Job Types

The following attributes are common to all job types: Command, File Watcher,
and Box. Although defaults may be available, the attributes in this section are
still essential due to the fact that every job definition must include them, whether
by default or by explicit specification.

Job Name

insert_job New Job and Save dialogs: Job Name

The job name is used to identify the job to, and must be unique. It can be
from 1 to 30 alphanumeric characters, and is terminated with white space.
Embedded blanks and tabs are illegal. Commands, File Watchers, and Box
Jobs cannot use the same name.

Job Type
job_type New Job dialog: Job Type

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

Job Owner
owner Basic Tab: Owner

The job owner specifies whose user ID the command will be run under on
the client machine. This attribute is automatically set to the user who
invoked jil or the Job Editor to define the job, and cannot be changed except
by the Edit Superuser.

4–4 User Guide

 Essential Job Attributes

Command Jobs Attributes

For Command jobs, the following attributes must be specified in addition to

those listed in the Attributes Common to All Job Types section previously
shown.

Command
command Basic tab: Command

The command attribute can be the name of any command, executable, UNIX
shell script or batch file, and its arguments. When issuing commands that are
to be run on a different operating system, you must use the syntax
appropriate to the operating system of the client machine. The 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. 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

(for example, 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.)

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, for
more information see Profile in this chapter.

If you want to use an command in the Command field or for the command
attribute, you must use the following syntax (when you use this syntax, the
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.

Job Attributes 4–5

Essential Job Attributes

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.

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

■ 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 Windows is initially empty) or in a user-defined
job profile.

■ Command line arguments can be passed using global variables.

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 section Job Profiles in the chapter “Jobs,”
in this guide. 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.

4–6 User Guide

 Essential Job Attributes

Machine to Run On
machine Basic tab: Send to Machine

This attribute specifies the client machine on which the command should be
run. The job’s owner must have permission to access this machine and to
execute the specified command at this machine. The machine can be a
specific real machine, a set of real machines, or a virtual machine. Real
machines must be accessible over the network using the TCP/IP protocol.

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 Unicenter AutoSys JM
chooses a machine to run on when you specify multiple machines or a load
balancing program, see the chapter, “Load Balancing and Queuing Jobs,” in this
guide.

Job Attributes 4–7

Essential Job Attributes

File Watcher Job Attributes

For File Watcher jobs, the following attributes must be specified in addition to
those listed in the section Attributes Common to All Job Types, in this chapter.

Machine to Run On

machine Basic tab: Send to Machine

This attribute specifies the client machine on which the File Watcher should
run. For a File Watcher, this attribute must specify a single real machine,
accessible over the network using TCP/IP.

File to Watch For

watch_file File to watch

The name of the file to watch for must be a legal file name and must include
the full path to the file. All directories in the path must exist, but the file itself
does not have to exist at the time the job is defined. Environment variables
defined and exported in the profile file (the specified or default), as well as
global variables, can be used in the path. Wildcards cannot be used in the file
name. For more information on how to use wildcards, see the Unicenter
AutoSys Job Management for UNIX and Windows Reference Guide in the
watch_file section.

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"and C\:\tmp are
valid; C:\tmp is not). When using the GUI, do not use escape characters. This
attribute is used in combination with the Watch File Minimum File Size and
Watch Interval attributes, to determine when a file is considered to have arrived.

Box Job Attributes

For more information on Box Job Attributes, see the section Attributes Common
to All Job Types, in this chapter.

4–8 User Guide

 Optional Job Attributes

Optional Job Attributes

Common Job Starting Attributes

The following optional attributes are common to all Job Types: Command, File
Watcher, and Box. These attributes are used to specify when a job should start,
and typically default to “inactive” or NULL if not specified.

For information on how date and time attributes are affected by the Spring and
Fall time adjustments, see the section Date and Time Attributes and Time
Changes, in this chapter.

Start Date /Time Dependence

date_conditions Date/Time tab: Date/Time Conditions

The start date/time dependencies attribute is a toggle, which specifies

whether or not there are date 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.

Days of the Week

days_of_week Date/Time tab: Run Days

The days of the week attribute specifies the days on which the job should be
run. You can specify one or more days, or all for every day.

Days to Run on —Using a Custom Calendar

run_calendar Date/Time tab: Run Days

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.

Job Attributes 4–9

Optional Job Attributes

Days to NOT Run on—Using a Custom Calendar

exclude_calendar Date/Time: Exclude Calendar

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

Specific Times of Day to Run

start_times Date/Time tab: Times of Day

This attribute specifies one or more specific times of day when the job should
be started. The job will be started at each specified time of day, on every day
specified in the associated date attributes. This attribute, the “Minutes after
Each Hour” (start_mins), and the “Anytime After Midnight” attributes are
mutually exclusive.

Time of Day Not to Run

run_window Date/Time tab: Run Window

This attribute specifies a time range (or time window) during which a job
can be started. When the starting conditions for a job have been met,
Unicenter AutoSys JM checks if the current time is within the specified run
window. The job will not start outside of the specified window. This
attribute controls only when the job will start, not when it will stop running.
This attribute is particularly useful when, for example, it is not known when
a watched-for file will arrive, and there are certain times when jobs
dependent on that file should not run. This setting can prevent a latearriving
file from causing a job to run at an inopportune time. The run window range
cannot span more than 24 hours. jobs that are not in a box must have starting
conditions in addition to the run_window attribute in order for the job to be
automatically started.

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

4–10 User Guide

 Optional Job Attributes

Specific Times Every Hour to Run

start_mins Date/Time tab: Minutes after Each Hour

One or more specific times per hour when the job should be started can be
specified. Each time is specified in minutes past the hour. The job will be
started at each specified time every hour of the day, on every day specified
in the associated date attributes. This attribute, the “Minutes after Each
Hour” (start_times), and the “Anytime After Midnight” attributes are
mutually exclusive.

Job Dependencies

condition Basic tab: Dependencies

Any number of job dependencies can be specified; however, every

dependency must evaluate to true before the dependent job will be run.
Examples of job dependencies include successful completion of a job, failure
of a job, a 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 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.

Job Attributes 4–11

Optional Job Attributes

To check for this type of invalid condition statement, you can use the chk_cond
stored procedure. For more informatin see the chapter “Commands,” in the
Unicenter AutoSys Job Management for Windows and UNIX Reference Guide.

For more information see the section Starting Parameters in the chapter “Jobs,”
and the chapter “Defining Jobs Using JIL,” in this guide. The functionality listed
in these locations will help you when creating your own job definitions.

Common General Attributes

The following optional attributes are common to all job types:

Command, File Watcher, and Box. These attributes are used to specify a variety
of features, and typically default to “inactive” or NULL if not specified.

Description

description Basic tab: Description

This attribute provides a comment field, used for documentation purposes

only. When entering a description using JIL, you should enclose the string in
double quotes to ensure JIL properly interprets it. The Job Editor adds
quotes for you automatically.

Box Name

box_name Basic tab: Box

Boxes allow a set of jobs to be manipulated as a group. This feature is

particularly useful for setting starting conditions at the box level, to “gate”
the jobs inside the box, then specifying their starting conditions relative to
each other individually, if necessary. This attribute specifies the name of the
box in which the job is to be placed. The specified box must already exist
before you can place jobs in it.

Minimum Run Time Alarm

min_run_alarm Alarms/Terminators tab: Minimum Run Time

4–12 User Guide

 Optional Job Attributes

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

Maximum Run Time Alarm

max_run_alarm Alarms/Terminators tab: Maximum Run Time

A maximum runtime can be specified for a job; the job should not take
longer than the specified time to finish. This reasonability test may catch an
error, such as the application being stuck in a loop, or the application
waiting for additional data which may never arrive. If the job runs longer
than this time, an alarm is generated to alert someone to investigate the
situation and take corrective action. Alarms are informational, and they do
nothing on their own. A monitor, the Alarm Sentry, or the Alarm Manager
must be running and tracking alarms in order for them to be seen and acted
upon in real-time.

The attribute “Terminate this job n mins after starting” (term_run_time) can be
used to automatically terminate a job that has been running for too long. If
term_run_time is not set, the job will continue running until manually
interrupted, or it completes by itself.

Terminate Due to Run Time

term_run_time Alarms/Terminators tab: Terminiate this job n

mins after starting

A maximum run time (in minutes) can be specified for a job; the job should
not take longer than the specified time to finish. This feature allows the job to
be automatically terminated if it runs longer than the allotted time.

Send Alarm if the Job Fails

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

Job Attributes 4–13

Optional Job Attributes

This attribute specifies whether or not an alarm should be generated when

the job fails. Failure is defined as the job completing with a FAILURE or
TERMINATED status. (The Maximum Exit Code for SUCCESS attribute
determines what codes are interpreted as FAILURE for a job, and the Failure
Condition attribute for Box Jobs determines what constitutes a box failure.)
Alarms are informational, and they do nothing on their own. A monitor, the
Alarm Sentry, or the Alarm Manager must be running and tracking alarms
in order for them to be seen and acted upon in real-time.

Terminate the Box if the Job Fails

box_terminator Alarms/Terminators tab: If this Job fails,

terminate the box it is in

This attribute specifies whether or not the box containing this job should be
terminated if the job fails or terminates. By using this attribute in
combination with the If this box fails, terminate this job attribute, you can
control how nested jobs react when a job fails. This attribute only applies if
the job is being placed in a box.

Terminate the Job if the Box Fails

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

This attribute specifies whether or not the job should be terminated if the box
it is in fails or terminates. By using this attribute in combination with the If
this job fails, terminate the box it is in attribute, you can control how nested
jobs react when a job fails. This attribute only applies if the job is being
placed in a box.

Note: Windows 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), Unicenter AutoSys JM 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.

4–14 User Guide

 Optional Job Attributes

Number of Times to Restart a Job

n_retrys Misc tab: Number of times to restart this job

after a failure

This attribute specifies how many times, if any, the job should be restarted
after exiting with a FAILURE status. The default is “0”, which means the job
will not be automatically restarted after an application failure. This attribute
applies to application failures (for example, Unicenter AutoSys JM is unable
to find a file or a command, or permissions are not properly set); it does not
apply to system or network failures (for example, machine unavailability,
the socket connect timed out, the fork in the Remote Agent failed, or the file
system space resource check failed).

The number of restarts after system or network failures is specified using the
Max Restart Trys field on the Administrator Event Processor screen.For more
information on Max Restart see the chapter “Administrator,” in this guide.

Time Zone for Job

timezone Date/Time tab: Time Zone

This attribute allows you to schedule a job based on a chosen time zone.
When this attribute is used, the time settings in the job are based on the
specified time zone. For example, if you define a start time of 01:00 for a job
running on a machine in Denver, and enter SanFrancisco in the Time Zone
field, the job will start at 1:00 a.m. Pacific time, which is 2:00 a.m. in Denver.
If you specify a time zone that includes a colon, you must quote the time
zone name if you are using JIL. For example:
timezone: "IST-5:30"

If you do not quote a time zone specification that contains a colon, JIL will
interpret the colon as a delimiter, producing unexpected results. Jobs with time-
based starting conditions that do not specify a time zone will have their start
event scheduled based on the time zone under which the Event Processor is
running.

Job Attributes 4–15

Optional Job Attributes

Delete Job After Completion

auto_delete Misc tab: Delete Job after completion

This attribute indicates whether or not the job definition should be

automatically deleted after successful completion. A number of hours can be
specified (including “0” for immediately), or the attribute can be turned
“off” by specifying a negative value (for example “-1”), which is the default.
If auto_delete is set to 0, Unicenter AutoSys JM will immediately delete job
definitions only if the job completed successfully. If the job did not complete
successfully, Unicenter AutoSys JM will keep the job definition for 7 days
before automatically deleting it. This attribute is useful for letting Unicenter
AutoSys JM schedule and run a one-time batch job.

Autohold

auto_hold Misc tab: AutoHold on for jobs in boxes

This feature is only for jobs in a box. When a job is in a box, it inherits the
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 (for example, 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.

4–16 User Guide

 Optional Job Attributes

Permissions

permissions Misc tab: Permissions

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

For Windows by default, only a job’s owner has Edit and Execute permission on
a job.

Unicenter AutoSys JM 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 as in
STARTJOB, KILLJOB and so forth.

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 section overview of the
chapter “Security,” in this guide.

Job Attributes 4–17

Optional Job Attributes

Command Job Attributes

For Command jobs, the following optional attributes can be specified, in

addition to those listed in the section Attributes Common to All Job Type, in this
chapter. These attributes typically default to “inactive” if not specified.

Profile

profile Resource Profile: Job Environment Profile

The profile attribute specifies the name of the defined job profile that
contains the environment variables that should be set for the command’s
execution. You can add and delete job profiles using the Profiles Manager,
which you can open from the program group. For more information on the
Profiles Manager aee the section Job Profiles, in the chapter “Jobs,” in this
guide.

If no profile attribute is specified, the profile named “default” is used. On

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

4–18 User Guide

 Optional Job Attributes

Redirection of the Standard Input File

std_in_file Command Info tab: File to redirect standard input

The standard input file can be redirected to any file to which the job owner
has read permission on the client machine. The full pathname must be
specified, although variables defined in the 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:.

Redirection of the Standard Output File

std_out_file Command Info tab: File to redirect standard output

The standard output file can be redirected to any file on the client machine to
which the job owner has write permission. The full pathname must be
specified, although variables defined in the 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 characters 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 Administrator Event Processor screen. It also overrides the
machine-specific setting for the AutoMachWideAppend variable, which you can
set on the 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 Unicenter AutoSys Administrator, see the chapter
“Administrator,” in this guide.

Job Attributes 4–19

Optional Job Attributes

Redirection of the Standard Error File

std_err_file Command Info tab: File to redirect standard error

The standard error file can be redirected to any file on the client machine to
which the job owner has write permission. The full pathname must be
specified, although variables defined in the 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 characters 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 Administrator Event Processor screen. It also overrides the
machine-specific setting for the AutoMachWideAppend variable, which you can
set on the 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 Unicenter AutoSys Administrator, see the chapter
“Administrator,” in this guide.

4–20 User Guide

 Optional Job Attributes

Job Load

job_load Command Info tab: Job Load

Machines can be assigned “maximum job loads,” which is a measure of the

CPU load that is desirable for a machine at any given time. Similarly, jobs
can be assigned loads, indicating the relative amount of processing power
they consume. This scheme allows for machine loading to be controlled, and
prevents a machine from being overloaded. If a job is ready to run on a
designated machine, but the current load on that machine is too large to
accept the new 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.

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 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 the chapter “Load
Balancing and Queuing Jobs,” in this guide.

Queue Priority

priority Command Info tab: Que priority

The queue priority establishes the relative priority of all jobs queued for a
given machine, with the lower number indicating higher priority. If a job is
ready to run on a designated machine, but the current load on that machine
is too large to accept the new 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 Attributes 4–21

Optional Job Attributes

Job Overrides

override_job File menu and Basic tab: Add One Time Override

You can specify a one-time job override for the next run of a particular job.
An override lets you change the behavior of a job the next time the job runs.

The following attributes can be modified in a job override: For a description

of how to use the Job Editor to specify job overrides, see the chapter
“Defining Jobs using the Job Editor,” in this guide.

override_job menu
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

Maximum Exit Code for Success

max_exit_success Command Info tab: Maximum Exit Code for SUCESS

The maximum exit code for success attribute indicates what exit codes will
be considered 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 attribute lets you define complex branching logic based on specific exit
code values. Unicenter AutoSys JM reserves exit codes greater than 120 for
internal use, so do not use exit codes of 120 or greater.

4–22 User Guide

 Optional Job Attributes

Average Runtimes

avg_runtime (JIL only)

The avg_runtime attribute is used to provide an average runtime (in

minutes) for a job that is newly submitted to the database; it establishes this
value in the absence of the job having been run multiple times. This attribute
is used solely to establish an average runtime for the new job in the
avg_job_runs table.

Heartbeat-Interval

heartbeat_interval Command Info tab: Heartbeat interval (mins)

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

For information on configuring Unicenter AutoSys JM and the Unicenter

AutoSys Administrator, see the chapter “Administrator,” in this guide. For
information on sending heartbeats, see the section Sending Heartbeats in the
chapter “API,”in the Unicenter AutoSys Job Management for Windows and
UNIX Reference Guide.

Job Attributes 4–23

Optional Job Attributes

Resource Check - File Space

chk_files Resource/Profile tab: Resource Check – File System Space

This attribute specifies a minimum amount of file space that must be

available on the designated drives for the job to be started. One or more
drives, specified with drive letters, and their corresponding sizes, can be
specified. If multiple drives 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 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.

4–24 User Guide

 Optional Job Attributes

File Watcher Job Attributes

For File Watcher jobs, the following attributes can be specified in addition to
those listed in the section File Watcher Job Attributes, in this guide. These
attributes typically default to inactive if not specified.

Watch File Minimum Size

watch_file_min_size Basic tab: Minimum file size (in bytes)

The watch file minimum size determines when enough data has been
written to the file to consider it complete. This attribute is specified in bytes.
You should specify a reasonable file size to ensure that a nearly empty file
isn’t assumed to be complete. Use caution with this attribute. If you specify a
large file size Unicenter AutoSys JM will wait for the file to reach that size,
even if the file has reached a steady state and is no longer growing.

Watch Interval

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

The watch interval specifies (in seconds) how often the File Watcher should
check the current file size to ascertain whether data is still being written to
the file. The default is every 60 seconds.

Resource Check - File Space

chk_files Resource/Profile tab: Resource Check – File System Space

This attribute specifies a minimum amount of file space that must be

available on designated file systems for a Command job to be started. One or
more file systems, specified with drive letters, and their corresponding sizes
can be specified. When the Remote Agent is preparing to start the job on the
client machine, it checks whether the required space is available before
starting the job. If the requirements are not met, an alarm is generated. File
Watcher jobs will still be started.

Job Attributes 4–25

Optional Job Attributes

Box Job Attributes

For Box jobs, the following optional attributes can be specified, in addition to
those listed in the section Attributes Common to All Job Types, in this chapter.
These attributes typically default to inactive or NULL if not specified.

Box Successful Completion

box_success Basic Tab: Success Conditions

The default condition required for a box to be considered successful is that

every job in the box must have completed with a success condition. A box
can contain complex branching logic, which can take a number of different
paths, all of which constitute a success. In this case, some jobs in the box may
never need to run, but if the default box behavior is applied, the jobs that
had not run would prevent the box from ever completing. This attribute can
be used to specify what is considered a success of a single job, or as complex
as necessary. This attribute is only displayed in the Job Editor when you
select a Box Job Type, and then it is located on the Basic tab.

Box Failure

box_failure Basic tab: Failure Conditions

The default condition required for a box to complete with a FAILURE status
is that all jobs in the box have completed and one or more jobs in the box
completed with a failure condition. A box can contain complex branching
logic, which may take a number of different paths, one of which may include
recovery from a failed job. In this case, you might want the box to be
considered successful, even though a job within it failed. This attribute can
be used to specify what will be considered as a failure, which could be as
simple as the failure of a single job, or as complex as necessary. This attribute
is only displayed in the Job Editor when you select a Box Job Type, and then
it is located on the Basic tab.

4–26 User Guide

 Date and Time Attributes and Time Changes

Date and Time Attributes and Time Changes

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

The Time Change

During the changes to and from daylight saving time, your operating system
automatically changes the system clock to reflect the switch to either Standard
Time (ST) or Daylight Time (DT). In the spring, at 2 a.m., the clocks spring
forward to 3 a.m. In most of the United States, this happens on the first Sunday
in April. The following illustration shows this time change.

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.

Job Attributes 4–27

Date and Time Attributes and Time Changes

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. The following illustration shows
this 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.

Behavior During Time Change

Jobs that are time dependent may have their scheduling shifted to adjust for the
time change. Jobs that are not time dependent, but have other starting
conditions, will run as normal.

There are two types of time dependencies: 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

4–28 User Guide

 Date and Time Attributes and Time Changes

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

Spring Time Change

During the change to daylight saving time in the spring, the “2:00-2:59” hour is
lost, therefore Unicenter AutoSys JM cannot schedule any jobs during that non-
existent hour.

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

Job Attributes 4–29

Date and Time Attributes and Time Changes

Run Windows

Run windows are treated a bit differently. If the specified closing of the run
window falls within the missing hour, its recalculated closing time will be
bumped up an hour, so that the effective duration of the run window remains
the same. For example, a run window of 1:00 - 2:30 will have the closing time
move to 3:30, so that the run window still remains open for an hour and a half.

If the specified opening of the run window falls within the missing hour, its
opening time is moved to 3:00. The closing time does not get altered, therefore
the run window is foreshortened. For example, a run window of 2:45 - 3:45 will
become 3:00 - 3:45, and the actual run window elapsed time will be 15 minutes
shorter.

If both the specified opening and closing of the run window is within the
missing hour, its opening time is moved to the first minute after 3:00, and its
closing time is pushed forward one hour. Therefore, the resultant run window
may be lengthened. For example, a run window of 2:15 - 2:45 will become 3:00 -
3:45, or 15 minutes longer.

4–30 User Guide

 Date and Time Attributes and Time Changes

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 the following
illistration).

Standard Time

1:00 2:00 3:00 4:00

start_time attribute
runs in second hour

start_mins attribute runs in both hours

0:00 1:00 1:59

Daylight Savings Time

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.

Job Attributes 4–31

Date and Time Attributes and Time Changes

Testing the Fall Time Change

During the fall time change from Daylight Savings time to Standard Time, your
operating system automatically falls back one hour from 2 a.m. to 1 a.m., causing
the hour from 1 a.m. to 2 a.m to be repeated.

When testing this time change, you must set the clock to a time before 1 a.m. and
allow the entire hour to pass before you can observe the time change. If you
manually set the time to a period within the 1 a.m to 2 a.m. window, the system
will assume that the time change has already occurred and will not reset at 2
a.m.

Run Windows

Run windows are treated a bit differently. If the specified opening of a run
window is before the time change, and its specified closing falls within the
repeated hour, it will close during the daylight saving, or first hour. For
example, a run window of 11:30 - 1:30 will have the closing time of 1:30 DT, not
1:30 ST, which means that the run window remains open for its specified two
hours. This may be a problem if there are also associated start times on the job
which occur during the repeated hour. In the example above, if the job also had a
start time of 1:15, the start time would be calculated for 1:15 ST, and the job
would not run on the day of the time change.

If the specified opening of the run window falls within the repeated hour, its
opening time is moved to the second, Standard Time hour. The closing time does
not get altered, therefore the length of the run window will remain the same. For
example, a run window of 1:45 - 2:45 will become 1:45 ST to 2:45, or the same
hour in length.

If both the specified opening and closing of the run window is within the
repeated hour, the run window will be open during the second, Standard Time
hour.

4–32 User Guide

 Chapter

Box Job Logic

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

Basic Box Concepts

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

Default Box Job Behavior

Some important rules to remember about boxes are:

■ Jobs run only once per box execution.

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

■ Boxes should be used primarily for jobs with the same starting conditions. A
box used to group sequential jobs is limited to 1,000 jobs.

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

Box Job Logic 5–1

Basic Box Concepts

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

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

■ Changing the state of a box to INACTIVE (the sendevent command) changes

the state of all the jobs in the box to INACTIVE.

When You Should Not Use a Box

The fact that all jobs in a box change status when a box starts running has lead
some to use boxes to implement “job cycle” behavior. Be aware that placing jobs
in a box to achieve this end may bring 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.

5–2 User Guide

 Basic Box Concepts

Likewise, you should not place jobs in a box solely because you want to run
reports on all of them. When you run autorep on a box, you will get a report on
the box and all the jobs in the box (unless you use the -L0 option). In addition, if
you use wildcarding when specifying a job name, you could get duplicate entries
in your report. For example, suppose you have a box named “acnt_box”
containing three jobs named “acnt_job1,” “acnt_job2,” and “daily_rep.” If you
specify acnt% as the job name for the autorep report, the report will have an
entry for the box “acnt_box” and an entry for each job in the box. Then autorep
will continue searching for all job names matching the wildcard characters and,
thus, will list “acnt_job1” and “acnt_job2” a second time.

What Happens When a Box Runs

As soon as a box starts running, all the jobs in the box (including sub-boxes)
change to status ACTIVATED, meaning they are eligible to run. (Because of this,
jobs in boxes do not retain their statuses from previous box cycles.) Then each job
is analyzed for additional starting conditions. All jobs with no additional starting
conditions are started, without any implied ordering or prioritizing. Jobs with
additional starting conditions remain in the ACTIVATED state until those
additional dependencies have been met. The box remains in the RUNNING state
as long as there are activated or running jobs in the box.

If a box is terminated before a job in it was able to start, the status of that job will
change directly from ACTIVATED to INACTIVE.

Note: 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, discussed later in this
chapter.)

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.

Box Job Logic 5–3

Basic Box Concepts

Simple Box Job

In this example, a box named “simple_box” contains three jobs: “job_a,” “job_b,”
and “job_c.” “job_a” and “job_b” have no starting conditions; the starting
condition for “job_c” is the success of “job_b.”

job_a job_b

simple_box SUCCESS job_b

job_c

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.

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.

5–4 User Guide

 Box Job Attributes and Terminators

Box Job Attributes and Terminators

The following sections describe how to use various job attributes to control the
behavior of box jobs and their contained jobs.

Attributes in a Box Job Definition

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

Example of a Non-Default Success Condition

Using the above simple box example, assume you defined the following success
condition for “simple_box”:
box_success: success(job_a)

If “job_a” runs successfully, and “job_b” is still running, “job_c” would pass
from ACTIVATED state directly to INACTIVE state without ever running
because the box it is in would no longer be running.

When overriding default box terminators, be careful that you do not define
conflicting success and failure conditions.

Box Job Logic 5–5

Box Job Attributes and Terminators

Attributes in a Job Definition

There are two attributes you can add to the definition of a job within a box to
force either the job or the box to stop running. They are box_terminator and
job_terminator.

The box_terminator: y attribute specifies that if the job fails, the box the job is in
should terminate. If you use this attribute, be sure you have defined conditions
for the other jobs in the box in the event that the box is terminated. For more
information, see the figure in Using the Box Terminator Attribute in this chapter.

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 the
figure in Using the Job Terminator Attribute in this chapter.

Time Conditions in a Box

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

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

5–6 User Guide

 Box Job Attributes and Terminators

The following illistration shows 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.”

bx_stat
job_a
3:00 a.m. Daily
run until succeed

job_report
success(job_a)
Report success of job_a

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.

Box Job Logic 5–7

Box Job Attributes and Terminators

Force Starting Jobs in a Box

The FORCE_STARTJOB command forces a job to start even if its starting

conditions have not been met. The command has the form:
sendevent -E FORCE_STARTJOB -J job_name

You can also execute this by selecting the Force Start Job button in the Job
Activity Console.

If you force start a job in a box, the state of the box influences whether or not
other jobs in the box will run as expected, as shown in the following example.

bx_report
3:00 a.m. Daily

job_Fwatch run_stats report_stats

success (job_Fwatch) success (run_stats)
box_terminator: y

Watch for file Run Statistics Report Statistics

In the previous figure, 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.

5–8 User Guide

 Box Job Attributes and Terminators

How Job Status Changes Affect Box Status

If a box that is not running contains a job that changes status, as a result of a
FORCE_STARTJOB or CHANGE_STATUS event, the new job status could
change the status of its container box. A change of status of the box could trigger
the start of downstream jobs that are dependent on the box.

If a box contained only one job, and the job changed status, the box status would
change as shown in the following table:

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

If another 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 evaluated again 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.

Box Job Logic 5–9

Examples

Examples
Spend some time studying the examples in this section. They will help explain
the logic of job flow in a box and reduce your chances of creating unexpected
box behavior.

Advanced Conditions in Box Jobs

In the following example, conditions are defined to address different situations

where the box might complete with a FAILURE status. The logic of this job flow
is as follows:

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

5–10 User Guide

 Examples

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

The following illistration shows this job stream:

bx_daily_update
3:00 a.m. daily

job_update
box_terminator: y
Update files

FAILURE job_update
SUCCESS job_update

job_run_stats
success
(job_update)
box_terminator: y
Run statistics

SUCCESS job_run_stats FAILURE job_run_stats

job_report_stats
success(job_run_stats)
Report Statistics

SUCCESS job_report_stats FAILURE job_report_stats

FAILURE bx_daily_update
SUCCESS bx_daily_update

job_trigger_msg
failure (bx_daily_update)
Page operator

SUCCESS job_trigger_msg

Box Job Logic 5–11

Examples

Default Box Success and Box Failure

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

The following illistration shows this job stream logic:

Job Stream Job status

update_accounts FAILURE

SUCCESS

run_stats
FAILURE ACTIVATED
success(update_accounts)

SUCCESS

report_stats
FAILURE ACTIVATED ACTIVATED
success(run_stats)

SUCCESS

Box SUCCESS Box FAILURE Box Still RUNNING Box Still RUNNING

5–12 User Guide

 Examples

Explicit Box Success and Box Failure

The following illistration showsm a box success and failure:

Job Definitions

do_statistics
3:00 a.m. Daily
box_success: success(update_accountes) AND success(run_stats) AND
success (report_stats)
box_failure: failure(update_accounts) OR failure(run_stats) OR
failure(report_stats)

run_stats
update_accounts report_stats
success(update_acco
success(run_stats)
unts)
Update Files Report Statistics
Run Statistics

Job Stream Job status

do_statistics

update_accounts FAILURE

SUCCESS

run_stats FAILURE INACTIVE

SUCCESS

report_stats FAILURE INACTIVIE INACTIVE

SUCCESS

Box SUCCESS FAILURE FAILURE FAILURE

Box Job Logic 5–13

Examples

Using the Box Terminator Attribute

The following illistration uses box_terminator:

Job Definitions

daily_accounts
3:00 a.m. Daily

daily_receipts daily_payables
daily_balance
box_terminator: y box_terminator: y
success(daily receipts)
AND
Process Receipts Process Payables
success(daily_payables)
Calculate Balance

Job Stream

daily_accounts

daily_receipts daily_payables

SUCCESS SUCCESS

FAILURE
FAILURE

Box TERMINATED SUCCESS TERMINATED

daily_balance

5–14 User Guide

 Examples

Using the Job Terminator Attribute

The following illistration uses job_terminator:

Job Definitions

daily_accounts
3:00 a.m. Daily
daily_balance
daily_payables success(daily receipts)
daily_receipts AND success(daily_payables)
job_terminator: y
Calculate Balance
Process Receipts
Process Payables

Job Stream
daily_accounts

daily_receipts daily_payables TERMINATE

SUCCESS SUCCESS

FAILURE FAILURE

Box FAILURE FAILURE

daily_balance

Box Job Logic 5–15

Examples

Advanced Job Streams

Scenario On the First of the Month

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

Job Definitions

job_Fwatch job_monthly
job_daily
3:00 a.m. Daily
1:00 a.m. First Day 2:00 a.m. First Day of
success(job_monthly)
of month Month
term_run_time:90 success(job_Fwatch)
Generate Report
Watch for File Re-index, Organize, Purge

Job Stream
Start
Date/Time job_Fwatch
Conditions Met File from
Mainframe
Job Dependency
Condition Met SUCCESS

Start
Date/Time job_monthly
Conditions Met

Event Status in
SUCCESS AutoSys Database=
SUCCESS
Job Dependency
Condition Met

job_daily

Date/Time
Conditions Met SUCCESS

5–16 User Guide

 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 database from the previous
run on the first of the month. As a result, “job_daily” will still run.

Job Definitions

job_Fwatch job_monthly
job_daily
3:00 a.m. Daily
1:00 a.m. First Day 2:00 a.m. First Day of
success(job_monthly)
of month Month
term_run_time:90 success(job_Fwatch)
Generate Report
Watch for File Re-index, Organize, Purge

Job Stream
NOT RUN
Date/Time job_Fwatch
NOT Conditions Met File from
Mainframe

X
Job Dependency
Condition NOT Met

NOT RUN
Date/Time job_monthly
NOT Conditions Met

Event Status in
AutoSys Database=
SUCCESS (from Jan 1)
Job Dependency
Condition Met
Start
job_daily

Date/Time
Conditions Met SUCCESS

Box Job Logic 5–17

Examples

Scenario I On First of the Month

On the first of the next month (for example, 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 database is still SUCCESS from the previous
month, and as a result, “job_daily” runs in error.

Job Definitions

job_Fwatch job_monthly
job_daily
3:00 a.m. Daily
1:00 a.m. First Day 2:00 a.m. First Day of
success(job_monthly)
of month Month
term_run_time:90 success(job_Fwatch)
Generate Report
Watch for File Re-index, Organize, Purge

Job Stream
Start
Date/Time job_Fwatch
Conditions Met File from
Mainframe

X
term_run_time: 90
Job Dependency
Condition NOT Met TERMINATED

NOT RUN
Date/Time job_monthly
Conditions

Event Status in
AutoSys Database=
SUCCESS (from Jan 1)
Job Dependency
Condition Met
Start
job_daily

Date/Time
Conditions Met

Undesirable Result SUCCESS

5–18 User Guide

 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.

Job Definitions

job_Fwatch job_monthly
job_daily
3:00 a.m. Daily
1:00 a.m. First Day 2:00 a.m. First Day of
success(job_monthly)
of month Month
term_run_time:90 success(job_Fwatch)
Generate Report
Watch for File Re-index, Organize, Purge

At 1:00 a.m. on first day of month, issue a CHANGE_STATUS on "job_monthly" using GUI
Send Event dialog or by issuing the following command:
sendevent -E CHANGE_STATUS -S INACTIVE -J job_monthly

Job Stream

Start
Date/Time job_Fwatch
Conditions Met File from
Job Dependency term_run_time: 90 Mainframe
Condition NOT Met

Date/Time
Conditions
NOT RUN
TERMINATED

job_monthly
X
Event Status in
AutoSys Database=
INACTIVE
Job Dependency
Condition NOT Met

NOT RUN job_daily

Date/Time
Conditions Met

Desirable Result

Box Job Logic 5–19

Examples

Scenario III On First of the Month

Instead of issuing a sendevent command to change the status of the jobs, you
could put the monthly process in a box, and set box_failure or box_terminator
appropriately.

box_monthly

job_Fwatch job_monthly
job_daily
1:00 a.m. First Day
3:00 a.m. Daily
of Month success(job_Fwatch)
success(box_monthly)
box_terminator: y job_terminator: y
Generate Report
Watch for File Re-index, Organize, Purge

box_monthly

Start File from

Date/Time
job_Fwatch Mainframe
Conditions Met

SUCCESS

job_monthly

SUCCESS

Job Dependency
TERMINATED Condition Met

Job Dependency Start

Condition NOT Met job_daily
job_daily Date/Time
NOT RUN Conditions Met
Date/Time SUCCESS
Conditions Met

5–20 User Guide

 Chapter
Introduction to the Graphical User
6 Interface

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

To start the GUI Control Panel:

Open the graphical interface from its icon in the program group.

This action opens the GUI Control Panel:

Introduction to the Graphical User Interface 6–1

Using the GUI Control Panel

Using the GUI Control Panel

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

GUI Control Panel Menu Bar

The GUI Control Panel has the following menus:

■ File

■ Tools

■ Preferences

■ Help

File Menu

The File menu contains the following options:

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

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

6–2 User Guide

 Using the GUI Control Panel

Tools Menu

The Tools menu contains the following options:

Send Event
Opens the Send Event Tool, which you can use to send events, as well as
cancel those previously sent events. For more information, see the topic
Using the Send Event Tool in the chapter “Scheduler Console,” in this guide.

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, and Alarm Manager. For more information about the
Run Status Tool, see the topic Using the Run Status Tool in the chapter
“Scheduler Console,” in this guide.

Event 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, or Alarm Manager
windows. For more information about the Job Detail Report tool, see the
topic Using the Job Detail Report Tool in the chapter “Scheduler Console,” in
this guide.

Preferences Menu

The Preferences menu contains the following options:

General
Opens the General dialog, which you can use to set the DB Retry Count and
the Alarm Color. In the DB Retry Count field, you can specify the number of
times each GUI component tries to connect to the database. After the
specified number of tries, the GUI stops trying to connect, and you must
close and restart the GUI component to restart the retry count. The Alarm
Color setting is used to indicate alarms in the Scheduler Console, Alarm
Sentry, and Alarm Manager. The No Alarm Color is used in the Alarm
Sentry to indicate there are no alarms for the instance.

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.

Introduction to the Graphical User Interface 6–3

Using the GUI Control Panel

Help Menu

The Help menu contains the following options:

About
Displays GUI Control Panel version number.

GUI Control Panel Buttons

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

Scheduler Console
Displays the Scheduler Console, which lets you monitor jobs and alarms
across multiple instances. For information, see the chapter “Scheduler
Console,” in this guide.

Job Editor
Displays the Job Editor, which lets you define jobs. For information, see the
chapter “Defining Jobs Using the Job Editor,” in this guide.

Calendar Editor
Displays the Calendar Editor window, which lets you define run and
exclude calendars. For information, see the chapter “Calendar Editor,” in
this guide.

Monitor/Browser Editor
Displays the Monitor/Browser Editor, which lets you define and run
monitors and reports (or browsers). For information, see the chapter
“Monitoring and Reporting on Jobs,” in this guide.

Alarm Manager
Displays the Alarm Manager application, which lets you view and respond
to alarms across multiple instances. For information, see the chapter
“Managing Alarms,” in this guide.

Alarm Sentry
Displays the Alarm Sentry dialog, which indicates if there is an alarm for
any instance you are monitoring. For information, see the chapter
“Managing Alarms,” in this guide.

6–4 User Guide

 Using the GUI Control Panel

Admin GUI
Displays the administration dialog, which lets you implement several
advanced configurations, including cross-instance job dependencies, dual-
event servers, and shadow event processors. For more information on the
Admin GUI, see the chapter “Administrator” in this guide.

Exit
Exits the GUI Control Panel.

Introduction to the Graphical User Interface 6–5

 Chapter

Defining Jobs Using the Job Editor

7
This chapter provides a description of the Job Editor interface and its use.

Starting the Job Editor

Use the Job Editor to create, modify, and delete job definitions for command, file
watcher, and box jobs.

To open the Job Editor:

Click Job Editor in the GUI Control Panel.

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 the chapter
“JIL/GUI Job Definitions,” in the Unicenter AutoSys Job Management for
Windows and UNIX Reference Guide.

Defining Jobs Using the Job Editor 7–1

Starting the Job Editor

The Job Editor opens for a command job, as the following illistration shows.

7–2 User Guide

 Using the Job Editor Interface

Using the Job Editor Interface

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 the
previous figure is based on a command job.

Job Editor Menu Bar

The Job Editor menu bar includes the following menus: File, Edit, Options, and
Help.

File Menu

The File menu includes the following options:

New—Displays the New Job dialog in which you enter the name of the job, the
instance to which you are defining it and the job type as follows:

■ Name must be unique to the instance. It must be from 1 to 64 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.

■ 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 percent (%), 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 enter 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.

Defining Jobs Using the Job Editor 7–3

Using the Job Editor Interface

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

New Job Editor

Displays a new, empty Job Editor window.

Exit
Closes the Job Editor.

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.

Edit Menu

The Edit menu contains the following option:

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

7–4 User Guide

 Using the Job Editor Interface

Options Menu

The Options menu contains the following option:

Adopt Session Context

Toggles the session context feature on and off. The default setting is to have
Adopt Session Context on (checked). When you select a job from the
Scheduler Console or Alarm Manager, the open Job Editor updates to reflect
the selected job. If you toggle this option to off, the open Job Editor does not
update.

Help Menu

The Help menu contains the following option:

Contents
Displays the Contents of the Unicenter AutoSys JM Help.

About
Displays the Job Editor version number.

Job Editor Tabs

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

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

Defining Jobs Using the Job Editor 7–5

Using the Job Editor Interface

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.

Job Editor Status Area

The bottom portion, or status area, of the Job Editor lists the fields that require
values for the job type you are defining. That is, each job type requires that you
set specific attributes, and those attributes are listed in the status area of the
window.

In addition, the status area indicates syntax errors and other problems with the
job definition.

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

Command
Indicates the command to run. When issuing commands that are to run on a
different operating system, you must use the syntax appropriate to the
operating system of the client machine on which the job will run. The job
Owner must be able to log on to 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.

7–6 User Guide

 Using the Job Editor Interface

Required Values for Box Jobs

Name, Job Type, and Owner are the only required values for box jobs.

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

Machine
Indicates the client machine on which to run the job. The job Owner must
have permission to access this machine and to execute the specified
command at this machine. For jobs running on Windows machines, the
owner must have a user account on the machine, and the associated logon ID
and password must be entered into the 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.

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.

Defining Jobs Using the Job Editor 7–7

Creating a Simple Command Job

Creating a Simple Command Job

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.

Create the test_run example command job from the following:

1. In the GUI Control Panel, click Job Editor.

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

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.

■ 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 Windows, you must have already entered
into the database a valid Windows user ID and password for the Owner’s
user account on the machine. If you use localhost, you must have a Windows
user ID and password in the database for user@localhost (entered using the
autosys_secure command). However, if you are running 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.

7–8 User Guide

 Creating a Simple Command Job

5. In the Save As dialog, select an Instance and enter the new job name:
test_run

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 the following
illistration. Leave the Job Editor open and use it for the next example.

WARNING! For the host portion of the Owner field, Unicenter AutoSys JM 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 Windows Control Panel
Network dialog.

Note: The Owner field for the job defaults to the currently logged-on user. The
Instance is the instance that you chose in the Save As dialog.

Defining Jobs Using the Job Editor 7–9

Creating a File Watcher Job

Creating a File Watcher Job

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.

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 the following in the Name field:

EOD_watch

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 (that is, 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 Windows 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

7–10 User Guide

 Creating a File Watcher Job

This setting indicates that Unicenter AutoSys JM 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.

When the definition is written to the database, a confirmation dialog is

displayed.

8. Click OK to dismiss the dialog.

Your entries in the Job Editor should look similar to those in the following
illistration. Leave the Job Editor open to use in the next example.

Note: The Owner field for the job defaults to the currently logged-on user. The
Instance is the instance that you chose in the New Job dialog.

Defining Jobs Using the Job Editor 7–11

Creating a Dependent Command Job

Creating a Dependent Command Job

This section describes how to create a command job that is dependent on the
successful completion of the file watcher job you just created. Unlike the simple
command job you created earlier, this command job is dependent on another job.

To create a command job with dependencies:

Follow these steps using the open Job Editor:

1. Choose File, New.

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

2. In the New Job dialog:

a. Enter the following in the Name field:

EOD_post

b. Select the appropriate Instance.

c. Leave the default Command setting for the Job Type.

d. Click OK.

A Job Editor opens for this command job.

3. In the Command field, enter the command that runs when the file watcher
completes, for example:
%HOMEPATH%\post.exe

In this example, assume that the environment variable %HOMEPATH%

means that the post executable is located in the job owner’s home directory.

4. In the Dependencies field, enter the starting condition, in this case the
successful completion of the file watcher job:
S(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 (that is, 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 database a valid Windows user ID and password for the
Owner’s user account on the machine.

7–12 User Guide

 Creating a Dependent Command Job

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

When the definition is written to the database, a confirmation dialog is

displayed.

7. Click OK to dismiss the dialog.

The Job Editor should look similar to the following illistration. Leave the Job
Editor open to use for the next example.

Note: On Windows, the job’s execution environment automatically includes

Windows System Variables and specific environment variables, but it does not
include the Windows User Variables. If you want to set the User Variables or any
other variables for the job, you must define them in an 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.

Note: The Owner field for the job defaults to the currently logged-on user. The
Instance is the instance that you chose in the New Job dialog.

Defining Jobs Using the Job Editor 7–13

Creating a Box Job

Creating a Box Job

A box job contains jobs with like starting conditions. For example, if you wanted
to schedule a group of jobs to start running after a file watcher job completes
successfully, you could create a box job to contain those jobs. Instead of making
each individual job dependent on the file watcher job, you create a box job that is
dependent on the file watcher, and place all of the jobs in the box.

This section describes how to do the following:

■ Create the EOD_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 the chapter “Box Job Logic,” in this
guide.

Creating the EOD_box Box Job

To define a box job:

Follow these steps using the open Job Editor:

1. Choose File, New.

The New Job dialog opens.

2. In the New Job dialog:

a. Enter the following in the Name field:

EOD_box

b. Select the appropriate Instance.

c. From the Job Type drop-down list, select Box.

d. Click OK.

A Job Editor opens in which you can define this box job.

3. In the Dependencies field, enter the following starting condition, which is

the successful completion of the file watcher job:
S(EOD-watch)

7–14 User Guide

 Creating a Box Job

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 the following illistration. Leave the Job
Editor open.

Note: The Owner field for the job defaults to the currently logged-on user. The
Instance is the instance that you chose in the New Job dialog.

Defining Jobs Using the Job Editor 7–15

Creating a Box Job

Modifying the EOD_post Command Job

This section describes how to modify the existing EOD_post job to remove its
dependencies and place it in the EOD_box job you just created.

Note: Before you modify any job, you must ensure that the job is not running.

To modify the EOD_post job:

Follow these steps using the open Job Editor:

1. Choose File, Open.

The Open dialog opens, which you can use to search for and select existing
job names.

2. In the Open Dialog, enter the following in the Pattern field.

EOD%

3. Click Search.

The names of the jobs you defined in this chapter should be displayed, as
shown in the following illistration:

Note: In the Pattern field, you can enter some portion of the job name,
followed by the percent (%) wildcard character. The percent (%) 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.

7–16 User Guide

 Creating a Box Job

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

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.

9. Click OK to dismiss the confirmation dialog.

Leave the Job Editor open.

Defining Jobs Using the Job Editor 7–17

Setting Date and Time Dependencies

Setting Date and Time Dependencies

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

To bring the Job Editor Date/Time tab to the front, click the tab. To enable the
fields, click the Date/Time Conditions check box, as shown in the following
illistration:

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, Unicenter AutoSys JM 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.

7–18 User Guide

 Setting Date and Time Dependencies

Setting Days of the Week Starting Conditions

When setting Date conditions, you can indicate that a job should run on specific
days of the week or on all days of the week. You can also use a custom calendar
to indicate that a job should run on the days defined in the calendar, or that it
should not run on the days indicated in the calendar. When you set Date
conditions, you must also set Time conditions to indicate the time of day the job
should run.

Note: You can set only one of the Run Days or Run Calendar Date options. They
are exclusive settings. However, you can set an Exclude Calendar in combination
with either of these Date options.

Setting the Run Days Option

You can define a job to run one or more days a week.

■ To define your job to run on one or more days of the week:

Select Run Days radio, and then click the check boxes 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 Run Days radio, and then click All.

■ To clear the selected days:

Click None.

Defining Jobs Using the Job Editor 7–19

Setting Date and Time Dependencies

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 Run Calendar radio, 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 Exclude Calendar radio, and then select a calendar name from the
Exclude Calendar drop-down list.

■ To modify an existing calendar or create a new calendar :

Click Edit Calendars. This action opens the Calendar Editor.

For information on using the Calendar Editor, see the chapter “Calendar Editor,”
in this guide.

Setting Time Starting Conditions

After you set the date condition, you must set a time starting condition. The time
starting condition indicates that Unicenter AutoSys JM should run the job at that
time, or times, on the days or dates on which the job is defined to run.

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

7–20 User Guide

 Setting Date and Time Dependencies

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.

Note: If a job runs daily at the same time (example: 12:00) and you EDIT this job
definition and save this job at (11:59), the job will not run today but will run
tomorrow at (12:00).

When a start time job definition is written to the database within “one minute” of
the current run time, the start time will be placed in the future, meaning
tomorrow. However, if the start time is two minutes or greater from the current
save time the job will run today.

Setting Time Zones

You can base the time settings for a job on a specific time zone. To do this, 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 the
chapter “JIL/GUI Job Definitions,” in the Unicenter AutoSys Job Management
for Windows and UNIX Reference Guide.

Defining Jobs Using the Job Editor 7–21

Setting Date and Time Dependencies

Example on Setting Date and Time Dependencies

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

To modify the test_run job to add time and date dependencies:

Follow these steps using the open Job Editor.

1. Choose File, Open.

The Open dialog opens.

2. In the Open dialog, enter test_run in the Job Name field, and then click OK.

A Job Editor opens with the test_run job definition.

3. Click the Date/Time tab to bring it to the front.

4. Click the Date/Time Conditions checkbox to enable the fields on this tab.

5. Select the Run Days radio button and single-click the Monday, Wednesday,
and Friday checkboxes. You can toggle the day check boxes on and off; they
are not mutually exclusive.

6. Select the Times of Day radio button, then enter the following times (in a 24
hour format) in the enabled field:
10:00, 14:00

Note: The times do not have to be enclosed in quotes when they are entered
in the Job Editor, unlike jobs entered using the Job Information Language
(JIL).

7. Choose File, Save.

A confirmation dialog is displayed to indicate the next start time.

7–22 User Guide

 Setting Date and Time Dependencies

8. Click OK to dismiss the confirmation dialog.

After the definition is written to the database, another confirmation dialog

displays.

9. Click OK to dismiss the second confirmation dialog.

The Job Editor Time/Date tab should look similar to the following illistration.
Leave the Job Editor open to use in the next example.

Defining Jobs Using the Job Editor 7–23

Deleting Jobs

Deleting Jobs
You can use the Job Editor to delete job definitions from the database. You can
delete any jobs, regardless of type, in the same way. To delete a job definition,
however, you must be either the owner of the job or the 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 the following
illistration.

2. Ensure that you are operating on the correct Instance. Then, in the Pattern
field, enter a name, partial name with the percent (%) 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 Ctrl and click
each job. You must select at least one job.

7–24 User Guide

 Deleting Jobs

4. Click OK.

A confirmation dialog displays.

5. Click OK to close the dialog and delete the jobs.

Note: If you have a job open, and you delete it using the Delete Jobs dialog, it
will still be in the Job Editor. If you change any setting and try to open another
definition, you are asked if you want to save the current (deleted) definition. If
you choose to save it, the job definition is written to the database (as if it is a new
definition).

Notes on Deleting a Box Job

When using the Job Editor to delete a box job, Unicenter AutoSys JM 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 the chapter
“Defining Jobs Using JIL,” in this guide.

Defining Jobs Using the Job Editor 7–25

Specifying One-Time Job Overrides

Specifying One-Time Job Overrides

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

Setting Job Overrides

To enter a onetime 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.

■ On the Basic 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 tables in Enabled Job Editor Fields for One-time Overrides in
this chapter.

3. Use the Job Editor to specify overrides. Enter new values into the fields, or
enter NULL to turn off the set value.

Note: To specify a date or time override, bring the Date/Time tab to the
front and select one of the choices from the drop-down list. This action will
enable the appropriate fields.

4. Choose File, Save.

When the modified definition is written to the database, a confirmation

dialog is displayed.

5. Click OK to dismiss the dialog.

7–26 User Guide

 Specifying One-Time Job Overrides

Notes on One-Time Overrides

Job overrides are applied for the next run of the job only. If a RESTART event is
generated because of system problems, Unicenter AutoSys JM 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.

Onetime 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
tables in Enabled Job Editor Fields for Onetime Overrides in this chapter.

Note: The maximum number of job restarts after system or network failures is
specified in the Max Restart Trys field on the Administrator event processor
screen.

Defining Jobs Using the Job Editor 7–27

Specifying One-Time Job Overrides

Deleting One-Time Overrides

To delete the onetime 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 tab.

■ Choose File, Delete Overrides.

Both of these actions display 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

The tables in this section list the fields that are enabled for one-time overrides.

The following table lists the Job Editor fields for command job overrides:

Tab Fields
Basic ■ 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)

7–28 User Guide

 Specifying One-Time Job Overrides

Tab Fields
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

The following table lists the Job Editor fields for box job overrides:

Tab Fields
Basic ■ Dependencies

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

Defining Jobs Using the Job Editor 7–29

Specifying One-Time Job Overrides

The following table lists the Job Editor fields for file watcher jobs:

Tab Fields
Basic ■ File to watch

■ Dependencies

■ Send To Machine

■ Time interval (secs) to determine steady state

■ Minimum file size (in bytes)

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

Resource/Profile ■ Job Environment Profile

7–30 User Guide

 Chapter

Defining Jobs Using JIL

8
This chapter describes how to define jobs using the Job Information Language or
JIL. It also provides information about creating various types of jobs. It discusses
changing and deleting a job, and how to set time dependencies. An example JIL
script is provided.

Job Information Language (JIL)

Job Information Language JIL) is a scripting language which provides a way to
specify how 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 Instance
Command Prompt window, which is located in the instance’s program group.
This window sets several environment variables that are needed to run the
commands.

Defining Jobs Using JIL 8–1

Job Information Language (JIL)

JIL Syntax Rules

When writing a JIL script, you must follow the syntax rules listed below.

Rule 1

Each sub-command uses the following form:

sub_command: job_name

where:

sub_command Is a sub-command.

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

For more information on JIL Sub-commands see the section JIL Sub-commands,
in this chapter.

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.

8–2 User Guide

 Job Information Language (JIL)

Rule 5

Legal value settings can include any of the following characters: uppercase and
lowercase letters, hyphens, underscores, numbers, colons (if the colon is escaped
with quotes or a preceding backslash), and the at 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 a forward

slash and astrisk (/*) and ending it with a astrisk and a forward slash (*/)
may be used; this allows comments to span multiple lines. The following is
an example:
/* this is a comment */

Defining Jobs Using JIL 8–3

Job Information Language (JIL)

JIL Sub-commands

JIL sub-commands are used to create, modify, override, or delete a job definition.
These sub-commands are listed in the following table.

Primary JIL Sub-command Definition

insert_job Add a new job.

update_job Edit fields on an existing job.

delete_job Delete an existing job from the 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

As stated earlier, a completed JIL script is called a job definition. This job
definition must be submitted to the database before the job it defines can be run.
You can submit a job to the database using one of the following methods (at the
Instance Command Prompt window that is associated with the instance for
which you are defining this job):

■ Submit the job 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 Command Prompts
jil>>

To exit interactive mode, enter exit at the prompt, or press Ctrl+d.

Both of these methods are analogous to saving a job definition in the GUI, using
the Job Editor.

8–4 User Guide

 Creating a Simple Command Job

Running JIL

After a job definition has been submitted to the 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 the chapter
“Commands,” in the Unicenter AutoSys Job Management for Windows and
UNIX Reference Guide.

Creating a Simple Command Job

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 following:
insert_job: test_run
job_type: c /*(optional, it is the default) */
machine: tibet
command: "C:\MYAPPS\DOREPORTS.BAT"

This JIL script instructs Unicenter AutoSys JM:

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

Defining Jobs Using JIL 8–5

Creating a File Watcher Job

Creating a File Watcher Job

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 following:
insert_job: EOD_watch
job_type: f
machine: tibet
watch_file: "C:\tmp\EodTransFile"
watch_interval: 60
watch_file_min_size: 50000

This JIL script instructs Unicenter AutoSys JM:

■ To add a new job named “EOD_watch”.

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

■ To run the job on the client machine named “tibet”.

■ To watch for a file named “EodTransFile” in the C:\tmp directory (this file
will contain end of day transactions).

■ Check the file every 60 seconds.

■ Determine if the file has reached the minimum file size of 50,000 bytes.

Until the minimum file size of 50,000 bytes has been reached, the file will not be
considered as complete. When the file reaches this minimum size and does not
change between check intervals (60 seconds in this example) it is considered
complete. When this occurs, the File Watcher Job will end with a SUCCESS
condition.

8–6 User Guide

 Creating a Dependent Command Job

Creating a Dependent Command Job

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_post
job_type: c
machine: tibet
condition: success(EOD_watch)
command: %HOMEPATH%\POST.EXE

This JIL script instructs Unicenter AutoSys JM:

■ To add a new job named “EOD_post”.

■ That the new job will be a Command Job.

■ To run the job on the client machine named “tibet”.

Defining Jobs Using JIL 8–7

Creating a Dependent 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 Windows 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 program group.)

Note: The job’s execution environment automatically includes NT system

environment variables, but Windows 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 Windows, 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
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 the section Job Profiles in
the chapter “Jobs,” in this guide. For information on the profile job attribute,
see the chapter “JIL/GUI Job Definitions,” in the Unicenter AutoSys Job
Management for Windows and UNIX Reference Guide.

8–8 User Guide

 Creating a Box

Creating a Box
Box Jobs are a convenient way to start multiple jobs. When you put jobs in a box,
you only have to start a single job (the box) in order for all the jobs in the box to
start running.

Assume you want to schedule a group of jobs to all start running once the File
Watcher completes successfully. Rather than make each job dependent on the
File Watcher, you can create a box that is dependent on the File Watcher, and
place all of the jobs in the box.

Now you will create a box, then change the job you just created to put it in the
box, and then make it no longer individually dependent on the File Watcher. The
JIL script required to define a Box Job named “EOD_box” is given following:
insert_job: EOD_box
job_type: b
condition: success(EOD_watch)

This JIL script instructs Unicenter AutoSys JM:

■ 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 the chapter “Box Job Logic,” in this guide.

Defining Jobs Using JIL 8–9

Changing a Job

Changing a Job
To place an existing job in a box, you need to change the “EOD_post” Command
Job that was created previously. 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 respecify any of the attributes that need to remain the
same. So, in the example below, you’ll use the update method. The JIL script
required to change the “EOD-post” job and to put it in the “EOD_box” is given
following:
update_job: EOD_post
condition: NULL
box_name: EOD_box

This JIL script instructs Unicenter AutoSys JM:

To update the job named “EOD_post”.

1. Remove the starting condition from the job definition, since the job will
inherit the starting condition of the box in which it is placed.

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

8–10 User Guide

 Setting Time Dependencies

Setting Time Dependencies

The “test_run” job you specified at the beginning of the chapter has no starting
conditions. Therefore, it will only run if it is started using the sendevent
command. To set the job to run automatically on certain days at a certain time,
such as 10:00 a.m. and 2:00 p.m. on Mondays, Wednesdays, and Fridays, you
would modify the job using this JIL script:
update_job: test_run
date_conditions: y
days_of_week: mo, we, fr
start_times: "10:00, 14:00"

This JIL script instructs Unicenter AutoSys JM:

1. To update the job named “test_run”.

2. Activate the conditions based on date.

3. Set the job to run on Mondays, Wednesdays, and Fridays.

4. 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 following:
start_times: 10\:00, 14\:00

Additional Time Setting Features

If you wanted the time settings for the job to be based on a specific time zone,
you would use the timezone attribute. If you specify a time zone that includes a
colon, you must quote the time zone name like:
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

Defining Jobs Using JIL 8–11

Deleting a Job

Alternatively, you could have specified a custom calendar specifying the days on
which the job was not to be run, “holiday_cal”, using the following JIL
statement:
exclude_calendar: holiday_cal

If you wanted the job to run at specific times every hour, as opposed to specific
times of day, the minutes past every hour could have been specified. For
example, to run a job at a quarter after and a quarter before each hour, use the
following JIL statement:
start_mins: 15, 45

Deleting a Job
Now you will delete the “test_run” job, which you specified at the beginning of
this chapter. To delete the “test_run” job, enter the following JIL sub-command:
delete_job: test_run

The delete_job sub-command checks the job_cond table and notifies you if
dependent conditions for the deleted job exist. This functionality only works
when JIL is in the job verification mode, which is the default.

Deleting a Box Job

To delete a box, and recursively delete every job in that box use the delete_box
sub-command, like:
delete_box: EOD_box

To delete a box, but leave its contents intact use the delete_job sub-command on
the box, like:
delete_job: EOD_box

Using JIL, there are a number of other attributes which you can configure. These
attributes are described in detail in the chapter “JIL/GUI Job Definitions,”in the
Unicenter AutoSys Job Management for Windows and UNIX Reference Guide.
This reference chapter provides complete information on all job attributes
specified using JIL.

8–12 User Guide

 Specifying One-Time Job Overrides

Specifying One-Time Job Overrides

Using JIL, you can specify a job override for the next run of a particular job. In
other words, the next time a job runs, you can change its behavior. Job overrides
are applied only once. If a RESTART event is generated because of system
problems, Unicenter AutoSys JM 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 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

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

Defining Jobs Using JIL 8–13

Specifying One-Time Job Overrides

Setting Job Overrides

To set job overrides, you use the override_job sub-command; you only need to
specify those attributes that you want to override. Using this command, you can
also temporarily delete a job attribute. For example, if you wanted to run a job
named “RunData” with no conditions (where some had been previously
specified) and you wanted to output the results to a different output file, you
would enter a JIL script like:
override_job: RunData
condition: NULL
std_out_file: "C:\tmp\SpecialRun.out"

To cancel the job overrides specified in the script above, you would enter the
following JIL script:
override_job: RunData delete

Note: Once you have submitted a JIL script to the 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 (for example, the first over_num) remains stored in the
“overjob” table in the database.

8–14 User Guide

 Example JIL Script

Example JIL Script

The following is a full example of an JIL script. It incorporates the creation and
use of a Command Job, a File Watcher Job, and a Box Job. The following is a
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_Download
job_type: b
date_conditions: yes
days_of_week: all
start_times: "02:00"
insert_job: Watch_4_file
job_type: f
box_name: Nightly_Download
watch_file: "C:\DOWNLOAD\MAINFRAME\SALES.RAW"
machine: gateway
insert_job: filter_data
job_type: c
box_name: Nightly_Download
condition: success(Watch_4_file)
command: filter_mainframe_info
machine: gateway
std_in_file: "C:\DOWNLOAD\MAINFRAME\SALES.RAW"
std_out_file: "C:\DOWNLOAD\MAINFRAME\SALES.SQL"
std_err_file: "C:\LOG\FilterMFLog.err"
insert_job: update_DBMS
job_type: c
box_name: Nightly_Download
condition: success(filter_data)
machine: gateway
command: isql -U mutt -P jeff
std_in_file: "C:\DOWNLOAD\MAINFRAME\SALES.SQL"

An example of the output generated by the autorep command for the previously
shown job definition is provided in the Examples section for the autorep
command in the chapter “Commands,” in the Unicenter AutoSys Job
Management for Windows and UNIX Reference Guide.

Defining Jobs Using JIL 8–15

Chapter

Calendar Editor
9
This chapter describes how to create calendars by using the Calendar Editor and
how to use the calendars you create with jobs.

The Calendar Editor provides a method of defining and maintaining 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, preexisting 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 9–1

Using Defined Calendars

Using Defined Calendars

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

Scheduling Jobs with Calendars

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

■ 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, and 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 check box.

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 the Run Calendar radio
button.

■ For a job that you do not want to start on holidays, click the Exclude
Calendar check box.

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.

9–2 User Guide

 Using Defined Calendars

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. By default, if no start time is specified, calendar-
scheduled jobs start at midnight.

Note: You can only assign times to calendars when using the command-line
calendar definition tool, autocal_asc. For information, see autocal_asc in the
chapter “Commands,” in the Unicenter AutoSys Job Management for
Windows and UNIX Reference Guide.
■ 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, Unicenter AutoSys JM 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 the chapter “Defining Jobs Using the
Job Editor,” in this guide. For information about these attributes, see their
reference pages in the chapter “JIL/GUI Job Definitions,” in the Unicenter
AutoSys Job Management for Windows and UNIX Reference Guide.

Calendar Editor 9–3

Starting the Calendar Editor

Starting the Calendar Editor

To start the Calendar Editor:

1. Open the GUI Control Panel from the Graphical Interface icon in the
AutoSys program group.

2. Click the Calendar Editor button in the GUI control panel. This opens the
Calendar Editor:

9–4 User Guide

 Using the Calendar Editor Interface

Using the Calendar Editor Interface

The Calendar Editor is divided into the following regions:

■ Menu Bar

■ Navigation Controls

■ Calendar Display

Using the Menu Bar

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

File Menu

The File menu contains the following options:

New
Displays the New Calendar dialog in which you enter the Instance and new
Calendar Name, then click OK. The new Calendar Name must be a unique
job name for the specific instance. The name must be from 1 to 30
alphanumeric characters, and white space indicates the end of the name.
Embedded spaces and tabs are illegal. When you click OK, an empty
Calendar Editor displays.

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 database, using
its current name. The first time you save a calendar, this option displays the
Save As dialog.

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.

Calendar Editor 9–5

Using the Calendar Editor Interface

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

New Calendar Editor

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

Exit
Exits the application.

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

9–6 User Guide

 Using the Calendar Editor Interface

Edit Menu

The Edit menu contains the following options:

Apply Rule
Displays the Term Calendar Rule dialog in which you can set multiple dates
using a variety of rule options. For more information, see Applying Rules to
Calendars in this chapter.

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

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

Utilities Menu

The Utilities menu contains the following option:

Job Definition Reference List

Displays the Job Definition Reference List dialog, which contains a list of all
the jobs that reference the calendar you are currently editing, either as their
Run Calendar or Exclude Calendar. This list is read only, and it indicates
which jobs will be affected by any changes you make to the current calendar.
For more information, see Using the Job Definition Reference List in this
chapter.

Note: When you update a calendar, Unicenter AutoSys JM recomputes the

starting times for all jobs that use that calendar.

Preferences Menu

The Preferences menu contains the following options:

Months in View
Displays a submenu that allows you to choose how many months are
displayed on one calendar screen. You can choose one of the following
options: One, Four, Six, Nine, or Twelve.

Calendar Editor 9–7

Using the Calendar Editor Interface

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.

Note: The Calendar Editor allows you to set dates in the current year that have
already past, if you do so, however, Unicenter AutoSys JM ignores these dates.

9–8 User Guide

 Using the Calendar Editor Interface

Help Menu

The Help menu contains the following options:

Contents
Displays the table of contents for the Unicenter AutoSys JM Help.

About
Displays the Calendar Editor version number.

Using the Navigation Controls

The Navigation controls area of the window contains the following:

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.

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.

■ 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 darkened box surrounds the date with focus.

Calendar Editor 9–9

Using the Calendar Editor Interface

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 database,
you are prompted that conflicts exist. If you choose to ignore the prompt and
save anyway, the Conflicting dates are lost; they are not written to the database.
All other date states are saved.

Instance Area

To the right of the Conflicts area is the Instance drop-down list. When you select
an instance, the Calendars drop-down list contains the appropriate defined
calendars.

Calendars Area

The Calendars drop-down list contains all of the defined calendars for the
selected instance (in the Instance drop-down list).

9–10 User Guide

 Using the Calendar Editor Interface

Using the Calendar Display

The Calendar Editor by default displays six months of the calendar currently
being edited. You can change the display from the Preferences, Months in View
menu.

■ To scroll to the next six months:

Click in the lower portion of the scroll bar.

■ To advance a month at a time:

Click the down arrow on the scroll bar.

■ To move to the previous six months (if it is part of the calendar):

Click in the upper portion of the scroll bar.

■ To move back a month:

Click the up arrow on the scroll bar.

The title bar of the window displays the name of the current calendar.

Date States

You can set the dates on the calendar to one of the following states:

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

You can cycle through these three states by clicking a date multiple times. If you
click, the date’s state is Selected; if you click again, the date’s state is Blocked;
and if you click the date a third time, the date’s state is Unset. The current state
of each date is indicated by its color, as indicated from the Preferences, Colors
submenu.

Calendar Editor 9–11

Using the Calendar Editor Interface

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 in this
chapter.

Note: Calendars created with the Calendar Editor are stored in the 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 database.

9–12 User Guide

 Creating and Modifying Calendars

Creating and Modifying Calendars

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

Creating a Calendar

This example demonstrates how to create a calendar containing 2003 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 2003 holidays:

1. Choose File, New.

A New Calendar dialog is displayed.

2. In the New Calendar dialog, select the Instance.

3. From the Preferences menu, select Years, and select Two. Then, using the
scroll bar, scroll down to 2003 in the calendar display area.

4. In the Calendar Editor, select the holiday dates by clicking each date. If the
desired dates are not displayed, use the scroll bar to bring them into view.

5. Choose File, Save. Enter us_hol_03 then click OK in the Save As dialog.

Calendar Editor 9–13

Creating and Modifying Calendars

Your calendar will resemble the following illistration:

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.

9–14 User Guide

 Creating and Modifying Calendars

Opening an Existing Calendar

To open a saved calendar, do the following:

1. Choose File, Open.

The Calendar Selection dialog appears:

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 database for this instance.

In the Pattern field of the Calendar Selection dialog, you can specify any
string, including the percent (%) wildcard character, and click Search to list
those calendars whose names include the string. The default filter, “%,” lists
all of the calendar names.

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.

Calendar Editor 9–15

Creating and Modifying Calendars

3. Do one of the following:

■ Select a calendar in the list, and click OK. This action opens the calendar
and exits the Calendar Selection dialog.

■ Click Cancel to exit the Calendar Selection dialog without opening a

calendar.

9–16 User Guide

 Applying Rules to Calendars

Applying Rules to Calendars

Using the Term Calendar Rule dialog, you can apply rules to calendars. Instead
of selecting each date individually to set a state, you can apply a rule to set the
state for multiple dates.

To open the Term Calendar Rule dialog from the Calendar Editor:

1. From the Edit menu, choose the Apply Rule option. This action opens the
Term Calendar Rule dialog:

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

Rule Specification
The top portion of the dialog.

Apply Rescheduling Rule

The lower portion of the dialog.

Calendar Editor 9–17

Applying Rules to Calendars

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.

Using the Rule Specification Area

The Rule Specification region provides a wide variety of options to specify the
dates in the selected calendar that you want to affect and to what states those
dates should be set. This region consists of the following three areas:

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.

To specify and apply a rule for a calendar:

Select the appropriate Action, Date Range, Occurrences, Day, and Period,
and click Apply, or 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. You can only select only one of these
actions:

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.

9–18 User Guide

 Applying Rules to Calendars

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 sub areas: Occurrences,
Day, and Period. The settings you select in these three areas must make sense
together. For usage examples, see Date Selection Rule Examples.

Occurrences
Allows you to specify the occurrence of a day for which the rule should be
applied (for example, First, Last, Every nth). Select one or more options by
clicking the corresponding check box.

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
Days. If you select Specific Days, you must also select one or more of the
specific days of the week.

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

You could choose the First/Monday Quarterly to indicate the first Monday of
each quarter.

Calendar Editor 9–19

Applying Rules to Calendars

If you select the Calendar Period option, only the dates specified in the indicated
calendar are used when applying the rule. You can enter the calendar name
directly, or you can click the Calendar drop-down list button to display a list of
existing calendars from which you can choose a calendar for the period.

Date Selection Rule Examples

The examples in this section illustrate the use of the Date Selection Rule options.

Note: When you first start applying rules to your calendars, we recommend 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 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.

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 sub area, select either the Third option, or type “3” in the
nth option field.
5. In the Day sub area, select Tuesday, which automatically selects the Specific
Days option.

6. In the Period sub area, select Monthly.

7. Click OK to apply the rule to the calendar you are currently editing, and to
close the dialog.

Example Two Block every holiday date and prevent those days from being scheduled:

Using the calendar named us_hol_03, which you defined, 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.

9–20 User Guide

 Applying Rules to Calendars

4. In the Occurrences sub area, select Every.

5. In the Day sub area, leave the default selection of Day.

6. In the Period sub area, select Calendar and, using the drop-down list, select
the us_hol_03 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_03 calendar are set to Blocked. Use the open Term Calendar Rule
dialog in the next example.

Example Three Continuing with the above example, you want to change the state of every
Thursday to Selected. To do this, follow these steps, using the open Term
Calendar Rule dialog:

1. In the Action area, select Set Dates.

2. In the Date Range area, do not change the default All Day in Range setting.

3. In the Occurrences sub area, leave Every selected.

4. In the Day sub area, select Thursday, which also selects the Specific Days
radio button.

5. In the Period sub area, 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_03
calendar. As a result, you could reset these conflicting dates manually, by
clicking them until they are Unset, Selected, or Blocked, or you could specify a
rescheduling rule to accommodate this type of conflict (as described in
Rescheduling Rule Example in this chapter). Rescheduling Rules are described in
Using the Rescheduling Rule Area.

Calendar Editor 9–21

Applying Rules to Calendars

Using the Rescheduling Rule Area

The Rescheduling Rule region allows you to specify how date conflicts should be
resolved when applying a rule.

To specify a rescheduling rule using the Term Calendar Rule dialog:

1. Create the rule in the Date Selection Rule area by selecting the Action, Date
Range, Occurrences, Day, and Period.

2. Select the Apply Rescheduling Rule check box. This action enables the Move
Direction and To Day options.

3. Select the appropriate Move Direction and To Day options. These settings
indicate how the Conflicting dates should be rescheduled.

4. Click OK.

If you intend to apply a Rescheduling Rule, you should set it up at the same time
you set up the Date Selection Rule, rather than wait for conflicts to occur.

Note: Conflicts can also occur if a date is both Selected and Blocked. When a
conflict occurs, the selected state is moved when rescheduling, and the Blocked
date is maintained.

Move Direction Area

You can select one of the following Move Direction options:

To Previous
Moves the Selected state backward in the calendar.

To Following
Moves the Selected state forward in the calendar.

9–22 User Guide

 Applying Rules to Calendars

To Day Area

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

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.

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” previously discussed):

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 sub area, leave Every selected.

4. In the Day sub area, select Thursday, which also selects the Specific Days
radio button.

5. In the Period sub area, select No Period.

6. Click the Apply Rescheduling Rule check box. 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.

Calendar Editor 9–23

Combining Existing Calendars

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.

Note: Many conflict dates can be rescheduled to the same new date. For
example, if you block all weekend dates, then apply a rule to set every day, with
rescheduling to the previous weekday, both the Saturday and Sunday conflicts
will be resolved to the preceding Friday. If you want separate runs for Saturday
and Sunday, turn off the Rescheduling Rule and resolve the conflicts manually.

Combining Existing Calendars

You can combine calendars in a number of ways. For example, you can create a
calendar that includes all the dates that are in either one calendar or another.
Likewise, you can create a calendar that includes all the dates that are in one
calendar but not in another. In fact, you can combine any number of calendars in
these ways.

Combining Calendars Example

For example, you could combine your existing us_hol_03 calendar with your
company holiday calendar. To do this you must first create a calendar named
co_hol_03, 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.

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

4. From the Edit menu, choose the Apply Rule option.

9–24 User Guide

 Combining Existing Calendars

5. In the Term Calendar Rule dialog, select Set Dates in the Action area, Every
in the Occurrences area, and Day in the Day area.

6. In the Period sub area, click the Calendar radio button, and select us_hol_03
from drop-down list.

7. In the Term Calendar Rule dialog, click Apply.

8. Repeat steps 5 and 6, except select the co_hol_03 calendar from the drop-
down list. Then, click OK to dismiss the Term Calendar Rule dialog.

9. From the File menu, select the Save option.

10. Enter the calendar name, holidays and click OK in the Save As dialog.

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.

Calendar Editor 9–25

Using the Job Definition Reference List

Using the Job Definition Reference List

From the Calendar Editor Utilities menu, you can open the Job Definition
Reference List. You can use the Job Definition List to see what jobs will be
affected by any changes you make to the current calendar.

To open the Job Definition Reference List dialog:

1. Choose Utilities, Job Definition List.

This action opens the Job Definition Reference List dialog:

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.

9–26 User Guide

 Importing and Exporting Calendars

Importing and Exporting Calendars

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.

Importing Calendar Text Files

You can import calendars contained in ASCII text files into the 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/2003
01/15/2003
02/01/2003
02/15/2003
03/01/2003

calendar: Q1holidays
01/01/2003

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: Unicenter AutoSys JM 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 9–27

Importing and Exporting Calendars

Exporting Calendars

You can export all calendars defined in the 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 file name to which the calendar definition should
be saved.

When you use the Export All option, all the calendars in the 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.

9–28 User Guide

 Chapter

Load Balancing and Queing Jobs

10
This chapter describes the use of real and virtual machines in the 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
In the 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 Unicenter AutoSys JM can
access it.

■ Undergone a client software installation (and is licensed) so that Unicenter

AutoSys JM can run jobs on it.

Load Balancing and Queing Jobs 10–1

Virtual Machines

The above two conditions are required for a real machine to run jobs. However,
for Unicenter AutoSys JM to perform intelligent load balancing and queuing
while executing jobs, it needs to know the relative processing power of the
various real machines. Unicenter AutoSys JM provides both load balancing and
queuing by way of the logical construct called virtual machines.

Virtual Machines
A virtual machine is comprised of one or more real machines, in whole or in part
(or a combination of both). All real machines within a virtual machine must be of
the same type, either Windows or UNIX. Virtual machines cannot be a mix of
both UNIX and Windows machines. By defining virtual machines to Unicenter
AutoSys JM , and then submitting jobs to run on those machines, you can
specify:

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

■ That Unicenter AutoSys JM automatically execute those policies in a multi-

machine environment.

Defining Machines
Define both real and virtual machines by using machine attribute statements
within a JIL script. The following JIL sub-command defines a real or virtual
machine:
insert_machine: machine_name

The following JIL machine attributes are used when defining machines:

Machine Attribute Description

type Specifies a machine type, which can be one of the
following:

■ r for UNIX real

■ v for UNIX virtual

■ n for Windows (Real or Virtual)

10–2 User Guide

 Specifying Machine Load (max_load)

Machine Attribute Description

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 if they meet one of the following criteria:

■ Require a max_load or factor attribute to be set for them.

■ 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 Unicenter AutoSys JM 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 the chapter “JIL Machine Definitions,” in the Unicenter AutoSys
Job Management for Windows and UNIX Reference Guide.

Specifying Machine Load (max_load)

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.

Load Balancing and Queing Jobs 10–3

Specifying Machine Load (max_load)

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

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.

10–4 User Guide

 Specifying Machine Load (max_load)

Using max_load and factor

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

Load Balancing and Queing Jobs 10–5

Machine Definitions

Machine Definitions
Unicenter AutoSys JM 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 Windows, however, the type attribute is required. Compare the following
definitions.

Real UNIX Real Windows

insert_machine: toad insert_machine: tiger

max_load: 100 type: n

factor: .8 max_load: 100

factor: .8

Virtual UNIX Virtual Windows

insert_machine: pond insert_machine: jungle

machine: toad type: n

machine: frog machine: tiger

machine: monkey

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.

10–6 User Guide

 Defining a Real Machine

Defining a Real Machine

To define a real machine

1. Assign a machine name, this must be its hostname.

2. Assign a machine type: r for real UNIX or n for Windows.

3. Optionally, assign a max_load and a factor attribute value.

The following illustration defines a real UNIX machine named “jaguar” with a
max_load of 100 and a factor of 1.0.
insert_machine: jaguar
type: r 100 max_load
max_load: 100 1.0 factor
factor: 1.0
jaguar

To define a real Windows machine named “jaguar”, enter the following JIL
statements:
insert_machine: jaguar
type: r
max_load: 100
factor: 1.0

Deleting Real Machines

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

Load Balancing and Queing Jobs 10–7

Defining a Virtual Machine

Defining a Virtual Machine

To define a virtual machine

1. Assign a machine name.

2. Assign a machine type: v for virtual UNIX or n for virtual Windows.

3. Specify the real machines that will make up the virtual machine.

The following defines a virtual UNIX machine named “modena”, which is

composed of two real UNIX machines named “ferrari” and “lambo”. Because the
real machines do not specify a max_load and factor, they will have the default
values for these attributes: a factor of 1.0 and unlimited load units.

insert_machine: modena
type: v modena
machine: ferrari ferrari lambo
machine: lambo

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, the virtual machine will
use the max_load and factor attributes specified for them.)
insert_machine: fiat
type: r
max_load: 100
factor: 1
insert_machine: lotus
type: r
max_load: 80
factor: .9
insert_machine: capri
type: v
machine: fiat
machine: lotus

10–8 User Guide

 Defining a Virtual Machine

The following illustration defines a virtual NT machine named “garden”

comprised of two real Windows machines named “rose” and “lily”.
Insert machine: garden
type: n
machine: rose
machine: lily

The following JIL statements define the two real NT machines.

insert_machine: rose
type: n
max_load: 100
factor: 1
insert_machine: lily
type: n
max_load: 80
factor: .9

The following JIL statements define a virtual machine named “mustang” which
is composed of slices, or subsets, of the real machines named “fiat” and “lotus.”
Even though the real machines have been previously defined, only the reduced
load portion (or slices) will be used in the virtual machine “mustang.”
insert_machine: mustang
type: v mustang
machine: fiat
max_load: 10 fiat lotus
machine: lotus 10 9
max_load: 9

Load Balancing and Queing Jobs 10–9

Defining a Virtual Machine

Deleting Virtual Machines

To delete a real machine component of a virtual machine, you specify the virtual
machine and the desired component. The following JIL statements delete only
the real machine named “lambo” found within the virtual machine named
“modena”:
delete_machine: modena
machine: lambo

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.

10–10 User Guide

 Load Balancing

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

When a job is ready to start, Unicenter AutoSys JM will determine which of the
specified machines is best suited to run the job. The following JIL example shows
the job definition statements for such a job:
insert_job: test_load
machine: modena
command: echo "Test Load Balancing"
job_load: 50
priority: 1

where:

modena Is a virtual machine.

Alternatively, if all machines are Windows 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, Unicenter AutoSys
JM would choose the machine to run on based solely on available processing
power. To accomplish this, Unicenter AutoSys JM 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 (for example, the machine with
the most relative processing cycles available).

In the example machine list previously shown, the factor attribute is not
specified for either machine, and thus the default factor value for each machine
is 1.0.

Load Balancing and Queing Jobs 10–11

Load Balancing

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 Unicenter AutoSys JM 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.

The following illustration shows three machines having different capabilities,

which are grouped into a virtual machine.

italia

ferrari alfa_romeo lambo

1.0 0.8 0.3 factors

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

insert_machine: italia
machine: ferrari
factor: 1
machine: alfa_romeo
factor: .8
machine: lambo
factor: .3

To start a job on this virtual machine, simply specify “italia” as the machine
attribute for the job. The Event Processor will perform the necessary calculations
to determine on which machine to run the job, and reflect these calculations in its
output log. The output is similar to:
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

10–12 User Guide

 Force Starting Jobs

Note that even though the “ferrari” usage was less than “alfa_romeo”, “ferrari”
was picked because of the factors (78 * 1.0 > 80 * 0.8). Thus, the factors weigh
each machine to account for variations in processing power.

Force Starting Jobs

If you force start a job, Unicenter AutoSys JM 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, Unicenter AutoSys JM 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.

Note: If you FORCE_START a job that has a status of ON_ICE or ON_HOLD,

upon completion (either success or failure), the status/condition does not change
back to the previous condition.

For example: You scheduled Job-1 to run every Monday at 3:00 A.M, however,
on Sunday you placed this job ON_HOLD. If you FORCE_START Job-1 on
Wednesday at 2:00 P.M., Job-1 will run to completion (either success or failure),
and then run again as scheduled on Monday at 3:00 A.M.

Queuing Jobs
Queuing jobs in Unicenter AutoSys JM 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 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 environment.

Load Balancing and Queing Jobs 10–13

Queuing Jobs

Queuing and Simple Load Limiting

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, Unicenter AutoSys JM will first determine whether each machine has
sufficient available load units before running the job. If each real machine has
sufficient load units, Unicenter AutoSys JM 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 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, 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.

Using a previously defined machine named “fiat” with a max_load of “100”, a

simple queuing example would be as follows:
insert_job: jobA
machine: fiat
job_load: 80
priority: 1
insert_job: jobB
machine: fiat
job_load: 90
priority: 1

If “jobA” was running when “jobB” started, “jobB” would be in a QUE_WAIT

state until “jobA” completed and “jobB” could run.

10–14 User Guide

 Queuing Jobs

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

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.

Note: The constructs of job loads and machine loads are merely conventions that
you set up, and that are enforced. If you do not indicate 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.

Load Balancing and Queing Jobs 10–15

Queuing Jobs

The following illustration shows a situation where a machine has 80 load units,
and multiple jobs are waiting to start. In this example, “JobB” and “JobC” are
executing while “JobA” and “JobD” are “queued” (in the QUE_WAIT state),
waiting for available load units. The numbers in the figure indicate the job_load
assigned to each job, and the max_load of the machine. The JIL statements
provided below define the machine and the jobs.

QUE_WAIT EXECUTE

JobA JobB
50 50 80 max_load

JobD JobC
30 30

insert_machine: ferrari
max_load: 80
insert_job: JobA
machine: ferrari
job_load: 50
priority: 60
insert_job: JobB
machine: ferrari
job_load: 50
priority: 50
insert_job: JobC
machine: ferrari
job_load: 30
priority: 80
insert_job: JobD
machine: ferrari
job_load: 30
priority: 70

In the previously shown illustration, “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.

10–16 User Guide

 Queuing Jobs

Subsets—Individual Queues

One variety of virtual machine can be considered a subset of a real machine.

Typically, this type of virtual machine is used to construct an individual queue
on a given machine. One use for this construct might be to limit the number of
jobs, of a certain type, that will run on a machine at any given time. For example,
you have created three different print jobs, but you want only one job to run on a
machine at a time. You can accomplish this by using a combination of the
max_load attribute for the virtual machine and the job_load attribute for the jobs
themselves.

The following illustration shows a virtual machine functioning as a queue. The

JIL statements to define the queue, called “ferrari_printQ” follow the graphic.
Note that “ferrari” is a real machine.

ferrari_printQ

ferrari

80 15

To implement the schema, you would first create the virtual machine named
“ferrari_printQ”, like:
insert_machine: ferrari_printQ
machine: ferrari max_load: 15

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

insert_job: Print1
machine: ferrari_printQ
job_load: 15
priority: 1
insert_job: Print2
machine: ferrari_printQ
job_load: 15
priority: 1
insert_job: Print3
machine: ferrari_printQ
job_load: 15
priority: 2

Using this definition, only one of the jobs would run on “ferrari” at one time,
since each job requires all of the load units available on the specified machine.

Load Balancing and Queing Jobs 10–17

Queuing Jobs

Load Units and Virtual Machines

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

Multiple Machine Queues

Virtual machines can also be constructed to allow subsets (or slices) of real
machines to be combined into one virtual machine. A possible need for this
would be if there were two machines that were print servers, on each of which
only one print job was to run at a time. The following illustration shows this
situation.

printQ
ferrari lambo

80 15 120 15

To implement the above illustration, you would first create the virtual machine
named “printQ”, then you would specify two real machines, “ferrari” and
“lambo” as shown in the following example:
insert_machine: printQ
type: v
machine: ferrari
max_load: 15
machine: lambo
max_load: 15

As a job is logically ready to start on printQ, Unicenter AutoSys JM 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, Unicenter AutoSys JM will determine the usage on each, and start the
job on the machine with the most available CPU resources.

10–18 User Guide

 User-Defined Load Balancing

User-Defined Load Balancing

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_free
machine: "C:\USERS\DEFAULT\PICK_MACHINE.BAT"
command: %HOME%\DEL_STUFF.BAT

At runtime, the "C:\USERS\DEFAULT\PICK_MACHINE.BAT" batch file is run

on the Event Processor machine. The standard output will be substituted for the
name of the machine, and the job will be run on that machine.

Note: If you specify a user-defined load balancing script in the machine

attribute, you cannot use the priority or job_load job attributes.

Load Balancing and Queing Jobs 10–19

 Chapter

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

Using the Scheduler Console

The Scheduler Console provides a sophisticated method of monitoring jobs from
multiple instances in real time. The Scheduler Console lets you view any jobs
that are defined, 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 Scheduler Console on the GUI Control Panel. This action opens a
window similar to the illistration following.

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 in this chapter.

Scheduler Console 11–1

Using the Scheduler Console

The following image is the Schedule Console:

The Scheduler Console has the following three areas:

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

Control area
The area below the menu bar that contains the drop-down list of defined
filters and the action buttons you have selected to display. You can populate
this “action area” with 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.

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.

11–2 User Guide

 Using the Scheduler Console

Using the Scheduler Console Menu Bar

At the top of the Scheduler Console is the menu bar, which contains the
following menus: File, Filters, Actions, Tools, Applications, Reports, Preferences,
and Help.

File Menu

The File menu has the following options:

New Unicenter AutoSys 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:

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 in this chapter.

Actions Menu

The Actions menu contains a list of actions that you can perform on the selected
jobs in the job list area. These are the Actions menu options:

Start Job
Starts the selected jobs if the Dependencies starting conditions are met. This
action ignores Date/Time starting conditions, but it does not ignore job
dependency starting conditions. You can only use this option to start top-
level jobs; do not use it on jobs in boxes. Choosing this option is equal to
sending a STARTJOB event.

Scheduler Console 11–3

Using the Scheduler Console

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

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.

For more information about any of these events, see sendevent in the chapter
“Commands” in the Unicenter AutoSys Job Management for Windows and
UNIX Reference Guide.

11–4 User Guide

 Using the Scheduler Console

Tools Menu

The Tools menu allows you to open 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 in this chapter.

Job Editor
Opens a Job Editor for the selected job. For information on the Job Editor, see
the chapter “Defining Jobs Using the Job Editor,” in this guide.

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 in this chapter.

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 in this chapter.

Applications Menu

The Applications menu has the following option:

Alarm Manager
Opens the Alarm Manager, which you can use to view alarms and change
their status from Open to Acknowledged or Closed. When you open the
Alarm Manager from the Scheduler Console, it contains the alarms for all
instances it can access. For information on the Alarm Manager, see the
chapter “Managing Alarms,” in this guide.

Scheduler Console 11–5

Using the Scheduler Console

Reports Menu

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

Job Detail Report

Opens the Job Detail Report tool for the selected job. This dialog displays a
realtime report of the job run information (in the format of the autorep
command output). For information, see Using the Job Detail Report Tool in
this chapter.

Preferences Menu

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

General
Opens the General dialog in which you can set the refresh interval (the
default setting is 60 seconds), the confirm action behavior, and the button
display. For information, see Using the General Dialog in this chapter.

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 in this chapter.

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 in this chapter.

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 in this chapter.

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 in this chapter.

11–6 User Guide

 Using the Scheduler Console

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 in this chapter.

Note: The Time Perspective affects the Start Time and Last Change display in
the summary area.

AutoRefresh
Indicates whether or not the Scheduler Console summary area should be
updated automatically. By default, AutoRefresh is selected (set to on). This
setting indicates that the Scheduler Console should be updated based on the
Refresh Interval setting in the General dialog. If you uncheck the
AutoRefresh option, setting it to off, the Console display is not updated
automatically. To update the display, you can check the AutoRefresh option,
or you can click the Refresh button (if you indicated to have the button in the
action area).

Help Menu

The Help menu contains the following options:

Contents
Displays the table of contents for the Unicenter AutoSys JM Help.

About
Displays the Scheduler Console version number.

Scheduler Console 11–7

Using the Scheduler Console

Using the Control Area

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 in this chapter).

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

– 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 in this chapter.

– 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 in this chapter.

Using the Summary Area

The summary area displays a list of all the jobs that are defined, subject to the
currently selected filter. The list of jobs in the summary area provides 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 Control
Panel Colors dialog, which you can open from the 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.

11–8 User Guide

 Using the Scheduler Console

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
in this chapter.

You can double-click on a job to open the Run Status Tool to view the job
information (see Using the Run Status Tool in this chapter).

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 in this chapter. When the
Scheduler Console is reading the database (refreshing or changing filters) an
asterisk appears at the end of the date time statement.

Scheduler Console 11–9

Using the Scheduler Console

■ To select a job:

Click the job in the summary area job list display.

■ To select contiguous multiple jobs:

Press and hold the shift key, click on the jobs at the end of a desired range 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 clicking a selected job deselects that job.

■ To deselect all the currently selected jobs:

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 in this chapter. In
addition, you can resize the titles by dragging the edges.

11–10 User Guide

 Defining Scheduler Console Filters

Defining Scheduler Console Filters

If you are opening the Scheduler Console for the first time, you will be prompted
to choose whether you want to open the Scheduler Console using the Default
Filter. The Default Filter includes all jobs, with all statuses, on all defined
machines, and for all locally defined (installed) instances.

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

Scheduler Console 11–11

Defining Scheduler Console Filters

Filters Editor Dialog

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

■ Names

■ Status

■ Machine/Instance

File Menu

The File menu has the following options:

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

11–12 User Guide

 Defining Scheduler Console Filters

Names Tab

Using the Filter Editor Names tab, you can select the jobs you want to view by
name. You can click one of the following radio buttons:

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

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.

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,” “Bad,” “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.

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.

Scheduler Console 11–13

Defining Scheduler Console Filters

Status Tab

From the Filter Editor Status Tab (shown in the following illistration), 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.

11–14 User Guide

 Defining Scheduler Console Filters

Machines/Instances Tab

From the Filter Editor Machine/Instance tab (shown in the following illistration),
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 check box 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.

Selecting Machines From the Machine or Instance list, you can choose one or several names to
or Instances include in the filter.

■ To specify Machines from the list:

Click the All Machines check box to uncheck it, and then select the machines
you want to include in the filter.

Scheduler Console 11–15

Defining Scheduler Console Filters

■ To specify Instances from the list:

Click the All Instances check box 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:

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 Ctrl key and click each name.

Using the Filter Editor

■ To define a filter:

1. Choose Filters, Filter Editor. This action opens a dialog similar to the one
shown in Defining Scheduler Console Filters in this chapter.

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 about changing the
settings, see Using the Summary Area Layout Dialog in this chapter.

11–16 User Guide

 Using Scheduler Console Tools

Using Scheduler Console Tools

The Tools menu contains the following options:

■ 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 the chapter “Defining Jobs Using the Job Editor,” in this
guide.

Scheduler Console 11–17

Using Scheduler Console Tools

Using the Job Dependencies Dialog

The Job Dependencies dialog allows you to view the defined Dependencies of
the selected job, and to move between the displayed dependent jobs to see their
defined Dependencies.

■ To open the Job Dependencies dialog:

Select a job, and choose Tools, Dependent Jobs. This action opens a dialog
like the one shown in the following illistration.

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.

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.

11–18 User Guide

 Using Scheduler Console Tools

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.

Scheduler Console 11–19

Using Scheduler Console Tools

Using the Run Status Tool

You can use the Run Status Tool to view comprehensive information about the
most recent run (or the current run) of the selected job.

To open the Run Status Tool:

■ Select a job, and choose Tools, Run Status Tool.

■ Double-click a job.

These actions open a dialog similar to the one shown in the Run Status Tool.

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.

11–20 User Guide

 Using Scheduler Console Tools

Run Status Tool Menu Bar

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

File Menu The File menu has the following options:

New Run Status Tool

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 Menu The Tools menu has the following option:

Send Event Tool

Opens the Send Event Tool for the selected job. Using this dialog, you can
send events, and you can cancel events that you have scheduled for a later
time. For information, see Using the Send Event Tool in this chapter.

Applications Menu The Applications menu contains the following option:

Job Editor
Opens a Job Editor for the current job. For more information, see the chapter
“Defining Jobs Using the Job Editor,” in this guide.

Options Menu The Options menu has the following option:

Adopt Session Context

Toggles the session context feature on or off. The default setting is on, and when
this is the case and you select a job from the Scheduler Console or the Alarm
Manager, the open Run Status Tool updates to reflect the selected job. If you
toggle this option to off (unchecked), the Run Status Tool does not update with
new selections.

Help Menu The Help menu has the following options:

Contents
Displays the table of contents for the Help.

About
Displays the Run Status Tool version number.

Scheduler Console 11–21

Using Scheduler Console Tools

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

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

11–22 User Guide

 Using Scheduler Console Tools

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
(previously discussed). For more job flow information, use the Job
Dependencies dialog (described in Using the Job Dependencies Dialog in
this chapter).

Using the Send Event Tool

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

■ Send any event that can be sent manually.

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

Scheduler Console 11–23

Using Scheduler Console Tools

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 this chapter. 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 and
Canceling a Send Event.

11–24 User Guide

 Using Scheduler Console Tools

Send Event Tool Menu Bar

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

File Menu The File menu contains the following options:

New Send Event Tool

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

Exit
Closes the tool.

Options Menu The Options menu contains the following option:

Adopt Session Context

Determines if the Send Event Tool will associate with the selected job in any
open Scheduler Console or Alarm Manager window. If this option is selected
(checked), the Send Event Tool updates to reflect the selected job. If the
option is off (unchecked), the Send Event Tool does not update, and you
must manually change the name or open a new tool for other jobs.

Help Menu The Help menu contains the following options:

Contents
Displays the table of contents for the Unicenter AutoSys JM Help.

About
Displays the Send Event Tool version number.

Scheduler Console 11–25

Using Scheduler Console Tools

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.

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.

11–26 User Guide

 Using Scheduler Console Tools

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 Unicenter AutoSys JM 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.

Scheduler Console 11–27

Using Scheduler Console Tools

Set Global
Sets an 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
job is running on a Windows machine. Choosing this option is equal to
sending a SEND_SIGNAL event.

For more information about any of these events, see the section sendevent in the
chapter “Commands” in the Unicenter AutoSys Job Management Reference
Guide.

These are the other Send Event Tool fields:

Cancel Previously Sent Event

Cancel one or more events scheduled to occur sometime in the future. You
can do this in one of two ways. You can either cancel a specific event (by
choosing an event from the Event Types list), or cancel a specific event (or
events) by scheduled time (by selecting an Event Type and the Match On
Time check box, then indicating a time). For information, see Canceling a
Sent Event in this chapter.

Match On Time
Indicates that the event or events you are canceling are based on the Time
you indicate in the Future field area. For information, see Canceling a Sent
Event in this chapter.

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.

11–28 User Guide

 Using Scheduler Console Tools

Instance
The AUTOSERV instance name for the currently selected job. When events
need to be sent to a different 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.

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.

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

Scheduler Console 11–29

Using Scheduler Console Tools

Canceling 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 canceling a
specific event or by canceling a specific event by its scheduled time.

Note: You should use this feature to cancel events that you have sent from the
Send Event Tool. If you want to override a scheduled starting condition for a job,
you should use the one time override job attribute, either from the Job Editor or
from JIL.

■ To cancel a specific event:

1. Make sure you have the appropriate job in the Job Name field.

Note: You can select multiple jobs in the Scheduler Console before you
open the Send Event Tool. If you do so, the Send Event Tool will send
this cancel event on all of the selected jobs that meet the Event Type
criteria.

2. In the Event Type region, specify an event type by selecting one of the
radio buttons.

3. Select the Cancel Previously Sent Event check box.

4. Click Send. This process cancels all pending events of the specified Event
Type for the selected jobs.

■ To cancel an event by its scheduled time:

1. Make sure you have the appropriate job in the Job Name field.

Note: You can select multiple jobs in the Scheduler Console before you
open the Send Event Tool. If you do so, the Send Event Tool will send
this cancel event on all of the selected jobs that meet the Event Type and
Time criteria.

2. Select an Event Type radio button, indicating the type of event to be

cancelled.

3. Select the Cancel Previously Sent Event check box.

11–30 User Guide

 Using Scheduler Console Tools

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 Send. This process cancels all pending events of the specified Event
Type at the specified Time for the selected jobs.

Notes on Canceling a The Cancel Previously Sent Event feature is designed to be used primarily on
Send Event 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.

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 set for 11:00 Tuesday. At 9:00 on Tuesday, you
cancel the 11:00 Start Job event. The job not only does not run at 11:00 on
Tuesday, but it will not be scheduled to run again. To restart the job, you can
either update its job definition or manually issue a Start Job Send Event.

Scheduler Console 11–31

Using Scheduler Console Reports

Using Scheduler Console Reports

The Reports menu contains the following options:

Job Detail Report

Opens the Job Detail Report tool.

Using the Job Detail Report Tool

The Job Detail Report tool displays a realtime report for one currently selected
job. This report presents job run information in the same format produced by the
autorep command. It presents the following two types of reports, which you can
select from the drop-down list on the bottom right of the tool:

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

■ To open the Job Detail Report tool:

Choose Reports, Job Detail Report. This action opens a dialog similar to the
one shown in the following figure.

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

■ To dismiss the tool:

Click OK.

11–32 User Guide

 Using Scheduler Console Reports

Job Detail Report Menu Bar

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

File Menu The File menu has the following options:

New Job Detail Report

Opens another Job Detail Report tool for the selected job.

Exit
Closes the Job Detail Report tool.

Tools Menu The Tools menu has the following options:

Send Event
Opens a Send Event Tool for the selected job. For information, see Using the
Send Event Tool in this chapter.

Run Status Tool

Opens a Run Status Tool for the selected job. For information, see Using the
Run Status Tool in this chapter.

Applications Menu The Applications menu has the following option:

Job Editor
Opens a Job Editor for the selected job. For information, see the chapter
“Defining AutoSys Jobs Using the Job Editor,” in this guide.

Options Menu The Options menu has the following option:

Adopt Session Context

Determines if the Job Detail Report tool will associate with the selected job in
any open Scheduler Console or Alarm Manager windows. If this option is
selected (checked), the Job Detail Report tool updates to reflect the selected
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.

Help Menu The Help menu has the following options:

Contents
Displays the table of contents for the Unicenter AutoSys JM Help.

About
Displays the version for the Job Detail Report.

Scheduler Console 11–33

Setting Scheduler Console Preferences

Setting Scheduler Console Preferences

The Scheduler Console Preferences menu contains the following options:

General
Opens the General dialog (see Using the General Dialog in this chapter).

User-Defined Commands
Opens the User-Defined Buttons dialog (see Using the User-Defined Buttons
Dialog in this chapter).

User-Defined Reports
Opens the User-Defined Reports dialog (see Using the User-Defined Reports
Dialog in this chapter).

Summary Area Layout

Opens the Summary Area Layout dialog (see Using the Summary Area
Layout Dialog in this chapter).

Action Area Layout

Opens the Action Area Layout dialog (see Using the Action Area Layout
Dialog in this chapter).

Time Perspective
Presents three submenu options (see Setting the Time Perspective in this
chapter).

AutoRefresh
You can toggle the AutoRefresh setting to determine if the Scheduler
Console updates automatically. By default, AutoRefresh is selected (set to
on). This setting indicates that the Scheduler Console should be updated
based on the Refresh Interval setting in the General dialog. If you uncheck
the AutoRefresh option, setting it to off, the Console display is not updated
automatically. To update the display, you can check the AutoRefresh option,
or you can click the Refresh button.

11–34 User Guide

 Setting Scheduler Console Preferences

Using the General Dialog

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 databases 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 Appearance. 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 the following illistration.

■ To close the General dialog:

Do one of the following:

■ Click OK to set the modified settings and dismiss the dialog.

or:

■ Click Cancel to make no changes and dismiss the dialog.

Scheduler Console 11–35

Setting Scheduler Console Preferences

Using the User-Defined Buttons Dialog

You can use the User-Defined Buttons dialog to implement shortcuts to

commands you use often.

Note: You can create up to 20 user-defined buttons.

Creating Command Buttons

To create buttons:

1. Choose Preferences, User-Defined Commands. This action opens a dialog

like the one shown in the following figure.

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.

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

11–36 User Guide

 Setting Scheduler Console Preferences

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 command in the Command field of this dialog, you must
use the following syntax:
initautosys -i $INST -r "command_line"

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 instance name, and the selected instance will be used
when you click the button.

Note: When you choose commands to execute from a user-defined button, you
should use only persistent commands.

Scheduler Console 11–37

Setting Scheduler Console Preferences

Using the User Defined Reports Dialog

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 in the following illistration.

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

11–38 User Guide

 Setting Scheduler Console Preferences

When you choose the new Reports menu item, it executes the specified
command.

Using the Summary Area Layout Dialog

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

Scheduler Console 11–39

Setting Scheduler Console Preferences

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 following illistration:

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.

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.

11–40 User Guide

 Setting Scheduler Console Preferences

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.

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.

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 nesting levels for box jobs has no meaning, and there is no indication of
which jobs are in which box job.

Scheduler Console 11–41

Setting Scheduler Console Preferences

Using the Action Area Layout Dialog

The Action Area Layout dialog allows you to select the 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
following illistration:

Buttons in the action area for any of these tools or actions:

Select the tools or actions, and click OK. This puts the appropriate buttons in the
action area.

When you click a tool button in the action area, the related dialog opens. When
you click an action button, a confirmation dialog displays, and after you click
OK, the associated event is sent. If you have initiated an action on multiple jobs,
the confirmation dialog will display the list of jobs you have selected.

11–42 User Guide

 Setting Scheduler Console Preferences

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 in this chapter.

Job Detail Report...

Opens the Job Detail Report tool for the selected jobs. This dialog displays a
realtime report of the job run information (in the format of the autorep
command output). For information, see Using the Job Detail Report Tool in
this chapter.

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 in this chapter.

Job Editor...
Opens a Job Editor with the selected jobs. For information on the Job Editor,
see the chapter “Defining Jobs Using the Job Editor,” in this guide.

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.

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.

Scheduler Console 11–43

Setting Scheduler Console Preferences

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.

Note: If you want to add your own buttons, see Using the User Defined Buttons
Dialog.

Setting the Time Perspective

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

Local Time
Displays the time in the time zone of the machine on which your Scheduler
Console is running.

Currently Selected Job

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.

Currently Selected Instance

Displays the time based on the time zone of the database.

11–44 User Guide

 Setting Scheduler Console Preferences

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.

Scheduler Console 11–45

 Chapter

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

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
appropriate instance changes color. You can then click the button to open an
Alarm Manager for that instance.

To open the Alarm Sentry:

Click Alarm Sentry in the GUI Control Panel. This action opens a window
similar to the following figure. Your Alarm Sentry will have a button for
each instance it can access.

The following illistration shows the Alarm Sentry for one instances:

Managing Alarms 12–1

Using the Alarm Sentry

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.

Using the Alarm Sentry Menu Bar

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

File Menu

The File menu contains the following option:

Exit
Closes the Alarm Sentry.

Preferences Menu

The Preferences menu contains the following option:

General
Opens the Refresh Interval dialog that you can use to set the time in seconds
between refresh (updating the buttons based on the database information).
You set the interval in seconds, and the default setting is every 60 seconds.

Help Menu

The Help menu contains the following options:

Contents
Displays the table of contents for the Unicenter AutoSys JM Help.

About
Displays the Alarm Sentry version number.

12–2 User Guide

 Using the Alarm Manager

Using the Alarm Manager

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

To display the Alarm Manager dialog do one of the following:

■ 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 opens an Alarm Manager dialog similar to the following
illistration.

Note: In addition, you can open the Alarm Manager from the Scheduler Console
by choosing Alarm Manager from the Applications menu.

Managing Alarms 12–3

Using the Alarm Manager

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

■ 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

Using the Alarm Manager Menu Bar

The Alarm Manager menu bar contains the following menus: File, Filters, Tools,
Preferences, and Help.

File Menu

The File menu contains the following options:

New Alarm Manager

Opens a New Alarm Manager.

Exit
Closes the Alarm Manager.

Filters Menu

The Filters menu contains the following options:

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 in Filtering Alarms in this
chapter). Use this dialog to define the filter by which you want to view
alarms.

12–4 User Guide

 Using the Alarm Manager

Tools Menu

The Tools menu contains the following options:

Run Status Tool

Opens the Run Status Tool for the Currently Selected Job. The Run Status
Tool displays a job summary, including information about the most recent,
or current, run of the job for which the alarm was generated. For
information, see Using the Run Status Tool in the chapter “Scheduler
Console,” in this guide.

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 the chapter “Scheduler Console,” in this guide.

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 realtime report of the job run
information (in the format of the autorep command output). For information,
see Using the Job Detail Report Tool in the chapter “Scheduler Console,” in
this guide.

Preferences Menu

The Preferences menu contains the following option:

General
Opens the Preferences dialog in which you can set the Time between
refreshes in seconds, and you can enable Sound.

The default refresh interval time is 60 seconds, and for refresh to work, you must
select the Auto Refresh check box (which is the default setting).

If you select the Sound check box 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
Unicenter AutoSys Administrator Sounds screen.

Managing Alarms 12–5

Using the Alarm Manager

Help Menu

The Help menu contains the following option:

Contents
Displays the table of contents for the Unicenter AutoSys JM Help.

About
Displays the Alarm Manager version number.

Using the Alarm Manager Alarm List

The Alarm List region of the dialog displays a list of all the alarms that are
currently in the system and that meet the 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.

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

12–6 User Guide

 Using the Alarm Manager

■ To select multiple alarms:

Do one of the following:

■ Press the Ctrl key and click on each alarm that you want to select.
Pressing the Ctrl key and 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.

Clicking anywhere in the alarm list will deselect the currently selected alarms.

Viewing the Currently Selected Alarm

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.

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.

Managing Alarms 12–7

Using the Alarm Manager

Registering Responses and Changing Alarm States

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

Setting the Refresh Behavior

At the bottom of the Alarm manager is the Refresh area, and it contains the Auto
Refresh setting, which you can turn off or on, and the Refresh button.

By default Auto Refresh is selected (set to on). The on setting indicates that the
Alarm Manager should be updated based on the setting in the General dialog,
which you can open from the Preferences menu. The default refresh interval is
60 seconds. With this setting, the Alarm Manager reads from the database to
update the alarm list every 60 seconds.

If you uncheck the Auto Refresh check box, setting it to off, the Console display
is not updated.

To update the display:

Do one of the following:

■ Check the Auto Refresh checkbox.

or:

■ Click Refresh.

12–8 User Guide

 Filtering Alarms

Filtering Alarms
Alarms and their responses are stored in the 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.

To display the Alarm Selection dialog:

Choose Filters, Select Alarms. The Alarm Selection dialog appears with the
defaults set, as shown in the following illistration:

Managing Alarms 12–9

Filtering Alarms

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

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

■ 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

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:

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 Ctrl key and click the desired alarms. To deselect an alarm, press
the Ctrl key and 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 section Alarms in the chapter
“System States, “ of the Unicenter AutoSys Job Management Reference Guide.

12–10 User Guide

 Filtering Alarms

Selecting Alarms by State

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

Selecting Alarms by Instance

You can select which 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

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

Managing Alarms 12–11

 Chapter

Monitoring and Reporting on Jobs

13

Using AutoSys Monitors and Browsers

You can define and create monitors and browsers to view the state of the system.
Monitors provide a realtime 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
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 database, and they
work with dual-event servers. Also, you can run monitors and reports on any
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 realtime information.

Monitoring and Reporting on Jobs 13–1

Using AutoSys Monitors and Browsers

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.

In addition, you can define monitors and reports by passing Job Information
Language (JIL) statements to the jil command. For information, see Defining
Monitors and Reports Using JIL in this chapter.

In either case, the monitor or report definitions are stored in the database.
Because the definitions are stored in the database, you can run defined monitors
or reports at any time without redefining the criteria.

Using Monitors

Monitors provide a realtime view of the 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 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.

13–2 User Guide

 Using AutoSys Monitors and Browsers

Using Reports

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.

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.

Monitoring and Reporting on Jobs 13–3

Using the Monitor/Browser Editor

Using the Monitor/Browser Editor

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

1. Open the GUI Control Panel from the Graphical Interface icon in the
program group.

2. In the GUI Control Panel, click Monitor/Browser Editor, which displays the
Monitor/Browser Editor shown in the following illistration.

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 to save the definition to, and can specify the name of
the monitor or report.

Note: When you first select an instance in any of the Monitor/Browser Editor
dialogs, Unicenter AutoSys JM establishes a connection to that instance’s
database, and maintains that connection until you close the Monitor/Browser
Editor.

13–4 User Guide

 Using the Monitor/Browser Editor

The Monitor/Browser Editor contains fields that represent all the information
needed to define a monitor or report. For more information about these fields,
see Setting Monitor and Report Attributes in this chapter.

Using the Monitor/Browser Editor Menu Bar

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

File Menu

The File menu contains the following options:

New
Opens the New Monitor/Browser dialog, which allows you to select an
instance and enter a unique name for the new monitor or report you are
going to define.

The monitor or report name identifies the monitor or report, and must be
unique within an 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 percent (%) 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 or a different name.

Monitoring and Reporting on Jobs 13–5

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

Note: When you first open a Monitor/Browser Editor, and when you select a
new instance in any of the Monitor/Browser dialogs, Unicenter AutoSys JM
establishes a connection to that instance’s database, and it maintains that
connection until you close the Monitor/Browser Editor.

Edit Menu

The Edit menu contains the following option:

Clear
Clears the Monitor/Browser Editor without affecting the database. Use this
button to clear all fields before you begin defining a new monitor or report.

Help Menu

The Help menu contains the following options:

Contents
Displays the table of contents for the Unicenter AutoSys JM Help.

About
Displays the Monitor/Browser Editor version number.

13–6 User Guide

 Defining Monitors and Reports with the Editor

Defining Monitors and Reports with the Editor

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 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 in this chapter.

Defining a Monitor

This example describes how to define a monitor with the name “Regular.” This
monitor will monitor all alarms, plus job status events when a job changes state
to running, success, failure, or terminated.

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

3. In the Job Change Status Events sub area; select the Running, Success,
Failure, and Terminated check boxes.

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 the following
illistration.

Monitoring and Reporting on Jobs 13–7

Defining Monitors and Reports with the Editor

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 in this chapter.

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 Instance Command Prompt window opens to
display the monitor or report output.

13–8 User Guide

 Defining Monitors and Reports with the Editor

Defining a Report

This example describes how to define a report with the name “Alarm_Rep.” This
definition will create a report that contains all alarms on any job, from May 22,
1997, at 2:00 a.m. to the present.

To define the example report:

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

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.

Monitoring and Reporting on Jobs 13–9

Defining Monitors and Reports with the Editor

Your entries in the Monitor/Browser Editor should look like those shown in the
following illistration:

Closing the Monitor/Browser Editor

To close the Monitor/Browser Editor:

Choose File, Exit.

13–10 User Guide

 Setting Monitor and Report Attributes

Setting Monitor and Report Attributes

To set the monitor or report attributes, use the fields on the Monitor/Browser
Editor. The Monitor/Browser Editor is divided into the following areas:

■ Event Types

■ Job Selection Criteria

■ Monitor Options

■ Browser Time Criteria

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

Setting Event Types

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

■ Changes in the state of jobs

■ Generated occurrences, such as alarms

■ Manually generated events, such as starting a job, placing a job on hold, or

killing a job

All Events JIL Keyword: all_events

Selecting the All Events check box 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 check box, the other
Event Types settings are used.

If you want to monitor all the events for all jobs, you should not run a monitor.
Instead, you should display the event processor log in real time, by using the
following command at an AutoSys instance command prompt:
autosyslog –e

Monitoring and Reporting on Jobs 13–11

Setting Monitor and Report Attributes

Running a monitor adds another connection to the database and establishes

another process that is continually polling the database. This has a significant
impact on system performance. Moreover, the information logged by the event
processor contains more diagnostic information than the monitor does. Reports
connect to the database only once to get the information, so they do not have the
same impact on system performance as monitors do.

Alarm JIL Keyword: alarm

Selecting the Alarm check box specifies that generated alarms should be tracked.

If you select the All Events check box, alarms are already tracked. To limit the
events that are tracked, however, you can select both Alarm and All Change
Status Events, or choose specific Job Change Status Events as filters (described
below).

All Change Status JIL Keyword: all_status

Events

Selecting the All Change Status Events check box 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 internal job status events are tracked.

You can select both All Change Status Events and Alarms as filters. If you select
the All Events check box, change status events are automatically tracked.

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

■ Running (running)

■ Success (success)

■ Failure (failure)

■ Terminated (terminated)

■ Starting (starting)

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

13–12 User Guide

 Setting Monitor and Report Attributes

Setting the Job Selection Criteria

In the Job Selection Criteria area you can indicate the jobs to track. The events to
be tracked are determined by the combination of the Event Types that you set as
filters and the Job Selection Criteria you set in this area.

Job Filter JIL Keyword: job_filter

You can set the Job Filter to one of three settings: All jobs (no job filtering), all
jobs in a box job with a specified name, or a single job with a specified name. If
you select either the Jobs in Box named or Single Job named radio buttons, you
must enter the job name in the field to the right of these choices.

Monitoring and Reporting on Jobs 13–13

Setting Monitor and Report Attributes

Setting Monitor Options

The monitor attributes in the Monitor Options area are optional.

Sound JIL Keyword: sound

Selecting the Sound check box specifies that the sound facility should be used. If
the Windows machine running the monitor has sound capabilities and you have
enabled sound using the Unicenter AutoSys Administrator, Unicenter AutoSys
JM uses sound to announce the events as they occur. The announcement is from
prerecorded sound clips.

For more information about enabling AutoSys sounds, see the section Sounds in
the Chapter “Administrator,” in this guide.

Note: We strongly recommend that you use the sound attribute for monitoring
AutoSys, especially alarms. It frees you from needing to look through output
files to see if there were any problems. However, for the sound attribute to work,
the monitor must be running.

Alarm Verification JIL Keyword: alarm_verif

Required

Selecting the Alarm Verification Required check box specifies that personnel
must respond to alarms 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 timestamped and logged in the msg_ack database table, along
with the alarm event. Execute SQL against the msg_ack table to view the account
of the alarms responded to and at what time.

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.

13–14 User Guide

 Setting Monitor and Report Attributes

Setting the Browser Time Criteria

When defining reports, you must specify one of the Browser Time Criteria
options. Reports are based on all events in the database, and the Browser Time
Criteria allows you to select events that occurred within a particular span of
time. The two choices are mutually exclusive.

Note: These settings are disabled for monitors because time is not used in
monitors; monitors only show events as they occur.

Current Run Only JIL Keyword: currun

Selecting the Current Run Only check box specifies that only events in the
current or most recent execution of the specified jobs 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 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 check box.

Events After JIL Keyword: after_time

Date/Time

Entering a date and time in the Events After Date/Time field specifies that only
the events occurring after that date and time for the specified jobs, 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.

Note: If your local setting uses a two-digit year, you must enter the year in that
format. Unicenter AutoSys JM however saves the setting to the database using a
four-digit year. If you enter 79 or less, Unicenter AutoSys JM prepends 20, and, if
you enter 80 or greater, Unicenter AutoSys JM prepends 19.

Monitoring and Reporting on Jobs 13–15

Running a Monitor or Generating a Report

Running a Monitor or Generating a Report

■ To run a monitor or report:

Do one of the following:

■ In the Monitor/Browser Editor, open a monitor or report and choose

File, Run Monitor/Browser, and the current monitor or report will run.

■ From an 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 Ctrl+C.

13–16 User Guide

 Defining Monitors and Reports Using JIL

Defining Monitors and Reports Using JIL

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 subcommands. For defining monitors or reports, use these JIL
subcommands:

■ insert_monbro

■ update_monbro

■ delete_monbro

■ To define a monitor or report using JIL interactively:

1. Open an instance command prompt window.

2. At the instance command prompt, issue the following command:

jil

3. At the jil prompt, enter the JIL subcommand followed by a set of

attribute: value pairs.
insert_monbro: name_value

■ To define a monitor or report using JIL by redirecting a file containing jil

definitions:

At the Instance Command Prompt, submit the JIL script file, like:
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 Monitor and Reports with the Editor in this
chapter.

Note: For a complete listing and description of the JIL commands and
subcommands that you can use to define monitors and reports, see the chapter
“JIL/GUI Monitor/Report Definitions” in the Unicenter AutoSys Job
Management for Windows and UNIX Reference Guide.

Monitoring and Reporting on Jobs 13–17

Defining Monitors and Reports Using JIL

Defining Monitors Using JIL

The first example in this section defines a monitor with the name “Regular.” This
monitor will track all alarms, plus job status events when a job changes state to
running, success, failure, and terminated:
/* Monitor for all ALARMS, and
* Job EVENTS: RUNNING,SUCCESS,FAILURE & TERMINATED
*/

insert_monbro: Regular
mode: m
alarm: y
running: y
success: y
failure: y
terminated: y

The following JIL statements define a monitor that catches alarms, generates a
sound, and repeats the sound until someone responds:
/* Monitor for JUST ALARMS!
* Verification Required is ON so someone must
* type in a response.
* Sound is ON!
*/

insert_monbro: Alarm
mode: m
sound: y
alarm: y
alarm_verif: y

Note: The file named %AUTOSYS%\install\data\monbro.jil contains example

JIL statements. For more information about enabling sound, see Sounds in the
chapter “Administrator,” in this guide.

This example defines a report with the name “Alarm_Rep.” This report will
report all alarms on any job from April 1, 1997, at 2:00 a.m. to the present.
insert_monbro: Alarm_Rep
mode: b
alarm: y
after_time: "05/22/1997 2:00"

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.

13–18 User Guide

 Chapter

Maintaining
14
This chapter describes the procedures for maintaining Unicenter AutoSys JM
and the database.

Maintaining the Event Processor

The Event Processor is the engine of Unicenter AutoSys JM. 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

The 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

1. Open the Unicenter AutoSys Administrator from the program group.

2. On the Instance screen, specify the Computer and 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.

4. On the Services screen, select the AutoSys Event Processor from the Service
drop-down menu.

5. Click the Start Service button.

Maintaining 14–1
Maintaining the Event Processor

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 services, including the 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
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.

14–2 User Guide

 Maintaining the Event Processor

■ 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
processes in a known state. Problems are detected upon Event Processor
startup. This method is similar to database check pointing 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 Unicenter AutoSys Administrator
Event Processor screen. For more information on using the Unicenter AutoSys
Administrator, see the section Administrator Event Processor in the chapter
“Administrator,” in this guide.

Monitoring the Event Processor

The output of the Event Processor (event_demon.exe executable) is written to the

following log file:
%AUTOUSER%\out\event_demon.%AUTOSERV%

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 autosyslog utility like:

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

Maintaining 14–3
Maintaining the Event Processor

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

■ If the Event Processor fails during the startup procedure, the error is written
to the designated Enterprise Wide Directory, in:
event_demon.%AUTOSERV%.out

■ If the Event Processor has problems while running, the error is written to:
%AUTOUSER%\out\event_demon.%AUTOSERV%

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 section Unicenter
AutoSys Administrator Event Processor in the chapter “Administrator,” in this
guide.

14–4 User Guide

 Starting the Event Processor in Global Auto Hold Mode

Starting the Event Processor in Global Auto Hold Mode

If you restart an Event Processor after a period of downtime, you might want to
start it in Global Auto Hold mode. In Global AutoHold mode, the Event
Processor starts without simultaneously starting all the jobs whose starting
conditions are met.

Starting the Event Processor in Global Auto Hold mode prevents the system
from being flooded with jobs that were scheduled to run during the downtime.
When you select Global Auto Hold, the Event Processor evaluates all jobs whose
starting conditions have passed and are eligible to run, but instead of starting the
jobs, the Event Processor puts them ON_HOLD. It does this for all types of jobs
(Box, Command, and File Watcher Jobs).

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

1. Open the Unicenter AutoSys Administrator from the program group.

2. On the Instance screen, specify the Computer and 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 Event Processor screen:

Choose AutoSys, Event Processor.

or:

Click the Event Processor button on the toolbar.

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

5. Do one of the following to display the Services screen:

Choose AutoSys, Services.

or:

Click the Services button on the toolbar.

6. On the Services screen, select the Event Processor from the Service drop-
down menu.

7. Click the Start Service button.

Maintaining 14–5
Starting the Event Processor in Global Auto Hold Mode

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:

sendevent -E STOP_DEMON

2. Open the Unicenter AutoSys Administrator from the program group.

3. On the Instance screen, specify the Computer and Instance you are
modifying and click OK. The Computer should be the machine on which the
Event Processor is installed.

4. Do one of the following to display the Event Processor screen:

Choose AutoSys, Event Processor.

or:

Click the Event Processor button on the toolbar.

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

6. Do one of the following to display the Services screen:

Choose AutoSys, Services.

or:

Click the Services button on the toolbar.

7. On the Services screen, select the Event Processor from the Service drop-
down menu.

8. Click the Start Service button.

Note: If you have AutoSys configured with a Shadow Event Processor, and you
start the Event Processor in Global Auto Hold mode, the Shadow Event
Processor will also be in Global Auto Hold mode.

14–6 User Guide

 Starting the Event Processor in Global Auto Hold Mode

Stopping the Event Processor

It is safe to stop the Event Processor at any time, if it is stopped properly. Only
the Exec Superuser can stop the Event Processor.

Note: Stopping the Event Processor does not affect jobs that are already running.
They continue to run to completion, at which time the exit events are sent
directly to the 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 Exec Superuser.

2. Issue the following command at an Instance Command Prompt:

sendevent -E STOP_DEMON

This method allows the Event Processor to complete gracefully any processing it
is performing. You can assign a high priority to the sendevent -E STOP_DEMON
command by including the -P 1 argument. When you issue the sendevent
command, the STOP_DEMON event is sent to the 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 the
chapter Commands, in the Unicenter AutoSys Job Management for Windows
and UNIX Reference Guide.

WARNING! Do not attempt to stop the Event Processor by using a utility such
as pview or by using the 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.

Maintaining 14–7
Starting the Event Processor in Global Auto Hold Mode

Shadow Event Processor Rollover

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.

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, Unicenter AutoSys JM will roll over to the
Shadow Event Processor and to Single Server mode. Unicenter AutoSys JM 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, Unicenter
AutoSys JM might not be able to determine which Event Processor is the
“healthy” one, and it will shut down both processors.

You can specify the Shadow Event Processor and the Third Machine using the
Unicenter AutoSys Administrator Event Processor screen (accessed from the
program group). For more information, see the chapter “Administrator,” in this
guide.

14–8 User Guide

 Starting the Event Processor in Global Auto Hold Mode

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 Exec Superuser, and
issuing the following command:
sendevent -E STOP_DEMON

2. On the Primary Event Processor machine, open the Unicenter AutoSys

Administrator from the program group.

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

4. Go to the Services screen by clicking Services on the toolbar.

5. On the Services screen, select the Event Processor from the Service drop-
down menu.

6. Click Start Service.

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 Unicenter AutoSys Administrator, the
Shadow Event Processor will not start.

Maintaining 14–9
Maintaining the Remote Agent

Maintaining the Remote Agent

A Remote Agent is a Windows service that runs on a remote machine. The Event
Processor directs the Remote Agent to perform specific tasks. The Remote Agent
starts the command specified for a given job, sends running and completion
information about a task as an event to the database, and then exits. If the
Remote Agent is unable to transfer the information, it waits and tries again. It
will continue to try to connect to the database until it can successfully transfer
the information.

Starting the Remote Agent

The Remote Agent service should start automatically when the machine is
started (this is set in the 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 Administrators
group privileges can restart it.

To restart the Remote Agent

1. Open the Unicenter AutoSys Administrator from the program group.

2. On the Instance screen, specify the Computer and Instance of the Remote
Agent you want to start, and click OK.

3. Go to the Services screen by doing one of the following:

■ Click the Services (traffic light) toolbar button.

or:

■ Choose AutoSys, Services.

14–10 User Guide

 Maintaining the Remote Agent

4. On the Services screen, select the 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, Start Service is enabled (if it is running, Stop Services is enabled
and Start Services is disabled).

5. Click Start Service.

If the Remote Agent does not start, see the section Remote Agent
Troubleshooting in the chapter “Troubleshooting,” in this guide.

For information on using the Administrator, see the chapter “Administrator,” in

this guide.

Stopping a Remote Agent

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

Maintaining 14–11
Running in Test Mode

Running in Test Mode

If you want to check your configuration, you can run 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 Unicenter AutoSys JM uses in its normal 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% environment variable before starting the event
processor. The levels of test mode are determined by the value of the
%AUTOTESTMODE% variable. These are the values, which are discussed in the
following sections:

■ %AUTOTESTMODE%= 1

■ %AUTOTESTMODE% = 2

Note: The event processor cannot run partially in test mode; Unicenter AutoSys
JM 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.

14–12 User Guide

 Running in Test Mode

%AUTOTESTMODE% = 1

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

■ The command ntgetdate 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

■ Sourcing a user-specified job profile file

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

Maintaining 14–13
Maintenance Commands

Maintenance Commands
The maintenance commands described below are located in the
%AUTOSYS%\bin directory. You can execute these commands from the
Instance Command Prompt window or as an 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 alert you to the problems it finds (by using
the -A option). In addition, it can automatically restart jobs that are “missing in
action” and that are defined to be restartable (by using the -E option). For more
information about the chase command, see the chapter “Commands,” in the
Unicenter AutoSys Job Management for Windows and UNIX Reference Guide.

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.

14–14 User Guide

 Maintenance Commands

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 database on that machine to purge all
remaining log files from the machine’s remote agent log directory (specified by
AutoRemoteDir in the configuration file). To remove only the log files older than
a specific number of days, use the following command:
clean_files -d days

where:

days Specifies that files older than this number of days should be deleted.

For more information about the clean_files command, see the chapter
“Commands,” in the Unicenter AutoSys Job Management for Windows and
UNIX Reference Guide.

Maintaining 14–15
Backing up Definitions

Backing up Definitions
We recommend that you back up the following 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 the section
Restoring Definitions in this chapter.

We also recommend that you keep a copy of your license keys in case you need
to reinstall them.

To back up definitions:

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

structure and select or enter a file name.

d. Click Save.

Note: The calendar definitions are saved as text.

2. Save your job definitions, from a Instance command prompt, execute the
following command:
autorep -J ALL -q > c:\directory\autosys.jil

where:

directory Is a directory outside of the Unicenter AutoSys JM directory structure. We

recommend that you save this directory to the same directory where you saved
your calendar definitions.

This command saves your job definitions to a file named autosys.jil.

14–16 User Guide

 Backing up Definitions

3. Append your machine definitions to the same file that contains your job
definitions, from the Instance command prompt, 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 Unicenter AutoSys JM 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. Append your monitor and browser definitions to the same file that contains
your job and machine definitions, from the Instance command prompt,
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 Unicenter AutoSys JM directory structure.

5. Save your global variables to their own file, from the Instance command
prompt, execute the following command:
autorep -G ALL > c:\directory\globals.jil

where:

directory Is a directory outside of the Unicenter AutoSys JM directory structure. We

recommend that you save this directory to the same directory where you saved
your other 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. Save your license keys, run the gatekeeper command to print your current
license keys to a file.

Maintaining 14–17
Restoring Definitions

Restoring Definitions
The procedure in this section assumes that you backed up your definitions by
following the procedure in Backing Up Definitions in this chapter.

To restore definitions:

1. 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 file name of the text file that
contains your calendar definitions.

d. Click Open.

2. Restore your job, machine, and monitor and browser definitions, from a
AutoSys Instance command prompt, execute the following command:
jil < c:\directory\autosys.jil

where:

directory Is the directory where you saved your definitions.

3. Restore your global variables, reference your backup file, redefine any global
variables and reset the necessary Administrator settings.

14–18 User Guide

 Database Overview

Database Overview
All information is stored in a relational database known as the Event Server or
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. 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 to run with Dual Event Servers (two databases).
Dual databases provide redundancy in the event of an Event Server crash.

Note: While Unicenter AutoSys JM 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.

Maintaining 14–19
Event Server Overview

Event Server Overview

An Event Server can be associated with only one instance 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 the chapter “Database Tables and Codes, “ in the
Unicenter AutoSys Job Management for Windows and UNIX Reference Guide.

Using Dual Event Server Mode

When you configure 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 section Installing
Dual Event Servers in the chapter “Advanced Configurations,” in the Unicenter
AutoSys Job Management for Windows Installation Guide.

14–20 User Guide

 Event Server Overview

Database Storage Requirements

The standard sizes for databases are 64 MB (Sybase and Microsoft SQL Server)
and 128 MB (Oracle). The standard sizes for 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.)

Maintaining 14–21
Database Architecture

Database Architecture
The following illustration shows the layout of databases in an Unicenter AutoSys
JM environment, and it will help you understand configuration options. It
depicts how Unicenter AutoSys JM determines which database to use, and how
the three primary components (the Event Processor, the database, and the
Remote Agent) interact.

One Instance of AutoSys — %AUTOSERV%

Define Read Registry to

Jobs determine which
Event
databases to use.
Server 1
OS File
AutoSys
Administrator
Event setting
Event Processor
Server 2 Instructs Remote
Machine:
Command to
execute and
databases to send
Remote events to.
Agent

databases Processes

The previous illustration shows one instance 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 databases.

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 Unicenter AutoSys Administrator. In the
Unicenter AutoSys Administrator, you can specify which databases to use. This
information is stored in the Registry. All commands access it. This variable along
with other specific variables are set in the Instance Command Prompt window,
and thus, you must execute commands in these windows.

For more information on configuring instances, see the chapter “Administrator,”

in this guide.

14–22 User Guide

 General Database Maintenance

General Database Maintenance

You can configure Unicenter AutoSys JM to maintain it self as it runs. In fact,
there are defaults in place that provide frequent, automatic maintenance. You
can customize the settings by using the Unicenter AutoSys Administrator. In
addition to this regularly scheduled maintenance, you can issue general and
database maintenance commands from the Instance Command Prompt.

Periodic maintenance is essential to keeping Unicenter AutoSys JM working

correctly. Several 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 Unicenter AutoSys JM and its jobs to a halt. Therefore, we
recommend that you use the suggested periodic maintenance practices described
in this section.

Daily Database Maintenance

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 Unicenter 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
Unicenter AutoSys Administrator, see the section Administrator Event Server in
the chapter “Administrator,” in this guide.

Maintaining 14–23
General Database Maintenance

DBMaint.bat Batch File

By default, Unicenter AutoSys JM 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 tables.

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

14–24 User Guide

 General Database Maintenance

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 the
chapter “Commands,” in the Unicenter AutoSys Job Management for Windows
and UNIX Reference Guide. For a list of the database tables and views, as well as
the event and alarm codes used in the tables, see the chapter “Database Tables
and Codes,” in the Unicenter AutoSys Job Management for Windows and UNIX
Reference Guide

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
more information on backing up bundled Sybase, see the section Bundled Sybase
Backup and Recovery, in this chapter.

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.

The batch file name is specified in the Database Maintenance Command field on
the Unicenter AutoSys Administrator Event Processor screen.

Data Locking

Depending on your environment, you may see many Sybase deadlock messages
in the event_processor log. While this has no adverse effect on the integrity of
your system, it can affect performance. To reduce the number of deadlocks, you
can turn on row-level locking.

To turn on row-level locking for the entire database, type the following at an xql
prompt:
sp_configure "lock scheme", 0, datarows;

Maintaining 14–25
Event Server Rollover Recovery

Or, you can lock tables individually, with the following command from an xql
prompt:
alter table <table> lock datarows;

Where <table> indicates the name of the table on which to configure row-level
locking. Based on usage, we recommend the following tables:

Tables
event proc_event job

job2 job_cond job_status

job_runs last_Eoid_counter next_oid

Event Server Rollover Recovery

When Unicenter AutoSys JM 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 (for example, corrupt database or

media failure).

If one Event Server is lost, Unicenter AutoSys JM 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.

Unicenter AutoSys JM makes these changes so that you and the utilities trying to
access the database will know that it is now running in Single Server mode, and
so that client processes will not try to write to the down Event Server.

14–26 User Guide

 Event Server Rollover Recovery

Returning to Dual Server Mode After a Rollover

When an Event Server is down, do not, under any circumstances, simply bring
that Event Server back on-line and run in Dual Server mode. After you recover
the crashed server, you can reconfigure Unicenter AutoSys JM to run with Dual
Event Servers. Before you can start 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 Instance

Command Prompt window (which you open from the program group):
sendevent -E STOP_DEMON

2. Synchronize the Event Servers by using the autobcp.NT Perl script.

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 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 Unicenter AutoSys Administrator from the program group.

b. Specify the appropriate Computer and 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 Unicenter 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. Unicenter AutoSys JM client processes and commands check the flags
in both Event Servers for consistency, therefore, you must start the Event
Processor before running any other commands.

5. Exit the Unicenter AutoSys Administrator.

Maintaining 14–27
Event Server Rollover Recovery

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 64 MB (Sybase and Microsoft SQL
Server) and 100 MB (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 clients (for example, Event Processor, 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.

14–28 User Guide

 Event Server Rollover Recovery

To synchronize the databases

1. In an Instance Command Prompt window, enter the following:
cd %AUTOSYS%\DBOBJ

2. Then, enter the following command:

■ For Sybase databases:

perl autobcp.NT source_server source_db destination_server destination_db
autosys_password dump_file

■ For Oracle databases:

perl autobcp.NT source_instance destination_instance autosys_password
dump_file oracle_path

■ For Microsoft SQL Server databases:

perl autobcp.NT source_server source_db destination_server destination_db
autosys_password dump_file MSSQL_path

where:

source_server Specifies the name of the source Sybase or Microsoft SQL Server (for example,
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 (for example,
autosys).

destination_server Specifies the destination Sybase or Microsoft SQL Server database (for example,
AUTOSYSDB2).

For Sybase this is defined in the SQL.INI file.

destination_db Specifies the destination Sybase or Microsoft SQL Server database

source_instance Specifies the source Oracle instance (for example, AUTOSYSDB).

destination_instance Specifies the destination Oracle instance (for example, 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.

Maintaining 14–29
Event Server Rollover Recovery

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 the section Returning to
Dual Server Mode After a Rollover, in this chapter. If the script is not successful,
see the section Handling Errors, in this chapter.

If you enter any information incorrectly, the script prompts you with questions
and requests confirmation, as described in the following database-specific
sections.

Synchronizing Sybase Databases

If you are synchronizing two Sybase databases, you are prompted to answer the
following questions, and then the script runs:
AUTOBCP.NT: Source server [SourceServer]? > source_server
AUTOBCP.NT: Source database [autosys]? > autosys
AUTOBCP.NT: Destination server [DestinationServer]? > destination_server
AUTOBCP.NT: Destination database [autosys]? autosys
AUTOBCP.NT: Autosys password [password]? > autosys_password
AUTOBCP.NT: Dump file name [dump.fil]? > dump.file
AUTOBCP.NT: Moving data from source_server:autosys to
destination_server:autosys
AUTOBCP.NT: Are you sure? ([y]|n)> y
...
autobcp: complete

If the script runs successfully, you see messages on your screen. When it
completes, continue with the steps described in the section Returning to Dual
Server Mode After a Rollover, in this chapter. If the script is not successful, see
the section Handling Errors, in this chapter.

14–30 User Guide

 Event Server Rollover Recovery

Synchronizing Oracle Databases

If you are synchronizing two Oracle databases, you are prompted to answer the
following questions, and then the script runs:
autobcp: Source instance [SourceInst]? > source_path
autobcp: Destination instance [DestinationInst]? > destination_path
autobcp: Autosys password [password]? > autosys_password
autobcp: Dump file name [dump.fil]? > dump.file
autobcp: Path for Oracle (ie. ORACLE_HOME) [c:\orant]? > c:\path
autobcp: Moving data from source_path to destination_path
autobcp: Are you sure? ([y]|n)> y
...
autobcp: complete

If the script runs successfully, you see messages on your screen. When it
completes, continue with the steps described in the section Returning to Dual
Server Mode After a Rollover, in this chapter. If the script is not successful, see
the section Handling Errors, in this chapter.

Synchronizing Microsoft SQL Server Databases

If you are synchronizing two Microsoft SQL Server databases, you are prompted
to answer the following questions, and then the script runs:
AUTOBCP.NT: Source server [SourceServer]? >source_server
AUTOBCP.NT: Source database [autosys]? > autosys
AUTOBCP.NT: Destination server [DestinationServer]? > destination_server
AUTOBCP.NT: Destination database [autosys]? > autosys
AUTOBCP.NT: Autosys password [password]? > autosys_password
AUTOBCP.NT: Dump file name [dump.fil]? > dump.file
AUTOBCP.NT: Path for MicroSoft SQL [c:\mssql]? > c:\path
AUTOBCP.NT: Moving data from source_server:autosys to
destination_server:autosys
AUTOBCP.NT: Are you sure? ([y]|n)> y
...
autobcp: complete

If the script runs successfully, you see messages on your screen. When it
completes, continue with the steps described in the section Returning to Dual
Server Mode After a Rollover, in this chapter. If the script is not successful, see
the section Handling Errors, in this chapter.

Maintaining 14–31
Event Server Rollover Recovery

Handling Errors

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

14–32 User Guide

 Improving Database Performance

Improving Database Performance

This section contains information about improving your database performance.

Improving Sybase Database Performance

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 Unicenter AutoSys JM 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

Tuning Oracle to improve its performance 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.

Maintaining 14–33
Improving Database Performance

To determine if you need to allocate more memory, enter the following query as
the “sys” user in SQL*Plus:
select name, value
from v$sysstat
where name in
(‘db block gets’, ‘consistent gets’, ‘physical reads’);

Monitor the statistics from the query while 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 five percent 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$sysstat
where name in (‘sorts (memory)’, ‘sorts (disk)’);

If disk sorts are greater than one percent of memory sorts, then increase the
value of SORT_AREA_SIZE.

14–34 User Guide

 Maintaining Bundled Sybase SQL Servers

Maintaining Bundled Sybase SQL Servers

Because you can purchase Unicenter AutoSys JM 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, consult your
database administrator for details on starting, stopping, and configuring your
database.

Sybase Architecture

The Sybase database is based on a client/server architecture, with the

communications between clients and server built into the product. The server
portion is called the Sybase SQL Server. This server is a multithreaded, single
process that runs on one machine. It listens on a specific port for a request from a
client, fulfills that request, and then returns the information to the client.

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

This means that all AutoSys commands and processes, including the Event
Processor, the Remote Agent, and monitors, are DB Library applications that
connect to the databases. Because all commands are merely Sybase clients, you
can execute those commands from any machine that has access to the Event
Server and is a licensed 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

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

DSQUERY
Defines the name of the Sybase dataserver.

Maintaining 14–35
Maintaining Bundled Sybase SQL Servers

SYBASE
Specifies the complete path to the Sybase software directory.

The Sybase software directory contains the Sybase configuration file, which on
UNIX is the interfaces file and on Windows is the SQL.INI file. Unicenter
AutoSys JM 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

To perform many administrative tasks on your bundled Sybase database, you

use the xql utility, which is an 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 the chapter “Commands” in the Unicenter AutoSys Job
Management for Windows and UNIX Reference Guide.

Database Users

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

User User Name Default Password

System Administrator sa sysadmin

User autosys autosys

For information on changing the “sa” password, see the section, Changing the
System Administrator Password, in this guide. For more information on
changing the “autosys” password, see the section autosys_secure in the chapter
“Commands,” in the Unicenter AutoSys Job Management for Windows and
UNIX Reference Guide.

14–36 User Guide

 Maintaining Bundled Sybase SQL Servers

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

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

When you reboot the machine after installation, 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 Instance Command Prompt (assuming “autosys” is the Unicenter AutoSys
JM 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 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.

Maintaining 14–37
Maintaining Bundled Sybase SQL Servers

Stopping Sybase

If you perform a Windows 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 Instance Command
Prompt:
sendevent -E STOP_DEMON

■ 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 Unicenter 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 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 the section Changing the
System Administrator Password, in this guide.

14–38 User Guide

 Maintaining Bundled Sybase SQL Servers

Accessing Sybase

Unicenter AutoSys JM 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 the chapter
“Commands,” in the Unicenter AutoSys Job Management for Windows and
UNIX Reference Guide.

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.

Maintaining 14–39
Maintaining Bundled Sybase SQL Servers

Identifying Processes Connected to the Database

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 Unicenter
AutoSys JM , 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:

program_name hostname hostprocess status
------------- --------- ----------- ------
xql Joe 14050 running
sleeping
sleeping
sleeping
sleeping
sleeping
event_demon Michelle 13448 recv sleep
jil Erik 12272 recv sleep

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 process you will see.

autocal event_demon sendevent

autocons hostscape timescape

autosc jil xql

auto_remote jobscape

14–40 User Guide

 Maintaining Bundled Sybase SQL Servers

Displaying the Database Date and Time

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.

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

You must back up the 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 database so that you will have no trouble recovering a lost
database, using the backup database dump.

This section describes how to dump the 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 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).

Maintaining 14–41
Maintaining Bundled Sybase SQL Servers

Configuring a Backup Server

To configure a Sybase backup server

1. Enter the following command at an 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.

14–42 User Guide

 Maintaining Bundled Sybase SQL Servers

Backing up the Database to a File

To backup, or dump, the database to a file

1. Execute the following xql command at the Instance Command Prompt:

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 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 database, when necessary.

Recovering a Bundled Sybase Database

To recover a damaged 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.

Maintaining 14–43
Maintaining Bundled Sybase SQL Servers

Stopping the Event Processor

To stop the Event Processor

Log on as the Exec Superuser and issue the following command at an Instance
Command Prompt:
sendevent -E STOP_DEMON

Dropping the Damaged Database

You can drop the damaged 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 Instance Command Prompt:

xql -Usa -Psysadmin

2. At the xql prompt, enter the following:

xql>>[AUTOSYSDB][master] 1> drop database autosys;

If the database is so damaged that drop database does not work, contact your
Technical Support representative.

3. The semicolon at the end of the command line is an end-of-statement

delimiter in xql, replacing the Sybase “go”.

Re-Creating the Database

After dropping the damaged database, you must recreate a new database. This
new database is used to load the database dump file (for example, the
autodump file) that you are recovering. Use the create database command to
create the new database.

To re-create the 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 50 MB is only an example.

The output generated by this command will look similar to:

14–44 User Guide

 Maintaining Bundled Sybase SQL Servers

Msg 1805, Level 0, State 1, Line 1 CREATE DATABASE:

allocating 15360 pages on disk ‘default’

2. To change the owner of the new 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 the

following should be returned:
Database owner changed.

Reloading the Database

You are now ready to execute the load database command to restore the
database you originally dumped to autodump.

To reload the database and put it online

Enter the following at the xql prompt:

xql>>[AUTOSYSDB][master] 1> load database autosys
xql>>[AUTOSYSDB][master] 2> from autodump;
xql>>[AUTOSYSDB][master] 1> online database autosys;

The database is now restored and online.

Note: For Sybase System 11, you must put the database online. Previous
versions of Sybase did not require this.

To exit xql

Enter the following at the xql prompt:

xql>>[AUTOSYSDB][master] 1> exit

Restarting the Event Processor

Then, you can restart the Event Processor using the Unicenter AutoSys
Administrator Services screen. When you complete this process, Unicenter
AutoSys JM will be in the state it was in when you dumped the database to the
backup file.

Maintaining 14–45
 Chapter

Administrator
15
This chapter describes the Unicenter AutoSys Administrator and how to use its
various screens to configure Unicenter AutoSys JM instances. In addition, this
chapter describes how to use the Unicenter AutoSys Administrator to implement
several advanced configurations, including cross-instance job dependencies,
dual-event servers, and shadow event processors.

About the Administrator

The Unicenter AutoSys Administrator is installed as part of the Console Utilities,
and you can use it to view and modify the configuration parameters for each
instance you install. Once set, these configuration parameters are loaded into the
Windows Registry. On startup, Unicenter AutoSys JM reads this information to
determine runtime behavior.

Unicenter AutoSys JM reads this configuration information to determine the

databases 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 Unicenter AutoSys Administrator.

The Administrator has the following screens, which contain the associated
configuration parameters:

■ Instance

■ Remote Agent

■ Event Server

■ Event Processor

■ Notifications

Administrator 15–1
About the Administrator

■ System Information

■ Sounds

■ Security

■ Services

To modify many of these settings, you must have Windows Administrators

group privileges. If you do not have these privileges, but you do have Windows
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 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 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 Unicenter 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 the topic
Using the Services Screen).

Note: Many of the configuration parameters that you set on Windows using the
Unicenter 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 configuration file on UNIX
platforms, see the chapter “Configuring ,” in the Unicenter AutoSys Job
Management for UNIX User Guide.

15–2 User Guide

 Starting the Administrator

For information while using the Unicenter AutoSys Administrator, see the
Unicenter AutoSys JM Help. Open the Unicenter AutoSys JM Help from the
Unicenter AutoSys JM Help icon in the 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 Administrator

To start the Unicenter AutoSys Administrator:

Select the Unicenter AutoSys Administrator icon in the program group.

Once you have started the Unicenter AutoSys Administrator, you must select an
instance before you can use the various Administrator screens.

For information on selecting an instance, see Administrator Instance Screen.

Administrator Menu Bar and Toolbar

The Unicenter AutoSys Administrator has a basic menu bar and toolbar that is
available with all Administrator screens. The toolbar buttons are menu item
accelerators.

Event Processor
Instance Event Server System Informat ion
Past e Security

Cut

Export

Copy S ervices
Sounds
Abo ut Administrator Remote Agent Notif ication

Administrator 15–3
Starting the Administrator

Administrator Menu Bar

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

File Menu The File menu contains the following options:

Export
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 Menu The Edit 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.

View Menu The View menu contains the following options:

Toolbar
Toggles to show or hide the toolbar.

Status Bar
Toggles to show or hide the status bar.

15–4 User Guide

 Starting the Administrator

AutoSys Menu The AutoSys menu contains the following options:

Instance
Displays the Instance screen, which you can use to select the computer and
installed instance. Once you select a computer and instance, you can view
and modify instance settings using the other Administrator screens.

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.

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 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 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 Menu The Help menu contains the following options:

Administrator 15–5
Instances

Help Topics
Displays the Help Index and Find utility.

About AutoSysAdmin
Displays release information on Unicenter AutoSys Administrator.

Instances
When you start the Unicenter AutoSys Administrator, the Instance screen is
displayed (see the figure in the section, Administrator Instance Screen in this
chapter). This screen lets you select a computer and instance, which you can
view or modify using the other screens of the Administrator.

An instance is one licensed version of Unicenter AutoSys JM software running as

a server and as one or more clients, on one or multiple machines. An instance
uses its own event processor and event server and operates independently of
other instances. An instance is defined by the following:

■ A definition in the Unicenter 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, which is prefixed by the three-letter instance ID that is 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.

You can have multiple instances, each using dual-event servers. In addition, you
can configure Unicenter AutoSys JM to run with cross-instance job
dependencies.

Note: You can set the instance ID only during the installation process.

15–6 User Guide

 Instances

For information on installing multiple instances, see the Installing Multiple

Instances section in the chapter “Advanced Configurations,” in the Unicenter
AutoSys Job Management for Windows Installation Guide. For information on
running multiple instances and running cross-instance job dependencies, see the
chapter “Introduction,” in the Unicenter AutoSys Job Management for Windows
Installation Guide.

Administrator Instance Screen

When you start the Unicenter AutoSys Administrator, the Instance screen is
displayed. To view the various Unicenter AutoSys Administrator screens, you
must first select a computer and installed instance on which to operate.

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

Computer

The Computer setting specifies the host name of the computer on which
Unicenter AutoSys JM is installed and to which you are connected. By default,
this field contains the name of the machine that you are logged on to, but you
can connect to a remote machine to administer the instance information.

To connect to a remote machine:

Enter the host name in the Computer field and click Connect.

Administrator 15–7
Instances

Instance

The capitalized three-letter name that identifies a specific 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 host name of the computer that you are logged on to is already
selected when you open the window.

2. If necessary, select an instance from the Instance drop-down list. The

instance that appears in the Instance field is selected.

3. Click OK.

After you select an instance, the menu items and their corresponding toolbar
buttons are enabled, which allows you to move from screen to screen.

Date Format

The date format is where you can specify the format for the date in your area.
The default is MM/DD/YYYY.

15–8 User Guide

 Remote Agents

Remote Agents
The remote agent is a Windows 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 on to 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.

Administrator Remote Agent Screen

The Administrator Remote Agent screen 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 do one of the following:

■ Select Remote Agent from the AutoSys menu.

or:

■ Click the Remote Agent button on the toolbar.

Note: To modify the settings on this screen, you must have Windows
Administrators group privileges.

Administrator 15–9
Remote Agents

Defining Remote Agent Configuration Parameters

Note: This section lists and describes the configuration parameters located on
the Remote Agent screen.

TCP/IP Port UNIX parameter: #AutoRemPort

The remote agent TCP/IP port number specifies the port number for the remote
agent, and it should be the same number for all remote agents associated with an
instance.

The event processor communicates to the remote agent by way of this TCP/IP
socket connection. The default number is 5280. You set the TCP/IP Port number
at installation time, but you can change this number using the Unicenter
AutoSys Administrator.

This number must be different from the event server port number, and all
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 Windows, 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, in this chapter.

Local Agent Logging The Local Agent Logging Directory field specifies the local directory, on the
Directory remote agent machine, in which Unicenter AutoSys JM 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 in
“Enterprise Wide Logging Directory,” in this guide.

15–10 User Guide

 Remote Agents

Authorized Event The Authorized Event Processor Host Names list specifies the host names of
Processor Host Names the event processors from which this remote agent can accept job-processing
requests.

Unicenter AutoSys JM 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 host name, 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 Windows, each remote agent installation is associated with an

instance; therefore, the machine host name 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 autosys_secure in the

chapter “Commands,” in the Unicenter AutoSys Job Management Reference
Guide.

Administrator 15–11
Event Servers

Event Servers
The event server is the database that contains all of the events and job definitions
that are used by the event processor. The event server is a Windows process and
its associated data space (or raw disk storage), which can include multiple
databases. As a safeguard, you can configure Unicenter AutoSys JM to run with
two event servers, in dual-server mode.

The Event Server Screen (see the figure in Administrator Event Server Screen in
this chapter) 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 reenable dual-server mode.

Dual-Event Servers

Unicenter AutoSys JM can run with two event servers. Unicenter AutoSys JM
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;
Unicenter AutoSys JM 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 data servers, running on different machines.

For more information about using dual-event servers, see Dual-Event Servers in
the chapter “Introduction,” in the Unicenter AutoSys Job Management for
Windows Installation Guide. For information on installing and configuring dual-
event servers, see Installing Dual-event Servers in the chapter “Advanced
Configurations,” in the Unicenter AutoSys Job Management for Windows
Installation Guide.

15–12 User Guide

 Event Servers

Administrator Event Server Screen

Using the Event Server screen, you can view and modify the database-specific
settings, and you can configure Unicenter AutoSys JM 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.

To move to the Event Server screen:

Do one of the following:

■ Select Event Server from the AutoSys menu.

or:

■ Click the Event Server button on the toolbar.

The following illustration shows the Event Server screen for Sybase and
Microsoft SQL Server installations.

Note: To modify the settings on this screen, you must have Windows
Administrators group privileges.

Administrator 15–13
Event Servers

Defining Event Server Configuration Parameters

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

The “Event Server A” area 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 Unicenter AutoSys JM
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.

WARNING! When you enter the event server information, it must be exactly as
it is defined for the database, including case.

Note: You can enable and define either Event Server A or Event Server B to be in
single-server mode.

Name or Alias UNIX parameter: EventServer

The Name parameter specifies a logical name used to locate the database. When
performing database queries, Unicenter AutoSys JM 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 values in the
Name field.

Note: In the UNIX configuration file, the EventServer parameter is defined by

the Name: Database combination.

Enable Use the Enable button to enable the associated event server, either when
enabling a down server or when implementing dual-server mode.

15–14 User Guide

 Event Servers

Disable Use the Disable button to stop an event server and return to single server mode.
If you click this button, it sets the associated event server status to DOWN. If
you disable a server, you must stop and restart the event processor, so that it is
restarted in single server mode.

Host The Host parameter specifies the name of the machine on which the associated
event server runs. For dual server mode, we recommend that the two event
servers reside on two different databases, running on different host machines,
to avoid a single point of failure.

For Oracle installations, this field is disabled.

Port The Port parameter specifies the port number for the TCP/IP socket connection
between the event server and the remote agent. This is the port number on
which the event server “listens” when waiting for requests. Note that this
number should be different than the value in the TCP/IP Port field in the
Remote Agent screen.

For information on the remote agent port number, see the topic “Defining
Remote Agent Configuration Parameters,” in this chapter.

Database UNIX parameter: EventServer

The Database parameter specifies the particular database for the associated event
server instance. Typically, this name is autosys, and for dual server mode, this
can be the same value for both event servers.
For Oracle installations, this field is disabled.

Note: In the UNIX configuration file, the EventServer parameter is defined by

the Event Server Name: Database combination.

Status The Status field indicates whether the associated database is UP or DOWN.
For information on dual server mode and how to re-enable a DOWN event
server, see Event Server Rollover Recovery in the chapter “Maintaining ,” in this
guide.

Database Provider Specifies the provider (manufacturer) of the Relational Database Manager
System (RDBMS) that is being used for the AutoSys database. This is a read-
only field; it is for informational purposes only.

Administrator 15–15
Event Servers

Database Rollover The Database Rollover Has Occurred check box is checked when there has been
Has Occurred 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 the chapter “Maintaining,” in this guide.

DB Event Reconnect UNIX parameter: DBEventReconnect

The Reconnect parameter specifies the number of times that an event processor
should attempt to connect to the event server before shutting down, or before
rolling over to single server mode.

In single server mode, the DB Event Reconnect value is a number, with a default
setting of 50. This setting specifies that the event processor should attempt to
connect to the event server 50 times before shutting down. That is, the event
processor attempts to reconnect 50 times both on startup and when there is a
connection problem.

In dual server mode, DB Event Reconnect contains two values, such as the
default setting of 50, 5 (which is set only if you initially install dual severs). If
you add a second server after completing the installation process, you must set
the DB Event Reconnect value appropriately.

The 50, 5 values 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 Unicenter AutoSys JM is in single server
mode, the event processor will attempt to reconnect to the remaining event
server 50 times before shutting down.

Upon startup, the event processor attempts to connect to the event servers 5
times. If the event processor is unable to connect to both databases, it assumes
there is a connection or configuration problem, and will gracefully shutdown.

15–16 User Guide

 Event Servers

Database Wait Time UNIX parameter: DBLibWaitTime

The Database Wait Time parameter indicates the amount of time the event
processor waits before it breaks a connection with an event server that is in an
unknown state. That is, the event processor maintains and checks its connections
with the databases, 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, Unicenter
AutoSys JM will attempt to reconnect to the database a specified number of
times. If you see the database connections timing out at a frequent rate, it
probably indicates some kind of machine or event server contention problem.

Note: If you set this value to 0, it means that no time-out value is to be applied.
In other words, there are infinite connections. Because it can cause the event
processor to hang, using the value of 0 is not recommended.

Database Alarm UNIX parameter: DBAlarmReconnect

Reconnect

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

Administrator 15–17
Event Processors

Event Processors
The event processor interprets and processes all the events it reads from the
database. The event processor is the program, running as a Windows service,
which actually controls Unicenter AutoSys JM—it schedules and starts jobs.

The event processor is a Windows 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 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 Unicenter AutoSys JM 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 the chapter “Introduction,” in the Unicenter AutoSys Job
Management for Windows Installation Guide. For information on installing
dual-event servers, see Installing a Shadow Event Processor in the chapter
“Advanced Configurations,” in the Unicenter AutoSys Job Management for
Windows Installation Guide.

15–18 User Guide

 Event Processors

Administrator Event Processor Screen

The Event Processor screen (see the following illustration) 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:

Do one of the following:

■ Select Event Processor from the AutoSys menu.

or:

■ Click on the Event Processor button on the toolbar.

Note: To modify the settings on this screen, you must have Windows
Administrators group privileges.

Administrator 15–19
Event Processors

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 Unicenter 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 the topic Using the Services Screen in this
chapter).

EP Count The EP Count parameter specifies the number of concurrent Event Processors
the user is able to run at one time (default is set to 1.) Each Event Processor is
able to retrieve an event out of the database and process it independently. The
maximum number of Event Processors the can run at one time is 256.

Note: The number of Event Processors you elect should be equal to the number
of processors available on the hardware Unicenter AutoSys JM is installed on.

For Example: Running a dual CPU machine would give you an EP Count of 2.

Shadow Machine The Shadow Machine parameter specifies the host name 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
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.

15–20 User Guide

 Event Processors

Third Machine UNIX parameter: ThirdMachine

When running a shadow event processor, the third machine is used to resolve
possible contentions between the two event processors, and to ensure that only
one of the processors is running at any given time. Before the shadow event
processor takes over, or if the primary event processor cannot signal the shadow
event processor, the processor that is taking over connects to this third machine
and creates a “dibs” file that will lock the other processor out.
Note: The third machine must have a remote agent installed on it, and it must
have a valid client license. In addition, the third machine must be defined by the
same AutoSys instance and installed on the same type of machine as the primary
and shadow event processors are installed on, either Windows or UNIX.

Network Machine List UNIX parameter: EDMachines

The Network Machine List parameter contains a comma-separated list of valid

server machines on the network where event processors may have been started,
or may 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
may 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.

Administrator 15–21
Event Processors

Enterprise Wide UNIX parameter: AutoRemoteDir

Logging Directory
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 a
Windows 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. A Windows 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 the topic “Defining Remote
Agent Configuration Parameters,” in this chapter.

Database UNIX parameter: DBMaintCmd

Maintenance
Command
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 about the DBMaint.bat batch file, see the chapter
“Maintaining,” in this guide.

15–22 User Guide

 Event Processors

Database UNIX parameter: DBMaintTime

Maintenance Time
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 we highly recommend that you configure your system to backup
the database during this maintenance cycle.

EP Heartbeat Interval The EP Heartbeat Interval parameter specifies the time interval (in seconds) the
Primary Event Processor (EP [1]) should use when checking the status of the
other Event Processors (default is set to 10.) If the Primary Event Processor
detects one of the other Event Processors are down, it will attempt to restart it.

Note: If you are not running multiple Event Processors, you do not need to set
this parameter.

Shadow Ping Delay The Shadow Ping Delay parameter specifies how often the Shadow machine
should ping the Primary Event Server Machine (in seconds.)

Note: The default setting of the Shadow Ping Delay is set to 60 seconds.

DB Poll Interval The DB poll Interval parameter specifies the time interval (in seconds) the
Event Processor should retrieve events from the database.

Note: The default setting of the DB Poll Interval is set to .5 seconds.

Administrator 15–23
Event Processors

Maximum Log Size The Maximum Log Size parameter specifies the maximum size of the event
processor log file. The event processor reads this setting on startup and checks
the file size. If the file is the indicated maximum size, the event processor
deletes it.

When you change this number the new size does not affect until you start the
event processor again. The event processor will read the new number only on
the subsequent startup processes.

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

File System Threshold UNIX parameter: FileSystemThreshold

If the amount of available disk space falls below that specified by the File System
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!

If the amount of disk space falls below 8 KB, 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 File System Threshold setting is 32 KB. Valid settings must be less
than 10 MB and greater than 8192 bytes.

If you set the File System Threshold setting on a remote agent machine, the
setting applies to the space available for the remote agent log file. The default
File System 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 Unicenter AutoSys Administrator for the event processor machine).

15–24 User Guide

 Event Processors

You can change the File System 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 10 MB and greater than
8192 bytes.

If the amount of available disk space falls below that specified by the File System
Threshold setting, the remote agent writes dots to the remote agent log file. If the
available space drops below 8 KB, the remote agent issues a warning and stops
writing to the remote agent log file, but the remote agent service keeps running.

Event Transfer Wait UNIX parameter: EvtTransferWaitTime

Time

The Event Transfer Wait Time parameter specifies the time-out delay for
transferring events while in dual-server mode. That is, when in dual-server
mode, an event that is missing from one event server is copied over to the second
server after this time-out delay.

Error Time Interval UNIX parameter: EDErrTimeInt

The Error Time Interval parameter specifies the time interval that is used with
the Number of Errors setting (see following) to determine if Unicenter AutoSys
JM should shut down the event processor. If the specified number of errors
occurs within the error time interval, Unicenter AutoSys JM 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 reissuing 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.

Administrator 15–25
Event Processors

Number Errors UNIX parameter: EDNumErrors

The Number Errors parameter specifies the maximum number of errors that can
happen within the Error Time Interval (see previous) when determining if
Unicenter AutoSys JM should shut down the event processor. If the specified
number of errors occurs within the error time interval, Unicenter AutoSys JM
shuts down the event processor 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.

Job HeartBeat UNIX parameter: Check_Heartbeat

Interval

The Job 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 Unicenter AutoSys JM . 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 Event Servers. 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
servers, 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.

15–26 User Guide

 Event Processors

Startjob Poll Interval The Startjob Poll Interval parameter controls how long the inetd waits between
job starts on the same Remote Agent machine. The default setting is set to .05
seconds.

Note: Setting the Startjob Poll interval too low for your specific hardware could
adversely affect performance. In addition, you must ensure your machines
processor is fast enough to handle starting jobs at a faster interval. Otherwise,
there will be frequent socket connection failures, which will cause numerous job
restarts.

Machine Method UNIX parameter: MachineMethod

The Machine Method parameter specifies the method Unicenter AutoSys JM 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 Windows is vmstat (on UNIX, rstatd is
also supported).

For information about rstatd, see the chapter “Configuring,” in the Unicenter
AutoSys Job Management for UNIX User Guide.

XInstance DB Drop UNIX parameter: XInstanceDBDropTime

Time

The XInstance DB Drop Time parameter specifies how an instance will connect
with a different 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.

Administrator 15–27
Event Processors

Max Restart Wait UNIX parameter: MaxRestartWait

The MaxRestartWait parameter specifies the maximum amount of time (in

seconds) Unicenter AutoSys JM 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
Unicenter AutoSys JM will wait before attempting to 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 counter, which indicates
the number of times Unicenter AutoSys JM 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 in this chapter.

Max Restart Trys UNIX parameter: MaxRestartTrys

The MaxRestartTrys parameter specifies the maximum number of times that

Unicenter AutoSys JM will try to start a job. Unicenter AutoSys JM may 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 (for example, Unicenter
AutoSys JM 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 n_retrys in the
chapter “JIL/GUI Job Definitions,” in the Unicenter AutoSys Job Management
Reference Guide.

15–28 User Guide

 Event Processors

Unicenter Events The Unicenter Events parameter specifies what messages should be sent to the
Unicenter Event Management Console. Use of this option requires the
Unicenter NSM Event Management component be installed locally on the
machine where AutoSys is installed. By default Unicenter Events is set to 0.

The parameter values for Unicenter Events are as follows:

■ 0–Reports no events to Unicenter (default setting)

■ 1–To log all Alarms to the Event Console.

■ 2–To log all Alarms and job completions.

■ 3–To log all events that are generated to the Event Console.

Note: Any other value in the Unicenter Events field will be ignored, and no
messages will be sent to the Unicenter Event Management Console.

Restart Factor UNIX parameter: RestartFactor

The Restart Factor parameter specifies a factor. This value is used in calculating
the Wait Time, which is the interval in seconds that Unicenter AutoSys JM 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, previously discussed.
The Restart Constant parameter is described in this chapter.

Kill Signals UNIX parameter: KillSignals

The Kill Signals parameter specifies a comma-separated list of signals to send to

a job whenever the KILLJOB event is sent. If the job to be killed is running on a
Windows 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.

Administrator 15–29
Event Processors

Microsoft Windows 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 (for example, *.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 Constant UNIX parameter: RestartConstant

The Restart Constant parameter specifies a constant value. This value is used in
calculating the Wait Time, which is the interval in seconds that Unicenter
AutoSys JM 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
“MaxRestartWait” MaxRestartWait.

15–30 User Guide

 Event Processors

Event Processor Options

Chase On Startup The Chase On Startup setting indicates whether the 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 chase in the chapter “Commands,” in
the Unicenter AutoSys Job Management Reference Guide.

Global Auto Hold The Global Auto Hold setting indicates whether global auto hold mode is on or
off. You should turn on global auto hold when you are going to restart an event
processor after a shutdown 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.

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 about Global Auto Hold, see Starting the Event Processor
in the chapter “Maintaining ,” in this guide. For information on using the
Scheduler Console, see the chapter “Scheduler Console,” in this guide.

Clean Temporary Files UNIX parameter: CleanTmpFiles

The Clean Temporary Files setting indicates whether the remote agent should
remove its temporary log file upon successfully completing a job. For every job
that runs, a file is created in the remote agent log directory. If you check the
Clean Temporary Files box, Unicenter AutoSys JM 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.

Administrator 15–31
Event Processors

Remote Profile UNIX parameter: RemoteProFiles

Logging

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 Windows, 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 the chapter “Configuring,” in the Unicenter AutoSys Job
Management for UNIX User Guide.

Append stdout/stderr UNIX parameter: AutoInstWideAppend

The Append stdout/stderr setting specifies whether the instance will overwrite
or append information to the standard output and standard error files.

If this check box is not selected, then the files are overwritten, which is the
default behavior. If this check box is selected, the new output and error
information is appended to the files

When determining its behavior, Unicenter AutoSys JM checks the following (in
this order):

1. Checks the AutoSys job definition for append or overwrite notation. If there
is a notation, Unicenter AutoSys JM uses the indicated behavior, and does
not check other settings.

To set the behavior at the job definition level, place the appropriate notation
as the first characters in the std_err_file or std_out_file specification in JIL, or
in the File to redirect standard output and File to redirect standard error
fields on the Job Editor Command Info tab. Use the following notation to
specify whether the files should be appended to or overwritten:
> Overwrite file
>> Append file

15–32 User Guide

 Event Processors

2. Checks the AutoMachWideAppend variable setting, which you can set in the
Unicenter AutoSys Administrator System Information screen (see the topic,
“AutoMachWideAppend.)” If this variable is set for the specific machine,
Unicenter AutoSys JM uses the indicated behavior, and does not check other
settings.

3. Checks the Append stdout/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.

Event Serialization This Event Serialization setting only allows one event processor to retrieve an
event from the database at a given time, preventing deadlock conditions
between multiple event processors. If the Event Serialization option is not
selected, multiple Event Processors will be able to retrieve events from the
database without serialization. It is possible to experience database deadlocks
without running the event serialization option. If this condition occurs, the
process that received the deadlock condition will retry.

Note: This option is only available when running multiple event processors.

Multiple EP Restart When the Multiple EP Restart option is checked, the primary event processor
will try to automatically restart any of the secondary event processors should it
go down. The primary event processor will not be restarted, should it go down.

Note: This option is only available when running multiple event processors.

Administrator 15–33
Event Processors

Broker Options

AutoSys Agent UNIX parameter: AutoSysAgentSupport

Support

The Unicenter AutoSys Agent Support setting indicates whether an instance can
start jobs on Unicenter AutoSys Agent machines. If the Unicenter AutoSys Agent
Support check box is checked on, the event processor can send jobs to Unicenter
AutoSys Agent machines. If the check box is not checked (the default setting),
the event processor will not send jobs to Unicenter AutoSys Agents.

For information on Unicenter AutoSys JM Connect and Unicenter AutoSys

Agent support, see Appendix a, “Integrating with the Mainframe and Unicenter
AutoSys Agents for AS/400 and OpenVMS,” in this guide.

Receive Remote Job The Remote Job Submissions setting specifies whether or not an instance can
Submissions receive job submissions from a mainframe or a Unicenter Manager. If the check
box is not checked (the default setting,) the Instance will not be able to receive
jobs.

Note: This option is only effective upon the initialization of the Event
Processor/Broker. When this option is selected, that Broker will start the
asbIIIsr1 process, which is responsible for processing remote job submissions.

15–34 User Guide

 Notification Mechanism

Notification Mechanism
The notification mechanism provides a method for communicating problems to
administrators in a manner that is external to the event system. That is, for
certain types of alarms, you can configure Unicenter AutoSys JM 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 events occur.

You can configure Unicenter AutoSys JM 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 Unicenter AutoSys JM should invoke a user-defined callback for

one of these alarms, enter the path and executable name in the appropriate field
on the Unicenter AutoSys Administrator Notifications screen.

Administrator 15–35
Notification Mechanism

Administrator Notifications Screen

Using the Unicenter AutoSys Administrator Notifications screen (see the

following illustration), 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:

Do one of the following:

■ Select Notifications from the AutoSys menu.

or:

■ Click the Notifications button on the toolbar.

Note: To modify the settings on this screen, you must have Windows
Administrators group privileges.

15–36 User Guide

 Notification Mechanism

Notification Example

If you want Unicenter AutoSys JM 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, Unicenter AutoSys JM will pass pager a
numeric code and a text message. You must code pager to accept these
parameters.

Defining Notifications Configuration Parameters

This section lists and describes the configuration parameters located on the
Notifications screen. When specifying a user-defined routine, you must enter the
complete path and executable name in the appropriate field.

Database Rollover UNIX parameter: DB_ROLLOVER

The Database Rollover parameter specifies the user-defined routine that

Unicenter AutoSys JM should call when it has rolled over from dual server mode
to single server mode.

Database Problem UNIX parameter: DB_PROBLEM

The Database Problem parameter specifies the user-defined routine that

Unicenter AutoSys JM should call when there is a problem with one of the
AutoSys databases.

Event Processor UNIX parameter: EP_ROLLOVER

Rollover

The Event Processor Rollover parameter specifies the user-defined routine that
Unicenter AutoSys JM should call when the shadow event processor is taking
over processing.

Event Processor UNIX parameter: EP_SHUTDOW

Shutdown

The Event Processor Shutdown parameter specifies the user-defined routine that
Unicenter AutoSys JM 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.

Administrator 15–37
System Information

Event Processor High UNIX parameter: EP_HIGH_AVAIL

Availability

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.

System Information
Access to Unicenter AutoSys JM software is controlled by three environment
variables and the Windows Registry settings that you enter through the
Unicenter AutoSys Administrator. In addition, the database often has associated
environment variables and configuration files. For Unicenter AutoSys JM 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
Windows system level and at the Unicenter AutoSys JM level. The Unicenter
AutoSys Administrator System Information screen displays the variables that are
set at the Unicenter AutoSys JM level; these variables are set when you run the
Unicenter AutoSys JM software. You can modify and add to these standard
environment variables.

Note: The environment variables for the AutoSys database are set at the
Windows system level.

15–38 User Guide

 System Information

Administrator System Information Screen

Using the Unicenter AutoSys Administrator System Information screen you can
view and modify the settings of environment variables that are necessary. In
addition, the System Information screen provides Version and Build information
on the Unicenter AutoSys JM that you are running.

The Administrator System Information screen reflects the information that

Unicenter AutoSys JM 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:

Do one of the following:

■ Select System Information from the AutoSys menu.

or:

■ Click the System Information button on the toolbar.

Administrator 15–39
System Information

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.

■ To delete an environment variable:

1. Double-click on the Environment Variable in the list that you want to

delete.

2. Click Delete, and click Apply or OK.

Note: To modify the settings on this screen, you must have Windows
Administrators group privileges.

System Information Configuration Parameters

This section lists and describes the specific variable settings that are located on
the System Information screen by default. These are the environment variables
that are set in the 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.

For information on ISDBGACTIV see the Appendix “General Debugging” in this

guide.

Note: The variables that appear on this screen are set when you open an
AutoSys instance command prompt window.

AUTOSYS UNIX parameter: $AUTOSYS

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

AUTOROOT UNIX parameter: $AUTOROOT

15–40 User Guide

 System Information

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

AUTOSERV UNIX parameter: $AUTOSERV

The %AUTOSERV% environment variable specifies the instance ID. The instance
ID is the capitalized three-letter name that identifies a specific 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 Unicenter AutoSys Administrator. To change the instance ID, you
must uninstall Unicenter AutoSys JM, and reinstall it using the new ID.

For more information about AutoSys instances, see the topic “Instances,” in this
chapter.

AUTOUSER UNIX parameter: $AUTOUSER

The %AUTOUSER% environment variable specifies the full path to the directory
containing the 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 about the config.EXTERNAL file, see the Configuring
Cross-instance Job Dependencies section in the chapter “Advanced
Configurations,” in the Unicenter AutoSys Job Management for Windows
Installation Guide.

DSQUERY The %DSQUERY% environment variable specifies the name of the Sybase event
server. The default setting is AUTOSYSDB.

If you are using an Oracle or Microsoft SQL Server database, this field is not
displayed.

Administrator 15–41
System Information

AutoMachWide You can set the %AutoMachWideAppend% variable to override, at the machine
Append level, the “Append stdout/stderr” configuration parameter, which is set in the
Unicenter AutoSys Administrator Event Processor screen (see “Append
stdout/stderr” AutoInstWideAppend). Using this variable, you can set up each
client machine to override global behavior.

If you set this variable to yes, the log files are appended. If you set it to no, the
log files are replaced. If you do not set this variable, the behavior set by the
“Append stdout/stderr” global configuration parameter is used.

Note: On UNIX, the AutoMachWideAppend parameter is located in the

/etc/auto.profile file.

Version The Version field indicates the Unicenter AutoSys JM for Windows version
number (for information purposes only).

Build The Build field indicates the Unicenter AutoSys JM for Windows build number.
This field is read-only; it is for informational purposes only.

15–42 User Guide

 Sounds

Sounds
If you have a Monitor/Browser Editor running on a Windows system that
supports sound, you can associate sounds with specific events, such as 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 specific
events. Then, once you have enabled and defined these sounds, Unicenter
AutoSys JM uses the defined sounds to announce the events as they occur.

Note: All sounds also can be managed using the Sound option of the Windows
Control Panel. In addition, you can record new sounds with the Windows Sound
Recorder in the Accessories program group. For instructions on how to record
sounds, see your Windows documentation.

For information on the Monitor/Browser Editor, see the chapter “Monitoring

and Reporting on Jobs,” in this guide.

Administrator Sounds Screen

Using the Unicenter AutoSys Administrator Sounds screen (see the following
illustration), you can turn sound on and off as well as specify the sounds you
want played for 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:

Do one of the following:

■ Select Sounds from the AutoSys menu.

or:

■ Click on the Sounds button on the toolbar.

Administrator 15–43
Sounds

Note: Changes you make to the sound settings are saved for the current, logged
on Windows user. If you log on as a different user, these modified settings will
not be in effect.

Defining Sounds Configuration Parameters

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

AutoSys Alarm The AutoSys Alarm setting specifies the location of the *.wav file that is played
for AutoSys Alarm events.

For a list of Alarms, see the Alarms section in the chapter “System States,” in the
Unicenter AutoSys Job Management Reference Guide.

AutoSys Big Alarm The AutoSys Big Alarm setting specifies the location of the *.wav file that is
played for the AutoSys Big Alarm. An AutoSys Big Alarm announces an event
that is not a job CHANGE_STATUS event, but still returns a FAILURE or
TERMINATED status.

AutoSys Default The AutoSys Default setting specifies the location of the *.wav file that is
played for all events that do not fit in the other Sounds categories (that is,
Alarm, Big Alarm, Success, and Failure).

15–44 User Guide

 Sounds

AutoSys Success The AutoSys Success setting specifies the location of the *.wav file that is
played for an AutoSys job SUCCESS event. A SUCCESS event occurs when a
job exits and AutoSys considers it successful, based on the exit code for a
command job or the success conditions for a box job.

AutoSys Failure The AutoSys Failure setting specifies the location of the *.wav file that is played
for an AutoSys job FAILURE status event. A FAILURE event occurs when a job
exits and AutoSys considers it a failure. A job is considered a failure when the
exit code for a command job is greater than the maximum success value
specified for the job, or when the failure conditions for a box job evaluated to
TRUE.

Administrator 15–45
Security

Security
Unicenter AutoSys JM supplies you with several security features. One of these
features is remote authentication. There are two types of remote authentication:

■ Event processor authentication

■ user authentication

You can configure your remote agents so they verify access permission for event
processors and for users. The Unicenter AutoSys 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 Unicenter 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 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 about specifying authorized event processors, see Defining

Remote Agent Configuration Parameters in this chapter. For information on
other types of security features, see the chapter “Security.” For information on
using autosys_secure to turn on remote authentication, see autosys_secure in the
chapter “Commands,” in the Unicenter AutoSys Job Management Reference
Guide.

15–46 User Guide

 Security

User Remote Authentication Example

With user remote authentication turned on, the remote agent follows this
procedure when trying to log on to a machine to run a job.

To log on to 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 host name 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.

Note: In addition to checking the permissions of these various users, the remote
agent makes sure that the Windows user has a valid ID and password entered in
the database. The edit superuser can enter and modify passwords using the
autosys_secure command, and any user that knows an existing user ID and
password can change the password or delete the user and password using the
autosys_secure command.

Administrator 15–47
Security

For more examples of security on Windows, see Examples of Security on

Windows in the chapter “Security.” For information on entering your Windows
user IDs and passwords, see the chapter “Adding the Superusers and the
Windows User IDs and Passwords,” in the Unicenter AutoSys Job Management
for Windows Installation Guide. For information on autosys_secure and turning
on remote authentication, see autosys_secure in the chapter “Commands,” of the
Unicenter AutoSys Job Management Reference Guide.

Administrator Security Screen

Using the Unicenter AutoSys Administrator Security screen (see the following
illustration), 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:

Do one of the following:

■ Select Security from the AutoSys menu.

or:

■ Click on the Security button on the toolbar.

Note: To modify the Trusted Host setting, you must be the edit superuser, and
you must have Windows Administrators group privileges.

15–48 User Guide

 Security

Defining Security Configuration Parameters

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

Trusted Hosts The Trusted Hosts list defines the machine host names or domain names that
are allowed to log on to the client machine to run jobs. You must be the edit
superuser to modify the Trusted Hosts settings. Use the Add Host and Remove
Host buttons to enter or remove the host name in the top field of the Trusted
Hosts list.

Exercise caution when modifying this list, since any user on a designated
Trusted Host host_or_domain is granted logon access, and thus can run jobs on
the client machine.

Trusted Users The Trusted Users list is a group of user@host_or_domain entries that define
who can log on and run jobs on the defining client machine. Trusted Users
permissions are owned and administered by individual users on client
machines. All users can define their own set of Trusted Users on their own
machines. As the current, logged on Windows 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 on to the defining
client machine, as long as they have a valid user ID and password in the
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.

Administrator 15–49
Services

Services
Unicenter AutoSys JM has the following primary components, or services:

■ Remote Agent

■ Event Processor

The Services screen allows to you check the statuses of Services associated with
the instance that you selected in the Instance screen.

Administrator Services Screen

Using the Unicenter AutoSys Administrator Services screen (see the following
illustration), users with Windows 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.

Note: You cannot stop the Event Processor service from this screen. To stop the
event processor, you must be the exec superuser, and you must execute the
sendevent -E STOP_DEMON command at an instance command prompt. When
you are ready to start the event processor again, you can do so from the Services
screen.

15–50 User Guide

 Services

To move to the Services screen:

Do one of the following:

■ Select Services from the AutoSys menu.

or:

■ Click on the Services button on the toolbar.

Note: To modify the settings on this screen, you must have Windows
Administrators group privileges.

Administrator 15–51
Services

Services Screen Components

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

Service The Service drop-down list shows the Services that are installed on the selected
instance. You can select a Service from the drop-down list, and then you can
view and change the Status of the Service.

Status The Status traffic light and the field below indicate the status of the selected
Service.

The traffic light indicates the status of the selected 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 Service—
it corresponds to the traffic light. This value can be “Stopped”, “Updating,” or
“Running.”

Start Service If the Start Service button is enabled, you can click it to start the selected
Service.

Stop Service If the Stop Service button is enabled, you can click it to stop the selected Remote
Agent service. (The Event Processor service cannot be stopped from this screen.
See the note in the next section.)

15–52 User Guide

 Services

Using the Services Screen

Using the Unicenter AutoSys Administrator Services screen, users with

Windows 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 exec superuser, and you must execute the
sendevent -E STOP_DEMON command at an instance command prompt. When
you are ready to start the event processor again, you can do so from the Services
screen.

Administrator 15–53
Chapter

Troubleshooting
16
Problems with Unicenter AutoSys JM usually involve the interactions between
the major components, rather than with the individual components themselves.
This chapter presents a number of common problems, their symptoms, and how
to resolve them. It provides very useful information about troubleshooting the
primary components.

Troubleshooting 16–1
Introduction

Introduction
To troubleshoot Unicenter AutoSys JM 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 components (that is, 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 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.

16–2 User Guide

 Windows Services Troubleshooting

Windows Services Troubleshooting

You can start the event processor and remote agents from the Administrator
Services screen, and you can start the event server (the Sybase, Oracle, or
Microsoft SQL Server service) from the Windows Control Panel’s Services
dialog. You can find details as to why the service did not start in the Windows
Event Viewer in the Administrative Tools program group.

Typically, problems with starting services, using the Administrator Services

screen, indicate that the software was not successfully installed. In these cases,
often the best approach, to remove the existing AutoSys installation and reinstall
it.

To verify that the Event Server service (the database service) is started, look at
the Windows 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 the appendix “Removing

Unicenter AutoSys JM 3.4,” in the Unicenter AutoSys Job Management for
Windows Installation Guide.

For information on starting services with the Administrator, see Services in the
chapter “Administrator,” in this guide.

Troubleshooting 16–3
Event Server Troubleshooting

Event Server Troubleshooting

Event Server Is Down (Sybase)

Symptoms

1. When trying to start xql, you get a message like:

DB-Library error: dbproc NULL
Error in SybInit: dbopen failed

2. When running programs like autorep or autosc, you get a message like:
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 the following:
Couldn’t connect with Server: AUTOSYS:autosys

4. You are unable to insert keys with gatekeeper.

Resolution

This indicates that either the data server is down, or the process in question is
unable to access it. To confirm that the data server is down, log onto the server
machine and run the chk_auto_up utility.

If you are running 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 bundled Sybase database on a Windows machine, you
can check the status of the database using the Services dialog in the Windows
Control Panel on that machine. The name of the bundled Sybase Service is
SYBSQL_LOCAL. In addition, you can use the Windows Services dialog to start
the Sybase Service.

If the database service is running, the problem could be that you are pointing to
the wrong data server. The system DSQUERY environment variable points to the
name of the data server (typically AUTOSYSDB). If it is not set properly and you
are not specifying a data server name to xql (using the -S server option), then xql
will fail.

16–4 User Guide

 Event Server Troubleshooting

You can view and modify the setting of the DSQUERY environment variable
using the Unicenter AutoSys Administrator, which you can open from the
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 the chapter “Introduction,” in the Unicenter AutoSys Job Management for
Windows Installation Guide. For information on using the Unicenter AutoSys
Administrator, see the chapter “Administrator,” in this guide.

Sybase Deadlock

Symptom

A message similar to the following appears in the event processor log when
viewed with the autosyslog -e command or in the Sybase error log
(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.

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 data server detects the situation and chooses the user whose process has
accumulated the least amount of CPU time as the “victim.” The data server 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.

Troubleshooting 16–5
Event Server Troubleshooting

Not Enough User Connections (Bundled Sybase)

Symptoms

Users cannot make connections to the database; they cannot start the GUI or
send events. When you check the Sybase error log
(Autosys.instance\sql10\log\sqlsrvr.log) you see one or both of the following
errors:
Not enough User Connections (Sybase error 1601)
No Pss structures available for new process

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 Unicenter AutoSys JM 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.

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;

Results similar to the following are displayed:

--------------
3
return status 0, rows affected 1

4. Enter:
1> select count(*) from master..sysdevices where mirrorname is not NULL;

Results similar to the following are displayed:

--------------
0
return status 0, rows affected 1

16–6 User Guide

 Event Server Troubleshooting

5. Enter:
1> select count(*) from master..sysservers where srvname != @@servername;

Results similar to the following are displayed:

--------------
1
return status 0, rows affected 1

The maximum number of user connections that you can set is

@@max_connections minus the sum of the results of the last three queries. In the
example results to the above queries, the maximum number of user connections
is 249.

To increase the number of user connections::

1. At the isql or xql prompt, enter the following command to specify the
number of user connections you want:
1> sp_configure “user connections”, number;

where:

number Is the number of user connections you want.

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

Troubleshooting 16–7
Event Server Troubleshooting

archive_events Fails (Bundled Sybase)

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.

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;

16–8 User Guide

 Event Processor 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 row count incrementally. To begin
with try doubling the number. If this fails at any time, decrease the row
count and try again. When the row count is large, log out of the data server.

5. Log out of the data server, and then run archive_events. Begin with a large
number of days and work down until you reach your target number of days.
For example:
archive_events -n 30
archive_events -n 10

Event Server Unable to Extend Tablespace (Oracle)

Symptom

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

Resolution

Ask your database administrator to increase the size of the tablespace in your
Oracle database. Then, restart your event processor.

Event Processor Troubleshooting

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 instance command

prompt (which you open from the 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.

Troubleshooting 16–9
Event Processor Troubleshooting

Everything that the event processor does, in the order it was done, is in this file.
Network problems are usually reflected in this file as well. This file is very useful
for reconstructing what happened when a problem occurs.

Event Processor Is Down

Symptoms

1. Jobs do not start.

2. When chk_auto_up is run, it returns a message similar to this (assuming

your event processor was installed on the machine “EPhost”:)
Checking machine: EPhost
No Event Processor is running on machine: EPhost.

8. The event processor log viewed with the autosyslog -e command has not
registered a date and timestamp for a period of time. The event processor log
should register date and timestamps every minute.

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 Unicenter 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 Unicenter 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, and 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 Unicenter AutoSys Administrator, see the chapter

“Administrator,” in this guide.

Event Processor Will Not Start

Symptom

16–10 User Guide

 Event Processor Troubleshooting

The autosyslog -e command displays a message indicating that the Time Key is
not valid.

Resolution

Install your Time Key as described in the chapter “Entering License Keys,” in the
Unicenter AutoSys Job Management for Windows Installation Guide.

Symptom

The autosyslog -e command displays messages indicating that it cannot connect

to the database.

Resolution

The 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 in this chapter. 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.

Symptom

Troubleshooting 16–11
Event Processor Troubleshooting

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 Unicenter 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 Windows event log message. The Event Log Viewer is
located in the Administrative Tools program group.

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.

Event Log Message

Incorrect options have been set to event_demon. It must not have been
set properly.

Resolution This occurs if you have modified the Windows Registry so that the -A option is
not used when starting the Event Processor service. To fix this problem with the
Windows Registry settings, you must uninstall AutoSys, and then reinstall
Unicenter AutoSys JM.

Event Log Message

The environment variable AUTOSYS is not set.

Resolution The %AUTOSYS% system environment variable is not available to the event
processor. In the Windows 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 UnicenterAutoSys Administrator System Information screen.)

Event Log Message

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 Unicenter AutoSys JM, and reinstall it into a
directory path that is fewer than 80 characters.

16–12 User Guide

 Event Processor Troubleshooting

Event Log Message

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 and reinstalling the software.

Event Log Message

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

Event Log Message

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

Event Log Message

The AutoSys environment has not been installed correctly.

Resolution The event processor launches chk_auto_up upon initialization. That process
reported that the setup is incorrect. Uninstall and reinstall the software.

Event Log Message

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 16–13
Event Processor Troubleshooting

Event Log Message

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.

Event Log Message

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

16–14 User Guide

 Remote Agent Troubleshooting

Remote Agent Troubleshooting

Remote Agent Verification

If you suspect problems with the remote agent, you can use autoping to verify
your suspicions.

autoping

The autoping command is used to test the connections between the event
processor and the remote agent. If you use the autoping -m client_hostname
command, and it does not return an error, the remote agent should start
properly.

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:
autoping -m machine -D

Instead of a single machine, you can enter autoping -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!

Troubleshooting 16–15
Remote Agent Troubleshooting

Remote Agent Will Not Start

The symptoms in this section are similar and result from network problems.

Symptom

The autosyslog -e command displays a message like:

Attempting to connect to AutoSys Remote Agent
Service on socket=5280: Interrupted function.
Could NOT connect to machine: spartacus

Resolution

Either there is a network communication problem, or the client machine is down.

You must resolve the network or machine problems before jobs can run on that
machine.

Symptom

The autosyslog -e command displays a message like:

Attempting to connect to AutoSys Remote Agent
Service on socket=5280: Connection Refused
Could NOT connect to machine: spartacus.

The remote agent may not be installed properly.

Resolution

Either the Remote Agent service is not started, or Unicenter AutoSys JM 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
Unicenter AutoSys Administrator from the AutoSys program group, and follow
these steps:

1. Select set Computer and Instance, and click OK. This action enables the
menu items, and their corresponding toolbar buttons.

2. Move to the Services screen by selecting Services from the menu or clicking
the Services button (traffic light) on the toolbar.

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.

16–16 User Guide

 Remote Agent Troubleshooting

After the Remote Agent service is started, verify that the port numbers are
synchronized using the Unicenter AutoSys Administrator. To do so, follow these
steps:

1. On the machine where the Remote Agent service is located, start the
Unicenter AutoSys Administrator and check the Remote Agent Port
Number, which is located on the Remote Agent screen.

2. On the event processor machine, check the Remote Agent Port Number in
the same fashion.

3. If the port number settings are different, synchronize the numbers by

modifying the incorrect one.

For information on the Unicenter AutoSys Administrator, see the chapter

“Administrator,” in this guide.

Remote Agent Starts, Command Runs: No RUNNING Event Is Sent

Symptoms

1. Job is stuck in STARTING state.

2. This problem is detected either in the Event Processor window (or log) or in
the results of running the autorep command on the job, when the following
event appears, then nothing else, yet the job does run to completion on the
client machine:
CHANGE_STATUS Status: STARTING Job: test_install

Resolution

This is a common problem and is nearly always the result of the remote agent
being unable to contact the event server. First, 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, the usual cause of this
connection problem is that 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 16–17
Remote Agent 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 Unicenter 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 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 run 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
Unicenter 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 Unicenter AutoSys
JM 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 Unicenter AutoSys
JM is using for the %SYBASE% variable, look at the Control Panel System dialog.

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

■ User accounts have been added on the database machines for all users.

16–18 User Guide

 Remote Agent Troubleshooting

If you do not configure your Microsoft SQL Servers 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 databases, because the owner of the job does not
have proper permissions on that database machine.

If you are using Oracle, check for the following:

1. Check that the Oracle TNS names file, TNSNAMES.ORA, exists, is readable,
and contains the correct information for the event server. By default, the TNS
names file is in the following location:
\ORANT\NETWORK\ADMIN\TNSNAMES.ORA

2. Check that the Oracle TNS names file has a SQL*Net V2 formatted entry for
the event server.

For information on using the Unicenter AutoSys Administrator, see the chapter
“Administrator,” in this guide.

Testing the Setup To test that everything is set up properly, try to log onto the event server from
the client machine, using the xql utility (for Sybase), the SQL*Plus command
language interface (for Oracle), or the ISQL/w graphical query interface (for
Microsoft SQL Server). When you log onto the event server, use the “autosys”
user and password.

Troubleshooting 16–19
Remote Agent Troubleshooting

xql Will Not Start (Sybase Only)

Symptom

From the remote machine, xql returns the following message:

DB-Library error: dbproc NULL
Error in SybInit: dbopen failed

Resolution

Check the following:

1. Determine if the data server is started and running, and start it if it is not
running.

2. Do one of the following:

■ Verify that the DSQUERY environment is set to the proper data server.

■ Run xql with the -S and -D options to specify the correct data server 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 in Remote Agent Starts, Command Runs: No RUNNING Event is
Sent in this chapter.

16–20 User Guide

 Job Failure Troubleshooting

Job Failure Troubleshooting

Remote Agent Will Start: Command Will Not Run

Each time the remote agent is started on a machine, it creates the following log
file:
AutoRemoteDir\auto_rem.pid

where:

AutoRemoteDir Is the Remote Agent Local Agent Logging Directory specified in the Unicenter
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 file name:
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 databases, which is the most common problem.

Troubleshooting 16–21
Job Failure 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 Unicenter 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 Unicenter AutoSys Administrator Event Processor
screen.

For information on the Unicenter AutoSys Administrator, see the chapter

“Administrator,” in this guide.

Symptoms

The event processor log as viewed with the autosyslog -e command displays a
message like:
Agent remote authentication!
Error:<Remote Authentication has FAILED for
User: USER@HOST on machine:RAHOST.>

In addition, the remote agent log as viewed with the autorep -J job_name
command might display the following message:
Remote Authentication has FAILED for User:USER@HOST
on machine:RAHOST.
Message: Couldn’t find valid entry in security key.

16–22 User Guide

 Job Failure Troubleshooting

Resolution

The job is trying to run on a host that is different than the host or domain on
which the job was defined, and security (remote agent user authentication) has
denied access for the host or domain on 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 edit superuser can log on to the RAHOST machine and add a Trusted
Host entry for HOST to the Trusted Hosts list on the Unicenter AutoSys
Administrator Security screen.

■ 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 Unicenter 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 a message similar to:

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 log as viewed with the autorep -J job_name
command could display 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 a message similar to:

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.

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 autosys_secure in
the chapter “Commands,” of the Unicenter AutoSys Job Management for
Windows and UNIX Reference Guide.

Symptoms

Troubleshooting 16–23
Job Failure Troubleshooting

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 Read-only, 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 where the job command resides 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.

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 Job Profiles in the chapter “Jobs,” in
this guide.

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

16–24 User Guide

Appendix Integrating with the Mainframe
and Unicenter AutoSys Agents for
A AS/400 and OpenVMS
Unicenter AutoSys JM enterprise-wide scheduling lets you integrate jobs with
Unicenter AutoSys Agents for AS/400, OpenVMS, and with various scheduling
products on the mainframe. The following types of integration are supported:

■ Jobs can be defined to conditionally start based on the status of jobs running
on OS/390, AS/400, and OpenVMS.

■ Unicenter AutoSys JM can schedule jobs on any of those machines as well.

■ Unicenter AutoSys JM can receive work from other agents.

Using cross-platform job dependency notation, jobs can be defined to

conditionally start based on the status of a job running on the included set of
agent machines. You can also create jobs that will run on any of the agent
machines (if the agent machine is defined). The term “agent machine” is defined
in the next paragraph.

Integrating with the Mainframe and Unicenter AutoSys Agents for AS/400 and OpenVMS A–1
Definition of Terms

Definition of Terms
The following terms are used in this appendix:

Term Definition
Unicenter AutoSys A job scheduler that runs on UNIX and Windows.
JM

Unicenter AutoSys Software that lets AutoSys communicate with legacy

JM Connect OS/390 schedulers.

CCI Common Communication Interface

Unicenter AutoSys Any remote agent in the set of agents supported by

Agent AutoSys 4.0. These are Unicenter AutoSys JM, AS/400,
Unicenter AutoSys JM Connect, scheduling agents for
VMS, and any Unicenter NSM Job Management Agent.

Agent Machines Any machine which supports an agent.

Unicenter Workload A small set of programs that execute on each target

Agent machine where jobs are processed. The agent performs
the following functions:

■ Receives job requests from one or more managers,

such as Unicenter Workload Server and Unicenter
AutoSys JM Server, and initiates the requested
program, script, JCL or other unit of work.

■ Collects status information about job execution and

file creations.

Sends status information to the requesting workload

manager.

Cross-instance job A dependency between jobs running on different

dependency instances of AutoSys.

Cross-platform job A dependency between jobs running on different

dependency platforms. For example, a job running on a UNIX or
Windows machine can be dependent on a job running on
a mainframe.

A–2 User Guide

 Definition of Terms

Related Documentation

The information presented in this appendix supplements the following

documents:

■ Unicenter AutoSys Job Management for Windows Installation Guide

■ Unicenter AutoSys Job Management Connect Option User Guide

Note: Unicenter AutoSys JM can also drive your legacy mainframe scheduler by
way of the Unicenter AutoSys JM Connect product. See the Unicenter AutoSys
Job Management Connect Option User Guide for instructions on how to install
and use this product.

Integrating with the Mainframe and Unicenter AutoSys Agents for AS/400 and OpenVMS A–3
Job Scheduling for the Enterprise

Job Scheduling for the Enterprise

Unicenter AutoSys JM 4.5 lets you schedule or reroute jobs from multiple
sources throughout the enterprise.

Prerequisites

Before you can implement enterprise job scheduling, you must install and
configure the basic software as instructed in the Unicenter AutoSys Job
Management for Windows Installation Guide. You must also install and
configure Unicenter AutoSys JM Connect or Unicenter AutoSys Agents, or both,
as instructed in the documentation for these components.

The required software and version levels are listed in the following table:

Unicenter AutoSys JM CCI Unicenter AutoSys

Agent
■ Unicenter AutoSys ■ CCI Version ■ TCP/IP
JM version 4.5 for 16123032000
One or more of the
Windows NT/2000 (minimum)
following:
To determine your
■ Unicenter AutoSys
version of CCI, enter the
JM Connect (OS/390)
following command:
■ Unicenter AutoSys
rmtcntrl release
Agent for AS/400 or
OpenVMS

■ Unicenter NSM Job

Management Agent
(for UNIX versions
such as AIX, HP,
OSF, SCO, DGI,
NCR, and so forth,
and Windows)

The following elements must be present on the machine:

■ asbIII
An Unicenter AutoSys JM process that communicates with Unicenter
AutoSys JM Connect or any supported Unicenter AutoSys Agent.

A–4 User Guide

 Configuring for Enterprise Job Scheduling

■ CCI
The Common Communication Interface. See the appendix “Introducing
CCI” in the Unicenter AutoSys Job Management for Windows Installation
Guide.

Configuring for Enterprise Job Scheduling

After installing and configuring the basic software and Unicenter AutoSys JM
Connect or Unicenter AutoSys Agents, or both, you need to configure the
machine.

Stop the Event Processor

Before you proceed with the configuration and initialization procedures

discussed in the following sections, shut down the event processor as shown
following (you must be the exec superuser to do this):
sendevent -E STOP_DEMON

Configure the Machine

Set the AutoSysAgentSupport Parameter

To run jobs directly on a Unicenter AutoSys Agent, enable Unicenter AutoSys JM

Agent job support. To enable Unicenter AutoSys JM Agent job support, select the
AutoSysAgentSupport check box on the Event Processor Maintenance tab of the
Unicenter AutoSys Administrator.

After enabling AutoSysAgentSupport, an instance can dispatch jobs to an

Unicenter AutoSys Agent.

Set the Receive Remote Job Submissions Parameter

To enable bi-directional support, select the Receive Remote Job Submissions

check box on the Event Processor Maintenance tab of the Unicenter AutoSys
Administrator.

Integrating with the Mainframe and Unicenter AutoSys Agents for AS/400 and OpenVMS A–5
Configuring for Enterprise Job Scheduling

After enabling this parameter, the asbIIIsr1 process is started. For more
information see the section Bi-Directional Scheduling in this appendix.

Create the config.EXTERNAL File

To enable cross-platform dependencies, create a file named config.EXTERNAL in

the $AUTOUSER directory. In config.EXTERNAL, add an entry similar to the
following for each agent for which cross-platform dependencies will be
exchanged:
INS:AGT=REMOTE_HOST

where:

INS Is the three-letter uppercase identifier for the Unicenter AutoSys JM Connect
instance; for example, CA7. This is the name by which the Unicenter AutoSys
JM Connect application will be known to AutoSys.
Is one of the following:
AGT
– CNCT Represents a Unicenter AutoSys JM Connect machine.

– TNG Represents a Unicenter Job Management Agent Mmchine.

The name of the agent machine.
REMOTE_HOST

A–6 User Guide

 Configuring for Enterprise Job Scheduling

config.EXTERNAL Examples:

The following are examples of the config.EXTERNAL file:

■ FLO:TNG=flower
where:

FLO Is a three-character instance name, or INS.

TNG Is the agent type, or AGT.

flower Is a REMOTE_HOST that is a Unicenter NSM Job Management Agent machine

on AS/400, UNIX, VMS, or Windows, CA-7, CA-Jobtrac, or CA-Scheduler.

■ FRU:CNCT=fruit
where:

FRU Is a three-character instance name, or INS.

CNCT Is the agent type, or AGT.

fruit Is a REMOTE_HOST that is an AutoSys Connect machine on OS/390.

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
AutoSysAgentSupport check box on the Event Processor Maintenance tab of the
Unicenter AutoSys Administrator. 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 any Unicenter AutoSys Agent, the following
must be true:

■ AutoSysAgentSupport check box is selected on the Event Processor

Maintenance tab of the Unicenter AutoSys Administrator.

■ Unicenter AutoSys JM Connect instances are defined in the

config.EXTERNAL file (if you want to communicate with Unicenter AutoSys
JM Connect).

Integrating with the Mainframe and Unicenter AutoSys Agents for AS/400 and OpenVMS A–7
Configuring for Enterprise Job Scheduling

If you want to disable only Unicenter AutoSys JM Connect communication, you

must:

■ Comment out any Unicenter AutoSys JM Connect instances in the

config.EXTERNAL file.

If you want to disable both Unicenter AutoSys Agent and Unicenter AutoSys JM
Connect communication, you must do the following:

■ Clear the AutoSysAgentSupport check box in the Event Processor

Maintenance tab of the Unicenter AutoSys Administrator.

■ Comment out any Unicenter AutoSys JM Connect instances in the

config.EXTERNAL file.

Configure the Communication Components

See the Appendix A, Introducing CCI in the Unicenter AutoSys Job Management
for Windows Installation Guide.

Restart the Event Processor

Now you can start the event processor using the Unicenter AutoSys
Administrator Services screen. For information about starting the event
processor, see the chapter “Administrator,” in this guide.

A–8 User Guide

 About asbIII

About asbIII
Communication between Unicenter AutoSys JM and Unicenter AutoSys JM
Connect or a Unicenter AutoSys Agent is facilitated by asbIII. It is a necessary
component for cross-platform communication. Letting asbIII handle that
exchange frees the event processor to handle other events, as in the following
example.

When the event processor is started, it checks if the AutoSysAgentSupport check

box in the event processor tab of the Unicenter AutoSys Administrator is
enabled. If it is, the event processor starts asbIII automatically. If the event
processor is stopped, or goes down for any reason, asbIII will also stop running.
The only way to bring up asbIII is to restart the event processor.

If the event processor and asbIII go down while an Unicenter AutoSys JM

Connect job finishes, the completion event will be lost. (This does not happen to
an Unicenter AutoSys Agent job because missed events are resent during a
checkpoint restart at asbIII startup.) 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 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 Scheduler Console.

Integrating with the Mainframe and Unicenter AutoSys Agents for AS/400 and OpenVMS A–9
About asbIII

Environment Variable for asbIII

You can customize asbIII by setting the environment variable from the
Environment tab of the System Properties dialog.

PRIMARYCCISYSID

PRIMARYCCISYSID = cci_system_id

This environment variable defines the CCI system ID used by the Broker running
under the Primary Event Processor when communicating with remote nodes
(mainframe or Unicenter Workload Agents.) This environment variable is key to
providing Broker failover support within the Unicenter AutoSys JM
environment should the Primary EP shutdown or become unreachable. The
value of this environment variable is passed by the Primary EP to the Shadow EP
on startup.

Should the Primary EP failover, all Broker communication under the Shadow EP
will take place as normal. Any statuses currently residing on the remote agent
machines (mainframe or Unicenter Workload Agents) will now be dispatched to
the Shadow EP machine as opposed to the primary for processing.

To set this environment variable on Windows:

■ Automatically configured at installation time should the Event Processor

component of Unicenter AutoSys JM be installed.

■ Through the Unicenter AutoSys Administrator “System” selection.

A–10 User Guide

 About asbIII

Bi-Directional Scheduling

Running Jobs on Behalf of a Workload Manager

With Unicenter AutoSys JM 4.5, it is possible to extend the Workload Manager’s

capabilities into Unicenter AutoSys JM. You can define a job in the database,
destined to run on any agent supported by Unicenter AutoSys JM, and include
the agents defined in this appendix with a full-fledged job definition, so that job
can be initiated by a Workload Manager. The statuses of these jobs will be
reported back to the Workload Manager as if Unicenter AutoSys JM was the
Workload Agent.

You can start jobs in other instances running on other nodes through out their
respective asbIII’s. It is also possible for a later instance to run jobs defined by an
earlier instance, since multiple instances can be thought of as full peers of one
another.

Note: There is no restriction on platforms, databases or number of instances

when running this broker-to-broker mode.

For example; a Linux Sybase instance can initiate jobs in an NT MSSQL

environment, or an NT MSSQL instance can initiate jobs in a Linux Sybase. In
either case, a Solaris Sybase and an AIX Oracle or HP environment can be added.

Any instance can initiate or be a recipient of any other instance, regardless of

platform or database, provided the instances run on distinct servers. Although,
these instances can share the same database. The broker-to-broker function can
be combined with the Workload function described previously, and the
scheduling load can be distributed across the network.

In order to enable this feature, you must have the

AutoSysAgentSupportReceiveSubmit parameter set to 1, in the configuration
file.

For more information on AutoSysAgentSupport, see the section Configure the

Machine, in this appendix.

Integrating with the Mainframe and Unicenter AutoSys Agents for AS/400 and OpenVMS A–11
Unicenter AutoSys JM Connect Cross-Platform Dependencies

Unicenter AutoSys JM Connect Cross-Platform

Dependencies
Jobs can have dependencies on jobs managed by the Unicenter AutoSys JM
Connect scheduling software running in the OS/390 environment. For example,
a job defined to run on a UNIX or Windows machine could have as a starting
condition the successful completion of an Unicenter AutoSys JM Connect job
running on a mainframe system.

AutoSys Windows OS/390

REMOTE_HOST: MYMACHIN REMOTE_HOST: CA7
Instance: ACE

C
Event CCI CCI O
Server N
N Job
E
C
T
Event
Processor asbIII

Note: CCI components are listed in the appendix “Introducing CCI” in the
Unicenter AutoSys Job Management for Windows Installation Guide.

In the previous figure, communication between Unicenter AutoSys JM and

Unicenter AutoSys JM Connect is handled by asbIII and the communication
components.

The event processor communicates with Unicenter AutoSys JM Connect through

a process called asbIII, which communicates with any supported agent through
CCI.

In addition, a file named config.EXTERNAL is present on the machine on which

the 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 in this chapter.

A–12 User Guide

 Unicenter AutoSys JM Connect Cross-Platform Dependencies

Job Scheduler Interdependencies

Jobs can be dependent on the status of Unicenter AutoSys JM Connect jobs, and
Unicenter AutoSys JM Connect jobs can be dependent on the status of jobs. For
details on how to implement this with the Unicenter AutoSys JM Connect job
scheduler, see your Unicenter AutoSys JM Connect documentation.

For jobs, the following describes this type of cross-platform dependency.

To create job scheduler interdependencies:

1. Unicenter AutoSys JM sends a request to asbIII for the status of an Unicenter

AutoSys JM Connect job running on a mainframe.

2. asbIII passes the request to Unicenter AutoSys JM Connect.

3. Unicenter AutoSys JM Connect registers the request.

4. The job runs as scheduled by Unicenter AutoSys JM Connect that can run the
job on the mainframe.

5. The completion status of the job is passed to asbIII.

6. asbIII communicates the status to the database.

7. The event processor starts the job that is dependent on the completion of the
remote job.

Integrating with the Mainframe and Unicenter AutoSys Agents for AS/400 and OpenVMS A–13
Unicenter AutoSys JM Connect Cross-Platform Dependencies

Notation for Cross-Platform Job Dependencies

To define a cross-platform job dependency, use the following notation:

JOB_NAME^INS

where:

JOB_NAME Is the name of the job.

INS Is a three-letter uppercase identifier of the instance on which the job is running.

^ (Caret symbol before the instance name)—Indicates that the job resides on a
different instance of AutoSys.

The caret symbol (^) before the instance name indicates that the job resides on a
different instance of AutoSys.

Note: Job names for cross-platform dependencies must be all uppercase.

From JIL, you enter this in the condition job attribute, as shown in the following
example:
condition: success(JOB_NAME^INS)

From the GUIs, enter this information in the Dependencies field of the Job
Editor. Use the following statuses in the condition attribute of an job definition
dependent on an Unicenter AutoSys JM Connect job:

■ SUCCESS

■ TERMINATED

■ DONE

■ NOTRUNNING

A–14 User Guide

 Unicenter AutoSys JM Connect Cross-Platform Dependencies

Unicenter AutoSys JM Connect Cross-Platform Dependency Example

Following is an example of an job that will start only upon the successful
completion of “JOBA,” an OS/390 scheduler defined job that runs on a
mainframe:
condition: success(JOBA^CA7)

where:

success(JOBA^CA7) Specifies the successful completion of an OS/390 defined job named “JOBA”
running on a mainframe specified with the three-letter ID of “CA7.”

Naming Conventions for Unicenter AutoSys JM Connect Cross-Platform Jobs

Because of naming limitations in the OS/390 environment, the names of jobs

specified as job dependencies between Unicenter AutoSys JM and Unicenter
AutoSys JM Connect must follow these guidelines:

■ The first character of a job name must be an uppercase alpha character or

one of the following characters: pound sign (#), an at symbol (@), or a dollar
sign ($). The remaining characters in the job name can be any combination of
uppercase alphabetic characters, numbers, or a pound sign (#), an at symbol
(@), or a dollar sign ($.)

■ Job names can be no longer than eight characters.

■ All alphabetic characters must be in uppercase.

Note: These limitations do not apply to all jobs, only to jobs that will be
referenced to Unicenter AutoSys JM Connect.

For more information about cross-instance job dependencies, see Cross-Instance

Job Dependencies in the chapter “Jobs,” in this guide.

Integrating with the Mainframe and Unicenter AutoSys Agents for AS/400 and OpenVMS A–15
Running Jobs on Agents

Running Jobs on Agents

Unicenter AutoSys JM can directly schedule jobs on a machine that is running a
supported agent, assuming the machine running the agent has been defined to
Unicenter AutoSys JM. In the following example configuration, the agent is
running on an AS/400 machine. Unicenter AutoSys JM and agent integration is
supported on other operating platforms as well.

AutoSys Windows AS/400

REMOTE_HOST: MYMACHIN REMOTE_HOST: ZASYS400
Instance: ACE

Event CCI CCI Job

Server

Event
Processor asbIII AGENT

Note: CCI components are listed in the appendix “Introducing CCI” in the
Unicenter AutoSys Job Management for Windows Installation Guide.

In the previous figure, communication between Unicenter AutoSys JM and all

agents is handled by asbIII and CCI.

■ The event processor communicates with an agent through a process called

asbIII.

■ The communication components running on the machine receive

information from the agent and pass it to asbIII.

■ The agent (which in this example is running on the AS/400 platform) is

analogous to an remote agent.

A–16 User Guide

 Running Jobs on Agents

Agent Job Names and User IDs

Agent job names and user IDs have the same naming restrictions as Unicenter
AutoSys JM.

Where the operating system allows, agent job names can contain up to 64
alphanumeric characters and agent user IDs can contain up to 30 alphanumeric
characters. These job names and user IDs can be both uppercase and lowercase
(when the operating system allows mixed case). Blank spaces and tabs are illegal
characters.

Running Jobs On Agent Managed Machines

The process by which Unicenter AutoSys JM can run jobs directly on an agent
managed machine is described following.

To run jobs on agent managed machine:

1. The event processor sends the job information to asbIII and the job changes
to STARTING status.

2. asbIII passes the information to the agent, which starts the job.

3. The agent passes the information that the job is running (BOJ event) to CCI
on the AutoSys machine that writes it to the proper broker instance.

4. asbIII writes to the database; the job changes to RUNNING status.

5. When the job exits, the agent client traps the return code and passes the
information that the job is finished to asbIII.

6. asbIII writes to the database; 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).

Integrating with the Mainframe and Unicenter AutoSys Agents for AS/400 and OpenVMS A–17
Running Jobs on Agents

Defining Agent Machines

Before you can run jobs on an agent machine, you must first define the agent
machine to Unicenter AutoSys JM using the insert_machine subcommand. This
command adds a new machine definition to the database. It is described in detail
in the chapter “Load Balancing and Queuing Jobs,” in this guide. This section
pertains specifically to defining an agent machine.

To define an agent machine, use JIL and follow this example:

insert_machine: REMOTE_HOST
type: MACHINE_TYPE

where:

REMOTE_HOST Is the name of the agent machine.

MACHINE_TYPE Is one of the following:

■ t

Indicates a machine running Unicenter NSM Job Management, CA-7, or

CA-JobTrac.

■ c

Indicates a machine running Unicenter AutoSys JM Connect.

If Unicenter AutoSys JM Connect is running on the same machine as

CA-7, CA-JobTrac, or any OS/390 scheduling system, the machine type
should be c.

Note: Agent managed machines cannot be part of a virtual machine. job_load,

max_load, and factor attributes are not supported for agent-managed machines.

For example, to define the machine shown in the previous figure in this chapter,
which has a REMOTE_HOST of “ZASYS400,” you would specify the following:
insert_machine: ZASYS400
type: t

A–18 User Guide

 Running Jobs on Agents

Job Definition Examples

The following job definition example is for an AS/400:

insert_job: as400_a1 job_type: c
command: DLYJOB DLY(15)
machine: usprncax
owner: user1@usprncax
permission: gx,wx
date_conditions: 1
days_of_week: all
start_mins: 30

The following job definition example is for Unicenter AutoSys JM Connect:

insert_job: cas1 job_type: c
command: auto_cnct -a A87SOENF -j RYAKEJ01 -c RUN -p SCHEDULE=RYAKE01 -s CAS
machine: A87SOENF
owner: user1@A87SOENF
permission: gx,wx
date_conditions: 1
days_of_week: all
start_mins: 45

The following job definition example is for OpenVMS:

insert_job: vmsjob1
command:”@SYS$LOGIN:SCHEDULE_WAIT.COM”
machine:VMSNODE
owner:system@VMSNODE
max_exit_success:1

Note: A job that executes successfully on an OpenVMS machine returns an exit

code of 1. Unicenter AutoSys JM , by default, will interpret an exit code of 1 as a
failure unless the max_exit_success attribute is used in the job definition.

Integrating with the Mainframe and Unicenter AutoSys Agents for AS/400 and OpenVMS A–19
Log and Trace Information

Unicenter AutoSys Agent Machine In an Job Definition

Once you have defined an Unicenter AutoSys Agent machine to Unicenter

AutoSys JM you can specify that machine in an job definition, using the machine
job attribute. For example:
insert_job: as400ji
owner: bob@ZASYS400
machine: ZASYS400
command: DLYJOB DLY(16)

The owner identified in the owner attribute of the job definition must have an
account on the target agent machine. The account must match the owner name
exactly in order for the job to run. The owner of the job definition must be
specified as “user@machine.” The edit superuser must use the autosys_secure
binary to add valid userids and passwords using option 4 as follows:

1. Start the Security Utility:

$ autosys_secure

2. Select option 4 from the menu:

AutoSys Security Utility
Please select an action to perform:
[1] Administer EDIT/EXEC superusers
[2] Change AutoSys database password.
[3] Change AutoSys remote authentication method.
[4] Create AutoSys User@Host or Domain password.
[5] Change AutoSys User@Host or Domain password.
[6] Delete AutoSys User@Host or Domain password.
[7] Disable E-Trust Access Control
[8[ Exit autosys_secure.
> 4

3. Enter the user name, user host or domain, and password information when
prompted:
Enter user name : bob
Enter user Host or Domain : ZASYS400
Enter new password:
Enter new password again:
User Create successful.

Log and Trace Information

If AutoSys is unable to start a job on an agent, an entry will be inserted into the
event processor log located in the %AUTOUSER%\out directory.

A–20 User Guide

 Unicenter AutoSys JM Connect and Unicenter AutoSys Agent Job Statuses

Unicenter AutoSys JM Connect and Unicenter AutoSys

Agent Job Statuses
The valid statuses that Unicenter AutoSys JM can get for Unicenter AutoSys JM
Connect and Unicenter AutoSys Agent managed jobs are:

■ STARTING
The job has been passed from the event processor to asbIII.

■ RUNNING
The job has started and a BOJ (Beginning Of Job) event has been sent back to
asbIII.

■ SUCCESS
The job has ended and an EOJ (End Of Job) event has been passed back to
asbIII.

■ TERMINATED
The job has ended and an AEOJ (Abnormal End Of Job) event has been sent
back to asbIII.

Any Unicenter AutoSys JM Connect or Unicenter AutoSys Agent managed job

without a return code of zero will be considered TERMINATED.

Integrating with the Mainframe and Unicenter AutoSys Agents for AS/400 and OpenVMS A–21
Unsupported Attributes for Unicenter AutoSys JM Connect or Unicenter AutoSys Agent Jobs

Unsupported Attributes for Unicenter AutoSys JM Connect or

Unicenter AutoSys Agent Jobs
The following attributes are not supported for Unicenter AutoSys JM Connect or
Unicenter AutoSys Agent managed jobs. If specified, they will be ignored. The
JIL attribute is listed on the left and the corresponding GUI field is shown on the
right.

JIL Attribute GUI Field

chk_files Resource Check - File System Space...

heartbeat_interval Heartbeat Interval (mins)

job_load Job Load

job_terminator If the Box fails should this Job be Terminated?

job_type:f Job Type (File Watcher)

n_retrys Number of Times to Restart this Job after a

FAILURE

priority Que Priority

profile Job Environment Profile

std_err_file File to Redirect to Standard Error

std_in_file File to Redirect to Standard Input

std_out_file File to Redirect to Standard Output

term_run_time Terminate this Job Mins after starting

watch_file File To Watch For

watch_file_min_size Minimum File Size (in Bytes)

watch_interval Time Interval (secs) to Determine Steady State

A–22 User Guide

 Cross-Platform Limitations

Cross-Platform Limitations
When you are 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

Unicenter AutoSys JM Connect or Unicenter AutoSys Agent jobs and
machines.

■ Remote authentication is not supported for Unicenter AutoSys JM Connect

or Unicenter AutoSys Agent jobs.

■ The following events cannot be executed on an Unicenter AutoSys JM

Connect or Unicenter AutoSys Agent job:

 CHANGE_PRIORITY
 SEND_SIGNAL

Integrating with the Mainframe and Unicenter AutoSys Agents for AS/400 and OpenVMS A–23
 Appendix

Troubleshooting CCI
B
This appendix describes troubleshooting CCI for AutoSys.

Troubleshooting Tools for Remote CCI Connections

The following are troubleshooting tools:

netstat

The netstat command allows you to check TCP/IP statistics:

■ netstat –a | grep caic

Shows all connections to the local host involving a port, which can be
resolved to caic(ci). The important connections are ESTABLISHED and
LISTEN. If the latter is present, you know that the kernel accepts connections
on behalf of the ccirmtd process. This means that a remote host attempting to
connect to this host should get the TCP/IP connected state. Established
connections are important because we know that CCI transactions may not
transpire between the hosts in question if a TCP/IP Established connection
does not exist.

Troubleshooting CCI B–1

Troubleshooting Tools for Remote CCI Connections

It is important to understand that netstat output is of the form:

ip-address:port

where the local host listed to the left of the remote host. One side will always
have a port that resolves to caicci and the other side will have a numeric
port. The latter side is that which initiated the connection.

Sometimes netstat –a does not return or may take a long time to return with
very little information. This is usually indicative of name resolution
problems. You can issue:
netstat –an | grep 1721

netstat skips the name resolution and displays information about

connections.

■ netstat –i

Shows information about the network interfaces on the local hosts. You can
use the netstat –i command to determine if the host has more than one
network card and determine the host names or IP addresses of these cards.
The netstat –i command also provides valuable statistics about network
collisions. A collision occurs when two hosts simultaneously attempt to send
on an ethernet. The important thing to look for is high ratio of outgoing or
incoming packets to collisions.

ping

The ping command allows you to establish that a remote host can be reached. It
is important to ping by IP address as well as host name. If you cannot ping a
host, CCI cannot establish a connection to that host.

nslookup

The nslookup command allows you to be sure that the name of the host to which
you wish to connect, as well as the IP address, is resolvable. If there is a question
as to the integrity of the DNS environment, you can use nslookup to verify the IP
address of the host to which you need to communicate. You then enter the IP
address back into nslookup and verify that the same host name is returned.
Verify the IP address and host name for both hosts.

B–2 User Guide

 Troubleshooting Tools for Remote CCI Connections

traceroute and tracert

The traceroute command on UNIX and the tracert command on Windows allow
you to determine the route taken between two hosts. If a client cannot ping a
host, this command may show where the network path is failing.

ccinet

ccinet may be used to pass commands to the ccirmtd demon on UNIX. On

Windows, this is the rmtcntrl binary. This may be used as follows:

■ ccinet ping

Can be used to send a special CCI test packet across the CCI connection. This
does not use the native ping command nor does it operate in quite the same
way.

■ ccinet status

Allows you to determine the status of the CCI connections.

■ ccir/ccis/ccic/ccii

Provides you a suite of test binaries to test application-to-application CCI

communication. (ccinet ping tests remote-process-to-remote-process
communication)

Troubleshooting CCI B–3

CCI Command Line Controls

CCI Command Line Controls

The command binaries on Windows are the following:
ccicntrl
rmtcntrl

ccicntrl

The main command binary is ccicntrl.

ccicntrl [start | stop] [tpd, nrs, nrc, rmt]

This is used to stop or start the CCI services. The specific services are:

■ tpd: Transport

■ nrs: NR-Server

■ nrc: NR-Client

■ rmt: Remote

■ ccicntrl remove [ tpd | nrs | nrc | rmt ]

This removes the specified service. This does not imply that the binary is
affected in any way; rather, the process is no longer available as a service.

ccicntrl install [tpd | nrs | nrc | rmt ] PATH

This command installs the specified service. Path is the directory in which the
executable resides.

ccicntrl status

Displays the status of the CCI services. The valid states are:

■ STOPPED

■ STARTED

■ START PENDING

■ STOP PENDING

■ NOT INSTALLED and RUNNING

B–4 User Guide

 CCI Command Line Controls

rmtcntrl

The remote service is contacted in a manner similar to the remote demon on

UNIX. The command executable is rmtcntrl.

rmtcntrl status

Displays information about the state of connections to remote hosts.

rmtcntrl debugon and rmtcntrl debugoff

Starts and stops remote service tracing. A unitrace window should have been
open prior to issuing this command.

rmtcntrl hats

Displays detailed information to stdout about the connections to other hosts.

rmtcntrl rrt

Displays detailed information to stdout about the remote receivers.

Note: rmtcntrl hats and rmtcntrl rrt are equivalent to ccinet show.

Troubleshooting CCI B–5

CCI Command Line Controls

rmtcntrl ping sysid

Sends a CCI test packet to the remote host specified and displays the round trip
time.

rmtcntrl reconnect [All] sysid

The remote service disconnects and reconnects to all of the remote hosts to which
it is connected or to the specified host.

rmtcntrl disconnect sysid

The remote service will disconnect from the remote host specified. Neither side
will attempt to reconnect.

rmtcntrl release

Displays the release of the remote service.

B–6 User Guide

Appendix

General Debugging
C
To better monitor the behavior of the Unicenter AutoSys JM product and to
facilitate in identifying problems while troubleshooting, a Unicenter AutoSys JM
environment variable has been introduced called ISDBGACTIV. (For UNIX,
ISDBGACTIV is an OS environment variable. For Windows it is a registry key).
The environment variable must be set prior to initiating the product. Upon
startup, the traceable applications will look for the set value of the ISDBGACTIV
environment variable and will output certain trace messages given the value
assigned. In UNIX, the ISDBGACTIV environment variable can be set as any
other environment variable using either the setenv or export command
depending on the UNIX operating system used. In Windows, the ISDBGACTIV
environment variable must be set using the Administrator Tool through the
System Environment Variable screen.

Values
The following is a description of how the products interpret the ISDBGACTIV
values:
ISDBGACTIV Value ID Description
1 DBG Generic Debug Status Information

2 CDB CCI Memory Output

4 MDB Internal Communications Data Information

(sockets, message queues)

8 OPX Internal Communications Status Information

16 EDB EDB Event Processor Debug Messages

32 DDB DDB Database

General Debugging C–1

Values

ISDBGACTIV Value ID Description

64 RDB Event Processor to Remote Agent Communications
Information

128 SDB Sendevent Status Information

256 JDB Job Start Status Information

The individual values can be combined to control the number of traces

generated. For example, to view Event Processor Debug Messages and Generic
Debug Status, ISDBGACTIV should be set to 32 + 1 = 33. To view all traces,
ISDBGACTIV should be set to 63 (32+16+8+4+2+1). In general, DBG, MDB, and
DDB generate large amounts of trace statements whereas OPX and EDB provide
light traces.

The products that generate trace messages are the Event Processor, the AutoSys
Broker, the AutoSys Broker CCI Send and Receive Objects, and the Remote
Agent. Each of these products generate their own log files under normal
circumstances located in the $AUTOSERV/autouser/out directory. Any trace
messages will be added to these log files at various places as the products
encounter them.

C–2 User Guide

Appendix

Unicenter Integration
D
Important! The information contained in this appendix pertains to Window
users only.

The integration process consists of the following steps:

■ Running the integration utility on Framework.

■ Starting the 2D map on Framework and launch the Unicenter AutoSys JM

applications.

■ Modifying your Unicenter AutoSys JM Admin configuration to publish

events on the Unicenter Event Manager console.

Running Unicenter AutoSys JM 4.5/Unicenter NSM

Framework Integration Utility
1. From the autosys\bin directory, enter:
autosys_wv

The utility displays the following menu:

[1] Add Instance

[2] Delete Instance

[3] List Autosys Instances

[4] Exit

2. Select option 1.

Unicenter Integration D–1

Running Unicenter AutoSys JM 4.5/Unicenter NSM Framework Integration Utility

3. Enter the three-character instance name.

When the autosys_wv utility is first executed, it creates the AutoSys class
and a Unicenter AutoSys JM instance. The instance is created as an object of
the Unicenter AutoSys JM class. The new object is created only if the instance
is installed and the object does not exist in the repository.

When the autosys_wv utility is started the repository selection box appears.

4. Select the “hostname_TNGDB.”

After the repository is selected, the repository sign on box appears.

5. Sign on.

Once you sign on, you are connected to the repository to perform operations.
The default user ID is “sa” with no password.

Example:

1. Start the WorldView Utility from the autosys\bin directory, enter:

autosys_wv

2. Type 1 at the prompt:

AutoSys WorldView Utility

[1] Add Instance

[2] Delete Instance

[3] List AutoSys Instances

[4] Exit
> 1

3. Type AutoSys Instance: ACE.

The following messages are displayed:

Checking if Instance ACE exits in the repository.....
AutoSys Instance ACE does not exist!
New object ACE created successfully.

D–2 User Guide

 Running Unicenter AutoSys JM 4.5/Unicenter NSM Framework Integration Utility

4. Type 1, from the AutoSys WorldView Utility menu:

AutoSys WorldView Utility

[1] Add Instance

[2] Delete Instance

[3] List AutoSys Instances

[4] Exit
> 1

5. Type AutoSys Instance: CHA

The following messages are displayed:

Checking if Instance CHA exits in the repository.....
AutoSys Instance CHA does not exist!
New object CHA created successfully.

6. Type 3, from the AutoSys WorldView Utility menu:

AutoSys WorldView Utility

[1] Add Instance.

[2] Delete Instance.

[3] List AutoSys Instances.

[4] Exit.
> 3

The following message appears:

There were 2 AutoSys objects found
1. ACE
2. CHA

7. Start the 2D map to view these two Unicenter AutoSys JM instances and will
launch the AutoSys applications.

Unicenter Integration D–3

Modifying Admin Configuration to Publish Events to the Unicenter Console

Modifying Admin Configuration to Publish Events to the

Unicenter Console
1. Open the Unicenter AutoSys JM Admin GUI.

2. Select the instance, from the drop-down list, whose events you want to
publish to the Unicenter Console. Click OK.

3. Select event processor from the drop-down menu.

Events are sent to the Event Management Console based on the value set in
the “Unicenter Events” edit box, in the event processor screen.

The valid values for the Unicenter Events edit box are:

0—No events are sent.

1—Only the Alarms are sent.

2—Alarms and Job Completion status are sent.

3—All the events are sent.

4. Enter the integer value (0–3) that corresponds to the desired message level in
the Unicenter Events edit box.

This field is located in the lower-right corner of the event processor screen.

5. Click Apply, then Click OK.

Note: To modify the settings on this screen, you must have privileges in the
Windows Administrators group.

Important! The event processor only reads the settings in the Unicenter AutoSys
JM Administrator on startup. Therefore, if you make a change that you want to
implement immediately, you must stop the event processor using the sendevent
-E STOP_DEMON command, then restart the event processor using the
Administrator Services screen (as described in the chapter “Administrator” of
the Unicenter AutoSys Job Management for Windows User Guide).

D–4 User Guide

 Modifying Admin Configuration to Publish Events to the Unicenter Console

After the Integration Process

For detailed information about using Unicenter, see the WorldView Help.

1. Restart Framework 2D Map.

2. In the Framework Managed Objects program window, you will see the new
icon for the Unicenter AutoSys JM instance.

3. Right-click the Unicenter AutoSys JM icon to display the Unicenter AutoSys

JM menu. From here, you can launch all Unicenter AutoSys JM GUIs.

4. To view Unicenter AutoSys JM events on the Unicenter console:

a. Select Programs, Unicenter, Enterprise Managers.

b. Click Windows.

c. Click Events.

d. Click Console Logs.

Unicenter AutoSys JM events will now display on the console, based on the
level set in the Unicenter AutoSys JM Administrator, event processor,
Unicenter Events edit box.

Unicenter Integration D–5

Removing Icons from WorldView

Removing Icons from WorldView

1. From the autosys\bin directory, enter:
autosys_wv

The AutoSys WorldView Utility displays the following menu:

[1] Add Instance.

[2] Delete Instance.

[3] List AutoSys Instances.

[4] Exit.

2. Select 2 to delete an instance from the CORe and enter the name of the
instance you want to delete.

If this is the last instance in the repository being deleted when you select
option 2, the AutoSys class is deleted.

3. Type 4 to exit the integration utility menu:

1] Add Instance

[2] Delete Instance

[3] List AutoSys Instances

[4] Exit
> 4

The Unicenter NSM Console continues to display Unicenter AutoSys JM

messages even though the WorldView icon has been removed.

D–6 User Guide

 Index

acknowledging alarms, 12–3

Alarm List, 12–4
$ Alarm Selection dialog, 12–9
Select by State region, 12–11
Select by Time region, 12–11
$AUTORUN, 3–32
Select by Type region, 12–10
$AUTOTESTMODE, 14–13 changing alarm states, 12–7
closing alarms, 12–3
Currently Selected Alarm
% acknowledging, 12–7
closing, 12–7
%AUTOSERV% variable, 15–6 Response edit box, 12–7
menu bar, 12–4
%autotestmode%, 14–13 registering responses, 12–8

alarm monitor/report attribute, 13–12

/ Alarm Sentry, 6–4, 12–1

alarm_verif monitor attribute, 13–14

/bin/date command, 14–13
alarms, about, 1–11
/tmp/autotest.$JobName, 14–13
all_events monitor/report attribute, 13–11

all_status monitor/report attribute, 13–12

A
Append stdout/stderr, 15–32

Action Area Layout dialog, 11–42 asbIII, environment variables, A–10

ACTIVATED status, 3–13 asset level security, 2–21

Administrator Services, 15–20 attributes

job dependencies, 3–21
after_time report attribute, 13–15 monitor
agent machines alarm_verif, 13–14
defining to AutoSys, A–18 sound, 13–14
in a job definition, A–20 monitor/report
alarm monitor/report attribute, 13–12
Alarm Manager, 6–4 all_status, 13–12
about, 12–3 job_filter, 13–13

Index–1
 report software requirements, A–4
after_time, 13–15 support, A–1
currun, 13–15
AutoSys Connect and AutoSys Agent support, A–1
starting conditions, 3–21
unsupported, A–22 AutoSys Console Utilities, AutoSys Administrator,
15–1
Attributes
Date and Time, 4–27 AutoSys Event Servers, 15–12

Authorized Event Processor Host Names, 15–11 AutoSys instance

defined, 15–6
autoping, 16–15
ID, 15–8
AutoSys screen, 15–6
components, 1–4
AutoSys Remote Agent screen, 15–9
database
defined, 1–5 AutoSys Services, 15–50
graphical user interface
AutoSys Sounds, 15–43
see GUI, 1–3
instances AutoSysAgentSupport parameter, A–5
defined, 1–10 autosyslog, monitoring Remote Agent log, 16–22
machines, 1–10
Notification Mechanism, 15–35 AytoSys Event Processor, 15–18
security, 2–1
System Information, 15–38
B
AutoSys Administrator
defined, 15–1
backing up definitions, 14–16
Event Processor Screen, 15–19
Event Server screen, 15–13 backups
Instance screen, 15–6, 15–7 calendar definitions, 14–16
menu bar and toolbar, 15–3 global variables (using autorep), 14–17
modifying configuration parameters, 15–2 job definitions (using autorep), 14–16
Notifications screen, 15–36 machine definitions (using autorep), 14–17
screens, 15–1 monitor and browser definitions (using monbro),
Security Screen, 15–48 14–17
Services, 16–10
batch files and exit codes, 3–29
Services Screen, 15–50, 15–52
Sounds Screen, 15–43 Bi-Directional Scheduling, A–11
starting, 15–3
Box
System Information screen, 15–38, 15–39
Creating, 8–9
AutoSys Administrator Security Screen, 15–46
Box Jobs, 3–3, 5–1
AutoSys Agent basic job definition, 3–12
job names and user IDs, A–17 default behavior, 5–1
machines, A–18 diagram, 3–17
running jobs, A–16 examples, 5–10

Index–2 User Guide

 force starting jobs in a box, 5–8 exiting, 9–6
guidelines, 5–2 exporting, 9–28
non-default terminators, 5–5 exporting definitions to file, 14–16
placing job in exporting to text, 9–6
GUI, 7–14 importing, 9–6, 9–27
starting conditions, 3–4, 3–19 importing definitions from file, 14–18
status changes, 5–9 Job Definition Reference List, 9–7
merging, 9–24
browsers
navigation controls, 9–9
backing up definitions, 14–17
opening, 9–5
defined, 13–1
opening new, 9–5
restoring definitions from backup file, 14–18
periods, 9–19
printing, 9–6
renaming, 9–6
C
rescheduling rules, 9–22, 9–23
restoring definitions, 14–18
Calendar Editor, 6–4, 9–1 reverting to last saved, 9–7
applying rules, 9–17 rule specification, 9–18
Calendar Selection dialog, 9–15 saving, 9–5
date states, 9–11 saving to other instances, 9–5
Edit menu, 9–7 selecting, 9–15
exporting definitions, 9–28 setting dates, 9–18
File menu, 9–5 Term Calendar Rule, 9–17
Help menu, 9–9 unsetting dates, 9–18
importing text files, 9–27
CCI
merging calendars, 9–24
command line controls, B–4
navigation controls, 9–9
troubleshooting tools, B–1
Preferences menu, 9–7
rescheduling rules, 9–22 ccicntrl, B–4
rule specification, 9–18
CHANGE_PRIORITY, 11–27
See also calendars, 9–4
starting, 9–4 CHANGE_STATUS, 11–27
Utilities menu, 9–7
Chapter Organization, 4–3
calendars, 9–1
chase, 14–14
applying rules, 9–7
backing up definitions, 14–16 Chase On Startup, 15–31
blocked dates, 9–11 Clean Temporary Files, 15–31
blocking dates, 9–18
combining, 9–24 clean_files, 14–15
conflicting dates, 9–10, 9–12 client machine, 1–10
custom, 3–21
date range, 9–19 command jobs, 3–3, 3–11
date states, 9–11 COMMENT, 11–26
deleting, 9–6
components

Index–3
 event processor, 1–6 Database Mainteneance Command, 15–22
event server, 1–5
database overview, 14–19
remote agent, 1–7
databases
conditions, starting, 3–21
handling errors, 14–32
config.EXTERNAL, creating the file, A–6 synchronizing, 14–28
synchronizing Microsoft SQL, 14–31
configure the AutoSys Machine, A–5
synchronizing oracle, 14–31
contacting technical support, 1–16 synchronizing sybase, 14–30

Control Panel, GUI, 6–1 dataserver, defined, 1–5

cross-platform Date and Time Attributes and Time Changes, 4–27

limitations, A–23
Date Changes, 4–27
naming conventions, A–15
notation, A–14 date dependency, 3–20

cross-platform dependencies, A–12 date range in calendars, 9–19

currun report attribute, 13–15 date/time job dependencies, 3–20

custom calendars, overview, 3–21 days to run job, setting

GUI, 7–22

DB Poll Interval, 15–23

D
dbmaint.bat batch file, 14–24
modifying, 14–25
data locking, 14–25
default owner of job, 2–10
database
architecture, 14–22 default port number, 15–10
connection to Monitor/Browser Editor, 13–18
defining a real machine, 10–7
daily maintenance, 14–23
data locking, 14–25 defining a virtual machines, 10–8
displaying date and time, 14–41 defining machines to AutoSys, 10–2
dropping, 14–44
general maintenance, 14–23 delete job
identifying connected processes, 14–40 GUI, 7–24
improving oracle performance, 14–33 Deleting a Job, 8–12
improving performance, 14–33
improving sybase performance, 14–33 Deleting a Job
passwords, 2–9 Box, 8–12
re-creating, 14–44 deleting a real machine, 10–7
reloading, 14–45
deleting virtual machines, 10–10
storage requirements, 14–21
tablespace error, Oracle, 16–9 dependencies
verifying connection, 16–15 cross-platform, A–12
job scheduler interdepencies, A–13
Database Maintenance Time, 15–23
notation, A–14

Index–4 User Guide

dependency, job controlling the event processor, 2–20
date/time, 3–20 disable security, 2–20
exit code, 3–28 policy manager, 2–19
global variables, 3–30 resource classes, 2–22
job status, 3–21 security access, 2–19
Security Administration, 2–18
dependent jobs
security call logic, 2–34
creating GUI, 7–12
security enabled applications, 2–33
example, 3–26
event processor
disable security, 2–20
AutoSys Broker Options, 15–34
dual event servers AutoSys Agent Support, 15–34
defined, 1–5 Receive Remote Job Submissions, 15–34
configuration parameters, 15–20
Dual-Event Server, 15–12
Database Maintenance Command, 15–22
Database Maintenance Time, 15–23
DB Poll Interval, 15–23
E
Enterprise Wide Logging Directory, 15–22
EP Count, 15–20
eAC, 2–17 EP Heartbeat Interval, 15–23
edit permissions, 2–11 Error Time Interval, 15–25
Event Transfer Wait Time, 15–25
Edit Superuser, 2–14
File System Threshold, 15–24
enterprise job scheduling, A–5 Job Heartbeat Interval, 15–26
Kill Signals, 15–29
Enterprise Wide Logging Directory, 15–22
Machine Method, 15–27
eoid, 15–6 Max Restart Trys, 15–28
Max Restart Wait, 15–28
EP Count, 15–20
Maximum Log Size, 15–24
EP Heartbeat Interval, 15–23 Network Machine List, 15–21
Number Errors, 15–26
Error Time Interval, 15–25
Restart Constant, 15–30
Essential Job Attributes, 4–4 Restart Factor, 15–29
eTrust Shadow Machine, 15–20
access control, 2–17 Shadow Ping Delay, 15–23
access modes, 2–23 Start Poll Interval, 15–27
as-calendar class, 2–25 Third Machine, 15–21
as-control class, 2–30 Unicenter Events, 15–29
as-gvar class, 2–28 configuration parametersXInstance DB Drop
as-job class, 2–23 Time, 15–27
as-list class, 2–31 defined, 1–6
as-machine class, 2–26 log, A–20
as-owner class, 2–29 log file location, 14–4
asset level security, 2–21 log file size, 14–4
as-view class, 2–31 maintaining, 14–1

Index–5
 monitoring, 14–3 Example
Multiple EP Restart, 15–33 Remote Authentication, 15–47
Options, 15–31
examples
Append stdout/stderr, 15–32
calendar rescheduling rule, 9–23
Chase On Startup, 15–31
job dependencies, 3–26
Clean Temporary Files, 15–31
monitor/report definition, 13–7
Event Serialization, 15–33
monitors, defining in JIL, 13–18
Global Auto Hold, 15–31
reports, defining in JIL, 13–18
Remote Profile Logging, 15–32
system architecture, 1–8
restarting, 14–45
restoring primary, 14–9 exclusive condition, 3–27
running in test mode, 14–12
exec superuser, 2–15
See also event_demon, 1–6
shadow rollover, 14–8 Exec Superuser, 2–15
starting, 14–1, A–8 execute permissions, 2–11
global mode, 14–5
status, 16–10 exit codes
stoping, 14–7 batch files, with, 3–29
stopping, 14–44, A–5 FALSE.EXE, 3–30
troubleshooting, 16–9 job dependencies, 3–28
maximum for success, 3–23
Event Processor Defined, 15–18
exporting calendars, 9–28, 14–16
Event Processor Screen, 15–19

Event Serialization, 15–33

F
event server
defined, 1–5
overview, 14–20 FAILURE status, 3–14
returning after rollback, 14–27 FALSE.EXE, 3–30
rollover recovery, 14–26
File System Threshold, 15–24
See also database, 1–5
See also dual event servers, 1–5 File Watcher
Server is Down, 16–4 Creating Job, 8–6
Sybase Deadlock, 16–5
File Watcher Jobs, 3–5
using dual server mode, 14–20
basic job definition, 3–11
Event Server Configuration Parameters, 15–14 creating, 7–10
Event Server screen, 15–13 Filter Editor, 11–12
Machine/Instance tab, 11–15
Event Transfer Wait Time, 15–25
Names tab, 11–13
event_demon Status tab, 11–14
See also event processor, 1–6 using, 11–16
events force starting jobs, 10–13
about, 1–11
FORCE_STARTJOB, 11–4, 11–27, 11–43
cancelling, 11–30

Index–6 User Guide

G I

General Dialog, 11–35 importing calendars, 9–27, 14–18

gid, 2–11 INACTIVE status, 3–13

Global Auto Hold, 15–31 inherit, job’s starting conditions, 3–19

global variables initautosys command, 11–37

backing up definitions, 14–17
Instance screen, 15–6
job dependencies, 3–30
restoring definitions, 14–18 Instance, ID, 15–8
setting in the Send Event Tool, 11–28
instances of AutoSys, 1–10
Graphical User Interface
introduction, 6–1
See also GUI, 6–1 J
group ID, 2–11
JIL, 8–1
GUI
defined, 1–3
alarm color setting, 6–3
defining monitor, 13–18
Alarm Manager, 6–4
defining report, 13–18
Alarm Sentry, 6–4
Calendar Editor, 6–4 JIL
connect to database, 6–3 Create a Job Definition, 4–2
Control Panel, 6–1 JIL
defined, 1–3 Syntax Rules, 8–2
introduction, 6–1
Job Editor, 6–4 JIL
Job Editor menu bar, 7–3 Sub-commands, 8–4
Monitor/Browser Editor, 6–4 JIL
one-time job overrides, 7–26 Submitting Job Definitions, 8–4
removing user preferences, 6–3
JIL
Scheduler Console, 6–4
Running, 8–5
time dependencies, setting, 7–18
JIL
Command Job
H Creating, 8–5

JIL
high availability Command Job
dual event servers, 1–5 File Watcher, 8–6
shadow event processor, 1–6
JIL
Command Job
Dependent Command Job, 8–7

JIL

Index–7
 Creating a Box, 8–9 Job Attributes
Optional
JIL
Command, 4–18
Changing a Job, 8–10
Job Attributes
JIL
Optional
Deleting a Job, 8–12
File Watcher, 4–25
JIL
Job Attributes
Job Overrides, 8–13
Optional
JIL Box Job, 4–26
Example Script, 8–15
Job Attributes and Definitions, 4–1
Job
Job Attributes and Load Balancing and Queuing, 10–
Box, 8–9
4
Changing, 8–10
Creating Simple Command, 8–5 Job Definition Reference List, 9–7
Deleting, 8–12
Job Dependencies dialog, 11–18
Deleting Box, 8–12
Dependent Command, 8–7 Job Detail Report, 11–32
File Watcher, 8–6
Job Editor, 6–4, 7–1
Overrides, 8–13
creating Box Jobs, 7–14
Running JIL, 8–5
creating Command Jobs, 7–8
Setting Overrides, 8–14
creating File Watcher Jobs, 7–10
Submitting Defenitions, 8–4
creating jobs with dependencies, 7–12
Time Dependencies, 8–11
deleting definition, 7–4
Job Attributes, 4–1, 4–4 deleting jobs, 7–24
menu bar, 7–3
Job Attributes
modifying job definitions, 7–16
Common to All Job Types, 4–4
one-time overrides, 7–26
Job Attributes opening definitions, 7–3
Common, 4–5 opening new job, 7–3
Owner field, 7–9
Job Attributes
saving job as, 7–4
File Watcher, 4–8
saving jobs, 7–3
Job Attributes setting days to run, 7–22
Box, 4–8 setting time dependencies, 7–18

Job Attributes Job Editor

Optional, 4–9 Using
Create a Job Definition, 4–2
Job Attributes
Optional Job Heartbeat Interval, 15–26
Common Job Starting, 4–9
Job Information Language, 1–12
Job Attributes See also JIL, 1–12
Optional
Job Information Language (JIL), 8–1
Common General, 4–12

Index–8 User Guide

job level security, 2–10 exit codes, 3–28
global variables, 3–30
Job Selection dialog
job status, 3–21
Box Levels field, 11–13
time
Job Name field, 11–13
GUI, 7–18
job status, as job dependency, 3–21 edit permissions, 2–11
execute permssions, 2–11
job_filter monitor/report attribute, 13–13
exit code, 3–28
JOB_OFF_HOLD, 11–4, 11–26, 11–44 File Watcher
JOB_OFF_ICE, 11–4, 11–27, 11–44 creating - GUI, 7–10
defined, 3–5
JOB_ON_HOLD, 11–4, 11–26, 11–44 list in Scheduler Console, 11–8
JOB_ON_ICE, 11–4, 11–27, 11–44 names and user IDs, A–17
on agent managed machines, A–17
jobs
overrides
backing up definitions, 14–16
GUI, 7–26
basic job information, 3–2
owner
Box Jobs, 5–1
default, 2–10
creating - GUI, 7–14
permissions on NT, 2–13
defined, 3–3
restoring definitions from backup file, 14–18
calendar reference list, 9–7
run number, 3–31
changing - GUI, 7–16
saving definitions to backup file, 14–16
command jobs
selection list, 7–16
defined, 3–3
starting conditions, 3–19
Command Jobs
states, 3–13
creating - GUI, 7–8
status
creating
ACTIVATED, 3–13
Box Jobs - GUI, 7–14
FAILURE, 3–14
Command Jobs - GUI, 7–8
INACTIVE, 3–13
File Watcher Jobs - GUI, 7–10
managing, 3–27
custom calendars, 3–21
ON_HOLD, 3–14
cycles of processing, 16–2
ON_ICE, 3–15
date/time dependencies
QUE_WAIT, 3–14
setting in GUI, 7–18
RESTART, 3–14
days to run, setting, 7–22
STARTING, 3–13
defined, 1–2
SUCCESS, 3–13
defining in AutoSys, 3–32
TERMINATED, 3–14
definition
status codes, 3–13
Box, 3–12
time/date dependencies, 3–20
command, 3–11
types, 3–2
File Watcher, 3–11
deleting
GUI, 7–24
dependencies
creating with GUI, 7–12

Index–9
K restoring definitions, 14–18

managing job status, 3–27

Kill Signals, 15–29 Max Restart Trys, 15–28
KILLJOB, 11–4, 11–27, 11–43 Max Restart Wait, 15–28

maximum exit code for success, 3–23

L Maximum Log Size, 15–24

Microsoft SQL
limitations, cross-platform, A–23 synchronizing databases, 14–31
load balancing, 10–11 Microsoft SQL Server, 16–2, 16–17
Load Units and Virtual machines, 10–18 Monitor/Browser Editor, 6–4, 13–1
Local Agent Logging Directory, 15–10 Alarm field, 13–12
Alarm Verification Required field, 13–14
log, A–20
All Change Status Events field, 13–12
log files, remote agent, 16–21 All Events field, 13–11
Current Run Only field, 13–15
Events After Date/Time field, 13–15
M Job Filter field, 13–13
naming, 13–5
Sound field, 13–14
machine
backing up definitions, 14–17 monitors, 13–1
client, 1–10 about, 13–2
permissions alarm_verif, 13–14
edit and execute, 2–12 backing up definitions, 14–17
restoring definitions from backup file, 14–18 defined, 13–1
saving definitions to backup file, 14–17 defining, 13–7, 13–17, 13–18
server, 1–10 restoring definitions from backup file, 14–18
sound, 13–14
Machine Definitions, 10–6
Multiple EP Restart, 15–33
Machine Method, 15–27
Multiple Machine Queues, 10–18
maintenace
chase, 14–14
commands, 14–14
N
maintenance
backing up definitions
names, A–17
calendar definitions, 14–16
global variables, 14–17 naming conventions, A–15
job definitions, 14–16
Network Machine List, 15–21
machine definitions, 14–17
monitor and browser definitions, 14–17 Notification Mechanism, 15–35
clean_files, 14–15

Index–10 User Guide

Notifications screen granting, 2–12
Configuration Parameters, 15–37 machine, 2–12
Database Problem, 15–37 types, 2–11
Database Rolloever, 15–37 user, 2–10
Event Processor High Availability, 15–38 using umask, 2–10
Event Processor Rollover, 15–37 Windows NT, 2–13
Event processor Shutdown, 15–37
policy manager, 2–19
defined, 15–36
port number, default, 15–10
ntrys, 3–31
preferences
Number Errors, 15–26
alarm color, 6–3
removing user, 6–3
retry count, 6–3
O
profile script, 3–3

ON_HOLD, 3–14

ON_HOLD vs. ON_ICE, 3–15 Q

ON_ICE, 3–15
QUE_WAIT status, 3–14
one-time job overrides, 7–26
queuing and simple load limiting, 10–14
oracle
improving database performance, 14–33 queuing jobs, 10–13
synchronizing databases, 14–31
Queuing with Priority, 10–15
Oracle, 16–2
tablespace error, 16–9
troubleshooting, 16–3 R
overrides
job real machines, 10–1
GUI, 7–26
remote agent
owner defined, 1–7
default, 2–10 Local Agent Logging Directory, 15–10
log name
assigning, 16–21
P maintaining, 14–10
port number, 15–10
starting, 14–10
passwords
stopping, 14–11
autosys user, 2–9
TCP/IP, 15–10
database, 2–9
Remote Agent
permissions
database connectivity, 16–17
edit, 2–11
Event Processor authentication, 2–9
execute, 2–11
security, 2–17

Index–11
 troubleshooting, 16–15 restricting access to jobs, 2–16
user authentication, 2–8
Rule Specification region, 9–18
Remote Agent screen
Run MonBro button, 13–6
defining configuration parameters, 15–10
run number, 3–31
remote authentication
Event Processor, 2–9 Run Status Tool, 11–20
user, 2–8 Command field, 11–22
Description field, 11–22
Remote Authentication, 15–46
End Time field, 11–22
Remote Profile Logging, 15–32 Exit Code field, 11–22
Instance field, 11–22
reports
Job Name field, 11–22
naming, 13–5
Next Start field, 11–23
reports, 13–1 Predecessor and Successor Jobs fields, 11–23
about, 13–3 Priority field, 11–23
defined, 13–1 Queue Name field, 11–23
Run Machine field, 11–22
reports
Run Time field, 11–22
defining, 13–7
Start Time field, 11–22
reports Starting Conditions field, 11–22
defining, 13–9 Status field, 11–23
reports Try Count field, 11–22
all_status, 13–12 run_num/ntry
reports defined, 3–32
defining, 13–17 RUNNING status, 3–13
reports ruserok, 2–8
defining, 13–18

rescheduling rules, 9–22

S
resource classes, 2–22

Restart Constant, 15–30 Scheduler Console, 6–4, 11–1

Restart Factor, 15–29 buttons, 11–43
cancelling a sent event, 11–30
RESTART status, 3–14 Control Area, 11–8
restoring Filter Editor, 11–11, 11–12
calendar definitions, 14–18 Machine/Instance tab, 11–15
global variables (using autorep), 14–18 Names tab, 11–13
job definitions (using autorep), 14–18 Names Tab, 11–13
machine definitions (using autorep), 14–18 Status tab, 11–14
monitor and browser definitions, 14–18 filters, 11–11
Job Dependencies dialog, 11–18
restoring definitions, 14–18
Job Detail Report, 11–32

Index–12 User Guide

 job list, 11–8 preventing unauthorized access, 2–7
menu bar, 11–3 Remote Agent, 2–17
Preferences remote agent authentication, 2–8
Action Area Layout, 11–42 restricting access to jobs, 2–16
AutoRefresh, 11–34 security control, 2–13
General, 11–35 superuser privileges, 2–14
Summary Area Layout, 11–39 superusers
Time Perspective, 11–44 AutoSys, 2–14
User Defined Commands, 11–36 system level, 2–7
User Defined Reports, 11–38 umask, 2–10
refresh interval user and database administrator passwords, 2–9
setting for, 11–35 user authentication, 2–8
Reports user permissions, 2–10
Job Detail Report, 11–32 user types, 2–11
Send Event Tool, 11–23, 11–26
security access, 2–19
AUTOSERV instance, 11–29
Close button, 11–29 security control, 2–13
Comment field, 11–28
security enabled applications, 2–33
opening, 11–24
Send button, 11–29 Security Screen, 15–48
sorting specified jobs, 11–41 Configuration Parameters, 15–49
summary area, 11–8 Defined, 15–46
time perspective, 11–44 Send Event Tool, 11–23, 11–26
Tools AUTOSERV instance, 11–29
Dependent Jobs, 11–18 cancelling an event, 11–30
Run Status Tool, 11–20 Change Priority, 11–27
Send Event Tool, 11–23 Change Status, 11–27
Tools menu, 11–17 Close button, 11–29
user defined commands, 11–36 Comment, 11–26
viewing job dependencies, 11–18 Comment field, 11–28
security, 2–1 Force Start Job, 11–27
call logic, 2–34 Job Off Hold, 11–26
database field verification, 2–7 Job Off Ice, 11–27
event processor authentication, 2–9 Job On Hold, 11–26
events sent by the event processor, 2–4 Job On Ice, 11–27
events sent by users, 2–2 Kill Job, 11–27
granting permissions, 2–12 opening, 11–24
job definition encryption, 2–7 Send button, 11–29
job level, 2–10 Send Signal, 11–28
job ownership, 2–10 Set Global, 11–28
job permissions and windows, 2–13 Start Job, 11–26
native, 2–2 Stop Demon, 11–26
overview, 2–1 SEND_SIGNAL, 11–28
permission types, 2–11

Index–13
sendevent command, 2–15 SUCCESS, 3–13
TERMINATED, 3–14
server instance, 1–5
tracking changes, 13–12
server machine, 1–10 monitor/report
failure, 13–12
Services Screen
restart, 13–12
Components, 15–52
running, 13–12
Defined, 15–50
starting, 13–12
SET_GLOBAL, 11–28 success, 13–12
shadow event processor terminated, 13–12
defined, 1–6 processed vs. unprocessed, 3–18
using in job dependencies, 3–21
Shadow Machine, 15–20
STOP_DEMON, 11–26
Shadow Ping Delay, 15–23
Subsets—Individual queues, 10–17
sound monitor attribute, 13–14
success
Sounds Screen, 15–43 maximum exit code, 3–23
Configuration Parameters, 15–44
SUCCESS status, 3–13
specifying machine load, 10–3
Summary Area Layout Dialog, 11–39
Specifying Relative Process Power, 10–4
superusers, 2–14
Spring Time Change, 4–29, 4–31 Edit Superuser
starting conditions, 3–19, 3–21 defined, 2–14
exec superuser
STARTING status, 3–13
defined, 2–15
STARTJOB, 11–3, 11–26, 11–43
sybase
Startjob Poll Interval, 15–27 accessing, 14–39
architecture, 14–35
states
backing up to a file, 14–43
job, 3–13
bundeled backup, 14–41
See also status, 3–13
bundeled recovery, 14–41
status bundled database users, 14–36
job changing system administrator password, 14–37
ACTIVATED, 3–13 configuring a backup server, 14–42
as job dependency, 3–22 default user, 14–36
FAILURE, 3–14 dropping a damaged database, 14–44
INACTIVE, 3–13 environment, 14–35
ON_HOLD, 3–14 improving database performance, 14–33
ON_ICE, 3–15 maintaining bundled SQL servers, 14–35
QUE_WAIT, 3–14 recovering a bundled database, 14–43
RESTART, 3–14 re-creating the database, 14–44
RUNNING, 3–13 reloading the database, 14–45
STARTING, 3–13 starting, 14–37

Index–14 User Guide

 stopping, 14–38 time perspective in the Scheduler Console, 11–44
stopping event processor, 14–44
trace information, A–20
synchronizing databases, 14–30
troubleshooting, 16–1
synchronizing databases, 14–28
Event Processor, 16–9
Syntax Rules, 8–2 Event Servers, 16–4
Microsoft SQL Server, 16–3, 16–18
System Information screen
Oracle, 16–3
Configuration Parameters, 15–40
Remote Agent, 16–15
defined, 15–38
Sybase, 16–3
using, 15–39
troubleshooting tools
CCI, B–1
T troubleshooting tools
netstat, B–1
TCP/IP, remote agent, 15–10
troubleshooting tools
technical support, 1–16 ping, B–2

Term Calendar Rule dialog, 9–17 troubleshooting tools

nslookup, B–2
TERMINATED status, 3–14
troubleshooting tools
test mode
traceroute and tracert, B–3
output file, 14–13
running in, 14–12 troubleshooting tools
ccinet, B–3
The Time Change, 4–27

The Time Change

AutoSys Behavior, 4–28 U
The Time Change
Spring Time Change, 4–29 uid, 2–11

The Time Change Unicenter Events, 15–29

Fall Time Change, 4–31
UNIX Parameter
Third Machine, 15–21 #AutoRemPort, 15–10
AutoInstWideAppend, 15–32
Time Changes, 4–27
AutoRemoteDir, 15–22
time dependencies AutoSysAgentSupport, 15–34
overview, 3–20 Check_Heartbeat, 15–26
setting CleanTmpFiles, 15–31
GUI, 7–18 DB_PROBLEMt, 15–37
Time Dependencies DBAlarmReconnect, 15–17
Setting, 8–11 DBEventReconnect, 15–16
Setting DBLibWaitTime, 15–17
Additional Features, 8–11 DBMaintCmd, 15–22
DBMaintTime, 15–23

Index–15
 DB-ROLLOVER, 15–37 user types
EDErrTimeInt, 15–25 group, 2–11
EDMachine, 15–21 owner, 2–11
EDNumErrors, 15–26 world, 2–11
EP_HIGH_AVAIL, 15–38
Using
EP_ROLLOVER, 15–37
Services Screen, 15–53
EP_SHUTDOWN, 15–37
EventServer, 15–14 using max_load and factor, 10–5
EvtTransferWaitTime, 15–25
utilities
FileSystemThreshold, 15–24
provided with AutoSys, 1–12
KillSignals, 15–29
MachineMethod, 15–27
MaxRestartTrys, 15–28
V
MaxRestartWait, 15–28
RemoteProFiles, 15–32
RestartConstant, 15–30 virtual machines, 10–2
RestartFactor, 15–29
ThirdMachine, 15–21
XInstanceDBDropTimer, 15–27 W
unsupported attributes, A–22
Windows NT
User Defined Buttons dialog, 11–36 job permissions on, 2–13
User Defined Load Balancing, 10–19

User Defined Reports dialog, 11–38

X
user ID, 2–11

user IDs, A–17 Xinstance DB Drop Time, 15–27

Index–16 User Guide