UAJM User ENU PDF

Unicenter AutoSys Job
Management
User Guide
r11 SP4
This documentation and any related computer software help programs (hereinafter referred to as the
"Documentation") are for your informational purposes only and are subject to change or withdrawal by CA at any
time.
This Documentation may not be copied, transferred, reproduced, disclosed, modified or duplicated, in whole or in
part, without the prior written consent of CA. This Documentation is confidential and proprietary information of CA
and may not be used or disclosed by you except as may be permitted in a separate confidentiality agreement
between you and CA.
Notwithstanding the foregoing, if you are a licensed user of the software product(s) addressed in the
Documentation, you may print a reasonable number of copies of the Documentation for internal use by you and
your employees in connection with that software, provided that all CA copyright notices and legends are affixed to
each reproduced copy.
The right to print copies of the Documentation is limited to the period during which the applicable license for such
software remains in full force and effect. Should the license terminate for any reason, it is your responsibility to
certify in writing to CA that all copies and partial copies of the Documentation have been returned to CA or
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, LOST INVESTMENT, BUSINESS
INTERRUPTION, GOODWILL, OR LOST DATA, EVEN IF CA IS EXPRESSLY ADVISED IN ADVANCE OF THE
POSSIBILITY OF SUCH LOSS OR DAMAGE.
The use of any software product referenced in the Documentation is governed by the applicable license agreement
and is not modified in any way by the terms of this notice.
The manufacturer of this Documentation is CA.
Provided with "Restricted Rights." Use, duplication or disclosure by the United States Government is subject to the
restrictions set forth in FAR Sections 12.212, 52.227-14, and 52.227-19(c)(1) - (2) and DFARS Section 252.2277014(b)(3), as applicable, or their successors.
Copyright 2010 CA. All rights reserved. All trademarks, trade names, service marks, and logos referenced herein
belong to their respective companies.
CA Technologies Product References

This document references the following CA Technologies products:
eTrust Identity and Access Management (eTrust IAM)

Note: CA Embedded Entitlements Manager is the new name for eTrust
IAM. This product will be rebranded throughout the documentation in a
future release. This document refers to eTrust IAM and CA EEM
synonymously.
eTrust Access Control (eTrust AC)
Unicenter AutoSys Job Management (Unicenter AutoSys JM)
Unicenter CA-7 Job Management (Unicenter CA-7)
Unicenter CA-Jobtrac Job Management (Unicenter CA-Jobtrac)
Unicenter CA-Scheduler Job Management (Unicenter CA-Scheduler)
Unicenter Desktop and Server Management (Unicenter DSM)
Unicenter Event Management
Unicenter Management Command Center (Unicenter MCC)
Unicenter Management Portal
Unicenter Network and Systems Management (Unicenter NSM)
Unicenter Service Desk
Unicenter Universal Job Management Agent (UUJMA)
Unicenter Workload Control Center (Unicenter WCC)
Contact CA Technologies
Contact Technical Support
For your convenience, CA Technologies provides one site where you can
access the information you need for your Home Office, Small Business, and
Enterprise CA Technologies products. At http://ca.com/support, you can
access the following:
Online and telephone contact information for technical assistance and

customer services
Information about user communities and forums
Product and documentation downloads
CA Support policies and guidelines
Other helpful resources appropriate for your product
Provide Feedback
If you have comments or questions about CA Technologies product
documentation, you can send a message to techpubs@ca.com.
If you would like to provide feedback about CA Technologies product
documentation, complete our short customer survey, which is available on the
CA Support website at http://ca.com/docs.
Contents
Chapter 1: Introduction
15
Operating Environment Conventions ...................................................................................... 16

Automated Job Control ........................................................................................................ 16
Jobs .................................................................................................................................. 17
Defining Jobs ................................................................................................................ 17
System Components............................................................................................................ 18
Event Server ................................................................................................................. 18
Application Server ......................................................................................................... 19
Scheduler ..................................................................................................................... 20
Agent .......................................................................................................................... 21
How the Event Server, Scheduler, Application Server, and Agents Interact............................. 22
Client ........................................................................................................................... 25
Start and Stop Unicenter AutoSys JM Components ............................................................. 25
Interface Components .................................................................................................... 27
Communications ................................................................................................................. 27
Computers ......................................................................................................................... 28
Instances ........................................................................................................................... 28
Events ............................................................................................................................... 29
Alarms .............................................................................................................................. 29
Utilities .............................................................................................................................. 30
Extending Functionality ........................................................................................................ 30
Unicenter AutoSys JM Connect......................................................................................... 30
Unicenter AutoSys JM Adapters........................................................................................ 30
Unicenter Universal JM Agent .......................................................................................... 31
Port Multiplexing (PMUX) ................................................................................................ 33
SSL Encryption of Unicenter AutoSys JM Messages ............................................................. 34
About the Unicenter AutoSys JM Administrator Utility ............................................................... 35
Start the Administrator ................................................................................................... 36
Chapter 2: Security
37
Security in Unicenter AutoSys JM .......................................................................................... 37

System-Level Security ......................................................................................................... 38
Database Field Verification .............................................................................................. 38
Job Definition Encryption ................................................................................................ 38
Agent Authentication ...................................................................................................... 39
User and Database Administrator Passwords...................................................................... 42
Restricting Unicenter AutoSys JM Through the File System................................................... 43
Contents 5
eTrust Embedded Identity and Access Management ................................................................. 44

Delegation of Administrative Privileges ............................................................................. 44
AS_EEM_AUTHUSER_MODE Environment Variable .............................................................. 45
Policy Synchronization .................................................................................................... 46
Asset-Level Security ...................................................................................................... 48
Resource Classes ........................................................................................................... 49
How an Application is Security-Enabled ............................................................................. 63
Create an Asset ............................................................................................................. 63
Update an Asset ............................................................................................................ 64
Delete an Asset ............................................................................................................. 64
List a Set of Assets ........................................................................................................ 65
Native Security ................................................................................................................... 65
Security Control ............................................................................................................ 66
Superusers ................................................................................................................... 67
Asset-Level Security ...................................................................................................... 68
Job Ownership .............................................................................................................. 69
User Types ................................................................................................................... 70
Permission Types ........................................................................................................... 71
Granting Permissions ..................................................................................................... 72
Job Permissions and Windows ......................................................................................... 73
Security on Events Sent by Users ..................................................................................... 73
Chapter 3: Job Definitions
75
Job Attributes ..................................................................................................................... 75

Create a Job Definition Using JIL ........................................................................................... 76
Create a Job Definition Using the Unicenter WCC GUI ............................................................... 76
JIL Subcommands ............................................................................................................... 77
Job Attributes ..................................................................................................................... 78
Date and Time Attributes and Time Changes ........................................................................... 80
Daylight Time Changes ................................................................................................... 81
Standard Time Changes.................................................................................................. 82
Chapter 4: Job Types, Structure, and States
85
Introducing Jobs ................................................................................................................. 85

Job Types and Structure ...................................................................................................... 86
Basic Job Information ..................................................................................................... 87
Command Jobs.............................................................................................................. 87
Box Jobs ...................................................................................................................... 88
File Watcher Jobs .......................................................................................................... 89
Create a New Job Type ................................................................................................... 89
Use a New Job Type ....................................................................................................... 90
6 User Guide
Starting Conditions and Boxes ......................................................................................... 90

How the Agent Sets Job Profiles ............................................................................................ 91
Environment Variables ................................................................................................... 92
Use the Job Profiles Manager ........................................................................................... 93
Delete a Job Profile ........................................................................................................ 94
Create a Variable Definition ............................................................................................. 95
Edit a Variable Definition ................................................................................................ 96
Delete a Variable Definition ............................................................................................. 97
Basic Job Attributes ............................................................................................................. 98
Command Job Attributes................................................................................................. 98
File Watcher Job Attributes ............................................................................................. 98
Box Job Attributes ......................................................................................................... 99
Job States .........................................................................................................................100
Starting Conditions............................................................................................................. 104
Date and Time Dependencies ......................................................................................... 105
Job Dependencies Based on Job Status ............................................................................ 106
Managing Job Status ..................................................................................................... 108
Cross-Instance Job Dependencies ...................................................................................109
Job Dependencies Based on Exit Codes ............................................................................ 113
Job Dependencies Based on Global Variables .................................................................... 116
Job Run Numbers and Names .............................................................................................. 117
Chapter 5: Box Job Logic
119
Basic Box Concepts ............................................................................................................ 119

Default Box Job Behavior ...............................................................................................119
Box Job Recommendations............................................................................................. 120
How a Box Runs ........................................................................................................... 120
How Job Status Changes Affect Box Status ....................................................................... 122
Box Job Attributes and Terminators ......................................................................................122
Attributes in a Box Job Definition .................................................................................... 123
Attributes in a Job Definition .......................................................................................... 123
Time Conditions in a Box ............................................................................................... 124
Force Jobs in a Box to Start ........................................................................................... 125
Box Job Flow Examples ....................................................................................................... 126
Default Box Success and Box Failure ............................................................................... 126
Explicit Box Success and Box Failure ............................................................................... 128
Job Flow with Job Terminator Attribute ............................................................................ 130
Job Flow with Box Terminator Attribute ............................................................................ 132
Advanced Job Flows ........................................................................................................... 134
Job Flow with Time Conditions Running on the First of the Month ......................................... 134
Job Flow with Time Conditions Running on the Second of the Month ..................................... 136
Job Flow with Time Conditions Running on the First of the Following Month ........................... 137
Contents 7
Resetting a Job Flow with Time Conditions Through INACTIVE Status Change ........................ 138
Resetting a Job Flow with Time Conditions Through Box Job................................................ 139
Chapter 6: Defining Jobs Using JIL
141
JIL Syntax Rules ................................................................................................................ 142

JIL Subcommands ..............................................................................................................144
User-Defined Job Types ......................................................................................................146
Submit a Job Definition in a JIL Script ................................................................................... 148
Submit a Job Definition in JIL Interactive Mode....................................................................... 149
Running a Job After Using JIL .............................................................................................. 150
How a Simple Command Job Is Created ................................................................................ 151
How a File Watcher Job Is Created ........................................................................................ 152
How a Dependent Command Job Is Created ........................................................................... 153
Look-Back Conditions .................................................................................................... 154
How a Box Job Is Created ...................................................................................................155
How Job Groupings Are Created ........................................................................................... 156
How Machines Are Added ....................................................................................................157
How an Existing Job Is Put in a Box ...................................................................................... 159
How Time Dependencies Are Set .......................................................................................... 160
Delete a Job ...................................................................................................................... 162
Delete a Box Job ................................................................................................................ 162
Specifying One-Time Job Overrides ....................................................................................... 163
How Job Overrides Are Set ............................................................................................. 165
Example JIL Script ............................................................................................................. 166
Chapter 7: Binary Large Object Definitions
169
Binary Large Objects .......................................................................................................... 170

Types of Blobs ................................................................................................................... 172
Job Blobs .......................................................................................................................... 172
Input Job Blobs ............................................................................................................ 172
Output and Error Job Blobs ............................................................................................ 173
Global Blobs ...................................................................................................................... 173
Manage Blobs Using JIL ......................................................................................................173
Blob Attributes .................................................................................................................. 174
Create Input Job Blobs ........................................................................................................ 175
Delete Job Blobs ................................................................................................................ 176
Create Global Blobs ............................................................................................................ 176
Delete Global Blobs ............................................................................................................ 177
Use Blobs in Job Definitions ................................................................................................. 178
std_in_file Attribute ......................................................................................................178
std_out_file and std_err_file Attributes ............................................................................ 179
8 User Guide
Generate Blob Reports Using Autorep.................................................................................... 180
Chapter 8: Machines
183
Real Machines ................................................................................................................... 183

Virtual Machines ................................................................................................................ 184
Defining Machines .............................................................................................................. 184
Specifying Machine Load (max_load) ............................................................................... 186
Specifying Job Load (job_load) ....................................................................................... 186
Specifying Queuing Priority (priority) ............................................................................... 187
Specifying Relative Processing Power (factor) ................................................................... 188
Machine Definitions ............................................................................................................ 189
Define a Real Machine ................................................................................................... 190
Delete a Real Machine ................................................................................................... 190
Define a Virtual Machine ................................................................................................ 191
Delete a Virtual Machine ................................................................................................ 193
Delete a Real Machine from a Virtual Machine ................................................................... 193
Machine Status .................................................................................................................. 194
Take a Machine Offline Manually ..................................................................................... 195
Put a Machine Online Manually ....................................................................................... 195
How Status Changes Automatically ................................................................................. 196
How Status Affects Jobs on Virtual Machines ..................................................................... 196
Load Balancing .................................................................................................................. 197
Forcing a Job to Start ......................................................................................................... 200
Queuing Jobs.....................................................................................................................200
How Unicenter AutoSys JM Queues Jobs........................................................................... 201
Using a Virtual Machine as a Subset of a Real Machine ....................................................... 204
Using a Virtual Machine to Combine Subsets of Real Machines ............................................. 205
User-Defined Load Balancing ............................................................................................... 206
Chapter 9: Monitoring and Reporting Jobs
207
Monitors and Reports .......................................................................................................... 207

Monitors ......................................................................................................................208
Reports ....................................................................................................................... 208
Define a Monitor or Report .................................................................................................. 208
Essential Monitor and Report Attributes ................................................................................. 209
Common Essential AttributesGeneral ............................................................................ 209
Common Essential AttributesEvents .............................................................................. 210
Essential Report Attributes .............................................................................................213
Optional Monitor Attributes .................................................................................................. 214
Verification Required for Alarms ...................................................................................... 214
Define Monitors and Reports Using JIL .................................................................................. 215
Contents 9
Run a Report or Monitor ......................................................................................................216
Chapter 10: Maintaining the Scheduler
217
Overview of Scheduler Maintenance ...................................................................................... 217

Start the Scheduler ............................................................................................................ 218
How the Scheduler Starts Processes .....................................................................................219
How You Can Back Up Definitions ......................................................................................... 220
Back Up Calendar Definitions .......................................................................................... 220
Back Up Job, Machine, and Monitor Definitions .................................................................. 221
Back Up Global Variable Definitions ................................................................................. 222
Restore Definitions ............................................................................................................. 223
Monitoring the Scheduler .................................................................................................... 225
Scheduler Log File Location ............................................................................................226
Start the Scheduler in Global Auto Hold Mode......................................................................... 226
How Shadow Scheduler Rollover Works ................................................................................. 228
Restore the Primary Scheduler After a Rollover....................................................................... 229
Stop the Scheduler ............................................................................................................. 231
Running the Scheduler in Test Mode ..................................................................................... 232
Chapter 11: Maintaining the Agent
235
Overview of Agent Maintenance ........................................................................................... 235

Start the Agent ..................................................................................................................236
Maintenance Commands ..................................................................................................... 238
Chapter 12: Maintaining the Event Server
239
Overview of Event Server Maintenance.................................................................................. 240

Using Dual Event Server Mode ............................................................................................. 240
Database Architecture ........................................................................................................ 241
Database Storage Requirements ..........................................................................................243
General Database Maintenance ............................................................................................ 243
Reschedule Daily Database Maintenance................................................................................ 244
How the DBMaint.bat Batch File or DBMaint Script Runs........................................................... 245
Modify the DBMaint.bat File or DBMaint Script ........................................................................ 246
Reduce the Frequency of Sybase Deadlocks ........................................................................... 247
Event Server Rollover Recovery ........................................................................................... 248
Return to Dual Event Server Mode After a Rollover ............................................................ 249
Synchronize the Event Servers ....................................................................................... 252
Handle Errors ............................................................................................................... 257
High Availability Recovery ................................................................................................... 258
Detect Missing Databases .............................................................................................. 258
10 User Guide
Configure the Scheduler Heartbeat Interval ...................................................................... 260

Recovery Scenarios Summary .............................................................................................. 261
Non-High Availability in Single Event Server Mode ............................................................. 261
Non-High Availability in Dual Event Server Mode ............................................................... 261
High Availability in Single Event Server Mode .................................................................... 262
High Availability in Dual Event Server Mode ...................................................................... 263
Chapter 13: Configuring Unicenter AutoSys JM
265
Configuration File ............................................................................................................... 266

Configure File Parameters ...................................................................................................266
Sample Configuration File .................................................................................................... 267
DBLibWaitTime ParameterConfigure Database Time-Out Period (Sybase Only) .................... 267
SNMP Connections ........................................................................................................ 268
DBEventReconnect ParameterSet Number of Scheduler Connection Attempts ..................... 269
EDNumErrors and EDErrTimeInt ParametersDefine Error Threshold ................................... 270
FileSystemThreshold ParameterSet Minimum Scheduler Log Disk Space............................. 270
DBMaintTime and DBMaintCmd ParametersConfigure Automatic Database Maintenance ....... 271
EvtTransferWaitTime ParameterSet the Event Transfer Time-Out for Dual Event Server
Mode ..........................................................................................................................271
SendeventMaxRetries ParameterSet Maximum Number of sendevent Retries ...................... 272
SendeventRetryInterval ParameterSet an Interval for sendevent Retries ............................ 272
Check_Hearbeat ParameterSet the Interval Between Heartbeat Checks ............................. 273
AutoRemoteDir ParameterDefine a Directory for Agent Logging ........................................ 274
CleanTmpFiles ParameterAutomatically Remove Temporary Agent Log Files ....................... 275
RemoteProFiles ParameterRedirect stderr and stdout Output to a File ................................ 276
MaxRestartTrys ParameterSet the Maximum Number of Job Restart Attempts ..................... 277
RestartConstant, RestartFactor, and MaxRestartWait ParameterCalculate Wait Time
Between Restart Attempts ............................................................................................. 279
MachineMethod ParameterSpecify Load Balancing Method ................................................ 280
KillSignals ParameterSpecify Signals for KILLJOB Events .................................................. 281
AutoRemPort ParameterSet Legacy Agent Port Number ................................................... 282
CrossPlatformScheduling ParameterActivate the Cross-Platform Interface .......................... 283
AutoInstWideAppend ParameterSpecify Whether to Overwrite Standard Error and
Standard Output........................................................................................................... 284
InetdSleepTime ParameterDefine Interval Between Job Starts for an Agent ........................ 285
UnicenterEvents ParameterActivate Unicenter Event Integration ....................................... 285
NotifyServerNode and NotifyAckTimeout ParametersActivate Unicenter Notification
Integration ..................................................................................................................286
ServiceDeskCust, ServiceDeskURL, and ServiceDeskUser ParametersActivate Unicenter
Service Desk Integration ............................................................................................... 287
auto.profile File..................................................................................................................288
Sample auto.profile File .................................................................................................289
Contents 11
ISDBGACTIV ParameterSet Run Time Trace Level ........................................................... 290

Configuring Remote Authentication ....................................................................................... 291
Configuring Unicenter AutoSys JM Scheduler Authentication................................................ 291
Client-Side Security ............................................................................................................ 292
User-Defined Alarm Callbacks .............................................................................................. 293
Notification Example ..................................................................................................... 294
Chapter 14: Dynamic Workload Placement
295
The CA Management Database and Unicenter DSM ................................................................. 296

Dynamic Workload Placement Scenarios ................................................................................ 297
Manage Machine Definitions with autodwp ............................................................................. 298
Unicenter AutoSys JM Machine Attributes ......................................................................... 300
Unicenter DSM Discovered Machine Attributes .................................................................. 301
Chapter 15: Troubleshooting
303
How System Components Are Affected When a Job Is Defined .................................................. 303
Windows Services Troubleshooting ....................................................................................... 304
Event Server Troubleshooting .............................................................................................. 305
Event Server Is Down ................................................................................................... 305
Deadlocks....................................................................................................................306
Not Enough User Connections ......................................................................................... 306
Scheduler Troubleshooting .................................................................................................. 307
Scheduler Is Down ........................................................................................................ 308
Scheduler Will Not Start ................................................................................................ 309
Scheduler Will Not Start ................................................................................................ 312
Agent Troubleshooting ........................................................................................................ 314
Agent Not Responding ................................................................................................... 315
Agent Not Responding ................................................................................................... 316
Agent Temporary Files................................................................................................... 317
Agent Starts, Command Runs: No RUNNING Event Is Sent ................................................. 318
Job Failure Troubleshooting ................................................................................................. 321
Agent Will Start: Command Will Not Run .......................................................................... 321
Agent Not Found .......................................................................................................... 327
Jobs Run Only From the Command Line ........................................................................... 328
Jobs Run Twice ............................................................................................................ 330
Application Server Troubleshooting ....................................................................................... 331
Application Server Is Down ............................................................................................ 332
Application Server Will Not Start ..................................................................................... 334
Application Server Starts, Clients on Remote Machine Times out.......................................... 337
12 User Guide
Chapter 16: Unicenter Integration
341
Integrating Event Management ............................................................................................ 341

How Event Management Processes Events ........................................................................ 342
Installation Considerations .............................................................................................343
Configure Message Forwarding ....................................................................................... 345
Integrating Unicenter Notification Services ............................................................................. 346
How Unicenter Notification Services Works ....................................................................... 348
Installation Considerations .............................................................................................349
Configure Notification .................................................................................................... 350
Send Notifications with Unicenter AutoSys JM ................................................................... 351
Integrating Unicenter Service Desk ....................................................................................... 352
Configure Unicenter AutoSys JM to Activate Its Unicenter Service Desk Interface ................... 352
Initiate a Service Desk Ticket with Unicenter AutoSys JM .................................................... 354
Appendix A: Cross-Platform Scheduling Considerations
355
Integrating Cross-Platform Scheduling .................................................................................. 356

Definition of Terms ............................................................................................................. 357
Enterprise Job Scheduling Prerequisites ................................................................................. 359
Cross-Platform Considerations ............................................................................................. 360
Configure Enterprise Job Scheduling ..................................................................................... 361
PRIMARYCCISYSIDCross-Platform Environment Variable ....................................................... 364
Bi-Directional Scheduling .................................................................................................... 365
Unicenter AutoSys JM Connect Cross-Platform Dependencies .................................................... 366
Naming Conventions for Unicenter AutoSys JM Connect Cross-Platform Jobs ......................... 367
How Job Scheduler Interdependencies Are Created ............................................................ 367
Define Cross-Platform Job Dependencies .......................................................................... 368
Running Jobs on UUJMA ...................................................................................................... 369
Naming Conventions for UUJMA Job Names and User IDs ................................................... 370
How Jobs Are Run On UUJMA-Managed Computers ............................................................ 370
Define UUJMA Computers .............................................................................................. 371
Add User IDs and Passwords on a UUJMA Computer .......................................................... 372
Job Definition Examples ................................................................................................. 374
Cross-Platform Interface Messages ....................................................................................... 376
Unsupported Attributes for Unicenter AutoSys JM Connect or UUJMA Jobs .................................. 377
Appendix B: Legacy Agent Considerations
379
Running Jobs on Computers with Legacy Unicenter AutoSys JM Agents ...................................... 380
Define Legacy Agent Computers ..................................................................................... 380
Define the Legacy Agent Port ......................................................................................... 381
Add User IDs and Passwords for a Windows Legacy Agent Computer .................................... 382
Contents 13
How Jobs Are Run On Legacy Agent Computers ................................................................ 384
Appendix C: General Debugging
385
ISDBGACTIV ..................................................................................................................... 385

Configure the Client Utilities to Run With Traces ................................................................ 385
Configure the Scheduler and Application Server to Run With Traces ..................................... 386
Configure the Agent to Run With Traces ........................................................................... 387
Trace Settings .............................................................................................................. 388
Appendix D: Message Port and SSL Configuration
389
Configuring Unicenter AutoSys JM to Use PMUX and SSL .......................................................... 389

Port Multiplexing ................................................................................................................ 389
How to Configure the Application Server to Listen on a Different Virtual Port ......................... 390
Virtual Ports Used by Unicenter AutoSys JM ...................................................................... 391
How to Configure Unicenter AutoSys JM to Run with SSL ......................................................... 392
Appendix E: Aggregator Considerations
395
About Unicenter AutoSys JM Aggregator ................................................................................ 395

Running the Unicenter AutoSys JM Aggregator ....................................................................... 396
Unicenter AutoSys JM Aggregator Statistics ........................................................................... 397
Appendix F: Tuning Unicenter AutoSys JM
399
Tuning the Scheduler .......................................................................................................... 400

Tuning the Application Server .............................................................................................. 402
Tuning the Agent ............................................................................................................... 403
Index
14 User Guide
405
Chapter 1: Introduction
This guide is for users responsible for defining jobs to Unicenter AutoSys JM
and monitoring and managing these jobs. It assumes familiarity with the
operating system on which jobs are run, and it assumes that you have already
installed and are running Unicenter AutoSys JM.
Note: For more information, see the Windows or UNIX Implementation
Guides.
This section contains the following topics:
Operating Environment Conventions (see page 16)
Automated Job Control (see page 16)
Jobs (see page 17)
System Components (see page 18)
Communications (see page 27)
Computers (see page 28)
Instances (see page 28)
Events (see page 29)
Alarms (see page 29)
Utilities (see page 30)
Extending Functionality (see page 30)
About the Unicenter AutoSys JM Administrator Utility (see page 35)
Introduction 15
Operating Environment Conventions
Operating Environment Conventions

The majority of the information in this guide applies generically to both the
Windows and UNIX operating environments. However, this guide uses the
following identifiers to denote operating environment-specific information:
Denotes information that is specific to Microsoft Windows operating

environments.
Unless otherwise noted, the term Windows refers to any Microsoft
Windows operating system supported by Unicenter AutoSys JM.
Note: For information about which specific Microsoft operating systems
Unicenter AutoSys JM supports, see the readme.
Denotes information that is specific to UNIX operating environments.
Denotes the end of operating environment-specific information.
Automated Job Control

Unicenter AutoSys JM is an automated job control system for scheduling,
monitoring, and reporting.
A job is any single command, executable, script, or batch file. These jobs can
reside on any configured machine that is attached to a network. Corresponding
job definitions contain a variety of qualifying attributes for associated jobs,
including the conditions specifying when and where a job should run.
As with most control systems, there are many ways to correctly define and
implement jobs. It is likely that the way you use Unicenter AutoSys JM to
address your distributed computing needs will evolve over time. As you
become more familiar with the product features and the characteristics of your
jobs, you can refine your use of Unicenter AutoSys JM.
However, before you install and use Unicenter AutoSys JM, you must
understand the basic system, its components, and how these components
work together.
This chapter provides a brief overview of Unicenter AutoSys JM, its
architecture, and its features.
16 User Guide
Jobs
Jobs
In the Unicenter AutoSys JM environment, a job is a single action that can be
performed on a valid Agent computer. On Windows, this action can be any
single command, executable, or batch file. On UNIX, this action can be any
single command or shell script. Corresponding job definitions include attributes
that define various characteristics of associated jobs, included when and where
the jobs should run.
Defining Jobs
You can use either of the following methods to define a job by assigning it a
name and specifying the attributes that describe its associated behavior.
Unicenter WCC
The Unicenter WCC GUI lets you interactively set the attributes that
describe when, where, and how a job should run. The fields in the
Unicenter WCC GUI correspond to the JIL subcommands and attributes. In
addition, from the Unicenter WCC GUI, you can define calendars, global
variables, and jobsets, and monitor and manage jobs. Unicenter WCC is
supplied with Unicenter AutoSys JM.
Job Information Language
Job Information Language (JIL) is a scripting language with its own syntax
that provides a way to define various Unicenter AutoSys JM assets such as
jobs, global variables, machines, job types, external instances, and blobs.
JIL scripts contain one or more JIL subcommands and one or more
attribute statements; these elements constitute a job definition.
When you enter the jil command, the JIL command prompt is displayed so
you can enter the job definitions one line at a time. When you exit the JIL
command prompt, the job definition is loaded into the database.
Alternatively, you can enter the definition as a text file and redirect 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.
The specification created using these methods comprise of a job definition.
Introduction 17
System Components
System Components
The main system components of Unicenter AutoSys JM are:
Event Server (database)
Application Server
Scheduler
Agent
Client
The following illustration shows the system components in a basic

configuration, and displays the communication paths between them:
Event Server
The Event Server is the database in which the system state and object
definitions are stored. Objects include but are not limited to calendars, jobs,
and global variables. To aid in disaster recovery, much of the active state of
the system, in particular the Scheduler, is stored in the Event Server. For
example, events and their current states, machine statuses, job statuses, and
machine queues are all stored in the Event Server.
18 User Guide
System Components
Occasionally, the database is called a data server, which actually describes a

server instance. That is, it is either a UNIX process or Windows service and its
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 Unicenter
AutoSys JM database for that instance. Some database utilities let you specify
a particular server and database.
Unicenter AutoSys JM supports various database vendors including Oracle,
Sybase, and Microsoft SQL Server. There are only two processes that interface
directly with the database: the Scheduler and the Application Server.
Therefore, those processes require a vendor database Client installation to
access the database. All other Unicenter AutoSys JM processes interface with
the Application Server and do not require database Client installations. The
Scheduler and the Application Server interact with the database using
vendor-specific native code libraries. They do not use Open Database
Connectivity (ODBC) or any other third-party interface.
Dual Event Servers

You can configure Unicenter AutoSys JM to run using two databases, or Dual
Event Servers. This feature provides complete redundancy so that, 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. This feature is independent of any replication or redundancy
offered by the database.
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 for Unicenter AutoSys JM only, or
it can be shared with other applications.
Note: For more information, see the Windows or UNIX Implementation Guide.
Application Server
The Application Server, which runs either as a UNIX process or a Windows
service, manages communication between the Event Server, Agent, and client
utilities.
Introduction 19
System Components
Scheduler
The Scheduler is the core component of Unicenter AutoSys JM. Sometimes
called the event_demon, the Scheduler is the program, running either as a
UNIX process or as a Windows service that actually runs Unicenter AutoSys
JM.
The Scheduler is event-driven. After you start it, the Scheduler periodically
queries the database for events to process. As events are retrieved, the
Scheduler acts on them as appropriate. Events have various origins: some are
manually sent by a user; others are sent by an Agent to indicate the progress
of a job. An event often requires an Agent process to perform an action. These
actions may include starting or stopping jobs, determining availability of
resources, monitoring existing jobs, or initiating corrective procedures.
High Availability Option: Shadow Scheduler

Unicenter AutoSys JM lets you set up a second Scheduler, called the Shadow
Scheduler. Each Scheduler should run on a separate computer.
Both the Primary Scheduler and the Shadow Scheduler periodically update the
Event Server to indicate that they are in active mode. The Shadow Scheduler
remains in an idle mode, receiving periodic messages called pings from the
Primary Scheduler. Basically, these messages indicate that the Primary
Scheduler is operating correctly. However, if the Primary Scheduler fails for
some reason, the Shadow Scheduler takes over the responsibility of
interpreting and processing events.
20 User Guide
System Components
High Availability Option and Dual Event Servers: Tie-breaker Scheduler

When you run both the High Availability and Dual Event Server options, an
additional Scheduler process, called the Tie-breaker Scheduler, is required.
Without this process, both the Primary and Shadow Schedulers assume that
the other Scheduler has failed and, therefore, both proceed with processing
events.
For example, imagine a scenario where the Shadow Scheduler is configured to
run on the same computer as one of the Event Servers, and this computer
gets disconnected from the network. The Shadow Scheduler continues to use
the Event Server on its node assuming there has been an Event Server failure
and that the Primary Scheduler has failed. However, it is actually the Shadow
Scheduler computer that has failed.
The Tie-breaker Scheduler running on a third node resolves this problem. It
remains permanently idle and updates the Event Servers periodically to
indicate its presence. In the example scenario, the Shadow Scheduler realizes
that it is the failed node when it does not receive updates from the Tie-breaker
Scheduler.
Agent
The Agent consists of two processes, a persistent or parent Agent and a
non-persistent or child Agent that is started by the parent for every job that is
run. The child Agent starts and monitors the job process and exits when the
job is completed.
On Windows, the parent Agent is a Windows service (autosysd.exe), and

the child Agent is an executable (auto_remote.exe).
On UNIX, the parent Agent is a binary (auto_remote), and the child

Agent is a split image of it.
The child Agent sends running and completion information about the job to the
Application Server. If the Agent cannot transfer the information, it waits and
retries until it can successfully communicate with the Application Server.
Introduction 21
System Components
How the Event Server, Scheduler, Application Server, and Agents Interact
This example scenario and the numbered explanations illustrate the
interactions between the Event Server, the Scheduler, the Application Server,
and the Agents.
In the example, the following Windows command is to run on the Agent

when the job starts. In this scenario, the Scheduler reads a STARTJOB event
for the job from the Event Server.
del C:\tmp\*.*
In the example, the following UNIX command line is used to run the
Agent when the job starts. In this scenario, the job starts when the Scheduler
reads a STARTJOB event for the job from the Event Server.
rm /temp/mystuff/*
Note: Understanding this example can help you answer questions that may
arise while using Unicenter AutoSys JM.
22 User Guide
System Components
The following illustration shows how the system components interact in an

example scenario on Windows and UNIX:
Note: In the previous illustration, the three primary components (Scheduler,

Event Server, and Agent) are shown running on different computers. Typically,
the Scheduler and the Event Server run on the same computer.
Introduction 23
System Components
The following steps explain the interactions in the example scenario:

1.
The Scheduler reads a new event (a STARTJOB event for which a start
time condition has been met) from the Event Server. Then, the Scheduler
reads the appropriate job definition from the database, including the
command and the full path name to the profile to use for the job. For jobs
running on Windows computers, the Scheduler also retrieves the user IDs
and passwords required to run the job on the client computer. In the
example, the Agent runs the following command:
del C:\tmp\*.*
rm /temp/mystuff/*
2.
The Scheduler issues a STARTING event to the Event Server, which the
Event Server processes later. Then the Scheduler passes the necessary
details about the job to the parent Agent. The details include the command
to run and how to contact the Application Server.
3.
The parent Agent starts the child Agent, which is responsible for
monitoring the progress of the Client job. At this point, the parent has
completed and awaits additional jobs to run from the Scheduler.
4.
The child Agent completes the communication with the Scheduler. The
Scheduler understands that the Agent has everything it requires to run the
Client job, and the Agent can continue without further interaction with the
Scheduler.
5.
The Agent checks the resource to verify that the minimum number of
processes is available. Then the child Agent logs on to the computer as the
user listed as the owner in the job definition. On Windows, the Agent uses
the credentials passed to it from the Scheduler. Finally, the Agent creates
a child process that runs the command specified in the job definition.
6.
When the Client job starts successfully, the Agent sends a RUNNING event
to the Application Server. The Application Server places the RUNNING
event in the Event Server.
7.
The command completes and exits, and the Agent captures the command
exit code.
8.
The Agent communicates the event, including the exit code and status, to
the Application Server, which in turn places the event in the Event Server.
If the job completes successfully, the Agent deletes the log file on the
Agent computer, based on configuration specifications. The child Agent
then exits.
To complete the operation, the Scheduler processes the events sent by the
Agent in Steps 6 and 8, which in turn may start other jobs.
24 User Guide
System Components
Four critical applications must be running for this process to work: the Event
Server, the Scheduler, the Agent, and the Application Server. If any of these is
not active, the job does not complete on time.
Client
A Client is any executable that interfaces with the Application Server. This
includes Unicenter AutoSys JM Command Line Interface (CLI) applications
such as JIL and autorep. It also includes the Unicenter WCC services which are
Clients of the Application Server and service the Unicenter WCC GUI
components and any user-defined binaries that link to the Unicenter AutoSys
JM SDK.
Note: For more information, see the SDK User Guide.
Client applications work by calling Application Programming Interfaces (APIs)
made available in the Application Server. A Client can run anywhere in the
enterprise provided it can reach the node on which the Application Server is
running. It does not require installation of a database vendor client. Clients are
the means by which users control the scheduling environment by creating and
monitoring the scheduling resources.
Start and Stop Unicenter AutoSys JM Components

You can use the following utility to start, stop, and determine the status
of Unicenter AutoSys JM components:
unisrvcntr
To view all the options of this utility, run the following command:
unisrvcntr -?
To determine the status of all the CA services that are installed on a machine,
run the following command:
unisrvcntr status
Introduction 25
System Components
Agent
Run the following command to start the Unicenter AutoSys JM Agent:
unisrvcntr start uajm_agent
Run the following command to stop the Unicenter AutoSys JM Agent:

unisrvcntr stop uajm_agent
Run the following command to determine the Unicenter AutoSys JM Agent

status:
unisrvcntr status uajm_agent
Application Server
Run the following command to start the Unicenter AutoSys JM Application
Server:
unisrvcntr start uajm_server.$AUTOSERV
Run the following command to stop the Unicenter AutoSys JM Application

Server:
unisrvcntr stop uajm_server.$AUTOSERV
Run the following command to determine the Unicenter AutoSys JM

Application Server status:
unisrvcntr status uajm_server.$AUTOSERV
Scheduler
Run the following command to start the Unicenter AutoSys JM Scheduler:
unisrvcntr start uajm_sched.$AUTOSERV
Run the following command to stop the Unicenter AutoSys JM Scheduler:

unisrvcntr stop uajm_sched.$AUTOSERV
Run the following command to determine the Unicenter AutoSys JM

Scheduler status:
unisrvcntr status uajm_sched.$AUTOSERV
26 User Guide
Communications
Interface Components
You can use either the Unicenter WCC GUI or CLI to define, monitor, and
report on jobs. In addition, the Job Status Console and its dialogs provide a
sophisticated method of monitoring jobs in real time. The Job Status Console
lets you view all defined jobs, whether they are currently active or not.
Unicenter AutoSys JM also provides the Unicenter AutoSys JM Administrator,
with which you can set configuration parameters, and the Job Profiles
Manager, with which you can set up job environment variables (or profiles) to
associate with jobs in their definitions.
Communications
Network communication between the Scheduler and the Agent, between the
Agent and the Application Server, and between the Client and the Application
Server is accomplished by proprietary middleware known as RRP.
Note: For more information, see the SDK User Guide.
RRP is implemented using proprietary technology known as libmsg over the
Secure Socket Adapter (SSA). SSA is a CA transport adapter, provided with CA
common components, which supports port multiplexing and SSL
authentication and encryption. libmsg is a high-performance, multi-threaded
library that manages delivery and acknowledgement of data using SSA.
Note: For more information about CA common components, see the CA
common components documentation.
Together, these technologies provide a robust, flexible, high-performance,
portable method of communication for Unicenter AutoSys JM applications.
Introduction 27
Computers
Computers
Unicenter AutoSys JM's architecture comprises the following types of
computers attached to a network:
The server is the computer on which the Application Server, Scheduler, or

Event Server (database) resides. In a basic configuration, the Application
Server, Scheduler, and Event Server reside on the same computer.
The Client is the computer on which the Client software resides. A Client
must be installed on the server computer and can also be installed on
separate physical Client computers.
The Agent is the computer on which the Agent software resides and where
jobs run. An Agent must be installed on the server computer and can also
be installed on separate physical Agent computers. An Agent is also
installed by default when a Client is installed, but it is not required.
Instances
An instance is a licensed version of Unicenter AutoSys JM software running as
a server and as one or more Clients or Agents on one or more computers. An
instance uses its own Event Server, Application Server, and Scheduler and
operates independently of other instances. An instance is defined by the
instance ID, which is a capitalized three-letter identifier defined by the
AUTOSERV environment variable.
It is possible to install multiple instances. For example, you can have one
instance for production and another for development. Multiple instances can
run on the same computer using a single copy of the binaries, and can
schedule jobs on the same computers without interfering or affecting the other
instances.
28 User Guide
Events
Events
Unicenter AutoSys JM is completely event-driven; for the Scheduler to activate
a job, an event must occur on which the job depends. For example, a job can
be activated when a prerequisite job has completed running successfully or a
required file has been received.
Events can come from a number of sources, including:
Jobs changing states, such as starting, finishing successfully, and so on.
Internal verification Agents, such as detected errors.
Events sent with the sendevent command, from the Unicenter WCC GUI,
or from user applications.
As each event is processed, the Scheduler scans the database for jobs that are
dependent on that event. If the event satisfies another job's starting
conditions, that job is either started immediately or queued for the next
qualified and available computer. The completion of one job can cause another
job to start so that jobs progress in a controlled sequence.
Alarms
Alarms are special events that notify operators of situations requiring their
attention. Alarms are integral to the automated use of Unicenter AutoSys JM.
That is, you can schedule jobs 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 depend on the arrival of a file,
and the file may be long overdue. It is important that someone investigate the
situation, make a decision, and resolve the problem.
The following are some important aspects of alarms:
Alarms are informational only. Any action taken must be initiated by a

separate action event.
Alarms are system messages about a detected incident.
Alarms are sent through the system as events.
Alarms have special monitoring features to make sure they are noticed.
Introduction 29
Utilities
Utilities
Unicenter AutoSys JM uses its own specification language (JIL) and client
utilities to help you define, control, and report on jobs. The JIL language is
processed by the JIL Client executable, which reads and interprets the JIL
statements that you enter and then performs the appropriate actions.
Unicenter AutoSys JM also provides a set of essential client programs for
controlling and reporting on jobs. For example, the autorep command lets you
generate a variety of reports about job execution, and the sendevent
command lets you manually control job processing.
Additional utilities are provided to assist you in troubleshooting, running
monitors and reports, and starting and stopping Unicenter AutoSys JM and its
components. Unicenter AutoSys JM also provides a database maintenance
utility that runs daily by default.
Extending Functionality
Unicenter AutoSys JM provides easy integration with other enterprise
applications and Schedulers.
Unicenter AutoSys JM Connect

Unicenter AutoSys JM Connect enables the Scheduler to run jobs on
mainframe schedulers. It also creates dependencies between Unicenter
AutoSys JM jobs and jobs on the mainframe scheduler. The Scheduler uses
CA, Inc. Common Communications Interface (CAICCI), a communications
protocol that is part of CA common components, to communicate with
Unicenter AutoSys JM Connect.
Note: For more information about CAICCI, refer to the CA Common
Components documentation.
Unicenter AutoSys JM Adapters

Unicenter AutoSys JM provides the ability to interact with other enterprise
applications such as SAP through a special binary known as an adapter. The
application-specific adapters let you initiate, control, and report the status of
jobs related to an application using the sophisticated job scheduling
capabilities of Unicenter AutoSys JM. The adapter is a command which is run
by the job, so interaction with an adapter job is the same as with a normal
Unicenter AutoSys JM job.
30 User Guide
Unicenter Universal JM Agent

The Unicenter Universal Job Management Agent (UUJMA) appears in various
contexts. One such context is a UUJMA that can be run on distributed
platforms as a standalone job Agent that executes binaries and scripts in a
method similar to the Unicenter AutoSys JM Agent.
Additionally, all CA mainframe scheduling products can behave as UUJMA
Agents, providing an additional method for the Unicenter AutoSys JM
Scheduler to run jobs through those mainframe schedulers. However, unlike
Unicenter AutoSys JM Connect, UUJMA does not allow dependencies. In this
context, the job being run is a named job known to the Scheduler, and not a
command or script.
The Unicenter AutoSys JM Scheduler can appear as a UUJMA Agent to other
Schedulers in the enterprise. In this context, the job submitted to the UUJMA
interface is a job defined to Unicenter AutoSys JM and is not a command or
script.
As with Unicenter AutoSys JM Connect, the Scheduler uses CAICCI to
communicate with UUJMA Agents.
Introduction 31
The following illustration provides a high-level overview of UUJMA interactions:
More information:
Cross-Platform Scheduling Considerations (see page 355)
32 User Guide
Port Multiplexing (PMUX)

Port multiplexing (PMUX) increases security and the efficient use of the
physical ports available on any given host by restricting all Unicenter AutoSys
JM traffic to a single physical port, with one exception.
Note: CAICCI is not PMUX-enabled and uses its own physical ports.
All PMUX-enabled ports are considered virtual and traffic through those virtual
ports is restricted to a single physical port. Unicenter AutoSys JM
communicates across the enterprise through a PMUX port known as the
PmuxServerPort. The registered default PmuxServerPort value is 7163 and is
set at installation. Although it is not recommended, you can change the
PmuxServerPort to another value.
Like their physical counterparts, virtual ports can have only one process bound
to them. The bound process is generally considered a tcp-server. Any number
of remote or local Clients can connect to the tcp-server process bound to a
port.
To accommodate PMUX, there is a small demon broker process referred to as
the PMUX broker. On UNIX, the process name is csampmuxf. You do not
typically need to start this process because it starts automatically with the first
Unicenter AutoSys JM binary. However, if you want to enable other ports after
installation, you must configure those additional ports.
More Information:
Port Multiplexing (see page 389)
Introduction 33
SSL Encryption of Unicenter AutoSys JM Messages

A Unicenter AutoSys JM message is defined as any message sent between any
set of Unicenter AutoSys JM processes. There are three persistent server
processes:
event_demon
as_server
auto_remote (parent)
Binaries such as jil, sendevent, autorep, chase, and auto_remote (child) are
Client processes and communicate with one or more of the server processes.
This discussion applies to all the Unicenter AutoSys JM binaries, both the
persistent server processes and the non-persistent Client processes.
Note: For a complete list of Client processes, see the Reference Guide.
You can use SSL encryption for all messaging between any of these processes.
SSL encryption is turned off by default.
Important! If SSL encryption is turned on for any server process, it must be
turned on for all Client and server processes that communicate with it. Simply
put, processes on an SSL-enabled host cannot communicate with processes on
a host that is not SSL-enabled. All Unicenter AutoSys JM processes are subject
to the SSL setting of the host.
34 User Guide
About the Unicenter AutoSys JM Administrator Utility

The Unicenter AutoSys JM Administrator (the Administrator) is installed
with the Console Utilities so you can view and modify configuration parameters
for each instance you install. After you set them, these configuration
parameters are loaded into the Windows Registry.
On startup, Unicenter AutoSys JM reads this information to check which
databases to connect and how to react to certain error conditions. In
particular, the Scheduler bases much of its run-time behavior on the
parameters defined in the Administrator.
The Administrator has the following screens:
Unicenter AutoSys Instance
Lets you select the instance for which you want to view and modify
settings.
Unicenter AutoSys Agent
Lets you set the Agent's port number and the list of authorized Schedulers
(for remote authentication).
Unicenter AutoSys Event Server
Lets you specify Event Servers, either for Single Event Server or Dual
Event Server mode.
Unicenter AutoSys Scheduler
Lets you specify the Scheduler's behavior and the information necessary to
run a Shadow or Tie-breaker Scheduler.
Unicenter AutoSys Integration
Lets you specify information for Unicenter Notification, Unicenter Event
Management, and Unicenter Service Desk.
Unicenter AutoSys Notifications
Lets you specify user-defined alarm callbacks for certain types of system
alarms.
Unicenter AutoSys System
Lets you 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.
Unicenter AutoSys Security
Lets you set the Trusted Hosts and Trusted Users for remote
authentication.
Introduction 35
Unicenter AutoSys Services

Lets you view and change the status of the Agent, Scheduler and
Application Server 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 only have access to the
Unicenter AutoSys Instance, Security, and Services screens and actions.
Important! The Scheduler only reads the settings in the Unicenter AutoSys
JM Administrator on startup. Therefore, if you make a change to an
Administrator setting that you want to implement immediately, you must stop
the Scheduler using the sendevent -E STOP_DEMON command, and restart it
using the Unicenter AutoSys Services screen.
For information while using the Unicenter AutoSys JM Administrator, see the
Online Help. You can open the help system from the Unicenter AutoSys JM
Help icon in the program group, or 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.
Note: Many of the configuration parameters that you set on Windows

using the Unicenter AutoSys JM 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 guide provides both the Administrator field name and its UNIX
configuration file parameter equivalent. For more information about the
configuration file on UNIX platforms, see the User Guide.
Start the Administrator

To start the Administrator, select the Unicenter AutoSys Administrator
icon in the program group.
When you start the Unicenter AutoSys JM Administrator, the Unicenter
AutoSys Instance screen is displayed.
To navigate to the various Administrator screens
1.
Select a computer.
2.
Select an instance in the Unicenter AutoSys Instance screen and click OK.
The menu items and their corresponding toolbar buttons are enabled.
3.
36 User Guide
Use the menu items to access the Administrator screens.
Chapter 2: Security
Security in Unicenter AutoSys JM (see page 37)
System-Level Security (see page 38)
eTrust Embedded Identity and Access Management (see page 44)
Native Security (see page 65)
Security in Unicenter AutoSys JM

Unicenter AutoSys JM includes several key features that let you protect
sensitive assets and control who is authorized to perform certain secured
activities. This chapter helps you understand some of the decisions you must
make to properly secure your enterprise and explains the Unicenter AutoSys
JM features that help you do so.
Unicenter AutoSys JM provides the following levels of security:
System-level security
Delegation of administrative privileges
Asset-level security
Unicenter AutoSys JM can run in either external security mode through eTrust
Embedded Identity and Access Management (eTrust Embedded IAM) or native
security mode. Each security mode has different methods of delegating
administrative privileges to users and securing Unicenter AutoSys JM assets.
External security mode (eTrust Embedded IAM) is robust and provides the
most flexibility of the two modes. You can enable external security during
product installation, or an authorized user under the native model can enable
it later. When external security is enabled, eTrust Embedded IAM is used to
assign administrative rights to the user to define policies and to check whether
a given user can switch the security mode of the product back to native. While
external security is enabled, native security is not enforced.
Note: For more information about controlling the security setting with the
Unicenter AutoSys JM autosys_secure utility, see the Reference Guide.
More information:
eTrust Embedded Identity and Access Management (see page 44)
Restricting Unicenter AutoSys JM Through the File System (see page 43)
Security 37
System-Level Security
Unicenter AutoSys JM provides the following security features at the system
level:
Database field verification
Job definition encryption
Agent authentication
User and database administrator passwords
At the system level, Unicenter AutoSys JM provides measures to prevent

unauthorized access to job information and to prevent unauthorized jobs from
running on a machine. These security features are always available and are in
effect regardless of the active security mode.
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. When 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 modified
the job definition in the database, probably by using an SQL command. In this
case, the job is disabled and cannot be run.
To re-enable a disabled job, access the job definition using either the JIL
update_job subcommand or the Unicenter WCC GUI and resave it. You must
be an owner or the EDIT Superuser to access the definition.
Job Definition Encryption

To secure the Agent from unauthorized access, the Scheduler encrypts the
information in a job definition sent over the socket to the Agent. The Agent
then decrypts the job information and processes the job. If the Agent receives
any job information from the Scheduler that it does not recognize, it issues an
error message and the job is not processed.
38 User Guide
Agent Authentication
Unicenter AutoSys JM provides two additional methods to authenticate an
Agent before permitting it to run a job on a computer:
User authentication
Scheduler authentication
By default, both user authentication and Scheduler authentication are

disabled. The EDIT Superuser must use the autosys_secure command to
enable them.
User Authentication
User authentication is a remote authentication method that uses

Microsoft authorization technologies to verify that a user has permission to
start a job on a Client computer. It accomplishes this by obtaining the primary
domain controller and contacting it to validate that the requesting user is
registered in that environment. Use the autosys_secure command to activate
this type of remote authentication.
User authentication is a remote authentication method that uses UNIX

ruserok() authentication to verify that a user has permission to start a job on
a Client computer. It accomplishes this by telling the Client's Agent to make
the ruserok() UNIX system call to check the Client computer's /etc/hosts.equiv
file 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 to rshd or rlogind. Use the autosys_secure command to activate
this type of remote authentication.
The hosts.equiv or .rhosts file entries must match the job owner and machine
name field exactly. For example, if the owner is parrot@jungle, the
hosts.equiv or .rhosts file must contain jungle. Similarly, if the owner is
parrot@jungle.vine.com, the hosts.equiv or .rhosts file must contain
jungle.vine.com. If the values do not match, jobs fail to run on that computer
when ruserok() remote authentication is in use.
Note: For more information, see the Reference Guide.
Security 39
How Scheduler Authentication Works

When Scheduler authentication is enabled, the Agent verifies that it has
permission to process requests from the requesting Scheduler before starting
each job.
On Windows, Scheduler Authentication is done by reading the

Authorized Scheduler Host Names registry entry on the computer on which the
Agent is running.
Before enabling Scheduler authentication, you must set up and properly
configure the Authorized Scheduler Host Names registry entry on every
Windows Client computer that uses this authentication method. The
Authorized Scheduler Host Names registry entry is configured from the
Unicenter AutoSys Agent screen of the Unicenter AutoSys JM Administrator
(autosysadmin).
On UNIX, Scheduler Authentication is done by reading the

/etc/.autostuff file on the computer on which the Agent is running.
Before enabling Scheduler authentication, you must set up and properly
configure the /etc/.autostuff file on every Client computer that participates in
this authentication method.
The Scheduler checks whether the following starting conditions are satisfied
before running a job on an Agent computer:
40 User Guide
Has the job definition been modified? If so, the job definition is invalid,
and the job does not run.
Can the Scheduler connect to the Agent computer as defined in the DES
encrypted job definition?
Does the user defined as the job owner (user@machine) have a logon
account on the Agent computer?
If user authentication is enabled:
Is the user a trusted user as verified by the primary domain

controller machine?
Is the user a trusted user as defined in the /etc/hosts.equiv and

$HOME/.rhosts files?
If Scheduler authentication is enabled, does the requesting Scheduler have

permission to run jobs on this Agent computer?
Note: The EDIT Superuser can use the autosys_secure utility to enable
remote authentication.
The following illustration shows the permissions and security checks that occur
before a job is allowed to start:
Note: In the illustration, an asterisk (for example, Yes*) indicates checks that
are made only if the specific method of remote authentication is enabled.
Security 41
User and Database Administrator Passwords

When you install Unicenter AutoSys JM and configure the database, a database
user called autosys is added and a database password is created. The autosys
user is granted rights to the Unicenter AutoSys JM objects and can make
changes to specific information in the database. To enhance system security,
we recommend that you use the appropriate database-specific utilities to
change the autosys user password.
You must supply the autosys and sa (system administrator) user IDs and
passwords to use specific utilities. For example, when using the ISQL utility to
query the database, you must know both the autosys user password and the
sa password.
Note: For information about changing the autosys user password, see the
Reference Guide.
42 User Guide
Restricting Unicenter AutoSys JM Through the File System

Another way to prevent unauthorized use of Unicenter AutoSys JM is to restrict
usage at the file system level.
First, you must make sure that only authorized users can change permissions
on the files and directories in the directory structure.
Then, check the level of security you must use. For example:
Only authorized users can use Unicenter AutoSys JM.
Any user can view jobs and reports about jobs (for example, by 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, make sure
that only those users have execute permissions for 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, make sure that only the authorized users
have execute permission for the following files in the $AUTOSYS/bin directory.
This also prevents unauthorized users from making changes to the
configuration.
autocal_asc
autocal
archive_events
autotimezone
clean_files
DBMaint
dbspace
dbstatistics
jil
sendevent
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 for the files. Read permission is necessary to source the
environment files.
Security 43
eTrust Embedded Identity and Access Management

Unicenter AutoSys JM running under external security provides comprehensive
protection of assets such as jobs, global variables, and calendars, and control
of critical tasks by authorized users. This level of security is made possible by
integration with eTrust IAM. eTrust IAM provides a central location to manage
your user base, create roles for your enterprise, and assign roles to users. In
addition, eTrust IAM is also used to maintain security policies that govern what
assets can be accessed by which users.
Security policies are enforced by the Application Server, which obtains policy
updates from the eTrust IAM back-end server. Because the Scheduler and
Agent do not enforce security, policy changes do not affect assets entered in
the database. For example if the security administrator withdraws a users
permission to create jobs, Unicenter AutoSys JM continues to run jobs created
by the user before the change.
Delegation of Administrative Privileges

During installation, a repository is created in the eTrust IAM back-end server
for the Unicenter AutoSys JM instance for policies visible to Unicenter AutoSys
JM. Only users with access rights to the Unicenter AutoSys JM instance can
connect to the repository through the eTrust IAM web interface and add or
remove policies.
Only an authorized administrator can assign access rights to the Unicenter
AutoSys JM application to a user. This can be done in one of the following
ways:
Add an eTrust IAM administrative scoping policy.
Make the user a member of the Unicenter AutoSys JM Admin group.
Note: For more information about using the eTrust IAM web interface and
creating administrative scoping policies, see the eTrust IAM documentation.
44 User Guide
AS_EEM_AUTHUSER_MODE Environment Variable

The AS_EEM_AUTHUSER_MODE environment variable enables Unicenter
AutoSys JM to distinguish a local user from a domain or remote user when
evaluating eTrust IAM policies.
To enable Unicenter AutoSys JM to distinguish a local user from a domain or
remote user, you must set the AS_EEM_AUTHUSER_MODE environment
variable on the Application Server as follows:
AS_EEM_AUTHUSER_MODE=legal_mode
legal_mode
Specifies the legal mode that Unicenter AutoSys JM uses to distinguish a
local user from a domain or remote user when evaluating eTrust IAM
policies. You can set the legal mode to one of the following:
OFFLegacy behavior. This is the default.
STRICTCauses the security subsystem to automatically deny access

to all non-local users.
QUALIFYCauses the security subsystem to treat all non-local users

as local users originating from the host that is sending the request.
TRUSTCauses the security subsystem to treat all non-local users as

valid Active Directory users.
Notes:
You can use the following qualifier with the STRICT, QUALIFY, and TRUST
legal modes:
AS_EEM_AUTHUSER_MODE=legal_mode,AD(DOMAIN1,DOMAIN2)
AD(DOMAIN1,DOMAIN2)
Causes the security subsystem to treat the DOMAIN or user account as
a valid user, if the DOMAIN is in the comma-delimited list of domain
names.
For example, if you want the security subsystem to treat all users of
DOMAIN1 and DOMAIN2 as valid users and all others as invalid users,
you must set the AS_EEM_AUTHUSER_MODE environment variable as
follows:
AS_EEM_AUTHUSER_MODE=TRUST,AD(DOMAIN1,DOMAIN2)
When a request is sent from the Unicenter AutoSys JM r11, r11 SP1, r11
SP2, or r11 SP3 client (irrespective of the legal mode set on the
application server), all users are treated as local users originating from the
host that is sending the request.
Security 45
Policy Synchronization
eTrust IAM r8.3 provides the following two methods for synchronizing policies
between the eTrust IAM back-end server and the eTrust IAM client:
Cache updateThe eTrust IAM client is configured to poll the eTrust IAM
back-end server at regular intervals and automatically download all the
policies that have been updated since the last interval.
Synchronize pushThe eTrust IAM client is configured to poll the eTrust

IAM back-end server at regular intervals and download updated policies
only if requested by the end user. The synchronize push feature is disabled
by default.
Unicenter AutoSys JM relies on the cache update feature to update the local
eTrust IAM-enabled application's policy cache.
You can enable the synchronize push feature to reduce the overhead incurred
on the network by frequent download of updated policies from the eTrust IAM
back-end server. Instead of requesting for and downloading the changed
policy tree at a regular interval, you can configure the eTrust IAM client to
download all policy updates on the next synchronize push interval after a
synchronize push request has been issued on the eTrust IAM back-end server.
You can enable the synchronize push feature by selecting a large cache update
value and configuring a modest synchronize push interval. Once the
synchronize push feature has been enabled, an additional commit step must
be performed on the eTrust IAM backend after all policies updates have been
saved, before the eTrust IAM clients can download the policy updates.
46 User Guide
Modify the UnicenterAutoSysJM Application Instance Configuration Values

The UnicenterAutoSysJM application instance is created on the eTrust IAM
back-end server and configured with the following default values:
Synchronize Poll Interval Time

Default: 0 seconds
When the eTrust IAM client connects to the UnicenterAutoSysJM
application instance for the first time, it acquires this value as the interval
to check for synchronization poll requests. The eTrust IAM client polls the
eTrust IAM back-end server to check for a synchronization push request. If
the eTrust IAM client detects a request, it proceeds and downloads the
policy tree. If, however, there are no pending synchronization push
requests on the eTrust IAM back-end server, the eTrust IAM client does
nothing. A zero value for the Synchronize Poll Interval Time disables this
feature.
Cache Update Interval

Default: 30 seconds
This value causes eTrust IAM clients connected to the UnicenterAutoSysJM
application instance on the eTrust IAM back-end server to check for policy
updates every 30 seconds. If no policies have been updated, the eTrust
IAM client does nothing.
The synchronize poll interval time and the cache update interval
configuration values can be modified from the eTrust IAM web interface.
To modify the configuration values

1.
Log on to the UnicenterAutoSysJM application instance as a user with

administrative privileges.
The eTrust IAM web interface appears.
2.
Select the Configure tab.

The Applications, Folders, Session, and EEM Server options appear.
3.
Click Applications.
The Applications pane appears.
4.
Click UnicenterAutoSysJM.
The Application Instance pane appears.
5.
Enter the Cache Update Time and the Synchronize Poll Interval, and click
Save.
The new configuration values are applied.
Security 47
Enable Synchronize Push

After you have completed and saved changes to one or more policies using the
eTrust IAM web interface, you must enable the synchronize push feature. If
you do not perform this step, the eTrust IAM clients will not download the
policy changes, even though you successfully established a connection to the
UnicenterAutoSysJM application instance on the eTrust IAM back-end server.
To enable the synchronize push feature after saving your policy
changes
1.
Log on to the UnicenterAutoSysJM application instance as a user with

administrative privileges.
The eTrust IAM web interface appears.
2.
Select the Configure tab.

The Applications, Folders, Session, and EEM Server options appear.
3.
Click Session.
The Session pane appears.
4.
Click Synchronize Push.

The Synchronize Push pane appears.
5.
Click Synchronize.
The synchronize push feature is enabled.
After the synchronization push feature is enabled, the eTrust IAM client
downloads the latest policy tree and its local policy cache contains the latest
policy changes.
You can repeat these steps to let the eTrust IAM-enabled client-side
application download the entire policy tree from the eTrust IAM back-end
server.
Asset-Level Security
You can choose to enable external security during product installation, or an
EXEC Superuser under the native model can activate it later. After you
activate eTrust IAM security, the job-level security and Superuser privileges
supported in native mode are no longer active. After you enable external
security, policies in the as-control class govern who can disable eTrust IAM
security. Use the autosys_secure command to activate or disable security.
48 User Guide
Resource Classes
A Unicenter AutoSys JM instance is the repository for policies that reside on
the eTrust IAM server and that are visible to Unicenter AutoSys JM. Policies in
the instance are classified into resource classes that control access to jobs,
calendars, cycles, machines, global variables, the owner field of a job, and so
on, and a specific class function to prevent unauthorized users from starting or
shutting down the Scheduler or disabling eTrust IAM security. A Unicenter
AutoSys JM instance can contain the following resource classes:
as-appl
as-calendar
as-cycle
as-control
as-group
as-gvar
as-job
as-jobtype
as-list
as-machine
as-owner
Before performing an action on a specified asset, Unicenter AutoSys JM issues

a security call to the appropriate class in the repository. For example, for job
assets, Unicenter AutoSys JM queries policies in the as-job class; for global
variable assets, it queries policies in the as-gvar class.
The resource name in an eTrust IAM policy consists of the name of the
Unicenter AutoSys JM instance, a period, and the name of the corresponding
asset. For example, when a user tries to update the payroll job in the ACE
instance, Unicenter AutoSys JM queries eTrust IAM as follows:
as-job ACE.payroll
Security 49
The as-owner resource class is an exception to this rule, because it does not
require the name of the instance. For example, when a user tries to update
the job owner field of a job to parrot@jungle in the ACE instance, Unicenter
AutoSys JM queries eTrust IAM as follows:
as-owner parrot@jungle
Note: The security administrator must use the instance.object convention

when creating policies except as cited for the as-owner class. You can use
wildcards (for example,*) to create policies that apply to multiple assets
across different instances. Also, eTrust IAM supports the use of regular
expressions to define an asset in a policy. For more information about
resource classes, see the eTrust IAM documentation.
Best Match Policy Evaluation

When deciding whether to grant access to an asset, eTrust IAM only considers
policies whose resource names most closely match the requested asset name.
The policy may contain the most matching characters and the fewest wildcard
characters compared to the asset name given to it by Unicenter AutoSys JM.
To evaluate whether a user has access to an asset, only policies that eTrust
IAM has collected using the best match criteria are considered. Consequently,
the best match policy evaluation used by eTrust IAM lets you benefit from a
hierarchical asset naming convention.
Example: Best Match Policy
You can select a job naming convention in which all payroll jobs in the ACE
instance are prefixed with the payroll identifier. Using such a job naming
convention lets you create a generic policy that can govern all payroll jobs
(where the resource name in the policy is ACE.payroll*). At the same time,
you can fine-tune security for a specific job by creating a policy for a job called
payroll_employeeID5702 (where the resource name in the policy is
ACE.payroll_employeeID5702).
In this example, with best match policy evaluation, eTrust IAM only considers
the policy containing the resource name ACE.payroll_employeeID5702 when
deciding whether to grant access to the payroll_employeeID5702 job. Even
though there may be other matching policies (such as the policy with a
resource name of payroll*), eTrust IAM uses the best match policy evaluation
to find the set of policies with resource names that most closely match the
requested asset name.
50 User Guide
Access Modes
Unicenter AutoSys JM uses one or more of the following access modes on each
of the resource classes:
READ
CREATE
DELETE
EXECUTE
WRITE
The use of these access modes is explained in more detail in the description of
each class.
as-appl Class
The as-appl class controls access to the job application field in a job definition
and controls which jobs can be included in an application job set.
EXECUTE
Controls whether a job definition can use the application job set name in
its application field.
In EXECUTE mode, this class accepts the following binary, which has the
indicated security checkpoint:
jil
insert_job, update_job (using the application attribute).
Security 51
as-calendar Class
The as-calendar class controls access to calendar objects.
READ
Controls whether users can view calendars or their contents.
In READ mode, this class accepts the following binary, which has the
autocal_asc
When as-list\AUTOCAL denied, LIST CALENDARS
LIST CALENDAR DATES
CREATE
Controls whether users can create a calendar.
In CREATE mode, this class accepts the following binary, which has the
autocal_asc
CREATE CALENDAR
DELETE
Controls whether users can delete a calendar.
In DELETE mode, this class accepts the following binary, which has the
autocal_asc
DELETE CALENDAR
EXECUTE
Controls whether users can specify a calendar to run or to exclude in a
job.
jil
run_calendar, exclude_calendar
52 User Guide
WRITE
Controls whether users can update existing calendar objects.
In WRITE mode, the class accepts the following binary, which has the
autocal_asc
MODIFY CALENDAR
Note: Assets in this class can only contain the following characters: a-z, A-Z,
0-9, period (.), underscore (_), and hyphen (-). Assets in this class cannot
contain spaces.
as-control Class
The as-control class controls access to critical Unicenter AutoSys JM services.
EXECUTE
Controls critical resources through the sendevent -e STOP_DEMON and
autosys_secure binaries.
STOP_DEMON
Controls who can use the sendevent binary to stop the Scheduler.
SECADM
Controls who can use the autosys_secure binary to disable external
security.
EPLOG
Controls whether users can retrieve Scheduler log files from the
Application Server.
Security 53
as-cycle Class
The as-cycle class controls access to cycle assets. Cycles are used in the
definition of advanced rules for generating calendar dates.
READ
Controls whether users can view cycles or their contents.
autocal_asc
When as-list\AUTOCAL denied, LIST CYCLE
LIST CYCLE DATES
CREATE
Controls whether users can create a cycle.
autocal_asc
CREATE CYCLE
DELETE
Controls whether users can delete a cycle.
autocal_asc
DELETE CYCLE
WRITE
Controls whether users can update existing cycles.
In WRITE mode, this class accepts the following binary, which has the
autocal_asc
MODIFY CYCLES
Note: Assets in this class can only contain the following characters: a-z, A-Z,
0-9, period (.), underscore (_), and hyphen (-). Assets in this class cannot
contain spaces.
54 User Guide
as-group Class
The as-group class controls access to the job group field in a job definition and
controls which jobs can be included in a group job set.
EXECUTE
Controls whether a job definition can use the group job set name in its
group field.
indicated security checkpoints:
jil
insert_job, update_job (using the group attribute).
as-gvar Class
The as-gvar class controls access to global variable assets. Because global
variable assets are only controlled through the sendevent binary, the access
modes are verified during sendevent execution.
READ
Controls whether users can view specific global variable objects.
autorep
-g variable
autostatus
-g variable
sendevent
CREATE
Controls whether users can create specific global variable objects.
sendevent
-g (new variable)
DELETE
Controls whether users can delete specific global variable objects.
sendevent
-g variable=DELETE
Security 55
EXECUTE
Controls whether users can use sendevent against all global variable
objects simultaneously.
sendevent
-e SET_GLOBAL, all-g options
WRITE
Controls whether users can update specific existing global variable objects.
sendevent
-g (existing variable)
as-job Class
The as-job class controls access to job assets.
READ
Controls whether users can view jobs or their contents.
In READ mode, this class accepts the following binaries, which has the
autorep
When as-list\AUTOREP denied, -J job, -q
autostatad
When as-list\AUTOSTAT denied, -J job
autostatus
-J job
job_depends
When as-list\JOBDEP denied, -J job
monbro
When as-list\MONBRO denied
56 User Guide
CREATE
Controls whether users can create a job.
jil
insert_job
DELETE
Controls whether users can delete jobs directly or with sendevent.
jil
delete_job
sendevent
-e DELETEJOB
EXECUTE
Controls whether a user can issue a sendevent for the job.
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 -J job
Security 57
WRITE
Controls whether users can update an existing job.
jil
update_job
sendevent
-e CHANGE_PRIORITY
as-joblog Class
The as-joblog class controls access to job log files, including files that contain
normal or error outputs from a job run (as defined by the std_out_file and
std_err_file job attributes). The as-joblog class also includes log files that
contain output from the job Agent and job Agent profile files.
READ
Controls whether users can retrieve job log files from the Application
Server.
Note: No spaces are allowed between the >> characters and the full path or
file name in the std_out_file or std_err_file fields in a job definition.
58 User Guide
as-jobtype Class
The as-jobtype class controls access to job_type assets.
READ
Controls whether users can view job types or their contents.
In READ mode, this class accepts the following binaries, which has the
autorep
When as-list\AUTOREP denied, -Y job_type
job_depends
When as-list\JOBDEP denied, -J job
CREATE
Controls whether users can create a job type.
jil
insert_job_type
DELETE
Controls whether users can delete job types directly.
jil
delete_job_type
Note: When installed, the as_jobtype class is defined with the DELETE
action. Its default policy is defined without the DELETE action. This
prevents a user from inadvertently deleting user-defined job types.
The default policy can be updated to include the DELETE action, or a
new policy can be defined that grants access to delete user-defined job
types.
EXECUTE
Controls whether users can specify a job type in a job.
jil
job_type (with a value other than b, c, or f)
Security 59
WRITE
Controls whether users can update an existing job type.
jil
update_job_type
as-list Class
The as-list class controls whether programs are directed to bypass individual
security for read-only operation of a potentially large list of assets where the
information displayed does not constitute a security violation (for example, in
autorep).
Note: By using the default of this class, Unicenter AutoSys JM does not incur
the overhead associated with issuing a security call for each individual line
item displayed.
READ
Controls security bypass through the following:
AUTOREP
Controls read access for the autorep binary. This value is ignored for
autorep reports created with the q option. The binary has the
following security checkpoints for READ mode:
-m ALL, -J ALL, -J box, -G ALL
AUTOSTAT
Controls read access in the autostatad binary. The binary has the
following security checkpoint for READ mode:
-J %
MONBRO
Controls read access to the monbro binary. The binary has the
following security checkpoint for READ mode:
Event related to secured jobs
JOBDEP
Controls read access to the job_depends binary. The binary has the
following security checkpoints for READ mode:
-c J ALL, -c J %, -t %, -d %, -t ALL, -d ALL, -t box, -d box
60 User Guide
as-machine Class
The as-machine class controls access to machine assets, including whether a
user can use a machine object in a job definition.
READ
Controls whether users can view machines or their contents.
autorep
When as-list\AUTOREP denied, -m machine
CREATE
Controls whether users can create machine definitions.
jil
insert_machine
DELETE
Controls whether users can delete machine definitions.
jil
delete_machine
Security 61
EXECUTE
Controls whether users can specify a machine in a job definition.
jil
machine
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 -J job
as-owner Class
The as-owner class controls access to the job owner field in the job and
controls which owners can be specified in a job definition. For example, the
user ID of the job creator is used by default as the job owner when a job is
created. However, when a user other than the job creator is to be used as the
owner, security verifies whether the current user can use the specified owner
ID.
EXECUTE
Controls whether users can use specific user IDs.
jil
owner
62 User Guide
How an Application is Security-Enabled

The Application Server enforces security policies. However, because eTrust
IAM policies can have calendar dates and times associated with them, the time
of authorization is important. To properly authorize a request from a Unicenter
AutoSys JM Client, the Application Server must know what the time is relative
to the Client. The logical flow when a Client makes a request to the Application
Server is as follows:
The Client calculates its offset (in seconds) from the GMT time zone and
sends it to the Application Server with the request.
When it receives the request, the Application Server checks its offset (in
seconds) from the GMT time zone.
The Application Server subtracts the Clients offset from its own to obtain
the time zone difference in seconds from the Client.
The Application Server applies the difference to the current time and uses
this as the time in its authorization check. This time represents the actual
time relative to the Clients time zone.
Create an Asset
To create an asset, you must validate that the user has the required
authorization. For the job assets, do the following:
Validate that the user can specify a different user in the owner job
attribute. Execute an authorization check against the user by passing in
the as-owner resource class name, the job owner, and the execute access
level.
Validate that the user can run the job on the computer that is specified in
the machine job attribute. Execute an authorization check against the user
by passing in the as-machine resource class name, the Unicenter AutoSys
JM instance-specific machine name, and the execute access level.
Validate that the user can use the calendar specified in the run_calendar
job attribute. Execute an authorization check against the user by passing
in the as-calendar resource class name, the Unicenter AutoSys JM
instance-specific calendar name, and the execute access level.
Note: You must repeat this step if a calendar name is also specified in the
exclude_calendar job attribute.
To create an asset, execute an authorization check against the user by passing

the security resource class name and the Unicenter AutoSys JM instancespecific asset name, and create the access level.
Security 63
Update an Asset
To update an asset, you must validate that the user has the required
authorization. For the job assets, do the following:
Validate that the user can specify a different user in the owner job
attribute. Execute an authorization check against the user passing in the
as-owner resource class name, the job owner, and the execute access
level.
Validate that the user can run the job on the computer specified in the
machine job attribute. Execute an authorization check against the user
passing in the Unicenter AutoSys JM instance-specific as-machine resource
class name, the machine name, and the execute access level.
Validate that the user can use the calendar specified in the run_calendar
job attribute. Execute an authorization check against the user passing in
the as-calendar resource class name, the Unicenter AutoSys JM instancespecific calendar name, and the execute access level.
Note: You must repeat this step if a calendar name is also specified in the
exclude_calendar job attribute.
To update an asset, execute an authorization check against the user passing in

the security resource class name, the Unicenter AutoSys JM instance-specific
asset name, and the write access level.
Delete an Asset
To delete an asset, an authorization check is executed against the user
passing in the security resource class name, the Unicenter AutoSys JM
instance-specific asset name, and the delete access level.
64 User Guide
Native Security
List a Set of Assets

To list a set of assets using the reporting tools, execute an authorization check
against the user by passing the as-list class name, the Unicenter AutoSys JM
instance-specific reporting tool names, like AUTOCAL, and AUTOREP, and the
read access level.
You can validate whether the user can view all the assets in a list without
issuing individual asset checks. Following are a set of conditions that are
applicable to enable the users to view the list of assets:
If as-list read access is granted, all assets are displayed with no further
authorization checks.
If as-list read access is denied, validate that the user can view an
individual asset in a list by executing an authorization check against the
user by passing in the security resource class name, the Unicenter
AutoSys JM instance-specific asset name, and the read access level. Only
the assets that are granted read access will be displayed. Assets that are
denied read access are not displayed. If every asset in the list is denied
read access, nothing will be displayed.
For job objects, an as-list read access authorization check against the user
is executed in the Unicenter AutoSys JM instance, where you want to view
the contents of a box job, based on the following:
If as-list read access is granted, information about the box job and all
jobs in it are displayed.
If as-job read access to the box job is denied, neither the box job nor
the jobs in it are displayed.
If a box is granted as-job read access, but one or more jobs in the box
is denied as-job read access, only the box job and jobs in the box
granted as-job read access are displayed. Jobs in the box that are
denied as-job read access are not displayed.
Native Security
Native security is the default security model under which Unicenter AutoSys JM
runs if the option to run under eTrust IAM was not selected during installation
or if the eTrust IAM policy permits a user to disable external security. Although
it provides a level of security for certain assets and activities, the scope of
protection is limited when compared to that of external security.
Security 65
Native Security
Security Control
External security is controlled by a setting in the Unicenter AutoSys JM
database. You can use the autosys_secure binary to turn external security on
or off.
To turn external security on
1.
Invoke autosys_secure binary.

The following menu appears:
Please select from the following options:
[1] Activate EIAM instance security.
[2] Manage EDIT/EXEC superusers.
[3] Change AutoSys database password.
[4] Change AutoSys remote authentication method.
[5] Manage AutoSys User@Host users.
[6] Get Encrypted Password.
[0] Exit AutoSys Security Utility.
>1
Are you sure you wish to activate EIAM security? [1(yes)/0(no)]: 1
2.
Enter the EIAM Backend Server name (or press the enter key to cancel).
The external security turned on. The following message appears:
CAUAJM_I_60201 EIAM instance security successfully set.
To turn external security off

1.
Invoke autosys_secure binary.

The following menu appears:
[1] Revert to NATIVE instance security.
[2] Regenerate EIAM certificate.
>1
Are you sure you wish to disable EIAM security? [1(yes)/0(no)]: 1
2.
Press the enter key.

The external security turned off. The following message appears:
CAUAJM_I_60202 NATIVE instance security successfully set.
66 User Guide
Native Security
Superusers
Under the native security model, users with administrative privileges are
known as Superusers. Unicenter AutoSys JM lets you define two levels of
Superusers: EDIT and EXEC. You can use the autosys_secure command to
define these Superusers.
EDIT Superuser
Only the EDIT Superuser has permission to do the following:
Edit or delete any job regardless of its owner or its permissions.
Change the owner attribute of a job.
Use the autosys_secure command to add or change Windows user IDs and
passwords.
Use the autosys_secure command to change the database password or the

remote authentication method.
The EDIT Superuser can override user authentication (if enabled) on a

job-by-job basis by changing the owner of the job from the user@machine
form to the user form. User authentication of the job at run time is not
performed on the Client computer.
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.
The EDIT Superuser must enter valid operating system user IDs and
passwords in the database. These user IDs and passwords are required to log
on to and run jobs on Client computers. When an Agent runs a job on a
computer, it logs on as the user defined in the owner attribute for the job. To
do this, the Scheduler 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 Agent.
Any user who knows an existing user ID and password can change that
password or delete that user and password.
Security 67
Native Security
EXEC Superuser
Only the EXEC Superuser has permission to do the following:
Use the sendevent command or the Unicenter WCC GUI to issue

commands that affect the running or the state of any job.
Enable eTrust IAM.
Use the following command to stop the Scheduler:

sendevent -E STOP_DEMON
Note: EXEC Superuser privileges are typically granted to the night operator.
Asset-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 run a job.
However, the owner can extend permissions to other users and other
computers.
68 User Guide
Native Security
Job Ownership
By default, the owner of a job is the user who defines that job on a particular
computer.
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 computer where the job command is to
run. The job owner must also have permission to access any device, resource,
and so on 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 for
the job, and the umask execute permission is used as the default Execute
permission for the job.
If a job is run on a Windows Client computer, the EDIT Superuser must

have entered the valid Windows user ID and password for the owner in the
database.
More information:
EDIT Superuser (see page 67)
Security 69
Native Security
User Types
Unicenter AutoSys JM uses the following three types of users for any job:
Owner
Creates the job.
Group
Resides in the same primary group as the owner.
World
Specifies all users.
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 let other users edit and execute the job by setting the
permissions in the job definition.
70 User Guide
Native Security
Permission Types
By default, only the owner has Edit and Execute permissions for a job, and all
Edit and Execute permissions are valid only on the computer on which the job
was defined. However, the owner can grant different types of permissions
when defining a job.
Unicenter AutoSys JM associates different types of permissions with each job.
Every job has the following permission types:
Edit
Lets users edit, override, or delete a job definition.
Execute
Lets users use the sendevent command or the Unicenter WCC GUI to send
an execute event that affects the running of a job.
Machine
Lets users logged on to a computer other than the one on which a job was
created edit or execute the job.
Note: For a job to run on a computer other than the one on which it was
defined, the owner of that job must have an account on that computer.
More information:
Security on Events Sent by Users (see page 73)
Security 71
Native Security
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 attribute for a job.
However, the owner can use JIL to set the permission attribute in the job
definition to grant other users Edit and Execute permissions for a job.
The following table shows the permissions that you can set using JIL:
JIL
Description
gx
Execute the job if logged onto the computer where the job was
created (the computer specified in the owner attribute; that is,
user@machine). This applies to users assigned to the job owner's
primary group.
ge
Edit the job if logged onto the computer where the job was
user@machine). This applies to users assigned to the job owner's
primary group.
mx
Execute the job (otherwise, the user must be logged onto the
computer specified in the owner attribute; that is,
user@machine). This applies to users, regardless of the computer
logged onto.
me
Edit the job (otherwise, the user must be logged onto the
computer specified in the owner attribute; that is,
user@machine). This applies to users, regardless of the computer
logged onto.
wx
Execute the job if logged onto the computer where the job was
user@machine). This applies to any user.
we
Edit the job if logged onto the computer where the job was
user@machine). This applies to any user.
Note: A job and the command it runs always runs as the user specified in the
owner attribute of the job definition. Execute permissions verify who can
execute events against the job, but not how the job runs. Even if World
Execute permissions are granted, the job still runs as the user, who is defined
in the owner attributes.
72 User Guide
Native Security
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 computer, you can set Group
permissions, but they are ignored. Group permissions are used if a job is
edited or executed on a UNIX computer.
When editing a job from a Windows computer, 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 computer, 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 on Events Sent by Users

If you have the appropriate permissions, you can use the sendevent command
or the Send Event dialog to send the following Execute events that affect the
running of a job:
CHANGE_PRIORITY
CHANGE_STATUS
DELETEJOB
FORCE_STARTJOB
JOB_OFF_HOLD
JOB_OFF_ICE
JOB_ON_HOLD
JOB_ON_ICE
KILLJOB
SEND_SIGNAL
STARTJOB
Security 73
Native Security
How a User Can Start a Job by Sending an Event

Unicenter AutoSys JM verifies the following when a user sends an event to
start a job:
Has the job definition been modified? If so, the job definition is invalid,
and the job does not run.
Does the user match the owner as indicated in the job definition?
Is the user the EXEC Superuser as defined with autosys_secure?
Does the user have job execute permissions as indicated in the job
definition?
Is there a machine name in the owner value of the job definition? The
EDIT Superuser can remove this portion of the owner value.
Does the machine portion of the user logon credentials match the machine
portion of the job owner definition?
Does the job have machine permission as indicated by the job definition?
When you start a job by sending an event, the job permissions are verified as
shown in the following illustration:
74 User Guide
Chapter 3: Job Definitions

Job Attributes (see page 75)
Create a Job Definition Using JIL (see page 76)
Create a Job Definition Using the Unicenter WCC GUI (see page 76)
JIL Subcommands (see page 77)
Job Attributes (see page 78)
Date and Time Attributes and Time Changes (see page 80)
Job Attributes
The specification of a job's attributes and behavior is called a job definition.
You can use JIL or the Unicenter WCC GUI to create job definitions. Regardless
of how you create a job definition, the specified attributes are the same and
the job definition is always stored in the database.
Before modifying or deleting an existing job, make sure that the job is not
running. To help ensure that you do not lose job definitions in the event of a
system failure, you should back up your job definitions periodically.
Job Definitions 75
Create a Job Definition Using JIL
Create a Job Definition Using JIL

You must create a job definition for each Unicenter AutoSys JM job. Each job
definition must include the job name, attributes that describe its intended
behavior, and the values of those attributes.
To create a job definition using JIL
1.
Enter the jil command at a command prompt.

The JIL command prompt appears.
2.
Enter the insert_job subcommand followed by the appropriate

attribute:value statements that specify an action to perform at the JIL
command prompt, where the jil commands resemble the following:
insert_job: job_name
attribute:value
...
job_name
Defines a unique name for the job.
attribute
Specifies the name of a valid JIL attribute.
value
Defines the setting to apply to the attribute.
The specified attributes and values are set for the indicated job.
Create a Job Definition Using the Unicenter WCC GUI

For information about using the Unicenter WCC GUI to work with job
definitions, see the Unicenter Workload Control Center Job Editor Help.
76 User Guide
JIL Subcommands
JIL Subcommands
The following table lists the JIL subcommands used to add, edit, and delete
jobs and machines in the database, notes whether the command is required,
and provides a brief description of the command.
Subcommands
Required?
Command Use
insert_job
Yes
Inserts a new job in the database.
update_job
No
Edits an existing job in the database.
override_job
No
Defines a one-time override for an

existing job definition. This override
affects the job for the next run only.
delete_job
No
Deletes a job from the database.
delete_box
No
Deletes an existing box job and all of

the jobs it contains.
insert_machine
Yes
Inserts a new machine definition in

the database. A machine must be
defined before it can be used in a job
definition.
update_machine
No
Updates an existing machine in the

database.
delete_machine
No
Deletes an existing machine from the

database.
Job Definitions 77
Job Attributes
Job Attributes
The following table lists job attributes, notes whether they are required for a
valid job definition, and summarizes the job types for which each attribute is
valid.
Attribute
Required?
Job Types
alarm_if_fail
No
Box, Command, File Watcher
application
No
auto_delete
No
auto_hold
No
(When the job is in a box)

avg_runtime
No
box_failure
No
Box
box_name
No
box_success
No
Box
box_terminator
No

78 User Guide
chk_files
No
Command, File Watcher
command
Yes
Command
condition
No
date_conditions
No
days_of_week
No
delete_box
No
Box
delete_job
No
description
No
exclude_calendar
No
group
No
heartbeat_interval
No
Command
insert_job
Yes
job_load
No
Command
job_name
Yes
Job Attributes
Attribute
Required?
Job Types
job_terminator
No

job_type
Yes
machine
Yes
max_exit_success
No
Command
max_run_alarm
No
min_run_alarm
No
n_retrys
No
notification_id
No
notification_msg
No
override_job
No
owner
Yes
permission
No
priority
No
Box, Command
profile
No
run_calendar
No
run_window
No
send_notification
No
service_desk
No
start_mins
No
start_times
No
std_err_file
No
Command
std_in_file
No
Command
std_out_file
No
Command
svcdesk_attr
No
svcdesk_desc
No
svcdesk_imp
No
svcdesk_sev
No
term_run_time
No
timezone
No
Job Definitions 79
Date and Time Attributes and Time Changes
Attribute
Required?
Job Types
update_job
No
watch_file
Yes
File Watcher
watch_file_min_size
No
File Watcher
watch_interval
No
File Watcher

Your operating system might automatically change the system clock to reflect
the switch to either standard time (ST) or daylight time (DT), and the
scheduling of time-dependent Unicenter AutoSys JM jobs might shift to adjust
for the time change. Jobs that are not time-dependent run as appropriate.
There are two types of time dependencies: absolute and relative.
Jobs with absolute time dependencies are defined to run at a specific time of
the day (for example, 9:30 on Thursday or 12:00 on December 25). The
following attributes define absolute time dependencies:
days_of_week
exclude_calendar
run_calendar
run_window
start_times
Relative time dependencies are based either on 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). The following
attributes define relative time dependencies:
auto_delete
max_run_alarm
min_run_alarm
start_mins
term_run_time
watch_interval
During the time change, absolute time attributes behave differently than
relative time attributes.
80 User Guide
Daylight Time Changes

Because the clock loses an hour during the change from standard time to
daylight time in the spring, Unicenter AutoSys JM cannot schedule any jobs
using time-dependent attributes during that time.
The solution is to schedule jobs with absolute time dependencies for the
missing hour to start during the first minute of the next hour. In this case,
because the time change automatically occurs at 2:00 a.m., a job scheduled to
run on Sundays at 2:05 runs at 3:00:05 that day; a job scheduled to run
every day at 2:45 runs at 3:00:45. Although it might not be possible to start a
large number of jobs during the first minute of the hour, this feature does
preserve the scheduling order.
If you schedule a job to run more than once during the missing hour (for
example, at 2:05 and 2:25), only the first scheduled job run occurs. Additional
start times for the same job in the missing hour are ignored.
Jobs with relative time dependencies run as expected. For example, a job
specified to run at 0, 20, and 40 minutes after the hour is scheduled for 1:00
ST, 1:20 ST, 1:40 ST, 3:00 DT, 3:20 DT, and 3:40 DT.
Run windows are treated differently. When the specified end of the run window
falls during the missing hour, Unicenter AutoSys JM recalculates its end time,
so that the effective duration of the run window remains the same. For
example, the product recalculates a run window of 1:00 - 2:30 so that the
window ends at 3:30 and the run window still remains open for 90 minutes.
When the run windows specified start time falls during the missing hour,
Unicenter AutoSys JM moves the start time to 3:00. The end time does not
change, so the run window is shortened. For example, a run window of
2:45 - 3:45 becomes 3:00 - 3:45, shortening the run window by 15 minutes.
When the run windows start and end time both fall during the missing hour,
Unicenter AutoSys JM moves the start time to the first minute after 3:00 and
the end time to one hour later. Therefore, the resulting run window might be
lengthened. For example, a run window of 2:15 - 2:45 becomes 3:00 - 3:45,
or 15 minutes longer.
Job Definitions 81
Standard Time Changes

Because the clock gains one hour during the change from daylight time to
standard time in autumn, there are two 1:00-1:59 hours. Unicenter AutoSys
JM only runs jobs for which the start_time attribute is set to between 1:00 and
1:59 during the second (standard time) hour. Jobs for which the start_mins
attribute is set run in both hours.
For example, a job scheduled to run on Sundays at 1:05 runs only at the
second 1:05. A job scheduled to run every 30 minutes runs at 1:00 DT and
1:30 DT, then again at 1:00 ST and 1:30 ST, and so on, as the following
illustration shows:
Jobs that are not time-based but have other dependencies still run during the
first hour.
Jobs with relative time dependencies run as expected. For example, if a job is
scheduled to run on Sunday at 0:30 and its term_run_time attribute is set to
120 minutes, the job would normally terminate at 2:30. On the day of the
autumn time change, the job terminates at 1:30 standard time, which is 120
minutes after the job started.
When testing how the change from daylight time to standard time affects your
jobs, you must set the system clock to a time before 1:00 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 during the 1:00 a.m. to 2:00 a.m. window, the system
assumes that the time change has already occurred and does not reset at 2:00
a.m.
82 User Guide
Run windows are treated differently. When the specified start of a run window
is before the time change and its specified end occurs during the repeated
hour, the run window closes during the daylight time period (the first hour).
For example, a run window of 11:30 - 1:30 ends at 1:30 DT, not 1:30 ST (that
is, the run window remains open for its specified two hours, not for three
hours). A problem might occur if there are also associated start times for the
job that occur during the repeated hour. If the job in our example 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.
When the specified opening of the run window falls during the repeated hour,
Unicenter AutoSys JM moves its start time to the second, standard time hour.
The end time does not change, so the length of the run window remains the
same. For example, a run window of 1:45 - 2:45 becomes 1:45 ST - 2:45 ST.
When both the specified start and end of the run window occur during the
repeated hour, the run window opens during the second, standard time hour.
Job Definitions 83
Chapter 4: Job Types, Structure, and

States
Introducing Jobs (see page 85)
Job Types and Structure (see page 86)
How the Agent Sets Job Profiles (see page 91)
Basic Job Attributes (see page 98)
Job States (see page 100)
Starting Conditions (see page 104)
Job Run Numbers and Names (see page 117)
Introducing Jobs
All activity controlled by Unicenter AutoSys JM is based on jobs. Other objects,
such as monitors, reports, and the Job Status Console, track job progress. A
job is the foundation for the entire operations cycle.
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 run.
You can define jobs using JIL statements. 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.
Note: The Scheduler must be running before you start any processes, so you
should start it before performing the tasks described in this chapter.
More information:
Schedulers (see page 110)
Job Definitions (see page 75)
Job Types, Structure, and States 85
Job Types and Structure

There are three basic types of classic jobs: command, file watcher, and box.
The structure of a job depends on the job type.
As their names imply, command jobs run commands, box jobs are containers
that hold other jobs or box jobs, and file watcher jobs watch for the arrival of
a specified file. 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 taken when the jobs run.
Unicenter AutoSys JM also supports definition of new job types.
The following illustration shows the structure of a job:
More information:
Create a New Job Type (see page 89)
86 User Guide
Basic Job Information

In the previous illustration, the attributes listed under Job comprise basic job
information and are common to all jobs regardless of type. These attributes
include the job name, starting conditions, specified alarms, restart conditions,
and a variety of other settings that are not shown in the illustration (such as
the box, if any, in which the job resides).
A job's starting conditions can depend on the date, time, and status of any
other job.
Command Jobs
Command jobs are usually simply referred to as jobs. The command run by
the job can be a shell script, an executable program, a file transfer, and so on.
When a command job runs, the result is the execution of a specified command
on a Client computer. 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.
Command jobs have the following supporting features:
Resource Criteria
Unicenter AutoSys JM verifies that an appropriate 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.
Profile Script
For each job, you can specify a script to be sourced before command
execution that defines the environment in which the command is to run.
All commands are run under the Bourne shell (/bin/sh). Therefore, all
statements in the profile must use /bin/sh syntax.
You can define a profile with environments variables that are stored
in the Windows registry by using the job profiles binary.
Standard I/O Files
For each job, you can specify the standard input, output, and error files.
Box Jobs
A box job (or box) is a container of other jobs. You can use it 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
contain other boxes. You can use boxes to contain other boxes that contain
jobs that are related by starting conditions or other criteria (not by similar
application types). This allows you to group the jobs and operate on them in a
logical manner.
Box jobs are powerful tools for organizing, managing, and administering large
numbers of jobs that have similar starting conditions or complex logic flows.
Knowing how and when to use boxes is often the result of some
experimentation.
Starting Conditions for Box Jobs

When no other starting conditions are specified at the job level, a job in a box
runs when the starting conditions for the box are satisfied. When several jobs
in a box do not have job-level starting conditions, they all run in parallel.
When any job in a box changes state, other jobs check if they are eligible to
start running.
When the priority attribute is set for jobs in a box, they are processed in order
of priority, highest to lowest.
Note: For more information about the priority attribute, see the Reference
Guide.
Jobs in boxes run only once for each box execution. If you specify multiple
start times for a job during one box processing cycle, only the first start time
is used. This prevents jobs in boxes from inadvertently running multiple times.
Unicenter AutoSys JM starts a job when the current time matches, or is later
than, the specified start time. In addition to explicit starting conditions, jobs in
boxes have the implicit condition that the box job itself is running. This means
that jobs in a box start only if the box job is running. However, if a job in a
box starts and the box job is stopped, the started job runs to completion.
Note: Use caution when putting a job with more than one time-related
starting condition in a box. For example, assume that a job that runs at 15
and 45 minutes past the hour is put in a box that runs at the start of 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 runs again at the
start of the next hour. At that time, the job runs as soon as the box starts
because it is past its 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.
88 User Guide
File Watcher Jobs

A file watcher job is similar to a command job. However, instead of starting a
user-specified command on a Client computer, a file watcher job starts a
process that monitors for the existence and size of a specific operating system
file. When that file reaches the specified 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, assume a file must be downloaded from a mainframe, and it is
expected to arrive after 2:00 a.m. After it arrives, a batch job is 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 exit. You could also set up the batch job so that the
completion of the file watcher job is its only starting condition.
Create a New Job Type

You can create new job types. For example, you have an adapter binary and
you want to create 300 jobs that invoke the adapter. You can create 300
command jobs and specify the command each time or you can define a single
job type (for example '0') that represents the adapter command and define
300 jobs of type '0'.
To create a new job type
1.
Insert_job_type:0.
2.
Enter the following command: special_adapter.
3.
Enter the following description: This is a job type to run special adapter
commands.
The new job type is created.
Use a New Job Type

After you create a new job type, you must define a job to use it.
To use a new job type
1.
Insert_job:test.
2.
Enter job_type:0.
3.
Enter machine name: localhost.

The newly created job type can be used.
Unicenter AutoSys JM also supports delete_job_type and update_job_type.

You can use the delete_job_type to delete a job type, and the
update_job_type when you want to modify an existing job type.
Starting Conditions and Boxes

When you put a job in a box, it inherits all of the starting conditions of the
box. Therefore, all starting conditions defined for the box must be met and the
box must enter the RUNNING state before the job can run. If there are no
additional conditions on the job, it starts as soon as the box starts. A job runs
only once for each box execution.
By default, there is no sequential job processing in a box. For example, if three
jobs are in a box, all three jobs start when the box starts if they have no
additional conditions.
To implement a processing sequence for jobs in a box, you must specify
additional starting conditions for each job. For example, you could specify that
Job1 has no starting conditions, Job2 depends on the completion of Job1, and
Job3 depends on the completion of Job2.
Note: Jobs that depend on a job that is ON_ICE run as if that starting
condition has been satisfied. In this scenario, if Job2 enters the ON_ICE state,
then Job1 and Job3 start simultaneously when the box they are in starts
running.
90 User Guide
How the Agent Sets Job Profiles

A job profile defines the appropriate non-system environment variables for a
job. Before running a command job, the Agent sets the assigned job profile on
the job's target computer. Use the following process to define and use a job
profile:
Use the Job Profiles Manager to define a profile that contains the
environment variables required for a specific job to run. The profile job
attribute is set to the name of the set of environments stored in the
registry as created by the Job Profiles Manager.
You can create a simple shell script file written to the Bourne shell
containing the environments you wish to source. The profile job attribute
is set to the filename of the shell script.
Use the profile attribute or the Unicenter WCC GUI to assign the profile to
one or more jobs.
The Agent on the job's target computer first sets the environment
variables for the job's execution, and then sets the specified job profile
variables.
Note: 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 value read is used.
The Agent searches for the assigned profile. By default, the Agent
searches for the profile on the computer on which the command is to run.
However, when assigning the job profile, you can specify both the
computer name and the profile name, which lets you run the job on one
computer while using a job profile defined on another computer.
Note: Job profiles are instance-specific. You cannot assign a profile
defined in one Unicenter AutoSys JM instance to a job defined in another.
Environment Variables
You must define all the environment variables needed to run a job in its
assigned profile, because only one profile is sourced before a command job
runs.
If you do not assign a profile job attribute in the job definition, the Agent
uses the DEFAULT job profile. While Unicenter AutoSys JM supplies a DEFAULT
job profile, it does not define any environment variables in it. You must use
the Job Profiles Manager to define your own DEFAULT profile.
When the Agent reads the profile, the environment variables in the profile are
expanded. For example, if Path is a variable in the specified profile, Unicenter
AutoSys JM expands any environment variables specified as the value of Path,
uses this path to search for the command, and sets the new value for the
%Path% variable before running the command. You can specify the full path
name, in which case you can use variables set from the job profile in the path
name specification. The Agent reads profile variables in alphabetical order.
Therefore, if you plan to expand variables in the profile itself, you must define
the variables so that they are in the appropriate order when read
alphabetically.
Note: Although environment variables are set automatically in the command's
environment, user environment variables are not automatically set. All other
required environment variables must be defined in the job's profile, either in
the DEFAULT profile (which on Windows is initially empty) or in a user-defined
job profile.
For more information about the profile attribute, see the Reference Guide.
92 User Guide
Use the Job Profiles Manager

If you have Windows Administrators group privileges and Windows
Registry edit privileges, you can use the Job Profiles Manager to create, open,
and delete job profiles and to create, edit, and delete profile environment
variable definitions.
To use the Job Profiles Manager
1.
Double-click the Instance Job Profile Management icon.

The Job Profiles Manager is displayed.
Note: Profiles are instance-specific. Therefore, if you have installed
multiple Unicenter AutoSys JM instances, make sure that you launch the
Job Profiles Manager for the appropriate instance. By default, the Job
Profiles Manager connects to the computer that you are logged on to.
2.
(Optional) To connect to a host other than the computer you are currently
logged on to, type the appropriate name in the Host Name field and click
Connect.
The Job Profiles Manager connects to the specified host.
3.
Do one of the following:
To open a profile, click

Name list.
and select a profile to open from the Profile
The current settings for the selected profile appear in the Environment
Variables area. Double-click a variable to display it in the Variable and
Value fields for editing.
To create a profile, enter a new profile name in the Profile Name field.
A new profile is created.
Note: Variable definitions in Windows are not case-sensitive. However, the Job
Profiles Manager does replicate, in the job profile itself, the capitalization that
you enter in the Variable and Value fields.
Delete a Job Profile

You can delete a job profile that is no longer needed for a job to run.
To delete a job profile
1.
Select the profile to delete from the Profile Name list in the Job Profiles
Manager.
Variables area.
2.
Click Delete Profile.

A confirmation message appears.
3.
Click OK.
The job profile is deleted.
Note: You cannot delete the DEFAULT profile. However, you can add and
delete environment variables in the DEFAULT profile. When you click Cancel,
the Job Profiles Manager discards all modifications you made to the current
profile, but does not restore deleted variables.
94 User Guide
Create a Variable Definition

You can add a variable and value to a profile so that a job can use the
variable at run time.
To create a variable definition
1.
Select the profile for which to create a variable definition from the Profile
Name list in the Job Profiles Manager.
Variables area.
2.
Enter a variable name in the Variable field, enter a value for the variable in
the Value field, and click Set.
The variable definition is recorded and the new variable appears in the
Environment Variables area.
3.
When you finish adding variables, do one of the following to save the
settings for the current profile:
Select a new profile from the Profile Name list.

Your settings are saved and the current settings for the newly selected
profile appear in the Environment Variables area.
Click OK.
Your settings are saved and the Job Profiles Manager closes.
Note: When adding new profiles, you must either define the profile on the
computer where the command runs 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, a Profile not found error displays when you attempt to start the
job. For more information, see the Reference Guide.
Edit a Variable Definition

You can modify an existing variable definition in the profile if the job
requires a different value to run.
To edit a variable definition
1.
Select the profile for which to edit a variable definition from the Profile
Variables area.
2.
Double-click the variable to edit in the Environment Variables area.

The dialog refreshes to display the name of the selected variable in the
Variable field and its value in the Value field.
3.
Modify the variable name and value as appropriate, and click Set.
The variable definition is recorded and the modified variable appears in the
Environment Variables area.
4.
When you finish editing variables, do one of the following to save the

Click OK.
Note: If you click Cancel, the Job Profiles Manager only discards
modifications you made to the current profile. Any changes you made to
other profiles were saved when you selected the current profile.
96 User Guide
Delete a Variable Definition

If you do not want an environment variable in the profile, you can delete
it.
To delete a variable definition
1.
Select the profile from which to delete a variable definition from the Profile
Variables area.
2.
Double-click the variable to delete in the Environment Variables area.

The dialog refreshes to display the name of the selected variable in the
Variable field and its value in the Value field.
3.
Click Delete.
The variable and its value are deleted from the profile.
4.
When you finish deleting variables, do one of the following to save the

Click OK.
Note: You cannot undo the deletion of a variable, but you can cancel any
other modifications you made to the current profile by clicking Cancel.
When you click Cancel, the Job Profile Manager closes and Unicenter
AutoSys JM does not update the current profile. Any changes you made to
other profiles were saved when you selected the current profile.
Basic Job Attributes

This section discusses the required job attributes for each standard job types.
Additional optional attributes are available for more advanced job definitions.
The owner attribute, which is required for all job types, is automatically
assigned when you create a job definition.
Command Job Attributes

The following attributes are required for all command job definitions:
job_name
Defines the name used to identify the job to Unicenter AutoSys JM.
command
Defines the shell script, command, or application that Unicenter AutoSys
JM runs when all of the job's starting conditions are met.
machine
Defines the name of the server on which to run the command.
condition
Defines the dependency conditions that must be met for the job to run.
This is not always required. For example, it may not be required in a case
where a job is always started manually.
File Watcher Job Attributes

The following attributes are required for all file watcher job definitions:
job_name
Defines the name used to identify the job to Unicenter AutoSys JM.
watch_file
Defines the name of the file to monitor.
machine
Defines the name of the server on which to run the command.
condition
98 User Guide
Box Job Attributes

The following attributes are required for all box job definitions:
box_name
Defines the name used to identify the job to Unicenter AutoSys JM. This
name is used by other jobs as the name of their parent box.
condition
Job States
Job States
Unicenter AutoSys JM tracks the current state, or status, of every job. The
value of a job's status checks when to start jobs with dependencies on the
tracked job. The job status is displayed in the job report generated by the
autorep command and in the Unicenter WCC GUI.
A job can have one of the following statuses:
ACTIVATED
Indicates that the top-level box in which the job resides is currently in a
RUNNING state but the job has not yet started.
FAILURE
Indicates one of the following:
For a command job, the command exited with a code greater than the
max_exit_success (maximum exit code for success) attribute value
specified for the job.
For a box job, at least one job in the box ended with a FAILURE status
or the box_failure (exit condition for box failure) attribute evaluated to
TRUE.
By default, any exit code greater than 0 is interpreted as FAILURE.

Unicenter AutoSys JM issues an alarm when a job fails.
INACTIVE
Indicates that the job has not yet been processed. Either it has never run,
or its status was intentionally changed to deactivate its previous
completion status.
ON_HOLD
Indicates that the job is on hold and will not run until it receives the
JOB_OFF_HOLD event.
ON_ICE
Indicates that the job is removed from all conditions and logic, but is still
defined. Operationally, this condition is equivalent to deactivating the job,
and it remains on ice until it receives the JOB_OFF_ICE event.
PEND_MACH
Indicates that a job can logically start (that is, all the starting conditions
have been met), but the machine to which it is assigned is currently
offline, either because of a MACH_OFFLINE event or because the computer
was proactively put in an inactive state. When the machine comes back
online and the required load units become available, Unicenter AutoSys JM
starts the job.
100 User Guide
Job States
QUE_WAIT
Indicates that the job can logically start (that is, all the starting conditions
have been met), but the machines to which it is assigned do not have
enough available load units. When the required load units become
available, Unicenter AutoSys JM starts the job.
RESTART
Indicates that the job was unable to start because of hardware or
application problems, and has been scheduled to restart.
RUNNING
Indicates that the job is running. If the job is a box job, the jobs in the box
can start (other conditions permitting). If the job is a command or file
watcher job, the RUNNING status indicates that the specified process is
actually running on the client computer.
STARTING
Indicates that the Scheduler has initiated the start job procedure with the
Agent. This status is only for command and file watcher jobs.
SUCCESS
Indicates that the job exited with a code equal to or less than the
max_exit_success (maximum exit code for success) attribute value
specified for the job.
If the job is a box, this value means that all the jobs in the box have
finished with a SUCCESS status or the box_success (exit condition for box
success) attribute evaluated to TRUE.
By default, only exit code 0 is interpreted as SUCCESS. However, you can
reserve a range of values up to the max_exit_success value to interpret as
SUCCESS for each job.
TERMINATED
Indicates that the job ended while in the RUNNING state. A job can be
terminated if it receives a KILLJOB event or if it was defined to terminate if
its containing box failed. A job might also be terminated if it exceeds its
term_run_time (maximum run time) attribute value or if it receives a UNIX
kill command. If the job itself fails, it has a FAILURE status, not a
TERMINATED status. Unicenter AutoSys JM issues an alarm when a job is
terminated.
Note: Jobs that depend on a job that is ON_ICE run as though the job
succeeded. However, dependent jobs do not run when a job is ON_HOLD. If a
jobs starting conditions are already satisfied when it is taken off hold, it is
scheduled to run. However, when a job is taken off ice, it does not run (even if
its starting conditions are already satisfied) until its starting conditions recur.
Job States
Example: Status of Simple Command Jobs

A change in job status is reported as a CHANGE_STATUS event, which the
Scheduler records in its log when the status is processed. For example, when
the job test_job changes from STARTING to RUNNING, the Scheduler log
contains the following entry:
EVENT: CHANGE_STATUS STATUS: RUNNING JOB: test_job
The following illustration shows 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.
Note: In the following illustration, statuses are shown as shaded boxes:
102 User Guide
Job States
Example: Status of Box Jobs

For a job in a box, the job enters the ACTIVATED state when the top-level box
in which it resides enters the RUNNING state, as the following illustration
shows. After the job starts, the remainder of the scenario is the same as for
simple jobs.
Note: In the following illustration, statuses are shown as shaded boxes:
A box always enters the RUNNING state as soon as all its starting conditions
are met. This RUNNING event usually starts jobs in the box.
If a job has an associated priority, all its starting conditions have been met,
and there are not enough machine resources available, it enters the
QUE_WAIT state. When resources become available, it enters the STARTING
state, and then runs.
Because the job state reflects the Scheduler status, a job might have actually
completed even if the Scheduler has not processed that event. In this case,
Unicenter AutoSys JM still shows the job's status as RUNNING. To view all the
events for a job, including those that have not yet processed, display the job
detail in the output of the autorep command.
Starting Conditions
In addition, the job state always reflects the most recent event processed.
Therefore, after a job completes, the status remains as it was on completion.
If the job ended successfully, the status remains SUCCESS until the job runs
again.
Note: When a box job starts, all jobs in the box change their state to
ACTIVATED before they run. Jobs run immediately unless other conditions
apply. If a box completes before a job runs, the job is set to INACTIVE at box
completion. As a result, jobs do not retain their statuses from previous box
processing cycles when a new box cycle begins.
More information:
Box Jobs (see page 88)
Starting Conditions
Unicenter AutoSys JM verifies if it should start a job based on the evaluation of
the starting conditions defined for the job. All defined starting conditions must
be true for a job to start. These conditions can include one or more of the
following:
Date and time scheduling parameters are met.
Starting conditions specified in the job definition evaluate to TRUE.
For jobs in a box, the box is in the RUNNING state.
The current job state is not ON_HOLD or ON_ICE.
The jobs machine is not OFFLINE.
When an event changes any of the above conditions, Unicenter AutoSys JM

finds all the jobs that might be affected by this change and checks if it can
start them.
104 User Guide
Starting Conditions
Date and Time Dependencies

You can use JIL statements to schedule Unicenter AutoSys JM jobs to start at a
specific date and time. Unicenter AutoSys JM then calculates a matrix of
specified day, date, and time values and starts jobs accordingly. A time range
cannot span more than 24 hours.
For example, you can define a job to start on Monday, Wednesday, and Friday
at 8:00 a.m. and 5:00 p.m.
You can specify days of the week or actual dates, but you cannot specify both.
You can specify days of the week using JIL, but you can only specify actual
dates using custom calendars. You can also specify a time zone to apply to
your starting times, and you can define a job to start at one specific time of
day or hourly, denoted in minutes past the hour.
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 (that is, the time zone under which the Scheduler runs).
Before you start the Scheduler, make sure that the TZ environment variable is
set. The Scheduler 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 or autorep.
Custom Calendars
You can use the autocal_asc utility to 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 to specify days on which to run the
jobs with which they are associated or to specify days on which jobs with
which they are associated should not run. Calendars exist independently of
any jobs associated with them and are referenced by jobs through job
definitions.
Starting Conditions
Job Dependencies Based on Job Status

You can define starting conditions to start jobs based on the current status of
one or more jobs that exist in the database. In this way you can program
simple or complex prerequisites for starting a job.
For example, you can implement a single-threaded, batch queue-like set of job
dependencies so that JobB starts when JobA achieves a SUCCESS status and
JobC starts when JobB achieves a SUCCESS status.
You can configure more complex conditions by combining a series of conditions
with the AND and OR logical operators. You can 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,
which force precedence. The equation is evaluated from left to right.
For example, in the following set of starting conditions, either both A and B
must be successful or both D and E must be successful for the statement to
evaluate as TRUE:
(success(JobA) and success(JobB)) or (success(JobD) AND success(Job E))
Note: If you specify a condition for an undefined job, the condition evaluates
as FALSE, and any jobs dependent on this condition do not run. You can use
the ujo_chk_cond stored procedure to check for this type of invalid condition
statement.
The syntax for defining job dependencies is the same whether the job is being
defined using JIL or the Unicenter WCC GUI, except that the JIL statement
begins with the JIL condition keyword.
106 User Guide
Starting Conditions
The following is the syntax for conditions based on job status:

status(job_name)
status
Indicates the status as one of the following:
success
Indicates that the status condition for job_name is SUCCESS. You can
abbreviate this value to s.
failure
Indicates that the status condition for job_name is FAILURE. You can
abbreviate this value to f.
done
Indicates that the status condition for job_name is SUCCESS, FAILURE
or TERMINATED. You can abbreviate this value to d.
terminated
Indicates that the status condition for job_name is TERMINATED. You
can abbreviate this value to t.
notrunning
Indicates that the status condition for job_name is anything except
RUNNING. You can abbreviate this value to n.
job_name
Identifies the job on which the new job is dependent.
You can also abbreviate the dependency specification EXIT CODE to e and
VALUE (of a global variable) to v.
You can use the max_exit_success (maximum exit code for success) attribute
set for a job to control the value of the SUCCESS status. If you specify this
attribute, any job that exits with an exit code less than or equal to the
specified value is treated as a success. A FAILURE status means the job exited
with an exit code higher than this value. The default exit code for normal job
completion is 0. A TERMINATED status means the job was killed.
Note: You can use either uppercase or lowercase letters to specify a status.
However, you cannot use mixed case.
Starting Conditions
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 job run, regardless of when that run occurred.
However, if you want 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 available.
When a box job starts, the status of all the jobs in the box changes to
ACTIVATED. Therefore, subsequent jobs in the box that depend on the
completion of jobs performed earlier in the same box only use the completion
statuses from this box run. 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 prevents time-critical jobs from being affected by invalid information.
When a job is first entered into the database, and before it runs for the first
time, its status is set to INACTIVE. By changing the status of jobs that have
completed but whose completion status should no longer be used in dependent
job conditions to INACTIVE, the completion status from the last run is no
longer the current status and it is not used.
Use the sendevent command to change a job status to INACTIVE.
Alternatively, you could create a Unicenter AutoSys JM job to accomplish this.
If you change the status of a top-level box to INACTIVE, all the jobs in the box
also change to INACTIVE.
Deleting and reinserting the job using JIL accomplishes the same thing.
However, the past reporting history on the job is no longer available. Updating
a job using JIL does not change the status of the job.
108 User Guide
Starting Conditions
Cross-Instance Job Dependencies

A Unicenter AutoSys JM instance is one licensed version of Unicenter AutoSys
JM software running as a Unicenter AutoSys JM server and as one or more
Unicenter AutoSys JM Clients, on one or more computers. An instance uses its
own Scheduler and Event Server 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, you can use a sendevent command similar to the following to
send events between instances:
sendevent -E STARTJOB -J job_name -S autoserv
In this example, the job_name identifies a job defined for the instance
indicated by the autoserv, which identifies the instance's unique, capitalized
three-character identifier (for example, ACE).
You can also associate jobs 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 resemble the following:
condition: success(jobA) AND success(jobB^PRD)
In this example, the success (jobB^PRD) condition specifies the successful

completion of a job named jobB running on a different instance specified with
the three-character identifier PRD. If the dependency specification does not
include a caret (^) and a different instance ID, the current instance is used by
default.
When Unicenter AutoSys JM encounters a cross-instance dependency, it sends
an EXTERNAL_DEPENDENCY event from the requesting instance. If the target
instance cannot be reached, the product issues an INSTANCE_UNAVAILABLE
alarm.
Starting Conditions
The following illustration shows two instances, each with a Single Event
Server, exchanging cross-instance job dependencies:
Different instances can run from the same executables and can have the same
values for $AUTOSYS and $AUTOUSER, both on the Scheduler machine and on
machines running remote Agents. However, each instance must have a
different value for $AUTOSERV.
For more information, see the Windows or UNIX Implementation Guide.
Schedulers
When you implement cross-instance dependencies, different Schedulers can do
the following:
Run on different server computers or on the same server computer.
Access the same Client computers to start jobs.
Send events to other Unicenter AutoSys JM instances.
Note: If the Application Server of a target instance is down, the Scheduler

tries to send an event (or events) every five minutes until the target instance's
Application Server can be reached.
110 User Guide
Starting Conditions
Event Servers
Event Servers track cross-instance job dependencies. Each time a job
definition with a cross-instance job dependency is submitted to the database,
the Event Server does the following:
Makes an entry in the ujo_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.
Makes an entry in the ujo_req_job table of the receiving instance. The

entries in this table specify the jobs defined as job dependencies in a job
definition on the source instance.
The Event Server uses the job name, a caret symbol (^) and the instance
name to enter jobs in the ujo_ext_job and ujo_req_job tables. For example:
jobB^PRD
The use of multiple databases is completely independent of instances using

cross-instance dependencies. You can have multiple instances that each use
Dual Event Servers.
Note: When communicating with the Application Server, Schedulers can only
connect to those instances with a like Application Server. That is, instances
with Sybase data servers can only connect with other instances that have
Sybase data servers. The same holds true for instances with Oracle
Example: Job Dependencies
For a job that runs only when the job named DB_BACKUP succeeds, you would
specify the job dependency as follows:
success(DB_BACKUP)
If JobC should only start when both JobA and JobB complete successfully or
when both JobD and JobE complete (regardless of whether JobD and JobE
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))
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 provide alternate actions for
error conditions.
Starting Conditions
For example, if JobB fails after partially processing, you might want to call a
routine called Backout that reverses the changes that were made. You would
specify the following job dependency in the job definition for Backout:
failure(JobB)
You can use the notrunning operator to keep multiple jobs from running
simultaneously. For example, assume you do not want to run a database
dump (DB_DUMP) and a file backup (BACKUP) at the same time because such
processing would adversely impact performance. However, you might have a
smaller job that can run as long as both of these resource-intensive jobs are
not running. You would specify the smaller job's dependency as follows:
notrunning(DB_DUMP) AND notrunning(BACKUP)
More information:
Specifying Job Load (job_load) (see page 186)
112 User Guide
Starting Conditions
Job Dependencies Based on Exit Codes

You can use the following syntax to 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.
This method of defining job dependencies has the following format:
exitcode (job_name) operator value
job_name
Defines the name of the job upon which the new job depends.
operator
Specifies one of the following exit code comparison operators:
=
Equal to.
!=
Not equal to.
<
Less than.
>
Greater than.
<=
Less than or equal to.
>=
Greater than or equal to.
value
Defines the numeric exit code value on which to base the dependency.
For example, if a broken communication line results in JobA failing with an exit
code of 4, and you want the system to run a script (JobB) that redials the line
when this code is encountered, you would enter the following for the job
dependency specification for the JobB redial job:
exitcode (JobA) = 4
You can use any job status or exit codes as part of the specification for
starting conditions. You can abbreviate the dependency specification exitcode
with the letter e (uppercase or lowercase).
Starting Conditions
Exit Codes and Batch Files in Jobs Running on Windows
When you define jobs to run batch files on Windows, you should be
aware of and account for Windows-specific behavior.
Windows programs return any exit values that are programmed in the
executable code. This exit value is the last thing returned to Windows when
the program terminates.
Generally, a zero (0) 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.
Modify these programs so that they return expected values, and use these
values when specifying exit code dependencies.
Jobs are created using standard Windows process creation techniques. After
the job is created, the 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.
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 a job to start *.BAT batch files.
The exit code returned from a batch file is the return code from the last
operation executed in 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 sample batch file returns 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 runs the test. Therefore, this batch file returns a 0 (successful) exit
code, even if test failed to execute as intended.
114 User Guide
Starting Conditions
To help handle situations like this, Unicenter AutoSys JM supplies a program

called FALSE.EXE. This program resides in the Windows %AUTOSYS/bin
directory and takes only one parameter, which is the exit code you want
FALSE.EXE to return on completion. You can use FALSE.EXE as follows:
REM test batch file
test
if errorlevel 1 goto bad
exit
:bad
del test.tmp
false 1
When test fails with error level 1, this batch file returns an exit code of 1 from
FALSE.EXE, whether the test.tmp file exists or not.
Starting Conditions
Job Dependencies Based on Global Variables

You can base job dependencies on global variables set using the sendevent
command. When using global variables in this way, the job dependency is
satisfied only when the value of the expression evaluates to TRUE.
This method of defining job dependencies has the following format:
VALUE(global_name) operator value
global_name
Defines the name of the global variable upon which the job depends.
Limits: This value can be up to 30 characters in length. The following
characters are valid: a-z, A-Z, 0-9, period (.), underscore (_), and
hyphen (-). You can include spaces in a global variable name.
operator
Specifies one of the following exit code comparison operators:
=
Equal to.
!=
Not equal to.
<
Less than.
>
Greater than.
<=
Less than or equal to.
>=
Greater than or equal to.
value
Defines the numeric or text value of the global variable on which to base
the dependency.
Limits: This value can be up to 30 characters in length and cannot contain
quotation marks or spaces. The following characters are valid: a-z, A-Z, 09, period (.), underscore (_), and hyphen (-).
Note: When using JIL, use the condition attribute to enter the above
expression in the appropriate JIL script.
116 User Guide
Job Run Numbers and Names
For example, assume that a set of jobs in a box should only run with a
manager's approval. In this case, use the following syntax to set the global
variable named manager-ok to OK, and make the top-level box job dependent
on this global variable:
VALUE(manager-ok) = OK
You can abbreviate the dependency specification VALUE with the letter v
(uppercase or lowercase).
Job Run Numbers and Names

Unicenter AutoSys JM uses 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 in a box. This means that all jobs in 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 in the same run.
If a job restarts, the run number remains the same and the ntrys field is
incremented. In the standard reports (autorep command), these two values
are displayed in the run column as run_num/ntry.
The run_num/ntry value is defined in the run-time environment for the job,
and is accessible to shell scripts or executables run 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 shell scripts or executables run
as the job's UNIX command. The value is contained in the variable
$AUTO_JOB_NAME.
On Windows, the environment variables are %AUTORUN% and
%AUTO_JOB_NAME%.
Chapter 5: Box Job Logic

Basic Box Concepts (see page 119)
Box Job Attributes and Terminators (see page 122)
Box Job Flow Examples (see page 126)
Advanced Job Flows (see page 134)
Basic Box Concepts

A box is a container of jobs with similar starting conditions (either date and
time conditions or job dependency conditions). Use boxes to group jobs with
similar scheduling parameters, not to group jobs organizationally. For
example, you can group jobs that run daily at 1:00 a.m. in a box and assign
them a daily start condition. However, you should not group a variety of
account processing jobs with diverse starting conditions in the same box.
Default Box Job Behavior

The following default rules apply to boxes:
Jobs in a box run only once for each box execution.
Jobs in a box start only if the box itself has a status of RUNNING.
Boxes are used primarily for jobs with the same starting conditions.
A box used to group sequential jobs can contain up to 1,000 jobs.
A box remains in RUNNING state until all the jobs it contains have run.
A box returns a status of SUCCESS when all the jobs it contains have run
and returned a status of SUCCESS.
A box returns a status of FAILURE when all the jobs it contains have run
and one or more of the jobs has returned a status of FAILURE.
A box runs until it reaches a status of SUCCESS or FAILURE.
Using the sendevent command to change the state of a box to INACTIVE

changes the state of all the jobs it contains to INACTIVE.
More information:
Box Job Attributes and Terminators (see page 122)
Box Job Logic 119
Basic Box Concepts
Box Job Recommendations

Because all jobs in a box change status when a box starts running, you may
want to use boxes to implement job cycle behavior. However, placing jobs in a
box to achieve this behavior can affect your system adversely because the job
status changes put a larger load on the Scheduler when the box starts
running.
Do not put jobs in a box solely to run reports on all of them. When you run
autorep on a box, the command generates a report about the box and all the
jobs it contains (unless you use the -L0 option). If you use wildcard characters
when specifying a job name, the report could contain duplicate entries. For
example, suppose you have a box named acnt_box that contains three jobs
(acnt_job1, acnt_job2, and daily_rep). If you specify acnt% as the job name
for the autorep report, the resulting report will contain an entry for the box
acnt_box and an entry for each job in the box. The autorep command
continues searching for all job names matching the wildcard character and lists
acnt_job1 and acnt_job2 a second time.
Note: Job names can only contain the following characters: a-z, A-Z, 0-9,
period (.), underscore (_), and hyphen (-). You cannot include spaces in a job
name.
How a Box Runs

When a box starts running, the status of all the jobs it contains (including
subboxes) changes to ACTIVATED, which means they are eligible to run.
Because of this status change, jobs in boxes do not retain their statuses from
previous box cycles.
When a box starts running, the system performs the following actions:
Analyzes each job for additional starting conditions.
Starts all jobs with no additional starting conditions and without any
implied order or priority.
Maintains jobs with additional starting conditions in the ACTIVATED state

until those additional dependencies are met.
Maintains the box in the RUNNING state as long as there are jobs in it with
ACTIVATED or RUNNING status.
Changes the status of the job directly from ACTIVATED to INACTIVE if its
containing box is terminated before the job starts.
Note: Jobs in a box cannot start unless the box has a status of RUNNING.
However, after a job starts running, it runs to completion even if the box is
stopped.
120 User Guide
Basic Box Concepts
After 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 it contains remain
unchanged until the next time the box runs.
If a box changes to TERMINATED state (for example, if a user sends a KILLJOB
event), it stays in TERMINATED state until the next time it is started,
regardless of any later state changes of the jobs it contains.
Example: Simple Box Job
This example shows the behavior of a simple box job.
The following illustration shows a box named simple_box that contains three
jobs (job_a, job_b, and job_c). job_a and job_b have no starting conditions.
The starting condition for job_c is the success of job_b.
When simple_box starts running, the status of all the jobs changes to
ACTIVATED. Because job_a and job_b have no additional starting conditions,
they start running. When job_b completes successfully, job_c starts. When
job_c completes successfully, the box completes with a SUCCESS status.
If job_b fails, job_c does not start but remains in the ACTIVATED state.
Because no contingency conditions have been defined, simple_box continues
running, waiting for the default completion criteria (that all jobs in the box
have run) to be met.
More information:
How Job Status Changes Affect Box Status (see page 122)
Box Job Logic 121
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 because of a
FORCE_STARTJOB or CHANGE_STATUS event, the new job status could
change the status of its containing box. A status change for the box could then
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
INACTIVE
SUCCESS
SUCCESS
INACTIVE
TERMINATED or FAILURE
FAILURE
TERMINATED
Any 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 is 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 forced to start and completes successfully, the status of the
box changes to SUCCESS even though none of the other jobs ran.

The following sections describe how to use various job attributes to control the
behavior of box jobs and the jobs they contain.
122 User Guide
Attributes in a Box Job Definition

You can use the box_success and box_failure attributes to override the default
success or failure conditions for a box. When you include these attributes in a
box job definition, they check what conditions must be met to put the box in a
state of SUCCESS or FAILURE. When you specify success conditions for a box,
you must also specify failure conditions; otherwise the product uses the
default failure conditions.
Example: Non-Default Success Condition
This example shows the behavior of a simple box job for which a non-default
success condition is defined.
Assume a box named simple_box that contains three jobs (job_a, job_b, and
job_c), where job_a and job_b have no starting conditions and the starting
condition for job_c is the successful completion of job_b. You could use the
box_success attribute as follows to define a success condition for simple_box:
box_success: success(job_a)
In this case, simple_box completes successfully if job_a runs successfully,

even if job_b is still running. If job_b has not completed successfully when
simple_box completes, job_c changes from ACTIVATED to INACTIVE without
running because the box it is in is no longer running.
Note: Do not define conflicting success and failure conditions when overriding
default box terminators.
Attributes in a Job Definition

You can use the following attributes in the job definition of a job in a box to
force either the job or the box to stop running:
box_terminator: y
Specifies that if the job completes with a FAILURE or TERMINATED status,
the box terminates. Define additional conditions for the other jobs in the
box in case the box is terminated.
job_terminator: y
Specifies that if the job's containing box completes with a FAILURE or
TERMINATED status, the job terminates. You must add this attribute to
each job definition that you want to terminate upon box failure.
More information:
Job Flow with Box Terminator Attribute (see page 132)
Job Flow with Job Terminator Attribute (see page 130)
Box Job Logic 123
Time Conditions in a Box

Each job in a box runs only once each time the box runs. Therefore, do not
define more than one time attribute for any job in a box because the job only
runs 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 define multiple start time conditions for the box
itself, and define no time conditions for the job.
Note: 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 starts immediately.
Example: Define Time Conditions for a Box Job
The following illustration shows a scenario that would not work properly if
placed in a box:
In the illustration, job_a is defined to run repeatedly until it succeeds;

job_report has one starting condition, the 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 is successful. However, if job_a fails,
it will not be able to run again until the next time the box starts, as jobs run
only once per box execution. Job job_report is still ACTIVATED waiting for the
success of job_a, and the status of the box is RUNNING. The box would remain
in this state indefinitely if job_a were not defined as a box terminator. This not
being the case, the failure of job_a will cause the box to enter into a
TERMINATED state, terminating job job_report in the process due to its
job_terminator attribute. Box bx_stat is now in a state that would permit it to
run again at 3:00 a.m. the following day.
124 User Guide
Force Jobs in a Box to Start

You can use the sendevent command to send a FORCE_STARTJOB event to
force a job to start, even if its starting conditions have not been met.
You can also execute the FORCE_STARTJOB command by selecting the Force
Start Job button in the Job Activity Console, which is part of the Unicenter
WCC GUI.
Example: Force a Job in a Box to Start
This example defines a sendevent command that sends a FORCE_STARTJOB
event to force a job in a box to run. You could use the following command to
force the job run_stats to start:
sendevent -E FORCE_STARTJOB -J run_stats
In the following illustration, the box job bx_report contains three jobs
(job_Fwatch, run_stats, and report_stats). If the job run_stats fails, the
bx_report box job terminates 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.
Box Job Logic 125
Box Job Flow Examples

This section contains examples to help explain the flow of box jobs and the
jobs they contain. These scenarios will help provide a clearer understanding of
box job flow concepts.
Default Box Success and Box Failure

This scenario describes the default job flow for box job success and failure.
The box job do_statistics runs every day at 3:00 a.m. It contains three jobs:
update_accounts
Updates files. This job starts when do_statistics starts running. It has no
other starting conditions.
run_stats
Runs statistics. This job starts when update_accounts completes
successfully. It has no other starting conditions.
report_stats
Reports statistics. This job starts when run_stats completes successfully. It
has no other starting conditions.
No conditions for success or failure have been defined for do_statistics;
therefore the default conditions are applied. The box job completes
successfully when all the jobs it contains have run and completed successfully.
The box job fails when all jobs in the box have run and at least one has failed.
The box job remains in the RUNNING state until all the jobs it contains have
run.
126 User Guide
The following illustration shows this job flow:

box_name do_statistics"
Box Job Logic 127
Explicit Box Success and Box Failure

This scenario provides an example job flow in which specific conditions are
defined for the success or failure of a box job.
The box job do_statistics runs every day at 3:00 a.m. It contains three jobs:
update_accounts
Updates files. This job starts when do_statistics starts running. It has no
other starting conditions.
run_stats
Runs statistics. This job starts when update_accounts completes
successfully. It has no other starting conditions.
report_stats
Reports statistics. This job starts when run_stats completes successfully. It
The following conditions define the criteria for success or failure of the box job
do_statistics:
128 User Guide
The box job can complete successfully only when all of the jobs it contains
have completed successfully.
The box job fails if any of the jobs it contains fails.
The following illustration shows the job definitions and the job flow:
Box Job Logic 129
Job Flow with Job Terminator Attribute

This scenario provides an example job flow in which the job_terminator
attribute is defined for a job in a box job.
The box job daily_accounts runs every day at 3:00 a.m. It contains two jobs:
daily_receipts
Processes receipts. This job runs when daily_accounts starts because it
daily_payables
Processes payables. This job runs when daily_accounts starts because it
has no other starting conditions. Because daily_payables includes a
job_terminator attribute, daily_account is terminated if this job fails.
A third job, daily_balance, is not contained in daily_accounts and runs only if
both daily_receipts and daily_payables complete successfully.
Because daily_accounts can only complete successfully if both of the jobs it
contains complete successfully, the failure of daily_receipts causes
daily_accounts to fail. This in turn triggers the job_terminator attribute in
daily_payables, which terminates the job if the box that contains it fails.
130 User Guide
Box Job Logic 131
Job Flow with Box Terminator Attribute

This scenario provides an example job flow in which the box_terminator
attribute is defined for jobs in a box job.
The box job daily_accounts runs every day at 3:00 a.m. It contains two jobs:
daily_receipts
Processes receipts. This job runs when daily_accounts starts because it
has no other starting conditions. Because daily_receipts includes a
box_terminator attribute, daily_accounts will be terminated if this job fails.
daily_payables
Processes payables. This job runs when daily_accounts starts because it
has no other starting conditions. Because daily_payables includes a
box_terminator attribute, daily_accounts will be terminated if this job fails.
A third job, daily_balance, is not contained in daily_accounts and will run only
if both daily_receipts and daily_payables complete successfully.
132 User Guide
Box Job Logic 133
Advanced Job Flows
Advanced Job Flows

This section contains examples to help explain the flow of box jobs and the
jobs they contain in advanced situations. These scenarios help provide a
clearer understanding of advanced job flow concepts.
Job Flow with Time Conditions Running on the First of the Month
This scenario is an example of a job flow that begins on the first of every
month.
134 User Guide
Advanced Job Flows
The job flow consists of three jobs:

job_Fwatch
Waits for a specific file to be created by some mainframe process. This job
runs at 1:00 a.m. on the first of every month and waits for 90 minutes
before giving up.
job_monthly
Re-indexes, organizes, and purges its records based on the file created by
the mainframe. This job runs at 2:00 a.m. on the first of the month only
when job_Fwatch completes successfully.
job_daily
Generates a report. This job runs daily at 3:00 a.m. when job_monthly
completes successfully.
The failure of job_Fwatch causes job_monthly to skip its scheduled run
because job_monthly can only complete successfully if job_Fwatch completes
successfully. Job job_daily only runs if job_monthly completes successfully. By
the same logic, job_daily always runs if job_monthly was able to successfully
run at least once.
Note: The first time the cycle is run (for example, January 1), statuses behave
as expected.
Box Job Logic 135
Advanced Job Flows
Job Flow with Time Conditions Running on the Second of the Month
This scenario builds upon the previous scenario and takes place on the
following day.
On days of the month other than the first, 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 day of the month. As a result, job_daily still runs.
136 User Guide
Advanced Job Flows
Job Flow with Time Conditions Running on the First of the Following Month
This scenario builds upon the previous scenario and takes place on the first
day of the following month.
On the first day of the next month (for example, February 1), the file from the
mainframe fails to arrive in the 90 minute wait time; therefore, job_Fwatch
self-terminates. As a result, job_monthly misses its run for the month.
However, because its event status in the database is still SUCCESS from the
previous month, job_daily is able to run every day this month. When job_daily
runs, it uses the previous month's data leading to invalid reports for the
month.
Box Job Logic 137
Advanced Job Flows
Resetting a Job Flow with Time Conditions Through INACTIVE Status Change
This scenario builds upon the previous scenario and takes place on the last day
of the month.
To fix time-related statuses, you can use a sendevent command to change
them to INACTIVE at the end of their valid interval. You can create another job
to do this automatically.
Changing the status of job_monthly to INACTIVE at the end of every month
allows job_daily to run only in the months that job_monthly completes
successfully. In the following example, when job_Fwatch fails, job_monthly
will not run, job_daily will not run because its status has been reset to
INACTIVE.
138 User Guide
Advanced Job Flows
Resetting a Job Flow with Time Conditions Through Box Job

This scenario builds upon the previous scenarios and takes place on the first
day of the month.
Instead of issuing a sendevent command to change the status of the jobs, you
can put the monthly process in a box, and set the box_failure or
box_terminator attribute appropriately.
The job flow now consists of a box called box_monthly that runs at 1:00 a.m.
on the first day of every month with the following jobs:
job_Fwatch
Waits for a specific file to be created by some mainframe process. This job
runs at 1:00am on the first of every month and waits for 90 minutes
before giving up.
job_monthly
Re-indexes, organizes, and purges its records based on the file created by
the mainframe. This job runs at 2:00 a.m. on the first of the month only
when job_Fwatch completes successfully.
Box Job Logic 139
Advanced Job Flows
A third job, job_daily, is not contained in box_monthly and runs only if

job_Fwatch and job_monthly complete successfully.
The failure of job_Fwatch causes box_monthly to terminate because
box_monthly can only complete successfully if both of the jobs it contains
complete successfully. This in turn triggers the job_terminator attribute in
job_monthly, which terminates the job if the box that contains it fails.
140 User Guide
Chapter 6: Defining Jobs Using JIL

JIL Syntax Rules (see page 142)
JIL Subcommands (see page 144)
User-Defined Job Types (see page 146)
Submit a Job Definition in a JIL Script (see page 148)
Submit a Job Definition in JIL Interactive Mode (see page 149)
Running a Job After Using JIL (see page 150)
How a Simple Command Job Is Created (see page 151)
How a File Watcher Job Is Created (see page 152)
How a Dependent Command Job Is Created (see page 153)
How a Box Job Is Created (see page 155)
How Job Groupings Are Created (see page 156)
How Machines Are Added (see page 157)
How an Existing Job Is Put in a Box (see page 159)
How Time Dependencies Are Set (see page 160)
Delete a Job (see page 162)
Delete a Box Job (see page 162)
Specifying One-Time Job Overrides (see page 163)
Example JIL Script (see page 166)
Defining Jobs Using JIL 141
JIL Syntax Rules
JIL Syntax Rules

JIL scripts contain one or more JIL subcommands and one or more attribute
statements; these elements constitute a job definition. When writing a JIL
script, you must follow these syntax rules:
Rule 1
Each subcommand uses the following form.
sub_command:job_name
sub_command
Defines a JIL subcommand.
job_name
Defines the name of the job on which to act.
Rule 2
You can follow each subcommand with one or more attribute statements.
These statements can occur in any order, and are applied to the job
specified in the preceding subcommand. A subsequent subcommand
begins a new set of attributes for a different job. The attribute statements
have the following form:
attribute_keyword:value
attribute_keyword
Defines a valid JIL attribute.
value
Rule 3
You can enter multiple attribute statements on the same line, but you
must separate the attribute statements with at least one space.
Rule 4
A box job definition must exist before you can add jobs to it.
142 User Guide
JIL Syntax Rules
Rule 5
Valid value settings can include any of the following characters:
Uppercase and lowercase letters (A-Z, a-z)
Hyphens (-)
Underscores (_)
Numbers (0-9)
Colons (:), if the colon is escaped with quotation marks (" ") or a
preceding backslash (\)
The at character (@)
Rule 6
Because JIL parses on the combination of a keyword followed by a colon,
you must use escape characters (a backslash) with any colons used in an
attribute statement's value. For example, to define the start time for a job,
specify 10\:00.
Note: When specifying drive letters in commands, you must use escape
characters with the colon (:). For example, "C:\tmp" and C\:\tmp are
valid; C:\tmp is not.
Rule 7
Use one of the following methods to indicate comments in a JIL script:
To comment an entire line, put a pound sign (#) in the first column.
To comment one or more lines, you can use the C programming

syntax for beginning a comment with a forward slash and asterisk (/*)
and ending it with an asterisk and a forward slash (*/). For example:
/* this is a comment */
Rule 8
You can use the blob_input attribute to manually enter multiline text. This
attribute is only valid for the insert_job, update_job, insert_blob, and
insert_glob subcommands. The blob_input attribute has the following
form:
blob_input:auto_blobt this is a multiline text
/auto_blobt
Note: Use the auto_blobt meta-tags to indicate the beginning and end of
multiline text. JIL interprets every character input between the auto_blobt
meta-tags literally. This implies that JIL does not enforce any of the
previously discussed rules for text entered in an open auto_blobt
meta-tag.
JIL Subcommands
JIL Subcommands
You can use the following JIL subcommands to create, modify, override, or
delete Unicenter AutoSys JM assets:
insert_job
Adds a new command, box, or file watcher job definition to the database.
update_job
Updates an existing command, box, or file watcher job definition in the
database.
delete_job
Deletes a specified command, box, or file watcher job from the database.
If the specified job is a box job, the box job is deleted and the jobs in the
box become stand-alone jobs.
delete_box
Deletes a specified box job and all the jobs in that box from the database.
override_job
Defines a one-time override of specified attributes to apply to the next run
of a job.
insert_machine
Adds a new real or virtual machine definition to the database.
delete_machine
Deletes the specified real or virtual machine definition from the database.
insert_monbro
Adds a new monitor or report definition to the database.
update_monbro
Updates an existing monitor or report definition in the database.
delete_monbro
Deletes the specified monitor or report definition from the database.
insert_job_type
Adds a new job type definition to the database. This is the only way to
define a job type.
update_job_type
Updates an existing job type definition in the database. You can use this
command to change the values of the command and description attributes.
144 User Guide
JIL Subcommands
delete_job_type
Verifies that no jobs are currently defined with the specified job type, then
deletes the specified job type definition from the database.
insert_xinst
Adds a new external instance definition to the database.
update_xinst
Updates an existing external instance definition in the database.
delete_xinst
Deletes the specified external instance definition from the database.
insert_blob
Adds a new blob definition associated with an existing job.
delete_blob
Disassociates a blob definition from an existing job and deletes the blob
from the database.
insert_glob
Adds a new glob definition referenced by a given name.
delete_glob
Deletes the specified glob definition from the database.
Note: Blobs and globs can only contain the following characters: A-Z, a-z, and
0-9.
User-Defined Job Types

Unicenter AutoSys JM lets you define custom job types if the functionality
provided by box, command and file watcher job types is not sufficient. A
custom job type is similar to a command job except that each custom job type
is associated with a custom program/script/adaptor. For example, a new job
type can be defined to perform FTP. For this to work, a custom
program/script/adaptor has to be provided which does FTP by taking a few
arguments. When a job with custom job type is defined, there is no need to
provide a command for that job. For example, if we define FTP job type as 'f',
a custom program/script/adaptor has to be provided as part of the definition
of type f.
insert_job_type:f
command: /home/scripts/myftp
When jobs of type FTP are defined, all of them execute /home/scripts/myftp
when those jobs are run.
insert_job: ftp_test
job_type: f
std_in_file: /tmp/ftp_params
When a new version of FTP script is used, only the definition of job type has to
be modified.
You can use the following jil commands to create, update, and delete
user-defined job types.
insert_job_type
delete_job_type
update_job_type
Only three attributes are associated with user-defined job types:

job_type
Defines the user-specified job type.
Limits: This value can be a singe-digit number (0-9). In Unicenter WCC,
this value can also be a letter (a-z, except b, c and f).
command
Defines the binary to associate with the job type.
Limits: This value can be up to 510 characters in length.
The command attribute is optional. If you do not specify the command
attribute, the job type uses the command attribute of the job definition. If
you specify the command attribute, it overrides the jobs command
attribute.
146 User Guide
description
Defines a description of the job type.
Limits: This value can be up to 256 characters in length.
Any other attribute is rejected and JIL fails.
Note: You must define a job type before you can use it to define a job. For
more information, see the Reference Guide.
Example: Use insert_job_type to Add a User-Defined Job Type
This example creates an association between a user-defined job type and an
executable.
insert_job_type: 5
description: Web Service Adapter
command:ws.exe
Example: Use delete_job_type to Delete a User-Defined Job Type

This example verifies that no jobs are currently using the specified job type,
and deletes the job type.
delete_job_type: 5
Example: Use update_job_type to Modify a User-Defined Job Type

This example modifies an existing job type, changing the values of the
description and command attributes.
update_job_type: 5
description: WorldView Adapter
command: wv.exe
Submit a Job Definition in a JIL Script
Submit a Job Definition in a JIL Script

You can include job definitions in a JIL script, which you must submit to the
database before the job it defines can run.
To submit a job definition in a JIL script
1.
Open the instance command prompt associated with the Unicenter

AutoSys JM instance for which you are defining the job.
The instance command prompt is displayed.
2.
Issue the following command to redirect the JIL script file containing the
job definition to the jil command:
jil < script name
Script name
Defines the script to redirect to all the jil command.
The job definitions in the specified script are submitted to the database.
To specify the instance to which to send and apply definitions, use the
-S autoserv_instance argument to the jil command. For single-instance
environments, the command defaults to the only available instance. For the jil
command to work properly, the correct environment variables must be
assigned.
Note: You can also submit job definitions through the Unicenter WCC GUI. For
more information about environment variables, see the Windows or UNIX
Implementation Guide. For more information about the jil command, see the
Reference Guide.
Example: Submit a Job Definition in a JIL Script
This example redirects a file called my_jil_script to the jil command on the
PRD instance of Unicenter AutoSys JM.
jil s PRD < my_jil_script
148 User Guide
Submit a Job Definition in JIL Interactive Mode
Submit a Job Definition in JIL Interactive Mode

You can submit job definitions to the database in JIL interactive mode. You
might do this, for example, if you want to test specific job definitions or if a
job only needs to be run once.
To submit a job definition in JIL interactive mode
1.
Open the instance command prompt associated with the Unicenter

AutoSys JM instance for which you are defining the job.
The instance command prompt is displayed.
2.
Issue the jil command and press Enter.

To specify the instance to which to send and apply definitions, use the -S
autoserv_instance argument to the jil command. For single-instance
environments, the command defaults to the only available instance. For
the jil command to work properly, the correct environment variables must
be assigned.
The JIL command prompt appears.
3.
Enter jil commands and prompts as directed, and enter Exit at the
command prompt when you complete the job definition.
JIL interactive mode ends.
Note: You can also submit job definitions through the Unicenter WCC GUI. For
more information about environment variables, see the Windows or UNIX
Implementation Guide. For more information about the jil command, see the
Reference Guide.
Running a Job After Using JIL
Running a Job After Using JIL

After you submit a job definition to the database, it runs according to the
starting parameters specified in its JIL script. That is, the Scheduler continually
polls the database, and when it verifies that the starting parameters are met it
runs the job.
If a JIL script does not specify any starting parameters for a job, the Scheduler
does not start the job automatically; the job starts only if you issue the
sendevent command.
Example: Run a Job with the sendevent Command
This example assumes that a job named test_install has no starting
parameters specified in its JIL script. The only way to start it is to issue the
following command:
sendevent -E STARTJOB -J test_install
This command tells the Scheduler to start the job named test_install.
150 User Guide
How a Simple Command Job Is Created
How a Simple Command Job Is Created

To create a basic command job, you must define (at a minimum) the
insert_job subcommand with the machine and command attributes. Because
the job_type attribute defaults to c (command), you must also specify it when
defining jobs of a type other than command (for example, box or file watcher
jobs).
Example: Creating a Simple Command Job
This example shows a JIL script that defines a simple command job
named test_run:
insert_job: test_run
job_type: c /*(optional, it is the default) */
machine: tibet
command: "c:\bin\test.bat"
This JIL script instructs Unicenter AutoSys JM to do the following:
Add a new job named test_run.
Define the job as a command job.
Run the job on the Client computer named tibet.
Run the c:\bin\test.bat command.
This example shows a JIL script that defines a simple command job
named test_run:
insert_job: test_run
job_type: c /*(optional, it is the default) */
machine: tibet
command: /bin/touch /tmp/test_run.out
Add a new job named test_run.
Run the UNIX /bin/touch command on the file named /tmp/test_run.out.
How a File Watcher Job Is Created
How a File Watcher Job Is Created

A file watcher job is similar to a command job. However, instead of starting a
user-specified command on a Client computer, a file watcher job starts a
process that monitors for the existence and size of a specific operating system
file. When that file reaches the specified minimum size and is no longer
growing in size, the file watcher job completes successfully, indicating that the
file has arrived.
Example: Creating a File Watcher Job
This example shows a JIL script that defines a file watcher job named
EOD_watch:
insert_job: EOD_watch
job_type: f
machine: tibet
watch_file: /tmp/EodTransFile
watch_interval: 60
watch_file_min_size: 50000
Add a new job named EOD_watch.
Define the job as a file watcher job.
Watch for a file named EodTransFile in the /tmp directory (this file
contains end of day transactions).
Check for the file every 60 seconds.
Check if the file has reached the minimum file size of 50,000 bytes.
When the watched file reaches the specified 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 ends with a SUCCESS status.
152 User Guide
How a Dependent Command Job Is Created

Command jobs can be dependent on the successful completion of other jobs.
The only difference between a dependent command job and a simple
command job is its dependency on another job.
Example: Creating a Dependent Command Job
This example shows a JIL script that defines a dependent command job named
EOD_post. EOD_post depends on the successful completion of the file watcher
job EOD_watch.
insert_job: EOD_post
job_type: c
machine: tibet
condition: success(EOD_watch)
command: $HOME/POST
Add a new job named EOD_post.
Run the job only if the file watcher job named EOD_watch completes with
a SUCCESS status.
Source the /etc/auto.profile file (Unicenter AutoSys JM sources this file by

default), and run the job named POST located in the job owner's home
directory.
Note: Unicenter AutoSys JM lets you specify a time limit in the condition
attribute for use in job dependency evaluations. The job's execution
environment is verified exclusively by the profile, which is sourced immediately
before the job starts. By default, the file /etc/auto.profile, on the Client
computer, is sourced. You can use the profile attribute to override the default
profile.
More information:
How the Agent Sets Job Profiles (see page 91)
Look-Back Conditions
Unicenter AutoSys JM supports look-back conditions. You can use look-back
conditions to base dependencies for a job on the last run of another job. The
last run is defined by the ending time of the last successful run of a job. If the
job has run with the specified result, the condition or predecessor is satisfied
and the job starts. If not, the condition is not satisfied and the job for which
the look-back condition is defined does not start.
To specify a look-back dependency, enter the job name followed by a comma
(,) then HH (hours), period (.) and MM (minutes).
Example: Specifying Look-Back Conditions
This example shows a job definition with look-back conditions.
In the following job definition, the command job test_sample_04 can only start
if all of the following conditions are met:
The last run of test_sample_01 completed successfully during the last 12

hours.
The last run of test_sample_02 completed with a FAILURE status during

the last 24 hours.
The last run of test_sample_03 completed successfully at any time.
insert_job: test_sample_04
machine: localhost
command: sleep 10
condition: success(test_sample_01,12.00) AND failure(test_sample_02,24.00) AND
success(test_sample_03)
154 User Guide
How a Box Job Is Created
How a Box Job Is Created

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) for all the jobs in the box to
start running.
Assume you want to schedule a group of jobs to start running when a file
watcher job completes successfully. Instead of making each job dependent on
the file watcher job, you can create a box job that is dependent on the file
watcher job, remove the file watcher job dependency from the individual jobs,
and put all of those jobs in the box. When the file watcher job completes
successfully, the box job starts, which in turn starts all of the jobs it contains.
Example: Creating a Box Job
This example shows how to define a box job named EOD_box that depends on
the success of a file watcher job to run:
insert_job: EOD_box
job_type: b
condition: success(EOD_watch)
Add a new job named EOD_box.
Define the job as a box job.
Run the job only if the file watcher job named EOD_watch completes with
a SUCCESS status.
More information:
Box Job Logic (see page 119)
How Job Groupings Are Created
How Job Groupings Are Created

Box jobs provide one method of grouping jobs, but are typically used when all
the jobs in the box share the same starting condition. Unicenter AutoSys JM
provides the group and application attributes so you can logically group sets of
jobs and boxes with unrelated starting conditions or dependencies. By
specifying both group and application attributes in a job definition, you can
make the job belong to both a group logical set and an application logical set.
Example: Associate Jobs with Groups and Applications
This example shows how you can associate jobs with specific groups and
applications to control processing.
Assume you want to create a set of jobs that run a suite of applications called
EmployeePay that is used to manage employee salaries. The Accounting and
Human Resources groups each have their own jobs defined to use the
EmployeePay applications. The following JIL script defines two jobs
(HR_payroll and ACCT_salaryreport):
insert_job: HR_payroll
job_type: c
...
group: HumanResources
application: EmployeePay
insert_job: ACCT_salaryreport
job_type: c
...
group: Accounting
application: EmployeePay
Add two new command jobs (HR_payroll and ACCT_salaryreport).
Associate job HR_payroll with the HumanResources group and the

EmployeePay application.
Associate job ACCT_salaryreport with the Accounting group and the

EmployeePay application.
To run a job associated with the EmployeePay application, enter the following:
sendevent -e STARTJOB -I EmployeePay
To run a job associated with the Accounting group, enter the following:
sendevent -e STARTJOB -B Accounting
156 User Guide
How Machines Are Added
To run a job associated with both the EmployeePay application and Accounting
group (intersection of both sets), enter the following:
sendevent -e STARTJOB -I EmployeePay -B Accounting

The insert_machine subcommand adds a new machine definition to the
database for one of the following:
Real machine
Virtual machine
Unicenter NSM
Universal Job Management Agent
You can specify the machine type as r (real UNIX), v (virtual), n (real or
virtual Windows), u (Unicenter NSM or UUJMA), c (Unicenter AutoSys JM
Connect), l (legacy real UNIX), or L (legacy real Windows). The component
real machines in a virtual machine definition can be UNIX or Windows
machines or a mix of both.
If you are defining a virtual machine, follow the insert_machine subcommand
with one or more machine attributes that specify real machines.
You can specify any machine accessible through the TCP/IP protocol in
the machine attribute of a job; you need not explicitly define it using the
insert_machine command. However, any undefined machine has a default
factor value of 1.0 and no max_load value, meaning that there is no limit on
the job load assigned to it.
You can specify any machine defined in the /etc/hosts file on the
machine running the Scheduler in the machine attribute of a job; you need not
explicitly define it using the insert_machine command. However, any
undefined machine has a default factor value of 1.0 and no max_load value,
meaning that there is no limit on the job load assigned to it.
Example: Define a Virtual Machine to Include Two Real Machines

This example defines a virtual machine virtual_b to include two real Windows
machines (cheetah with a factor value of 5.0 and a max_load value of 400,
and wv with a factor value of 2 and a max_load value of 15):
insert_machine: virtual_b
type: n
machine: cheetah max_load: 400 factor: 5.0
machine: wv max_load: 15 factor: 2
Note: In this example, the two real machines (when specified in a job
definition through the virtual machine) vary considerably in capacity from a
scheduling standpoint. However, when these machines are explicitly specified
by name in a job definition, the factor and max_load attributes defined here
have no effect; they only have these values when used through the virtual
machine.
158 User Guide
How an Existing Job Is Put in a Box
How an Existing Job Is Put in a Box

To place an existing job in a box, verify that the job is not running, and do
either of the following:
Use the update_job subcommand to change the current job definition.
Use the delete_job subcommand to delete the current job definition, and
use the insert_job subcommand to redefine the job.
This method is useful when the job definition contains many non-default
attributes that you want to deactivate instead of resetting them. However,
if you delete and redefine the job, you must redefine any non-default
attributes you want to keep from the previous definition.

Example: Put an Existing Job in a Box
This example shows how to update the definition of an existing job to include
it in a box.
The following JIL script uses the update_job subcommand to change the
EOD_post job to put it in the EOD_box job:
update_job: EOD_post
condition: NULL
box_name: EOD_box
Update the job named EOD_post.
Remove the previously defined starting conditions from the job definition,
so the job inherits the starting conditions of the box in which it resides.
Put the job named EOD_post in the box named EOD_box.
How Time Dependencies Are Set

If you do not define starting conditions for a job, it only runs when you issue a
sendevent command for it. You can set time dependencies for a job so that it
runs automatically on specific days and at specific times.
Example: Set Time Dependencies for a Job
This example shows how to use the date_conditions, days_of_week, and
start_times attributes to set time dependencies for a job.
To set the existing job test_run 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 could modify the job using the following JIL script:
update_job: test_run
date_conditions: y
days_of_week: mo, we, fr
start_times: "10:00, 14:00"
Update the job named test_run.
Activate the conditions based on date.
Set the job to run on Mondays, Wednesdays, and Fridays.
Start the job at 10:00 a.m. and 2:00 p.m. on each of the specified days.
The times shown in the sample script are surrounded by quotation marks
because they contain a colon. You can also use a backslash (\) as an escape
character for the colon, as the following example shows:
start_times: 10\:00, 14\:00
Note: If a job runs daily at the same time (for example, 12:00) and you edit
the job definition and save it at 11:59, the job will not run until the next day
at 12:00.
When you save a start time job definition to the database within one minute of
the specified start time, the start time is placed in the future (that is,
tomorrow). However, if the start time is two minutes or more from the save
time, the job runs at the next occurrence of the specified start time (that is,
today).
160 User Guide
Example: Base Time Settings on a Specific Time Zone

Use the timezone attribute to base the time settings for a job on a specific
time zone. If you specify a time zone that includes a colon, you must surround
the time zone name with quotation marks, as in the following example:
timezone: "IST-5:30"
Example: Run a Job Every Day

To run the job every day, instead of only on specific days, specify the all value
instead of listing the individual day values. For example:
days_of_week: all
Example: Schedule a Job to Run on Specific Dates

To schedule the job for specific dates, instead of specific days of the week,
specify a custom calendar. Use the autocal_asc command to define the
calendar, and then use the run_calendar attribute to specify the calendar
name (for example, weekday_cal) in the job definition. For example:
run_calendar: weekday_cal
Example: Exclude a Job from Running on Specific Dates

To specify a custom calendar that defines the days on which the job should not
run, use the autocal_asc command to define the calendar, and use the
exclude_calendar attribute to specify the calendar name (for example,
holiday_cal) in the job definition. For example:
exclude_calendar: holiday_cal
Example: Schedule a Job to Run at Specific Times Every Hour

To run the job at specific times every hour instead of at specific times of the
day, use the start_mins attribute to specify the minutes past every hour that
the job should run. For example, to run a job at 15 minutes after and 15
minutes before each hour, add the following statement to the job definition:
start_mins: 15, 45
Delete a Job
Delete a Job
To delete a job, enter the delete_job subcommand followed by the name of
the job to delete. For example, to delete the job test_run, you would enter the
following:
delete_job: test_run
When JIL is in job verification mode (the default), the delete_job subcommand
scans the ujo_job_cond table and notifies you of any dependent conditions for
the deleted job before deleting it.
Delete a Box Job

To delete a box and every job it contains, enter the delete_box subcommand
followed by the name of the box job to delete. For example, to delete the box
EOD_box and every job in it, you would enter the following:
delete_box: EOD_box
To delete a box without deleting the jobs it contains, enter the delete_job
command followed by the name of the box job to delete. The jobs in the box
become stand-alone jobs. For example, to delete the box EOD_box without
deleting the jobs in it, you would enter the following:
delete_job: EOD_box
162 User Guide
Specifying One-Time Job Overrides

You can use the override_job subcommand to specify an override that changes
the behavior of a specific job during its next run. Job overrides are applied
only once. If a RESTART event is generated because of system problems,
Unicenter AutoSys JM reissues a job override until the job actually runs once,
or until the maximum number of retries limit is met. After this, Unicenter
AutoSys JM discards the override.
You can modify the following attributes in a job override:
auto_hold
command
condition
date_conditions
days_of_week
exclude_calendar
machine
max_run_alarm
min_run_alarm
n_retrys
profile
run_calendar
run_window
start_mins
start_times
std_err_file
std_in_file
std_out_file
term_run_time
watch_file
watch_file_min_size
watch_interval
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 let you set the start_times attribute to NULL because removing the start
condition makes the job definition invalid (no start time could be calculated).
Note: The maximum number of job restarts after system or network

failure is specified in the Max Restart Trys field on the Unicenter AutoSys
Scheduler screen in the Administrator.
Note: The maximum number of job restarts after system or network

failures is specified by editing the $AUTOUSER/config.$AUTOSERV file.
MaxRestartTrys is a variable in the Unicenter AutoSys JM instance
configuration file.
One-time job overrides are applied to jobs restarted due to system problems,
but are not applied to jobs restarted because of application failures.
System problems include the following:
Machine unavailability
Media failures
Insufficient disk space
Application failures include the following:
164 User Guide
Inability to read or write a file
Command not found
Exit status greater than the defined maximum exit status for success
Various syntax errors
How Job Overrides Are Set

To set job overrides, use the override_job subcommand to specify the job and
attributes to override. You can also temporarily delete a job attribute in this
manner.
Example: Define a One-time Override for a Job
This example shows how to define a one-time job override. The following
script runs the job RunData with no conditions (where some had been
previously specified) and outputs the results to a different output file:
override_job: RunData
condition: NULL
std_out_file: "C:\tmp\SpecialRun.out"
override_job: RunData
condition: NULL
std_out_file: "tmp\SpecialRun.out"
Example: Cancel a Job Override Before it Runs

This example shows how to cancel a job override before it runs. To cancel
overrides for a job, enter the override_job subcommand followed by the job
name and the delete parameter. For example:
override_job: RunData delete
Note: After you submit a JIL script to the database, you cannot view the script
or edit an override. To change the override values, you must submit another
JIL script with new values or use the Unicenter WCC Job Editor. However, the
original override remains stored in the ujo_overjob table in the database.
Example JIL Script
Example JIL Script

The following is a complete example of a JIL script. It incorporates the creation
and use of a command job, a file watcher job, and a box job to address this
processing scenario:
A file named /DOWNLOAD/MAINFRAME/SALE.RAW is expected to arrive

from the mainframe some time after 2:00 a.m.
When the file arrives, it is processed by the command file named

filter_mainframe_info, and the results are sent as an output to the file
named /DOWNLOAD/MAINFRAME/SALES.SQL.
When the above functions are completed, the file named

/DOWNLOAD/MAINFRAME/SALES.SQL (containing SQL statements) is run.
# Example of a Machine
insert_machine: lowgate
type: r
# Example of Jobs
insert_job: Nightly_Download
job_type: b
date_conditions: yes
days_of_week: all
start_times: "02:00"
insert_job: Watch_4_file
job_type: f
box_name: Nightly_Download
watch_file: /DOWNLOAD/MAINFRAME/SALES.RAW
machine: lowgate
insert_job: filter_data
job_type: c
condition: success(Watch_4_file)
command: filter_mainframe_info
machine: lowgate
std_in_file: /DOWNLOAD/MAINFRAME/SALES.RAW
insert_job: parse_data
job_type: c
condition: success(filter_data)
machine: lowgate
command: isql -U mutt -P jeff
std_in_file: /DOWNLOAD/MAINFRAME/SALES.SQL
std_out_file: /DOWNLOAD/MAINFRAME/SALES.SQL
std_err_file: /LOG/FilterMFLog.err/
insert_job: update_DBMS
job_type: c
166 User Guide
Example JIL Script
condition: success(filter_data)
machine: lowgate
command: isql -U mutt -P jeff
std_in_file:/DOWNLOAD/MAINFRAME/SALES.SQL
Chapter 7: Binary Large Object

Definitions
Binary Large Objects (see page 170)
Types of Blobs (see page 172)
Job Blobs (see page 172)
Global Blobs (see page 173)
Manage Blobs Using JIL (see page 173)
Blob Attributes (see page 174)
Create Input Job Blobs (see page 175)
Delete Job Blobs (see page 176)
Create Global Blobs (see page 176)
Delete Global Blobs (see page 177)
Use Blobs in Job Definitions (see page 178)
Generate Blob Reports Using Autorep (see page 180)
Binary Large Object Definitions 169
Binary Large Objects

Binary Large Objects (blobs) are binary data of variable length. Unicenter
AutoSys JM supports blobs in job definitions, and after they are defined, they
are stored in the database. This allows the blob data to be shared by jobs
running on multiple computers.
To understand the advantages of using blobs in Unicenter AutoSys JM
environment, refer to the following example, which explains the process that is
used to share data amongst the jobs that are running on a single computer:
1.
When the jobs are running on a single computer, you can define a
command job to run a program that outputs the data to a file using the
std_out_file attribute.
2.
When the job is completed, a file is created in the location specified by the
std_out_file attribute.
3.
All the other jobs that depend on this output data can access this file.
4.
You can also define a second command job to run a program that reads
the output data of the previous job, by specifying the file name in the
std_in_file attribute.
5.
This second command job opens the file specified by the std_in_file
attribute and passes the data to the program, allowing it to complete
successfully.
Based on this example, as the output data is stored in a file on one computer,
it is not available to all the other jobs that are scheduled to run on other
computers. However, the use of blobs allows the data that is saved as output
by a job on one computer to be shared by all the other jobs that are running
across multiple computers.
Also, you can define a command job to run a program that uploads the output
data to the database as a blob using the std_out_file attribute. You can also
define a second command job to run a program that reads the blob data of the
previous job using the std_in_file attribute. The second command job
downloads the blob data specified by the std_in_file attribute from the
database and passes the data to the program, allowing it to complete
successfully.
170 User Guide
Blob data can be of the following types:

Binary Data
Requires a program that understands the format of the data to interpret
the bytes in binary data. For example:
Multimedia files which include the following:
Images
Video files
Audio files
Textual Data
Requires an operating system that can interpret the bytes in textual data,
which contains the characters that conform to the ASCII standard.
Note: Some operating systems handle the specification of a new line in
the textual data differently. In this instance, you must convert the
necessary textual data when it is copied across operating systems.
Unicenter AutoSys JM allows you to specify the type of blob data that is
being used and converts the textual data when it is downloaded across
multiple operating systems.
Types of Blobs
Types of Blobs
Unicenter AutoSys JM supports the following types of blobs:
Job blobs
Global blobs
Job Blobs
Job blobs are associated with an existing Unicenter AutoSys JM job and are
referenced by the job name. Job blobs can either be created at the time of the
job definition or after the job has been defined. They are deleted when the job
is deleted.
There are three types of job blobs, which include the following:
Input
Contains the input data that is reserved for the job to which they are
associated in textual data format.
Output
Stores the program output messages of a running job in textual or binary
data format.
Error
Stores the error messages of a running job in textual or binary data
format.
Input Job Blobs

Input blobs are uploaded to the database using JIL. You can insert an input job
blob multiple times. Each time it is inserted, it acquires a new version number.
When the job starts, the most recent version of the job input blob is used. All
the earlier versions of the blob remain in the database until they are manually
deleted. If you delete an input job blob, only the active version of the input job
blob is deleted. The version which was prior to the deleted version becomes
the new active version.
When you run a job, the Unicenter AutoSys JM Agent downloads the active
version of job's input blob from the database into a temporary file on the
computer. This file is then passed into the standard input of the program that
is executed by the job. When the job completes, the temporary file containing
the input blob data is deleted. The blob in the database, however, is not
deleted and remains as the active version for subsequent job runs.
172 User Guide
Global Blobs
Output and Error Job Blobs

Output and error job blobs store the program output and error messages of a
running job. When you run a job, the Unicenter AutoSys JM Agent creates
temporary files on the computer that are used to capture the standard output
and standard error messages from the program that was executed by the job.
After the job has completed its run, the Agent uploads the files containing the
output data as blobs into the database, overwriting the existing files, and
deletes the temporary files. An output job blob can be used as input by
another job. An error job blob, on the other hand, cannot be used as input by
another job.
Global Blobs
Global blobs are general purpose blobs in textual or binary data format. Like
the Unicenter AutoSys JM global variables, they are referenced by a unique
name. You can either upload the global blobs to the database using JIL or they
can be uploaded by the Unicenter AutoSys JM Agent, after a job has completed
its run. After a global blob is created, it is available to any job as input. Global
blobs remain in the database until they are deleted using JIL.
Manage Blobs Using JIL

The following section describes how to use JIL to do the following:
Upload blobs to the database
Delete blobs from the database
Blob Attributes
Blob Attributes
The following table lists the subcommands and attributes associated with the
definition or destruction of a blob:
Task
Subcommands
Attributes
Create input job blob
insert_job, update_job blob_input or blob_file
Create input job blob
insert_blob
blob_input or blob_file
Delete job blob
delete_blob
blob_type
Create global blob
insert_glob
blob_mode, blob_input, or
blob_file
Delete global blob
delete_glob
The blob_input attribute lets you manually input the contents of a blob
containing textual data. The blob_input attribute has the following format:
blob_input: <auto_blobt>textual data</auto_blobt>
Note: The textual data begins immediately after the auto_blobt XML-style
open tag and may span multiple lines. JIL recognizes the end of the textual
data when it reads the auto_blobt XML-style end tag. This implies that the
literal character string </auto_blobt> cannot form part of the blob_input
value. If you want to include this character string as part of the textual blob
data, use the blob_file attribute.
The blob_file attribute allows the user to specify the location and name of a file
on the computer that serves as the input job blob or global blob file. The
blob_file attribute has the following format:
blob_file: filename
Note: If the blob_file attribute is used to specify an input job blob through the
insert_job or insert_blob subcommand, the file is interpreted as a text-based
file.
174 User Guide
Create Input Job Blobs
Create Input Job Blobs

To create an input job blob in the database using JIL, do the following:
Upload an input job blob at the time of the definition of the associated job.
Upload an input job blob after you have defined the job.
Note: Input job blobs are referenced by the name of the job.
To create an input job blob at the time of the definition of the associated job,
use the insert_job JIL subcommand and specify either the blob_input or
blob_file attributes, as follows:
insert_job: test_job_with_blob
job_type: c
command: sleep 60
machine: juno
owner: jerry@juno
permission:
std_in_file: $$blobt
blob_input: <auto_blobt>multi-lined text data for job blob
</auto_blobt>
or
blob_file: /test_job_with_blob_file.txt
To create an input job blob after you have defined the job, use the insert_blob
JIL subcommand and specify either the blob_input or blob_file attributes, as
follows:
insert_blob: test_job_with_blob
</auto_blobt>
or
blob_file: /test_job_with_blob_file.txt
JIL interprets the file name that is specified in the blob_file attribute as a file
that contains the textual data and performs a conversion of the new line
character. JIL also displays the version number of the most recent input job
blob.
Delete Job Blobs
Delete Job Blobs

You can use the JIL delete_blob subcommand to delete the following:
Active version of the input job blob
Output and error job blobs
You must specify whether to delete the job input or output blob data using the
blob_type attribute.
Note: Job blobs are referenced by the name of the job. JIL displays the
version number of the most recent job input blob.
To delete the most recent version of the input job blob, use the delete_blob
JIL subcommand and specify the blob_type attribute with the value of input,
as follows:
delete_blob: test_job_with_blob
blob_type: input
To delete the output and error job blobs, use the delete_blob JIL subcommand
and specify the blob_type attribute with the value of output, as follows:
delete_blob: test_job_with_blob
blob_type: output
Create Global Blobs

You can use the JIL insert_glob subcommand to upload blobs containing
textual or binary data.
As the global blobs are not associated with a job, you must do the following:
Provide a unique identifier.
Specify the mode of the blob data that is being used in the blob_mode
attribute.
Note: If you use the insert_glob JIL subcommand using the same name as an
existing global blob, the blob data is reinserted into the database. In this case,
the original blob data is deleted and the new blob data takes its place.
176 User Guide
Delete Global Blobs
To create a global blob containing textual data, use the insert_glob JIL
subcommand and specify the blob_mode attribute with a value of text and
either the blob_input or blob_file attributes, as follows:
insert_glob: my_text_global_blob
blob_mode: text
</auto_blobt>
or
blob_file: /my_text_global_blob_file.txt
Note: JIL interprets the file name that is specified in the blob_file attribute as
a file that contains textual data and performs a conversion of the new line
character.
To create a global blob containing binary data, use the insert_glob
subcommand and specify the blob_mode attribute with a value of binary and
the blob_file attribute, as follows:
insert_glob: my_binary_global_blob
blob_mode: binary
blob_file: /my_binary_global_blob_file
Note: You cannot use the blob_input attribute to create a global blob that
contains the binary data.
Delete Global Blobs

You can use the JIL delete_glob subcommand to delete the existing global
blobs.
Note: You must provide a unique identifier because global blobs are not
associated with a job.
To delete a global blob, use the delete_glob JIL subcommand and provide the
name of an existing global blob, as follows:
delete_glob: my_global_blob
Use Blobs in Job Definitions

You can use the std_in_file, std_out_file, and std_err_file attributes of the JIL
insert_job, update_job, or override_job subcommands to reference blobs in
addition to files. Based on the keyword values you specify for these attributes,
Unicenter AutoSys JM downloads a blob for input or uploads a jobs output as
blob to meet the jobs needs.
The keywords are explained in the subsequent sections.
std_in_file Attribute
The keywords that are supported by the std_in_file attribute include the
following:
$$blobt
Uses the input job blob of the current job as input and treats the blob data
as textual data.
$$blob.<job name>
Uses the output job blob of the specified job as input and treats the blob
data as binary data.
$$blobt.<job name>
Uses the output job blob of the specified job as input and treats the blob
data as textual data.
$$glob.<global blob name>
Uses the specified global blob as input and treats the blob data as binary
data.
$$globt.<global blob name>
Uses the specified global blob as input and treats the blob data as textual
data.
Note: You cannot use the keyword $$blob to specify the use of the current
job's input blob.
To define a job that uses the output blob of its previous run as input
178 User Guide
1.
Define the job so that the job's name is in the std_in_file attribute using
either the $$blob.<job name> or $$blobt.<job name> keyword.
2.
Apply a one-time override of the std_in_file attribute, so that the job reads
from a local file on the computer on its first run.
std_out_file and std_err_file Attributes

The keywords that are supported by the std_out_file and std_err_file
attributes include the following:
$$blob
Uploads the output or error of the current job as a job blob and treats the
data as binary data.
$$blobt
Uploads the output or error of the current job as a job blob and treats the
data as textual data.
$$glob.<global blob name>
Uploads the output or error of the current job as a global blob with the
specified name and treats the data as binary data.
$$globt.<global blob name>
Uploads the output or error of the current job as a global blob with the
specified name and treats the data as textual data.
Note:
You cannot append data to an existing job or global blob.
Unicenter AutoSys JM does not support the use of > or >> character
strings in the std_out_file or std_err_file attributes.
Existing blob data is overwritten with the new data after the job run is
completed.
Generate Blob Reports Using Autorep

You can use the autorep utility to report on and download the input job blobs
and global blobs. To export the job definition using the autorep J <jobname>
-q option includes exporting all versions of that jobs input blob. If a download
path is not specified, the contents of all input job blobs are displayed along
with the job definition. Otherwise, autorep downloads the input blob to the
specified directory and displays the input blob file names numbered by version
along with the job definition. Reports generated against one or more global
blobs are extracted in binary format unless otherwise specified using the a
command line parameter. If a download path is not specified, autorep
downloads the global blob into a temporary directory.
Options specific to blob and glob data include the following:
-z globname
Specifies a glob name or mask whose contents are to be extracted. ALL
may be specified to extract all globs. Wildcard characters % and _ are also
supported.
-a
Specifies that the global blob can be downloaded as textual data.
-f outdir
Specifies the directory name where input job blobs or global blobs are
extracted to.
Default:
The directory represented by environment variable %TEMP%.
The /tmp directory.
Note: For more information about autorep reports, job input, and global blobs,
see the Reference Guide.
180 User Guide
Example: Export Job Definition with Input Blobs

This example uses the autorep command to export a job definition:
autorep -J ALL -q
The output might resemble the following:

insert_job: test_job
job_type: c
command: sleep 60
machine: juno
owner: jerry@ca
permission: gx,ge,wx
alarm_if_fail: 1
If the job has one or more input blobs tied to it, in addition to the job
definition, the autorep command extracts each of the job blob definitions, and
the output might resemble the following:
job_type: c
command: sleep 60
machine: juno
owner: jerry@juno
permission:
alarm_if_fail: 1
/* -- test_job_with_blob:insert_blob #1 -- */
blob_input: <auto_blobt>multi-lined text data for job blob 1
</auto_blobt>
blob_input: <auto_blobt> multi-lined text data for job blob 2
</auto_blobt>
blob_input: <auto_blobt> multi-lined text data for job blob 3
</auto_blobt>
You can also specify a location to download the blobs using the -f parameter
as follows:
autorep -J ALL -q -f /myblobsdir
The output might resemble the following:

job_type: c
command: sleep 60
machine: juno
owner: jerry@juno
permission:
alarm_if_fail: 1
blob_file: /myblobsdir/test_job_with_blob_1.txt
Example: Generate a Report for All Global Blobs

This example generates a report that downloads the contents of all global
blobs to the location /myblobsdir as binary data:
autorep -z ALL -f /myblobsdir
The report might resemble the following:

Glob Name
File Name
____________
_____________________________
MYGLOB
/myblobsdir/MYGLOB
REPORT_CHART
/myblobsdir/REPORT_CHART
ARCHIVED_DATA
/myblobsdir/ARCHIVED_DATA
JOB_SNAPSHOT
/myblobsdir/JOB_SNAPSHOT
This example generates a report that downloads the contents of all global
blobs to the location /myblobsdir as text data:
autorep -z ALL -f /myblobsdir -a
The report might resemble the following:

Glob Name
___________
182 User Guide
File Name
__________________________________
MYGLOB
/myblobsdir/MYGLOB.txt
REPORT_CHART
/myblobsdir/REPORT_CHART.txt
ARCHIVED_DATA
/myblobsdir/ARCHIVED_DATA.txt
JOB_SNAPSHOT
/myblobsdir/JOB_SNAPSHOT.txt
Chapter 8: Machines
Real Machines (see page 183)
Virtual Machines (see page 184)
Defining Machines (see page 184)
Machine Definitions (see page 189)
Machine Status (see page 194)
Load Balancing (see page 197)
Forcing a Job to Start (see page 200)
Queuing Jobs (see page 200)
User-Defined Load Balancing (see page 206)
Real Machines
A real machine is any network host that meets the following criteria:
It has been identified in the appropriate network so that Unicenter AutoSys

JM can access it.
It has undergone an Agent software installation so that Unicenter AutoSys

JM can run jobs on it.
Unless the machine is localhost, it has been defined to Unicenter AutoSys

JM as a real machine using JIL.
A real machine must meet these conditions to run jobs. However, for
Unicenter AutoSys JM to perform intelligent load balancing and queuing while
running jobs, it must know the relative processing power of the various real
machines. Unicenter AutoSys JM uses the virtual machine logical construct to
provide both load balancing and queuing.
Machines 183
Virtual Machines
Virtual Machines
A virtual machine is comprised of one or more real machines. By defining
virtual machines to Unicenter AutoSys JM and then submitting jobs to run on
those machines, you can specify the following:
Run-time resource policies (or constraints) at a high level.
That Unicenter AutoSys JM automatically runs those policies in a

multi-machine environment.
Note: Previous releases of Unicenter AutoSys JM required that all machines in

a virtual machine be of the same type. That is no longer necessary. However,
virtual machines can never contain machines of type u (Unicenter NSM or
Unicenter Universal Job Management Agent) or type c (Unicenter AutoSys JM
Connect).
Defining Machines
You can use machine attribute statements in a JIL script to define both real
and virtual machines. The following JIL subcommand defines a real or virtual
machine:
insert_machine: machine_name
Note: You can only define real and virtual machines using JIL. There is no
Unicenter WCC GUI interface for defining real and virtual machines.
You can use the following JIL attributes to define machines:
type
Specifies a machine type, which can be one of the following:
r for UNIX real
v for UNIX and Windows virtual
n for Windows real
u for Unicenter NSM or Unicenter Universal Job Management Agent
c for Unicenter AutoSys JM Connect
l for a legacy (real) UNIX machine
L for a legacy (real) Windows machine
machine
Defines the name of a real machine to use as a component of a virtual
machine.
184 User Guide
Defining Machines
max_load
Defines the maximum load (in load units) that a machine can reasonably
handle. This attribute is used for load balancing and is only valid in a real
machine definition.
factor
Defines a factor to multiply by a real machine's available CPU cycles to
verify the relative available CPU cycles. This attribute is used for load
balancing and is only valid in a real machine definition.
You need only define a real or virtual machine if it meets one of the following
criteria:
It requires a max_load or factor attribute to be set for it.
It will be included in a virtual machine.
You must define virtual machines before you can use them.
Load balancing and queuing is possible only if real and virtual machines have
been defined to Unicenter AutoSys JM using these machine attributes. The
max_load and factor attributes, used when defining real machines, are key for
load balancing and queuing.
Machines 185
Defining Machines
Specifying Machine Load (max_load)

The max_load attribute is only valid in a real machine definition. It defines the
maximum load (in load units) that a real machine can reasonably handle. Load
units are arbitrary values, the range of which is user-defined. You can use any
weighting scheme you prefer. For example, a load unit with a range of 10 to
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. You cannot use zero (0) or negative
numbers as load units.
The max_load attribute is primarily used to limit the load on a machine. As
long as a job's load will not exceed a machine's maximum load, the max_load
attribute does not influence which machine a job runs on.
If you do not define the max_load attribute in a real machine definition, its
value defaults to none (no limit).
Example: Set the Maximum Load for a Real Machine
This example sets the maximum load for a relatively low-performance real
machine, with a range of possible load values of 1 to 100:
max_load: 20
Specifying Job Load (job_load)

For load balancing to work, you must assign a job_load value to every job that
impacts the load on a machine. The job_load attribute in a job definition
defines the relative amount of processing power the job consumes (that is, the
relative load the job places on a machine). Load units are arbitrary values, the
range of which is user-defined. You can use any weighting scheme you prefer.
You can use the max_load attribute to assign a real machine a maximum job
load, then use the job_load attribute in the job definition to assign the job a
load value that indicates the relative amount of the machine's load that the job
should consume. This lets you control machine loading and prevent a machine
from being overloaded.
Example: Define the Relative Processing Load for a Job
This example sets the load for a job that typically uses 10% of the CPU, with a
range of possible load values from 1 to 100:
job_load: 10
186 User Guide
Defining Machines
Specifying Queuing Priority (priority)

When a job is ready to run on a designated machine but the current load on
that machine is too large to accept the new jobs load, Unicenter AutoSys JM
queues the job for that machine so it runs when sufficient resources are
available.
For job queuing to take place, you must define the priority attribute in the job
definition. The queue priority establishes the relative priority of all jobs queued
for a given machine, the lower number indicating a higher priority. If you do
not set the priority attribute, the job runs immediately on a machine, and is
not put in the queue.
Example: Set the Job to Run with Highest Priority
This example sets the job to run with the highest priority without overriding
the machine load control mechanism:
priority: 1
Example: Set the Job to Run in the Background

This example sets the job to run in the background when the machine load is
low:
priority: 100
Machines 187
Defining Machines
Specifying Relative Processing Power (factor)

The factor attribute is only valid in a real machine definition. It defines a factor
to multiply by a real machines available CPU cycles to check the relative
available CPU cycles. The factor value is used to weigh available cycles on one
machine against those of another machine. When Unicenter AutoSys JM
checks the available cycles on each machine, it multiplies the percent of free
CPU cycles by the factor value to check which machine has more relative
processing power available.
Factor units are arbitrary values, the range of which is user-defined. The value
consists of a real number that can contain a decimal. Therefore, the factor
value is typically a number between 0.0 and 1.0. If you do not define the
factor attribute in a real machine definition, its value defaults to 1.0.
Example: Set the Factor for a Low-Performance Real Machine
This example sets the factor for a low-performance real machine, on a scale of
0.0 to 1.0:
factor: 0.1
Example: Set the Factor for a High-Performance Real Machine

This example sets the factor for a high-performance real machine, on a scale
of 0.0 to 1.0:
factor: 1.0
188 User Guide
Machine Definitions
Machine Definitions
Unicenter AutoSys JM can infer whether you are defining a real or virtual
machine based solely on the attributes in the definition:
Any machine definition that contains a max_load or factor attribute must

be a real machine definition, because these attributes are only valid in real
machine definitions.
Any machine definition that contains a list of machine attributes is a virtual

machine definition.
The type attribute is required when defining a Windows real machine, but you
can omit it when defining a UNIX machine. Compare the following definitions:
/* real UNIX */
insert_machine: toad
max_load: 100
factor: 0.8
/* real Windows */
insert_machine: tiger
type: n
max_load: 100
factor: 0.8
/* virtual */
insert_machine: jungle
machine: toad
machine: tiger
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.
Machines 189
Machine Definitions
Define a Real Machine

To run jobs to an Agent, you must define a real machine on which it must run.
To define a real machine
1.
Assign a machine name. This must be its hostname.
2.
Assign a machine type of r for UNIX or n for Windows.
3.
(Optional) Assign a maximum load and a factor attribute value (optional).

A real machine is defined.
Example: Define a Windows Real Machine

This example defines a Windows real machine named jaguar:
insert_machine: jaguar
type: n
max_load: 100
factor: 1.0
Example: Define a UNIX Real Machine

This example defines a UNIX real machine named jaguar:
insert_machine: jaguar
type: r
max_load: 100
factor: 1.0
Delete a Real Machine

To delete a real machine definition, include the delete_machine subcommand
followed by the name of the machine to delete in the JIL script.
Example: Delete a Real Machine
This example deletes the real machine definition for the computer named
jaguar:
delete_machine: jaguar
190 User Guide
Machine Definitions
Define a Virtual Machine

You can use a virtual machine when jobs run on any member of a group of
real machines that are currently available and meet the job_load requirements
of the job.
To define a virtual machine
1.
Assign a machine name.
2.
Assign the machine type v.
3.
Specify the real machines that comprise the virtual machine.

A virtual machine is defined.
Example: Define a Windows Virtual Machine with Subsets of Real

Machines
This example defines two Windows real machines (lion and lotus), and a
virtual machine (gorilla), which is composed of slices, or subsets, of the
max_load specified for the real machines. Although the real machines were
defined with specific max_load values (100 and 80), the virtual machine only
makes use of the reduced loads specified in the virtual machine definition (10
and 9).
insert_machine: lion
type: n
max_load: 100
factor: 1
insert_machine: lotus
type: n
max_load: 80
factor: .8
insert_machine: gorilla
type: v
machine: lion
max_load: 10
machine: lotus
max_load: 9
Machines 191
Machine Definitions
Example: Define a UNIX Virtual Machine with Default Real

Machines
This example defines a UNIX virtual machine (sheep), which is composed of
two UNIX real machines (cheetah and camel). Because the max_load and
factor attributes are not defined for the real machines, they use the default
values for these attributes (a factor of 1.0 and a max_load of none, indicating
unlimited load units).
insert_machine: cheetah
insert_machine: Camel
insert_machine: sheep
type: v
machine: cheetah
machine: camel
Example: Define a UNIX Virtual Machine with Non-Default Real

Machines
This example defines two UNIX real machines (lion and lotus), and a virtual
machine (zebra), which is composed of the two real machines. The virtual
machine is a superset of the two real machines and uses the max_load and
factor attributes defined for them.
insert_machine: lion
type: r
max_load: 100
factor: 1
insert_machine: lotus
type: r
max_load: 80
factor: .9
insert_machine: zebra
type: v
machine: lion
machine: lotus
192 User Guide
Machine Definitions
Delete a Virtual Machine

To delete a virtual machine, include the delete_machine subcommand followed
by the name of the machine to delete in the JIL script. When you delete a
virtual machine, the definitions for its component real machines are not
deleted.
Example: Delete a Virtual Machine
This example deletes the virtual machine definition for the computer named
gorilla:
delete_machine: gorilla
Delete a Real Machine from a Virtual Machine

To delete a real machine from a virtual machine, include the following in the
JIL script:
The delete_machine subcommand followed by the name of the virtual

machine that contains the real machine to delete.
The machine attribute followed by the name of the real machine to delete.
Example: Delete a Real Machine from a Virtual Machine

This example deletes the real machine named camel from the virtual machine
named sheep. The machine definitions for sheep and camel are not deleted
from the database.
delete_machine: sheep
machine: camel
Machines 193
Machine Status
Machine Status
Real machines have a run-time status attribute designed to reflect the
machines availability. The machine status lets the Scheduler run more
efficiently by not wasting time trying to contact machines that are out of
service. If a job is scheduled for a machine that is offline, it is set to
PEND_MACH status until the machine comes back online. In the case of a
virtual machine, offline machines are not considered as possible candidates for
running a job.
A machine can have one of following statuses:
Online
Indicates that the machine is available and accepting jobs to run.
Offline
Indicates that the machine has been manually removed from service and
will not accept jobs to run.
Missing
Indicates that the Scheduler has verified that the machine is not
responding and has automatically removed it from service. The machine
will not accept jobs to run.
194 User Guide
Machine Status
Take a Machine Offline Manually

To manually take a machine offline (for example, during hardware service),
use the sendevent command to send a MACH_OFFLINE event.
When you send a MACH_OFFLINE event, jobs that are currently running run to
completion even though the machines status is offline. You can use the
autorep command to monitor running jobs.
If you shut a machine down for servicing, you may want to let the running
jobs complete before continuing. With the machine offline, you can service the
machine while the Scheduler continues running. All jobs that are scheduled to
start on the offline machine are put in PEND_MACH status until the machine
returns to service.
Example: Manually Take a Machine Offline
This example takes the machine cheetah offline:
sendevent -E MACH_OFFLINE -n cheetah
The Scheduler log displays a message similar to the following when the
machine is offline:
[11/28/2005 15:38:21]
CAUAJM_I_40245 EVENT: MACH_OFFLINE
MACHINE: cheetah
Put a Machine Online Manually

To manually put a machine online, use the sendevent command to send a
MACH_ONLINE event.
When you send a MACH_ONLINE event for a machine, jobs with a status of
PEND_MACH on that machine are automatically started.
Example: Manually Put a Machine Online
This example returns the machine cheetah to online status:
sendevent E MACH_ONLINE n cheetah
The Scheduler log displays a message, similar to the following, when the
machine is online:
[11/28/2005 15:38:21]
CAUAJM_I_40245 EVENT: MACH_ONLINE
MACHINE: cheetah
Machines 195
Machine Status
How Status Changes Automatically

When the Scheduler verifies that a real machine is not reachable, it uses the
following process to manage machine and job status:
If the Scheduler fails to contact a machine's Agent, it attempts to qualify

the status of that machine by pinging the Agent every 10 seconds.
If the Agent fails to respond after three attempts, the Scheduler marks the
machine as missing, issues a MACHINE_UNAVAILABLE alarm, and logs a
message similar to the following:
[11/28/2005 16:01:46]
CAUAJM_I_40253 Machine cheetah is not responding.
Taking offline.
The Scheduler puts all jobs scheduled to start on the missing machine in
PEND_MACH status.
The Scheduler pings the missing machines Agent every 60 seconds to

check its availability.
If the machine responds, the Scheduler sends a MACH_ONLINE event and

the machine returns to service.
When the machine returns to service, the Scheduler starts all jobs in
PEND_MACH status for that machine.
Note: If you understand the cause of a missing machine and intervene to
correct it, you can use the sendevent command to send a MACH_ONLINE
event to bring the machine back online instead of waiting for the
Scheduler to do so.
How Status Affects Jobs on Virtual Machines

If a job is defined to run on a virtual machine or a list of machines and one of
those machines is offline, the job will run on another available machine with
which it is associated.
If, however, all machines in the virtual list are offline, the Scheduler puts the
job in PEND_MACH status. If any of the machines with which the job is
associated comes back online, the Scheduler removes the job from
PEND_MACH status and runs it on the online machine, subject to the queuing
criteria.
196 User Guide
Load Balancing
Load Balancing
You can implement simple load balancing (wherein the workload is spread
across multiple machines based on each machine's capabilities) by using the
machine attribute to specify a virtual machine or multiple real machines in a
job definition. This is also an easy way to help ensure reliable job processing.
For example, the Scheduler can use load balancing to check which of the
machines in a job definition is best suited to run the job, and automatically
start it on that machine.
The advantages of building a virtual machine are:
Its definition can be changed and the new construct is immediately applied
globally.
The max_load and factor values can vary between machines.
Even when a set of real machines that have not been explicitly defined to
Unicenter AutoSys JM is specified in a job's machine attribute, the
available CPU cycles are used to check which machine runs the job.
Alternatively, you can specify a list of real machines in the job's machine
attribute. The system configuration includes machines of varying processing
power, so you should specify the max_load and factor attributes for each real
machine. If the max_load attribute is not defined for any of the real machines
or all of them have ample load units available, Unicenter AutoSys JM chooses
which machine to run on based solely on available processing power.
Machines 197
Load Balancing
In either case, Unicenter AutoSys JM uses the following process to verify the
available relative processing cycles for each machine:
1.
Unicenter AutoSys JM uses one of the following methods (specified in the

MachineMethod parameter in the Unicenter AutoSys JM configuration file)
to verify the percentage of CPU cycles available on each real machine in
the specified virtual machine:
For Windows Agents, Unicenter AutoSys JM opens a Windows

registry key named HKEY_PERFORMANCE_DATA, which provides a
variety of system performance data, including available CPU cycles.
For UNIX Agents, Unicenter AutoSys JM runs vmstat.
2.
Unicenter AutoSys JM multiplies the available CPU cycles by the machine's

factor value.
3.
Unicenter AutoSys JM chooses the machine with the most relative

processing cycles available, based on the calculation in Step 2.
If a real machine in the virtual machine is not online, the Scheduler does not
attempt to contact it and it is not considered in the load balancing algorithm.
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: cheetah, camel
If the factor attribute is not specified for a machine, Unicenter AutoSys JM

assumes the default factor value for each machine (1.0).
198 User Guide
Load Balancing
Example: Load Balancing With a Virtual Machine

This example defines a virtual machine (marmot) with three real machines
(cheetah, hippogriff, and camel):
insert_machine: marmot
machine: cheetah
factor: 1
machine: hippogriff
factor: 8
machine: camel
factor: .3
To start a job on this virtual machine, specify marmot in the job's machine
attribute. The Scheduler performs the necessary calculations to verify on
which machine to run the job, and reflects these calculations in its output log.
The output is similar to the following:
EVENT: STARTJOB JOB: test_mach
[11/22/2005 10:16:53]
CAUAJM_I_40245 EVENT: STARTJOB
[11/22/2005 10:16:54]
CAUAJM_I_10208
[11/22/2005 10:16:59]
<cheetah=78>
[11/22/2005 10:17:02]
<hippogriff=80*[.80]=64>
[11/22/2005 10:17:07]
<camel=20*[.30]=6>
[11/22/2005 10:17:11]
CAUAJM_I_40245 EVENT: CHANGE_STATUS
JOB: tvm
Checking Machine usages:
STATUS: STARTING
JOB: tvm
[11/22/2005 10:17:11]
CAUAJM_I_10082 [cheetah connected for tvm]
Note that even though the machine usage on cheetah was less than that of
machine hippogriff, machine cheetah was picked because of the result of the
factor calculation (machine cheetah had 78% of its processing power available,
while machine hippogriff only had 64% available). Thus, the factors weigh
each machine to account for variations in processing power.
Machines 199
Forcing a Job to Start
Forcing a Job to Start

If you use the sendevent command to send a FORCE_STARTJOB event to a
job, Unicenter AutoSys JM immediately starts the job on the machine specified
in the job definition, regardless of the current load on the machine or the
job_load value set for the job. If the job was defined to run on a virtual
machine or a list of real machines, Unicenter AutoSys JM checks which
machine has the most processing power available and runs the job on that
machine, even if the job_load value set for the job exceeds the max_load
value set for the machine.
Note: If you send a FORCE_STARTJOB event to a job that has a status of
ON_ICE or ON_HOLD, the job's status does not revert to its previous status
when it completes.
Example: Force a Job to Start
This example describes the effects of forcing a job to start. Assume you
scheduled Job1 to run every Monday at 3:00 A.M. On Sunday, you sent a
JOB_ON_HOLD event to put the job in ON_HOLD status, so that the job does
not run as scheduled on Monday. If you send a FORCE_STARTJOB event to
Job1 on Wednesday at 2:00 P.M., Job1 runs to completion (either success or
failure), and then runs again as scheduled on Monday at 3:00 A.M. Note that
the job did not revert to the ON_HOLD status after you forced it to start on
Wednesday.
Queuing Jobs
Queuing is a mechanism used in Unicenter AutoSys JM to check the run order
of jobs that cannot run immediately. There is no actual physical queue.
Instead, Unicenter AutoSys JM uses queuing policies, which are based on the
use and subsequent interaction of the job_load and priority attributes in a job
definition and the max_load and factor attributes in a machine definition. You
can also use the sendevent command to send a CHANGE_PRIORITY event to
change the priority of a job that is already queued.
Note: The constructs of job loads (specified in the job_load attribute) and
machine loads (specified in the max_load attribute) are user-defined
conventions that Unicenter AutoSys JM enforces. If you do not indicate what
the load of a job is, it does not figure in the product's queuing calculations.
This is different from the load balancing feature, which inspects the CPU to
verify its usage.
The following sections discuss queuing jobs and give examples of how to use
load balancing and queuing to optimize job processing in your environment.
200 User Guide
Queuing Jobs
How Unicenter AutoSys JM Queues Jobs

For queuing to be most effective, you must set the priority attribute for all
jobs. By default, the priority attribute is set to 0, indicating that the job should
not be queued and should run immediately. When you let the priority attribute
default for a job, it runs even if its job load would push the machine over its
load limit. However, even when jobs have a priority of 0, Unicenter AutoSys JM
tracks job loads on each machine so that jobs with non-zero priorities can be
queued.
Unicenter AutoSys JM uses the following process to limit the job load on
machines and to queue jobs for processing:
If you set a job_load value for a job and you assigned a max_load for
every real machine comprising a virtual machine, Unicenter AutoSys JM
checks if each machine has sufficient available load units before running
the job.
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
available to run the highest priority job, it remains in the queue and lower
priority jobs are considered subsequently.
If each real machine has sufficient load units, Unicenter AutoSys JM

employs the load balancing and factor algorithms to verify on which
machine the job should start.
If only one of the machines has sufficient load units, the job runs on that
machine.
If none of the machines has sufficient load units, Unicenter AutoSys JM

puts the job in QUE_WAIT status for all of the machines. The job stays in
QUE_WAIT status until one of the machines has sufficient load units
available.
When one of the machines has the necessary load units available,
Unicenter AutoSys JM reviews all the job's starting conditions to make sure
it may still run.
If all of the job's starting conditions are satisfied (that is, they evaluate
as TRUE), the job runs and is removed from all other queues.
If any of the starting conditions are no longer true, the Scheduler

generates the following message:
CAUAJM_I_40191 Job: job_name Starting Conditions are no longer TRUE.
De-Queuing this Job and setting to ACTIVATED.
Note: If a job is in QUE_WAIT status and you want it to run immediately, do

not force the job to start. Instead, use the sendevent command to send a
CHANGE_PRIORITY event that changes the job's priority to 0.
Machines 201
Queuing Jobs
Example: Job Queuing

This example shows a simple job queuing scenario that uses a previously
defined machine named lion with a max_load of 100:
insert_job: jobA
machine: lion
job_load: 80
priority: 1
insert_job: jobB
machine: lion
job_load: 90
priority: 1
In this example, if JobA was running when JobB started, Unicenter AutoSys JM
would put JobB in QUE_WAIT status until JobA completes, at which point JobB
can run.
Example: Job Queuing and Load Balancing
This example shows a situation in which 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) and
waiting for available load units. The numbers in the following illustration
indicate the job_load assigned to each job, and the max_load set for the
machine.
The following JIL statements define the machine and the jobs in this example:
insert_machine: cheetah
max_load: 80
insert_job: JobA
machine: cheetah
job_load: 50
priority: 60
insert_job: JobB
machine: cheetah
job_load: 50
priority: 50
202 User Guide
Queuing Jobs
insert_job: JobC
machine: cheetah
job_load: 30
priority: 80
insert_job: JobD
machine: cheetah
job_load: 30
priority: 70
In this example, JobB and JobC are already running because their starting
conditions were satisfied first. After JobB or JobC completes, JobA or JobD
starts. Whether JobA or JobD starts first is verified by a combination of the
priority and job_load attributes of each job, and the max_load machine
attribute. The result differs based on whether JobB or JobC finishes first. If
JobB finishes first, 50 load units become available, so either JobA or JobD
could run. Because JobA has a higher priority, it runs first. However, if JobC
finishes first, only 30 load units become available, so only JobD could run.
Machines 203
Queuing Jobs
Using a Virtual Machine as a Subset of a Real Machine

One variety of virtual machine can be considered a subset of a real machine.
Typically, you would use this type of virtual machine 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 run on a machine at any given time.
Example: Define a Virtual Machine as a Subset of a Real Machine
This example shows how to define a virtual machine that functions as a subset
of a real machine, thereby acting as a queue.
In this example, cheetah is a real machine with a max_load value of 80. If you
create three different print jobs, but you want only one job to run on a
machine at a time, you can use a combination of the max_load attribute for a
virtual machine and the job_load attributes for the jobs themselves to control
how the jobs run.
To implement this scenario, you would first create the virtual machine named
cheetah_printQ as follows:
insert_machine: cheetah_printQ
machine: cheetah max_load: 15
Next, you would define the three print jobs as follows:

insert_job: Print1
machine: cheetah_printQ
job_load: 15
priority: 1
insert_job: Print2
job_load: 15
priority: 1
insert_job: Print3
job_load: 15
priority: 2
204 User Guide
Queuing Jobs
Although the real machine cheetah has a max_load value of 80, meaning that
all three jobs (with their job_load values of 15) could run on it simultaneously,
the virtual machine cheetah_printQ effectively resets the real machine's
max_load to 15. Because each job is defined to run on cheetah_printQ, not
cheetah, only one of the jobs can run at a time because each job requires all
of the load units available on the specified machine.
Note: The load units associated with a virtual machine have no interaction
with the load units for the real machine. This example implies 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 that lets the user restrict concurrent jobs
running on any one machine.
Using a Virtual Machine to Combine Subsets of Real Machines

You can also define virtual machines to combine subsets (or slices) of real
machines into one virtual machine. You might do this, for example, if there are
two machines that are print servers and you want only one print job to run at
a time on each.
Example: Define a Virtual Machine to Combine Subsets of Real
Machines
This example defines a virtual machine (printQ) that uses subsets of the loads
available on two real machines to control where jobs run.
To implement this, you would create the virtual machine named printQ, and
specify two real machines (cheetah and camel), as shown in the following JIL
statements:
insert_machine: printQ
type: v
machine: cheetah
max_load: 15
machine: camel
max_load: 15
When a job is ready to start on printQ, Unicenter AutoSys JM checks if the

component real machine (cheetah or camel) has enough load units available to
run the job.
If neither machine has enough available load units, the product puts the
job in QUE_WAIT status and starts it when there are enough load units.
If only one machine has enough available load units, the product starts the
job on that machine.
If both machines have enough available load units, the product checks the
usage on each, and starts the job on the machine with the most available
CPU resources.
Machines 205
User-Defined Load Balancing
User-Defined Load Balancing

As an alternative to using the load balancing methods that Unicenter AutoSys
JM provides, you can write your own programs or batch files to check which
machine to use at run time. If you specify the name of a program or batch file
as the value of the machine attribute in the job definition, the Scheduler runs
the batch file at job run time, and substitutes its output for the machine name.
If the machine returned by the script is offline, the product puts the job in
PEND_MACH status for that machine. When the missing machine returns to
service, the pending job runs on it regardless of whether the script would
return a different machine name at that point in time. Because a machine
must be defined for the Scheduler to run a job on it, you must have previously
defined the machine returned by the script to Unicenter AutoSys JM.
Example: User-Defined Load Balancing
This example shows how you would specify a user-defined program or batch
file in place of a real or virtual machine for processing a job.
For example, you might supply the following:
insert_job: run_free
machine: `/usr/local/bin/pick_free_mach`
command: $HOME/DEL_STUFF
At run time, the script /usr/local/bin/pick_free_mach runs on the Scheduler

machine. The standard output is substituted for the name of the machine, and
the job runs on that machine.
Important! The escape character in the machine value above is the back-tic
character (`), not an apostrophe ('). You must escape a program or batch file
used as the machine attribute value with back-tic characters as shown for the
Scheduler to recognize that the machine value specifies a script. The
apostrophe and quotation mark characters do not work in this case.
206 User Guide
Chapter 9: Monitoring and Reporting

Jobs
Monitors and Reports (see page 207)
Define a Monitor or Report (see page 208)
Essential Monitor and Report Attributes (see page 209)
Optional Monitor Attributes (see page 214)
Define Monitors and Reports Using JIL (see page 215)
Run a Report or Monitor (see page 216)
Monitors and Reports

Monitors provide a real-time view of the system. Reports (sometimes called
browsers) let you use a variety of reporting views to examine historical
information about job executions.
Monitors and reports are simply applications that run against 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, including Dual
Event Servers, and on any Unicenter AutoSys JM Client computer.
Monitors and reports let you filter and display only the information you are
interested in from of a vast collection of data. That is, they are tools that can
provide information meaningful to you.
Both monitors and reports filter events by type and by job or groups of jobs.
Reports also filter by time (monitors do not filter by time because they provide
real-time information).
Note: Because monitors provide a picture of the system's state in real time,
they will not provide any information if the Scheduler is down. On the other
hand, reports provide a picture of the system's state from a historical
perspective, not in real time.
Monitoring and Reporting Jobs 207
Define a Monitor or Report
Monitors
Monitors provide a real-time view of the system. The following steps are
necessary to use a monitor:
1.
Define which events to monitor.
2.
Run the 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 view of Unicenter AutoSys JM events as they occur. For box
jobs, all job levels can be observed, if appropriate.
Note: Monitor names can only contain the following characters: a-z, A-Z, 0-9,
period (.), underscore (_), and hyphen (-). You cannot include spaces or tabs
in a monitor name.
Reports
A report or browser is a query run against the database, based on the
selection criteria defined for that report. Its primary function is to enable you
to quickly get specific information, such as the finish time of the database
backup for the last two weeks or a list of all jobs that have an alarm
associated with them. In addition, all job levels in box jobs can be reported.
Like monitors, a report definition is stored in the database, enabling you to run
reports any time, without redefining the criteria. Reports can only display
events that are still in the database. Archived events are inaccessible and
cannot be displayed.
Note: Report names can only contain the following characters: a-z, A-Z, 0-9,
period (.), underscore (_), and hyphen (-). You cannot include spaces or tabs
in a report name.
Define a Monitor or Report

To define a monitor or report, issue the jil command and pass it the
insert_monbro subcommand followed by a set of attributes.
To define a new monitor or report, you assign it a name and specify attributes
that further define its behavior. Using these attributes, you can specify
everything from the name to assign to the monitor or report to the events it
should track. The monitor or report specification is stored in the database.
208 User Guide
Essential Monitor and Report Attributes

The following topics describe the essential monitor and report attributes. You
must specify these attributes to define a valid monitor or report.
This section provides the following information for each attribute described:
Its name.
Its JIL attribute keyword.
A description of its use.
Common Essential AttributesGeneral

The following attributes are required for both monitors and reports. Although
defaults might be available, every monitor or report definition must include
these attributes, whether by default or by explicit specification.
Monitor or Report Name

insert_monbro: monbro_name
monbro_name
Defines a unique name for the monitor or report.
Limits: A monitor cannot have the same name as a report, but a monitor
or report can have the same name as a job.
This value can be up to 30 characters in length and can contain the
following characters: A-Z, a-z, 0-9, period ( . ), underscore ( _ ), and
hyphen ( - ). This value cannot include spaces or tabs.
Mode
mode: type
type
Specifies whether to define a monitor or report.
Set type to m or monitor to define a monitor.
Set type to b or browser to define a report.
Common Essential AttributesEvents

The events specification verifies which events to monitor or report. An event is
any change in the state of a job. Events can be programmatically generated
occurrences, such as alarms, or they can be manually generated occurrences,
such as starting a job, putting a job on hold, or killing a job.
Monitors and reports can track events by filtering at several levels or based on
selected jobs. The events to track are verified by the combination of the
various event filters and the job filter, which are specified with any of the
essential attributes.
All Events
all_events: toggle
toggle
Specifies whether to track all events for the specified jobs.
Set toggle to y or 1 to track all events. In this case, the other event
filtering attributes are ignored, and all events, regardless of source,
are reported for the selected jobs. These events include job status
events and alarms.
Set toggle to n or 0 if you do not want to track all events.
Note: Do not define a monitor to monitor all events for all jobs. Instead,
use the following command to display the Scheduler log in real time:
autosyslog -e
Running a monitor adds another connection to the database, and

establishes a process that continually polls the database. This can
significantly impact system performance. Moreover, the Scheduler log
provides more diagnostic information than a monitor.
Default: 0
Alarms
alarm: toggle
toggle
Specifies whether to track alarms. You can track alarms and job status
events in the same monitor or report.
Set toggle to y or 1 to track alarms.
Set toggle to n or 0 if you do not want to track alarms. This is the

default value.
Default: 0
210 User Guide
All Job Status Events

all_status: toggle
toggle
Specifies whether to track all job status events for the specified jobs. Job
status events occur whenever a job's status changes. You can track alarms
and job status events in the same monitor or report.
Set toggle to y or 1 to track all job status events.
Set toggle to n or 0 if you do not want to track all job status events.
Default: 0
Individual Job Status Events

The following table lists the additional monbro attributes used to request the
display of individual job status events:
JIL Keyword
Field Name
running
Displays RUNNING status events
success
Displays SUCCESS status events
failure
Displays FAILURE status events
terminated
Displays TERMINATED status events
starting
Displays STARTING status events
restart
Displays RESTART status events
Note: For each JIL keyword, do the following:
Set toggle to y or 1 to track the individual job status event.
Set toggle to n or 0, if you do not want to track the individual job

status events.
Default: n or 0.
Job Filter
job_filter: type
type
Defines which jobs to track. Monitors and reports can track events based
on selected jobs. The events to track are verified by the combination of
the various event filters and the job filter.
Set type to a to track all jobs (no job filtering).
Set type to b to track a single box and the jobs it contains.
Set type to j to track a single job.
If you set type to b or j, you must also define the job_name attribute to
specify the name of the box or job to track.
Default: a
212 User Guide
Essential Report Attributes

When defining reports, you must specify either the currun or the after_time
attribute in addition to the essential attributes described previously. The time
criteria specified in these mutually exclusive attributes let you select events
that occurred during a particular interval.
Current Run Only

currun: toggle
toggle
Specifies whether to report events only for the current or most recent run
of the specified jobs.
Set toggle to y or 1 to report events only for the current or most

recent job run.
Set toggle to n or 0 if you do not want to restrict reporting to events

for the current or most recent job run. If you set toggle to n or 0, you
must define the after_time attribute.
This feature is useful for getting a sense of what is happening right now.
For example, you could select the job status event RESTART, turn off job
filtering, and set this attribute to y to see all the jobs that have been
automatically restarted in their current or latest run.
Default: 1
Events After a Certain Date and Time

after_time: "date_time"
date_time
Defines that only events occurring for the specified jobs after the specified
date and time are reported.
Default: When you set the currun attribute to n or 0, the after_time
attribute defaults to 00:00 (12:00 a.m.) on the current day. When you set
the currun attribute to y or 1, the after_time attribute is ignored. When
you omit the date from the date_time value, after_time defaults to the
current day.
Limits: Specify date_time in the format "MM/DD/[YY]YY hh:mm", where
MM is the month, DD is the day, [YY]YY is the year, hh is the hour (in 24hour format), and mm is the minutes. You must enclose the date_time
value in quotation marks (").
You cannot use the after_time attribute in a monitor definition because
monitors only show events as they occur.
Optional Monitor Attributes
Optional Monitor Attributes

The following topics describe optional monitor attributes. You must specify
these attributes to define a valid monitor. There are no optional report
attributes.
This section provides the following information for each attribute described:
Its name.
Its JIL attribute keyword.
A description of its use.
Verification Required for Alarms

alarm_verif: toggle
toggle
Specifies whether the monitor should require an operator response to
alarm events and provides an accounting of alarm events for which there
was an operator response. When the monitor detects an alarm event, it
prompts the operator for a response and repeats the prompt every 20
seconds until the operator responds. When the operator responds
(typically by entering a comment at the prompt), the monitor time stamps
the response and records it in the database, along with the alarm event.
Set toggle to y or 1 to require an operator response to alarms.
Set toggle to n or 0 if you do not want to require an operator response

to alarms.
Default: 0
214 User Guide
Define Monitors and Reports Using JIL
Define Monitors and Reports Using JIL

Use the following syntax to define a monitor or report using JIL:
subcommand:monbro_name
attribute_keyword:value
The only difference between defining monitors or reports and defining jobs is
that different subcommands are used. Use the following JIL subcommands to
define and manage monitors and reports:
insert_monbro
update_monbro
delete_monbro
Example: Define a Monitor Using JIL

This example uses the following JIL statements to define a monitor named
Regular. This monitor tracks job status events when a job changes state to
RUNNING, SUCCESS, FAILURE, or TERMINATED. It also defines a monitor
named Alarm that tracks all alarm events. When the monitor detects an alarm
event, it prompts the operator for a response and repeats the prompt every 20
seconds until the operator responds.
insert_monbro: Regular
mode: m
running: y
success: y
failure: y
terminated: y
/* Monitor for JUST ALARMS!
* Verification Required is ON so someone must type in a response.
*/
insert_monbro: Alarm
mode: m
alarm: y
alarm_verif: y
These JIL statements are stored in the ujo_monbro table in the database.
Run a Report or Monitor
Example: Define a Report Using JIL

This example uses the following JIL statements to define a report named
Alarm_Rep that reports all alarms on any job from June 1, 1997 at 2:00 a.m.
to the present.
insert_monbro: Alarm_Rep
mode: b
alarm: y
after_time: "06/01/1997 2:00"
The quotation marks are required in the after_time value because it contains a
colon (:).
Note: Reports can only display events that are still in the database. Archived
events are inaccessible and cannot be displayed.
Run a Report or Monitor

To run a report or monitor, run the following command at the command
prompt:
monbro -N monitor_name
216 User Guide
Chapter 10: Maintaining the Scheduler

Overview of Scheduler Maintenance (see page 217)
Start the Scheduler (see page 218)
How the Scheduler Starts Processes (see page 219)
How You Can Back Up Definitions (see page 220)
Restore Definitions (see page 223)
Monitoring the Scheduler (see page 225)
Start the Scheduler in Global Auto Hold Mode (see page 226)
How Shadow Scheduler Rollover Works (see page 228)
Restore the Primary Scheduler After a Rollover (see page 229)
Stop the Scheduler (see page 231)
Running the Scheduler in Test Mode (see page 232)
Overview of Scheduler Maintenance

The Scheduler (that is, the event_demon.exe executable) is the engine of
Unicenter AutoSys JM; when the Scheduler is not running, you cannot initiate
new actions. If you stop the Scheduler, any actions that have already started
run to completion.
The database that is designated as the Event Server must be available,
running, and properly identified before you can start the Scheduler.
Maintaining the Scheduler 217
Start the Scheduler
Start the Scheduler

You must start the Scheduler to use Unicenter AutoSys JM to schedule and run
jobs. The database that is designated as the Event Server must be available,
running, and properly identified before you can start the Scheduler.
To start the scheduler at a Windows command prompt

1.
Open the Unicenter AutoSys JM Administrator from the program group and
select Instance from the AutoSys menu.
The Unicenter AutoSys Instance screen opens.
2.
(Optional) Enter the name of the computer on which the Scheduler is

installed in the Computer field, and click Connect.
Note: By default, the Computer field contains the name of the computer
you are logged on to, but you can connect to a remote computer to
administer the instance information by specifying the appropriate
computer name.
Unicenter AutoSys JM connects to the specified computer.
3.
Select an instance from the AutoSys Instance list, specify the date format
in the Date Format field, and click OK.
The Unicenter AutoSys Instance screen closes.
4.
Select Services from the AutoSys menu.

The Unicenter AutoSys Services screen opens.
5.
Select the Scheduler from the Service list and click Start Service.
The Scheduler starts.
To start the Scheduler at a UNIX command prompt, enter the following

command:
eventor
Note: Most services, including the Agent and the Event Server (database
service), start automatically at system startup. We recommend that you start
the Scheduler and the Application Server manually after starting your system.
If you lose several systems simultaneously due to power failure, this approach
lets the Agents start on their respective computers before you start the
Scheduler.
218 User Guide
How the Scheduler Starts Processes
How the Scheduler Starts Processes

After you start the Scheduler, it performs the following tasks before it begins
processing:
Verifies that no other Scheduler is running on that computer.
Runs the chase command with the -A and -E parameters. The chase
command verifies from the database which jobs are in the STARTING or
RUNNING state, and on which computer. For each Client computer, the
chase command passes the Agent a list of jobs that should be running
there and instructs the Agent to verify that the processes are actually
running. This command also verifies that the Agent is running. If the chase
command detects errors, it sends an alarm. If a job is not running as
expected, the Scheduler sends the necessary corrective event for the job,
if the job definition allows it.
If a STARTJOB event is being processed and the job it started is still

active, the Scheduler does not restart it. The purpose of running the chase
command is to guarantee that the Scheduler starts with all processes in a
known state. Problems are detected upon Scheduler startup. This method
is similar to a database checkpointing and rolling forward or back upon
recovery.
Note: You can turn off this Scheduler startup behavior by clearing the
Chase On Startup check box on the Unicenter AutoSys Administrator
Scheduler screen. For more information, see the Online Help.
Note: You can turn off this Scheduler startup behavior by running the
eventor script with the -n command line option:
eventor -n
How You Can Back Up Definitions

We recommend that you back up the following definitions periodically so you
have files to restore from in the event of a system failure:
Calendar definitions
Job definitions
Machine definitions
Monitor and report definitions
Global variables
Use the following process to back up your definitions:

1.
Use the autocal_asc command to back up calendar definitions.
2.
Use the autorep command to back up job and machine definitions.
3.
Use the monbro command to back up monitor and report definitions.
4.
Use the autorep command to back up global variables.
Back Up Calendar Definitions

You should back up your calendar definitions periodically so you have files to
restore from in the event of a system failure.
To back up calendar definitions, run each of the following commands from an
instance command prompt:
autocal_asc E /directory/autosys.ecal e ALL
autocal_asc E /directory/autosys.ccal c ALL
autocal_asc E /directory/autosys.scal s ALL
directory
Defines a directory outside of the Unicenter AutoSys JM directory
structure.
220 User Guide
Back Up Job, Machine, and Monitor Definitions

You should back up your job, machine, and monitor and report definitions
periodically so you have files to restore from in the event of a system failure.
To back up job, machine, and monitor definitions
1.
Run the following command from an instance command prompt to save

your job definitions:
autorep -J ALL -q > /directory/autosys.jil
directory
structure. We recommend that you use the same directory in which
you saved your calendar definitions.
The command saves your job definitions to a file named autosys.jil.
2.
Run the following command from an instance command prompt to append

your machine definitions to the file that contains your job definitions:
autorep -M ALL -q >> /directory/autosys.jil
Note: To append definitions to an existing file, you must enter >>

(instead of >) in the command. We recommend that you append your job,
machine, and monitor and report definitions to the same file so you have
only one file to restore following a system failure.
The command appends your machine definitions to the file that contains
your backed-up job definitions.
3.
Run the following command from an instance command prompt to append

your monitor and report definitions to the file that contains your job and
machine definitions:
monbro -N ALL -q >> /directory/autosys.jil
The command appends your monitor and report definitions to the file that
contains your backed-up job and machine definitions.
Back Up Global Variable Definitions

You should back up your global variable definitions periodically so you have
files to restore from in the event of a system failure.
To back up calendar definitions, run the following command from the instance
command prompt to save your global variables to their own file:
autorep -G ALL > /directory/globals.jil
directory
structure. We recommend that you use same directory in which 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.
222 User Guide
Restore Definitions
Restore Definitions
If you think you might have lost data during a system failure or you want to
reset the definitions in your database to a previous level, you must restore
backed-up definitions. This procedure assumes that you have previously
backed up your global variables and your calendar, job, machine, monitor and
report definitions.
To restore definitions
1.
Run each of the following commands from an instance command prompt

to restore your calendar definitions:
autocal_asc I c:\directory\autosys.ecal
autocal_asc I c:\directory\autosys.ccal
autocal_asc I c:\directory\autosys.scal
directory
Defines the directory to which you previously backed up the
definitions.
The commands restore your calendar definitions to the database.
2.
Run the following command from an instance command prompt to restore

your job, machine, and monitor and report definitions:
jil < c:\directory\autosys.jil
directory
definitions.
The command restores your definitions to the database.
3.
Open the globals.jil file that contains your backed-up global variables and
reference it as you manually redefine any global variables and reset the
necessary Administrator settings.
Your global variables are restored.
Restore Definitions
To restore definitions
1.
Run each of the following commands from an instance command prompt

to restore your calendar definitions:
autocal_asc I /directory/autosys.ecal
autocal_asc I /directory/autosys.ccal
autocal_asc I /directory/autosys.scal
directory
definitions.
The commands restore your calendar definitions to the database.
2.
Run the following command from an instance command prompt to restore

your job, machine, and monitor and report definitions:
jil < /directory/autosys.jil
directory
definitions.
The command restores your definitions to the database.
3.
Open the globals.jil file that contains your backed-up global variables and
reference it as you manually redefine any global variables.
Your global variables are restored.
224 User Guide
Monitoring the Scheduler
Monitoring the Scheduler

The Scheduler writes its output to the following log file:
%AUTOUSER%\out\event_demon.%AUTOSERV%
This log file contains a record of all the actions taken by the Scheduler,
including startup and shutdown information.
To view the log file, run the following command:
autosyslog -e
The Scheduler writes its output to the following log file:

$AUTOUSER/out/event_demon.$AUTOSERV
This log file contains a record of all the actions taken by the Scheduler,
including startup and shutdown information. If the $AUTOUSER directory is
NFS mounted, you can view this output from any computer on the network.
To view the log file, run the following command:
autosyslog-e
When you run the autosyslog-e command, the last ten lines of the Scheduler
log file are displayed, and all subsequent additions to the log are automatically
displayed as they occur.
To terminate autosyslog, press Ctrl+C.
Start the Scheduler in Global Auto Hold Mode
Scheduler Log File Location

When the Scheduler has problems starting, it logs errors to a location that is
dependent upon when the starting process fails. You can find the error
description in one of the following locations:
If the Scheduler fails early in startup, it writes errors to the Windows Event
Log.
If the Scheduler fails during the startup procedure, it writes errors to the
designated Enterprise Wide Directory, in the following location:
event_demon.$AUTOSERV$.out
If the Scheduler encounters problems while running, it writes errors to the

following location:

If you restart a Scheduler after a period of downtime, you might want to start
it in Global Auto Hold mode. Starting the Scheduler 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 Scheduler
evaluates all box, command, and file watcher jobs whose starting conditions
have been met and are eligible to run, but instead of starting the jobs the
Scheduler puts them in ON_HOLD status.
This approach lets you decide which jobs should run and selectively start them
by using the sendevent command to send a FORCE_STARTJOB event. The only
way to start a job when Global Auto Hold is on is to send the
FORCE_STARTJOB event.
To start the Scheduler in Global Auto Hold mode

1.
2.
(Optional) Enter the name of the computer on which the Scheduler is

installed in the Computer field, and click Connect.
computer name.
226 User Guide
3.
4.
Select Scheduler from the AutoSys menu.

The Unicenter AutoSys Scheduler screen opens.
5.
Select the Global Auto Hold check box, and click OK.
The Global Auto Hold mode is activated and the Unicenter AutoSys
Scheduler screen closes.
6.

7.
To start the Scheduler in Global Auto Hold mode

1.
Enter the following command at a UNIX command prompt:

eventor -G

2.
Run the following command to send a Force Start Job event:

sendevent -E FORCE_STARTJOB -J job_name
Job_name
Defines the name of the job to which to send the FORCE_STARTJOB
event.
The specified job starts.
How Shadow Scheduler Rollover Works
How Shadow Scheduler Rollover Works

You can configure a Shadow Scheduler to use as a backup Scheduler. In this
scenario, both the Primary Scheduler and the Shadow Scheduler periodically
update the Event Server to indicate that they are active. The Shadow
Scheduler remains idle, checking the Event Server for periodic messages
(called pings) from the Primary Scheduler. These messages indicate that the
Scheduler is operating correctly. If the Primary Scheduler fails to ping the
Event Server, the Shadow Scheduler assumes responsibility for interpreting
and processing events.
If the Primary Scheduler and an Event Server are on the same machine, the
Scheduler failure could also mean an Event Server failure. In this case, if Dual
Event Servers are configured, Unicenter AutoSys JM rolls over to the Shadow
Scheduler and to Single Event Server mode. Unicenter AutoSys JM uses the
Tie-breaker Scheduler to resolve contentions and to eliminate the case where
one processor takes over because its own network is down. However, the
Shadow Scheduler is not guaranteed to take over in every case. For example,
in the case of network problems, Unicenter AutoSys JM might not be able to
determine which Scheduler works, and might shut down both Schedulers.
You can use the Unicenter AutoSys Scheduler screen of the

Administrator (accessed from the program group) to select the RoleDesignator
of Shadow Scheduler or Tie-breaker Scheduler.
Note: For more information, see the Online Help.
You can specify the Shadow Scheduler and the Tie-breaker Scheduler by
modifying the RoleDesignator parameter in the configuration file.
More information:
Dual Event Servers (see page 19)
High Availability Option and Dual Event Servers: Tie-breaker Scheduler (see
page 21)
High Availability Option: Shadow Scheduler (see page 20)
High Availability Recovery (see page 258)
228 User Guide
Restore the Primary Scheduler After a Rollover

If you run
Scheduler
Scheduler
Scheduler
Unicenter AutoSys JM with a Shadow Scheduler, the Shadow

takes over interpreting and processing events if the Primary
fails. You can restore the Primary Scheduler after the Shadow
takes over.
To restore the Primary Scheduler after a rollover

1.
Log on to the machine running the Shadow Scheduler as the EXEC

Superuser, and issue the following command:
The Shadow Scheduler completes any processes it is currently performing,

and stops.
2.
Open the Unicenter AutoSys JM Administrator from the program group on

the Primary Scheduler computer and select Instance from the AutoSys
menu.
3.
(Optional) Enter the name of the computer on which the Primary

Scheduler is installed in the Computer field, and click Connect.
computer name.
4.
5.

6.
7.

the Shadow Scheduler computer and select Instance from the AutoSys
menu.
8.
(Optional) Enter the name of the computer on which the Shadow

Scheduler is installed in the Computer field, and click Connect.
computer name.
9.
10. Select Services from the AutoSys menu.

11. Select the Scheduler from the Service list and click Start Service.
The Scheduler service for the Shadow Scheduler is restored.
To restore the Primary Scheduler after a rollover

1.
Log onto the machine running the Shadow Scheduler as the EXEC
Superuser, and issue the following command:
sendevent -E STOP_DEMON.
The Shadow Scheduler completes any processes it is currently performing,

and stops.
Note: If you are running with Dual Event Servers, the TieBreaker
Scheduler must also be stopped and restarted.
2.
On the Primary Scheduler machine, restart the Primary Scheduler by

issuing the following command;
eventor
The Primary Scheduler is restored.

3.
On the Shadow Scheduler machine, issue the following command:

eventor.
The Shadow Scheduler is restarted.
230 User Guide
Stop the Scheduler
Stop the Scheduler

Stopping the Scheduler does not affect jobs that are already running. They
continue to run to completion, at which time their exit events are sent directly
to the database. When you stop the Scheduler, actions triggered by incoming
events sent from the Agents are not initiated until you restart the Scheduler.
Only the EXEC Superuser can stop the Scheduler. It is safe to stop the
Scheduler at any time, if you do it properly.
To stop the Scheduler, log on to any Unicenter AutoSys JM-configured
computer as the EXEC Superuser and issue the following command at an
instance command prompt:
When you issue the sendevent command, the STOP_DEMON event is sent to
the database. The Scheduler reads the STOP_DEMON event, enters an orderly
shutdown cycle (completing any processing it is currently performing), and
exits.
There might be a delay between when you send the STOP_DEMON event and
when the Scheduler reads it and shuts down. If the Scheduler does not stop
immediately, do not send another STOP_DEMON event, because the Scheduler
will process that event the next time it starts, promptly shutting down.
To assign a high priority to the sendevent command, include the -P 1
argument, as follows:
sendevent -E STOP_DEMON -P 1
Note: Do not attempt to stop the Scheduler by terminating the process. This
method stops the Scheduler immediately, even if it is processing an event.
Also, if you are using Dual Event Servers and terminate the process in any
way other than with the sendevent command, the databases can lose
synchronization. For more information, see the Reference Guide.
Running the Scheduler in Test Mode

You can run the Scheduler in test mode to troubleshoot problems, check your
configuration, and test the setup and execution of logic by the jil command,
without running the defined jobs. In test mode, the Scheduler runs a simple
test job instead of the defined jobs.
When running in test mode, you can check the following:
Whether the Scheduler and the 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 normal mode.
Whether the conditional logic for jobs, including nested boxes, is

functioning correctly.
To define the level at which test mode runs, set the value of the
%AUTOTESTMODE% variable before you start the Scheduler. You can set
%AUTOTESTMODE% to one of the following values:
%AUTOTESTMODE% = 1
Runs each job with the following test mode variations:
The ntgetdate command runs on the remote computer instead of the

command specified in the job definition.
The Scheduler redirects standard output and standard errors for the
command to the \tmp\autotest %AUTO_JOB_NAME% file, where
%AUTO_JOB_NAME% is the job name as defined to Unicenter AutoSys
JM.
If the job being run in test mode is a file watcher job, it is not
disabled. The Scheduler runs it as it would in real mode.
This test mode disables the following functions:
Minimum and maximum run alarms
Sourcing a user-specified job profile file
All resource checks
%AUTOTESTMODE% = 2
Runs each job with the same behaviors as %AUTOTESTMODE = 1, adding
the following procedures:
Resource checks are performed.
A user-defined job profile is sourced.
The Scheduler redirects output from the ntgetdate command to the

user-defined standard output and standard error files (if they are defined).
Otherwise, the Scheduler redirects output to the
\tmp\autotest.%AUTO_JOB_NAME% file.
232 User Guide
To define the level at which the test mode runs, set the value of the
$AUTOTESTMODE variable before you start the Scheduler. The levels of test
mode are verified by the value of the $AUTOTESTMODE variable. You can set
$AUTOTESTMODE to one of the following values:
$AUTOTESTMODE = 1
Runs each job with the following test mode variations:
The ntgetdate command runs on the remote computer instead of the

command specified in the job definition.
The Scheduler redirects standard output and standard errors for the
command to the \tmp\autotest $AUTO_JOB_NAME$ file, where
$AUTO_JOB_NAME$ is the job name as defined to Unicenter AutoSys
JM.
If the job being run in test mode is a file watcher job, it is not
disabled. The Scheduler runs it as it would in real mode.
This test mode disables the following functions:
Minimum and maximum run alarms
Sourcing a user-specified job profile file
All resource checks
$AUTOTESTMODE = 2
Runs each job with the same behaviors as $AUTOTESTMODE = 1, adding
the following procedures:
Resource checks are performed.
A user-defined job profile is sourced.
The Scheduler redirects output from the ntgetdate command to the

user-defined standard output and standard error files (if they are
defined). Otherwise, the Scheduler redirects output to the
\tmp\autotest.$AUTO_JOB_NAME file.
Note: The Scheduler cannot run partially in test mode, and Unicenter AutoSys
JM does not provide a test mode for the database. Exercise extreme caution
when you run in test mode on a live production system.
Chapter 11: Maintaining the Agent

Overview of Agent Maintenance (see page 235)
Start the Agent (see page 236)
Maintenance Commands (see page 238)
Overview of Agent Maintenance

An Agent is a Windows service or UNIX process that runs on a remote
computer. The Scheduler directs the Agent to perform specific tasks. The
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 Agent cannot transfer the information, it waits and tries again. It
continues to try to connect to the database until it can successfully transfer
the information.
Maintaining the Agent 235
Start the Agent
Start the Agent

The Agent service starts automatically when the computer starts. Under
normal circumstances you should not need to start the Agent manually. If the
Agent service is stopped, any user with Administrators group privileges can
restart it.
Important! You should not stop the Agent service. If the Agent service is
inadvertently stopped, follow the instructions in this topic to restart it.
To start the Agent

1.
2.
(Optional) Enter the name of the computer on which the Agent is installed
in the Computer field, and click Connect.
computer name.
3.
Select the instance with which the Agent is associated from the AutoSys
Instance list, and click OK.
4.

5.
Select the Agent service from the Service list.

The Unicenter AutoSys Services screen refreshes to indicate the status of
the selected Agent. If the selected Agent is not running, Start Service is
enabled. If the selected Agent is running, Stop Service is enabled and
Start Service is disabled.
6.
Click Start Service.

The Agent service starts.
236 User Guide
Start the Agent
To manually restart the Agent, issue the following command at a UNIX

command prompt:
More Information:
Agent Troubleshooting (see page 314)
Maintaining the Agent 237
Maintenance Commands
Maintenance Commands
The following maintenance commands are located in the %AUTOSYS/bin
directory. You can run these commands from the instance command prompt
window or as a job.
chase
Verifies that the expected jobs are running. The command queries every
computer that should be running a job and verifies that the Agent and the
job are running.
The chase command sends errors it detects to standard output. You can
use the following options with the chase command to further define the
actions to take when the command detects error conditions:
-A
Sends alarms to alert you when the command detects an error.
-E
Restarts missing jobs that are defined as restartable.
Note: The chase command cannot tell if a computer is down;
therefore, the command cannot tell if jobs on that computer are
running or if the network connection to the computer is down. If you
run the chase command with the -E option, jobs that have already run
or are running on the computer with the failed network connection
might restart when the network connection is re-established.
clean_files
Deletes old Agent log files. The command searches the database for all
computers that have had jobs started on them, and sends a command to
the database on that computer to purge all remaining log files from the
computer's enterprise-wide logging directory (for UNIX it is specified by
AutoRemoteDir in the configuration file, and for Windows it is specified in
the Enterprise Wide Logging Directory field in the Unicenter AutoSys
Scheduler screen). To remove only the log files older than a specific
number of days, enter the command as follows:
clean_files -d days
-d days
Defines the threshold for deleting old Agent log files. When you run
the command, files older than the specified number of days are
deleted.
238 User Guide
Chapter 12: Maintaining the Event

Server
Overview of Event Server Maintenance (see page 240)
Using Dual Event Server Mode (see page 240)
Database Architecture (see page 241)
Database Storage Requirements (see page 243)
General Database Maintenance (see page 243)
Reschedule Daily Database Maintenance (see page 244)
How the DBMaint.bat Batch File or DBMaint Script Runs (see page 245)
Modify the DBMaint.bat File or DBMaint Script (see page 246)
Reduce the Frequency of Sybase Deadlocks (see page 247)
Event Server Rollover Recovery (see page 248)
High Availability Recovery (see page 258)
Recovery Scenarios Summary (see page 261)
Maintaining the Event Server 239
Overview of Event Server Maintenance
Overview of Event Server Maintenance

All information is stored in a relational database known as the Event Server.
You can use Oracle, Sybase, or Microsoft SQL Server for the Event Server
database.
An Event Server contains all of the information about a particular Unicenter
AutoSys JM instance, and can be associated with only one instance and one
running Scheduler. The Event Server contains the following objects:
Job definitions
Events
Monitor and report definitions
Calendar definitions
Machine definitions
Note: For more information about the database tables and views and the
event and alarm codes used in the database, see the Reference Guide.
The Scheduler reads from the Event Server to check what actions to take. The
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.
More Information:
Configuring Unicenter AutoSys JM (see page 265)
Using Dual Event Server Mode

When you
two Event
Scheduler
Scheduler
configure with Dual Event Servers, all of the data is duplicated on

Servers. In Dual Event Server mode, both servers are peers and the
is responsible for keeping the databases synchronized. The
continually reads from both databases as it processes events.
Note: For information about installing a second Event Server, see the
Windows or UNIX Implementation Guide.
240 User Guide
Database Architecture
The following illustration shows the layout of databases in a Unicenter
AutoSys JM environment to help you understand configuration options. It
shows how Unicenter AutoSys JM verifies which database to use, and how the
four primary components (the Scheduler, the Application Server, the Event
Server database, and the Agent) interact.
The illustration shows one instance configured with Dual Event Servers, which
are used only by this instance. The Scheduler and the 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 with the Unicenter AutoSys JM Administrator. In
the Administrator, you can specify which databases to use. This information is
stored in the Windows registry and all commands access it. The
%AUTOSERV% variable is set in the instance command prompt window, so
you must run commands using that window.
The following illustration shows the layout of databases in a Unicenter

AutoSys JM environment to help you understand configuration options. It
depicts how Unicenter AutoSys JM checks which database to use, and how the
four primary components (the Scheduler, the Application Server, the Event
Server database, and the Agent) interact.
The illustration shows one instance configured with Dual Event Servers, which
are used only by this instance. Both the Scheduler and the Agent help 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 modifying the $AUTOUSER/config.$AUTOSERV
configuration file. In this file, you can specify which databases to use, and all
commands access this information. The $AUTOSERV variable is set in the
instance command prompt window, so you must run commands using that
window.
242 User Guide
Database Storage Requirements
Database Storage Requirements

The limit on how much disk space a database location can use is based on the
underlying operating system and its file size limitations. Databases needs disk
space for more than just the database tables and stored procedures. They
require sufficient disk space for work locations used for sorting, temporary and
transient files. In addition, product operation and database backups can
require a lot of space.
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 ujo_job_runs table).
The standard sizes for databases are 64 MB (Microsoft SQL Server), 400 MB
(Oracle) and 200 MB (Sybase). The database tables are created with the
option that they will automatically extend as long as there is room in the file
system. The table sizes specified are the recommended initial size. If your job
load is large, create a larger database.
General Database Maintenance

Periodic maintenance is essential to keeping Unicenter AutoSys JM working
correctly. Each run of each job generates several events. If you do not remove
these events from the database periodically, the database eventually reaches
its size limit, 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.
Reschedule Daily Database Maintenance
Reschedule Daily Database Maintenance

The Scheduler performs internal database maintenance once a day. It does
not process any events during maintenance, and it waits for the maintenance
activities to complete before resuming normal operation. By default, this
maintenance cycle starts at 3:30 a.m.
Note: You should schedule the maintenance command to run during a time of
minimal system activity. We highly recommend that you configure your
system to back up the database during the maintenance cycle.
To reschedule daily database maintenance

1.
select Scheduler from the AutoSys menu.
The Unicenter AutoSys Scheduler screen opens.
2.
(Optional) Edit the location of the DBMaint.bat file in the Database

Maintenance Command field.
Unicenter AutoSys JM runs the DBMaint.bat file at this location at run time.
3.
Edit the time of day the DBMaint.bat file should run in the Database
Maintenance Time field. Use 24-hour format for the time entry.
4.
Click OK.
The Unicenter AutoSys Scheduler screen closes and the DBMaint.bat file
will run as scheduled.
To reschedule daily database maintenance, define the DBMaintCmd and

DBMaintTime Parameters in the $AUTOUSER/config.$AUTOSERV configuration
file. Use a 24-hour format for the time entry.
More Information:
DBMaintTime and DBMaintCmd ParametersConfigure Automatic Database
Maintenance (see page 271)
244 User Guide
How the DBMaint.bat Batch File or DBMaint Script Runs
How the DBMaint.bat Batch File or DBMaint Script Runs

By default, Unicenter AutoSys JM runs the
%AUTOSYS%\bin\DBMaint.bat file during its daily maintenance cycle. This
batch file runs the dbstatistics and archive_events commands.
By default, Unicenter AutoSys JM runs the $AUTOSYS/bin/DBMaint

script during its daily maintenance cycle. This script 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, dbstatistics 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, dbspace issues warning messages
and generates a DB_PROBLEM alarm.
Note: If you use an Oracle database, running DBMaint may incorrectly
report that your database is nearly full. This can occur because dbspace
calculates how much space is not allocated for extents. The extents may
be nearly empty, but the command reports the whole extent as used
space.
Calculate and update the average job run statistics in the ujo_avg_job_run
table. When dbstatistics runs, it overwrites old data with the new data.
DBMaint runs the archive_events command to remove old information from

various database tables. Specifically, archive_events removes the following:
Events and alarms associated with them from the ujo_event table
Job run information from the ujo_job_runs table
Autotrack log information from the ujo_audit_info and ujo_audit_msg

tables
The output from DBMaint, %AUTOUSER%\out\DBMaint.out, reports how

much space is left in your database so you can monitor whether the event
tables are filling up.
The output from DBMaint, $AUTOUSER/out/DBMaint.out reports how

much space is left in your database so you can monitor whether the event
tables are filling up.
Modify the DBMaint.bat File or DBMaint Script
Running DBMaint is a good way to calculate how many events that occur in a
single day you can safely maintain in the database before you should archive
them.
Note: If you are archiving large event tables, your SQL connection might time
out, causing the DBMaint script to fail. If this occurs, set the -I argument of
the archive_events command to a higher value. For more information, see the
Reference Guide.
Modify the DBMaint.bat File or DBMaint Script

You can modify the %AUTOSYS%\bin\DBMaint.bat batch file or the
$AUTOSYS/bin/DBMaintscript. For example, you might want to modify the
batch file or script to perform database backups.
Before you modify the batch file or script, make a backup copy, and modify
the copy. When you upgrade, you will not lose your changes. You can use your
enhanced batch file or script to modify the newly installed file.
The batch file name is specified in the Database Maintenance Command

field on the Unicenter AutoSys Scheduler screen.
The script name is specified in the DBMaintCmd parameter in the

$AUTOUSER/config.$AUTOSERV configuration file.
246 User Guide
Reduce the Frequency of Sybase Deadlocks
Reduce the Frequency of Sybase Deadlocks

Depending on your environment, the Scheduler log might contain many
Sybase deadlock messages. While these messages do not affect system
integrity, they 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, enter the following
command at an ISQL prompt:
sp_configure "lock scheme", 0, datarows;
You can also lock tables individually. To do so, enter the following command at
an ISQL prompt:
alter table tablename lock datarows;
tablename
Defines the name of a table on which to configure row-level locking.
Based on usage, we recommend that you lock the following tables:
ujo_event
ujo_proc_event
ujo_job
ujo_job2
ujo_job_cond
ujo_job_status
ujo_job_runs
ujo_last_Eoid_counter
ujo_next_oid
Event Server Rollover Recovery

When Unicenter AutoSys JM is running in Dual Event Server mode and the
Scheduler detects an unrecoverable error condition on one of the Event
Servers, it automatically rolls over to Single Event Server mode on the
remaining Event Server. 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, database corruption

or media failure).
The Administrator Event Server screen indicates a rollover and a switch

to Single Event Server mode in two ways:
The Status field shows which Event Server is DOWN.
The Database Rollover Has Occurred check box is selected.
The $AUTOUSER/config.$AUTOSERV configuration file indicates a

rollover and switch to Single Event Server mode by commenting out the
EventServer line that defines the Event Server that went offline.
Unicenter AutoSys JM makes these changes so that you and the utilities trying
to access the database are aware that it is now running in Single Event Server
mode, and to ensure that Client processes do not try to write to the inactive
Event Server.
Notes:
248 User Guide
When an Event Server rollover occurs, the product edits the AutoSys
Administrator Event Server screen or $AUTOUSER/config.$AUTOSERV
configuration file on the Scheduler computers only. The
$AUTOUSER/config.$AUTOSERV configuration file on Client computers are
not modified.
If you run Unicenter AutoSys JM under heavy job load in an Oracle

environment, it rolls over to Single Event Server mode when the
transaction log is full, and the transactions are suspended.
Return to Dual Event Server Mode After a Rollover

If one Event Server goes down in Dual Event Server mode, Unicenter AutoSys
JM automatically rolls over to the second Event Server and continues running
in Single Event Server mode. After you recover the Event Server that failed,
you can reconfigure to run in Dual Event Server mode.
Important! Do not simply restart the failed Event Server and attempt to run
in Dual Event Server mode. Before starting the failed server, you must
synchronize the two Event Servers.
To return to Dual Event Server mode after a rollover

1.
Log on to a Unicenter AutoSys JM-configured computer as the EXEC

Superuser, and issue the following command at an instance command
prompt:
The Scheduler completes any processing it is currently performing, and

stops.
2.
select Services from the AutoSys menu.
3.
Select the Application Server from the Service list, and click Stop Service.
The Application Server stops.
4.
Run one of the following scripts as appropriate to synchronize the Event

Servers:
For MSSQL, run autobcpMSQ.pl
For Oracle, run autobcpORA.pl
For Sybase, run autobcpSYB.pl
Note: The autobcpDB script is located in the

C:\Program Files\CA\UnicenterAutoSysJM\autosys\dbobj\dbtype\
directory, where dbtype is MSQ (MSSQL), ORA (Oracle), or SYB (Sybase).
5.
Enable the second database:

a.
Open the Unicenter AutoSys JM Administrator from the program group

and select Instance from the AutoSys menu.
b.
(Optional) Enter the name of the computer on which the Event Server
is installed in the Computer field, and click Connect.
Note: By default, the Computer field contains the name of the
computer you are logged on to, but you can connect to a remote
computer to administer the instance information by specifying the
appropriate computer name.
c.
Select the instance with which the Event Server is associated from the
AutoSys Instance list, and click OK.
d.
Select Event Server from the AutoSys menu.

The Unicenter AutoSys Event Server screen opens.
e.
Click Enable to start the disabled Event Server.

The selected Event Server starts.
f.
Click OK.
The Unicenter AutoSys Event Server screen closes.
6.
Start the Scheduler:

a.

b.
Select the Scheduler from the Service list, and click Start Service.
Note: The Scheduler marks both Event Servers as being in Dual Event
Server mode. Unicenter AutoSys JM Client processes and commands check
the flags in both Event Servers for consistency; therefore, you must start
the Scheduler before running any other commands.
7.
Select the Application Server service from the Service list, and click Start
Service.
The Application Server starts.
250 User Guide
To return to Dual Event Server mode after a rollover

1.
Run the following command at a UNIX command prompt to stop the

Primary, Shadow, and Tie-breaker Schedulers:
uajm_sched.$AUTOSERV stop
The Primary, Shadow and Tie-breaker Schedulers stop.

2.

Application Server:
uajm_server.$AUTOSERV stop

3.
Run one of the following scripts as appropriate to synchronize the Event

Servers:
For Oracle, run autobcpORA.pl
For Sybase, run autobcpSYB.pl
Note: The autobcpDB script is located in the $AUTOSYS/dbobj/dbtype

directory, where dbtype is ORA (Oracle), or SYB (Sybase).
4.
Edit the $AUTOUSER/config.$AUTOSERV configuration file on the server

computer to remove the rollover comment from the EventServer line that
defines the server that went off line. The Scheduler commented out this
line during the rollover to Single Event Server mode.
5.
Run the following command at a UNIX command prompt to start the

Scheduler:
eventor

Note: The Scheduler marks both Event Servers as being in Dual Event
Server mode. Unicenter AutoSys JM Client processes and commands check
the flags in both Event Servers for consistency; therefore, you must start
the Scheduler before running any other commands.
6.

Application Server:
uajm_server.$AUTOSERV start
Synchronize the Event Servers

Before you start the Scheduler and Application Server, you must synchronize
the Event Server databases. Unicenter AutoSys JM provides autobcpDB scripts
to synchronize the Event Server databases. These scripts identify one
database as the source and the other database as the target for the
synchronization process.
Before you synchronize the Event Servers, check the following:
Make sure that both the Event Servers are running.
Make sure that no Unicenter AutoSys JM Schedulers, Application Servers,

or GUI applications are running.
Make sure that the Event Servers have unique names (for example,
eventserver1::mdb and eventserver2::mdb).
For Microsoft SQL Server, make sure both databases are defined correctly.
Use the Microsoft SQL Enterprise Manager to view the information.
For Oracle, make sure the TNSNAMES.ORA file contains valid entries for
both Event Servers.
For Sybase, make sure the SQL.INI file contains entries for both Event
Servers.
Know the path to the database software so you can supply it when you run
the autobcpDB script.
Make sure you have at least as much free disk space as the size of your
database for the temporary file that autobcpDB script creates. The script
deletes this temporary file after the synchronization process is complete.
Note: When you stop the Scheduler, any jobs that are running run to
completion. You can run the autobcpDB script while the jobs are running on
remote computers. In the worst-case scenario, there may be events on the
source Event Server that are not stored on the target Event Server. This is not
a problem, because the Scheduler always reads from both Event Servers. If
the Scheduler 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 Event Servers.
252 User Guide
To synchronize the Event Servers

1.
Log on to a database machine as the EXEC Superuser, make sure that no

one is running JIL or using the Unicenter WCC GUI to change job
definitions, and enter the following command to stop the Scheduler:

stops.
2.
select Services from the AutoSys menu.
3.
Select the Application Server from the Service list, and click Stop Service.
4.
Enter the following command at an instance command prompt:

cd %AUTOSYS%\dbobj\dbtype
dbtype
Specifies the type of database in use: MSQ (Microsoft SQL), ORA
(Oracle), or SYB (Sybase).
5.
Run the appropriate command for your database type:

For Microsoft SQL Server, enter the following command:
perl autobcpMSQ.pl source_server source_db destination_server destination_db
autosys_password dump_file
For Oracle, enter the following command:

perl autobcpORA.pl source_instance destination_instance autosys_password
dump_file oracle_path
For Sybase, enter the following command:

perl autobcpSYB.pl source_server source_db destination_server destination_db
autosys_password
Defines the password for the autosys user (by default, the autosys
user password is autosys).
destination_db
Defines the destination Microsoft SQL Server or Sybase database.
destination_instance
Defines the destination Oracle instance (for example, AUTOSYSDB2).
destination_server
Defines the destination Microsoft SQL Server or Sybase database (for
example, AUTOSYSDB2). For Sybase, this is defined in the SQL.INI
file.
dump_file
Defines the temporary file used in the transfer of data from one
database to the other.
source_db
Defines the source Microsoft SQL Server or Sybase database (for
example, autosys).
source_instance
Defines the source Oracle instance (for example, AUTOSYSDB).
source_server
Defines the name of the source Microsoft SQL Server or Sybase server
(for example, AUTOSYSDB). For Microsoft SQL Server, see the
Microsoft SQL Enterprise Manager. For Sybase, this is defined in the
SQL.INI file.
The Event Servers are synchronized.
6.

the server computer and select Event Server from the AutoSys menu.
Click Enable on the Event Server that went offline to bring it back online.
The Scheduler disabled this Event Server during the rollover to Single
Event Server mode. Click OK to save the changes and exit the Event
Server screen.
7.
In the Unicenter AutoSys JM Administrator, select Services from the

AutoSys menu.
8.
Select the Scheduler from the Service list, and click Start Service.
9.
Select the Application Server from the Service list, and click Start Service.
254 User Guide
To synchronize the Event Servers

1.
Log on to a server machine as the EXEC Superuser, make sure that no one
is running JIL or using the Unicenter WCC GUI to change job definitions,
and enter the following command to stop the Scheduler:

stops.
2.

Application Server:
uajm_server.$AUTOSERV stop

3.
Run the appropriate command for your database type:

For Oracle, run the following command:
perl autobcpORA.pl source_instance destination_instance autosys_password
dump_file oracle_path
For Sybase, run the following command:

perl autobcpSYB.pl source_server source_db destination_server destination_db
autosys_password
Defines the password for the autosys user (by default, the autosys
user password is autosys).
destination_db
Defines the destination Sybase database.
destination_instance
Defines the destination Oracle instance (for example, AUTOSYSDB2).
destination_server
Defines the destination Sybase server (for example, AUTOSYSDB2).
For Sybase, this is defined in the interfaces file.
dump_file
Defines the temporary file used in the transfer of data from one
database to the other.
source_db
Defines the source Sybase database (for example, autosys).
source_instance
Defines the source Oracle instance (for example, AUTOSYSDB).
source_server
Defines the name of the source Sybase server (for example,
AUTOSYSDB). For Sybase, this is defined in the interfaces file.
The Event Servers are synchronized.
4.
Edit the $AUTOUSER/config.$AUTOSERV configuration file on the server

computer to remove the rollover comment from the EventServer line that
defines the sever that went off line. The Scheduler commented out this
line during the rollover to Single Event Server mode.
5.
Run the following command to restart the Scheduler:

eventor
The Scheduler prints a message indicating that it is in Dual Event Server

mode.
6.

Application Server:
uajm_server.$AUTOSERV start

Note: If Unicenter AutoSys JM is configured to run in Dual Event Server mode,
the Scheduler will not start unless both databases are available.
256 User Guide
Handle Errors
If the autobcpDB script detects an error, the script exits and displays the
following message:
The AutoSys data server is not accessible.
Please check the data server and rerun this script.
If this happens, verify the following, and rerun the autobcpDB script:
Are both Event Servers started?

To verify this, make sure you can connect to the database.
For Microsoft SQL Server, look for the following services:

MSSQLSERVER, SQLSERVERAGENT
For Oracle, look for the following services (where * indicates the
Oracle SID): OracleService*, OracleStart*, and OracleTNSListener.
For Sybase, the service name is user-configurable.
Did you specify the source and the target databases correctly in the
autobcpDB script?
Did you enter the passwords correctly in the autobcpDB script?
Did you set the Sybase or Oracle environment variables correctly?
The Oracle environment variable, ORACLE_HOME, defines the path to

the top-level Oracle directory.
The Sybase environment variables are DSQUERY and SYBASE. The

DSQUERY variable defines the name of the Sybase Event Server. The
SYBASE variable defines the complete path to the Sybase software
directory.
Did you specify the Event Server names and ports correctly?
For Microsoft SQL Server, this information can be viewed in the

Microsoft SQL Enterprise Manager.
For Oracle, this information is located in the TNSNAMES.ORA file.
For Sybase, this information is located in the interfaces file.
Note: The Scheduler marks both Event Servers as being in Dual Event Server
mode. Unicenter AutoSys JM Client processes and commands check the flags
in both Event Servers for consistency; therefore, you must start the Scheduler
before running any other commands.
High Availability Recovery

Running Unicenter AutoSys JM with the High Availability and Dual Event Server
options provides protection from interruption of service due to network and
database failures. This section describes the behavior of the Scheduler and
Application Server when a failure is detected and how Unicenter AutoSys JM
attempts to recover.
Detect Missing Databases

When the Scheduler or Application Server fails to update one of the databases
while running in Dual Event Server mode, Unicenter AutoSys JM pauses the
run while it attempts to re-establish the connection with the database. You can
configure the number of reconnection attempts Unicenter AutoSys JM makes
before rolling over to Single Event Server mode.
To detect missing databases

1.
Open the Unicenter AutoSys Event Server screen of the Unicenter AutoSys
JM Administrator and locate the DB Event Reconnect configuration
parameter.
2.
Enter the number of times the Scheduler should attempt to reconnect to

the database before rolling over.
The number of reconnect attempts is configured.
Only the Primary and Shadow Schedulers roll over to Single Event Server
mode when the number of reconnection attempts is exceeded. The Primary or
Shadow Scheduler performs the following actions during a database rollover:
258 User Guide
Sends a DB_ROLLOVER alarm to the Event Server.
Updates the Event Server to reflect that the system is running in Single
Event Server mode.
Updates the status of the failed Event Server in the Windows registry. This
registry entry activates the Enable button corresponding to the failed
Event Server in the Event Server screen of the Unicenter AutoSys JM
Administrator utility.
To detect missing databases

1.
Open the Unicenter AutoSys JM configuration file and locate the

DBEventReconnect configuration parameter.
2.
Enter the number of times the Scheduler should attempt to reconnect to

the database before rolling over.
The number of reconnect attempts is configured.
Only the Primary and Shadow Schedulers roll over to Single Event Server
mode when the number of reconnection attempts is exceeded. The Primary or
Shadow Scheduler performs the following actions during a database rollover:
Sends a DB_ROLLOVER alarm to the Event Server.
Updates the Event Server to reflect that the system is running in Single
Event Server mode.
Saves a copy of the current Unicenter AutoSys JM configuration file as

config.rollover.$AUTOSERV, where $AUTOSERV identifies the instance. The
EventServer configuration parameter of the file is changed to include the
active Event Server.
The Tie-breaker Scheduler and the Application Server do not automatically roll
over to Single Event Server mode. They maintain both their connections to the
database and try to reconnect until they receive notification from either the
Primary or Secondary Schedulers to roll over.
Note: The Application Server does not service API requests from Unicenter
AutoSys JM Clients from the time the Application Server detects the failure of
one of the databases until the time it receives notification to roll over.
If any of the components lose all of their database connectivity, either before
or after database rollover occurs, the components shut down. If the Scheduler
or Application Server receives a request to shut down, the database
reconnection process is interrupted immediately after the active connection
attempt is completed.
Configure the Scheduler Heartbeat Interval

In High Availability mode, the Primary, Shadow, and Tie-breaker Schedulers
update the database with their statuses at regular intervals. If a Scheduler
does not update the databases after two intervals, that Scheduler is
unavailable and the system leaves High Availability mode. You can configure
the length of each interval.
To configure the Scheduler Heartbeat Interval

1.
Open the Unicenter AutoSys Scheduler screen of the Unicenter AutoSys JM

Administrator utility and locate the HA Poll Interval configuration
parameter.
2.
Enter the interval (in seconds) to allow between status polls.

The interval is configured.
To configure the Scheduler Heartbeat Interval

1.
Open the Unicenter AutoSys JM configuration file and locate the

HAPollInterval configuration parameter.
2.
Enter the interval (in seconds) to allow between status polls.

The interval is configured.
In Single Event Server mode, the system enters High Availability mode when
both the Primary and Shadow Schedulers are running. If the Shadow
Scheduler does not update the database for two consecutive intervals, the
Primary Scheduler issues an EP_HIGH_AVAIL alarm with a message to indicate
that the Shadow Scheduler has not updated its status. If the Shadow
Scheduler returns and posts updates at regular intervals, the system re-enters
High Availability mode. If the Primary Scheduler does not update the database
for two consecutive intervals, the Shadow Scheduler issues an
EP_HIGH_AVAIL alarm with a message to indicate that the Primary has not
updated its status. It proceeds to fail over and become the new Primary
Scheduler. If the original Primary Scheduler returns, it detects that the
Shadow Scheduler has failed over and shuts down. The system remains in
failover status until the Primary Scheduler is shut down.
In Dual Event Server mode, the system enters High Availability mode when
the Primary, Shadow, and Tie-breaker Schedulers are running. The detection
and failover procedure is the same as in Single Event Server mode. However,
before either Scheduler makes the final decision to fail over, it also verifies if
the Tie-breaker Scheduler has sent regular updates. If either the Primary or
Shadow Scheduler fails to detect two consecutive updates from its counterpart
and the Tie-Breaker Scheduler, that Scheduler shuts itself down.
260 User Guide
Recovery Scenarios Summary

The following sections summarize the recovery behavior of Unicenter AutoSys
JM after a point of failure. The recovery scenarios apply to Single Event Server
mode and Dual Event Server mode, as well as to non-High Availability and
High Availability modes.
Non-High Availability in Single Event Server Mode

If the connection to the single Event Server is lost, Unicenter AutoSys JM takes
the following actions:
The Scheduler attempts to reconnect to the database for the configured

number of times. If the Scheduler cannot reconnect, it shuts down.
The Application Server attempts to reconnect to the database for the

configured number of times. If the Application Server is unable to
reconnect, it shuts down.
Non-High Availability in Dual Event Server Mode

If the connection to one of the Event Servers is lost, Unicenter AutoSys JM
takes the following actions:

number of times. If it cannot reconnect, it rolls over and notifies the
Application Server.

configured number of times. It continues to attempt to reconnect to the
database at regular intervals until one of the following occurs:
It re-establishes a connection.
It receives notification to roll over.
It receives a shutdown request.
If the connections to both Event Servers are lost, Unicenter AutoSys JM takes

number of times. If it cannot reconnect, it rolls over and notifies the
Application Server. If the Scheduler fails to connect to the second
database after the configured number of times, it shuts down.

It detects the loss of the second Event Server and shuts itself down.
High Availability in Single Event Server Mode

If the Primary Scheduler becomes unavailable, the Shadow Scheduler issues
an EP_ROLLOVER alarm and fails over as the new Primary Scheduler.
If the Shadow Scheduler becomes unavailable, the Primary Scheduler issues
an EP_HIGH_AVAIL alarm and continues to run.
If the Event Server connection is lost, Unicenter AutoSys JM takes the
following actions:
262 User Guide

number of times. If it cannot reconnect, it shuts itself down.

configured number of times. If it cannot reconnect, it shuts itself down.
High Availability in Dual Event Server Mode

If the Primary Scheduler becomes unavailable, the Shadow Scheduler issues
an EP_ROLLOVER alarm and fails over as the new Primary Scheduler.
If the Shadow Scheduler becomes unavailable, the Primary Scheduler issues
an EP_HIGH_AVAIL alarm and continues to run.
If the Tie-breaker Scheduler becomes unavailable, the Primary Scheduler
issues an EP_HIGH_AVAIL alarm and continues to run.
If the connection to one of the Event Servers is lost, Unicenter AutoSys JM
takes the following actions:
The Primary Scheduler attempts to reconnect to the database for the

configured number of times. If it cannot reconnect, it rolls over and
notifies the Application Server. The Primary Scheduler then checks for
status updates from the Shadow and Tie-breaker Schedulers. If the
Shadow and Tie-breaker Schedulers have updated the Event Server, the
Primary Scheduler continues to run. If neither the Shadow nor the
Tie-breaker Schedulers update the Event Server in two consecutive poll
intervals, the Primary Scheduler shuts down. If only the Shadow Scheduler
did not update the Event Server in two consecutive polling intervals, the
Primary Scheduler issues an EP_HIGH_AVAIL alarm and continues to run.
The Shadow Scheduler attempts to reconnect to the database for the

configured number of times. If it cannot reconnect, it rolls over and
notifies the Application Server. The Shadow Scheduler then checks for
status updates from the Primary and Tie-breaker Schedulers. If the
Primary and Tie-breaker Schedulers have updated the Event Server, the
Shadow Scheduler continues to run. If neither the Primary nor the
Tie-breaker Schedulers update the Event Server in two consecutive poll
intervals, the Shadow Scheduler shuts down. If only the Primary Scheduler
did not update the Event Server in two consecutive poll intervals, the
Shadow Scheduler fails over and becomes the new Primary Scheduler.
The Tie-breaker Scheduler attempts to reconnect to the database for the

In the meantime, it continues to update the accessible database with its

status.

If the connections to both Event Servers are lost, Unicenter AutoSys JM takes
The Primary and Shadow Schedulers attempt to reconnect to the database

for the configured number of times, then roll over and notify the
Application Server. If the Schedulers fail to connect to the second
database after the configured number of times, they shut down.
The Tie-breaker Scheduler attempts to reconnect to the database for the

264 User Guide
It detects the loss of the second Event Server to shutdown.

It detects the loss of the second Event Server to shutdown.
Chapter 13: Configuring Unicenter

AutoSys JM
You can configure Unicenter AutoSys JM for Windows and UNIX applications.
You can configure Unicenter AutoSys JM on Windows using the options

available in the Unicenter AutoSys Administrator. For information about these
options, see the Online Help.
The parameters required to configure Unicenter AutoSys JM on UNIX

using are explained in the subsequent sections of this chapter.
Configuration File (see page 266)
Configure File Parameters (see page 266)
Sample Configuration File (see page 267)
auto.profile File (see page 288)
Configuring Remote Authentication (see page 291)
Client-Side Security (see page 292)
User-Defined Alarm Callbacks (see page 293)
Configuring Unicenter AutoSys JM 265
Configuration File
Configuration File
UNIX run-time behavior is controlled by the parameters in the
configuration file and the environment variables set in the /etc/auto.profile
file.
Upon startup, Unicenter AutoSys JM reads the configuration file to verify its
behavior, including which databases to connect to and how to react to certain
error conditions. In particular, the Scheduler bases much of its run-time
behavior on the parameters found in this file. If you change the settings in the
configuration file, you must stop and restart the Scheduler so that it can read
the new settings.
The configuration file has the following name:
$AUTOUSER/config.$AUTOSERV
The file is instance-specific, and the $AUTOSERV value is the name of the
instance with which the configuration file is associated. The $AUTOSERV value
must be three uppercase alphabetic characters and must be unique to each
instance.
Note: Events have a unique ID called eoid, which is prefixed by the first three
letters of $AUTOSERV value. This ensures an event's uniqueness and
traceability across multiple instances.
Configure File Parameters

You can modify the parameters in the configuration file to control
Unicenter AutoSys JM behavior and optimize your system.
The Scheduler only reads the settings in the configuration file on startup only.
Therefore, if you make changes to the file, you must stop and restart the
Scheduler for it to read the new settings.
To stop and restart the Scheduler
1.
Issue the following command:

The Scheduler stops.

2.
Issue the following command:

eventor
The Scheduler restarts.
266 User Guide
Sample Configuration File

Unicenter AutoSys JM includes a sample configuration file, located at
$AUTOSYS/install/data/config.ACE. You can reference this file as you read
through this chapter or use it as the basis for your own configuration file. We
recommend that you make a copy of the sample configuration file before you
modify it.
DBLibWaitTime ParameterConfigure Database Time-Out Period (Sybase Only)

The DBLibWaitTime configuration parameter specifies the amount of
time the Scheduler will wait before breaking the connection with an Event
Server that is in an unknown state. The Scheduler continually maintains and
verifies its connections with the databases, and when an Event Server enters
an unknown state, the Scheduler will break the connection after the wait time
specified by the DBLibWaitTime parameter.
The following line in the configuration file sets the timer for 90 seconds:
DBLibWaitTime=90
Typically, the database should never time out. However, if it does, Unicenter
AutoSys JM attempts to reconnect to the database the number of times
specified by the DBEventReconnect parameter. If the database connections
time out often, it probably indicates some kind of computer or data server
contention problem.
Note: If you set this value to DBLibWaitTime=0, no time-out value is applied
and the connection is continuous. Because it can cause the Scheduler to hang,
we do not recommend this setting.
SNMP Connections
Unicenter AutoSys JM can be integrated with Hewlett-Packard's Node
Manager software, versions 4.10 or higher. This enables OpenView users to do
the following:
Monitor all alarms generated by Unicenter AutoSys JM.
Monitor all UNIX signals received by the Scheduler.
Specify that certain commands be issued when an alarm or signal is

received by OpenView.
Unicenter AutoSys JM uses the Simple Network Management Protocol (SNMP)

to send alarms and signals to OpenView and uses the SNMP trap mechanism
to post alarms and signals.
Note: When the Scheduler receives a UNIX signal, it posts an SNMP event to
OpenView. This can be particularly useful if a signal has been sent that shuts
down the Scheduler. The signal is posted to OpenView before the Scheduler
shuts down.
To integrate with OpenView, you must configure the SnmpManagerHosts and
SnmpCommunity parameters so OpenView can detect alarms.
SnmpManagerHosts ParameterDefine Computers that Send SNMP Traps
The SnmpManagerHosts parameter specifies the computers to which the

UNIX Scheduler will send SNMP traps. It contains a list of computers on the
network that are running SNMP managers, such as HP's OpenView or IBM's
NetView, and to which you want to send SNMP traps (for example, post SNMP
events). When you enter the name of a computer with this parameter, you
enable this functionality.
The entry in the configuration file resembles the following:
SnmpManagerHosts=host1,host2
SnmpCommunity ParameterDefine Community for All SNMP Traps
The SnmpCommunity parameter specifies the SNMP community

associated with all SNMP traps sent. This parameter is effectively a password
that SNMP managers such as OpenView can be use to filter SNMP traps. This
value is almost always public, and so the entry in the Unicenter AutoSys JM
configuration file usually resembles the following:
SnmpCommunity=public
268 User Guide
DBEventReconnect ParameterSet Number of Scheduler Connection Attempts

You can configure Unicenter AutoSys JM to attempt to connect and
reconnect to databases a specified number of times. This behavior occurs on
the first attempt to connect to the database, and when a database connection
is lost and a reconnect attempt is made. This database connection behavior
also sets the rollover criteria for Dual Event Server mode.
The DBEventReconnect parameter controls the number of times a Scheduler
should attempt to connect (or reconnect) to an Event Server before shutting
down, or before rolling over to Single Event Server mode. This parameter is
used on startup and when there is a connection problem at run time.
In Single Event Server mode, the DBEventReconnect parameter is set to a
simple number as follows:
DBEventReconnect=50
This setting specifies that the Scheduler should attempt to connect with the
Event Server 50 times. If it cannot connect after 50 attempts, the Scheduler
shuts down.
In Dual Event Server mode, the DBEventReconnect parameter contains two
values (separated by a comma) that describe the connection and rollover
behaviors, as follows:
DBEventReconnect=50,5
This setting specifies that the Scheduler should attempt five connections with
the Event Servers. If it cannot connect after five attempts, the Scheduler rolls
over to Single Event Server mode, marking the other Event Server as down.
When in Single Event Server mode, the Scheduler attempts to connect with
the Event Server 50 times. If the Scheduler cannot connect to the Event
Server, it assumes there is a connection or configuration problem, and shuts
down.
EDNumErrors and EDErrTimeInt ParametersDefine Error Threshold

To guard against cascading errors, which can occur when the Scheduler
automatically reissues failed directives, you can set the EDNumErrors and
EDErrTimeInt parameters. The EDNumErrors parameter specifies the
maximum number of errors that can occur during the interval specified by the
EDErrTimeInt parameter. These parameters work together to force Unicenter
AutoSys JM to automatically shut the Scheduler down if too many errors occur
during the specified interval.
The primary reason for setting these parameters to shut the Scheduler down
in this situation is to avoid starting any new processes while there are serious
problems in the system.
The default settings specify to shut the processor down if more than 20 errors
occur within 60 seconds; the corresponding entries in the configuration file are
as follows:
EDNumErrors=20
EDErrTimeInt=60
FileSystemThreshold ParameterSet Minimum Scheduler Log Disk Space

The Scheduler shuts down if there is less than 8196KB (8MB) of disk
space available to write to the Scheduler log file (event_demon.$AUTOSERV).
If the amount of disk space falls below that specified by the
FileSystemThreshold parameter, the Scheduler issues warnings similar to the
following:
CAUAJM_W_40358 The disk partition containing the Unicenter AutoSys JM Scheduler log file is full
CAUAJM_W_40359 The Unicenter AutoSys JM Scheduler will shutdown if partition has less than
8,388,608 bytes available.
The default FileSystemThreshold setting is 20480KB (20MB). Valid settings

must be less than 102400KB (100MB) and greater than 8192KB (8MB).
If the amount of disk space falls below 8192KB (8MB), the Scheduler issues an
EP_SHUTDOWN alarm, shuts down, and displays messages similar to the
following:
CAUAJM_W_40360 Error: No disk space left to write the Unicenter AutoSys JM Scheduler log file.
CAUAJM_I_40247
CA Unicenter AutoSys JM Scheduler processing of events complete.
CAUAJM_I_40248
CA Unicenter AutoSys JM Scheduler shutdown complete.
Exiting.
The entry in the configuration file resembles the following:

FileSystemThreshold=20480
270 User Guide
DBMaintTime and DBMaintCmd ParametersConfigure Automatic Database

Maintenance
To reschedule daily database maintenance, define the DBMaintCmd and
DBMaintTime parameters in the configuration file. Use a 24-hour format for
the time entry.
DBMaintTime
Defines the time of day at which the Scheduler should run internal
database maintenance.
Default: 03:30
DBMaintCmd
Defines the maintenance command to run at the time specified in the
DBMaintTime parameter.
Default: $AUTOSYS/bin/DBMaint
The configuration file contains the following default entries:
DBMaintTime=03:30
DBMaintCmd=$AUTOSYS/bin/DBMaint
EvtTransferWaitTime ParameterSet the Event Transfer Time-Out for Dual Event

Server Mode
When you run Unicenter AutoSys JM in Dual Event Server mode, the
Scheduler copies missing events from one Event Server to the other after a
time-out delay specified in the EvtTransferWaitTime parameter in the
configuration file. Typically, you need not modify the default setting (5
seconds).
The configuration file contains the following record, which sets the default
time-out of five seconds:
EvtTransferWaitTime=5
SendeventMaxRetries ParameterSet Maximum Number of sendevent Retries

The SendeventMaxRetries parameter defines the maximum number of
times that the sendevent command attempts to send an event to the Event
Server database.
For example, to set the number of retry attempts to 10, set the following value
in the configuration file:
SendeventMaxRetries=10
SendeventRetryInterval ParameterSet an Interval for sendevent Retries

The SendeventRetryInterval parameter specifies the interval, in
seconds, between attempts to send an event to the Event Server. There is no
default value.
For example, to set the interval to 15 seconds, set the following value in the
configuration file:
SendeventRetryInterval=15
272 User Guide
Check_Hearbeat ParameterSet the Interval Between Heartbeat Checks

You can program your user applications to send heartbeats that the
Agent monitors to check their continued progress. A heartbeat is a signal
(SIGUSR2) sent from the application to the Agent that started the application.
That Agent then sends a HEARTBEAT event to the Event Servers.
The Scheduler verifies that the HEARTBEAT event has occurred during the
heartbeat interval specified for the job.
The Scheduler, and not the Agent, checks if there is a HEARTBEAT between
the Agent and the Event Servers, and sends an alarm if the HEARTBEAT is
absent. Therefore, the HEARTBEAT option also provides a good indication of
the stability of the network.
The Check_Heartbeat parameter defines the interval (in minutes) that the
Scheduler uses when checking for heartbeats. If there are no applications
sending heartbeats, you need not set this parameter. By default, this
parameter is commented out in the configuration file.
For example, to instruct the Scheduler to check for missing heartbeats every
two minutes, set the following value in the configuration file:
Check_Heartbeat=2
AutoRemoteDir ParameterDefine a Directory for Agent Logging

At any time, the Agent writes output messages to files in the directory
specified by the AutoRemoteDir parameter. By default, the /tmp directory is
used for Agent logging.
Note: For some operating systems, locking of files located in the /tmp
directory is not supported (for example, on SunOS platforms when /tmp is
mounted on tmpfs). In such cases, you must see the AutoRemoteDir
parameter to specify a different directory, because Unicenter AutoSys JM uses
the locks to check if the Agent is running.
The Scheduler passes the AutoRemoteDir parameter to the Agent when it
starts. As a result, the Agent log files directory must already exist, and it must
be writable on every computer that is running.
In a cross-platform environment (for example, where a UNIX Scheduler starts
a Windows Agent), the path to the log files directory is translated to the
format expected by the recipient platform. A UNIX Agent removes the drive
letter and colon, if present, and replaces \ characters with / characters. For
example, C:\tmp becomes /tmp. Similarly, a Windows Agent adds the system
drive letter and colon if they are not present, and replaces all / characters with
\ characters. For example, /tmp becomes C:\tmp.
directory (/tmp) for enterprise-wide logging:
AutoRemoteDir=/tmp
274 User Guide
CleanTmpFiles ParameterAutomatically Remove Temporary Agent Log Files

For each job, Unicenter AutoSys JM creates a file in the Agent log
directory on the computer where the job runs. If you set the CleanTmpFiles
parameter to 0 (off), these files remain on each computer until you use the
clean_files command to remove them.
Instead of using the clean_files command, you can set the CleanTmpFiles
value in the configuration file to 1 (on), as follows:
CleanTmpFiles=1
When you set CleanTmpFiles on, the Agent removes the /tmp/auto_rem* file
when its tasks complete successfully (assuming the AutoRemoteDir parameter
specifies the default /tmp directory).
The format of the Agent log file name (that is, of the auto_rem* file name) is
as follows:
auto_rem.joid.run_number.ntry
joid
Defines the unique job object ID associated with the job.
run_num
Defines the jobs run number.
ntry
Defines the number of tries or restarts.
If the Agent cannot run the job successfully, it does not remove the files
because they are useful for diagnosing the problem.
To view the Agent output file, use the autosys_log command on the client
computer as follows:
autosys_log -J job_name
job_name
Defines the name of the job for which to display the log file.
Regardless of how you set the CleanTmpFiles parameter, you should run the
clean_files command regularly to remove files from unsuccessful Agent
processes.
RemoteProFiles ParameterRedirect stderr and stdout Output to a File

When you set the RemoteProFiles parameter to 1 (on), it redirects
stderr and stdout output generated when /etc/auto.profile is sourced to a file.
RemoteProFiles value (1):
RemoteProFiles=1
The name of the file to which the product writes output is based on the log file
name, and has the following format:
auto_rem_pro.joid.run_number.ntry
joid
run_num
Defines the jobs run number.
ntry
This output file contains entries if anything specified in the profile fails. For
example, if the profile attempts to use setenv to set an environment variable,
the Bourne shell cannot process the C shell syntax. In this case, the output file
contains the following record:
setenv: not found
Non-fatal errors that occur when a profile is sourced are not recorded and do
not appear in the output file.
276 User Guide
To view the output file, use the autosys_log command on the Client computer
as follows:
autosys_log -J job_name -p
job_name
Defines the name of the job for which to display the log file.
This command displays the log file and appends the profile output, if there is
any. If no profile output file exists, the log file contains the following record:
File: profile_output_file Does Not Exist.
Note: If you set CleanTmpFiles to 1 (on), the output file is removed when the
job completes successfully, and the profile log information is not available. If
you set CleanTmpFiles to o (off), the file remains until you use the clean_files
command to remove it.
MaxRestartTrys ParameterSet the Maximum Number of Job Restart Attempts

If a job cannot be started because of system problems such as
computer unavailability, socket connection time-out, inability of the Agent to
start another process, or failure of the file system space resource check,
Unicenter AutoSys JM tries to restart the job. The number of restart attempts
is specified by the MaxRestartTrys parameter.
For example, to set the number of job restart attempts to five, set the
following value in the configuration file:
MaxRestartTrys=5
Notes:
The MaxRestartTrys parameter is instance-specific. You can configure it to

be machine-specific for a Unicenter AutoSys JM instance.
The MaxRestartTrys parameter governs retries that result from 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, when Unicenter AutoSys JM cannot find a file or a command, or
permissions are not properly set).
Configure the MaxRestartTrys Parameter to be Machine-Specific

The MaxRestartTrys parameter is instance-specific. You can configure the
MaxRestartTrys parameter to be machine-specific for a Unicenter AutoSys JM
instance.
To configure the MaxRestartTrys parameter to be machine-specific
1.
Create a configuration file named MaxRestartTrys.%AUTOSERV% (on

Windows) or MaxRestartTrys.$AUTOSERV (on UNIX) in the AUTOUSER
directory on the scheduler machine.
2.
In the configuration file, enter the following:

agent_name: value
agent_name
Specifies the name of the agent on the machine where you want to
define the MaxRestartTrys value.
value
Defines the maximum number of times the scheduler tries to restart a
job after a system or network problem occurs.
3.
Repeat Step 2 for each machine where you want to define the
MaxRestartTrys value.
Note: Each entry must begin on a new line.
4.
Save the file.

The MaxRestartTrys parameter is defined and is now machine-specific for
the Unicenter AutoSys JM instance.
Note: If you do not create the MaxRestartTrys.%AUTOSERV% (on Windows)

or MaxRestartTrys.$AUTOSERV (on UNIX) configuration file and add entries for
machines where you want to define the MaxRestartTrys value, the
MaxRestartTrys parameter is instance-specific.
278 User Guide
RestartConstant, RestartFactor, and MaxRestartWait ParameterCalculate Wait

Time Between Restart Attempts
Unicenter AutoSys JM uses the following formula to calculate the amount
of time (in seconds) between each attempt to restart a job:
WaitTime=RestartConstant+(Num_of_Tries*RestartFactor)
if WaitTime > MaxRestartWait,
then WaitTime = MaxRestartWait
RestartConstant
Indicates the minimum time (in seconds) to wait between each attempt to
restart a job.
Num_of_Tries
Identifies the value of the n_retrys attribute defined to a job.
RestartFactor
Indicates the time (in seconds) compounded to the RestartConstant. This
value multiplies with every job restart and is used to gradually increase
the number of seconds per retry attempt.
MachineMethod ParameterSpecify Load Balancing Method

The MachineMethod parameter defines the method used to check the
percentage of CPU cycles available on a real machine belonging to a virtual
machine. This method is used to help achieve load balancing. You can set the
MachineMethod parameter to the following values:
job_load
Verifies only the job load and does not require real-time usage of the
machine.
rstatd
Checks the CPU usage statistics of candidate machines.
If you set MachineMethod to rstatd, you must make sure that this demon
is running on all Client computers. To make sure that the demon is
running, do the following:
Edit the internet demon configuration file (/etc/inetd.conf) on all Client

computers, and uncomment the rstatd entry.
Send a SIGHUP signal (kill -1) to reset the running inetd process.
Sometimes, a kill -1 command is not sufficient to reset the inetd. If
rstatd fails, you might have to issue a kill -9 command, and restart
inetd. If necessary, check with your systems administrator.
Note: rstatd is not currently supported on NCR or Pyramid Client

computers.
vmstat
Checks the CPU usage statistics of candidate machines.
vmstat is the default MachineMethod value.
For example, to set the method to rstatd, set the following value in the
configuration file:
MachineMethod=rstatd
280 User Guide
KillSignals ParameterSpecify Signals for KILLJOB Events

The KillSignals parameter defines a comma-separated list of signals to
send to a job that is the target of a KILLJOB event. If the job is running on a
UNIX computer, the parameter defines one or more UNIX signals to send to
the job. If a comma-delimited list of signals is defined, the signals are sent in
the order listed, with five-second intervals between each call.
To preserve backward compatibility, the configuration file contains the
following entry:
KillSignals=2,9
We recommend that you set the KillSignals parameter to 15,9. In most cases,
this leads Unicenter AutoSys JM to return a TERMINATED state for the target
job. If it does not, set the KillSignals parameter to 9.
Note: The sendevent -k command overrides the KillSignals value in the
configuration file.
If the target job is running on a Windows computer, the KillSignals

parameter is ignored and the job is simply terminated.
AutoRemPort ParameterSet Legacy Agent Port Number

The Scheduler communicates to the Agent through a TCP/IP socket
connection. The AutoRemPort parameter defines the port number for this
socket connection. The internet services daemon (inetd) on the Client
computer uses the port number to point to the name of the service (found in
/etc/services). The service name is located in the inetd configuration file
(/etc/inetd.conf), where it finds the path to the legacy Agent binary.
It is possible to have different Unicenter AutoSys JM releases installed on the
same computer, where the versions are not cross-compatible between the
Scheduler and the Agent. By setting up multiple services and using different
port numbers, you can maintain multiple releases of the software.
The AutoRemPort value in the configuration file is set during installation. If you
change it, you must change the AutoRemPort value and the port numbers in
all /etc/services files on all Unicenter AutoSys JM Client and server computers.
The configuration file contains the following default entry:
AutoRemPort=5280
Note: If you use NIS or NIS+, and want to change the AutoRemPort value,
you must modify /etc/services on your NIS or NIS+ master and push it to all
Client computers, then run a kill -1 process on inetd.
282 User Guide
CrossPlatformScheduling ParameterActivate the Cross-Platform Interface

The CrossPlatformScheduling parameter defines how the cross-platform
interface runs.
To enable the cross-platform interface to run jobs directly on a Unicenter
Workload Agent, set the CrossPlatformScheduling parameter to 1.
To enable bi-directional scheduling support, set the CrossPlatformScheduling
parameter to 2. After enabling cross-platform scheduling with bi-directional
support, an instance can dispatch jobs to a Unicenter Workload Agent and
receive jobs from a Unicenter Job Scheduling Manager.
By default, the cross-platform interface is not activated during Scheduler
startup. The configuration file contains the following default entry:
CrossPlatformScheduling=0
Note: To make changes to the CrossPlatformScheduling parameter effective,

you must stop and restart the Scheduler.
More Information:
AutoInstWideAppend ParameterSpecify Whether to Overwrite Standard Error

and Standard Output
The AutoInstWideAppend parameter specifies whether an instance will
overwrite or append information to the standard error and standard output
files.
If you set this parameter to 0, the standard error and standard output files are
overwritten. If you set this parameter to 1 (the default), new information is
appended to the files.
AutoInstWideAppend=1
Each Client computer can use the AutoMachWideAppend variable in the

/etc/auto.profile file to override the instance-wide setting. The
AutoMachWideAppend variable is set as follows:
#AUTOENV#AutoMachWideAppend=TRUE
Note: If you are running jobs across operating systems, the Scheduler of the
issuing instance controls the default behavior.
To override either the instance-wide or machine setting in a job definition by
entering the following notation as the first characters in the standard output
and standard error file specifications:
>
Overwrite file
>>
Append file
Note: For Windows, the default is to overwrite the standard error and
standard output files.
284 User Guide
InetdSleepTime ParameterDefine Interval Between Job Starts for an Agent

The InetdSleepTime parameter controls how long (in seconds) inetd
waits between job starts on the same Agent computer. By default,
InetdSleepTime is set to 2, and there is no parameter in the configuration file.
To reduce the time the inetd waits between job starts on a computer, you can
add the InetdSleepTime parameter to the configuration file and lower the
value.
For example, to lower the InetdSleepTime setting to one second, add the
following entry to the configuration file:
InetdSleepTime=1
Note: Setting InetdSleepTime too low for your hardware could adversely
affect performance. You must also make sure your computer has a processor
fast enough to handle starting jobs at the shorter interval. Otherwise, frequent
socket connection failures will occur, causing numerous job restarts.
UnicenterEvents ParameterActivate Unicenter Event Integration

Before enabling Unicenter event integration, you must (at a minimum)
install the Unicenter Event Agent on the Scheduler computer.
When you set UnicenterEvents to 1 (on), Unicenter AutoSys JM forwards all
messages written to the Scheduler log to the Unicenter Event Management
console.
By default, UnicenterEvents is set to 0 (off).
UnicenterEvents=0
More Information:
Unicenter Integration (see page 341)
NotifyServerNode and NotifyAckTimeout ParametersActivate Unicenter

Notification Integration
Before enabling Unicenter notification integration, you must (at a
minimum) install the Unicenter Notification Agent on the Scheduler computer.
You must set the NotifyServerNode and NotifyAckTimeout parameters to
activate Unicenter Notification. When you set these notification parameters,
the Scheduler can send a notification to Unicenter Notification, assuming that
the job the Scheduler is processing was defined with the appropriate job
notification attributes.
NotifyServerNode
Defines the node name of the Unicenter Notification Services server.
NotifyAckTimeout
Defines the amount of time (in seconds) the Client waits for an
acknowledgement from the specified Unicenter Notification Services server
before timing out.
Default: 30
Unicenter Notification integration is inactive by default.
The configuration file contains the following example entry:
#NotifyServerNode=unshost
#NotifyAckTimeout=30
More Information:
286 User Guide
ServiceDeskCust, ServiceDeskURL, and ServiceDeskUser ParametersActivate

Unicenter Service Desk Integration
You must set either the ServiceDeskURL and ServiceDeskUser
parameters, or the ServiceDeskURL and ServiceDeskCust parameters to
activate Unicenter Service Desk integration. When these parameters are set
(and assuming that the job the Scheduler is processing has been defined with
the appropriate Unicenter Service Desk attributes), the Scheduler can open a
service desk ticket through Unicenter Service Desk.
ServiceDeskCust
Defines a valid Unicenter Service Desk customer ID.
ServiceDeskURL
Defines the URL of the Unicenter Service Desk server.
ServiceDeskUser
Defines user ID and password to use to log on to the specified Unicenter
Service Desk server.
Unicenter Service Desk integration is inactive by default.
The configuration file contains the following example entry:
#ServiceDeskURL=http://servicedeskhost:8080/axis/services/USD_R11_WebService
#ServiceDeskUser=<user/pw>
#ServiceDeskCust=
More Information:
auto.profile File
auto.profile File
The Agent is a process (called auto_remote) that is started so the
Scheduler can perform a specific task on a remote (Client) computer. The
Agent starts the command specified for a given job, sends running and
completion information about a task to the Event Server, and then exits.
The Agent starts on the Client computer as root. The Agent environment is
controlled through special descriptors in the /etc/auto.profile file, which is
located on the remote Client.
The /etc/auto.profile file serves two purposes:
It specifies a number of descriptors that set the environment for the Agent
on the Client computer. These descriptors are environment variables that
are preceded by the following characters:
#AUTOENV#
It specifies default settings for jobs that do not have a profile specified in
the job definition. A job profile sets environment variables for a job
immediately before the job starts.
A typical job reads /etc/auto.profile twice. First, the Agent reads the file, using
only the lines beginning with #AUTOENV# to set its own environment. Then, if
there is no explicit profile in the job definition, the Agent orders the shell to
read /etc/auto.profile before running the command for the job. The shell
interprets the entire file except lines beginning with #.
You should view the /etc/auto.profile file in a text editor to familiarize yourself
with the environment settings in it.
More information:
AutoInstWideAppend ParameterSpecify Whether to Overwrite Standard
Error and Standard Output (see page 284)
Client-Side Security (see page 292)
288 User Guide
auto.profile File
Sample auto.profile File

The following is an example auto.profile file for a typical Unicenter
AutoSys JM installation.
The Agent looks for the #AUTOENV# descriptors and reads the variables that
follow to set its environment.
Important! The #AUTOENV# descriptor is not a comment. Do not remove the
# characters from this file.
# Set Unicenter AutoSys JM Environmental Variables
#
# This must be a Bourne shell script,
# AND the variables exported for your command
# to have access to them.
# The AUTOSYS and AUTOUSER variables are needed if the job's command uses
# any Unicenter AutoSys JM programs.
# AUTOSYS is already set in the environment for auto_remote, the UAJM Agent.
# AUTOUSER can be different for each instance in the case statement below.
hostname=`$AUTOSYS/bin/autoflags -n`
case $AUTOSERV in
ACE)
AUTOUSER=/opt/CA/UnicenterAutoSysJM/autouser.ACE
test -f $AUTOUSER/autosys.sh.$hostname &&
. $AUTOUSER/autosys.sh.$hostname
;;
esac
export AUTOUSER
# Windowing system environment variable
DISPLAY=":0.0"
export DISPLAY
# set a PATH so executables can be found
PATH=".:$AUTOSYS/bin:$AUTOSYS/test/bin:/bin:/usr/bin:/usr/local/bin:/usr/openwin/
bin:/usr/bin/X11:/bin:/usr/ucb:/usr/etc"
export PATH
#############################################################################
# auto_remote Environment Variables
# OverrideAutoRemoteDir sets the log directory for this agent if the
# Scheduler is on a Windows machine or if its AutoRemoteDir value is
# otherwise unsuitable.
#AUTOENV#OverrideAutoRemoteDir=
# ISDBGACTIV controls debug traces in the agent log file.
# Values can be comma-separated:
# OFF = No traces
# MS = Add milliseconds to time in output
# LIGHT = Light traces
# HEAVY = full traces
auto.profile File
# DUMP = Cross-Platform Interface traces

# GBE = Scheduler Get Batch Event traces
# JOB = Job runtime traces
#AUTOENV#ISDBGACTIV=OFF
ISDBGACTIV ParameterSet Run Time Trace Level

The ISDBGACTIV parameter controls the level of trace information to
return to the Scheduler and Application Server logs. You can set the
ISDBGACTIV parameter to the following values:
OFF
Returns no trace information. This is the default value.
MS
Adds milliseconds to the time in the output.
LIGHT
Returns light trace information.
HEAVY
Returns full trace information.
DUMP
Traces data sent and received by the cross-platform interface.
GWB
Scheduler Get Batch Event traces.
JOB
Traces the run time of a job.
You must separate multiple values with commas, as follows:
ISDBGACTIV=JOB,DUMP
290 User Guide
Configuring Remote Authentication
Configuring Remote Authentication

You can use either of the following methods to configure remote
authentication:
UNIX ruserok() Authentication
When using this method, Unicenter AutoSys JM instructs a Client's Agent
to make the UNIX system ruserok() call. The ruserok() call checks the
Client computer's /etc/hosts.equiv and the user's .rhosts files to validate
that the requesting user is registered in that environment.
Unicenter AutoSys JM Agent Scheduler Authentication
When using this method, a specific Agent can be bound to one or more
Schedulers. In other words, an Agent must verify its permission to process
a Scheduler's requests before starting each job. The Agent does this by
reading the /etc/.autostuff file on the computer where it is running.
The EDIT Superuser can use the autosys_secure command to enable (or
disable) remote authentication. Remote authentication is disabled by default.
If you enable Agent Scheduler authentication, you must configure Unicenter
AutoSys JM to support it.
Configuring Unicenter AutoSys JM Scheduler Authentication

You can configure Agents to accept jobs only from trusted Schedulers.
To configure Unicenter AutoSys JM for Agent Scheduler Authentication, you
must do the following:
Enable Agent Scheduler authentication.
Create an ASCII file named.autostuff in the /etc directory of every Client

computer that participates in this authentication method.
After you complete these steps, the Agent only runs jobs submitted by
Schedulers listed in the .autostuff file.
Client-Side Security
The /etc/.autostuff File
The /etc/.autostuff file should have read and write permissions for root
only. Entries in this file must be in the following form:
AUTOSERV:hostname
AUTOSERV
Defines the three-character name of the Unicenter AutoSys JM instance
with which the trusted Scheduler is associated.
hostname
Defines the name of the host on which the trusted Scheduler is
associated.
Client-Side Security
The AUTOENV environment variable DENY_ACCESS restricts access to
the Agent computer.
You can use the auto.profile file for the Agent computer to specify a list of
users whose jobs are prohibited from running on that computer. The list is a
comma-delimited list of user names, with no spaces. The entry can contain up
to 512 characters. For example, you might specify the following in the
auto.profile file:
########################################################
#
auto_remote environment variables
DO NOT REMOVE
#AUTOENV#DENY_ACCESS=root,demon,admin
In this example, the Agent will not start jobs owned by root, demon, or admin.
If a job owned by one of these users is submitted to run on the Agent, the job
fails as if the job's owner did not have a valid account on the computer. There
will be no job restart attempts, regardless of the MaxRestartTrys setting in the
configuration file. When a job fails for this reason, the Scheduler log displays
the following error as a STARTJOBFAIL alarm on the job:
Permission ERROR:
292 User Guide
Could not SET uid=uid on Host: host
User-Defined Alarm Callbacks

User-defined alarm callbacks provide 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:
DB_ROLLOVER
Indicates that Unicenter AutoSys JM has rolled over from Dual Event
Server to Single Event Server mode.
DB_PROBLEM
Indicates that there is a problem with one of the databases.
EP_ROLLOVER
Indicates that the Shadow Scheduler is taking over processing.
EP_SHUTDOWN
Indicates that the Scheduler is shutting down due to an error condition.
EP_HIGH_AVAIL
The Tie-breaker Scheduler for resolving contentions between two
Schedulers cannot be reached, one of the Schedulers is shutting down, or
there are other Scheduler take-over problems.
To specify what executable should run as a user-defined callback for one of the
above alarms, you must create a file named notify.$AUTOSERV in the
$AUTOUSER directory. The $AUTOSYS/install/data/notify.ACE file provides the
following example:
# Notify for certain CRITICAL ALARMS
#
# Form is: ALARM executable
# We pass in $1 = numeric code
#
$2 = Text Message
# Only have 1 space between the ALARM and the executable

#
# The environment is inherited from the scheduler
# The following is executed: system( <executable>
# $1 $2 & );
#
#DB_ROLLOVER $AUTOUSER/notify_db
#DB_PROBLEM $AUTOUSER/notify_db
#EP_ROLLOVER $AUTOUSER/notify_ep
#EP_SHUTDOWN $AUTOUSER/notify_ep
#EP_HIGH_AVAIL $AUTOUSER/notify_ep
Notification Example
This example gives the process for instructing Unicenter AutoSys JM to
call the program /usr/local/bin/pager when the Scheduler shuts down:
1.
Copy the sample notification file from $AUTOSYS/install/data/notify.ACE to

$AUTOUSER/notify.$AUTOSERV
2.
Change the EP_SHUTDOWN line in the notification file to:

EP_SHUTDOWN /usr/local/bin/pager $@
When the Scheduler shuts down, Unicenter AutoSys JM passes the pager
program a numeric code and a text message. The pager itself must be
programmed to accept these parameters.
294 User Guide
Chapter 14: Dynamic Workload

Placement
The CA Management Database and Unicenter DSM (see page 296)
Dynamic Workload Placement Scenarios (see page 297)
Manage Machine Definitions with autodwp (see page 298)
Dynamic Workload Placement 295
The CA Management Database and Unicenter DSM
The CA Management Database and Unicenter DSM

Previous chapters explained how Unicenter AutoSys JM relies on real and
virtual machined definitions to perform load balancing and job queuing. In the
day-to-day production environment, you can add new machines to the
network and update software on existing machines, in such a way as to
change the environment's run-time characteristics. Dynamic workload
placement makes it possible for Unicenter AutoSys JM to use existing
Unicenter AutoSys JM machine definitions or the asset data collected by
Unicenter Desktop and Server Management (Unicenter DSM) to automatically
update Unicenter AutoSys JM machines or to dynamically generate virtual
machines.
The dynamic workload placement feature is made possible by the CA
Management Database (CA-MDB). The CA-MDB combines data from distinct
disciplines such as operations, storage, security, life cycle, and service
management, and provides the foundation necessary to manage and optimize
your IT infrastructures. The data contained in the CA-MDB is highly visible to
all CA products and makes cross-functional interoperability between solutions
possible. Unicenter DSM offers the ability to discover and classify any device
on a network, be it mainframe, server, workstation, router, switch, and so on.
As it discovers new devices, Unicenter DSM populates the CA-MDB with
information about the asset. The information Unicenter DSM collects and
stores in the CA-MDB includes:
Host name
Hardware vendor
Operating system
Primary network address
Installed software
Software status (active, disabled)
Asset status (online, shut down)
After the asset information is stored in the CA-MDB, it becomes available for
other CA products (including Unicenter AutoSys JM) to share.
296 User Guide
Dynamic Workload Placement Scenarios
Dynamic Workload Placement Scenarios

The Unicenter AutoSys JM Scheduler relies on the defined attributes of real
and virtual machines to decide whether it can schedule a job to run on a given
machine. As you add more machines to a production environment, or as the
software configuration of existing machines changes, maintaining the
Unicenter AutoSys JM machine definitions can become tedious. Similarly,
maintaining virtual machine definitions to take advantage of Unicenter
AutoSys JM's load-balancing and job queuing features can also pose a
challenge. Dynamic workload placement provides a way to efficiently manage
all Unicenter AutoSys JM machine definitions.
You might have an initial list of requirements for determining whether a
machine forms part of a virtual machine definition. For example, you might
choose to include a machine in your virtual machine definition based on
Unicenter AutoSys JM machine attributes such as the fully qualified name, the
type, the max_load value, the factor value, or even its online or offline status.
However, as these attribute values change, a machine that is currently part of
a virtual machine definition may no longer meet the criteria used to generate
the original list. Similarly, a machine that was not previously part of a virtual
machine can meet the requirements in the future to join the virtual machine
list. With the dynamic workload placement feature, Unicenter AutoSys JM can
keep your virtual machine definition current; refreshing it with an updated list
of machines that always meets your criteria.
Unicenter AutoSys JM benefits from integration with the CA-MDB. One such
benefit is the recognition of asset data collected by Unicenter DSM. You can
choose to expand your list of requirements for adding an existing machine to
the Unicenter AutoSys JM virtual machine list based on additional search
criteria such as the assets hardware vendor, operating system, installed
software, or hardware and software status. Unicenter AutoSys JM can also use
the expanded search criteria to automatically create Unicenter AutoSys JM
machine definitions for assets newly discovered by Unicenter DSM. In this
manner, you can use the dynamic workload feature combined with Unicenter
DSM to keep your enterprise up to date with the latest Unicenter AutoSys JM
machine definitions based on qualifying discovered assets.
Note: For more information, see the Unicenter DSM documentation.
Manage Machine Definitions with autodwp

The autodwp command maintains Unicenter AutoSys JM machine definitions.
With the command, you can generate or refresh a virtual machine definition
with machine names selected by the search criteria specified in a machine
conditions file. You can base the criteria in the machine conditions file on
Unicenter AutoSys JM machine attributes, asset data collected by Unicenter
DSM, or both.
To use autodwp to dynamically search and create new Unicenter AutoSys JM
machine definitions, enter the autodwp command at a command prompt with
the following parameters:
autodwp -f machine_conditions_file
To use autodwp to dynamically update only existing Unicenter AutoSys JM

machine definitions, enter the autodwp command at a command prompt with
the following parameters:
autodwp -f machine_conditions_file -u
machine_conditions_file
Defines the full path and name of the file containing the criteria for
determining which machines to include in the virtual machine. The syntax
of the search criteria in the file resembles the following:
<machine_query_type_meta-tag>
(attribute operator value) [boolean_operator (attribute operator value)]
...
</machine_query_type_meta-tag>
...
machine_query_type_meta-tag
Defines the type of search criteria. This value can be one of the
following:
MA_ATTRIB_QUERYDefines search criteria based on Unicenter
AutoSys JM machines.
CA_ASSET_QUERYDefines search criteria based on machines
discovered by Unicenter DSM.
attribute
Defines a valid machine search criteria attribute.
operator
Defines the operator to apply to the attribute. Valid operators are: >
(greater than), < (less than), = (equal to), != (not equal to), >=
(greater than or equal to), and <= (less than or equal to).
298 User Guide
value
boolean_operator
Defines the operator to use to join two or more expressions. Valid
Boolean operators are: && (and) and || (or).
Note: For more information about autodwp syntax, see the Reference Guide.
Example: Define Search Criteria Based on Unicenter AutoSys JM
Machines
This example shows the autodwp machine search criteria file entries for
refreshing a virtual machine definition with real UNIX or Windows Unicenter
AutoSys JM machines that are online:
<MA_ATTRIB_QUERY>
(MachineType=r || MachineType=n) && MachineStatus=o
</MA_ATTRIB_QUERY>
Example: Define Search Criteria Based on Machines Discovered by

Unicenter DSM
This example shows the autodwp machine search criteria file entries for
refreshing a virtual machine definition with active machines discovered by
Unicenter DSM that are running Unicenter AutoSys JM:
<CA_ASSET_QUERY>
CaAssetSoftware=AutoSys && (CaAssetHardwareAlive=true &&
CaAssetSoftwareAlive=true)
</CA_ASSET_QUERY>
Unicenter AutoSys JM Machine Attributes

This section lists the valid attributes for search criteria based on Unicenter
AutoSys JM machines. The listed attributes are only valid in the
MA_ATTRIB_QUERY XML-style meta-tags.
MachineName
Corresponds to the machine name in the Unicenter AutoSys JM machine
definition.
MachineQueName
Corresponds to the virtual machine name to which a machine belongs, as
defined in the Unicenter AutoSys JM machine definition.
MachineType
Corresponds to the type attribute in the Unicenter AutoSys JM machine
definition.
MachineFactor
Corresponds to the factor attribute in the Unicenter AutoSys JM machine
definition.
MachineMaxLoad
Corresponds to the max_load attribute in the Unicenter AutoSys JM
machine definition.
MachineStatus
Corresponds to the online or offline status of the machine. Valid values
are:
m for offline
o for online
300 User Guide
Unicenter DSM Discovered Machine Attributes

This section lists the valid attributes for search criteria based on machines
discovered by Unicenter DSM. The listed attributes are only valid in the
CA_ASSET_QUERY XML-style meta-tags.
CaAssetHostName
Corresponds to the host name of the asset discovered by Unicenter DSM.
CaAssetSoftware
Corresponds to the name of software installed on the asset discovered by
Unicenter DSM.
CaAssetVendor
Corresponds to the vendor of the asset discovered by Unicenter DSM.
CaAssetOS
Corresponds to the operating system of the asset discovered by Unicenter
DSM.
CaAssetNetwork
Corresponds to the primary network address of the asset discovered by
Unicenter DSM.
CaAssetSoftwareAlive
Corresponds to the status of software installed on the asset discovered by
Unicenter DSM. Valid values are True and False. The search is successful
only if the software is in active state.
CaAssetHardwareAlive
Corresponds to the status of the asset discovered by Unicenter DSM. Valid
values are True and False. The search is successful only if the machine is
up and running when the value is True.
Chapter 15: Troubleshooting

How System Components Are Affected When a Job Is Defined (see page 303)
Windows Services Troubleshooting (see page 304)
Event Server Troubleshooting (see page 305)
Scheduler Troubleshooting (see page 307)
Agent Troubleshooting (see page 314)
Job Failure Troubleshooting (see page 321)
Application Server Troubleshooting (see page 331)
How System Components Are Affected When a Job Is

Defined
Problems with Unicenter AutoSys JM usually involve interactions between the
major components instead of the individual components themselves. This
chapter presents a number of common problems, their symptoms, and
possible solutions. It provides useful information about troubleshooting the
primary components.
To troubleshoot Unicenter AutoSys JM more effectively, you must understand
the stages in the life of a job, the order in which they occur, and the roles
played by the four major components (that is, Application Server, Scheduler,
Agent, and Event Server).
When you define a job, Unicenter AutoSys JM saves its starting conditions to
the Event Server (database), and the following occurs:
When the job's starting conditions are met, the Scheduler starts an Agent
on the Client computer to run the job.
The Agent runs the job and returns the job's exit status to the Application
Server.
The Application Server updates the Event Server.
After the job completes, it does not run again until its starting conditions
are met.
Note: Sybase and Oracle are supported in UNIX, and MS SQL, Oracle and
Sybase are supported in Windows. Database-specific tools like SQLPLUS
(Oracle) and ISQL (Sybase/MS SQL) are recommended for any databasespecific tasks. You must use OSQL for MS SQL 2005, because ISQL is not
available; however, for the purposes of this documentation, the group ISQL
contains OSQL. XQL and ZQL have been phased out.
Troubleshooting 303
Windows Services Troubleshooting
Windows Services Troubleshooting

Valid on Windows
You can start the Application Server, Scheduler, and Agents from the
Services screen of the Unicenter AutoSys Administrator, and you can start the
Event Server (the Microsoft SQL Server, Oracle, or Sybase service) from the
Windows Services Control Manager. You can find details as to why a service
did not start in the Windows Event Viewer in the Administrative Tools program
group.
Typically, problems with starting services using the Unicenter AutoSys
Administrator indicate that the software was not successfully installed. In such
cases, the best approach is often to remove the existing Unicenter AutoSys JM
installation and reinstall it.
Note: For more information about how to remove Unicenter AutoSys JM, see
the Windows Windows or UNIX Implementation Guide. For more information
about starting services with the Administrator, see the Online Help.
To verify that the Event Server service (the database service) is started, look
at the Windows Services Control Manager.
If you are running Microsoft SQL Server, verify the status of the MSSQLServer
service.
If you are running Oracle, verify the status of the following services (substitute
your Oracle SID for the asterisk): OracleService*, OracleStart*, and
OracleTNSListener.
If you are running Sybase, verify that a service with a name that starts with
SYBSQL is started. It is possible that a different name was chosen for the
service when Sybase was installed.
304 User Guide
Event Server Troubleshooting

This section describes scenarios for troubleshooting the Event Server.
Event Server Is Down

Valid on Windows and UNIX
Symptom:
When you run the chk_auto_up command, a message similar to the following
is displayed:
Couldn't connect with Server: AUTOSYS:autosys
Solution:
Either the database server is down, or the process in question cannot access
the database server.
To confirm that the database server is down, log on to the Event Server and
look to see if the database processes are active.
If the database is running, the problem could be that Unicenter AutoSys JM is
configured to the wrong Event Server or communication between Unicenter
AutoSys JM and the Event Server is not configured correctly.
Troubleshooting 305
Deadlocks
Symptom:
A message similar to the following appears in the Scheduler log when viewed
with the autosyslog -e command or in the database server error log:
Your server command (process id #11) was deadlocked with another process and has
been chosen as deadlock victim. Re-run your command.
Solution:
A deadlock is a 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 release the lock, but the
second user will not release it until the lock on the first user's object is freed.
The database server detects the situation and chooses the user whose process
has accumulated the least amount of CPU time. The database server rolls back
that user's transaction, notifies the application with the indicated error
message, and lets the other user's processes continue.
The Application Server tries to rerun the command until it is successful or until
it has exceeded the maximum number of retries.
Not Enough User Connections

Symptom:
Unicenter AutoSys JM processes cannot make connections to the database;
they cannot start the Unicenter WCC GUI or send events.
Solution:
Verify the maximum number of user connections your system can support. If
the current number of connections does not exceed the capacity of your
environment, you can increase the number of user connections.
Note: For more information about increasing the maximum number of user
connections, contact your database administrator or see the database
documentation.
306 User Guide
Scheduler Troubleshooting
This topic describes Scheduler troubleshooting.
Output from the Scheduler is redirected to the following log file:
%AUTOUSER%\out\event_demon.%AUTOSERV%
To view this file, issue the autosyslog -e command. This command displays the
Scheduler log file and shows each job-related event as it occurs. To terminate
this reporting, press Ctrl+C.
The Scheduler log records every Scheduler action in the order it was
performed. Network problems are usually reflected in this file. This file is very
useful for reconstructing what happened when a problem occurs.
Troubleshooting 307
Scheduler Is Down
Symptom:
Jobs do not start.
When you run the chk_auto_up command, it returns a message similar to

the following (assuming your Scheduler was installed on the machine
EPhost):
Checking machine: EPhost
No Scheduler is running on machine: EPhost.
The Scheduler log has not registered a date and time stamp for a while.
The Scheduler log should register date and time stamps each minute.
Solution:
Do one of the following to confirm that the Scheduler is down:
Run the chk_auto_up command.
Run the autosyslog -e command to display the Scheduler log, and check
for date and time stamps.
Open the Services screen of the Unicenter AutoSys Administrator,

select the Scheduler from the Service list, and check the Status icon.
If the Scheduler is down, use the Unicenter AutoSys Administrator to
restart it. To do so, select the Scheduler from the Service list and click
Start Service. The Status field should change to Running, and the icon
should turn green.
Note: For information about the Unicenter AutoSys JM Administrator, see
the Online Help.
Check for running Unicenter AutoSys JM Scheduler processes.

If the Scheduler is down, run the eventor command to start it.
308 User Guide
Scheduler Will Not Start

Valid on Windows
Symptom:
The autosyslog -e command displays messages indicating that it cannot
connect to the database.
Solution:
The database is down or there are problems with the database. To correct this,
verify that the database is running and that you can connect to it. After you
have done this and the database is accessible, the Scheduler should be able to
connect.
Symptom:
The autosyslog -e command displays messages indicating that the

Scheduler log file does not exist, or that no entries were made when the
Scheduler service was started.
The Scheduler service does not remain running or never starts.
Solution:
Check for a file named event_demon.%AUTOSERV% in the directory specified
in the Enterprise-Wide Logging Directory field on the Scheduler screen of the
Unicenter AutoSys Administrator (by default, this directory is
%AUTOUSER%\out).
If the file exists, enter the following command at a command prompt to view
it:
type %AUTOUSER%\out\EVENT_DEMON.%AUTOSERV% | more
Correct the problems identified at the end of this file, and restart the
Scheduler.
Note: The Scheduler appends this file each time it starts.
Troubleshooting 309
Symptom:
The Scheduler does not remain running and does not write log output to the
%AUTOUSER%\out\event_demon.%AUTOSERV% file.
Solution:
This symptom could have various causes; and the resolution depends on which
of the following messages is displayed in the Windows event log. The Event
Log Viewer is located in the Administrative Tools program group.
The log file %AUTOUSER%\out\event_demon.%AUTOSERV% is
missing!
The Scheduler must have been started on the computer at least once or
this message appears. If the Scheduler has been started, make sure that
permissions are set on the log file that enables a system program to read
and write to it.
Incorrect options have been set to event_demon. It must not have
been set properly.
This occurs if you have modified the Windows Registry so that the -A
option is not used when starting the Scheduler service. To fix this problem
with the Windows Registry settings, you must uninstall Unicenter AutoSys
JM, and reinstall it.
The environment variable AUTOSYS is not set.
The %AUTOSYS% system environment variable is not available to the
Scheduler. In the Windows Control Panel, click the System icon and make
sure the %AUTOSYS% environment variable is set properly in the System
Environment Variables region. You can also check the setting of this
variable on the System screen of the Unicenter AutoSys Administrator.
The environment variable AUTOSYS is too long.
The %AUTOSYS% environment variable value is set to a path that is more
than 80 characters in length. Uninstall Unicenter AutoSys JM, and reinstall
it to a directory path that is fewer than 80 characters in length.
chk_auto_up process is missing. Scheduler not operational. Call Tech
support.
The Scheduler runs the chk_auto_up command upon initialization, and
that process has terminated without properly notifying the Scheduler. This
indicates a serious problem with your local system account. Try setting the
Scheduler to log on as the administrator. If this is successful, you can run
the Scheduler. However, we recommend that you consider uninstalling and
reinstalling Unicenter AutoSys JM.
310 User Guide
chk_auto_up times out while waiting for response from Application

Server
Verify whether the Application Server is running by viewing the Services
screen of the Unicenter AutoSys Administrator. On the screen, select the
Application Server from the Service list, and check the Status icon.
chk_auto_up is taking a while to complete...
The Scheduler runs the chk_auto_up command upon initialization, and it is
taking more than five minutes to complete. This might occur on large or
slow networks where the chk_auto_up command must query every
machine in the Authorized Scheduler Host Names list (located on the
Agent screen of the Unicenter AutoSys Administrator). To test for this
problem, run the chk_auto_up command at an instance command prompt,
and check how long it takes to complete. This message is only a warning,
and the Scheduler waits for the command to complete before starting.
Wait for chk_auto_up process failed. Windows Error Code
The Scheduler launches the chk_auto_up command upon initialization, and
it 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.
The Unicenter AutoSys JM environment has not been installed
correctly.
The Scheduler runs the chk_auto_up command upon initialization, and it
has reported that the setup is incorrect. Uninstall and reinstall Unicenter
AutoSys JM.
A Scheduler is already running. We will not start another one.
When the Scheduler was started, it detected another Scheduler running
with the same instance ID. Only one Scheduler can run in an instance.
Either stop the other Scheduler, or do not attempt to start this Scheduler.
Scheduler cannot open its log file event_demon.%AUTOSERV%. Some
directory in the path is not accessible to the SYSTEM.
The Scheduler could not create the normal log file named in the message.
Make sure that the log file has permissions that enable a system program
to read and write it. Also verify that the disk drive has not run out of
space.
Troubleshooting 311
Could not rename the LARGE Scheduler file:

event_demon.%AUTOSERV% to backup archive file:
event_demon.%AUTOSERV%.date. Fix file and directory permissions
so accessible by SYSTEM, or remove the files.
When the Scheduler starts, it checks the size of the
event_demon.%AUTOSERV% log file. If this file is larger than 256 KB, the
Scheduler tries to rename it to event_demon.%AUTOSERV%.date and
create a new event_demon.%AUTOSERV% log file. If the Scheduler cannot
do this, verify that event_demon.%AUTOSERV% has permissions that
enable a system program to read and write it. Also, verify that the disk
drive has not run out of space.
Scheduler Will Not Start

Valid on UNIX
Symptom:
The autosyslog -e command displays messages indicating that it cannot
Solution:
The database is down or there are problems with the database. To correct this,
verify that the database is running and that you can connect to it. After you
have done this and the database is accessible, the Scheduler should be able to
connect.
Symptom:
The autosyslog -e command displays messages indicating that the

Scheduler log file does not exist, or that no entries were made when the
Scheduler service was started.
The Scheduler service does not remain running or never starts.
Solution:
Check for a file named event_demon.$AUTOSERV in the enterprise-wide
logging directory (by default, this directory is $AUTOUSER/out).
If the file exists, enter the following command at a command prompt to view
it:
type $AUTOUSER/out/event_demon.$AUTOSERV | more
Correct the problems identified at the end of this file, and restart the
Scheduler.
Note: The Scheduler appends this file each time it starts.
312 User Guide
Symptom:
The Scheduler does not remain running and does not write log output to the
$AUTOUSER/out/event_demon.$AUTOSERV file.
Solution:
This symptom could have various causes and the resolution depends on which
of the following messages occurs.
The log file $AUTOUSER/out/event_demon.$AUTOSERV is missing!
The Scheduler must have been started on the computer at least once or
this message appears. If the Scheduler has been started, make sure that
permissions are set on the log file that enables a system program to read
and write to it.
The $AUTOSYS environment variable is not available to the Scheduler.
Make sure Unicenter AutoSys JM source file has been sourced in your
session.
The Unicenter AutoSys JM environment has not been installed
correctly.
The Scheduler runs the chk_auto_up command upon initialization and it
has reported that the setup is incorrect. Make sure Unicenter AutoSys JM
source file has been sourced in your session.
A Scheduler is already running. We will not start another one.
When the Scheduler was started, it detected another Scheduler running
with the same instance ID. Only one Scheduler can run in an instance.
Either stop the other Scheduler, or do not attempt to start this Scheduler.
Scheduler cannot open its log file event_demon.$AUTOSERV. Some
directory in the path is not accessible to the SYSTEM.
The Scheduler could not create the normal log file named in the message.
Make sure that the log file has permissions that enable a system program
to read and write to it. Also verify that the disk drive has not run out of
space.
Could not rename the LARGE Scheduler file: event_demon.$AUTOSERV
to backup archive file: event_demon.$AUTOSERV.date. Fix file and
directory permissions so accessible by SYSTEM, or remove the files.
When the Scheduler starts it checks the size of the
event_demon.$AUTOSERV log file. If this file is larger than 256 KB, the
Scheduler tries to rename it to event_demon.$AUTOSERV.date and create
a new event_demon.$AUTOSERV log file. If the Scheduler cannot to do
this, verify that event_demon.$AUTOSERV has permissions that enable a
system program to read and write it. Also, verify that the disk drive has
not run out of space.
Troubleshooting 313
Agent Troubleshooting
If you suspect there are problems with the Agent, you can use the autoping
command to verify them.
The autoping command tests the connections between the Scheduler and
Agent, and between the Application Server and the Agent. If you issue the
following command and it does not return an error, the Agent should start
properly:
autoping -m machine
machine
Defines the name of the client computer to verify.
This computer must be a real machine that is accessible through
TCP/IP on the computer from which you issue the command.
This computer must be a real machine that is listed in the /etc/hosts
file on the computer from which you issue the command.
If you enter ALL instead of a machine name for the -m parameter, the
autoping command verifies the Application Server database connection for
all computers.
The Application Server writes RUNNING and completion statuses to the Event
Server when the Agent confirms these statuses to the Application Server.
You can use the autoping command to verify the Application Server database
connection on request of the Agent. To determine the database connections on
a computer, enter the following command:
autoping -m machine -D
The autoping command captures the output from the attempted database
connection and displays it.
If you use the -A parameter with the autoping command, it generates an
alarm containing the output from the attempted database connection, if
problems occur.
314 User Guide
Example: Verify a Database Connection

This example uses the autoping command to verify a database connection with
the machine venice, and displays the output from the command:
autoping -m venice -D
AutoPinging Machine [venice] AND checking the
Agent's DB Access.
AutoPing WAS SUCCESSFUL!
Agent Not Responding

Valid on Windows
Symptom:
The autosyslog -e command displays a message that resembles the following:
Read stream socket failed
CAUAJM_E_40157 System Restart Job (Jobxxx) was unable to start
CAUAJM_I_40253 Machine is not responding. Taking Offline.
Solution:
To verify that the Agent service is started
1.
2.
(Optional) Enter the name of the computer on which the Agent is installed
in the Computer field, and click Connect.
computer name.
3.
Select the instance with which the Agent is associated from the AutoSys
Instance list, and click OK.
4.
5.
Select the CA Unicenter AutoSys JM Agent service from the Service list.
The Unicenter AutoSys Services screen refreshes to indicate the status of
the Agent. If the Agent is not running, Start Service is enabled. If the
Agent is running, Stop Service is enabled and Start Service is disabled.
6.
Click Start Service.

The Agent service starts.
Troubleshooting 315
Agent Not Responding

Valid on UNIX
Symptom:
The autosyslog -e command displays a message that resembles the following:
Read stream socket failed
CAUAJM_E_40157 System Restart Job (Jobxxx) was unable to start
CAUAJM_I_40253 Machine is not responding. Taking Offline.
Solution:
To verify that the Agent service is started
1.
Run the following command to check the status of the Agent:

unisrvcntr status uajm_agent
The Agent's current status is displayed.

2.
If the Agent is not running, run the following command to start it:
The Agent starts.

Note: For more information, see the UNIX Windows or UNIX Implementation
Guide.
316 User Guide
Agent Temporary Files

Valid on UNIX
Symptom:
When the agent started, the auto_remote memory increased significantly, and
the following messages were displayed:
In univagent.out: "sar: fork failed! Not enough space."
Outputs of prstat command show that auto_remote process takes more than 1 GB of
memory.
Solution:
The problem was resolved by removing all files under the
AutoSys_Install_Directory/agent/tx/* directories. We recommend that you do
the following:
When possible, let the job agents processes complete before recycling the
autosys or agent service.
If the files under agent/tx/jobst, agent/tx/request, and agent/tx/response

are invalid or out-of-date (for example, multiple days ago), remove them.
If there is no job agent process running, remove all files under

agent/tx/request.
If a clean startup is needed, remove all files under tx/*/.
Troubleshooting 317
Agent Starts, Command Runs: No RUNNING Event Is Sent

Symptom:
Job does not advance from STARTING state.
The Scheduler window (or log) or the results of running the autorep
command on the job contain the following event with nothing after it, but
the job runs to completion on the client computer:
CHANGE_STATUS Status: STARTING Job: test_install
Solution:
This is a common problem and is nearly always the result of the Agent being
unable to contact the Application Server.
First, make sure network problems are not preventing communication between
the Agent and the Application Server computers. If this is not the problem, use
the following database-specific solutions to confirm whether the Application
Server can contact the Event Server:
For Microsoft SQL Server and Sybase databases, the usual cause of this
connection problem is that the database settings on the Application Server
are different from those used by the Unicenter AutoSys JM Scheduler.
For Oracle databases, this problem usually occurs because the SQL*Net V2
connections are not set up properly.
For Sybase databases, this problem usually occurs because the interfaces
file is not set up properly on the computer running the Agent.
The Agent must be able to contact the Application Server, and the Application
Server must be able to connect to the database to send the RUNNING,
SUCCESS, FAILURE, or TERMINATED status events.
To verify the problem, issue the following command at an instance command
prompt on the machine where the job should have run to view the job log:
autosyslog -J job_name
job_name
Defines the name of the job.
In the log, check the AutoRemoteDir\auto_rem* file value for the job.
The AutoRemoteDir value is the Local Agent Logging Directory value, specified
in the Unicenter AutoSys Agent screen in the Administrator.
If the Agent cannot send the event back to the Application Server, it writes a
message to that effect, and runs some diagnostics. The output from the
autosyslog command could provide a helpful DBMS error number from the
connect attempt.
318 User Guide
To verify that all the database settings are correct, check the settings on
the Event Server screen of the Unicenter AutoSys Administrator for both the
Application Server and the Scheduler computers. Verify that the Application
Server's Event Server name, database, and port number settings are the same
as the settings on the Scheduler computer.
To verify that all the database settings are correct, check the settings in
the $AUTOUSER/config.$AUTOSERV configuration file for both the Application
Server and the Scheduler computers. Verify that the Application Server's
Event Server name, database, and port number settings are the same as the
settings on the Scheduler computer.
You should also make sure that the database settings (as verified by
Microsoft SQL Server, Oracle, or Sybase) are the same as the settings on the
Event Server screen of the Unicenter AutoSys Administrator.
For Microsoft SQL Server databases, use the SQL Enterprise Manager to
check the Microsoft SQL Server database settings. Also make sure that
one of the following is true:
Unicenter AutoSys JM Application Server computers are on the same

Windows domain.
User accounts have been added on the database computers for all
users.
If you do not configure your Microsoft SQL Servers in one of these ways,
your jobs go into STARTING state and seem to remain in this condition.
This behavior results from the fact that the Agent cannot write the status
back to the Microsoft SQL Server databases because the job owner does
not have proper permissions on that database server.
For Oracle databases, check for the following:
Confirm 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
Confirm that the Oracle TNS names file has an SQL*Net V2-formatted
entry for the Event Server.
For Sybase databases, make sure that the Sybase SQL.INI file exists, then
make sure that the settings are the same as the settings Unicenter
AutoSys JM is using. This file is located in the %SYBASE%\INI directory.
Troubleshooting 319
Check the database settings against the settings in the

For Oracle databases, check the following:

Confirm 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
Confirm that the Oracle TNS names file has an SQL*Net V2 formatted
entry for the Event Server.
For Sybase databases, first make sure that the Sybase interfaces file
exists, then make sure that the settings are the same as the settings
Unicenter AutoSys JM is using. This file is located in the $SYBASE
directory.
To test that communication from the Application Server to the Event Server is
set up properly, try to log on to the Event Server from the Application Server
computer, using database-specific utilities like ISQL/w (for Microsoft SQL
Server), SQLPLUS (for Oracle), or ISQL (for Sybase). When you log on to the
Event Server, use the autosys user name and password.
When testing Oracle using SQLPLUS, be sure that your user

environment is accessing the same tnsnames.ora file as the auto_remote
(Agent). Set TNS_ADMIN to the same value that is in /etc/auto.profile.
Note: auto_remote only attempts to read the tnsnames.ora file once. After a
bad tnsnames.ora file is read, correcting it does not automatically cause a
running auto_remote to connect. After you correct the tnsnames.ora file, you
must terminate auto_remote and restart the job.
For Oracle, try to log onto the Event Server from the remote computer using
SQLPLUS with a V2 connect descriptor similar to the following:
sqlplus autosys/autosys@AUTOSYSDB
Note: For more information about testing the database setup, contact your
database administrator or see the database documentation.
320 User Guide
Job Failure Troubleshooting

This section describes job failure troubleshooting.
Agent Will Start: Command Will Not Run

The Agent creates the following log file each time it starts on a computer:
AutoRemoteDir\auto_rem.pid
AutoRemoteDir
Defines the Local Agent logging directory specified during
installation or in the Agent screen of the Unicenter AutoSys Administrator.
By default, this directory is C:\%AUTOROOT%\agent\out.
Defines the local Agent logging directory specified during
installation. By default, this directory is
/opt/CA/UnicenterAutoSysJM/agent/out.
auto_rem.pid
Defines the process ID of the Agent. After the Agent receives its
instructions from the Scheduler, it renames this file as follows to give it a
unique name:
AutoRemoteDir\auto_rem.joid.run_num.ntry
joid
run_num
Defines the job's run number.
ntry
This file contains all the instructions passed to the Agent by the Scheduler, the
results of any resource checks, and a record of all actions taken. Any problems
experienced by the Agent are reported here, including the inability to send
events to the databases, which is the most common problem.
Troubleshooting 321
To find the most recent instance of the Agent Log for a given job, issue the
following command on the computer where the job last ran:
autosyslog -J job_name
job_name
Note: The Clean Temporary Files check box on the Scheduler screen of
the Unicenter AutoSys Administrator specifies whether Agent log files should
be cleaned up at the completion of a job. If this setting is selected (the
default), the file is removed when a job completes normally. If the job fails,
the log file is not deleted regardless of the setting. To turn off automatic
deletion of the Agent log files, clear the Clean Temporary Files check box on
the Unicenter AutoSys Scheduler screen.
Note: The CleanTmpFiles parameter in the

$AUTOUSER/config.$AUTOSERV configuration file specifies whether the Agent
log files are to be cleaned up at the completion of a job. If this parameter is
set to 1 (on, which is the default setting), the file is removed when a job
completes normally. If the job fails the log file is not deleted, regardless of the
setting. To turn off automatic deletion of the Agent log files, set the parameter
CleanTmpFiles=0.
322 User Guide
Symptom:
The Scheduler log as viewed with the autosyslog -e command displays a
message resembling the following:
Agent remote authentication!
Error:<Remote Authentication has FAILED for
User: USER@HOST on machine:RAHOST.>
The Agent log as viewed with the autorep -J job_name command might also
display a message resembling the following:
Remote Authentication has FAILED for User:USER@HOST on machine:RAHOST.
Message: Couldn't find valid entry in security key.
Solution:
The job is trying to run on a host that is different from the host or domain on
which it was defined, and security (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:
Log on to the RAHOST machine as the EDIT Superuser and add a Trusted
Host entry for HOST to the Trusted Hosts list.
Log on to the RAHOST machine as USER and add a Trusted User entry for
the USER@HOST user to the Trusted Users list.
Note: On Windows, you can add a trusted host and a trusted user in the
Security screen of the Unicenter AutoSys Administrator.
Troubleshooting 323
Symptom:
The Scheduler log as viewed with the autosyslog -e command displays a
message that resembles one of the following:
Owner UserId/Password error! ERROR: The password specified for
USER@HOSR_OR_DOMAIN is invalid! Run "autosys_secure" to enter the correct
password.
or
Owner UserId/Password error! ERROR: No valid password was found for USER@HOST or
USER@DOMAIN. Cannot run job for user USER! Run "autosys_secure" to enter the user
password.
The Agent log as viewed with the autorep -J job_name command might also
display a message that resembles one of the following:
The password specified for USER@DOMAIN is invalid! Run "autosys_secure" to enter
the correct password.
or
No valid password was found for USER@HOST or USER@DOMAIN. Cannot run job for user
USER! Run "autosys_secure" to enter the user password.
Solution:
The password for user@host_or_domain does not exist or is invalid. To fix this
problem, run the autosys_secure command to enter or change the user ID and
password.
324 User Guide
Symptom:
The Scheduler log as viewed with the autosyslog -e command indicates that
the job immediately returned a FAILURE status.
Solution:
To verify what is wrong, run the autosyslog -e command on the Scheduler
machine and the autorep -J job_name command on the machine where the
job should have run, and review the resultant error messages.
For example, if the job's standard output file was read-only, a message
indicating this would appear in the Scheduler log.
You should also verify the following items:
Make sure the default profile or the job's specified user-defined profile
defines the appropriate job environment. In particular, make sure that the
path variable, if defined in a job profile, is correct. You should always
include the following in any job profile that defines a path variable to help
ensure that all system path directories are accessible:
%PATH%
$PATH
Make sure the file system where the job command resides is accessible
from the machine where the job should have run.
Make sure the system permissions are correct for the job command to run.
Make sure the permissions are correct on any standard input and output
files specified for redirection.
Note: A valuable debugging technique is to specify a file to use for standard

output and standard error for a job that is having run problems. If there are
any command problems, most error messages are in that file.
Troubleshooting 325
Symptom:
When a job starts, the Scheduler log as viewed with the autosyslog -e
command displays a message that resembles the following:
Read Stream Socket Failed
Solution:
This error has the following possible causes:
An invalid path statement
Performance problems with the network or machine
Network problems
Usually, an invalid path statement for the directory causes a read-stream

socket failure. From the System dialog in the Windows Control Panel, select
the Environment tab and verify that all the directories in the System Variables
list for the path are valid on the hard drive.
Also, check for invalid characters and syntax in the path statement. A
semicolon (;), which separates individual directories, is often entered
incorrectly. Check for two semicolons in a row or for a trailing semicolon at the
end of the path. A network drive before the directory is also considered an
invalid character in the path. The directory must precede any network drives.
Correct any path problems and restart the computer. You must restart the
computer after making changes to the path.
Occasionally, performance problems on the network or computer might cause
the read-stream socket failure. The network might be down or slow due to
high traffic volume. The computer might be underpowered, or you are trying
to do too much on it at one time.
326 User Guide
Agent Not Found

Valid on UNIX
Symptom:
When trying to start a job or trying to start the Scheduler with a Shadow
Scheduler, the following message appears in the Scheduler log when viewed
with the autosyslog -e command:
Unknown Host Machine
Solution:
This message might occur in the following situations:
1.
There is a network problem and the Scheduler cannot connect to the Agent
computer.
2.
The Agent computer is not in /etc/hosts or DNS.
3.
The Unicenter AutoSys JM configuration file lists the computer; however,

there is a space after the computer name. Check /etc/hosts or DNS for the
computer name, and correct it if necessary.
Check the configuration file, $AUTOUSER/config.$AUTOSERV ($AUTOSERV is

the name of the Unicenter AutoSys JM instance). A space after the computer
name is hard to see. Use an editor, such as vi (with the :set list option), to
edit the configuration file and remove anything after the name of the computer
and before the $ that marks the end of the line.
Troubleshooting 327
Jobs Run Only From the Command Line

Valid on UNIX
Symptom:
Jobs run from the command line, but they fail when run.
Solution:
This problem is nearly always in the shell environment where the job runs. The
following are the possible reasons for the problem:
The profile in the job definition is not a Bourne shell (sh) type profile. If
this is the case, the profile fails.
The default profile does not produce the proper environment for the job to
run. The default profile for all jobs is /etc/auto.profile, not the job owner's
logon profile $HOME/.profile. If the job owner's profile is not specified in
the job definition, it is never sourced.
To verify the difference between the job definition and the user
environment
1.
Write the current owner's environment to a file. To do so, log in as the

owner of the job on the computer where the job runs and enter the
following command:
env >user.env
2.
Write the Agent environment to a file by entering the following jil

command:
insert_job: auto_env
machine: client_hostname
owner: owner
command: env
std_out_file: /tmp/auto.env
std_err_file: /tmp/auto.err
client_hostname
Defines the host name of the computer where the problem job runs.
owner
Defines the owner of the job that will not run.
328 User Guide
3.
Enter the following command to run the troubleshooting job:

sendevent -E STARTJOB -J auto_env
4.
Enter the following command to check the two files for differences:
diff /tmp/auto.env user.env
The diff command shows you where the environment and the user
environment files differ. Make the necessary changes in the job definition
and the user profile.
It is also useful to define the std_err_file for the job that fails, because you
can check the errors from the shell for a clue about what is missing.
Note: No spaces are allowed between the >> characters and the full path or
file name in the std_out_file or std_err_file fields in a job definition.
Troubleshooting 329
Jobs Run Twice

Valid on UNIX
Symptom:
Failed to connect to socket errors occur during a job run and the job runs
more than once.
Solution:
The scenario has the following sequence of events:
1.
The server opens a connection to the Client to run the job.
2.
The Agent on the Client starts the job, and then tries to respond to the
server.
3.
The server issues a failed to connect to socket error because the Agent
took longer than 30 seconds (the time-out value) to start the job and
respond.
4.
The server checks whether the job can be restarted, and (if possible)
restarts the job. Meanwhile, the job is running and perhaps completed on
the Client.
5.
The server opens another connection to the Client to run the job a second
time.
6.
The Agent starts the job and responds to the server in time.
7.
The job runs again.
The main reason for this scenario occurring is severe performance problems on
the Client. For example, the following might affect performance:
330 User Guide
Running a full system backup on the Client at the same time as jobs are
starting might slow the system down and cause the timeout because it
cannot respond to the server.
Network problems. If a job's home directory is on an NFS drive and there

are bandwidth problems, the job might take so long to start that the
socket times out.
Application Server Troubleshooting
Because socket time-out is not a customizable parameter, there is little you

can do to avoid this situation from a Unicenter AutoSys JM perspective.
However, you can analyze the performance of the Client by asking these
questions:
Are there too many processes running on the Client when you run jobs?
Are you having network problems?
Are you using NFS-mounted directories?
Do you need more memory or processors on the Client?

This topic describes Application Server troubleshooting.
Output from the Application Server is re-directed to the following log file:
%AUTOUSER%\out\as_server.%AUTOSERV%
$AUTOUSER/out/as_server.$AUTOSERV
At the instance command prompt enter the autosyslog -s command.

The Application Server log file appears. This file displays error messages
as they occur.
Press Ctrl+C.
Terminates error reporting.
You can view the details related to error messages in the Application Server
log records.
You can enable run-time traces to view incoming Client requests in the order
they were received by the Application Server and use them for troubleshooting
communications with the Unicenter AutoSys JM Client or an application using
the SDK.
Troubleshooting 331
Application Server Is Down

Symptom:
Unicenter AutoSys JM Client utilities on the local machine time out.

the following:
CAUAJM_E_50033 Error initializing tx subsystem:
CAUAJM_E_10527 Timed out
waiting for response from the Unicenter AutoSys JM Application Server.

CAUAJM_E_10062 Failed to get initial configuration Unicenter AutoSys JM
Application Server: [<application server machine>:9,000]
Application Server log has registered an error message since it was

started.
Solution:
Do one of the following to confirm that the Application Server is down:
Run the autosyslog -s command to view the Application Server log, and
check for date and time stamps of the last run as well as any other error
messages.
To test that communication from the Application Server to the Event

Server is set up properly, log on to the Event Server from the computer
where Application Server is available, by using the following:
For Microsoft SQL Server, use the ISQL/w graphical query interface.
For Oracle, use the SQL*Plus command language interface.
For Sybase, use the isql utility.
Use the Unicenter AutoSys JM user name and password to log on to the
Event Server.
You can also check the status of the Application Server in the Windows
Service Control Manager.
To check the status of the Application Server, use the Services screen of the
Unicenter AutoSys JM Administrator. Select the Application Server from the
Service list. Use the Status icon to check the status of the Application Server.
332 User Guide
If the Application Server is down, use the Services screen of the Unicenter
AutoSys Administrator to restart it. Select the Application Server from the
Service list, and click Start Service. The Status field changes to running, and
the Application Server icon turns Green.
Note: For information about the Unicenter AutoSys JM Administrator, see the
Online Help.
Symptom:
Unicenter AutoSys JM Client utilities on the local machine time out.

the following:
CAUAJM_E_50033 Error initializing tx subsystem: CAUAJM_E_10527 Timed out
waiting for response from the Unicenter AutoSys JM Application Server.
The Application Server log has registered an error message since it was
started.
Solution:
Do one of the following to confirm that the Application Server is down:
Run the following command:

unisrvcntr status uajm_server.$AUTOSERV
Run the autosyslog -s command to view the Application Server log, and
check for date and time stamps of the last run as well as any other error
messages.
To test that communication from the Application Server to the Event

Server is set up properly, log on to the Event Server from the computer
where Application Server is available, by using the following:
Use the Unicenter AutoSys JM user name and password to log on to the
Event Server.
Check for running as_server processes for the given $AUTOSERV using the
ps command.
Troubleshooting 333
If the Application Server is down, run the following command to start it:
unisrvcntr start uajm_server.$AUTOSERV
Note: For more information, see UNIX Windows or UNIX Implementation

Guide.
Application Server Will Not Start

Symptom:
The autosyslog -s command displays messages indicating that it cannot
Solution:
To confirm that the Application Server is down, log on to the Event Server
computer and run the chk_auto_up utility. If the database is running, there is
a possibility that Unicenter AutoSys JM is configured to the wrong Application
Server or communication between Unicenter AutoSys JM and the Application
Server is failing.
To test that communication from the Application Server to the Event Server is
set up properly, try to log on to the Event Server from the Application Server
computer, by using the following:
For Microsoft SQL Server, use the ISQL/w graphical query interface.
Use the Unicenter AutoSys JM user name and password to log on to the Event
Server.
334 User Guide
Symptom:
The Application Server does not remain running and does not write log output
to the %AUTOUSER%\out\as_server.%AUTOSERV% file.
Solution:
Check the Windows event log message viewer, located in the Administrative
Tools program group, to verify the cause of the problem. Take the appropriate
solution based on the problem in the event log.
Incorrect options have been set to Application Server. It must not

have been set properly.
This occurs if you have modified the Windows Registry so that the -A
option is not used when starting the Application Server service. To fix this
problem with the Windows Registry settings, uninstall and reinstall
Unicenter AutoSys JM.

The %AUTOSYS% system environment variable is not available to the
Application Server. In the Windows Control Panel, click the System icon
and set the %AUTOSYS% environment variable in the System
Environment Variables region. You can also check the setting of this
variable on the System screen of the Unicenter AutoSys Administrator.

The %AUTOSYS% environment variable value is set to a path that is more
than 80 characters in length. Uninstall and reinstall Unicenter AutoSys JM
to a directory path that has fewer than 80 characters.
Application Server cannot open its log file

as_server.%AUTOSERV%. Some directory in the path is not
accessible to the SYSTEM.
The Application Server was unable to create the normal log file named in
the message. Make sure that the log file has permissions that enable a
system program to read and write to the file. Also verify that the disk drive
has not run out of space.
Troubleshooting 335
Symptom:
The autosyslog -s command displays messages indicating that it cannot
Solution:
The database server is down or there are problems with the database
installation. To test that communication from the Application Server to the
Event Server is set up properly, log on to the Event Server from the
Application Server computer, by using the following:
Use the Unicenter AutoSys JM user name and password to log on to the Event
Server.
Symptom:
The Application Server is not running and does not write log output to the
$AUTOUSER/out/as_server.$AUTOSERV file.
Solution:
This symptom could be attributed to a number of causes.

The $AUTOSYS environment variable is not available to the Application
Server. Make sure the AutoSys source file has been sourced in your
session.

The $AUTOSYS environment variable value is set to a path that is more
than 80 characters in length. Uninstall and reinstall Unicenter AutoSys JM
to a directory path that has fewer than 80 characters.
Application Server cannot open its log file as_server.$AUTOSERV.

Some directory in the path is not accessible to the SYSTEM.
The Application Server was unable to create the normal log file named in
the message. Make sure that the log file has permissions that enable a
system program to read and write to the file. Also verify that the disk drive
has not run out of space.
336 User Guide
Application Server Starts, Clients on Remote Machine Times out

Symptom:
When you run the chk_auto_up command from a remote machine, it returns a
CAUAJM_E_50033 Error initializing tx subsystem: CAUAJM_E_10527 Timed out waiting
for response from the Unicenter AutoSys JM Application Server.
Solution:
Check to make sure that network problems are not preventing communication
between the Client and the Application Server computers through the
Operating System ping command.
Use the following steps to confirm whether the Client computers can contact
the Application Server:
1.
On the Client computer, open a command prompt to the bin folder of the
location specified by the %CSAM_SOCKADAPTER% environment variable,
and run the following command:
csamconfigedit Port=nnnn display
nnnn
Defines the port number to display.
Default: 9000
2.
On the Application Server computer, open a command prompt to the bin

folder of the location specified by the %CSAM_SOCKADAPTER%
environment variable, and run the following command:
nnnn
Default: 9000
Troubleshooting 337
3.
Compare the two previous outputs and make sure that both the
EnablePmux and EnableSSL settings are identical.
4.
Run the following command on both computers and compare settings:

csamconfigedit PortRange=49152-50176 display
If the settings do not match, change the settings of either or both

computers to match and stop/start the services.
If the settings match, verify that physical port 7163 is not being blocked
by firewall software on either computer.
Symptom:
When you run the chk_auto_up command from a remote machine, it returns a
CAUAJM_E_50033 Error initializing tx subsystem: CAUAJM_E_10527 Timed out waiting
for response from the Unicenter AutoSys JM Application Server.
Solution:
Make sure network problems are not preventing communication between the
Client and the Application Server computers through the Operating System
ping command.
Use the following steps to confirm whether the Client computers can contact
the Application Server:
1.
On the Client computer, open a command prompt to the bin folder of the
location specified by the $CSAM_SOCKADAPTER environment variable, and
run the following command:
nnnn
Default: 9000
2.
On the Application Server computer , open a command prompt to the bin

folder of the location specified by the $CSAM_SOCKADAPTER environment
variable, and run the following command:
nnnn
Default: 9000
338 User Guide
3.
Compare the two previous outputs and make sure that both the
EnablePmux and EnableSSL settings are identical.
4.
Run the following command on both computers and compare settings:

csamconfigedit PortRange=49152-50176 display
If the settings do not match, change the settings of either or both

computers to match and stop/start the services.
If the settings match, verify that physical port 7163 is not being blocked
by a firewall software on either computer.
More Information:
General Debugging (see page 385)
How to Configure Unicenter AutoSys JM to Run with SSL (see page 392)
Troubleshooting 339
Chapter 16: Unicenter Integration

Integrating Event Management (see page 341)
Integrating Unicenter Notification Services (see page 346)
Integrating Unicenter Service Desk (see page 352)
Integrating Event Management

The Event Management system collects events from almost every running
program or script that generates them, and provides a complete view of the
ongoing processing in your enterprise. Event Management checks which
messages are important, and responds to them based on user-defined policies.
It can automate many manual problem resolution tasks, filter and consolidate
multiple events, and significantly reduce the need for human intervention.
Event Management can correlate various messages, monitor for unusual
conditions, and take proper corrective action.
With Event Management, you can do the following:
Identify events that are important to your organization and define

message record and action profiles that specify the special processing that
Unicenter NSM performs when the events occur.
Define calendars that establish dates and times for processing events.
Monitor event activity through the console log and immediately respond to
events as they occur.
Define console log views that restrict message access to authorized users
and user groups.
Note: The examples in this section focus on the Unicenter WCC GUI. You can
also perform most of the actions with Unicenter Management Portal.
Unicenter Integration 341
How Event Management Processes Events

In the context of Event Management, an event is a message that an operating
system or other application issues to alert the user or other software
components of an important occurrence. Information such as date, time, node
of origin, and user are typically associated with the event.
A typical event goes through the following stages:
342 User Guide
1.
A situation or event occurs that causes creation of a message. The

message can be informational, such as announcing that a job is
completed. It can also announce a more serious event, such as a server
about to go down.
2.
The event is sent directly to Event Management or collected by various

components and sent to Event Management for processing.
3.
The event is added to the console log, if a message policy does not
prevent it.
4.
The event is matched against Event Management message policies and

Advanced Event Correlation (AEC) policies. If the event matches a policy,
various actions are executed automatically. Depending on the policy, the
event can also go to the Held Messages area of the console log or to Alert
Management System (AMS) for further tracking and processing.
5.
When human intervention is required, a technician is notified by

Notification Services and then starts to resolve the situation. If it was a
held message, the technician also acknowledges the message or sends a
reply.
6.
The situation that caused the message is resolved, and another event can
be created to announce the resolution.
Installation Considerations
To integrate Unicenter AutoSys JM with Event Management, you must have an
Event Agent installed on the Unicenter AutoSys JM server. The Event Agent
can be installed from the CA Common Components DVD (shipped with
Unicenter AutoSys JM) or Unicenter NSM.
Note: You can skip this section if you already have an Event Agent installed on
the Unicenter AutoSys JM server.
If you do not already have an Event Agent installed on the Unicenter AutoSys
JM server, select Event Agent from CA common components when installing
Unicenter AutoSys JM. Selection of just the Agent component implies that you
have installed a Unicenter Event Manager in your enterprise. If you want to
integrate Unicenter AutoSys JM with Event Management but do not have an
Event Manager installed, Event Manager from CA common components.
If you only selected the Event Agent component, the Unicenter AutoSys JM
installation prompts you for the machine name of the Unicenter Event Manager
node.
The installation sets the Event Manager node as an environmental

variable (CA_OPERA_NODE) in the Event Agent environment. When this
environmental variable is set, all messages that arrive on the Event Agent are
sent to that managing node. If this environmental variable is not set,
messages that arrive on the Event Agent that must be sent to another node
must have a Message Record with a FORWARD action defined in their local
message policy file.
If the Event Manager node changes after installation, you can use the
Unicenter cautenv command to modify this environmental variable. If you
modify the environmental variable, you must stop and restart the Event Agent
to implement your changes.
The installation records this machine name in the

$CAIGLBL0000/scripts/envset file under the following variables:
CAI_OPR_REMOTEDB
CAI_CAL_REMOTEDB
CA_CAL_SYSTEMID
To redefine the manager on systems running Unicenter NSM, modify the data
in these three environment variables and recycle Unicenter NSM.
For an Event Agent-only installation, this information specifies the manager
from which the Agent retrieves its policies. No messages are forwarded to the
manager or any other location unless it is specified in a policy defined for this
Agent. This policy resides on the manager as a Message Record defined for the
Event Agent node with a FORWARD action of the complete message text,
where the forwarding destination is the manager node.
After the policy is defined and reloaded on the manager and the Event Agent is
recycled to pick up the new policy, all messages that arrive on the Event Agent
are sent to that managing node.
To make sure that messages are properly forwarded from the Event Agent
residing on the Unicenter AutoSys JM server, do the following:
1.
Make sure that the Event Management environment variables,

CAI_OPR_REMOTEDB, CAI_CAL_REMOTEDB, and CA_CAL_SYSTEMID
(located in the $CAIGLBL0000/scripts/envset file) are set to the Unicenter
Event Manager node on the Event Agent computer.
2.
Define a Message Record/Action for the Event Agent node that forwards all
messages that occur on the Event Agent computer to the Event Manager
node. If the Event Manager is active, issue the opreload command to
cause a reload of all new event policies.
Recycle the Event Agent using the Unicenter commands unishutdown all and
unistart all.
Note: For more information about Event Management setup and configuration,
see the Unicenter Event Management documentation.
344 User Guide
Configure Message Forwarding

After installing and configuring the basic software, you must configure the
Unicenter AutoSys JM server to activate its message forwarding interface.
Note: Event Management is installed as a Unicenter NSM component or a CA
common component. Unicenter AutoSys JM requires at least Event
Management r11.
The Unicenter Event Agent requires a valid CAICCI connection to the Unicenter
Event Manager computer if the manager is not installed locally on the
Unicenter AutoSys JM server computer.
To configure message forwarding
1.

Superuser and issue the following command at an instance command
prompt:
The Scheduler completes any processing it is currently performing and

stops.
2.
Open the Unicenter AutoSys Administrator and select a specific

instance. Then, open the Integration screen and select the Forward all
Unicenter AutoSys JM messages check box.
3.
Set the parameter UnicenterEvents=1 in the

All Unicenter AutoSys JM messages generated to the Scheduler log are
forwarded to the Unicenter Event Management console. You can write
Event Management policies to act on any or all forwarded messages.
Note: For information about writing and implementing Event Management
policies, see the Unicenter Event Management documentation.
4.
Issue the following command at an instance command prompt:

eventor
The Scheduler starts. Any messages written to the Scheduler log should
now also appear in the Event Management console.
Integrating Unicenter Notification Services

Unicenter Notification Services lets you use various protocols and devices to
send wired and wireless messages to operators or administrators who must
resolve problems or attend to emergencies.
Note: Unicenter Notification Services is different from Wireless Messaging,
which is still available in Event Management. Wireless Messaging lets you send
email and pages.
The following protocols are available:
Email - SMTP, POP3
Simple Mail Transfer Protocol (SMTP) is used to send one-way and
two-way email messages. Post Office Protocol version 3 (POP3) is used to
receive email from a mail server.
Wireless - WCTP
Wireless Communications Transfer Protocol (WCTP) uses XML over
Hypertext Transport Protocol (HTTP) to send and receive messages and
binary data between wire-line systems and one-way or two-way wireless
devices.
Page - SNPP
Simple Network Paging Protocol (SNPP) is based on TCP/IP and offers
one-way and two-way paging.
Page - TAP
Telocator Alphanumeric Protocol (TAP) sends pages by modem, and is the
oldest one-way paging protocol.
Short Message - SMS
Short Message Service (SMS) is used to send one-way text messages to
cellular telephones using HTTP.
Instant Message - Sametime
IBM Lotus Instant Messaging and Web Conferencing (Sametime Instant
Messaging - SIM) is used on Windows to send one-way and two-way
instant messages.
346 User Guide
Voice - TAPI
Telephony Application Programming Interface (TAPI) is used on Windows
to send one-way voice messages that are synthesized from text using the
Microsoft Speech Application Programming Interface (SAPI) text-to-speech
(TTS) engine. The default speech is set in the Windows Control Panel. The
messages travel by telephone line to a human recipient using a
TAPI-compliant telephony device.
Script
Third-party or customer programs or scripts can be used to send one-way
messages. Scripts and command definitions are stored in the
UNSConnections.ini file in the install_path/config directory.
How Unicenter Notification Services Works

Unicenter Notification Services uses the following process to track all
notifications that you send. This is especially important for two-way
notifications that must be matched with responses.
1.
2.
You use one of the following features to create a notification message:
User interface
Command line or script
Event Console (by right-clicking a message)
Event Management NOTIFY action
Alert Management escalation
Application using the Notification Services Client SDK
Based on the recipient, provider, or protocol information in the request,

the Notification Services daemon (unotifyd) selects a protocol-specific
driver to send the notification.
Note: The daemon runs as a service on Windows and as a background
process on UNIX and Linux.
3.
The daemon assigns a tracking ID, which it returns to the command or

program that sent the notification.
Note: If the daemon stops and restarts, it also restarts the outstanding
notifications stored on disk.
348 User Guide
4.
The daemon checks periodically for a response from the service provider, if
one was requested.
5.
The daemon stores information about the notification on disk, and updates
that information throughout the life cycle of the notification. This is called
checkpointing. Updates occur for the following events:
The request is created.
The service provider received the notification.
The provider delivered the notification.
The recipient read the notification.
The recipient sent a reply.
Installation Considerations
To integrate Unicenter AutoSys JM with Unicenter Notification Services, you
must have a Notification Agent installed on the Unicenter AutoSys JM server.
The Notification Agent can be installed from the Unicenter NSM media.
Note: You can skip this section if, you already have a Notification Agent
installed on the Unicenter AutoSys JM server.
If you do not already have a Notification Agent installed, on the Unicenter
AutoSys JM server, you must install it from the Unicenter NSM media. The
Notification Agent installation assumes you have installed a Notification
Manager in your enterprise. If you want to integrate Unicenter AutoSys JM
with Unicenter Notification Services but do not have a Notification Manager
installed, you must install the Notification Manager from the Unicenter NSM
media.
Note: For more information about Unicenter Notification Services setup and
configuration, see the Unicenter NSM documentation.
Configure Notification
Unicenter AutoSys JM server to activate its notification interface.
Note: Unicenter Notification Services is installed as a component of Unicenter
NSM. Unicenter AutoSys JM requires at least Unicenter Notification r11.
To send a notification request to Unicenter Notification Services, Unicenter
AutoSys JM requires the node name of the Unicenter Notification Manager.
If the manager is not installed locally on the Unicenter AutoSys JM server, the
Notification Agent requires a valid CAICCI connection to the Notification
Manager computer.
To configure notification
1.

prompt:

stops.
2.
Open the Integration screen of the Unicenter AutoSys Administrator,

enter the Unicenter Notification Services server name in the Server Node
field and click OK.
Modify the Client API Timeout parameter to set the wait time the Client
uses when requiring an acknowledgement from the Unicenter Notification
Services server. The default value (30 seconds) is sufficient for the server
to respond to a Client request.
Set the NotifyServerNode parameter in the
$AUTOUSER/config.$AUTOSERV configuration file to the node name of the
Unicenter Notification Services server.
3.
(Optional) Modify the NotifyAckTimeout parameter in the

$AUTOUSER/config.$AUTOSERV configuration file to set the wait time the
Client uses when requiring an acknowledgement from the Unicenter
Notification Services server. The default value (30 seconds) is sufficient for
the server to respond to a Client request.
4.

eventor
The Scheduler starts and the notification interface is activated.
350 User Guide
Send Notifications with Unicenter AutoSys JM

The integration of Unicenter Notification Services with Unicenter AutoSys JM
lets you send wired and wireless messages based on the completion of a job.
The Unicenter AutoSys JM Scheduler sends a notification during terminal
status processing based on the jobs send_notification attribute. If the
send_notification attribute is set, the Scheduler prepares and sends the
notification request using the jobs notification_id and notification_msg
attributes. Messages are written to the Scheduler log indicating whether the
notification request was sent and processed successfully. You can also use the
optional notification job attributes (notification_pri, notification_imp, and
notification_sev) to classify the notification based on priority, importance, and
severity.
Example: Send a Notification Request when a Job Completes
This example shows the JIL statements used in a job definition to send a
notification request to a recipient named administrator when job
notify_on_completion completes:
insert_job: notify_on_completion
machine: localhost
command: sleep 1
owner: user@localhost
send_notification: y
notification_id: administrator
notification_msg: notify_on_completion has completed.
Example: Send a Notification Request when a Job Fails

This example shows the JIL statements used in a job definition to send a
notification request to a recipient named operator when job notify_on_failure
fails:
insert_job: notify_on_failure
machine: localhost
command: false
owner: notify@localhost
send_notification: f
notification_id: operator
notification_msg: notify_on_failure has failed.
Note: For more information about the notification attributes of jobs, see the
Reference Guide.
Integrating Unicenter Service Desk

Unicenter Service Desk is an enterprise-level service desk solution that lets
you automate IT processes and provide audit trails for regulatory compliance.
Unicenter Service Desk enables you to improve efficiency, while fostering
customer satisfaction and improved productivity. It is easily configured to
support the ITIL model, leverage CA's collection of years of service, support
best practices, or implement your own processes. Unicenter Service Desk
provides a self-service interface that helps your customers resolve their own
issues. From this web interface, they can submit tickets, checks status and
browse the knowledge base.
Configure Unicenter AutoSys JM to Activate Its Unicenter Service Desk Interface

When Unicenter AutoSys JM is integrated with Unicenter Service Desk, the
default data files that are added to the Unicenter Service Desk database
during configuration are used to create requests through the web services. In
addition to the data files, Unicenter Service Desk also provides the default
templates and contacts for Unicenter AutoSys JM, that is, the default users
and templates use the names of the product for which they are applicable.
Note: Only the Unicenter Service Desk Administrator is authorized to modify
the default templates that are provided during the configuration process.
From a Unicenter Service Desk perspective, do the following:
1.
Open the Unicenter Service Desk application and verify that it operates
properly.
2.
Use a Windows command prompt to access the following location:

C:\Program Files\CA\Service Desk\data\integrations.
3.
Run either of the following commands to complete the installation:

pdm_load f itil_integAutoSys.dat
Specifies an ITIL configured Unicenter Service Desk installation.

pdm_load f integAutoSys.dat
Specifies a default or non-ITIL configured Unicenter Service Desk

installation.
Unicenter AutoSys JM server to activate its Unicenter Service Desk interface.
Note: Unicenter Service Desk is installed as a standalone product. Unicenter
AutoSys JM requires at least Unicenter Service Desk r11. Contact your
Unicenter Service Desk administrator if you need assistance with setting the
parameters in this section.
352 User Guide
To initiate a service desk ticket to Unicenter Service Desk, Unicenter AutoSys

JM requires the Web Service Desk URL, login identifier, and password. The
Web Service Desk Customer can be substituted for the Web Service Desk login
identifier and password.
To configure Unicenter AutoSys JM to activate its Unicenter Service
Desk interface
1.

prompt:
The Scheduler completes any processing it is currently performing, then

stops.
2.
Open the Integration screen of the Unicenter AutoSys Administrator

and update the Web Service Login ID, Web Service Login Password, and
URL Location fields.
Note: If you use a Web Service Customer identifier to access Unicenter
Service Desk, update the Web Service Customer field instead of the Web
Service Login ID and Web Service Login Password fields.
Set the ServiceDeskURL parameter in the
$AUTOUSER/config.$AUTOSERV configuration file to the URL of your
Unicenter Service Desk Web server (for example,
http://localhost:8080/axis/services/USD_R11_WebService?wsdl).
Set the ServiceDeskUser parameter in the $AUTOUSER/config.$AUTOSERV
configuration file to your Unicenter Service Desk user ID and password.
Note: If you use a Service Desk Customer identifier to access Unicenter
Service Desk instead of a user ID and password, update the
ServiceDeskCust parameter instead of the ServiceDeskUser field.
3.

eventor
Initiate a Service Desk Ticket with Unicenter AutoSys JM

The integration of Unicenter Service Desk into Unicenter AutoSys JM lets you
open a service desk ticket (request or incident) when a job fails. The Unicenter
AutoSys JM Scheduler initiates opening a service desk ticket during terminal
status processing based on the jobs service_desk attribute. If set, the
Scheduler prepares and sends the service desk ticket using the jobs
svcdesk_desc, svcdesk_pri, svcdesk_imp, svcdesk_sev, and svcdesk_attr
attributes. Messages are written to the Scheduler log indicating whether the
service desk ticket was sent and processed successfully.
Only the service_desk attribute is mandatory. If the jobs svcdesk_desc,
svcdesk_pri, svcdesk_imp, svcdesk_sev, and svcdesk_attr attributes are not
set, they use the Unicenter AutoSys JM service desk template values set in
Unicenter Service Desk. This template is included in the Unicenter Service
Desk installation. Before initiating a Service Desk ticket, make sure Web
Services for Unicenter Service Desk is active.
Example: Initiate a Service Desk Incident
This example shows the JIL statements used in a job definition that initiates a
service desk incident with a priority of 1 for a job named
service_desk_on_failure:
insert_job: service_desk_on_failure_1
machine: localhost
command: false
service_desk: y
svcdesk_pri: 1
svcdesk_desc: service_desk_on_failure_1 has failed.
Example: Initiate a Service Desk Request

This example shows the JIL statements used in a job definition that initiates a
service desk request with an impact of 3 and a severity of 4 for a job named
service_desk_on_failure_2:
insert_job: service_desk_on_failure_2
machine: localhost
command: false
service_desk: y
svcdesk_imp: 3
svcdesk_sev: 4
svcdesk_desc: service_desk_on_failure_2 has failed.
Note: For more information about the service desk attributes of a job, see the
Reference Guide.
354 User Guide
Appendix A: Cross-Platform Scheduling

Considerations
Integrating Cross-Platform Scheduling (see page 356)
Definition of Terms (see page 357)
Enterprise Job Scheduling Prerequisites (see page 359)
Cross-Platform Considerations (see page 360)
Configure Enterprise Job Scheduling (see page 361)
PRIMARYCCISYSIDCross-Platform Environment Variable (see page 364)
Bi-Directional Scheduling (see page 365)
Unicenter AutoSys JM Connect Cross-Platform Dependencies (see page 366)
Running Jobs on UUJMA (see page 369)
Cross-Platform Interface Messages (see page 376)
Unsupported Attributes for Unicenter AutoSys JM Connect or UUJMA Jobs
(see page 377)
Cross-Platform Scheduling Considerations 355
Integrating Cross-Platform Scheduling
Integrating Cross-Platform Scheduling

Unicenter AutoSys JM enterprise-wide scheduling lets you integrate jobs with
Unicenter Universal Job Management Agent (UUJMA) for UNIX, Windows,
AS/400, and OpenVMS, and with various CA 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 systems.
Unicenter AutoSys JM can schedule jobs on Windows, UNIX, OS/390,

AS/400, and OpenVMS systems.
Unicenter AutoSys JM can receive work from other Unicenter workload

managers.
You can use cross-platform job dependency notation to define jobs to

conditionally start based on the status of a job running on the included set of
Unicenter Workload Agent computers. You can also create jobs that run on any
of the UUJMA computers (if the UUJMA computers are defined).
The UUJMA performs the following functions:
Receive job requests from one or more Unicenter workload managers,

such as Unicenter NSM Job Management Option (JMO), Unicenter AutoSys
JM Server, or Unicenter CA-7, and initiate the requested program, script,
JCL, or other unit of work. If scheduling to the mainframe, the command
or program to initiate is the job name of the job as defined in the
mainframe scheduling system.
Collect status information about job runs.
Send status information to the requesting workload manager.
Job scheduling to UUJMA computers is accomplished through the

Cross-Platform Interface of the Unicenter AutoSys JM Scheduler. For the
Unicenter AutoSys JM Scheduler to communicate with UUJMA computers, the
Scheduler must convert Unicenter AutoSys JM-based events such as
STARTJOB, RUNNING, SUCCESS, and FAILURE to events that UUJMA can
interpret. Similarly, the Scheduler must convert events returned from UUJMA
back to events the Unicenter AutoSys JM Scheduler can interpret.
356 User Guide
Definition of Terms
The following table lists the Unicenter AutoSys JM and UUJMA events:
Operation
Unicenter AutoSys JM
UUJMA
Starting a job
STARTJOB
SUBMITU
Job has started and is

running
RUNNING
JOBINITU
Job has terminated

successfully with
exitcode
SUCCESS or FAILURE
JOBTERMU
Job has failed to start
FAILURE
JOBFAILU
Definition of Terms
The following terms are used in this appendix.
Agent computer
Any computer that supports a Unicenter workload agent.
bi-directional job scheduling
The ability of Unicenter AutoSys JM to support both inbound and outbound job
scheduling.
CAICCI
CA International Common Communications Interface
cross-instance job dependency
A dependency between jobs running on different Unicenter AutoSys JM
instances.
cross-instance scheduling
The process of scheduling jobs or dependencies between Unicenter AutoSys JM
instances.
cross-platform scheduling
The process of scheduling jobs or dependencies between Unicenter AutoSys JM
and any Unicenter Workload Agent.
cross-platform job dependency
A dependency between Unicenter AutoSys JM and any Unicenter Workload
Agent.
Definition of Terms
inbound job scheduling

The process of scheduling Unicenter AutoSys JM-defined jobs from a remote
Unicenter workload manager.
outbound job scheduling
The process of scheduling Unicenter AutoSys JM-defined jobs from Unicenter
AutoSys JM to a Unicenter Workload Agent.
Unicenter AutoSys JM
A workload manager that runs on UNIX and Windows.
Software that lets Unicenter AutoSys JM communicate with legacy OS/390
workload manager.
Unicenter AutoSys JM Scheduler
A Unicenter AutoSys JM process that communicates with Unicenter AutoSys JM
Connect, any supported UUJMA Agent, or Unicenter workload manager.
Commonly referred to as the Scheduler.
Unicenter Workload Manager
A Unicenter job management process that communicates with a workload
Agent. Examples include Unicenter NSM JMO, Unicenter AutoSys JM, or any CA
mainframe scheduling product.
Unicenter Workload Agent
Any Agent in the set of Unicenter-based scheduling Agents residing on UNIX,
Windows, AS/400, and VMS that are supported by Unicenter AutoSys JM. This
also includes the mainframe Unicenter AutoSys JM Connect solution and any
CA mainframe scheduling product.
358 User Guide
Enterprise Job Scheduling Prerequisites
Enterprise Job Scheduling Prerequisites

Unicenter AutoSys JM lets you schedule or reroute jobs from multiple sources
throughout the enterprise.
Before you can implement enterprise job scheduling, you must install and
configure the basic software as instructed in the Windows or UNIX
Implementation Guide. You must also install and configure Unicenter AutoSys
JM Connect or a UUJMA, or both, as instructed in the documentation for those
components.
The required software and minimum versions are as follows:
Unicenter AutoSys JM r11 (including service packs) for Windows or UNIX.
CAICCI Version 40.

To check the version of CAICCI you have installed, enter the following
command at a command prompt:
rmtcntrl release
UUJMA requires TCP/IP and one or more of the following:
Unicenter AutoSys JM Connect (OS/390).
Unicenter AutoSys JM r11 (including service packs) for Windows or

UNIX.
Unicenter CA7, Unicenter CA-Scheduler, or Unicenter CA-JobTrac.
The following components must be present on the Unicenter AutoSys JM

Server computer:
Unicenter AutoSys JM Scheduler
CAICCI
Cross-Platform Considerations
Cross-Platform Considerations
Keep the following in mind when you are running jobs across platforms:
360 User Guide
If you are running Unicenter AutoSys JM in High Availability mode, job

statuses and cross-platform dependencies are not lost when the Shadow
Scheduler takes over. This assumes the PRIMARYCCISYSID environment
variable was correctly set on the Primary and Secondary Schedulers and
the UUJMA computers, and that jobs and external dependencies were sent
to Unicenter workload manager/Agent with proper release levels to
support PRIMARYCCISYSID.
When running a job from a Unicenter NSM Job Management Option (JMO)
scheduling manager, you may need to modify the default fail codes
currently set for the Unicenter JMO defined job. Exit codes 2 through 99
are defined as the default fail codes for Unicenter JMO jobs; thus an exit
code of 0 to 1 indicates success. When you run a job from Unicenter JMO
that executes a job in Unicenter AutoSys JM and the job fails with an exit
code 1, (for example, bad command), from Unicenter AutoSys JM job the
Unicenter AutoSys JM job ends with a status of FAILURE, but the Unicenter
JMO defined job ends with a status of SUCCESS or COMPLETE. You must
modify the fail codes to accommodate the differences in how success and
failure are interpreted between the two scheduling systems. That is, you
must define exit codes 1 through 99 as the fail codes for the Unicenter
JMO defined job and define only an exit code of 0 to indicate success.
If more than one instance of Unicenter AutoSys JM is running on a single

machine and you plan to activate the Cross-Platform Interface, only one
instance of Unicenter AutoSys JM can run with the Cross-Platform
Scheduling option set to a value of 2. That is, only one instance can
function as an Agent capacity (that is, only one instance can accept job
submissions from a remote Unicenter JMO, CA-7, CA-Scheduler, or
Unicenter CA-Jobtrac manager).
The chase and autoping commands return limited information about

Unicenter AutoSys JM Connect and UUJMA jobs and computers.
Remote user authentication is not supported for Unicenter AutoSys JM

Connect jobs. For UUJMA jobs, remote user authentication is performed
using the owner name associated with the job.
You cannot execute the following events on Unicenter AutoSys JM Connect

or UUJMA jobs and computers:
CHANGE_PRIORITY
SEND_SIGNAL
Configure Enterprise Job Scheduling

After installing and configuring the basic software and Unicenter AutoSys JM
Connect or a UUJMA Agent, or both, you must configure the Unicenter AutoSys
JM Server to activate its cross-platform scheduling interface.
To configure enterprise job scheduling
1.

prompt:

stops.
2.
In the Unicenter AutoSys Administrator, select a specific instance,

and select any of the following cross-platform scheduling parameters from
the Cross Platform Scheduling drop-down list on the Scheduler screen:
Select 1 Enable outbound cross-platform scheduling (manager
only)
Runs jobs directly on a Unicenter workload Agent. When you select
this option, a Unicenter AutoSys JM instance can dispatch jobs to a
UUJMA Agent.
Select 2 Enable outbound and inbound cross-platform scheduling
(manager and Agent)
Enables bi-directional scheduling support. When you select this option,
a Unicenter AutoSys JM instance can dispatch jobs to a Unicenter
Workload Agent and receive jobs from a Unicenter workload
manager.
Edit the $AUTOUSER/config.$AUTOSERV configuration file and set
the CrossPlatformscheduling parameter as appropriate:
To run jobs directly on a Unicenter Workload Agent, set

CrossPlatformScheduling=1.
When you set CrossPlatformScheduling=1, a Unicenter AutoSys JM
instance can dispatch jobs to a UUJMA Agent.
To enable bi-directional scheduling support, set

CrossPlatformScheduling=2.
When you set CrossPlatformScheduling=2, a Unicenter AutoSys JM
instance can dispatch jobs to a Unicenter workload Agent and receive
jobs from a Unicenter workload manager.
3.
Issue the insert_machine jil command as appropriate to define the remote

node.
To define a UUJMA or Unicenter CA-7 node, issue the following jil

command and attribute:
insert_machine: remote_node
type: u
To define a Unicenter AutoSys JM Connect node, issue the following jil

command and attribute:
insert_machine: remote_node
type: c
remote_node
Identifies the hostname of the computer running UUJMA, Unicenter
CA-7, or Unicenter AutoSys Connect.
4.
Issue the insert_xinst jil command as appropriate to define external

instance entries to Unicenter AutoSys JM, thereby enabling cross-platform
dependencies.
Note: All external instance entries are stored in the Unicenter AutoSys JM
Event Server. Entries are created and maintained through the JIL
application and reported on through the autorep command.
To define a UUJMA remote node that supports external dependencies

to Unicenter AutoSys JM, issue the following jil commands and
attributes:
insert_xinst: UJA
xtype: u
xmachine: remote_node
To define a Unicenter AutoSys JM Connect node that supports external

dependencies to Unicenter AutoSys JM, issue the following jil
commands and attributes:
insert_xinst: A50
xtype: c
xmachine: remote_node
362 User Guide
5.
Start the Scheduler.

Select Services from the AutoSys menu in the Unicenter AutoSys
Administrator, select the Scheduler from the Service list on the Unicenter
AutoSys JM Services screen, and click Start Service.
eventor

6.
Review the Scheduler log to verify that the cross-platform scheduling

interface is active. The interface is active if the log contains the following
messages:
CAUAJM_I_40005 Cross Platform Interface Initialization in progress
CAUAJM_I_40015 Cross Platform Interface is now active
Note: If you modify external instance entries while the Unicenter AutoSys JM
Scheduler is active, the Scheduler handles the modifications in real time. You
need not recycle the Scheduler when maintaining external instance entries.
PRIMARYCCISYSIDCross-Platform Environment Variable
PRIMARYCCISYSIDCross-Platform Environment Variable

You can customize cross-platform scheduling by setting the
PRIMARYCCISYSID environment variable. You can also set it on the System
screen of the Unicenter AutoSys Administrator.
You can customize cross-platform scheduling by setting the

PRIMARYCCISYSID environment variable in /etc/auto.profile.
The environment variable is initially configured during Scheduler installation.
PRIMARYCCISYSID = cci_system_id
cci_system_id
Defines the CAICCI system ID used by the cross-platform scheduling
interface when communicating with remote mainframe or UUJMA nodes.
This environment variable is key to providing failover support in the
Unicenter AutoSys JM environment if the Primary Scheduler shuts down or
becomes unreachable.
If the Primary Scheduler fails over, all communication on the Secondary
Scheduler proceeds as normal. Any statuses currently residing on the
Agent computers (mainframe or UUJMA) are dispatched to the Secondary
Scheduler computer for processing.
364 User Guide
Bi-Directional Scheduling
Bi-Directional Scheduling
You can use bi-directional scheduling to employ Unicenter AutoSys JM as the
workload manager, to define a job to run on any Unicenter Workload Agent
machine that is defined in the Event Server; and also employ Unicenter
AutoSys JM as the Workload Agent machine by using any Unicenter workload
manager to schedule a previously defined Unicenter AutoSys JM job.
You can also use the cross-platform interface to start jobs in other Unicenter
AutoSys JM instances. Any instance can initiate or be a recipient of any other
instance, regardless of platform or Event Server, provided the instances run
on distinct servers (although these instances can share the same Event
Server).
To enable this feature, you must select a specific instance in the

Unicenter AutoSys JM Administrator and select option 2 - Enable outbound and
inbound cross-platform scheduling (manager and Agent) from the Cross
Platform Scheduling drop-down list on the Scheduler screen.
To enable this feature, you must set the cross-platform scheduling

parameter (CrossPlatformScheduling) in the $AUTOUSER/config.$AUTOSERV
configuration file to 2.
Note: There is no restriction on platforms, Event Servers, or number of
instances when running in bi-directional scheduling mode.
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 or z/OS environment. For
example, the following illustration shows that a job defined to run on a UNIX
or Windows computer could have as a starting condition the successful
completion of a Unicenter AutoSys JM Connect job running on a mainframe
system.
Note: CAICCI components are listed in the Windows or UNIX Implementation

Guide.
The Scheduler uses the cross-platform scheduling interface to communicate
with Unicenter AutoSys JM Connect.
Note: Throughout this section, jobs defined in the mainframe scheduling
products are referred to as Unicenter AutoSys JM Connect jobs. For
implementation details, see the Unicenter AutoSys JM Connect documentation.
366 User Guide
Naming Conventions for Unicenter AutoSys JM Connect Cross-Platform Jobs

Due to naming limitations in the mainframe 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 letter (A-Z), a

pound sign (#), an at sign (@), or a dollar sign ($).
The remaining characters in the job name can be any combination of

uppercase letters (A-Z), numbers (0-9), pound signs (#), at signs (@),
and dollar signs ($).
All letters (A-Z) must be in uppercase.
Job names can be up to eight characters in length.
Note: These limitations only apply to jobs that are referenced to Unicenter
AutoSys JM Connect.
How Job Scheduler Interdependencies Are Created

Unicenter AutoSys JM 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 Unicenter AutoSys JM jobs. Unicenter AutoSys JM
uses the following process to create this type of cross-platform dependency:
1.
The Unicenter AutoSys JM Scheduler sends a request for the status of a

Unicenter AutoSys JM Connect job.
2.
Unicenter AutoSys JM Connect registers the request.
3.
The Unicenter AutoSys JM Connect job runs on the mainframe.
4.
Unicenter AutoSys JM Connect sends the job status to the Unicenter

AutoSys JM Scheduler.
5.
The Unicenter AutoSys JM Scheduler communicates the status to the Event

Server.
6.
The Unicenter AutoSys JM Scheduler processes the status and starts the
job that is dependent on the completion of the Unicenter AutoSys JM
Connect job, if appropriate.
Define Cross-Platform Job Dependencies

To define a cross-platform job dependency, use the following notation in the
condition attribute of the dependent job definition:
condition: status(JOB_NAME^INS)
status
Specifies one of the following statuses:
SUCCESS
TERMINATED
DONE
NOTRUNNING
When the specified Unicenter AutoSys JM Connect job completes with the
specified status, the job dependency is satisfied.
JOB_NAME
Note: Job names for cross-platform dependencies must all be uppercase.
^
Indicates that the job resides on a different Unicenter AutoSys JM
instance.
INS
Defines the three-letter uppercase identifier of the external instance on
which the specified job is running.
Example: Unicenter AutoSys JM Connect Cross-Platform Dependency
This example defines a dependency for a job that starts only upon the
successful completion of a Unicenter AutoSys JM Connect job (JOBA), which
runs on an external instance named CA7:
condition: success(JOBA^CA7)
368 User Guide
Running Jobs on UUJMA

Unicenter AutoSys JM can directly schedule jobs on a computer that is running
a supported Unicenter Workload Agent, assuming the computer running the
Agent has been defined to Unicenter AutoSys JM. For this example, we will use
the Unicenter Universal Job Management Agent (UUJMA).
Note: CAICCI components are listed in the Windows or UNIX Implementation

Guide.
The Scheduler communicates directly with UUJMA through CAICCI.
The communication components running on the computer receive information
from the Scheduler and pass it to UUJMA. Similarly, UUJMA passes information
through the communication components to the Scheduler.
Note: For jobs run to the mainframe or where Unicenter AutoSys JM is used
as a Unicenter Workload Agent, the execution string is a job name as defined
in the scheduling system or manager. Otherwise, the execution string is a
script name or executable.
Naming Conventions for UUJMA Job Names and User IDs

UUJMA job names and user IDs have the same naming restrictions as
Unicenter AutoSys JM, with the exception of jobs submitted to the mainframe.
Where the operating system permits, UUJMA job names can contain up to 64
alphanumeric characters and UUJMA user IDs can contain up to 30
alphanumeric characters. These job names and user IDs can contain both
uppercase and lowercase characters (when the operating system permits
mixed case). You cannot use blank spaces and tab characters in UUJMA job
names and user IDs.
Jobs submitted to the mainframe use the same naming conventions as jobs
that are run through Unicenter AutoSys JM Connect.
More information:
Naming Conventions for Unicenter AutoSys JM Connect Cross-Platform Jobs
(see page 367)
How Jobs Are Run On UUJMA-Managed Computers

The process by which Unicenter AutoSys JM can run jobs directly on a
UUJMA-managed computer is as follows:
370 User Guide
The Scheduler sends the job information to UUJMA.
The job changes to STARTING status.
UUJMA starts the job and sends an event to the Scheduler (JOBINITU if it
could start the job, or JOBFAILU if it could not start the job).
The Scheduler converts the JOBINITU event to RUNNING, puts it in the

database, and updates the job's status to RUNNING. If UUJMA sent a
JOBFAILU event, the Scheduler converts the event to FAILURE and
processes it accordingly.
If the job completes successfully, UUJMA sends a JOBTERMU event to the

Scheduler.
The Scheduler converts the JOBTERMU event to SUCCESS, FAILURE, or

TERMINATED based on the exit code of the job (if the job exited with a
normal end-of-job code, EOJ, the Scheduler converts JOBTERMU to
SUCCESS or FAILURE; if the job exited with an abnormal end of job code,
AEOJ, the Scheduler converts JOBTERMU to TERMINATED).
Define UUJMA Computers

Before you can run jobs on a UUJMA computer, you must define the computer
to Unicenter AutoSys JM. To define a UUJMA computer, use the following JIL
statements:
insert_machine: remote_host
type: machine_type
remote_host
Defines the name of the UUJMA computer.
machine_type
Specifies the type of machine you are defining:
u
Indicates a computer running UUJMA. This can be a computer running
Unicenter NSM JMO, Unicenter CA-7, Unicenter CA-Jobtrac, Unicenter
CA-Scheduler, or Unicenter AutoSys JM.
c
Indicates a computer running Unicenter AutoSys JM Connect.
If Unicenter AutoSys JM Connect is running on the same computer as
Unicenter CA-7, Unicenter CA-Jobtrac, Unicenter CA-Scheduler, or any
OS/390 scheduling system, you should set machine_type to c.
Note: UUJMA-managed computers cannot be part of a virtual machine. The
job_load, max_load, and factor attributes are not supported for
UUJMA-managed computers.
Example: Define a UUJMA Computer
This example defines the computer MYAGENT, which is running UUJMA with
Unicenter NSM, Unicenter CA-7, Unicenter CA-Jobtrac, Unicenter
CA-Scheduler, or Unicenter AutoSys JM:
insert_machine: MYAGENT
type: u
Add User IDs and Passwords on a UUJMA Computer

After you define a UUJMA computer to Unicenter AutoSys JM, you can use the
machine attribute to specify that computer in a job definition. 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 UUJMA computer. The account must match the owner
name exactly for the job to run. You must specify the owner of the job
definition as user@machine. The EDIT Superuser must use the autosys_secure
command to add valid accounts and passwords on the UUJMA computer.
To add user IDs and passwords on a UUJMA Computer
1.
Issue the following command at the command prompt:

$ autosys_secure
The Security Utility starts and displays the AutoSys Security Utility menu.
2.
Select option 5 (Manage AutoSys User@Host users) from the menu:

AutoSys Security Utility
>5
The Manage AutoSys User@Host users menu is displayed.
372 User Guide
3.
Select option 1 (Create AutoSys User@Host or Domain password) from the

menu:
Manage AutoSys User@Host users
[1] Create AutoSys User@Host or Domain password.
[2] Change AutoSys User@Host or Domain password.
[3] Delete AutoSys User@Host or Domain password.
[4] Show all AutoSys User@Host users.
[9] Exit from "Manage AutoSys User@Host users" menu.
>1
The Security Utility prompts you to enter user information.

4.
Enter the user name, user host or domain, and password information
when prompted:
CAUAJM_I_60207 Create an USER@HOST user:
Input the user name (or hit enter to cancel): BOB
Enter user Host or Domain (or hit enter to cancel): ZASYS400
Enter new password:
******
Enter new password again:
******
You have successfully added a user when the Security Utility displays the
following message:
CAUAJM_I_60135 User Create successful.
Job Definition Examples

These examples require that you activate the cross-platform interface of the
Unicenter AutoSys JM Scheduler and that you define the proper computer
definition to the Event Server.
Example: Define a Job to Run on an AS/400 Computer
This example defines a command job to run on an AS/400 computer:
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
Example: Define a Job to Run Through Unicenter AutoSys JM Connect

This example defines a command job to run in Unicenter CA-7 through
Unicenter AutoSys JM Connect:
insert_job: ca71
job_type: c
command: auto_cnct -a A87SOENF -j RYAKEJ01 -c RUN -p SCHEDULE=RYAKE01 -s CA7

machine: A87SOENF
owner: user1@A87SOENF
permission: gx,wx
date_conditions: 1
days_of_week: all
start_mins: 45
Example: Define a Job to Run Directly

This example defines a command job to run directly in Unicenter CA-7:
insert_job: ca72
job_type: c
command: RYAKEJ01
machine: A87SOENF
owner: user1@A87SOENF
permission: gx,wx
date_conditions: 1
days_of_week: all
start_mins: 45
374 User Guide
Example: Define a Job to Run in Another Unicenter AutoSys JM

Instance
This example defines a command job to run in another Unicenter AutoSys JM
instance:
insert_job: ca72 job_type: c
command: job_in_other_instance
machine: othermachine
owner: user1@othermachine
permission: gx,wx
date_conditions: 1
days_of_week: all
start_mins: 45
The following assumptions were made in this example:
In the machine definition for othermachine, machine_type was set to u,

indicating a machine that runs UUJMA.
The cross-platform interface has been activated on the server (where job
ca72 is being submitted) by setting the CrossPlatformScheduling
parameter to 1 (run jobs directly on a UUJMA Agent). If this instance will
receive job submissions from any workload manager in the enterprise, set
the CrossPlatformScheduling parameter to 2 (enable bi-directional
scheduling support) instead.
The CrossPlatformScheduling parameter for the machine othermachine is

set to 2 (enable bi-directional scheduling support).
Example: Define a Job to Run on an OpenVMS Computer

This example defines a command job to run on an OpenVMS computer:
insert_job: vmsjob1
command: @SYS$LOGIN:SCHEDULE_WAIT.COM
machine: VMSNODE
owner: system@VMSNODE
max_exit_success: 1
Note: A job that runs successfully on an OpenVMS computer returns an exit

code of 1. By default, Unicenter AutoSys JM interprets an exit code of 1 as a
failure unless the max_exit_success attribute is properly set in the job
definition.
Cross-Platform Interface Messages
Cross-Platform Interface Messages

All messages produced by the cross-platform interface are written to the
Unicenter AutoSys JM Scheduler log, which is located in the
%AUTOUSER%\out directory.
All messages produced by the cross-platform interface are written to the

Unicenter AutoSys JM Scheduler log, which is located in the $AUTOUSER/out
directory.
The following message indicates that the Scheduler has transferred a job to
the cross-platform interface for submission to a UUJMA:
CAUAJM_I_10073 AutoSys --> Cross Platform Interface:
machine=machine_name
job_name=job_name
machine_name
Identifies the UUJMA computer to which the job is being submitted.
job_name
Identifies the Unicenter AutoSys JM job name as defined to the Event
Server.
The following message indicates that an event status has been received from
UUJMA. The event status is converted to the appropriate Unicenter AutoSys JM
event status and inserted in the Event Server.
CAUAJM_I_40263 EVENTU: event_name
EXITCODE: exitcode/dbcode JOB: job_name
event_name
Identifies one of the following events:
JOBINITU
Indicates that a job has started on a UUJMA.
JOBTERMU
Indicates that a job has completed on a UUJMA.
JOBFAILU
Indicates that a job has failed to start on a UUJMA.
SUBMITU
Indicates that a job has been submitted to Unicenter AutoSys JM.
exitcode/dbcode
Identifies the actual job exit code returned by the UUJMA.
376 User Guide
Unsupported Attributes for Unicenter AutoSys JM Connect or UUJMA Jobs
job_name
Identifies the Unicenter AutoSys JM job name as defined to the Event
Server.
Unsupported Attributes for Unicenter AutoSys JM Connect or

UUJMA Jobs
The following table lists attributes that are not supported for Unicenter
AutoSys JM Connect or UUJMA-managed jobs. If you specify these attributes,
they are ignored.
JIL Attribute
UI 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
Queue 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 check Steady State
Appendix B: Legacy Agent

Considerations
Running Jobs on Computers with Legacy Unicenter AutoSys JM Agents (see
page 380)
Legacy Agent Considerations 379
Running Jobs on Computers with Legacy Unicenter AutoSys JM Agents
Running Jobs on Computers with Legacy Unicenter AutoSys

JM Agents
Unicenter AutoSys JM can schedule jobs on a computer that is running a
previous product version (or legacy version) of the Unicenter AutoSys JM
Agent. Because legacy Agents connect directly to the database in order to add
job events, Unicenter AutoSys JM only works with legacy Agents running the
same database vendor as the Event Server. In addition, the Unicenter AutoSys
JM instance identifier (AUTOSERV) must match the instance identifier of the
legacy Agent.
Define Legacy Agent Computers

With Unicenter AutoSys JM r11 (including service packs), the Scheduler
component has the capability to run jobs on both Unicenter AutoSys JM and
legacy Agent computers. Due to the differences in the communication protocol
used by Unicenter AutoSys JM r11 (including service packs) and legacy Agent
computers, the Scheduler component must know which communication
protocol to invoke before contacting the Agent computer. This is done by
examining the Agent's machine definition type attribute. If the type attribute is
set to either l or L, the Scheduler component prepares the job data using the
legacy protocol before sending it to the Agent computer; otherwise it prepares
the data using Unicenter AutoSys JM protocol.
Before you can run jobs on a legacy Agent computer, you must define the
computer to Unicenter AutoSys JM. To define a legacy Agent computer, use
the following JIL statements:
insert_machine: remote_host
type: machine_type
remote_host
Defines the name of the legacy Agent computer.
machine_type
Specifies the type of machine you are defining:
l
Indicates a UNIX computer running a Unicenter AutoSys JM legacy
Agent. This machine type lets the Scheduler know how to use the
legacy communication protocol to communicate with the Agent and is
analogous to an r-type computer for Unicenter AutoSys JM.
L
380 User Guide
Indicates a Windows computer running a Unicenter AutoSys JM legacy

Agent. This machine type lets the Scheduler know how to use the
legacy communication protocol to communicate with the Agent and is
analogous to an n-type computer for Unicenter AutoSys JM.
Note:
Legacy Agent computers may form part of a virtual machine. The job_load,
max_load, and factor attributes continue to support legacy Agent computers.
As part of the Event Server data migration from a previous product version to
Unicenter AutoSys JM r11 (including service packs), pre-defined machines of
type 'r' are converted to type 'l' and pre-defined machines of type 'n' are
converted to type 'L'. For more details about data migration from a previous
product version, see the Windows or UNIX Implementation Guide.
Example: Define a Legacy Agent Computer
This example defines the UNIX computer MYLEGACYUNIXAGENT, which is
running a previous version of Unicenter AutoSys JM:
insert_machine: MYLEGACYUNIXAGENT
type: l
Define the Legacy Agent Port

In addition to setting the type attribute of the machine definition for each
legacy Agent computer, the Legacy Agent Port value must also be set in the
Unicenter AutoSys JM environment. This value specifies the port number to be
used by the Scheduler to communicate with legacy Agent computers.
On Windows, the Legacy Agent Port value can be set in the Scheduler screen
of the Unicenter AutoSys Administrator, while on UNIX you can set this value
by locating and updating the AutoRemPort string in the
$AUTOUSER/config.<instance> file.
Note: The Agent for Unicenter AutoSys JM r11 (including service packs) has
been decoupled from the UNIX internet daemon (inetd). Therefore, the
installation does not add any service entries to either the UNIX services (found
in /etc/services) or the inetd configuration files (/etc/inetd.conf).
Add User IDs and Passwords for a Windows Legacy Agent Computer
After you define a legacy Agent computer to Unicenter AutoSys JM, you can
use the machine attribute to specify that computer in a job definition. For
example:
insert_job: aslegacyjob
owner: user@legacyagenthost
machine: legacyagenthost
command: my_command
The owner identified in the owner attribute of the job definition must have an
account on the target legacy Agent computer. The account must match the
owner name exactly for the job to run. You must specify the owner of the job
definition as user@machine. The EDIT Superuser must use the autosys_secure
command to add valid accounts and passwords for a Windows legacy Agent
computer just as you do for a Windows Unicenter AutoSys JM Agent.
382 User Guide
To add user IDs and passwords for a Windows legacy Agent computer
1.
Issue the following command at the command prompt:

$ autosys_secure
The Security Utility starts and displays the AutoSys Security Utility menu.
2.
Select option 5 (Manage AutoSys User@Host users) from the menu:

AutoSys Security Utility
>5
The Manage AutoSys User@Host users menu is displayed.

3.
Select option 1 (Create AutoSys User@Host or Domain password) from the

menu:
Manage AutoSys User@Host users
[1] Create AutoSys User@Host or Domain password.
[2] Change AutoSys User@Host or Domain password.
[3] Delete AutoSys User@Host or Domain password.
[4] Show all AutoSys User@Host users.
[9] Exit from "Manage AutoSys User@Host users" menu.
>1
The Security Utility prompts you to enter user information.

4.
Enter the user name, user host or domain, and password information
when prompted:
CAUAJM_I_60207 Create an USER@HOST user:
Input the user name (or hit enter to cancel): user
Enter user Host or Domain (or hit enter to cancel): legacyagenthost
Enter new password:
******
Enter new password again:
******
You have successfully added a user when the Security Utility displays the
following message:
CAUAJM_I_60135 User Create successful.
How Jobs Are Run On Legacy Agent Computers

The process by which Unicenter AutoSys JM can run jobs directly on a legacy
Agent computer is as follows:
After evaluating the job start conditions, the Scheduler places the job in a
STARTING status.
The Scheduler recognizes the type of the machine as a computer running a

legacy Agent.
The Scheduler obtains the port number of the legacy Agent computer from
its configuration settings.
The Scheduler initiates communication with the legacy Agent computer.

On Windows, the Agent service starts the Agent process. On UNIX, the
internet daemon (inetd) starts the Agent process.
The Scheduler prepares the job details using the legacy Agent
communication protocol. The Scheduler then sends the information to the
newly started Agent process.
The legacy Agent completes the communication protocol with the

Scheduler and starts the job.
The legacy Agent puts a RUNNING event directly into the Event Server.
The Scheduler processes the RUNNING event.
After the job completes, the legacy Agent puts a SUCCESS, FAILURE, or
TERMINATED event directly into the Event Server based on the exit code
of the job.
The Scheduler processes the end status event.
Note:
If the Scheduler log reports an error while trying to run a job on a computer
with a legacy Agent, see the Agent log file on the remote computer for details.
The legacy Agent log may report some database errors while trying to send
job status events even when the Scheduler log shows that the job has
completed successfully. The errors are due to the differences between the new
Unicenter AutoSys JM database tables and the tables expected by the legacy
Agent. These database errors do not prevent the job event from being sent to
the Event Server and must be ignored.
384 User Guide
Appendix C: General Debugging

ISDBGACTIV (see page 385)
ISDBGACTIV
The ISDBGACTIV setting controls the display of trace messages. The
configuration of the ISDBGACTIV setting is different for the various
components. This section explains how to configure Unicenter AutoSys JM to
generate runtime traces.
Configure the Client Utilities to Run With Traces

For the client utilities, ISDBGACTIV is an OS environment variable you must
set before initiating the utilities.
On Windows, use the set command to set ISDBGACTIV.
On UNIX, use either the setenv or export command, depending on your

UNIX operating system, to set ISDBGACTIV.
Upon startup, the traceable applications search for the specified ISDBGACTIV
value and output the appropriate trace messages according to the value
assigned.
General Debugging 385
ISDBGACTIV
Configure the Scheduler and Application Server to Run With Traces

ISDBGACTIV is a registry key for the Scheduler and Application Server
on Windows. You can set it on the System screen in the Unicenter AutoSys
Administrator.
On UNIX, ISDBGACTIV is a parameter in the configuration file on UNIX.

Enter a value for the ISDBGACTIV parameter in the
On startup, the traceable applications search for the specified ISDBGACTIV
value and output the appropriate trace messages.
Note: You can change the ISDBGACTIV value at any time while the traceable
applications are running.
For the Scheduler or Application Server to read the new value after it
has been set on Windows, you must locate the service in the Windows Service
Control Manager, and pause and resume the service.
For the Scheduler or Application Server to read the new value after it
has been set on UNIX, you must obtain the process id of the application, and
use the signal -HUP UNIX command to issue the SIGHUP signal. The new trace
level will be displayed in the log file for confirmation.
386 User Guide
ISDBGACTIV
Configure the Agent to Run With Traces

ISDBGACTIV is a registry key for the Agent on Windows. You can set it
on the Unicenter AutoSys Agent screen in the Unicenter AutoSys JM
Administrator.
ISDBGACTIV is an environment descriptor located in the

/etc/auto.profile file on the remote Client in UNIX. Enter a value for the
#AUTOENV#ISDBGACTIV entry in the /etc/auto.profile file.
On startup, the traceable applications search for the specified ISDBGACTIV
value, and output the appropriate trace messages. Job Agent processes
started by the Agent search for the value and set it once for the life of the
process.
Note: You can change the ISDBGACTIV value at any time while the Agent is
running.
For the Agent to read the new value after it has been set on Windows,
you must locate the service in the Windows Service Control Manager, and
pause and resume the service.
For the Agent to read the new value after it has been set on UNIX, you
must obtain the process id, and use the signal -HUP UNIX command to issue a
SIGHUP signal. The new trace level will be displayed in the log file for
confirmation.
General Debugging 387
ISDBGACTIV
Trace Settings
The following table describes how Unicenter AutoSys JM interprets the
ISDBGACTIV values:
ISDBGACTIV
Value
Description
OFF
No Traces
MS
Adds milliseconds to the timestamp in the log output
LIGHT
Light Traces
HEAVY
Heavy Traces
JOB
Traces the run time of a job
DUMP
Traces data sent and received by the cross-platform

interface
GBE
(Scheduler only) Traces scheduler events as they are

read from the ujo_event table
COMM
Traces network communication activity at the sockets

level
Note: To combine trace settings, separate each setting with a comma (,). If
you use the OFF setting with other settings, the traceable applications will not
display a trace.
The Scheduler, Application Server, Agent, client utilities, and communication
and database infrastructure routines generate trace messages.
For components such as the Scheduler that generate their own log files, trace
messages are added to these log files at various places when the components
encounter them.
For applications (such as client utilities like jil, autorep, and sendevent) that
are executed interactively or in batches, trace messages are written to the
active window or to a file if streamed accordingly.
388 User Guide
Appendix D: Message Port and SSL

Configuration
Configuring Unicenter AutoSys JM to Use PMUX and SSL (see page 389)
Port Multiplexing (see page 389)
How to Configure Unicenter AutoSys JM to Run with SSL (see page 392)
Configuring Unicenter AutoSys JM to Use PMUX and SSL

Unicenter AutoSys JM integrates with CA Common components for its network
communication needs. CA Common components, installed as part of the
Unicenter AutoSys JM product installation, includes SSA, an application that
serves as an abstract layer between Unicenter AutoSys JM and the operating
system network socket libraries. In addition to offering support for standard
peer-to-peer communications, SSA offers other features, such as port
multiplexing (PMUX) and secured encryption of transport data.
Port Multiplexing
The PMUX feature of SSA enables network data intended for multiple ports on
the same host to be redirected through a single physical port. Using PMUX
increases availability of physical ports and reduces the number of ports that
are exposed through a firewall. Physical port 7163 has officially been
registered with the Internet Assignment Numbers Authority (IANA) for use by
CA products. Therefore, the ports that are configured for the Unicenter
AutoSys JM Application Server and Agent during installation are considered to
be virtual ports that map to physical port 7163.
SSA consists of a Connection Broker that receives incoming data from the
physical port and redirects it to the corresponding network application that is
listening on a virtual port. Similarly, the Connection Broker redirects all
outgoing data sent by network applications using different virtual ports
through the same physical port.
For the Connection Broker to effectively redirect network traffic to the correct
application, it must be told what virtual ports to recognize. During installation,
Unicenter AutoSys JM configures the virtual ports it intends to use. If,
however, you want to change any of the virtual ports originally set during
installation, you must perform an additional configuration step.
Message Port and SSL Configuration 389
Port Multiplexing
How to Configure the Application Server to Listen on a Different Virtual Port

There are several reasons why you might want to reconfigure the port on
which the Application Server listens. For example, you might want to
reconfigure the port if:
The default virtual port is in use by another CA product and you want that
product to continue using that virtual port.
You want to enable more than one Application Server to run on the same
host (which requires you to specify a unique virtual port for each
Application Server).
Use the following process to configure the Application Server to listen on a

different virtual port:
1.
Shut down all instances of Unicenter AutoSys JM Scheduler, Application

Server, and Agent.
2.
Open a command prompt to the bin folder of the location specified by the
CSAM_SOCKADAPTER environment variable and run the following
command:
csamconfigedit port=nnnn EnablePmux=True
nnnn
Defines the port number to configure.
3.
Run the following command to display the configuration information for the
specified virtual port:
csamconfigedit port=nnnn display
4.
Stop the SSA, by doing the following:

Stop the CA Connection Broker service from the Windows Service
Control Manager.
csampmux stop
5.
Start the SSA, by doing the following:

Restart the CA Connection Broker service from the Windows Service
Control Manager.
csampmux start
390 User Guide
Port Multiplexing
6.
Enter the new port number for the Application Server.

In the Application Server Port field on the Instance Screen of the
Unicenter AutoSys Administrator.
In the AutoServerPort parameter in the
7.
Start all instances of Unicenter AutoSys JM Scheduler, Application Server,

and Agent.
8.
Repeat this process on all computers with an Agent-only or Client

installation that communicates with the Application Server for which you
configured the new port.
Virtual Ports Used by Unicenter AutoSys JM

Both the Unicenter AutoSys JM Application Server and Agent require a
persistent port on which to listen for incoming connections. By default, the
Unicenter AutoSys JM installation configures SSA to recognize virtual port
9000 for use by the Application Server and virtual port 49152 for use by the
Agent. You can configure the Application Server to listen on a different virtual
port.
However, for interaction to and from the Unicenter AutoSys JM Application
Server and between the Scheduler and Agent, virtual ports are dynamically
assigned with values in the range of 49153 - 50176. This range of port values
is also known as the ephemeral port range and is reserved for short-term
communications. The Unicenter AutoSys JM installation also configures SSA to
register the ephemeral port range as virtual ports.
More Information:
Port Multiplexing (PMUX) (see page 33)
How to Configure Unicenter AutoSys JM to Run with SSL

The SSL feature of SSA provides an added layer of protection by encrypting
network data before transmission over the network and decrypting the data
upon receipt. Unicenter AutoSys JM does not enable SSL by default. This
section discusses how to configure Unicenter AutoSys JM to use SSL.
Because the Unicenter AutoSys JM Scheduler, Agent, Application Server, and
Client interact with one another, if SSL is enabled for one of the components,
it must be enabled for all components (including remote computers) for
Unicenter AutoSys JM to work. It is impossible for a process on a host that is
SSL-enabled to communicate with a process on a host that is not SSL-enabled.
A Client can be on the same machine that hosts a server process but does not
have to be. Typically, a Client process is remote from the server process.
Clients communicate with servers across operating systems with no additional
configuration. The SSL encryption works across operating systems as well,
with no additional configuration other than what is required for each host. All
messages are encrypted, whether they are local or across the network.
Enablement of SSL within the Unicenter AutoSys JM inter-process
communication environment will result in additional overhead being incurred
at process startup time. Persistent processes such as the Scheduler,
Application Server, and Agent will incur this one time cost at startup and then
function normally thereafter. Client processes which are short running in
nature or are invoked repetitively such as JIL, autorep, or sendevent will incur
this cost for each process invocation.
Use the following process to configure Unicenter AutoSys JM to run with

SSL:
1.
Shut down all instances of Unicenter AutoSys JM Scheduler, Application

Server, and Agent
2.
Open a command prompt to the bin folder of the location specified by the
CSAM_SOCKADAPTER environment variable and run the following
command:
csamconfigedit port=nnnn EnableSSL=True
nnnn
Defines the port number to configure.
Note: By default, the Unicenter AutoSys JM installation configures 9000 as
the Application Server port. If you selected another port value for the
Application Server, use that port number when configuring SSL.
392 User Guide
3.
Run the following command to display the configuration information for the
specified virtual port:
csamconfigedit port=nnnn display
4.
Run the following command to enable SSL for the virtual ports in the
ephemeral port range:
csamconfigedit PortRange=49152-50176 EnableSSL=True
5.
Stop the CA Connection Broker service from the Windows Service Control
Manager.
6.
Restart the CA Connection Broker service from the Windows Service

Control Manager.
7.
Start all instances of Unicenter AutoSys JM Scheduler, Application Server,

and Agent.
8.
Repeat this process on all machines with a Unicenter AutoSys JM

installation.
To enable SSL, run the following commands as user root from a

Unicenter AutoSys JM environment. In the example below, the port value of
9000 is the port on which the Application Server is listening. This Application
Server port is configurable and need not be 9000, but whatever it is set to,
you must enable it in this same manner. You can view or change this value by
locating AutoServerPort in the config.instance file. If you run more than one
Application Server, you must enable each Application Server in this manner.
Likewise, if you run more than a single Application Server, you must enable
each Application Server in this same manner.
# cd $CSAM_SOCKADAPTER/bin
#
# csamconfigedit port=9000 EnableSSL=true display
#
# csamconfigedit PortRange=49152-50176 EnableSSL=true display
The parameter EnableSSL= should show a value of true.

If you enable an Application Server port other than the default, you must also
consider how you want that port to behave under the port multiplexing feature
and enable it accordingly.
Note: You must run these commands on every host in the Unicenter AutoSys
JM network. After the procedure is complete for a given host, you must stop
and restart all Unicenter AutoSys JM processes on the newly SSL-enabled
host. After all hosts are enabled, all Unicenter AutoSys JM network traffic is
encrypted under SSL.
Appendix E: Aggregator Considerations

About Unicenter AutoSys JM Aggregator (see page 395)
Running the Unicenter AutoSys JM Aggregator (see page 396)
Unicenter AutoSys JM Aggregator Statistics (see page 397)
About Unicenter AutoSys JM Aggregator

The Unicenter AutoSys JM aggregator collects raw data from various product
tables and stores the data in statistics tables. This statistical information is
used by applications such as, Unicenter WCC to provide a quick and easy way
to generate custom and canned reports. Without aggregated statistics, an
application requiring this data would need to make numerous database
queries, not to mention the calculations required to produce this statistical
data.
The aggregation process computes and stores statistics based on hour
intervals. Once the aggregated data is available in the database, an application
can retrieve these aggregated statistics by using the products public SDK. By
utilizing the Unicenter AutoSys JM aggregator, an application can now extract
product based statistical data quickly and efficiently.
More information:
Unicenter AutoSys JM Aggregator Statistics (see page 397)
Aggregator Considerations 395
Running the Unicenter AutoSys JM Aggregator
Running the Unicenter AutoSys JM Aggregator

The aggregator should be run on a daily basis at a minimum. The aggregator
can be executed on an hourly basis and is the preferred recommendation.
Executing the program on an hourly basis reduces the amount of time required
to aggregate raw data as it is only aggregating the data that is collected in one
hour when compared to the data collected over a 24 hour period.
A second benefit to aggregate data on an hourly basis is that an application
which references aggregated data will be able to display statistical information
up to the previous hour as opposed to the prior day.
To aggregate data every hour, schedule it at the fifth minute so that previous
hour data can be viewed immediately. To aggregate once a day, schedule it so
that aggregation is done when the system is not loaded or lightly loaded.
Note: You should avoid scheduling the aggregator process during your daily
scheduled database maintenance or while executing the Unicenter AutoSys JM
DBMaint program.
396 User Guide
Unicenter AutoSys JM Aggregator Statistics

The following statistics are calculated on an hourly basis:
alarms_database_rollover
Generates the total number of DB_ROLLOVER alarms due to the database
rollover from dual event server mode to single event server mode.
alarms_job_failure
Generates the total number of JOBFAILURE alarms due to jobs that are in
FAILURE or TERMINATED status.
alarms_max_retrys
Generates the total number of MAX_RETRYS alarms.
alarms_max_runtime
Generates the total number of MAXRUNALARM alarms.
alarms_min_runtime
Generates the total number of MINRUNALARM alarms.
alarms_scheduler_rollover
Generates the total number of EP_ROLLOVER alarms when the Shadow
Scheduler takes over.
alarms_scheduler_shutdown
Generates the total number of EP_SHUTDOWN alarms.
alarms_start_job_failure
Generates the total number of STARTJOBFAIL alarms.
alarms_unanswered
Generates the total number of alarms that are open, that is, alarms
neither acknowledged nor closed.
alarm_total
Generates the total number of alarms, irrespective of alarm status.
alarm_response_time_avg
Generates the average time taken to respond to an alarm.
jobs_failure
Generates the total number of jobs in FAILURE status.
jobs_inactive
Generates the total number of jobs in INACTIVE status.
jobs_onhold
Generates the total number of jobs in ON_HOLD status.
Aggregator Considerations 397
jobs_onice
Generates the total number of jobs in ON_ICE status.
jobs_restart
Generates the total number of jobs in RESTART status.
jobs_running
Generates the total number of jobs in RUNNING status.
jobs_starting
Generates the total number of jobs in STARTING status.
jobs_success
Generates the total number of jobs in SUCCESS status.
jobs_terminated
Generates the total number of jobs in TERMINATED status.
job_failures
Generates the total number of jobs that are in FAILURE or TERMINATED
status.
job_runs
Generates the total number of jobs that ran in that hour.
job_force_starts
Generates the total number of jobs that were force started.
job_kills
Generates the total number of jobs for which KILLJOB event was sent.
job_open_svcdesk
Generates the total number of jobs for which a service desk issue was
opened. This statistic is different from others in that it is not for a
particular hour. It is computed for that Unicenter AutoSys JM instance
depending on when the aggregator was run.
total_events
Generates the total number of events processed.
total_latency
Generates the latency in processing all events. That is the total processing
time that is required for all the events.
398 User Guide
Appendix F: Tuning Unicenter AutoSys

JM
Unicenter AutoSys JM supports scalability. If run on high-end computers, you
can configure Unicenter AutoSys JM to make efficient use of the computers
CPU, memory, and database connections in order to increase the overall
productivity.
Tuning the Scheduler (see page 400)
Tuning the Application Server (see page 402)
Tuning the Agent (see page 403)
Tuning Unicenter AutoSys JM 399
Tuning the Scheduler

On Windows, the registry keys are the Scheduler tuning parameters.
You can set the tuning parameters on the Unicenter AutoSys JM Administrator
System screen.
On UNIX, the OS environment variables are the Scheduler tuning

parameters. You can use either the setenv or export command to set the
tuning parameters, depending on your UNIX operating system. The tuning
parameters may also be set in any one of the environment script files
(autosys.<UNIX shell>.<computer name>) located in the $AUTOUSER
directory.
Upon startup, the tuning parameters are read and applied by the Scheduler
and persist throughout the life of the process. You must shut down the
Scheduler to apply new values for the tuning parameters.
SCHED_SCALE
Controls the maximum limit of process threads that can be started
dynamically as a function of the scale value. This value does not represent
the total number of process threads that are active. Rather, it is a scale
value used by the Scheduler to calculate the maximum limit of threads
that can dynamically be started as the workload demands. A
SCHED_SCALE value of 1 therefore represents the lowest ceiling of
additional dynamic threads that can be started to process job events
(some arbitrary ceiling not necessarily equal to one). Increasing this value
increases the Schedulers ability to process job events.
Default: 5
Limit: 1 to 64
400 User Guide
DB_CONNECTIONS
Controls the maximum number of database connections allotted to the
Scheduler. Increasing this value increases the Schedulers ability to
perform simultaneous database operations.
Default: 16
Limit: 1 to 128
Note: The Application Server also shares the same DB_CONNECTIONS

tuning parameter. If the Scheduler and Application Server are run on the same
Windows computer, then this value will be applied to both processes upon
startup.
Note: The Application Server also shares the same DB_CONNECTIONS

tuning parameter. If you set this value in the environment script files located
in the $AUTOUSER directory and start the Scheduler and Application Server on
the same UNIX computer after sourcing the environment, then this value will
be applied to both processes upon startup.
Tuning the Application Server
Tuning the Application Server

On Windows, the registry keys are the Scheduler tuning parameters.
You can set the tuning parameters on the Unicenter AutoSys JM Administrator
System screen.
On UNIX, the OS environment variables are used as the Application

Server tuning parameters. You can use either the setenv or export command
to set the tuning parameters, depending on your UNIX operating system. The
tuning parameter may also be set in any one of the environment script files
(autosys.<UNIX shell>.<computer name>) located in the $AUTOUSER
directory.
Upon startup, the tuning parameters are read and applied by the Application
Server and persist throughout the life of the process. You must shut down the
Application Server to apply new values for the tuning parameters.
DB_CONNECTIONS
Controls the maximum number of database connections allotted to the
Application Server. Increasing this value increases the Application Server's
ability to process simultaneous Unicenter AutoSys JM Client and Agent
requests.
Default: 32
Limit: 1 to 128
Note: The Scheduler also shares the same DB_CONNECTIONS tuning

parameter. If the Scheduler and Application Server are run on the same
Windows computer, then this value will be applied to both processes upon
startup.
Note: The Scheduler also shares the same DB_CONNECTIONS tuning

parameter. If you set this value in the environment script files located in the
$AUTOUSER directory and start the Scheduler and Application Server on the
same UNIX computer after sourcing the environment, then this value will be
applied to both processes upon startup.
402 User Guide
Tuning the Agent
Tuning the Agent

On Windows, the registry keys are used as the Agent tuning
parameters. You can set the tuning parameters on the Unicenter AutoSys JM
Administrator Agent screen.
On UNIX, the OS environment variables are used as the Agent tuning

parameters. You can use either the setenv or export command to set the
tuning parameters, depending on your UNIX operating system. The tuning
parameter may also be set in the uajm_start script file located in the
/etc/init.d, /etc/rc.d, or /sbin/init.d directory, based on the UNIX operating
system.
Upon startup, the tuning parameters are read and applied by the Agent and
persist throughout the life of the process. You must shut down the Agent to
apply new values for the tuning parameters.
RSP_REGULATOR
Controls the maximum job agent processes that can be started at the
same time. Increasing this value raises the maximum number of
simultaneous job agent processes.
Default: 5
Limit: 1 to 256
Note: The RSP_REGULATOR parameter does not necessarily limit the number
of job agent processes that run on a computer. It only controls how many job
agents can be started at the same time. Long running jobs (file watcher or
otherwise) will not prevent new job agents from starting and running on the
same computer.
Index
$
$AUTORUN 117
$AUTOTESTMODE 232
$AUTOUSER/config.$AUTOSERV 266
%
%AUTOTESTMODE% 232
/
/etc/.autostuff file 291, 292
A
access modes 51
ACTIVATED status 100
activating Unicenter Service Desk interface
352
adding user IDs and passwords 382
administrative privileges 44
administrator
overview 35
starting 36
after_time report attribute 213
agent
computer 28, 357
log files directory 274
maintaining 235
overview 21
setting job profiles 91
starting 236
troubleshooting 314, 318, 321
tuning 403
verifying 314
aggregator
overview 395
running 396
statistics 397
alarm monitor/report attribute 210
alarm_verif monitor attribute 214
alarms
callbacks 293
DB_PROBLEM 293
DB_ROLLOVER 293
EP_HIGH_AVAIL 293
EP_ROLLOVER 293
EP_SHUTDOWN 293
overview 29
verification 214
all_events monitor/report attribute 210
all_status monitor/report attribute 211
application server
overview 19
troubleshooting 331, 332, 334, 337
tuning 402
asset-level security 48, 68
assets
creating 63
deleting 64
listing 65
updating 64
attributes
box job 99
command job 98
file watcher job 98
machine 300, 301
monitor (optional) 214
monitor and report (essential) 209, 210,
211, 212
report (essential) 213
unsupported 377
auto.profile file 288
autodwp command 298
AutoInstWideAppend 284
automated job control 16
autoping command 314
AutoRemoteDir 274
AutoRemPort 282
AUTOSERV variable 28
autosyslog command 315, 316
B
backing up
calendar definitions 220
definitions 221
global variable definitions 222
batch files and exit codes 114
best match policy 50
bi-directional scheduling 357, 365
box jobs
attributes 99, 123
creating 155
Index 405
default behavior 119

flow examples 126, 128, 130, 132
forcing jobs in a box to start 125
guidelines 120
overview 88, 119
running 120
starting conditions 88, 90
status changes 122
time conditions 124
C
cache update interval 47
CAICCI
defined 357
calculating wait time 279
calendars
backing up 220
custom 105
restoring definitions 223
chase command 238
Check_Heartbeat 273
clean_files 238
CleanTmpFiles 275
client
computer 28
defined 25
command jobs 87, 98
communications 27
components
client 25
dual event server 19
event server 18
interaction 22, 303
overview 18
scheduler 20
troubleshooting 303
computers
agent 28, 357
client 28
server 28
configuration
file 266
configuring
application server 390
enterprise job scheduling 361
file parameters 266
message forwarding 345
notification 350
remote authentication 291
406 User Guide
running with SSL 392

scheduler authentication 291
console utilities 35
conventions 16
creating
box job 155
dependent command job 153
file watcher job 152
job definition 76
job groupings 156
new job type 89
simple command job 151
variable definition 95
cross-instance
dependencies 109
scheduling 357
cross-platform
considerations 356, 360
dependencies 357, 368
dependencies (Unicenter AutoSys JM
Connect) 366, 367, 368
environment variable 364
interface messages 376
limitations 356
scheduling 356
CrossPlatformScheduling 283
custom calendars 105
D
database
architecture 241
connections 269
daily maintenance 244
general maintenance 243
maintenance 271
overview 18
passwords 42
storage requirements 243
vendors 18
verifying connection 314
date/time job dependencies 105
daylight time changes 81
DB_CONNECTIONS 400, 402
DBEventReconnect 269
DBLibWaitTime 267
DBMaint script 245, 246
DBMaint.bat batch file 245, 246
DBMaintCmd 271
DBMaintTime 271
deadlock 247, 306

debugging 385
defining
legacy agent computers 380
legacy agent port 381
machines 184
monitor or report 208
real machine 190
virtual machine 191
definitions 357
deleting
box job 162
job 162
job profile 94
real machine 190, 193
variable definition 97
virtual machine 193
dependencies
cross-platform 366, 368
job scheduler interdependencies 367
dependencies (job)
date/time 105
exit code 113
global variables 116
job status 106
dual event servers
defined 19
dynamic workload placement 296, 297
E
EDErrTimeInt 270
edit permissions 71
EDIT superuser 67
EDNumErrors 270
enabling synchronized push 48
encrypting messages 34
enterprise job scheduling
configuring 361
prerequisites 359
environment variables
defining 92
eTrust IAM
asset level security 48
best match policy 50
native security 65
policy synchronization 46
resource classes 49
security control 66
security enabled applications 63
event management 341

event servers
defined 18
failure 249
maintaining 239, 240
overview 18, 111
rollover recovery 248
synchronizing 252
troubleshooting 305, 306
event transfer 271
events
life cycle 342
overview 29
security 73
starting a job 74
EvtTransferWaitTime 271
examples
advanced job flows 134, 136, 137, 138,
139
auto.profile 289
box job flow 126, 128, 130, 132
notification 294
EXEC superuser 68
execute permissions 71
exit codes
batch files 114
FALSE.EXE 114
job dependencies 113, 114
extended functionality
port multiplexing 33
Unicenter AutoSys JM Adapters 30
Unicenter AutoSys JM Agent 31
Unicenter AutoSys JM Connect 30
external instance entries 361
F
factor 184, 188
FAILURE status 100
FALSE.EXE 114
file watcher jobs
attributes 98
creating 152
overview 89
forcing jobs to start 200
G
gid 70
global variables (job dependencies) 116
group ID 70
Index 407
H
handling errors 257
heartbeats 273
high availability
dual event servers 19
shadow scheduler 20
I
INACTIVE status 100
InetdSleepTime 285
installation considerations (event agent) 343
instances
defined 28
interface components 27
ISDBGACTIV 385
J
JIL
adding machines 157
changing a job 159
creating a box job 155
creating a file watcher job 152
creating dependent command job 153
creating job definition 76
creating job groupings 156
defined 17
defining a monitor or report 208
deleting a job 162
example script 166
placing jobs in a box 159
running a job 150
setting job overrides 165
setting time dependencies 160
specifying job overrides 163
subcommands 144
submitting job definitions 148, 149
syntax rules 142
job information language 17, 30
job ownership 69
job profiles manager 93
job scheduling
inbound 358
outbound 358
job states 100
job status 106
job types
job types 146
using 90
408 User Guide
job_load 186
jobs
attributes 98, 99
backing up definitions 220
basic job information 87
box jobs 88
command jobs 87
defining 17
deleting 162
dependencies 106, 113, 116
edit permissions 71
execute permssions 71
file watcher jobs 89
managing job status 108
naming conventions 370
overview 17, 85
permissions 73
placing jobs in a box 159
run numbers and names 117
running JIL 150
running on UUJMA computers 370
setting overrides 165
setting time dependencies 160
specifying job overrides 163
states 100
submitting definitions 148
time/date dependencies 105
types 86
K
KillSignals 281
L
load balancing 197, 206
log 376
look-back conditions 154
M
MachineMethod 280
machines
attributes 300, 301
definitions 189
status 194
maintenance commands 238
managing job status 108
max_load 184, 186
MaxRestartTrys 277
message forwarding 345

message port and SSL configuration 389
modifying configuration values 47
modifying DBMaint.bat file 246
monitors 207, 208
multiple machine queues 205
N
naming conventions 367
native security 65
notifications
configuring 350
installation considerations 349
overview 346
sending 351
working 348
NotifyAckTimeout 286
NotifyServerNode 286
ntrys 117
O
offline 195
ON_HOLD status 100
ON_ICE status 100
online 195
operating environment conventions 16
Oracle
database-specific tools 303
P
passwords 42
PEND_MACH status 100, 196
permissions
edit 71
execute 71
granting 72
machine 71
types 71
Windows NT 73
policy synchronization 46
port multiplexing 389
Q
QUE_WAIT status 100
queuing jobs 200, 201, 204, 205
R
real machines
defining 190
deleting 190, 193
overview 183
RemoteProFiles 276
reports 207, 208
resource classes
as-appl class 51
as-calendar class 52
as-control class 53
as-cycle class 54
as-group class 55
as-gvar class 55
as-job class 56
as-joblog class 58
as-jobtype class 59
as-list class 60
as-machine class 61
as-owner class 62
RESTART status 100
RSP_REGULATOR 403
run number 117
run_num/ntry 117
running
monitor or report 216
scheduler in test mode 232
running jobs on legacy agent computers 380,
384
RUNNING status 100
S
sample configuration file 267
SCHED_SCALE 400
scheduler
authentication 40
cascading errors 270
log 376
log disk space 270
log file location 226
maintaining 217
monitoring 225
overview 20, 110
restoring primary 229
rollover 228
running in test mode 232
start processing 219
starting in global mode 226
stopping 231
troubleshooting 307, 308, 309
Index 409
tuning 400
security
agent authentication 39
asset-level 68
client-side 292
database field verification 38
events sent by users 73
granting permissions 72
job definition encryption 38
job permissions and windows 73
native 65
overview 37
passwords 42
permission types 71
preventing unauthorized access 38
restricting 43
scheduler authentication 40
security control 66
system level 38
user authentication 39
user types 70
security (events) 73
security-enabled application 63
sendevent command 68
sendevent retries 272
server
computer 28
service desk
configuring 352
initiating 354
overview 352
setting parameters 352
ServiceDeskCust 287
ServiceDeskURL 287
ServiceDeskUser 287
shadow scheduler
high availability option 20
SNMP connections 268
SnmpCommunity 268
SnmpManagerHosts 268
specifying relative process power 188
SSL 389, 392
standard time change 82
STARTING status 100
subcommands 144
SUCCESS status 100
superuser
EDIT 67
410 User Guide
EXEC 68
synchronize poll interval time 47
synchronizing databases 252
syntax rules 142
system architecture (example) 22
T
TERMINATED status 100
time changes
date and time attributes 80
daylight saving 81
standard 82
time dependencies 105, 160
troubleshooting
agent 314, 315, 316, 318, 321
application server 321, 331, 332, 337
event server 305, 306
job failure 327, 328, 330
scheduler 307, 308, 309, 312
system components 303
Windows services 304
tuning
agent 403
application server 402
scheduler 400
TZ environment variable 105
U
uid 70
Unicenter AutoSys JM Connect 358
Unicenter AutoSys JM Scheduler 358
Unicenter DSM 296
Unicenter Job Scheduling Manager 358
Unicenter WCC GUI 17
UnicenterEvents 285
unsupported attributes 377
user
authentication 39
types 70
user ID 70
user-defined load balancing 206
utilities 30
UUJMA
adding user IDs and passwords 372
computers 371
defined 358
defining computers 371
job names and user IDs 370
running jobs 369, 370
software requirements 359
V
variable definitions
creating 95
deleting 97
editing 96
virtual machines
defining 191
deleting 193
overview 184
virtual port 390
Index 411

UAJM User ENU PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UAJM User ENU PDF

Uploaded by

Copyright:

Available Formats

Unicenter AutoSys Job

CA Technologies Product References

eTrust Identity and Access Management (eTrust IAM)

eTrust Access Control (eTrust AC)

Unicenter AutoSys Job Management (Unicenter AutoSys JM)

Unicenter CA-7 Job Management (Unicenter CA-7)

Unicenter CA-Jobtrac Job Management (Unicenter CA-Jobtrac)

Unicenter CA-Scheduler Job Management (Unicenter CA-Scheduler)

Unicenter Desktop and Server Management (Unicenter DSM)

Unicenter Event Management

Unicenter Management Command Center (Unicenter MCC)

Unicenter Management Portal

Unicenter Network and Systems Management (Unicenter NSM)

Unicenter Service Desk

Unicenter Universal Job Management Agent (UUJMA)

Unicenter Workload Control Center (Unicenter WCC)

Online and telephone contact information for technical assistance and

Information about user communities and forums

Product and documentation downloads

CA Support policies and guidelines

Other helpful resources appropriate for your product

Operating Environment Conventions ...................................................................................... 16

Security in Unicenter AutoSys JM .......................................................................................... 37

eTrust Embedded Identity and Access Management ................................................................. 44

Chapter 3: Job Definitions

Job Attributes ..................................................................................................................... 75

Chapter 4: Job Types, Structure, and States

Introducing Jobs ................................................................................................................. 85

Starting Conditions and Boxes ......................................................................................... 90

Chapter 5: Box Job Logic

Basic Box Concepts ............................................................................................................ 119

Chapter 6: Defining Jobs Using JIL

JIL Syntax Rules ................................................................................................................ 142

Chapter 7: Binary Large Object Definitions

Binary Large Objects .......................................................................................................... 170

Generate Blob Reports Using Autorep.................................................................................... 180

Real Machines ................................................................................................................... 183

Chapter 9: Monitoring and Reporting Jobs

Monitors and Reports .......................................................................................................... 207

Run a Report or Monitor ......................................................................................................216

Chapter 10: Maintaining the Scheduler

Overview of Scheduler Maintenance ...................................................................................... 217

Chapter 11: Maintaining the Agent

Overview of Agent Maintenance ........................................................................................... 235

Chapter 12: Maintaining the Event Server

Overview of Event Server Maintenance.................................................................................. 240

Configure the Scheduler Heartbeat Interval ...................................................................... 260

Chapter 13: Configuring Unicenter AutoSys JM

Configuration File ............................................................................................................... 266

ISDBGACTIV ParameterSet Run Time Trace Level ........................................................... 290

Chapter 14: Dynamic Workload Placement

The CA Management Database and Unicenter DSM ................................................................. 296

Chapter 15: Troubleshooting

Chapter 16: Unicenter Integration

Integrating Event Management ............................................................................................ 341

Appendix A: Cross-Platform Scheduling Considerations

Integrating Cross-Platform Scheduling .................................................................................. 356

Appendix B: Legacy Agent Considerations

How Jobs Are Run On Legacy Agent Computers ................................................................ 384

Appendix C: General Debugging

ISDBGACTIV ..................................................................................................................... 385

Appendix D: Message Port and SSL Configuration