Unicenter AutoSys Job

 

Management for UNIX

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

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

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

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

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

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

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

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

 2003 Computer Associates International, Inc.

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

Chapter 1: Introduction to Unicenter AutoSys Job

Management
Assumptions ................................................................................. 1–1
Basics ........................................................................................ 1–2
System Components .......................................................................... 1–3
Event Server .............................................................................. 1–4
Event Processor ........................................................................... 1–5
Remote Agent ............................................................................ 1–5
Example Scenario on UNIX ................................................................ 1–6
Explanation ........................................................................... 1–7
Interface Components ..................................................................... 1–8
Remote Command Service ............................................................. 1–8
Machines .................................................................................... 1–9
Instance ..................................................................................... 1–10
Environment ................................................................................ 1–10
Environment Variables ................................................................... 1–11

Configuration Parameters................................................................. 1–12

/etc/auto.profile File ..................................................................... 1–12
Database Information .................................................................... 1–12

Sybase .............................................................................. 1–13

Oracle ............................................................................... 1–13

Directory Structure .......................................................................... 1–14

Connecting to the Database ................................................................... 1–15

Changes to System Files and Directories ....................................................... 1–17

Multiple Instances ........................................................................... 1–18

Running Multiple Instances ............................................................... 1–19

Running Cross-Instance Job Dependencies ..................................................... 1–20

Contents iii
 Specifying Cross-Instance Job Dependencies ............................................... 1–21
Event Processors and Cross-Dependencies ................................................. 1–22
Event Servers and Cross-Dependencies .................................................... 1–22
High-Availability Options.................................................................... 1–23
Dual Event Servers ...................................................................... 1–23
Running with Dual-Event Servers ..................................................... 1–25
Shadow Event Processor ................................................................. 1–25
Running with a Shadow Event Processor ............................................... 1–27
Related Publications ......................................................................... 1–28

Chapter 2: Preparing for Installation

Meeting System Requirements ..................................................................2–1
Memory ..................................................................................2–1
Disk Space ................................................................................2–1
Oracle Requirements .......................................................................2–1
Sybase Requirements ......................................................................2–1

Adaptive Server Version 12.0 ...........................................................2–2

Database Size Requirements ................................................................2–4

Selecting Components .........................................................................2–4

Remote Command Service .....................................................................2–5

Java Based Listener ........................................................................2–6

Listener Compatibility .....................................................................2–6

Identifying Machines ..........................................................................2–7

Server Machines ...........................................................................2–7
Client Machines ...........................................................................2–7
User and Host Names for eTrust Access Control ..............................................2–8
Determining the Policy Manager User Name .................................................2–9
Determining a PMDB or Policy Manager Host Name........................................ 2–10
Gathering Installation Information ............................................................ 2–12
Wizard Setup ........................................................................... 2–12
Unicenter AutoSys JM Server ......................................................... 2–12
Unicenter AutoSys JM Client.......................................................... 2–12
Unicenter AutoSys JM Agent Only .................................................... 2–12
eTrust Server Information ............................................................ 2–12

iv Installation Guide
 eTrust Client Information ............................................................. 2–13
Unicenter CCI information ............................................................ 2–13
Remote Command Service Information ................................................. 2–13
auto_install Setup ........................................................................ 2–14
System Files Location ................................................................. 2–14
Monitor Type ........................................................................ 2–14
Owner .............................................................................. 2–14

Instance Information ..................................................................... 2–15

Path Name to AUTOUSER ............................................................ 2–15

Primary Event Server Name ........................................................... 2–15
Primary Event Server Host (Sybase) .................................................... 2–15
Primary Database Name (Sybase) ...................................................... 2–15
SA User (Sybase) ..................................................................... 2–15
SA Password (Sybase) ................................................................ 2–16

Bundled Sybase ...................................................................... 2–16

Unbundled Sybase ................................................................... 2–16

Primary Event Server TNS Alias (Oracle) ............................................... 2–16

Location of tnsnames.ora File (Oracle) .................................................. 2–16
Data Tablespace Name (Oracle) ........................................................ 2–17
Index Tablespace Name (Oracle) ....................................................... 2–17
Temporary Tablespace Name (Oracle) .................................................. 2–17
DBA User Name (Oracle) ............................................................. 2–17

DBA Password (Oracle) ............................................................... 2–17

Oracle Database Configuration ........................................................ 2–17

auto_remote (Remote Agent) Directory Path ............................................ 2–18

inetd File Location.................................................................... 2–18
Remote Agent Service Name .......................................................... 2–18

Remote Agent Port ................................................................... 2–18

Using the Installation Checklists .............................................................. 2–19

Wizard Setup Checklist for Unicenter AutoSys JM Server .................................... 2–19

Wizard Setup Checklist for Unicenter AutoSys JM Client .................................... 2–20

Server Checklist.......................................................................... 2–21

Client Checklist .......................................................................... 2–24

Contents v
Chapter 3: Preparing the Server for Installation
Configuring the Server.........................................................................3–1
Log On to the Server .......................................................................3–1
Installation Directory ......................................................................3–2

Create the AutoSys Owner .................................................................3–2

NIS or NIS+ Only: Configure Internet Demon Services ........................................3–3

Configuring for Bundled Sybase ................................................................3–5
Configuring the Operating System ..........................................................3–5
Tru64 .................................................................................3–5
HP-UX................................................................................3–6
IBM AIX ..............................................................................3–7
Solaris 2.x .............................................................................3–8
Configuring an Existing Unbundled Sybase Database .............................................3–8
Configuring an Existing Oracle Database ...................................................... 3–11

Chapter 4: Server Installation for Sybase

Before You Begin ..............................................................................4–1
Server Installation .............................................................................4–1
Using the Setup Wizard to Extract Unicenter AutoSys JM from the Media .......................4–3
Running the Installation Script .................................................................4–4

Server Installation Scripts ..................................................................4–5

Bundled Sybase ...........................................................................4–6

Unbundled Sybase.........................................................................4–6
Remote Agent Information .............................................................4–6

Rerunning the Installation ..................................................................4–7

Preparing the Installation ......................................................................4–7

Time Zone Setting .........................................................................4–8

Set Up the Environment ....................................................................4–8
Bundled Sybase Only: Start the Database ....................................................4–9

Start the Event Processor ................................................................. 4–10

Configuring the Installation .................................................................. 4–11
eTrust Access Control .................................................................... 4–11
Define the Exec and Edit Superusers ...................................................... 4–11
Verify Remote Agent and Database Accessibility ........................................... 4–12

vi Installation Guide
 Internet Demon ...................................................................... 4–13
Remote Agent Verification ............................................................ 4–13

Database Connection Verification ...................................................... 4–14

Install the License Keys ................................................................... 4–14
Set up Autotrack ......................................................................... 4–14
Testing the Installation ....................................................................... 4–16
Create a Test Job ......................................................................... 4–16
Verify the Test Job .................................................................... 4–18
Verify the Environment and Configuration ................................................. 4–18

Chapter 5: Client Installation for Sybase

Client Installation ............................................................................. 5–2
Preparing the Client Machine .................................................................. 5–4
NIS or NIS+ Only: Configure the Internet Demon Services .................................... 5–4
Loading the Software on the Client Machine..................................................... 5–5
Run the Installation Script ..................................................................... 5–6
Client Installation Scripts .................................................................. 5–6
Bundled Sybase ....................................................................... 5–7
Unbundled Sybase .................................................................... 5–7
Remote Agent Installation ................................................................. 5–7
Remote Agent Verification ..................................................................... 5–8
Low-Level Installation Procedures.............................................................. 5–9
Internet Demon Services ................................................................... 5–9
Set Up Services........................................................................ 5–9
Sybase Interfaces ......................................................................... 5–10
Profile Script ............................................................................ 5–11

Executables .............................................................................. 5–11

User Interface Screens .................................................................... 5–12
Sun Workstations .................................................................... 5–13

Contents vii
Chapter 6: Server Installation for Oracle
Before You Begin ..............................................................................6–1
Server Installation .............................................................................6–2
Using the Setup Wizard to Extract Unicenter AutoSys JM from the Media .......................6–4
Oracle Setup Confirmation Utility (recon) .......................................................6–5

Syntax ....................................................................................6–6
Example ..................................................................................6–6
Running the Install Script ......................................................................6–8
Sample Server Installation Script ............................................................6–9
Remote Agent Information .............................................................6–9

Rerunning the Installation ................................................................ 6–10

Preparing the Installation .................................................................... 6–10
Time Zone Setting ....................................................................... 6–11
Set Up the Environment .................................................................. 6–11
Bundled Sybase Only: Start the Database .................................................. 6–12
Start the Event Processor ................................................................. 6–13
Configuring the Installation .................................................................. 6–14
eTrust Access Control .................................................................... 6–14
Define the Exec and Edit Superusers ...................................................... 6–14
Verify Remote Agent and Database Accessibility ........................................... 6–15
Internet Demon ...................................................................... 6–16
Remote Agent Verification ............................................................ 6–16
Database Connection Verification ..................................................... 6–17
Install the License Keys .................................................................. 6–17
Set up Autotrack ........................................................................ 6–17
Testing the Installation ....................................................................... 6–19
Create a Test Job......................................................................... 6–19
Verify the Test Job ................................................................... 6–21
Verify the Environment and Configuration................................................. 6–21

viii Installation Guide

Chapter 7: Client Installation for Oracle
Client Installation ............................................................................. 7–2
Loading the Software On the Client Machine .................................................... 7–4
Run the Install Script .......................................................................... 7–5
Client Installation Script ................................................................... 7–6
Remote Agent Installation ................................................................. 7–7
Remote Agent Verification ..................................................................... 7–7
Low-Level Installation Procedures.............................................................. 7–9
Internet Demon Services ................................................................... 7–9
Set Up Services........................................................................ 7–9
Profile Script ............................................................................ 7–10

Executables .............................................................................. 7–11

Oracle Environment Settings .............................................................. 7–11
User Interface Screens .................................................................... 7–12
Sun Workstations .................................................................... 7–13

Chapter 8: Advanced Configurations

The Configuration File ........................................................................ 8–1
Remote Command Service ..................................................................... 8–2
Starting and Stopping ..................................................................... 8–3
Logging .................................................................................. 8–4
Debugging ............................................................................... 8–4
Installing Dual-Event Servers .................................................................. 8–5
Notes on Installing Dual-Event Servers...................................................... 8–5
Overview of Dual-Server Installation ....................................................... 8–6
Copying Bundled Sybase .................................................................. 8–6
Event Servers on the Same Operating System ............................................ 8–7
Event Servers on Different Operating Systems ........................................... 8–8
Installing Unbundled Sybase ............................................................... 8–9
Installing Oracle ......................................................................... 8–11

Configuring for Dual-Event Servers ........................................................ 8–13

Configuring Sybase................................................................... 8–13
Configuring Oracle ................................................................... 8–17
Synchronizing the Event Servers........................................................... 8–19

Contents ix
 Stop the Event Processor ............................................................. 8–19
Run the autobcp Script ............................................................... 8–19
Start the Event Processor ............................................................. 8–21
Installing a Shadow Event Processor .......................................................... 8–23
Notes on Installing a Shadow Event Processor .............................................. 8–23
Installation Steps ........................................................................ 8–24
Restoring the Primary Event Processor .................................................... 8–25
Installing Multiple Instances.................................................................. 8–26
Configuring Multiple Instances Across Platforms ........................................... 8–26
Determining Instance Configuration Settings ........................................... 8–28
Configuring a UNIX Remote Agent for Multiple Instances ............................... 8–29
Configuring Cross-Instance Job Dependencies .............................................. 8–30
Tips on Creating the config.EXTERNAL File............................................ 8–31

Appendix A: Introducing CAICCI

Installing CAICCI ............................................................................ A–1
Configuring CAICCI ......................................................................... A–2

caiccid.prf ............................................................................... A–2

Node-Specific Path Name ............................................................. A–2

CAICCI Demons ...................................................................... A–3

Shared Memory for RVTs .............................................................. A–3
Customizing ......................................................................... A–5

ccirmtd.prf ............................................................................... A–5

Node-Specific Path Name ............................................................. A–6

cciclnd.prf ............................................................................... A–7

Node-Specific Path Name ............................................................. A–7

CAICCI Environment Variables ............................................................... A–8

CAI_CCI_DEBUG ........................................................................ A–8

CAI_CCI_LOG ........................................................................... A–8
CAI_CCI_CONFIG ....................................................................... A–9

CAI_CCI_SHMMIN ...................................................................... A–9

CAI_CCI_PORT1 ........................................................................ A–10

CCI_SELECT_TIME ..................................................................... A–10

Starting and Stopping CAICCI................................................................ A–11

x Installation Guide
Appendix B: Platform Notes
DG/UX: TZ Variable Setting ................................................................... B–1
IBM AIX: GUI Display ........................................................................ B–1

Sun Solaris: GUI Display ...................................................................... B–1

Appendix C: Removing Unicenter AutoSys JM 4.5

Before You Remove ........................................................................... C–1
Removing .................................................................................... C–2
eTrust AC ................................................................................ C–3
Unicenter CCI ............................................................................ C–3

Contents xi
 Introduction to Unicenter AutoSys
Chapter

1 Job Management

Welcome to the world of Unicenter® AutoSys® Job Management (Unicenter

AutoSys JM), the scheduling and operations automation software for distributed
computing environments.

This guide provides an overview of Unicenter AutoSys JM and describes how to

install, how to configure components, databases, high availability options,
entering license keys and advanced configurations.

Assumptions
This guide is for system administrators who are responsible for upgrading and
installing Unicenter AutoSys JM as well as configuring the servers and clients
and entering license keys. It assumes familiarity with the UNIX operating system
and with the database server you will be using.

Note: The Unicenter AutoSys JM installation will not let you continue unless
you are running as root on the machine in which you are trying to install

Introduction to Unicenter AutoSys Job Management 1–1

Basics

Basics
Unicenter AutoSys JM is an automated job control system for scheduling,
monitoring, and reporting. These jobs can reside on any configured machine that
is attached to a network.

A job is any single command, executable, script, or Windows NT batch file. Each
job definition contains a variety of qualifying attributes, including the conditions
specifying when and where a job should be run.

As with most control systems, many ways exist to correctly define and
implement jobs. It is likely the way you utilize Unicenter AutoSys JM to address
your distributed computing needs will evolve over time. As you become more
familiar with both the features of Unicenter AutoSys JM and the characteristics
of your own jobs, you will also refine your use of Unicenter AutoSys JM.

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

This chapter provides an overview of Unicenter AutoSys JM, its system

architecture, environment, and advanced configurations.

1–2 Installation Guide

 System Components

System Components
The main Unicenter AutoSys JM system components are as follows:

■ Event Server (AutoSys database)

■ Event Processor

■ Remote Agent

In addition, Unicenter AutoSys JM provides utilities to help you define, run, and
maintain instances and jobs. The included utilities are platform-specific;
however, all platforms include the graphical user interface (GUI) and Job
Information Language (JIL). Both the GUI and JIL enable you to define, manage,
monitor, and report on jobs.

The following figure illustrates the Unicenter AutoSys JM system components in

a basic configuration. In addition, this figure illustrates the communication paths
between the components.

AutoSys Server UNIX Client

(UNIX or NT)
Remote
Agent
Event Processor
Unix Job

NT Client

Remote
Agent
Event Server
(database)
NT Job

Introduction to Unicenter AutoSys Job Management 1–3

System Components

Event Server

The event server, or database, is the data repository for all system information
and events as well as all job, monitor, and report definitions. Event server refers
to the database where all the information, events, and job definitions are stored.

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

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

Note: The database refers to the specific server instance and the “autosys”
database for that instance. Some utilities, such as isql (Sybase), lets you specify a
particular server and database, and this guide will use the more precise terms of
data server and database in those cases.

You can configure Unicenter AutoSys JM to run using two databases, or dual-
event servers. This feature provides complete redundancy. Therefore, if you lose
one event server due to hardware, software, or network problems, operations
can continue on the second event server without loss of information or
functionality. For more information, see the topic Dual-Event Servers in this
chapter.

1–4 Installation Guide

 System Components

Event Processor

The event processor is the heart of Unicenter AutoSys JM; it interprets and
processes all the events it reads from the database. Sometimes called the
event_demon, the event processor is the program, running either as a UNIX
process or as a Windows NT service, which actually runs Unicenter AutoSys JM.
It schedules and starts jobs.

After you start the event processor, the event processor continually scans the
database for events to be processed. When the event processor finds one, it
checks whether the event satisfies the starting conditions for any job in the
database. Based on this information, the event processor first determines what
actions to take, then instructs the appropriate remote agent process to perform
the actions. These actions might be the starting or stopping of jobs, checking for
resources, monitoring existing jobs, or initiating corrective procedures.

You can set up a second event processor, called the shadow event processor. If
the primary event processor fails for some reason, the shadow event processor
will take over the responsibility of interpreting and processing events. For more
information, see the topic Shadow Event Processor in this chapter.

Remote Agent

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

event processor to perform a specific task on a remote, or client, machine. On a
Windows NT machine, the remote agent is a Windows NT service running on a
client machine that is directed by the event processor to perform specific tasks.

The remote agent starts the command specified for a given job, sends running
and completion information about a task to the event server, and then exits. If
the remote agent is unable to transfer the information, it waits and tries again
until it can successfully communicate with the database.

Introduction to Unicenter AutoSys Job Management 1–5

System Components

Example Scenario on UNIX

The example scenario in the following figure and the numbered explanations
that follow it illustrate the interactions between the event server, the event
processor, and remote agents.

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

WorkStation_2, at the start date and time specified in the job definition:
rm /tmp/mystuff/*

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

PROCESS PROCESS
PROCESS

Event Processor Remote Agent

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

• Sends Exit event back to

Event Server

PROCESS
5 WorkStation_2
PROCESS Command

Event Server • Runs UNIX Command

4 'rm/tmp/mystuff/*' or
• Events Windows NT
Command 'del C:\
• Job Definitions tmp\*.*'
Local Area
• Completes execution
Network
and exits with status

Note: In this example, the three primary components are shown running on
different machines. For UNIX, the event processor and the event server typically
run on the same machine.

1–6 Installation Guide

 System Components

Explanation

The following steps explain the interactions in the example scenario:

1. From the event server, the event processor reads a new event, which is a
STARTJOB event with a start time condition that has been met. Then the
event processor reads the appropriate job definition from the database and,
based on that definition, determines what action to take. In the example, it
runs the rm /tmp/mystuff/* command on WorkStation_2.

2. The event processor communicates with the remote agent on WorkStation_2.

As soon as the remote agent receives the instructions from the event
processor, the connection between the two processes is dropped. After the
connection is dropped, the job will run to completion, even if the event
processor stops running.

3. The remote agent performs resource checks, such as ensuring that the
minimum specified number of processes are available, then “forks” a child
process that will actually run the specified command.

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

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

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

Note: The remote agent is started on the client machine by the event processor
talking to the internet demon, inetd, on the client machine. For this to happen,
inetd must also be running. However, because UNIX is responsible for starting
this demon, it is not considered a process.

Introduction to Unicenter AutoSys Job Management 1–7

System Components

Interface Components

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

Remote Command Service

The Unicenter AutoSys Remote Command Service (RCS) is used to handle

various requests from the Unicenter AutoSys JM Web Interface. RCS has the
following features:

■ Handles EPLOG requests

■ Handles JOBLOG requests

■ Handles CHECKUSER requests

■ Handles JIL requests

■ Multiple Instances

EPLOG
The Unicenter AutoSys JM RCS will send a portion of a Unicenter AutoSys
eplog for a specified instance to the Unicenter AutoSys Web Interface. This
request is processed when a user selects the AutoSys Log option from
Reports Tab of the Unicenter AutoSys Web Interface. The RCS retrieves a
predefined number of lines from the end of the Unicenter AutoSys eplog.

JOBLOG
The JOBLOG request sends the standard output file or standard error file for
a given job to the Unicenter AutoSys JM Web Interface.

CHECKUSER
The CHECKUSER request is used during the Unicenter AutoSys JM Web
Interface Administration AutoSys EDIT Super Sign-on call. The Unicenter
AutoSys JM Web Interface verifies the user credentials by issuing a request
to the RCS to check whether user has the Super Edit privilege.

1–8 Installation Guide

 Machines

JIL
The JIL request allows a user to add, remove, or edit a Unicenter AutoSys JM
job by using the Unicenter AutoSys JM Web Interface. When a user edits a
job from the Unicenter AutoSys JM Web Interface Job Management Tab, the
RCS receives the updated job information and uses the JIL program to
update the job in the Event Server.

Multiple Instance Support

One RCS per Unicenter AutoSys machine is needed to handle Unicenter
AutoSys JM Web Interface requests for all the Unicenter AutoSys JM
instances on that machine.

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

■ Server machine

The server is the machine on which the event processor or the event server
(database) reside. In a basic UNIX configuration, both the event processor
and the event server reside on the same machine. In a basic Windows NT
configuration, we recommend that the event processor and the event server
reside on separate machines.

■ Client machine

The client is the machine on which the remote agent software resides, and
where jobs run. A remote agent must be installed on the machine with the
event processor, and it can also be installed on separate physical client
machines.

Introduction to Unicenter AutoSys Job Management 1–9

Instance

Instance
An instance is one licensed version of Unicenter AutoSys JM software running as
a server with one or more clients, on a single machine or on multiple machines.

An instance is defined by the following:

■ An instance ID, an uppercase three-alphanumeric identifier defined by the

AUTOSERV environment variable. You set the instance ID during
installation and cannot change it.

■ The $AUTOUSER/config.$AUTOSERV configuration file.

■ At least one event server.

■ At least one event processor.

You may want to install multiple instances, for example, one instance for
production and another for development. Each instance operates independently
of other AutoSys instances. For information about using multiple instances, see
Multiple Instances in this chapter.

Environment
Access to Unicenter AutoSys JM software and the event server is controlled by
environment variables and the configuration parameters, which must be set for
the event processor and the remote agents to communicate and the commands to
execute. The installation process creates files that are sourced when the user logs
on.

All processes must know the following:

■ Which databases to connect to for reading events and definitions.

■ Which directories to access for write output files.

1–10 Installation Guide

 Environment

Environment Variables

In order for Unicenter AutoSys JM to run properly and to determine which

instance to connect to, it consults the following listed environment variables:

AUTOSYS
Specifies the full path to the Unicenter AutoSys JM software directory.

AUTOUSER
Specifies the directory containing user configuration files, event processor
output files, archive output files generated during database maintenance,
and sound files (for platforms supporting audio functionality).

AUTOSERV
Specifies the unique, capitalized three-letter name of an instance.

DISPLAY
Referenced to run the AutoSys GUIs.

To communicate with the Sybase or Oracle database, Unicenter AutoSys JM also

relies on the environment variables described in the topic Database Information
in this chapter.

If only one instance is running, the above variables can be set when a user logs
on by including their definitions in either the .profile or .cshrc file for each user
that accesses Unicenter AutoSys JM.

The installation script generates files that are designed to be sourced by a user
wanting to access Unicenter AutoSys JM. These files can be sourced from a
.profile or .cshrc file. They are found in the $AUTOUSER directory and are listed
following:

■ autosys.sh.hostname—for Bourne shell users.

■ autosys.csh.hostname—for C shell users.

■ autosys.ksh.hostname—for Korn shell users.

These files have the host name appended to the end of their file names so that
client and server environment files cannot be easily confused.

Optionally, frequently used variations for the sendevent, autorep, and eventor
commands can be aliased in the files to be sourced.

Introduction to Unicenter AutoSys Job Management 1–11

Environment

Configuration Parameters

The environment is also defined by configuration parameters. The configuration

parameters include information about the remote agents, event servers, and
event processor as well as many tunable parameters that control the behavior of
Unicenter AutoSys JM.

Some configuration parameters are specified when you install Unicenter

AutoSys JM and the rest have default settings. You do not have to modify these
settings if the installation specifications are acceptable.

On a UNIX machine, the configuration parameters are specified in the

configuration file, $AUTOUSER/config.$AUTOSERV. On a Windows machine,
the parameters are specified using the Unicenter AutoSys JM Administrator.

Note: Properly setting the required environment variables in every user’s

environment and configuring Unicenter AutoSys JM correctly will help to
prevent potential problems. The most common problems are that Unicenter
AutoSys JM cannot determine which event server to connect to and it cannot
locate various executables or files.

For information on the configuration file, see the chapter “Configuring” in the
Unicenter Job Management AutoSys for UNIX User Guide. For information on
the Unicenter AutoSys Administrator, see the chapter “Unicenter AutoSys
Administrator” in the Unicenter AutoSys Job Management for Windows User
Guide.

/etc/auto.profile File

On a UNIX machine, the remote agent environment is controlled through special

descriptors located in the /etc/auto.profile file, located on the remote agent
(client) machine.

Database Information

Unicenter AutoSys JM uses database-specific environment variables and

configuration settings to locate and connect to the database (event server).

For information on how Unicenter AutoSys JM uses the database-specific values

to connect to a database, see the topic Connecting to the Database in this chapter.

1–12 Installation Guide

 Environment

Sybase

If you are using a Sybase data server, whether bundled with Unicenter AutoSys
JM or not, the following environment variables are used:

DSQUERY
Defines the name of the Sybase data server.

SYBASE
Specifies the complete path to the Sybase software directory.

The SYBASE environment variable must be set before you run the installation
script. The Sybase software directory contains the Sybase configuration file,
which on UNIX is the interfaces file and on Windows NT is the SQL.INI file.
Unicenter AutoSys JM uses the Sybase configuration file to look up database
information. It is by which the network is navigated to find the Sybase data
server.

Oracle

If you are using an Oracle database, the ORACLE_HOME environment variable

must be defined. In addition, SQL*Net V2 must be installed and configured
correctly on all client machines. In particular, the TNS alias name of the data
server that Unicenter AutoSys JM will use must be configured, and an SQL*Net
V2 connect descriptor must be in the TNS names configuration file.

The tnsnames.ora file is used by Unicenter AutoSys JM to look up the database

host machine and port number based on its name. It is the means by which the
network is navigated to find the Oracle data server. This file specifies where the
Oracle server is located. On UNIX, the tnsnames.ora file is usually in the /etc or
$TNS_ADMIN directory. On Windows, this file is usually in the
\ORANT\NETWORK\ADMIN directory.

Introduction to Unicenter AutoSys Job Management 1–13

Directory Structure

Directory Structure
The following figure shows the default directory structure for Unicenter AutoSys
JM . This figure refers to the installation directory as AUTOTREE. When this
default structure is used, all the prompts displayed by the install scripts will
match exactly what you see on the screen. The autouser directory can be placed
elsewhere. The new directories are pointed to by the environment variables
AUTOSYS and AUTOUSER.

/usr/vendor/autotree

(bundled DB only)
$AUTOUSER $AUTOSYS $SYBASE
autouser sadb
interfaces file
Configuration Files:
config.$AUTOSERV
autosys.sh.host
autosys.csh.host ASE-12-0 DATA OCS-12-0
etc.

bin install lib bin include lib

archive sounds
out

test
bin code dbobj doc sounds snmp

install

data bin jil demo

1–14 Installation Guide

 Connecting to the Database

Connecting to the Database

All information is kept in a relational database (RDBMS) called the event server,
which is configured for Unicenter AutoSys JM. Access to Unicenter AutoSys JM
requires a connection to this database. That is, you must connect to the database
to add, modify, control, report on, or monitor jobs, and to change certain
configuration settings.

The configuration parameters and the Unicenter AutoSys JM and database

environment variables (described previously) tell the software which databases
to connect to for a particular instance. The following figures illustrate how this is
accomplished.

Note: These examples use the default values for the environment variables, and
when appropriate, they show both the UNIX and Windows environments.

The following figure illustrates how this is accomplished when connecting to a

Sybase database:

Connecting to a Sybase Database

Reads the $AUTOUSER/config.$AUTOSERV file or the
AutoSys Administrator settings in the Windows NT Registry
d and locates the Event Server and database configuration
setting (for example: EventServer=AUTOSYSDB:autosys).

c Access AutoSys e Searches for AUTOSYSDB in the interfaces or SQL.INI file.

Uses hostname and port number entry to connect to Sybase

f database
6234).
(for example: AUTOSYSDB autosys_server

AutoSys Server
autosys_server
RDBMS

Introduction to Unicenter AutoSys Job Management 1–15

Connecting to the Database

The following figure shows the scenario for connecting to an Oracle database.

Connecting to an Oracle Database

Reads the $AUTOUSER/config.$AUTOSERV file or the
AutoSys Administrator settings in the Windows NT Registry
d and locates the Event Server and database configuration
setting (for example: EventServer=MYORACLEDB).

Searches for the TNS aliasMYORACLEDB in the

c Access AutoSys e tnsnames.ora file.

f Uses network configuation information to connect to

SQL*Net V2 and the Oracle database.

AutoSys Server
MYORACLEDB
RDBMS

1–16 Installation Guide

 Changes to System Files and Directories

Changes to System Files and Directories

The changes listed are made to existing system files and directories during the
course of the installation. Unless noted, these changes are made on all installed
machines:

■ A line is added to the internet demon (inetd, usually found in

/etc/inetd.conf) so that it points to the remote agents.

■ The internet demon services file (usually /etc/services) is changed. If your

machine is running NIS or NIS+, you must edit the file, remake the map, and
push it out to all clients.

■ The file named auto.profile is added to the /etc directory.

■ The files named Autosc, Autocons, and Autocal are added to the local app-
defaults directory. This directory is usually one of the following:
/usr/lib/X11/app-defaults
/usr/openwin/lib/app-defaults

■ The file named XKeysymDB is added to the /usr/lib/X11 directory, if it is

not already there. If the X11 directory does not exist, it is created.

■ Because of certain Sybase requirements, if you are installing a bundled

Sybase database, the UNIX kernel of the server machine must be
reconfigured manually for certain operating systems. This must be done
before the database is started. These changes are explained in the chapter
“Preparing the Server for Installation,” in the Unicenter AutoSys Job
Management for UNIX Installation Guide.

Introduction to Unicenter AutoSys Job Management 1–17

Multiple Instances

Multiple Instances
Multiple instances of Unicenter AutoSys JM can run on the same machine and
can schedule jobs on the same machines without interfering or affecting the other
instances. Each instance uses its own event processor and event server and
operates independently of other instances; however, you can configure instances
to run with cross-instance job dependencies.

For information on installing multiple instances and configuring to run with

cross-instance job dependencies, see the topic Running Cross-Instance Job
Dependencies in this chapter.

Note: If you elect to install multiple instances of Unicenter AutoSys JM on one

machine where the first instance of Unicenter AutoSys JM has been configured to
use eTrust Access Control (eTrust AC) it is recommended that all job processing
be put on hold for that instance or that instance be shutdown completely before
proceeding with any new installations of Unicenter AutoSys JM on this machine.
This is recommended since the installation program will stop and restart eTrust
ACl on several occasions during the post installation process if you elect to
configure the new instance with eTrust AC. This stopping and starting of eTrust
AC may impact any running Unicenter AutoSys JM instances currently using
eTrust AC.

1–18 Installation Guide

 Multiple Instances

Running Multiple Instances

You can run multiple instances of Unicenter AutoSys JM on the same network at
the same time. Some of the reasons you may want to run multiple instances are
listed following:

■ Your processing volume is large, and you want to distribute the load down
to the departmental level.

■ You want each department in your company to be insulated from what

happens in other departments.

■ You want to separate or test your development and production

environments.

Each instance must have its own event processor specified in the configuration
file and it must have its own instance-specific event servers installed.

Event processors from multiple instances can access the same client machines to
start jobs. To enable this, you must install a remote agent on the client machine
for each instance that will run jobs on that machine.

Different instances can run from the same executables and can have the same
values for the AUTOSYS and AUTOUSER variables, both on the event processor
machine and on client machines. However, each instance must have a unique
value for the AUTOSERV variable and each instance must have its own unique
remote agent port number. You can have unique event server port numbers for
each instance, but this is not required.

Note: The use of multiple databases is completely independent of multiple

instances. You can have multiple instances, each using dual event servers.

The following figure shows two instances of Unicenter AutoSys JM, each with a
single event server. Both instances can send jobs to the same client machine as
long as both instances have a remote agent installed or configured on that client
machine.

Introduction to Unicenter AutoSys Job Management 1–19

Running Cross-Instance Job Dependencies

One Instance of AutoSys One Instance of AutoSys

ACE PRD

OS File OS File
config.ACE File config.PRD File
or NT Registry Settings or NT Registry Settings

Event Event
Server Server
Event Event
Processor Processor

Client
Machine

Remote Agent for ACE instance

Remote Agent for PRD instance

Note: If you want to install Unicenter AutoSys JM on both UNIX and Windows,
and you want to enable cross-platform job dependencies, then you must supply
different remote agent port numbers for each instance that you install. On
Windows, the remote agent port number must be unique, so if you are running
across UNIX and Windows platforms, you must configure your UNIX
components with the same remote agent port numbers that you are using on the
Windows installations.

For information about installing multiple instances, see the chapter “Advanced
Configurations,” in this guide.

Running Cross-Instance Job Dependencies

You can implement cross-instance job dependencies among different instances.

1–20 Installation Guide

 Running Cross-Instance Job Dependencies

Specifying Cross-Instance Job Dependencies

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 may appear as 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-alphanumeric ID of PRD.

If the dependency specification does not include a caret (^) and a different
instance ID, the current instance will be used by default.

Each time cross-instance job dependency is encountered, Unicenter AutoSys JM

sends an EXTERNAL_DEPENDENCY event from the requesting instance. If the
target instance cannot be reached, Unicenter AutoSys JM issues an
INSTANCE_UNAVAILABLE alarm.

The following figure shows two instances, each with a single event server,
sharing cross-instance dependencies.

One Instance of AutoSys One Instance of AutoSys

ACE PRD

Event Event
Server Server
OS File OS File
config.ACE config.PRD File
config.EXTERNAL or NT Registry Settings
Event Event
Processor Processor

condition: success jobB

(jobB^PRD) condition: success
jobE (jobE^ACE)

For more information about defining jobs to run with cross-instance

dependencies, see Cross-Instance Job Dependencies in the chapter “Jobs” of the
Unicenter AutoSys Job Management for UNIX User Guide.

Introduction to Unicenter AutoSys Job Management 1–21

Running Cross-Instance Job Dependencies

Event Processors and Cross-Dependencies

When you implement cross-instance job dependencies, event processors can do

the following:

■ Run on different server machines or on the same server machine.

■ Access the same client machines to start jobs.

■ Send events to other instances.

Note: If the event server of a target instance is down, the event processor will try
to resend events every five minutes until it can reach the other instance’s event
server.

Event Servers and Cross-Dependencies

Each time a job definition with a cross-instance job dependency is submitted to

the event server, the following entries are made in the database:

■ To the ext_job table of the source instance. The entries in this table specify
the status of jobs belonging to other instances in which this instance has
defined job dependencies.

■ To the req_job table of the target instance. The entries in this table specify the
jobs that have a job dependency in a job definition in the source instance.

In both the source instance and target instance tables, jobs are entered using the
job name, a caret symbol (^), and the instance name, like the following:
jobB^PRD

Note: When communicating with event servers, event processors can only
connect to those instances with “like” event servers. That is, instances with
Sybase data servers can only connect with other instances having Sybase data
servers. The same holds true for instances with Oracle and Microsoft SQL Server
databases.

For information about configuring Unicenter AutoSys JM to run with cross-

instance job dependencies, see Configuring for Cross-Instance Job Dependencies
in the chapter “Advanced Configurations,” in this guide.

1–22 Installation Guide

 High-Availability Options

High-Availability Options
Unicenter AutoSys JM provides two high-availability options that lets Unicenter
AutoSys JM keep processing even if an event server or event processor fails due
to hardware or connection problems. These high-availability options are dual-
event servers and a shadow event processor.

You can install and configure the high-availability options at the same time you
install , or you can modify an existing installation to add the high availability
options.

For information on installing high-availability options, see the chapter

“Advanced Configurations,” in this guide.

Dual Event Servers

One way that Unicenter AutoSys JM provides high-availability is by running

two event servers. The two event servers contain identical information, including
job definitions and events, because Unicenter AutoSys JM reads and writes to
both servers simultaneously. Unicenter AutoSys JM also keeps both event
servers synchronized and provides complete recovery when one server becomes
unusable, disabled, or corrupted.

When processing events, the event processor reads from both event servers. If it
detects an event on one server and not the other, it will copy the missing event to
the other server. In this way, a temporary problem in getting events to one of the
servers will not interrupt processing.

In addition, the remote agent sends events and writes to both event servers.

The following figure illustrates a typical configuration running with dual event
servers.

Important! We recommend that the two event servers reside on two different
machines, to prevent a single point of failure.

Introduction to Unicenter AutoSys Job Management 1–23

High-Availability Options

reads
&
writes
Event Event
Server Server
#1 #2
reads
& writes
writes

Event
Processor

MACHINE A MACHINE B

Start
Job
Remote
Agent

Run Job

User
Command

Remote
MACHINE

1–24 Installation Guide

 High-Availability Options

Running with Dual-Event Servers

When running within dual-event server mode, and the event processor detects
an unrecoverable condition on one of the event servers, it automatically rolls
over to single server mode. A rollover results from one of the following
conditions:

■ The connection to the database is lost, and after the configured number of
reconnect attempts, the database remains unconnected.

■ The database has an unrecoverable error, for example, the database is

corrupt or a media failure occurs.

If there was an event server rollover on servers running on UNIX, the event
processor edits the $AUTOUSER/config.$AUTOSERV configuration file, on the
server machine only, to comment out the database that has been taken offline.
The event processor makes this change so that utilities attempting to access the
database will know that Unicenter AutoSys JM is now running in single server
mode.

Do not restart the down event server and run in dual-event server mode. Before
starting the event server, you must make sure that the two event servers are
synchronized.

Note: If Unicenter AutoSys JM is configured to run with dual-event servers, the

event processor will not start unless both databases are available.

For information on event server recovery, and how to synchronize event servers,
see the chapter “Maintaining ” in the Unicenter AutoSys Job Management for
UNIX User Guide.

Shadow Event Processor

Another way that Unicenter AutoSys JM provides high-availability is through

running with a shadow event processor. The shadow event processor is designed
to take over event processing in case there is a failure of the primary event
processor.

The following figure illustrates a typical configuration running with primary

and shadow event processors as well as dual-event servers. The shadow event
processor and dual-event servers are independent features, but you can run
them together. (This configuration is not required.)

Introduction to Unicenter AutoSys Job Management 1–25

High-Availability Options

Important! We recommend that the primary and shadow processors reside on

two different machines, to prevent a single point of failure.

Remote
Agent

.dibs file

Third
MACHINE

reads
&
writes
Event Event
Server Server
#1 #2
reads
& writes
writes

Primary Shadow
Processor Processor
PING

MACHINE A MACHINE B

Start
Job
Remote
Agent

Run Job

User
Command

Client
MACHINE

1–26 Installation Guide

 High-Availability Options

Running with a Shadow Event Processor

The shadow event processor is normally in idle mode, listening for routine pings
from the primary event processor, which indicate all is well. If the shadow event
processor stops receiving this signal, it assumes the primary event processor has
failed.

If the shadow event processor does not receive the signal, it checks the third
machine (defined in the configuration file) for the .dibs file. If it cannot connect
to the third machine, the shadow event processor shuts down. If it can connect
and cannot locate the .dibs file, the shadow event processor creates the file,
attempts to signal the primary event processor to stop, and takes over processing
the events. If the file already exists, it shuts down.

Similarly, if the primary event processor cannot locate and signal the shadow
event processor, the primary processor checks the third machine for the .dibs file
and follows the same procedure as the shadow event processor (described
previously).

If it is necessary at the time of event processor rollover, Unicenter AutoSys JM

will also rollover from dual-server mode to single-server mode. That is, if the
primary event processor and an event server are on the same machine, the event
processor failure could also mean an event server failure. In this situation,
Unicenter AutoSys JM would roll over to the shadow event processor, and to
single server mode.

The shadow event processor is designed primarily for the situation where the
machine on which the primary event processor runs goes down, or the network
on which this processor runs goes down. Particular care is given to ensuring that
both event processors never take over at the same time. To achieve this,
Unicenter AutoSys JM uses the third machine and the existence of the .dibs file
to resolve contentions and to eliminate the case where one processor takes over
because its own network is down.

The shadow event processor is not guaranteed to take over in 100% of the cases
where it theoretically could. For example, in the case of network problems,
Unicenter AutoSys JM may not be able to determine which event processor is the
functional one. In this case, both processors will shut down.

For more information about event processor rollover and recovery, see the
chapter “Maintaining” in the Unicenter AutoSys Job Management for UNIX User
Guide.

Introduction to Unicenter AutoSys Job Management 1–27

Related Publications

Related Publications
In addition to this Installation Guide, the following documentation is provided:

■ Unicenter AutoSys Job Management Release Summary, which provides

important information about this version, read this before proceeding.

■ Unicenter AutoSys Job Management for UNIX Upgrade Instructions, which

describes how to upgrade to the current version of Unicenter AutoSys JM.

■ Unicenter AutoSys Job Management for UNIX User Guide, which describes
how to use Unicenter AutoSys JM to define, run, manage, monitor, and
report on jobs. In addition, it describes how to run and manage the
databases, and it describes security and the configuration file.

■ Unicenter AutoSys Job Management for Windows and UNIX Reference

Guide, which lists the system states and commands, and lists job, machine,
monitor, and report definition parameters.

1–28 Installation Guide

Basics

Basics
Unicenter AutoSys JM is an automated job control system for scheduling,
monitoring, and reporting. These jobs can reside on any configured machine that
is attached to a network.

A job is any single command, executable, script, or Windows NT batch file. Each
job definition contains a variety of qualifying attributes, including the conditions
specifying when and where a job should be run.

As with most control systems, many ways exist to correctly define and
implement jobs. It is likely the way you utilize Unicenter AutoSys JM to address
your distributed computing needs will evolve over time. As you become more
familiar with both the features of Unicenter AutoSys JM and the characteristics
of your own jobs, you will also refine your use of Unicenter AutoSys JM.

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

This chapter provides an overview of Unicenter AutoSys JM, its system

architecture, environment, and advanced configurations.

1–2 Installation Guide

 System Components

System Components
The main Unicenter AutoSys JM system components are as follows:

■ Event Server (AutoSys database)

■ Event Processor

■ Remote Agent

In addition, Unicenter AutoSys JM provides utilities to help you define, run, and
maintain instances and jobs. The included utilities are platform-specific;
however, all platforms include the graphical user interface (GUI) and Job
Information Language (JIL). Both the GUI and JIL enable you to define, manage,
monitor, and report on jobs.

The following figure illustrates the Unicenter AutoSys JM system components in

a basic configuration. In addition, this figure illustrates the communication paths
between the components.

AutoSys Server UNIX Client

(UNIX or NT)
Remote
Agent
Event Processor
Unix Job

NT Client

Remote
Agent
Event Server
(database)
NT Job

Introduction to Unicenter AutoSys Job Management 1–3

System Components

Event Server

The event server, or database, is the data repository for all system information
and events as well as all job, monitor, and report definitions. Event server refers
to the database where all the information, events, and job definitions are stored.

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

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

Note: The database refers to the specific server instance and the “autosys”
database for that instance. Some utilities, such as isql (Sybase), lets you specify a
particular server and database, and this guide will use the more precise terms of
data server and database in those cases.

You can configure Unicenter AutoSys JM to run using two databases, or dual-
event servers. This feature provides complete redundancy. Therefore, if you lose
one event server due to hardware, software, or network problems, operations
can continue on the second event server without loss of information or
functionality. For more information, see the topic Dual-Event Servers in this
chapter.

1–4 Installation Guide

 System Components

Event Processor

The event processor is the heart of Unicenter AutoSys JM; it interprets and
processes all the events it reads from the database. Sometimes called the
event_demon, the event processor is the program, running either as a UNIX
process or as a Windows NT service, which actually runs Unicenter AutoSys JM.
It schedules and starts jobs.

After you start the event processor, the event processor continually scans the
database for events to be processed. When the event processor finds one, it
checks whether the event satisfies the starting conditions for any job in the
database. Based on this information, the event processor first determines what
actions to take, then instructs the appropriate remote agent process to perform
the actions. These actions might be the starting or stopping of jobs, checking for
resources, monitoring existing jobs, or initiating corrective procedures.

You can set up a second event processor, called the shadow event processor. If
the primary event processor fails for some reason, the shadow event processor
will take over the responsibility of interpreting and processing events. For more
information, see the topic Shadow Event Processor in this chapter.

Remote Agent

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

event processor to perform a specific task on a remote, or client, machine. On a
Windows NT machine, the remote agent is a Windows NT service running on a
client machine that is directed by the event processor to perform specific tasks.

The remote agent starts the command specified for a given job, sends running
and completion information about a task to the event server, and then exits. If
the remote agent is unable to transfer the information, it waits and tries again
until it can successfully communicate with the database.

Introduction to Unicenter AutoSys Job Management 1–5

System Components

Example Scenario on UNIX

The example scenario in the following figure and the numbered explanations
that follow it illustrate the interactions between the event server, the event
processor, and remote agents.

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

WorkStation_2, at the start date and time specified in the job definition:
rm /tmp/mystuff/*

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

PROCESS PROCESS
PROCESS

Event Processor Remote Agent

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

• Sends Exit event back to

Event Server

PROCESS
5 WorkStation_2
PROCESS Command

Event Server • Runs UNIX Command

4 'rm/tmp/mystuff/*' or
• Events Windows NT
Command 'del C:\
• Job Definitions tmp\*.*'
Local Area
• Completes execution
Network
and exits with status

Note: In this example, the three primary components are shown running on
different machines. For UNIX, the event processor and the event server typically
run on the same machine.

1–6 Installation Guide

 System Components

Explanation

The following steps explain the interactions in the example scenario:

1. From the event server, the event processor reads a new event, which is a
STARTJOB event with a start time condition that has been met. Then the
event processor reads the appropriate job definition from the database and,
based on that definition, determines what action to take. In the example, it
runs the rm /tmp/mystuff/* command on WorkStation_2.

2. The event processor communicates with the remote agent on WorkStation_2.

As soon as the remote agent receives the instructions from the event
processor, the connection between the two processes is dropped. After the
connection is dropped, the job will run to completion, even if the event
processor stops running.

3. The remote agent performs resource checks, such as ensuring that the
minimum specified number of processes are available, then “forks” a child
process that will actually run the specified command.

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

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

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

Note: The remote agent is started on the client machine by the event processor
talking to the internet demon, inetd, on the client machine. For this to happen,
inetd must also be running. However, because UNIX is responsible for starting
this demon, it is not considered a process.

Introduction to Unicenter AutoSys Job Management 1–7

System Components

Interface Components

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

Remote Command Service

The Unicenter AutoSys Remote Command Service (RCS) is used to handle

various requests from the Unicenter AutoSys JM Web Interface. RCS has the
following features:

■ Handles EPLOG requests

■ Handles JOBLOG requests

■ Handles CHECKUSER requests

■ Handles JIL requests

■ Multiple Instances

EPLOG
The Unicenter AutoSys JM RCS will send a portion of a Unicenter AutoSys
eplog for a specified instance to the Unicenter AutoSys Web Interface. This
request is processed when a user selects the AutoSys Log option from
Reports Tab of the Unicenter AutoSys Web Interface. The RCS retrieves a
predefined number of lines from the end of the Unicenter AutoSys eplog.

JOBLOG
The JOBLOG request sends the standard output file or standard error file for
a given job to the Unicenter AutoSys JM Web Interface.

CHECKUSER
The CHECKUSER request is used during the Unicenter AutoSys JM Web
Interface Administration AutoSys EDIT Super Sign-on call. The Unicenter
AutoSys JM Web Interface verifies the user credentials by issuing a request
to the RCS to check whether user has the Super Edit privilege.

1–8 Installation Guide

 Machines

JIL
The JIL request allows a user to add, remove, or edit a Unicenter AutoSys JM
job by using the Unicenter AutoSys JM Web Interface. When a user edits a
job from the Unicenter AutoSys JM Web Interface Job Management Tab, the
RCS receives the updated job information and uses the JIL program to
update the job in the Event Server.

Multiple Instance Support

One RCS per Unicenter AutoSys machine is needed to handle Unicenter
AutoSys JM Web Interface requests for all the Unicenter AutoSys JM
instances on that machine.

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

■ Server machine

The server is the machine on which the event processor or the event server
(database) reside. In a basic UNIX configuration, both the event processor
and the event server reside on the same machine. In a basic Windows NT
configuration, we recommend that the event processor and the event server
reside on separate machines.

■ Client machine

The client is the machine on which the remote agent software resides, and
where jobs run. A remote agent must be installed on the machine with the
event processor, and it can also be installed on separate physical client
machines.

Introduction to Unicenter AutoSys Job Management 1–9

Instance

Instance
An instance is one licensed version of Unicenter AutoSys JM software running as
a server with one or more clients, on a single machine or on multiple machines.

An instance is defined by the following:

■ An instance ID, an uppercase three-alphanumeric identifier defined by the

AUTOSERV environment variable. You set the instance ID during
installation and cannot change it.

■ The $AUTOUSER/config.$AUTOSERV configuration file.

■ At least one event server.

■ At least one event processor.

You may want to install multiple instances, for example, one instance for
production and another for development. Each instance operates independently
of other AutoSys instances. For information about using multiple instances, see
Multiple Instances in this chapter.

Environment
Access to Unicenter AutoSys JM software and the event server is controlled by
environment variables and the configuration parameters, which must be set for
the event processor and the remote agents to communicate and the commands to
execute. The installation process creates files that are sourced when the user logs
on.

All processes must know the following:

■ Which databases to connect to for reading events and definitions.

■ Which directories to access for write output files.

1–10 Installation Guide

 Environment

Environment Variables

In order for Unicenter AutoSys JM to run properly and to determine which

instance to connect to, it consults the following listed environment variables:

AUTOSYS
Specifies the full path to the Unicenter AutoSys JM software directory.

AUTOUSER
Specifies the directory containing user configuration files, event processor
output files, archive output files generated during database maintenance,
and sound files (for platforms supporting audio functionality).

AUTOSERV
Specifies the unique, capitalized three-letter name of an instance.

DISPLAY
Referenced to run the AutoSys GUIs.

To communicate with the Sybase or Oracle database, Unicenter AutoSys JM also

relies on the environment variables described in the topic Database Information
in this chapter.

If only one instance is running, the above variables can be set when a user logs
on by including their definitions in either the .profile or .cshrc file for each user
that accesses Unicenter AutoSys JM.

The installation script generates files that are designed to be sourced by a user
wanting to access Unicenter AutoSys JM. These files can be sourced from a
.profile or .cshrc file. They are found in the $AUTOUSER directory and are listed
following:

■ autosys.sh.hostname—for Bourne shell users.

■ autosys.csh.hostname—for C shell users.

■ autosys.ksh.hostname—for Korn shell users.

These files have the host name appended to the end of their file names so that
client and server environment files cannot be easily confused.

Optionally, frequently used variations for the sendevent, autorep, and eventor
commands can be aliased in the files to be sourced.

Introduction to Unicenter AutoSys Job Management 1–11

Environment

Configuration Parameters

The environment is also defined by configuration parameters. The configuration

parameters include information about the remote agents, event servers, and
event processor as well as many tunable parameters that control the behavior of
Unicenter AutoSys JM.

Some configuration parameters are specified when you install Unicenter

AutoSys JM and the rest have default settings. You do not have to modify these
settings if the installation specifications are acceptable.

On a UNIX machine, the configuration parameters are specified in the

configuration file, $AUTOUSER/config.$AUTOSERV. On a Windows machine,
the parameters are specified using the Unicenter AutoSys JM Administrator.

Note: Properly setting the required environment variables in every user’s

environment and configuring Unicenter AutoSys JM correctly will help to
prevent potential problems. The most common problems are that Unicenter
AutoSys JM cannot determine which event server to connect to and it cannot
locate various executables or files.

For information on the configuration file, see the chapter “Configuring” in the
Unicenter Job Management AutoSys for UNIX User Guide. For information on
the Unicenter AutoSys Administrator, see the chapter “Unicenter AutoSys
Administrator” in the Unicenter AutoSys Job Management for Windows User
Guide.

/etc/auto.profile File

On a UNIX machine, the remote agent environment is controlled through special

descriptors located in the /etc/auto.profile file, located on the remote agent
(client) machine.

Database Information

Unicenter AutoSys JM uses database-specific environment variables and

configuration settings to locate and connect to the database (event server).

For information on how Unicenter AutoSys JM uses the database-specific values

to connect to a database, see the topic Connecting to the Database in this chapter.

1–12 Installation Guide

 Environment

Sybase

If you are using a Sybase data server, whether bundled with Unicenter AutoSys
JM or not, the following environment variables are used:

DSQUERY
Defines the name of the Sybase data server.

SYBASE
Specifies the complete path to the Sybase software directory.

The SYBASE environment variable must be set before you run the installation
script. The Sybase software directory contains the Sybase configuration file,
which on UNIX is the interfaces file and on Windows NT is the SQL.INI file.
Unicenter AutoSys JM uses the Sybase configuration file to look up database
information. It is by which the network is navigated to find the Sybase data
server.

Oracle

If you are using an Oracle database, the ORACLE_HOME environment variable

must be defined. In addition, SQL*Net V2 must be installed and configured
correctly on all client machines. In particular, the TNS alias name of the data
server that Unicenter AutoSys JM will use must be configured, and an SQL*Net
V2 connect descriptor must be in the TNS names configuration file.

The tnsnames.ora file is used by Unicenter AutoSys JM to look up the database

host machine and port number based on its name. It is the means by which the
network is navigated to find the Oracle data server. This file specifies where the
Oracle server is located. On UNIX, the tnsnames.ora file is usually in the /etc or
$TNS_ADMIN directory. On Windows, this file is usually in the
\ORANT\NETWORK\ADMIN directory.

Introduction to Unicenter AutoSys Job Management 1–13

Directory Structure

Directory Structure
The following figure shows the default directory structure for Unicenter AutoSys
JM . This figure refers to the installation directory as AUTOTREE. When this
default structure is used, all the prompts displayed by the install scripts will
match exactly what you see on the screen. The autouser directory can be placed
elsewhere. The new directories are pointed to by the environment variables
AUTOSYS and AUTOUSER.

/usr/vendor/autotree

(bundled DB only)
$AUTOUSER $AUTOSYS $SYBASE
autouser sadb
interfaces file
Configuration Files:
config.$AUTOSERV
autosys.sh.host
autosys.csh.host ASE-12-0 DATA OCS-12-0
etc.

bin install lib bin include lib

archive sounds
out

test
bin code dbobj doc sounds snmp

install

data bin jil demo

1–14 Installation Guide

 Connecting to the Database

Connecting to the Database

All information is kept in a relational database (RDBMS) called the event server,
which is configured for Unicenter AutoSys JM. Access to Unicenter AutoSys JM
requires a connection to this database. That is, you must connect to the database
to add, modify, control, report on, or monitor jobs, and to change certain
configuration settings.

The configuration parameters and the Unicenter AutoSys JM and database

environment variables (described previously) tell the software which databases
to connect to for a particular instance. The following figures illustrate how this is
accomplished.

Note: These examples use the default values for the environment variables, and
when appropriate, they show both the UNIX and Windows environments.

The following figure illustrates how this is accomplished when connecting to a

Sybase database:

Connecting to a Sybase Database

Reads the $AUTOUSER/config.$AUTOSERV file or the
AutoSys Administrator settings in the Windows NT Registry
d and locates the Event Server and database configuration
setting (for example: EventServer=AUTOSYSDB:autosys).

c Access AutoSys e Searches for AUTOSYSDB in the interfaces or SQL.INI file.

Uses hostname and port number entry to connect to Sybase

f database
6234).
(for example: AUTOSYSDB autosys_server

AutoSys Server
autosys_server
RDBMS

Introduction to Unicenter AutoSys Job Management 1–15

Connecting to the Database

The following figure shows the scenario for connecting to an Oracle database.

Connecting to an Oracle Database

Reads the $AUTOUSER/config.$AUTOSERV file or the
AutoSys Administrator settings in the Windows NT Registry
d and locates the Event Server and database configuration
setting (for example: EventServer=MYORACLEDB).

Searches for the TNS aliasMYORACLEDB in the

c Access AutoSys e tnsnames.ora file.

f Uses network configuation information to connect to

SQL*Net V2 and the Oracle database.

AutoSys Server
MYORACLEDB
RDBMS

1–16 Installation Guide

 Changes to System Files and Directories

Changes to System Files and Directories

The changes listed are made to existing system files and directories during the
course of the installation. Unless noted, these changes are made on all installed
machines:

■ A line is added to the internet demon (inetd, usually found in

/etc/inetd.conf) so that it points to the remote agents.

■ The internet demon services file (usually /etc/services) is changed. If your

machine is running NIS or NIS+, you must edit the file, remake the map, and
push it out to all clients.

■ The file named auto.profile is added to the /etc directory.

■ The files named Autosc, Autocons, and Autocal are added to the local app-
defaults directory. This directory is usually one of the following:
/usr/lib/X11/app-defaults
/usr/openwin/lib/app-defaults

■ The file named XKeysymDB is added to the /usr/lib/X11 directory, if it is

not already there. If the X11 directory does not exist, it is created.

■ Because of certain Sybase requirements, if you are installing a bundled

Sybase database, the UNIX kernel of the server machine must be
reconfigured manually for certain operating systems. This must be done
before the database is started. These changes are explained in the chapter
“Preparing the Server for Installation,” in the Unicenter AutoSys Job
Management for UNIX Installation Guide.

Introduction to Unicenter AutoSys Job Management 1–17

Multiple Instances

Multiple Instances
Multiple instances of Unicenter AutoSys JM can run on the same machine and
can schedule jobs on the same machines without interfering or affecting the other
instances. Each instance uses its own event processor and event server and
operates independently of other instances; however, you can configure instances
to run with cross-instance job dependencies.

For information on installing multiple instances and configuring to run with

cross-instance job dependencies, see the topic Running Cross-Instance Job
Dependencies in this chapter.

Note: If you elect to install multiple instances of Unicenter AutoSys JM on one

machine where the first instance of Unicenter AutoSys JM has been configured to
use eTrust Access Control (eTrust AC) it is recommended that all job processing
be put on hold for that instance or that instance be shutdown completely before
proceeding with any new installations of Unicenter AutoSys JM on this machine.
This is recommended since the installation program will stop and restart eTrust
ACl on several occasions during the post installation process if you elect to
configure the new instance with eTrust AC. This stopping and starting of eTrust
AC may impact any running Unicenter AutoSys JM instances currently using
eTrust AC.

1–18 Installation Guide

 Multiple Instances

Running Multiple Instances

You can run multiple instances of Unicenter AutoSys JM on the same network at
the same time. Some of the reasons you may want to run multiple instances are
listed following:

■ Your processing volume is large, and you want to distribute the load down
to the departmental level.

■ You want each department in your company to be insulated from what

happens in other departments.

■ You want to separate or test your development and production

environments.

Each instance must have its own event processor specified in the configuration
file and it must have its own instance-specific event servers installed.

Event processors from multiple instances can access the same client machines to
start jobs. To enable this, you must install a remote agent on the client machine
for each instance that will run jobs on that machine.

Different instances can run from the same executables and can have the same
values for the AUTOSYS and AUTOUSER variables, both on the event processor
machine and on client machines. However, each instance must have a unique
value for the AUTOSERV variable and each instance must have its own unique
remote agent port number. You can have unique event server port numbers for
each instance, but this is not required.

Note: The use of multiple databases is completely independent of multiple

instances. You can have multiple instances, each using dual event servers.

The following figure shows two instances of Unicenter AutoSys JM, each with a
single event server. Both instances can send jobs to the same client machine as
long as both instances have a remote agent installed or configured on that client
machine.

Introduction to Unicenter AutoSys Job Management 1–19

Running Cross-Instance Job Dependencies

One Instance of AutoSys One Instance of AutoSys

ACE PRD

OS File OS File
config.ACE File config.PRD File
or NT Registry Settings or NT Registry Settings

Event Event
Server Server
Event Event
Processor Processor

Client
Machine

Remote Agent for ACE instance

Remote Agent for PRD instance

Note: If you want to install Unicenter AutoSys JM on both UNIX and Windows,
and you want to enable cross-platform job dependencies, then you must supply
different remote agent port numbers for each instance that you install. On
Windows, the remote agent port number must be unique, so if you are running
across UNIX and Windows platforms, you must configure your UNIX
components with the same remote agent port numbers that you are using on the
Windows installations.

For information about installing multiple instances, see the chapter “Advanced
Configurations,” in this guide.

Running Cross-Instance Job Dependencies

You can implement cross-instance job dependencies among different instances.

1–20 Installation Guide

 Running Cross-Instance Job Dependencies

Specifying Cross-Instance Job Dependencies

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 may appear as 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-alphanumeric ID of PRD.

If the dependency specification does not include a caret (^) and a different
instance ID, the current instance will be used by default.

Each time cross-instance job dependency is encountered, Unicenter AutoSys JM

sends an EXTERNAL_DEPENDENCY event from the requesting instance. If the
target instance cannot be reached, Unicenter AutoSys JM issues an
INSTANCE_UNAVAILABLE alarm.

The following figure shows two instances, each with a single event server,
sharing cross-instance dependencies.

One Instance of AutoSys One Instance of AutoSys

ACE PRD

Event Event
Server Server
OS File OS File
config.ACE config.PRD File
config.EXTERNAL or NT Registry Settings
Event Event
Processor Processor

condition: success jobB

(jobB^PRD) condition: success
jobE (jobE^ACE)

For more information about defining jobs to run with cross-instance

dependencies, see Cross-Instance Job Dependencies in the chapter “Jobs” of the
Unicenter AutoSys Job Management for UNIX User Guide.

Introduction to Unicenter AutoSys Job Management 1–21

Running Cross-Instance Job Dependencies

Event Processors and Cross-Dependencies

When you implement cross-instance job dependencies, event processors can do

the following:

■ Run on different server machines or on the same server machine.

■ Access the same client machines to start jobs.

■ Send events to other instances.

Note: If the event server of a target instance is down, the event processor will try
to resend events every five minutes until it can reach the other instance’s event
server.

Event Servers and Cross-Dependencies

Each time a job definition with a cross-instance job dependency is submitted to

the event server, the following entries are made in the database:

■ To the ext_job table of the source instance. The entries in this table specify
the status of jobs belonging to other instances in which this instance has
defined job dependencies.

■ To the req_job table of the target instance. The entries in this table specify the
jobs that have a job dependency in a job definition in the source instance.

In both the source instance and target instance tables, jobs are entered using the
job name, a caret symbol (^), and the instance name, like the following:
jobB^PRD

Note: When communicating with event servers, event processors can only
connect to those instances with “like” event servers. That is, instances with
Sybase data servers can only connect with other instances having Sybase data
servers. The same holds true for instances with Oracle and Microsoft SQL Server
databases.

For information about configuring Unicenter AutoSys JM to run with cross-

instance job dependencies, see Configuring for Cross-Instance Job Dependencies
in the chapter “Advanced Configurations,” in this guide.

1–22 Installation Guide

 High-Availability Options

High-Availability Options
Unicenter AutoSys JM provides two high-availability options that lets Unicenter
AutoSys JM keep processing even if an event server or event processor fails due
to hardware or connection problems. These high-availability options are dual-
event servers and a shadow event processor.

You can install and configure the high-availability options at the same time you
install , or you can modify an existing installation to add the high availability
options.

For information on installing high-availability options, see the chapter

“Advanced Configurations,” in this guide.

Dual Event Servers

One way that Unicenter AutoSys JM provides high-availability is by running

two event servers. The two event servers contain identical information, including
job definitions and events, because Unicenter AutoSys JM reads and writes to
both servers simultaneously. Unicenter AutoSys JM also keeps both event
servers synchronized and provides complete recovery when one server becomes
unusable, disabled, or corrupted.

When processing events, the event processor reads from both event servers. If it
detects an event on one server and not the other, it will copy the missing event to
the other server. In this way, a temporary problem in getting events to one of the
servers will not interrupt processing.

In addition, the remote agent sends events and writes to both event servers.

The following figure illustrates a typical configuration running with dual event
servers.

Important! We recommend that the two event servers reside on two different
machines, to prevent a single point of failure.

Introduction to Unicenter AutoSys Job Management 1–23

High-Availability Options

reads
&
writes
Event Event
Server Server
#1 #2
reads
& writes
writes

Event
Processor

MACHINE A MACHINE B

Start
Job
Remote
Agent

Run Job

User
Command

Remote
MACHINE

1–24 Installation Guide

 High-Availability Options

Running with Dual-Event Servers

When running within dual-event server mode, and the event processor detects
an unrecoverable condition on one of the event servers, it automatically rolls
over to single server mode. A rollover results from one of the following
conditions:

■ The connection to the database is lost, and after the configured number of
reconnect attempts, the database remains unconnected.

■ The database has an unrecoverable error, for example, the database is

corrupt or a media failure occurs.

If there was an event server rollover on servers running on UNIX, the event
processor edits the $AUTOUSER/config.$AUTOSERV configuration file, on the
server machine only, to comment out the database that has been taken offline.
The event processor makes this change so that utilities attempting to access the
database will know that Unicenter AutoSys JM is now running in single server
mode.

Do not restart the down event server and run in dual-event server mode. Before
starting the event server, you must make sure that the two event servers are
synchronized.

Note: If Unicenter AutoSys JM is configured to run with dual-event servers, the

event processor will not start unless both databases are available.

For information on event server recovery, and how to synchronize event servers,
see the chapter “Maintaining ” in the Unicenter AutoSys Job Management for
UNIX User Guide.

Shadow Event Processor

Another way that Unicenter AutoSys JM provides high-availability is through

running with a shadow event processor. The shadow event processor is designed
to take over event processing in case there is a failure of the primary event
processor.

The following figure illustrates a typical configuration running with primary

and shadow event processors as well as dual-event servers. The shadow event
processor and dual-event servers are independent features, but you can run
them together. (This configuration is not required.)

Introduction to Unicenter AutoSys Job Management 1–25

High-Availability Options

Important! We recommend that the primary and shadow processors reside on

two different machines, to prevent a single point of failure.

Remote
Agent

.dibs file

Third
MACHINE

reads
&
writes
Event Event
Server Server
#1 #2
reads
& writes
writes

Primary Shadow
Processor Processor
PING

MACHINE A MACHINE B

Start
Job
Remote
Agent

Run Job

User
Command

Client
MACHINE

1–26 Installation Guide

 High-Availability Options

Running with a Shadow Event Processor

The shadow event processor is normally in idle mode, listening for routine pings
from the primary event processor, which indicate all is well. If the shadow event
processor stops receiving this signal, it assumes the primary event processor has
failed.

If the shadow event processor does not receive the signal, it checks the third
machine (defined in the configuration file) for the .dibs file. If it cannot connect
to the third machine, the shadow event processor shuts down. If it can connect
and cannot locate the .dibs file, the shadow event processor creates the file,
attempts to signal the primary event processor to stop, and takes over processing
the events. If the file already exists, it shuts down.

Similarly, if the primary event processor cannot locate and signal the shadow
event processor, the primary processor checks the third machine for the .dibs file
and follows the same procedure as the shadow event processor (described
previously).

If it is necessary at the time of event processor rollover, Unicenter AutoSys JM

will also rollover from dual-server mode to single-server mode. That is, if the
primary event processor and an event server are on the same machine, the event
processor failure could also mean an event server failure. In this situation,
Unicenter AutoSys JM would roll over to the shadow event processor, and to
single server mode.

The shadow event processor is designed primarily for the situation where the
machine on which the primary event processor runs goes down, or the network
on which this processor runs goes down. Particular care is given to ensuring that
both event processors never take over at the same time. To achieve this,
Unicenter AutoSys JM uses the third machine and the existence of the .dibs file
to resolve contentions and to eliminate the case where one processor takes over
because its own network is down.

The shadow event processor is not guaranteed to take over in 100% of the cases
where it theoretically could. For example, in the case of network problems,
Unicenter AutoSys JM may not be able to determine which event processor is the
functional one. In this case, both processors will shut down.

For more information about event processor rollover and recovery, see the
chapter “Maintaining” in the Unicenter AutoSys Job Management for UNIX User
Guide.

Introduction to Unicenter AutoSys Job Management 1–27

Related Publications

Related Publications
In addition to this Installation Guide, the following documentation is provided:

■ Unicenter AutoSys Job Management Release Summary, which provides

important information about this version, read this before proceeding.

■ Unicenter AutoSys Job Management for UNIX Upgrade Instructions, which

describes how to upgrade to the current version of Unicenter AutoSys JM.

■ Unicenter AutoSys Job Management for UNIX User Guide, which describes
how to use Unicenter AutoSys JM to define, run, manage, monitor, and
report on jobs. In addition, it describes how to run and manage the
databases, and it describes security and the configuration file.

■ Unicenter AutoSys Job Management for Windows and UNIX Reference

Guide, which lists the system states and commands, and lists job, machine,
monitor, and report definition parameters.

1–28 Installation Guide

 Chapter

Preparing for Installation

2
This chapter describes the decisions you need to make, the tasks you need to
perform, and the information you need to gather to prepare for your Unicenter
AutoSys JM installation.

Meeting System Requirements

Memory

We recommend that the server machine have at least 512 MB of RAM.

Disk Space

The total disk space requirement to install Unicenter AutoSys JM with a bundled
Sybase database on the server is 600 MB. To install only the application (without
bundled Sybase), 150 MB of available disk space is required. To install the Oracle
application binaries, 350 MB of disk space is required.

Oracle Requirements

The recommended size of the data tablespace is 100 MB.

The recommended size of the index tablespace is 40 MB.

Sybase Requirements

For unbundled Sybase, the standard size of a database is 100 MB. We

recommend a transaction log of 20 MB.

Preparing for Installation 2–1

Meeting System Requirements

Adaptive Server Version 12.0

The hardware and software requirements for the Sybase Adaptive Server
Enterprise Version 12.0 are listed as following.

Platform Hardware Software Minimum RAM

Tru64 Tru64 4.0 92 MB

Sun Solaris Sun SPARC Sun Solaris 2.6 64 MB (32-bit)

92 MB (64-bit)

HP-UX HP 9000/700 HP-UX 11 64 MB (32-bit)

HP 9000/800
92 MB (64-bit)
HP 9000 D & E
classes

IBM RISC AIX 4.3.3 64 MB (32-bit)

System/6000
92 MB (64-bit)

The following operating system patches are required for the Adaptive Server on
HP-UX 11.0 to run Adaptive Server 12.0 components for both 32-bit and 64-bit
versions:

■ Extension Patch Bundle 9808

■ PHNE_16017 – NFS Kernel General Release/Performance patch

■ PHNE_16599 – NFS Kernel General Release/Performance patch

■ PHNE_16470 – ONC cumulative patch

■ PHKL_15689 – AutoFS support patch

■ PHKL_17091 – PM/VM/UFS/async/scsi/io/DMAPI/p2p_bcopy/MPI

■ PHCO_16629 – libc cumulative patch

■ PHCO_19391 – libc cumulative patch

■ PHSS_16404 – ld (1) and linker tools cumulative patch

■ PHSS_18072 – ld (1) and linker tools cumulative patch

2–2 Installation Guide

 Meeting System Requirements

AIX 4.3.2 requires the following operating system patches to run Adaptive
Server 12.0 components:

■ TX88865 (JRE patch)

■ TY01642

■ TY02407

Solaris 2.6 (32-bit) requires the following operating system patches to run
Adaptive Server 12.0 components:

■ 105284-16

■ 105490-06 (memory leak patch)

■ 105181-12, 105568-13 (JRE patches)

■ 105181-06

■ 105210-09

■ 105529-03

■ 105786-05

■ 104668-09 (c 4.2)

■ 104631-07 (c++ 4.2)

Solaris 2.7 (64-bit) requires the following operating system patches to run
Adaptive Server 12.0 components:

■ 106541-03

■ 106327-05

■ 106300-06

Preparing for Installation 2–3

Selecting Components

Database Size Requirements

The required database sizes are the minimum recommended sizes. If your job
load is large, you should create a larger database. The size requirements for your
database depend on the following criteria:

1. The number of jobs you define.

2. How many of the jobs have dependencies.

3. How often the jobs are run. (Every time a job runs, it generates at least
three events and an entry in the job_runs table.)

4. How often the database is cleaned. (The utility called dbmaint handles
this; see the chapter “Maintaining” in the Unicenter AutoSys Job
Management for UNIX User Guide.)

Selecting Components
The installation lets you install the following listed software components:

Server
The server installation sets up the database and various configuration files,
and then configures the server machine to run as a client as well. This
enables you to run jobs on a server machine.

Client
The client installation must be performed on every machine that you will use
to run, monitor, or define jobs.

2–4 Installation Guide

 Remote Command Service

Remote Command Service

Since Unicenter AutoSys JM can be installed through multiple scenarios, this
section is designed to assist you with which listener to install. The “listener” is
defined as an interface point between the Unicenter AutoSys JM Web Interface
and Unicenter AutoSys JM. It allows the Web Interface application to present
real-time data from the Unicenter AutoSys JM machine to its client.

With the Unicenter AutoSys JM 4.5 base product, the Java Listener which is
currently shipped on the Unicenter AutoSys JM Web Interface CD has been
updated to run as a “C” based application. This new “C” based application is
now known as the Remote Command Service (RCS) and is included on the
Unicenter AutoSys JM 4.5 base product CD. Having written the RCS as a
portable “C” based application it eliminates the need to have to install the Java
Runtime Environment (JRE) on the Unicenter AutoSys JM Event Processor
machine or Remote Agent machines to which the Unicenter AutoSys JM Web
Interface was to access data from. The following sections describe each
component in some addition detail.

RCS component should be selected for installation when installing the Unicenter
AutoSys JM 4.5 base product if you plan to utilize the Unicenter AutoSys JM 4.5
Web Interface. The Unicenter AutoSys JM 4.5 Web Interface requires RCS to be
installed in order to service requests initiated on behalf of the Web Interface
when running against Unicenter AutoSys JM 4.5.

RCS is included as part of the base installation with the following platforms.

■ HP 9000/800, 700 HP-UX 11, 11i

■ IBM RS/6000 AIX 4.3.3, 5.1, 5.2

■ SUN SPARC Solaris 2.6, 2.7, 2.8, 2.9

■ Red Hat Linux 7.2, 7.3, 8.0, 9.0

■ SuSE Linux 8.0

■ Microsoft Windows NT 4.0 SP6, 2000 SP2, XP, 2003

Preparing for Installation 2–5

Remote Command Service

Java Based Listener

The Java Listener component should be selected for installation if installing the
Unicenter AutoSys JM Web Interface and the Web Interface will be initiating
requests against earlier versions of Unicenter AutoSys JM (For example; 4.0).

For more information on requirement and details on installing the Java Listener,
see the Unicenter AutoSys Job Management Web Interface Installation Guide.

Installation of the Java Listener on any Unicenter AutoSys JM Event Processor

machine or Remote Agent machine will require the installation of JRE 1.4 or
higher in order to successfully interface with the Unicenter AutoSys JM Web
Interface.

Listener Compatibility

The following table illustrates which listener to install when interfacing the
Unicenter AutoSys JM Web Interface with the Unicenter AutoSys JM base
product.

Product Unicenter AutoSys JM Unicenter AutoSys JM

Web Interface 4.0 Web Interface 4.5
Unicenter AutoSys JM 4.0 4.0 Java Listener 4.5 Java Listener

Unicenter AutoSys JM 4.5 4.0 Java Listener Remote Command

Service (RCS)

Notes:
■ The 4.0 Java Listener is included on the Unicenter AutoSys JM Web Interface
4.0 CD.

■ The 4.5 Java Listener is included on the Unicenter AutoSys JM Web Interface
4.5 CD.

■ RCS is part of the Unicenter AutoSys JM 4.5 base product installation.

2–6 Installation Guide

 Identifying Machines

Identifying Machines
Before you install, identify the machines on which you will install the required
components.

Server Machines

The server machine is a machine on which the database, the event processor, or
both reside.

You must perform the modifications described in the chapter “Preparing the
Server for Installation” in this guide, before you perform the installation.

Identify one reliable machine on which to install the database. To ensure high
availability of the database, you can install dual-event servers; in which case,
you identify two reliable machines on which to install databases. The terms
event server and database are often used interchangeably.

You can also install a shadow event processor to ensure high availability of the
event processor. This requires that you identify two additional machines—a
shadow machine and a third machine. The primary and shadow event processor
machines and the third machine must all be of the same type, either Windows or
UNIX. All three machines must be defined by the same instance.

Client Machines

Identify one or more machines on which to install the remote agent. You can
define a client machine to run jobs only, or to run both jobs and the GUIs for
defining and monitoring jobs.

Preparing for Installation 2–7

Identifying Machines

User and Host Names for eTrust Access Control

To avoid intrusion, eTrust AC is particular about the spelling of user names and
host names. This affects Unicenter AutoSys JM users in the following
circumstances:

■ When a Policy Manager connects to the Policy Model Database (PMDB) to

administer it, and

■ When the Policy Model server connects to one of its subscribers.

In the first case, the eTrust server uses the IP address of the Policy Manager
machine to find its host name. It then checks that the user making the request
has administrative authority over the PMDB from that host. In other words, the
Policy Manager user must be defined as an administrator of the PMDB, and
must have write access to the TERMINAL whose name matches the name of the
host where the Policy Manager is running.

In the second case, the subscriber uses a similar procedure to authenticate the
PMD server. It uses the server's IP address to find the server's host name. It
checks that the server's host name matches the subscriber's expected PMD server
name and that the user who changed the policy is an administrator of the
subscriber.

2–8 Installation Guide

 Identifying Machines

Determining the Policy Manager User Name

To determine the policy manager name do the following:

1. Run the Policy Manager.

2. Select Options, from the Tools menu.

3. Select the Appearance tab.

4. Make sure the Show Connection Dialog box is checked under General
Settings.

5. Click OK.

6. Select Connect from the File menu.

7. Highlight localhost in the list and click OK.

8. Note the User Name from the Connection Information box.

When entering a Windows user name with a domain name into a UNIX
machine, double the backslash, for example WORKGROUP\\Administrator.
UNIX systems are sensitive to upper and lower case letters, even in the names of
Windows users.

Preparing for Installation 2–9

Identifying Machines

Determining a PMDB or Policy Manager Host Name

Use the PMD server to find the name of a Policy Manager host. Use a subscriber
to find the name of the PMD server. Remember to do this on the machine
receiving the connection, not the machine whose name you want to know how to
spell.

Beware that different subscribers on your network might use different name
services, and therefore might require different spellings of the PMD server name.
Some might require the domain name and others might require you to omit it.

Try it without the domain name, then with it. Substitute the host's IP address for
ipaddr where it appears.

1. Determine which name services are in effect.

$ grep '^hosts' /etc/nsswitch.conf

Look for the words files, nis, nisplus, and dns in the output. Use the
commands to the right of the $ signs in steps 2 and 3 in the order the
corresponding name services appear in nsswitch.conf. Stop when you find a
match. If you don't have the nsswitch.conf file, try all of the commands.

2. Find the IP address of the host in question.

files $ fgrep -i hostname /etc/hosts
nis $ ypmatch hostname hosts
nisplus $ nismatch, ask your network administrator for details
dns $ nslookup hostname

3. Translate the IP address to the name.

files $ fgrep ipaddr /etc/hosts
nis $ ypmatch ipaddr hosts.byaddr
nisplus $ nismatch, ask your network administrator for details
dns $ nslookup ipaddr

2–10 Installation Guide

 Identifying Machines

Examples:
$ grep '^hosts' /etc/nsswitch.conf
hosts: files nis dns
$ fgrep -i morpheus /etc/hosts
$ ypmatch morpheus hosts
192.168.2.25 morpheus hqsun56
$ fgrep 192.168.2.25 /etc/hosts
192.168.2.25 hqsrv56

In the previous example, the correct spelling is hqsrv56, since that's the first
name encountered for that IP address.
$ grep '^hosts' /etc/nsswitch.conf
hosts: files dns
$ fgrep -i morpheus /etc/hosts
$ nslookup morpheus
Server: hqsrv2.com.biz
Address: 192.168.1.7
Name: hqsrv56.com.biz
Address: 192.168.2.25
Aliases: morpheus.com.biz
$ fgrep 192.168.2.25 /etc/hosts
$ nslookup 192.168.2.25
Server: hqsrv2.com.biz
Address: 192.168.1.7
Name: hqsrv56.com.biz
Address: 192.168.2.25

In the previous examples, this subscriber doesn't use NIS, and doesn't have the
PMD server in its hosts file. The correct spelling in this case is hqsrv56.com.biz.

Preparing for Installation 2–11

Gathering Installation Information

Gathering Installation Information

To begin the installation, you need the information described in the following
sections. Use the checklists in the section Using the Installation Checklists in this
chapter to help you organize the information.

Wizard Setup

Prior to installation, you will need the following information for the setup
wizard.

Unicenter AutoSys JM Server

All Unicenter AutoSys JM components

Unicenter AutoSys JM Client

Remote Agent, client, and guis

Unicenter AutoSys JM Agent Only

Remote Agent Only

eTrust Server Information

This information is for the eTrust server which will contain the pmdb.

Admin. Users

List the OS users who will have permission to administer the eTrust AC on
Admin Hosts

Admin. Hosts

A list of hosts from which Admin Users may administer the pmdb.

2–12 Installation Guide

 Gathering Installation Information

Subscribers

The host names of eTrust AC clients which will subscribe to this pmdb.

eTrust Client Information

This information is for the eTrust client which will subscribe to the pmdb.

Admin. Users

A list of users who will have permission to administer the eTrust AC on this
host.

Note: In the eTrust client (seosdb), you must specify an admin user that is
defined in the eTrust server (pmdb). If this is not done then client (seosdb) will
not be synchronized with the server (pmdb).

Server host

The host name of the eTrust AC server.

Unicenter CCI information

This information is for the installation of Unicenter CCI.

Installation directory

The directory to install Unicenter CCI.

Remote Hosts

The name of remote hosts with which CCI is to communicate.

Remote Command Service Information

This information is for the installation of the RCS.

Preparing for Installation 2–13

Gathering Installation Information

Installation directory

The directory to install the RCS.

Port Number

The TCP port number for the RCS.

Valid Hosts

The host names of machine which will communicate with the RCS.

Directories

The fully qualified names of directories where the RCS will look for standard
output and standard error files from jobs.

auto_install Setup

After the Setup Wizard, you will need the following information for the
auto_install

System Files Location

Specify the location of your system files, either local, NIS, or NIS+. If your
system uses NIS or NIS+, see NIS or NIS+ Only: Configure Internet Demon
Services in the chapter “Preparing the Server for Installation,” in this guide.

Monitor Type

Specify if the monitor is color or monochrome

Owner

A UNIX user will be assigned ownership of the software files. This can be any
user except root. If this user does not exist, create it now. This user’s home
directory can be any directory except one of those found under the standard
installation directory autotree.

2–14 Installation Guide

 Gathering Installation Information

The owner has no special permissions regarding jobs unless given Superuser
permissions during the installation process.

Instance Information

An instance must have a unique ID (an uppercase, three-alphanumeric name

that identifies a specific installation of AutoSys).

Path Name to AUTOUSER

The $AUTOUSER directory, which contains configuration files, output files, and
user-defined sound files, can be placed in a different directory than the standard
installation directory (autotree). By convention, the $AUTOUSER directory is
located in autotree/autouser.

Primary Event Server Name

The logical name of the database (event server). When performing database
queries, Unicenter AutoSys JM uses this value to locate the event server.

If you are installing with bundled Sybase, the name of the data server is
AUTOSYSDB.

Primary Event Server Host (Sybase)

The host name of the machine on which the event server for the instance is
installed and will run.

Primary Database Name (Sybase)

The name of the database. For bundled Sybase, this name is autosys.

SA User (Sybase)

The user who was granted the System Administrator and System Security
Officer (SSO) roles for the database.

Preparing for Installation 2–15

Gathering Installation Information

SA Password (Sybase)

The password for the user who was granted the System Administrator (SA) and
System Security Officer (SSO) roles for the database.

Bundled Sybase

For bundled Sybase, some operating system modifications are required on

certain platforms, as described in the chapter “Preparing the Server for
Installation,” in this guide.

Note: Bundled Sybase users cannot change the size of the database shipped with
the software.

Unbundled Sybase

In addition to the previous information, you must supply the following

information:

■ The directory path to the existing interfaces file.

■ The size of the database to be created is recommended at 100 MB.

The steps for creating and configuring the Sybase database are detailed in
Configuring an Existing Unbundled Sybase Database in the chapter, “Preparing
the Server for Installation” in this guide.

Primary Event Server TNS Alias (Oracle)

The Net8/Oracle Net TNS alias for the event server that will contain the
database. AutoSys requires that Net8/Oracle Net be installed on the database
machine. The TNS alias name must be configured in the Oracle tnsnames.ora
configuration file.

Location of tnsnames.ora File (Oracle)

The system TNS configuration file is tnsnames.ora. You must specify the path to
the tnsnames.ora file.

2–16 Installation Guide

 Gathering Installation Information

Data Tablespace Name (Oracle)

The name of the tablespace on event server that will contain the database tables.
The recommended size is 100 MB.

Index Tablespace Name (Oracle)

The name of the tablespace on the event server that will contain the database
indexes. The recommended size is 40 MB.

Temporary Tablespace Name (Oracle)

The name of the tablespace on the event server that will contain the temporary
tablespace.

DBA User Name (Oracle)

The name of the user who was granted the DBA role for the database.

DBA Password (Oracle)

The password of the user who was granted the DBA role for the database.

Oracle Database Configuration

The steps for configuring the Oracle database are detailed in Configuring an
Existing Oracle Database in the chapter, “Preparing the Server for Installation”
in this guide.

The recon utility is provided to verify that your Oracle environment is properly
configured. As described in the Oracle Setup Utility in the chapter, “Server
Installation for Oracle” in this guide.

Preparing for Installation 2–17

Gathering Installation Information

auto_remote (Remote Agent) Directory Path

The path to the remote agent executable. The remote agent executable can be
installed in any valid directory. The default for server installations is
$AUTOSYS/bin; for clients, it is /usr/local/bin. Because the actual path to the
executable is written in the inetd configuration file, you should be cautious
about changing it. Therefore, choose a stable directory that is not subject to
removal.

inetd File Location

You must specify the path and file name of the configuration file for the internet
services demon (inetd). Typically, this file is:
/etc/inetd.conf;

on some systems, it is:

/usr/etc/inetd.conf

and on others is:

/etc/xinetd.d/

Remote Agent Service Name

It is possible to install and maintain different versions on the same hardware by

setting up multiple services with different names and different port numbers.
For most installations, you can safely use the default remote agent service name,
auto_remote.

Remote Agent Port

The default port number for the remote agent is 5280. If this number is already in
use, or if you wish to install multiple versions of the remote agent, you can
change this number.

2–18 Installation Guide

 Using the Installation Checklists

Using the Installation Checklists

Use the following checklists for the information you will need to install on
UNIX.

Wizard Setup Checklist for Unicenter AutoSys JM Server

Use the following table to define your setup wizard.

Unicenter AutoSys JM Wizard Setup

Option Response
Unicenter AutoSys JM Server (y/n)

eTrust Access Control (y/n)

Admin. Users

Admin. Hosts

Subscribers

eTrust Client (y/n)

Admin. Users

Server host

Unicenter CCI (y/n)

Installation Directory

Remote Hosts

Unicenter AutoSys Motif GUIs (y/n)

Unicenter AutoSys JM Remote

Command Service for Web Interface
(y/n)

Installation Directory

Port Number

Valid Hosts

Directories

Preparing for Installation 2–19

Using the Installation Checklists

Wizard Setup Checklist for Unicenter AutoSys JM Client

Use the following table to define your setup wizard.

Unicenter AutoSys JM Wizard Setup

Option Response
Unicenter AutoSys JM Client (Agent
Only)

eTrust Access Control (y/n)

eTrust Server (y/n)
Admin. Users

Admin. Hosts

Subscribers

eTrust Client (y/n)

Admin. Users

Server host

Unicenter AutoSys JM Motif GUIs

(y/n)

Unicenter AutoSys JM Remote

Command Service for Web Interface
(y/n)

Installation Directory

Port Number

Valid Hosts

Directories

2–20 Installation Guide

 Using the Installation Checklists

Server Checklist

Use the following table to define your server.

Server Checklist
Item Description
Platform

Operating system/version

Host name

Host ID

Password of root

Available memory (512 MB

recommended)

Available disk space (350 MB Oracle,

600 MB Bundled Sybase, 150 MB
Unbundled Sybase)

License keys obtained and available

(y/n)

Installation directory pathname

(AUTOSYS)

Directory path name for configuration

and output files (AUTOUSER)

Instance name (AUTOSERV)

Non-NIS, NIS, or NIS+ configuration

Monitor type (color or monochrome)

Name of user who will own software

files

Installing with bundled Sybase or

unbundled Sybase or Oracle?

If bundled, OS configuration required

(y/n)

OS configuration completed (y/n)

Preparing for Installation 2–21

Using the Installation Checklists

Server Checklist
Item Description
Name of data server that will contain
database (DSQUERY)

Name of database in data server

Path to Sybase interfaces file

(SYBASE)

Name of database user who has been

granted both SA and SSO roles

Password of database user who has

been granted both SA and SSO roles

Size of unbundled database

Value of ORACLE_HOME

TNS alias name of the data server

containing the tablespaces

TNS alias name configured in

Net8/Oracle Net (y/n)

Name of the data tablespace

Size of the data tablespace (100 MB

minimum, 100 MB recommended)

Name of the index tablespace

Size of the index tablespace (40 MB

recommended)

Value of TNS_ADMIN

Name of temporary tablespace

2–22 Installation Guide

 Using the Installation Checklists

Server Checklist
Item Description
Name of the database user who has
been granted DBA role

Password for database user who has

been granted DBA role

Full path name to remote agent

executable

Location of the inetd configuration file

Name of the remote agent service

Port number for the remote agent

Preparing for Installation 2–23

Using the Installation Checklists

Client Checklist

Use the following table to define your client. Entries with two stars (**) must
have the same response as the corresponding entry in the Server checklist.

Client Checklist
Item Description
Platform

Operating system/version

Host name

Host ID

Password of root

Installing with bundled Sybase or **

unbundled Sybase or Oracle

Installation directory path name

(AUTOSYS)

Directory path name for configuration

and output files (AUTOUSER)

Instance name (AUTOSERV) **

Install Full client or Jobs only

Non-NIS, NIS, or NIS+ configuration

Monitor type (color or monochrome)

Name of user who will own software

files

Name of data server that will contain **

database (DSQUERY)

Name of database in data server **

Path to Sybase interfaces file

(SYBASE)

Name of database user who has been

granted both SA and SSO roles

2–24 Installation Guide

 Using the Installation Checklists

Client Checklist
Item Description
Password of database user who has
been granted both SA and SSO roles

Value of ORACLE_HOME

TNS alias name of the data server **

containing the tablespaces

TNS alias name configured in

Net8/Oracle Net (y/n)

Value of TNS_ADMIN

Name of the database user who has

been granted DBA role

Password for database user who has

been granted DBA role

Full path name to remote agent

executable

Location of the inetd configuration file

Name of the remote agent service **

Port number for the remote agent **

Preparing for Installation 2–25

 Preparing the Server for
Chapter

3 Installation

This chapter describes how to configure your server machine and its operating
system for using either a Sybase or an Oracle database. It also discusses
configuring a preexisting Sybase or Oracle database for use with Unicenter
AutoSys JM.

Note: You must complete the steps in this chapter prior to installing.

Configuring the Server

In the steps following, you will be asked to perform an action on the server
machine. Record your choices in your server checklist.

Log On to the Server

Since many of these preparatory steps require that you have UNIX superuser
permissions, you should log on to the server machine as “root.”

Preparing the Server for Installation 3–1

Configuring the Server

Installation Directory

All of the software, the database software and the data file (if you are installing a
bundled version) will be installed under the same directory. At this time, you
should confirm that you have sufficient available disk space, as described in
Disk Space in the chapter “Preparing for Installation,” in this guide.

You can specify any directory to be the installation directory, and it does not
have to be empty. By convention, this guide refers to the installation directory as
AUTOTREE, which represents the following default path:
/opt/CA/UnicenterAutoSysJM

After you complete the installation procedure, the following directories will exist
under AUTOTREE:

■ autosys

■ autouser

■ sadb (bundled Sybase only)

Create the AutoSys Owner

A UNIX user will be assigned ownership of all the files. This can be any user
except root.

If the user who is intended to own all files does not exist, create the user now.
This user’s home directory can be any directory except one of those found under
AUTOTREE.

Note: This user is not the only user that can run Unicenter AutoSys JM. Any
user with the correct environment can use Unicenter AutoSys JM.

3–2 Installation Guide

 Configuring the Server

NIS or NIS+ Only: Configure Internet Demon Services

If you are running NIS or NIS+, this step is required. If you are not running NIS
or NIS+, the internet demon is configured automatically when the installation
script is run; therefore, you can skip this step.

Unicenter AutoSys JM starts jobs by first connecting to the internet demon on the
client machine where the job is to be run. If your machine is running NIS or
NIS+, you must edit the services file, remake the map, and push it out to all
clients, including the server. Generally, the system administrator manages this
task.

Add the following line to /etc/services file on the server machine:

auto_remote 5280/tcp

where:

auto_remote Indicates the default service name for the remote agent. If multiple versions are
to be run concurrently on the same hardware, the remote agent service name
must be different for each version. In any case, the remote agent service name
must be the same in both the /etc/services file and the internet demon
configuration file (/etc/inetd.conf). For more information, see Modifying
Remote Agent Settings in the chapter “Configuring” of the Unicenter AutoSys
Job Management for UNIX User Guide.

5280 Indicates the default port number for the remote agent. If this number is
already in use by another internet service at your site, or if you wish to have
multiple versions of the remote agent installed on the same hardware, you can
change this number. In either case, this number should match the port number
recorded in both your server and client checklists.

After the /etc/services file is modified, it must be remade and pushed out to all
clients. For NIS, you would typically issue the following commands:
cd /var/yp
make

Preparing the Server for Installation 3–3

Configuring the Server

To see an updated services file from the client’s perspective, log on to the client
and issue the following command:
ypcat services

If you are using NIS+, see your system administrator for information on how to
push out the services file.

Note: These steps must be done successfully. The primary cause of a job not
starting on a client machine is the improper completion of these steps. If a client
machine that was working suddenly stops, it is usually because the
/etc/services file was modified.

3–4 Installation Guide

 Configuring for Bundled Sybase

Configuring for Bundled Sybase

If you are installing a bundled Sybase database, review the requirements
described in this section. Otherwise, skip this section and go to Configuring an
Existing Unbundled Sybase Database or Configuring an Existing Oracle
Database sections in this chapter.

The name of the bundled Sybase data server is AUTOSYSDB. The name of the
database in that data server is “autosys.”

Note: Bundled Sybase database users cannot change the size of the database that
is shipped with the software.

Configuring the Operating System

Sybase requires that changes be made to certain operating systems for the
database to work properly. The required changes, as dictated in the SYBASE
Adaptive Server Enterprise Installation Guide, are described following, by
operating system. The system administrator should do these changes. For more
information the SYBASE Adaptive Server Enterprise Installation Guide can be
obtained at supportconnect.ca.com.

Tru64

The server machine that will run bundled Sybase must be configured.

To configure the server machine:

1. Edit the file named /etc/sysconfigtab and add the following line:
ipc:
<tab>shm-max = 96468992

where:

<tab> Is a tab character.

2. Restart the system.

Note: If the above step is not performed, the server will not start.

Preparing the Server for Installation 3–5

Configuring for Bundled Sybase

HP-UX

Shared Memory Bundled Sybase will not start unless the operating system kernel has enough
shared memory available.

To adjust the shared memory value of the operating system, use the System
Administration Manager (SAM). Set the shared memory value to 67108864.

Asynchronous You must enable asynchronous disk I/O.

Disk I/O
To enable asynchronous, install the HP asynchronous I/O driver from SAM.
For help with installing this driver, contact your operating system
administrator or HP technical support.

Note: Before executing the following instructions, shut down Adaptive Server
(or SQL Server).

To enable asynchronous disk I/O, do the following:

1. From the SAM Kernel Configuration menu, choose Drivers and set the
Pending State for asyncdisk to In

2. From the Actions menu, rebuild the kernel, and restart the system.

3. At the UNIX prompt, execute the following statements as “root”. The user ID
of the user who is booting Adaptive Server and Backup Server must be the
owner of the /dev/async directory.
/etc/mknod /dev/async c 101 4
chmod 0660 /dev/async
chown sybase /dev/async

Note: Setting the minor device number on /dev/async to 4 reduces or

eliminates transient 605 errors in Adaptive Server.

3–6 Installation Guide

 Configuring for Bundled Sybase

IBM AIX

To install bundled Sybase, you must enable asynchronous disk I/O regardless of
whether you intend to use it. You enable asynchronous I/O by adjusting various
kernel parameters using the SMIT utility. Setting the “servers” and “REQUEST”
parameters optimizes asynchronous I/O for the SQL Server. To address this
requirement, perform the following steps; you must be “root” to do the
following.

Enable asynchronous disk I/O by adjusting the kernel parameters, using the
System Management Interface Tool (SMIT).

To enable asynchronous disk I/O, follow these steps:

1. Enter “smit” at the UNIX prompt.

2. From the Devices menu, select Asynchronous I/O.

3. Select Change/Show Characteristics of Asynchronous I/O.

4. Enter the values from the following:

Minimum number of servers 1
Maximum number of servers 10
Maximum number of REQUESTS I/O 4096
Server PRIORITY 39
ASYNC I/O STATE Available
(to be configured at system restart)

If your system uses more than seven disks at the same time for
Asynchronous I/O, increase the MAXIMUM number of servers value by 1
for every active device.

Preparing the Server for Installation 3–7

Configuring an Existing Unbundled Sybase Database

Solaris 2.x

The Sybase SQL Server will not start unless the operating system kernel has
enough shared memory available. The operating system’s shared memory
parameter should always be set to a value larger than the value of the Sybase
SQL Server’s memory parameter.

To address this requirement, log on as “root” and perform the following steps:

1. Adjust the maximum shared-memory segment size parameter in the

operating system configuration. Add the following line to the end of the
operating system file named /etc/system:
set shmsys:shminfo_shmmax=67108864

2. Restart the operating system.

Configuring an Existing Unbundled Sybase Database

This section applies to unbundled Sybase users only.

If you want to use an existing Sybase database with Unicenter AutoSys JM, it
must be configured before the new software is installed. The Sybase system
administrator permission and the UNIX system administrator permissions are
required to perform these tasks.

The following checklist excerpted from the server checklist. It lists the decisions
you need to make when using an unbundled Sybase database with an Unicenter
AutoSys JM server. Steps describing these decisions are provided after the
checklist. You can fill in your responses in the checklist provided following, or
make a copy of the blank checklist following:

Unbundled Sybase Checklist

Item Description
Value of SYBASE

Name of data server that will contain the

database (DSQUERY)

Name of database in data server

Path to Sybase interfaces file (SYBASE)

3–8 Installation Guide

 Configuring an Existing Unbundled Sybase Database

Unbundled Sybase Checklist

Item Description
Name of database user who has been
granted both SA and SSO roles

Password of database user who has been

granted both SA and SSO roles

Size of unbundled database

1. Determine the value of the SYBASE environment variable. For bundled

Sybase, this is AUTOTREE/sadb.

2. Determine the name of the Sybase SQL Server (DSQUERY) in which the
database will be created. Your Sybase database administrator should supply
this information.

3. Determine the name of the database that will contain the Unicenter AutoSys
JM information. The name can be anything; however, by convention it is
“autosys.”

4. Note the path to the Sybase interfaces file (SYBASE) on the server machine.

5. Identify the database user who has been granted both the System
Administrator (SA) and System Security Officer (SSO) roles.

6. Note the Sybase database user password. When installing Unicenter

AutoSys JM, the password cannot be null. If it is, have the system
administrator change it temporarily for the server installation.

Note: For Sybase SQL Server System 10 or greater, the installation script
prompts you to enter a database user and password granted the SA and SSO
roles. Users running unbundled Sybase 11.9.2 must accept the default user
(sa), then enter the sa account password.

7. Determine the size of the database that will contain the Unicenter AutoSys
JM information. The size can be any value greater than 25 MB. We
recommend 50 MB or 100 MB for large applications.

Preparing the Server for Installation 3–9

Configuring an Existing Unbundled Sybase Database

8. Create the database on the desired Sybase SQL Server using the following
entries (consult the Sybase documentation for more detailed instructions):
isql -Usa -Psa_password -S$DSQUERY

where:

sa_password Is the system administrator’s password.

$DSQUERY Is the setting for the DSQUERY environment variable.

After the previous command has completed executing, enter the following:
1> create database db_name on disk1=db_size
2> log on disk2=logfile_size
3> go

where:

db_name Is the name of the database to be created; it will contain the Unicenter AutoSys
JM data. This name is usually “autosys.”

disk1 Is the disk device to be used for storing the database information.

db_size Is the size of the database (in MB). This is often 60 MB.

disk2 Specifies where the transaction log is to be stored.

logfile_size Is the size of the transaction log file (in MB). This is typically 25 MB.

The actual database objects (for example, tables and stored procedures) will be
installed when the installation script is run. These objects must be installed for
Unicenter AutoSys JM to run.

3–10 Installation Guide

 Configuring an Existing Oracle Database

Configuring an Existing Oracle Database

If you want to use an existing Oracle database with Unicenter AutoSys JM, it
must be configured before the new software is installed. The password of a
database user who has been granted DBA role is required to perform these tasks.
Typically this user is SYSTEM, but it does not have to be.

The recon utility is provided to verify that your Oracle environment is properly
configured for Unicenter AutoSys JM. This is described in the topic Oracle Setup
Configuration Utility in the chapter “Server Installation for Oracle,” in this
guide.

The following checklist is excerpted from the server checklist. It lists the
decisions you need to make when using an existing Oracle database with an
Unicenter AutoSys JM server. Steps describing these decisions are provided after
the checklist. You can fill in your responses in the checklist below, or make a
copy of the blank checklist following:

Existing Oracle Checklist

Item Description
Value of ORACLE_HOME

TNS alias name of the data server

containing the Unicenter AutoSys JM
tablespaces

TNS alias name configured as V2 connect

descriptor? (y/n)

Name of the data tablespace

Size of the data tablespace (100 MB

minimum, 140 MB recommended)

Name of the index tablespace

Size of the index tablespace (40 MB

minimum, 50 MB recommended)

Preparing the Server for Installation 3–11

Configuring an Existing Oracle Database

Existing Oracle Checklist

Item Description
Value of TNS_ADMIN

Name of temporary tablespace

Name of the database user who has been

granted DBA role.

Password for database user who has been

granted DBA role.

1. Determine the value of the ORACLE_HOME environment variable.

2. Determine the TNS alias name of the data server in which the tablespace will
be created.

3. Confirm that the TNS alias name is configured and that a SQL* Net V2
connect descriptor is in the tnsnames.ora configuration file.

4. Determine the name of the tablespaces that will contain the Unicenter
AutoSys JM database objects. The names can be anything; however, by
convention they are:
data tablespace ‘autodata’
index tablespace ‘autoindexes’

By default, temp is used for the temporary tablespace.

5. Determine the size of the tablespaces that will contain the database objects.
The data tablespace must be a minimum of 100 MB, 140 MB is
recommended. The index tablespace must be a minimum of 40 MB, 50 MB is
recommended. These tablespace sizes can be increased for large systems;
however, they should be increased in increments that are proportional to
each other.

6. Determine the value of the TNS_ADMIN environment variable.

Note: TNS_ADMIN specifies the path to the tnsnames.ora file. We highly

recommend that you specify this value to ensure proper communication
between Unicenter AutoSys JM and the database. Also, ensure that the
tnsnames.ora file is world readable.

7. Determine the name of the database user who has been granted DBA role.
Typically this is SYSTEM (the Oracle system user), but it does not have to be.

8. Note the password of the database user who has been granted DBA role.

3–12 Installation Guide

 Configuring an Existing Oracle Database

9. Create the new tablespaces.

Unicenter AutoSys JM uses three tablespaces: a data tablespace, an index

tablespace, and a temporary tablespace. These procedures assume that
Oracle has been installed already with the temporary tablespace.

Note: For optimal performance, we strongly recommend that the data files
for the data tablespace and the index tablespace reside on different hard
disks.

The following example creates the data tablespace data files and the index
tablespace data file.
sqlplus system/system_password@TNS_alias

where:

system_password Is the system user’s password.

TNS_alias Is the TNS alias of the data server.

10. When the SQL prompt appears, enter the following:

create tablespace autodata
datafile ’/usr/app/oracle/ordata/autodata.dbf’ size 100M
default storage (
initial 10K
next 10K
minextents 1
maxextents 100
pctincrease 50);
create tablespace autoindexes
datafile ’/usr/app/oracle/ordata/autoindexes.dbf’ size 50M
default storage (
initial 10K
next 10K
minextents 1
maxextents 100
pctincrease 50);

The actual database objects (for example, tables and stored procedures) will
be installed when the installation scripts are run. These database objects
must be installed for Unicenter AutoSys JM to work properly.

Preparing the Server for Installation 3–13

 Chapter

Server Installation for Sybase

4
This chapter describes the steps for installing the server components of the
application software for Sybase. It contains all of the instructions necessary to
install the AutoSys server for a basic configuration. Information on advanced
AutoSys configurations is given in the chapter “Advanced Configurations,” in
this guide.

Before You Begin

You must complete the server configuration and fill in your server checklist
before performing the installation, following the directions in the chapter
“Preparing the Server for Installation,” in this guide. You can use the
information in your completed checklist during the installation process.

Server Installation
The following is an example server checklist that has been filled in for a basic
configuration with a bundled Sybase database. The procedures in this chapter
will use the information in this example checklist to illustrate the various
installation steps.

Server Checklist
Item Description
Platform Sun

Operating system/version Solaris 2.8

Host name fiji

Host ID 1234567ab

Server Installation for Sybase 4–1

Server Installation

Server Checklist
Item Description
Password of root

Available memory (512 MB 512

recommended)

Available disk space (600 MB 2.6 GB

bundled, 150 MB unbundled)

License keys obtained and available? yes

(y/n)

Installation directory path name for /opt/CA/UnicenterAutoSysJM/

Unicenter AutoSys JM (AUTOSYS)

Directory path name for /opt/CA/UnicenterAutoSysJM/autouser

configuration and output files
(AUTOUSER)

Install CCI yes

Instance name (AUTOSERV) ACE

Non-NIS, NIS, or NIS+ non-NIS

configuration?

Monitor type (color or monochrome) color

Name of user who will own files autosys

Installing with bundled Sybase or Bundled Sybase

unbundled Sybase or Oracle?

OS configuration required? (y/n) yes

OS configuration completed? (y/n) yes

Name of data server that will contain AUTOSYSDB

Database (DSQUERY)

Name of Database in data server autosys

Path to Sybase interfaces file /opt/CA/UnicenterAutoSysJM/sadb

(SYBASE)

Name of database user who has been sa

granted both SA and SSO roles

4–2 Installation Guide

 Server Installation

Server Checklist
Item Description
Password of database user who has
been granted both SA and SSO roles

Full path name to remote agent /opt/CA/UnicenterAutoSysJM/autosys

executable /bin

Location of the inetd configuration /etc

file

Name of the remote agent service auto_remote

Port number for the remote agent 5280

Using the Setup Wizard to Extract Unicenter AutoSys JM from the Media

The version media contains executables for Sybase databases. The media also
includes a script for loading the correct files for your platform and a text file
named README that describes the contents of the media.

To load the version:

1. Log on to the server machine as root.

2. Insert the media into the appropriate device.

3. Mount your CD-ROM following the appropriate steps for your operating
system. For example:
mount -r -t cdfs /dev/rz4c /cdrom

4. Run the installation program as follows:

./install_sybase.sh
Setup Wizard/Extracting Specifics.
AutoSys Server (y/n) yes
eTrust Access Control (y/n) yes
eTrust Server (y/n) yes
Admin. Users
Admin. Hosts
Subscribers
Unicenter CCI (y/n)
Installation directory
Remote Hosts
AutoSys Motif GUIs (y/n)
AutoSys Remote Command Service for the Web Interface (y/n)
Installation directory
Port Number
Valid Hosts

Server Installation for Sybase 4–3

Running the Installation Script

Directories

Notes:

The installation appears as a graphical interface if Java 2 runtime is available in

the path with suitable display. Otherwise, the installer uses a menu-driven
terminal window.

In the eTrust client (seosdb), you must specify an admin user that is defined in
the eTrust server (pmdb). If this is not done then client (seosdb) will not be
synchronized with the server (pmdb).

Running the Installation Script

The installation script is a Bourne shell script located in the
AUTOTREE/autosys/install directory. This script creates required directories,
configures special files for your environment, installs runtime procedures, and
(for networks that are not NIS or NIS+) configures the Internet demon.

To run the installation script:

1. Ensure the SYBASE environment variable is set.

2. Make sure you are logged on as root.

3. If you have not changed directories since loading the release, change to the
install directory by entering:
cd autosys/install

The auto_install script will prompt you for information as it executes,

supplying defaults whenever possible. For the basic configuration, we
recommend that you accept all the defaults.

Note: For unbundled Sybase users, make sure the data server is up. For
bundled Sybase users, the database does not have to be up.

4. Execute the install script as follows:

./auto_install

Note: By default, output from auto_install and your responses to auto_install’s

prompts are written to a log file named
AUTOTREE/autosys/install/auto_install.log. To specify a different log file, use
the auto_install -f filename option.

4–4 Installation Guide

 Running the Installation Script

If you are using NIS or NIS+, ensure that the steps described in the topic NIS or
NIS+ Only: Configure Internet Demon Services in the chapter “Preparing the
Server for Installation”, in this guide, have been completed. The services file
must be edited before you can successfully run auto_install.

Note: The Unicenter AutoSys JM software is compiled for either Sybase or

Oracle prior to shipment; it is not configurable during installation. The
auto_install script prints out which version you are installing; contact Computer
Associates Technical Support.

Server Installation Scripts

The following sample scripts display responses based on installing a basic

configuration with bundled Sybase and unbundled Sybase databases. If you are
installing advanced configurations, your responses to the installation script will
vary from these examples. The sections of the script’s output, which require a
response, are provided; user responses are in bold. The default responses are
displayed in square brackets “[ ].” They can be accepted by pressing Enter.

At various points during the installation, you will be asked to verify the
information that has been entered. When asked, you can enter n (no) to go back
and correct any mistakes. At these verification prompts, you can cancel the
installation and start over.

The script always asks for confirmation before any system files are modified.

After you provide all the information the script needs to begin the installation, a
message that begins with the following line is displayed:
All the information needed to install AutoSys has been collected
Do you wish to proceed? ([y]|n)>

If you confirm at this point, you cannot cancel the installation.

Server Installation for Sybase 4–5

Running the Installation Script

Bundled Sybase

For bundled Sybase installations, you are not prompted for the system
administrator user and password. The default “sa” user, and “sysadmin”
password are used.

After installation, the installation script continues with remote agent

information, as described in the topic Remote Agent Information in this chapter.
Information about CCI is explained in the appendix “Introducing CCI,” in this
guide.

Unbundled Sybase

For unbundled Sybase installation, the install script asks for information
regarding the existing data server and for a database user and password.

After installation, the installation script continues with remote agent

information, as described in the topic Remote Agent Information in this chapter.
For information about CCI, see the appendix “Introducing CCI,” in this guide.

Remote Agent Information

Up to this point, you can cancel the installation and start over. If you press Enter,
files will be modified and you will not be able to stop the installation. You will
see the following message followed by a series of informational messages
describing the progress of the installation:
Continuing installation...

If you want to make changes to the installation settings after this point, you can
rerun the installation after completion (see the topic Rerunning the Installation in
this chapter.)

At this point, this machine is now configured as a server.

4–6 Installation Guide

 Preparing the Installation

Rerunning the Installation

The auto_install script can be run again if necessary. For bundled installations,
rerunning the script gives you the opportunity to overwrite the internet demon
configuration that was made before the previous installation.

WARNING! For unbundled server installations, running auto_install again will

cause the database objects to be rebuilt; as a result, it will delete all the data in
the database.

Preparing the Installation

Unicenter AutoSys JM is now installed on the server machine on which the
installation script was run. Before continuing with the installation of license
keys, creating exec and edit superusers, and installing on the client machines,
you should test the software you have just installed.

The following procedures bring up the data server and event processor on the
server machine. They also test the connection to the remote agent on the server
machine, to ensure that the installation is successful to this point.

Note: The DNS server must be started before starting Unicenter AutoSys JM.

Server Installation for Sybase 4–7

Preparing the Installation

Time Zone Setting

Before you start the event processor, you must ensure that the TZ environment
variable is set. The event processor references this setting to determine the
default time zone. Jobs with time-based starting conditions that do not specify a
time zone will have their start event scheduled based on the time zone under
which the event processor is running. This time zone is also used to report event
times, using the autorep command.

An example of how to set the TZ variable is shown following:

For C shell:
setenv TZ timezone

For Bourne shell and Korn shell:

TZ=timezone; export TZ

where:

timezone Specifies a valid time zone specification (such as: MST7MDT).

Set Up the Environment

To set up the environment, follow these steps:

1. Log on to the server machine as the owner of Unicenter AutoSys JM (for

example, ‘autosys’).

2. Set up the environment for this user by sourcing the proper file in
AUTOUSER. (Since AUTOUSER is not defined yet, you must enter the full
path.)

In the following examples, “fiji” is the name of the server machine and
/opt/CA/UnicenterAutoSysJM represents the path to the directory where you
installed Unicenter AutoSys JM.

If you are running the C shell (csh), enter:

source /opt/CA/UnicenterAutoSysJM/autouser/autosys.csh.fiji

If you are running the Bourne shell (sh), enter:

. /opt/CA/UnicenterAutoSysJM/autouser/autosys.sh.fiji

4–8 Installation Guide

 Preparing the Installation

If you are running the Korn shell (ksh), enter:

. /opt/CA/UnicenterAutoSysJM/autouser/autosys.ksh.fiji

Bundled Sybase Only: Start the Database

If you installed Unicenter AutoSys JM with a bundled database, the auto install
program automatically starts the dataserver. However, if you reboot, or shut
down, the dataserver will be shutdown and you must restart the dataserver
using the following procedures. (For unbundled Sybase users, the data server is
up already.)

If you are using the C or Korn shell, enter:

start_autodb

or:
$SYBASE/ASE-12_0/install/RUN_data server_name

start_autodb is an alias setup in the autosys.csh or autosys.ksh file for bundled

Sybase users only.

If you are using the Bourne shell, enter:

$SYBASE/ASE-12_0/install/RUN_data server_name

The default data server_name is AUTOSYSDB.

As the data server comes up, messages will appear on your screen. These are
messages from the data server. If there are problems, messages will continue to
be output to this window. That is why we recommend that you start the data
server in the console window.

The messages will look something like the following example.

The output begins with:

00:00000:00000:2003/04/08 09:12:43.76 kernel Use license file
/export/home/as45syb/sadb/SYSAM-1_0/licenses/license.dat.
00:00000:00000:2003/04/08 09:12:43.79 kernel Feature ASE_SERVER is over drafted
273048192 times.
00:00000:00000:2003/04/08 09:12:43.91 kernel Using config area from primary
master device.
00:00000:00000:2003/04/08 09:12:44.36 kernel Kernel memory at address 4202692608
(0xfa800000), size is 55721984 bytes
00:00000:00000:2003/04/08 09:12:44.37 kernel Using 1024 file descriptors.
00:00000:00000:2003/04/08 09:12:44.37 kernel Adaptive Server
Enterprise/12.0.0.1/P/SWR 9264 ESD 3/Sun_svr4/OS 5.6/1629/32bit/FBO/Wed Sep 6
22:14:20 2000
00:00000:00000:2003/04/08 09:12:44.37 kernel Confidential property of Sybase,
Inc.

Server Installation for Sybase 4–9

Preparing the Installation

00:00000:00000:2003/04/08 09:12:44.39 kernel Copyright 1987, 2000

00:00000:00000:2003/04/08 09:12:44.39 kernel Sybase, Inc. All rights reserved.

The output ends with:

00:00000:00001:2003/04/08 09:12:49.72 server Recovery complete.
00:00000:00001:2003/04/08 09:12:49.72 server SQL Server's default sort order is:
00:00000:00001:2003/04/08 09:12:49.72 server 'bin_iso_1' (ID = 50)
00:00000:00001:2003/04/08 09:12:49.72 server on top of default character set:
00:00000:00001:2003/04/08 09:12:49.72 server 'iso_1' (ID = 1).
...

When the output display is complete, press Enter a few times; the command
prompt should reappear.

Start the Event Processor

Before you start the event processor, you must ensure that the TZ environment
variable is set. For more information on the TZ environment, see the section
Time Zone Setting, in this guide.

The event processor references this setting to determine the default time zone.

To start the event processor, enter:

eventor

When eventor is run, you will lose control of the open command prompt
window. To run any other commands while the eventor is running you must
open a new command window. This will let you see the eventor output while
running commands through the second command prompt.

Or:

To start the event processor, enter:

eventor –q

Running eventor –q allows the eventor to run silently, and returns a command
prompt. This will let you manually scroll through the eventor output without
losing the command prompt.

Notes: The eventor script is designed to make sure the environment is in the
right state before starting the event processor; specifically, it ensures that another
event processor is not already running.

4–10 Installation Guide

 Configuring the Installation

Configuring the Installation

The following procedures must be completed before jobs are entered into the
database.

eTrust Access Control

If you installed eTrust AC, you must set your subscriber security word, before
proceeding. For more information on how to set the subscriber security word,
see the section eTrust Access Control in the chapter Security of the Unicenter
AutoSys Job Management for UNIX User Guide.

Define the Exec and Edit Superusers

If you selected not to install eTrust AC, you must establish your EDIT and EXEC
superusers. If you selected to install eTrust, skip this topic.

The exec superuser is the only user who has permission to stop the event
processor. The exec superuser can also start and stop all jobs, regardless of their
ownership or permissions.

The edit superuser is the only user who can change the database password and
remote authentication method, change the owner of a job, or edit any job,
regardless of who owns it.

Notes: Until the exec superuser is defined, the event processor cannot be
properly shut down with a sendevent -E STOP_DEMON command.

To define the exec and edit superusers, execute the autosys_secure program.
When autosys_secure is invoked, the following menu appears:
AutoSys Security Utility.
[1] Administer EDIT and EXEC superusers.
[2] Change AutoSys database password.
[3] Change AutoSys remote authentication method.
[4] Create AutoSys User@Host or Domain password.
[5] Change AutoSys User@Host or Domain password.
[6] Delete AutoSys User@Host or Domain password.
[7] Enable eTrust Access Control
[8] Exit autosys_secure
[A] Get Encrypted Password for Adapters
>

Server Installation for Sybase 4–11

Configuring the Installation

The first time option [1] in the autosys_secure menu is chosen after Unicenter
AutoSys JM is installed, you are given another menu for edit and exec
superusers. Select one of the displayed options to continue. Both these privileges
can be assigned to the same user.

Important! Use caution when assigning edit and exec superuser privileges.
These privileges allow a user to modify behavior and change jobs.
AutoSys EDIT Super-User: autosys
...changed.
AutoSys EXEC Super-User: autosys
...changed.

After the initial assignments, only the edit superuser can change it. Option [1]
displays the current settings and allows the edit superuser to accept the same
users by pressing Enter, or change the users by entering a new specification.

The autosys_secure command is also used to change the database password for
the “autosys” user (the default password is “autosys”) and to enable remote
authentication. These options are explained in autosys_secure in the chapter
“Commands” of the Unicenter AutoSys Job Management for UNIX and
Windows Reference Guide.

Note: Any user with the proper environment can use Unicenter AutoSys JM;
you do not have to log on as the “autosys” user to use Unicenter AutoSys JM.

Verify Remote Agent and Database Accessibility

Use the autoping command to do the following:

■ Verify that the internet demon (inetd) is properly configured.

■ Verify that the remote agent on the server machine is functioning.

■ Check the machine’s database connection. If you are running dual event
servers, autoping checks both databases.

4–12 Installation Guide

 Configuring the Installation

Internet Demon

If you are running NIS or NIS+, this verification is required. If you are not
running NIS or NIS+, the inetd is configured automatically when the installation
script is run; therefore, you can skip this step.

For more information on configuring the inetd, see the chapter Preparing the
Server for Installation, in this guide.

Remote Agent Verification

To verify that the remote agent on the server machine is functional, run the
autoping command. Assuming that the machine’s name is “fiji,” you would
enter:
autoping -m fiji

The following message appears:

AutoPinging Machine [fiji]
AutoPing WAS SUCCESSFUL!

If you do not get this message, the remote agent is not configured properly, and
as a result, Unicenter AutoSys JM cannot start jobs on that machine (even if it is
the same machine as the server).

The remote agent is only executed when a connection is made to a client (that is,
a job is started). Therefore, looking in the process table for the remote agent
executable most likely will not be very informative.

If the remote agent is not installed properly, you can still verify the environment
and install the license keys; however, you will not be able to run a job.

If there is a problem, it is generally due to the improper configuration of the

inetd, a missing or incorrect interfaces file, or an incorrect setting for Sybase in
the configuration file.

If you have any problems, see the topic Remote Agent Troubleshooting in the
chapter “Troubleshooting” in the Unicenter AutoSys Job Management for UNIX
User Guide.

Server Installation for Sybase 4–13

Configuring the Installation

Database Connection Verification

To check the database connection on machine “fiji,” you would type:

autoping -m fiji -D

The following message appears:

AutoPinging Machine [fiji] AND checking the Remote Agent’s DB Access.
AutoPing WAS SUCCESSFUL!

If you do not get this message, the database is not accessible. For troubleshooting
information, see the chapter “Troubleshooting” in the Unicenter AutoSys Job
Management for UNIX User Guide.

Install the License Keys

These keys are generated by the Customer Service department at Computer

Associates. Permanent keys are based on the host name, host ID and
hardware type of the machines on which Unicenter AutoSys JM will run.

If you have not received your keys, contact Computer Associates Technical
Service at supportconnect.com.

You should install your license keys during the configuration of your Unicenter
AutoSys JM environment. However, if you do not install your license keys, you
will still be able to run jobs during the 30 day trial period. During this trial
period and thereafter you will receive license key warning and error messages.

Set up Autotrack

Now would be a good time to set up your desired autotrack tracking level.
autotrack tracks changes to the database (for example, job definition changes,
sendevent calls, and job overrides) and writes this information to the database.
Changes to job definitions made via JIL or the GUI can be tracked. Changes
made directly to the database through SQL commands cannot be tracked.

When you query for this information, autotrack prints a report to the screen, or
you can use standard UNIX file redirection to save the output to a file.

4–14 Installation Guide

 Configuring the Installation

This facility is especially useful for:

■ Sites desiring careful monitoring of the job definition environment.

■ Sites where multiple users have permission to edit job definitions or send
AutoSys events.

The syntax of the command is as follows:

autotrack [-D data_server:database | -D TNSname] [-u 0|1|2] [-l]
[-h|H] [-v] [-F "from_time"] [-T "to_time"] [-U user_name] [-m machine] [-J
job_name] [-t autotrack_type]

Tip: Double quotes are required around the to_time and from_time
arguments.

To start tracking, use the autotrack -u command to set the tracking level to 1 or 2,
depending on the amount of detail you want tracked. By default, autotrack is set
to level 0 (no tracking). Only the exec superuser or edit superuser can change the
tracking level. For a complete description of this command, see the chapter
“Commands” of the Unicenter AutoSys Job Management for UNIX and
Windows Reference Guide.

Server Installation for Sybase 4–15

Testing the Installation

Testing the Installation

After you have configured your installation, test the installation by creating a
test job and verify the Unicenter AutoSys JM environment, you set up
previously.

Create a Test Job

After you have installed the license keys, you will be ready to enter a test job to
verify that the database can be updated. A client key must be installed on any
machine on which you want to run jobs, including the server machine if you
want to run jobs on that machine.

Note: If the instance is being controlled by eTrust AC, then prior to executing
any command line interface or GUI programs ensure the Unicenter AutoSys JM
subscriber security word is set first through running the AutoSys Secure Utility.

For more information on autosys_secure, see the section Commands in the

Unicenter AutoSys Job Management for UNIX and Windows Reference Guide.

A test job called “test_install” is included with this version. The job definition is
in the file named $AUTOSYS/test/jil/test_install. If you view this job definition
in a text editor, you will see the following:
# JIL file to test the installation
# It will write a line to the Output File
insert_job: test_install
machine: localhost
command: /bin/echo “AUTOSYS install test”
std_out_file: /tmp/test_install.out
std_err_file: /tmp/test_install.err

Job definitions are specified using Job Information Language (or JIL). The jil
command is a language processor that parses the language and updates the
database. JIL is documented in the Unicenter AutoSys Job Management for
UNIX User Guide.

4–16 Installation Guide

 Testing the Installation

If your machine is not aliased to localhost, you will have to modify the
“test_install” job to specify your machine’s actual name.

1. Edit $AUTOSYS/test/jil/test_install and modify the line that reads:

machine: localhost

Replace localhost with your machine’s host name, for example:

machine: fiji

2. Save and exit the test_install file.

3. To insert the “test_install” job into the database, enter the following
command at the operating system prompt:
jil < $AUTOSYS/test/jil/test_install

The output should appear as the following:

Insert/Updating Job: test_install
Database Change WAS Successful!
Exit Code = 0

If there is a problem, you will see the following message and some error
messages:
Database change was NOT successful
Exit Code = 1

To run the “test_install” job, an event must be sent to cause the job to start.

4. To send the event to start this job, enter the following (ksh or csh):
sj test_install

This command starts the job “test_install” by using the sj alias that is defined
in the environment file. The sj alias represents the full command line shown
following (which could also be used to start the job, if you do not have the
aliases defined):
sendevent -E STARTJOB -J test_install

The event to start the job is now in the database, but the job itself will not
start until the event processor is up and running.

Server Installation for Sybase 4–17

Testing the Installation

Verify the Test Job

To verify that the job started and ran successfully, monitor the event processor
output log with the following command.
autosyslog -e

If the job ran successfully, the following message will be written to the
/tmp/test_install.out file:
AUTOSYS install test

This indicates that the basic Unicenter AutoSys JM environment is set up

properly.

If the job did not run successfully, you should see an error message indicating a
problem in the /tmp/test_install.err file.

To close the event processor output log, press Ctrl+C.

Verify the Environment and Configuration

After verifying the database is up, testing the database connection, and running
a test job, you need to test navigation through the data server. If this is
accomplished successfully, it confirms that the environment variables needed for
Unicenter AutoSys JM have been set up properly.

To test this, issue the report command as shown following:

autorep -J ALL

The following message appears:

Job Name Last Start Last End ST Run Pri/Xit

If the environment is not set up correctly, some diagnostic messages will be

displayed to inform you of what is incorrect. For troubleshooting information,
see the chapter “Troubleshooting” in the Unicenter AutoSys Job Management for
UNIX User Guide.

If all these steps have completed successfully, you have a properly installed
instance of Unicenter AutoSys JM.

4–18 Installation Guide

Chapter

Client Installation for Sybase

5
This chapter describes the steps for installing the client components of the
application software for Sybase. It contains all the instructions necessary to
install the client for a basic configuration. Information on advanced
configurations are given in the chapter “Advanced Configurations,” in this
guide.

Before you begin the client installation, review the chapter “Preparing for
Installation” in this guide for information about the client configuration required
before Unicenter AutoSys JM can be installed. Also, ensure that the server was
installed successfully and you completed your client checklist. Use the
information from your checklist during the installation.

Note: If you will be using the server machine as a client also—that is, running
jobs and utilities on the server machine—you do not need to install the client
software on the server. The client software is installed during the server
installation.

Client Installation for Sybase 5–1

Client Installation

Client Installation
Unicenter AutoSys JM can use a client machine in several ways. It can be used as
the following:

■ Machine on which to start jobs.

■ Machine to access, control, and monitor (for example, to generate reports,

run monitors, access the GUI, run jil, and so forth).

It is possible to install the client for running jobs only, but it is better to install it
for all of the uses, as described in this chapter. If you want a client machine to
only start jobs, you can select that option during the installation.

The following is an example client checklist that has been filled in for a basic
configuration with bundled Sybase. The information in this checklist will be
used to illustrate the various installation steps.

Client Checklist
Item Description
Platform Sun

Operating system/version Solaris 2.8

Different OS than Unicenter No

AutoSys JM server (y/n)

Host name crete

Host ID 987654yz

Password of root

Installing with bundled Sybase or Bundled Sybase

unbundled Sybase or Oracle

Install CCI Yes

If installing Bundled Sybase on N/A

NCR, OS configuration is required.
Is this completed

Installation directory pathname for /opt/CA/UnicenterAutoSysJM/

Unicenter AutoSys JM (AUTOSYS)

Directory path name for /opt/CA/UnicenterAutoSysJM/autouser

5–2 Installation Guide

 Client Installation

Client Checklist
Item Description
configuration and output files
(AUTOUSER)

Instance name (AUTOSERV) ACE

Install all clients, or jobs only all clients

Non-NIS, NIS, or NIS+ Non-NIS

configuration

Monitor type (color or Color

monochrome)

Name of user who will own files autosys

Sybase Database

Name of data server that will AUTOSYSDB

contain Database (DSQUERY)

Name of Database in data server autosys

Path to Sybase interfaces file /opt/CA/UnicenterAutoSysJM/sadb

(SYBASE)

Name of database user who has sa

been granted both SA and SSO roles

Password of database user who has

been granted both SA and SSO roles

Remote Agent
Full pathname to remote agent /usr/local/bin
executable

Location of the inetd configuration /etc/inetd.conf

file

Name of the remote agent service auto_remote

Port number for the remote agent 5280

For more information about CCI see the appendix “Introducing CCI,” in this
guide.

Client Installation for Sybase 5–3

Preparing the Client Machine

Preparing the Client Machine

Before you begin installing Unicenter AutoSys JM software on the client
machine, you must complete the preparatory procedures described following.

NIS or NIS+ Only: Configure the Internet Demon Services

If you are running NIS or NIS+, this step is required. If you are not running NIS
or NIS+, you can skip this step because the internet demon configuration will be
done for you automatically when the install scripts run.

Unicenter AutoSys JM starts jobs by first connecting to the internet demon on the
client machine where the job is to run. However, if the client machine is running
NIS or NIS+, you must edit the services file, remake the map, and push it out to
all clients, including the clients. Generally, the system administrator manages
this task and should be consulted.

See your system administrator for information on how to push out the services
file when running NIS+. For NIS systems, use the following procedures.

To configure the internet demon services, follow these steps:

1. To change the services file, add the following line to /etc/services on the
server machine:
auto_remote 5280/tcp

The default port number for the remote agent is 5280. If this number is
already in use by another internet service at your site, or if you wish to have
multiple versions of the remote agent installed on the same hardware, you
can change this number. In either case, this number should match the port
number recorded in both your server and client checklists.

Note: The default service name for the remote agent is auto_remote. If
multiple versions are to be run concurrently on the same hardware, the
remote agent service names must be different for each version. In any case,
the remote agent service name must be the same in both the /etc/services
file and the internet demon configuration file (/etc/inetd.conf). For
information, see the chapter “Advanced Configurations,” in this guide.

5–4 Installation Guide

 Loading the Software on the Client Machine

After the /etc/services file has been modified, it must be remade and
pushed out to all clients. To do this for NIS, you would issue commands
similar to the following:
cd /var/yp
make

To see an updated services file from the client’s perspective, log on to the
client and issue the following command:
ypcat services

Note: It is important that these steps are done carefully and successfully. The
primary cause of a job not starting on a client machine is the improper
completion of the steps shown previously. If a client machine that was working
suddenly stops, it is usually because the /etc/services file was modified.

Loading the Software on the Client Machine

These steps assume
/usr/vendor/autotree

is the installation directory into which the directory (AUTOSYS) is to be copied.

To load the version, follow these steps:

1. Log on to the client machine as root.

2. Insert the media into the appropriate device.

3. Mount your CD-ROM following the appropriate steps for your operating
system. For example:
mount -r -t cdfs /dev/rz4c /cdrom

4. Run the installation program as follows:

./install_sybase.sh

Note: The installation appears as a graphical interface if Java 2 runtime is

available in the path with suitable display. Otherwise, the installer uses a menu-
driven terminal window.

Client Installation for Sybase 5–5

Run the Installation Script

Run the Installation Script

The installation script is a Bourne shell script located in the directory:

AUTOTREE/autosys/install

This script creates required directories, configures special files for your
environment, installs runtime procedures, and (for networks that are not NIS or
NIS+) configures the Internet demon.

To run the installation script, do the following:

1. Ensure the SYBASE environment variable is set.

2. If you are not in the install directory, move there by entering:

cd autosys/install

In the following examples, we will follow the recommended file installation,

with both a bundled and an unbundled database.

3. The installation must be done by “root.” If you have not already done so, log
on as “root.”

4. To execute the installation script, enter the following:

./auto_install

Note: By default, output from auto_install and your responses to auto_install’s

prompts are written to a log file named
AUTOTREE/autosys/install/auto_install.log.
To specify a different log file, use the auto_install -f filename option.

Client Installation Scripts

At various points during the installation, you will be asked to verify the
information that has been entered. When asked, you can enter n (no) to go back
and correct any mistakes. At these verification prompts, you can cancel the
installation and start over. The script always asks for confirmation before any
system files are modified.

After the script has been provided with all the information it needs to begin the
installation, a message beginning with the following line is displayed:
All the information needed to install AutoSys has been collected...
Do you wish to proceed? ([y]|n)>

Important! If you confirm at this point, you cannot cancel the installation.

5–6 Installation Guide

 Run the Installation Script

Bundled Sybase

The following option allows you to select either all clients, or jobs only. If you
select “Jobs only,” the machine will be configured to execute jobs only—no
utilities can be used and the other client software (for example, the GUIs) will be
removed at the end of the installation.
Choose the type of client installation.
(1) All clients.
(2) Jobs only.
[1]> Enter

When installing with bundled Sybase, the interfaces file will be created for you.

For more information about CCI, see the appendix “Introducing CCI,” in this
guide.

After installing, the installation script continues with remote agent information,
described in the topic, Remote Agent Installation section in this chapter.

Unbundled Sybase

The following option allows you to select either all clients, or jobs only. If you
select “Jobs only,” the machine will be configured to execute jobs only—no
utilities can be used and the other client software (for example, the GUIs) will be
removed at the end of the installation.
Choose the type of client installation.
(1) All clients.
(2) Jobs only.
[1]> Enter

When installing with an unbundled Sybase data server, the interfaces file must
already exist on the client machine.

For more information about CCI, see the appendix “Introducing CCI,” in this
guide.

After the summary, the installation script continues with remote agent
information, described in the topic, Remote Agent Installation in this chapter.

Remote Agent Installation

Up to this point, you can cancel the installation and start over. If you press Enter,
files will be modified and you will not be able to stop the installation.

Client Installation for Sybase 5–7

Remote Agent Verification

You will see the following message followed by a series of informational

messages describing the progress of the installation:
Continuing installation...

The following two lines of output would appear if you had installed jobs only.
AutoSys client installation for jobs only. Removing additional AutoSys clients...
AutoSys installation is complete.

At this point, this machine is now configured as a client.

Remote Agent Verification

To verify that the remote agent is functional, run the autoping command.
Assuming that the client machine’s name is “crete,” you would enter:
autoping -m crete

The following message appears:

AutoPinging Machine [crete]
AutoPing WAS SUCCESSFUL!

If you do not get this message, the remote agent is not configured properly; and
as a result, AutoSys cannot start jobs on that machine.

The remote agent is only executed when a connection is made to a client (that is,
a job is started). Therefore, looking in the process table for the remote agent
executable most likely will not be very informative.

If the remote agent is not installed properly, you can still verify the environment
and install the license keys; however, you will not be able to run a job.

If there is a problem, it is generally due to the improper configuration of the

internet demon (inetd), a missing or incorrect interfaces file, or an incorrect
setting for Sybase in the configuration file.

If you have any problems, see the topic Remote Agent Troubleshooting in the
chapter “Troubleshooting” in the Unicenter AutoSys Job Management for UNIX
User Guide.

5–8 Installation Guide

 Low-Level Installation Procedures

Low-Level Installation Procedures

The installation script automatically performs the procedures described in this
section. The installation procedures are explained here for reference so you can
make modifications to these settings without rerunning the installation.

Internet Demon Services

Unicenter AutoSys JM uses the internet demon to start up the remote agent on
the client machine. To manually set up a machine to use the internet demon
(inetd), you must perform the steps described following.

Set Up Services

If you are using NIS or NIS+, the services file must be updated on the server, the
map must be remade and pushed out to the client. Generally, the system
administrator manages this task. (For details, see NIS or NIS+ Only: Configure
the Internet Demon Services in this chapter.)

If you are using NIS or NIS+, confirm that the NIS/NIS+ Services are set up
properly, and proceed with Step 2 following.

If you are not using NIS, the services are generally located in the
/etc/services file.

To set up services, follow these steps:

1. As “root,” add the following line to the /etc/services file:

auto_remote 5280/tcp # auto_remote

The default port number for the remote agent is 5280. If this number is
already in use by another internet service at your site, or if you wish to have
multiple versions of the remote agent installed on the same hardware, you
can change this number. In either case, this number should match the port
number recorded in both your server and client checklists.

Note: The default service name for the remote agent is “auto_remote.” If
multiple versions are to be run concurrently on the same hardware, the
remote agent service names must be different for each version. In any case,
the remote agent service name must be the same in both the /etc/services
file and the internet demon configuration file (/etc/inetd.conf). For more
information, see the chapter “Advanced Configurations,” in this guide.

Client Installation for Sybase 5–9

Low-Level Installation Procedures

2. As “root,” edit the file named /etc/inetd.conf and add the following single
line:
auto_remote stream tcp nowait root
/opt/CA/UnicenterAutoSysJM/autosys/bin/auto_remote auto_remote

where:

auto_remote Matches the service name used in the

/etc/services fil

Note: This assumes that auto_remote has been installed in the

/opt/CA/UnicenterAutoSysJM/autosys/bin directory. The auto_remote
service can be installed in any directory. Make sure that the directory, where
auto_remote is installed, is the same as the one specified in that machine’s
inetd.conf file. In addition, this entry assumes that the internet demon uses
the /etc/inetd.conf file for its configuration. You may need to check with
your system administrator to verify this.

3. Send a kill -1 to inetd.

Sometimes, a kill -1 is not sufficient to reset the inetd. If you cannot connect
to the remote agent, you may have to issue a kill -9, then restart inetd. If
necessary, check with your system administrator for assistance.

For HP-UX, enter inetd -k to restart the internet demon.

Sybase Interfaces

For Sybase, there must be an entry in the interfaces file that corresponds to the
data server (in our example, AUTOSYSDB) that will host the database. If this is
not done properly, the remote agent cannot send events back to Unicenter
AutoSys JM.

#AutoSys locates the interfaces file on the client by looking in the

/etc/auto.profile file for a line similar to the following:
#AUTOENV#SYBASE=/usr/home/sybase

The #AUTOENV# string is a special environment descriptor just for the remote
agent, and SYBASE points to the actual directory where the interfaces file
resides. Do not remove this descriptor from the /etc/auto.profile file.

5–10 Installation Guide

 Low-Level Installation Procedures

For more information about the format and contents of the interfaces file, see
Configuring AutoSys for Dual-Event Servers in the chapter “Advanced
Configurations,” in this guide.

Profile Script

Before running the command specified in a command job, Unicenter AutoSys JM

will execute a Bourne shell script. Executing this script is the only way to set up
an environment in which the command will execute.

While the script can be specified at the individual job level, a default script must
be installed on every machine. An example script can be found in the file
$AUTOSYS/install/data/auto.profile. The default script should be copied into
/etc/auto.profile.

The /etc/auto.profile file also contains special descriptors, beginning with

#AUTOENV# which are used exclusively to control the remote agent’s
environment. Do not remove the #AUTOENV# descriptors. These descriptors
are described in the topic Sybase Interfaces in this chapter.

Executables

All the executables in the $AUTOSYS/bin directory must be accessible on the

client machine in order for it to access Unicenter AutoSys JM. They must be
either copied into the machine’s $AUTOSYS/bin directory, or mounted on the
directories where they were originally installed. The remote agent executable
(auto_remote) must reside locally on the client machine.

Client Installation for Sybase 5–11

Low-Level Installation Procedures

User Interface Screens

Unicenter AutoSys JM uses a Motif graphical user interface for all user interface
screens and dialogs. The application defaults file defines the GUI display. The
installation script installs this file in /usr/lib/X11/app-defaults or
/usr/openwin/lib/app-defaults. Consult your system administrator to verify
which directory is used on your system.

To install the GUI files yourself, you must copy the appropriate files for your
type of monitor, based on the following:

■ For a color monitor, you issue the following four commands:

cp $AUTOSYS/install/data/Autosc.co /usr/lib/X11/app-defaults/Autosc
cp $AUTOSYS/install/data/Autocons.co /usr/lib/X11/app-defaults/Autocons
cp $AUTOSYS/install/data/Autocal.co /usr/lib/X11/app-defaults/Autocal
cp $AUTOSYS/install/data/Xpert.co /usr/lib/X11/app-defaults/Xpert

■ For a monochrome monitor, you issue the following four commands:

cp $AUTOSYS/install/data/Autosc.bw /usr/lib/X11/app-defaults/Autosc
cp $AUTOSYS/install/data/Autocons.bw /usr/lib/X11/app-defaults/Autocons
cp $AUTOSYS/install/data/Autocal.bw /usr/lib/X11/app-defaults/Autocal
cp $AUTOSYS/install/data/Xpert.bw /usr/lib/X11/app-defaults/Xpert

5–12 Installation Guide

 Low-Level Installation Procedures

Sun Workstations

For Sun Workstations running OPEN WINDOWS, the directories are different.
The following files should be installed in $OPENWINHOME/lib/app-defaults:
$AUTOSYS/install/data/Autosc.*
$AUTOSYS/install/data/Autocons.*
$AUTOSYS/install/data/Autocal.*
$AUTOSYS/install/data/Xpert.*

Use the following commands (In this example, we are using the files for a color
monitor.):
cp $AUTOSYS/install/data/Autosc.co $OPENWINHOME/lib/app-defaults/Autosc
cp $AUTOSYS/install/data/Autocons.co $OPENWINHOME/lib/app-defaults/Autocons
cp $AUTOSYS/install/data/Autocal.co $OPENWINHOME/lib/app-defaults/Autocal
cp $AUTOSYS/install/data/Xpert.co $OPENWINHOME/lib/app-defaults/Xpert

The GUI screens will run under the OPEN LOOK window manager; however, an
additional key-binding file must be installed for cursor control to work properly.
To do that, enter the following command:
cp $AUTOSYS/install/data/XKeysymDB /usr/lib/X11

If /usr/lib/X11 does not exist, it must be created before XKeysymDB is copied.

For Sun Workstations running OPEN WINDOWS, you should also copy
XKeysymDB to $OPENWINHOME/lib as shown following:
cp $AUTOSYS/install/data/XKeysymDB $OPENWINHOME/lib

Client Installation for Sybase 5–13

 Chapter

Server Installation for Oracle

6
This chapter describes the steps for installing the server components of the
application software for Oracle. It contains all the instructions necessary to
install the server for a basic configuration. Information on advanced
configurations are given in the chapter “Advanced Configurations,” in this
guide.

Before You Begin

You must complete the server configuration and fill in your server checklist
before performing the installation, which is described in the chapter “Preparing
the Server for Installation,” in this guide. Use the information in your completed
checklist during the installation.

Server Installation for Oracle 6–1

Server Installation

Server Installation
The following is an example server checklist has been filled in for a basic
configuration, with an Oracle database. The installation procedures in this
chapter will use the information in this checklist to illustrate the various
installation steps.

Server Checklist
Item Description
Platform Sun

Operating system/version Solaris 2.8

Host name Hawaii

Host ID 1234567ab

Password of root

Available memory (512 MB 512

recommended)

Available disk space (350 MB 4 GB

recommended)

Keys obtained and available (y/n) Yes

Install CCI Yes

Installation directory pathname /opt/CA/UnicenterAutoSysJM/

(AUTOSYS)

Directory path name for /opt/CA/UnicenterAutoSysJM/autouser

configuration and output files
(AUTOUSER)

Instance name (AUTOSERV) ACE

Non-NIS, NIS, or NIS+ configuration Non-NIS

Monitor type (color or monochrome) Color

Name of user who will own files autosys

Installing with bundled Sybase or Oracle

unbundled Sybase or Oracle?

OS configuration required (y/n) Yes

6–2 Installation Guide

 Server Installation

Server Checklist
Item Description
OS configuration completed (y/n) Yes

Oracle Database
Value of ORACLE_HOME /var/opt/oracle

TNS alias name of the data server AUTOSYSDB

containing the tablespaces

TNS alias name configured in Yes

Net8/Oracle Net (y/n)

Name of the data tablespace autodata

Size of the data tablespace (100 MB 100

recommended)

Name of the index tablespace autoindexes

Size of the index tablespace (40 MB 40

recommended)

Value of TNS_ADMIN /etc

Name of temporary tablespace temp

Name of the database user who has SYSTEM

been granted DBA role

Password for database user who has

been granted DBA role

Remote Agent
Full path name to remote agent /opt/CA/UnicenterAutoSysJM/autosys
executable /bin

Location of the inetd configuration /etc

file

Name of the remote agent service auto_remote

Port number for the remote agent 5280

For more information about CCI see the appendix “Introducing CCI,” in this
guide.

Server Installation for Oracle 6–3

Server Installation

Using the Setup Wizard to Extract Unicenter AutoSys JM from the Media

The version media contains executables for Oracle databases. The media also
includes a script for loading the correct files for your platform and a text file
named README that describes the contents of the media.

To load the version, follow these steps:

1. Log on to the server machine as root.

2. Insert the media into the appropriate device.

3. Mount your CD-ROM following the appropriate steps for your operating
system. For example:
mount -r -t cdfs /dev/rz4c /cdrom

4. Run the installation program as follows:

./install_oracle.sh
Setup Wizard/Extracting Specifics.
AutoSys Server (y/n) yes
eTrust Access Control (y/n) yes
eTrust Server (y/n) yes
Admin. Users
Admin. Hosts
Subscribers
Unicenter CCI (y/n)
Installation directory
Remote Hosts
AutoSys Motif GUIs (y/n)
AutoSys Remote Command Service for the Web Interface (y/n)
Installation directory
Port Number
Valid Hosts
Directories

Notes:
The installation appears as a graphical interface if Java 2 runtime is available
in the path with suitable output. Otherwise, the installer uses a menu-driven
terminal window.

In the eTrust client (seosdb), you must specify an admin user that is defined
in the eTrust server (pmdb). If this is not done then client (seosdb) will not
be synchronized with the server (pmdb).

6–4 Installation Guide

 Oracle Setup Confirmation Utility (recon)

After you have extracted the files from the version, run the Oracle confirmation
utility described in the following section to verify that your database
environment is correct for Unicenter AutoSys JM.

To install the version, run the installation script as described in the topic
Running the Install Script in this chapter.

Oracle Setup Confirmation Utility (recon)

Run the recon utility after your database administrator has created tablespaces
(described in Configuring an Existing Oracle Database in the chapter “Preparing
the Server for Installation,” in this guide) but before you run the installation
script. The recon utility checks that your Oracle database environment is
properly configured.

The recon utility is useful even after you have installed Unicenter AutoSys JM to
easily obtain information about your Oracle environment. If you are having
problems running with Oracle, run recon to more quickly diagnose the problem.

The recon utility will not change any settings on your system. Instead, it prints to
the screen the current settings and states whether or not these settings
correspond to what Unicenter AutoSys JM expects. Running this utility before
you install gives you the opportunity to correct Oracle settings, if necessary, and
protects you from a failed installation.

The recon utility analyzes the current user’s Oracle environment and the current
Oracle TNS configuration. For each accessible specified database, recon performs
the following tasks:

■ Checks if “product user profile config” is installed.

■ Checks for system packages, such as stored processes and functions from
catproc.sql.

■ Checks for an existing autosys user.

■ Looks for invalid objects, including publicly accessible objects.

■ Reports on free tablespace.

The output of recon helps to determine what corrective action, if any, should be
taken before proceeding with the installation.

Server Installation for Oracle 6–5

Oracle Setup Confirmation Utility (recon)

Syntax

Recon [-v] [-t tmp_dir] user/password TNS_alias_list

tmp_dir Specifies the temporary directory.

user/password Specifies which user name and password to check. Used for all database access.
If you do not enter a password, you will be asked for it.

TNS_alias_list A space delimited list of TNS alias names of the data servers containing the
tablespaces.

Example

The following example prints verbose information about the Oracle setup:

The output of recon shows the path to, or status of the following:

■ ORACLE_HOME environment variable

■ SQL*Plus binary

■ TWO_TASK environment variable

■ ORACLE_SID environment variable

■ TNS_ADMIN environment variable

The recon utility displays the results of its attempt to log on and inspect the
databases. Specifically, it checks:

■ If the product user profile is configured

■ If system packages (dbms_output, dbms_utility, and so forth) are installed

■ For an existing “autosys” user in the database

■ For invalid objects

6–6 Installation Guide

 Oracle Setup Confirmation Utility (recon)

For free tablespace information, the output will resemble the following:

Tablespace Free Extents Total (KB) Largest (KB)

------------ ------------ ---------- -----------
AUTODATA 1 9258 9258
AUTOINDEXES 3 3688 1990
RBS 2 192 96
SYSTEM 1 10592 10592
TEMP 3 7162 4094
TOOLS 2 1606 1586
USERS 2 1012 992
===================== done =====================

The following example shows the same request with non-verbose output:
recon system/manager AUTOSYSDB

The output of this request is shown following:

Your Oracle user environment appears to be in good shape.
The system TNS configuration file appears to be `etc/tnsnames.ora'.
Your TNS environment appears to be in good shape.

AUTODATA 1 9258 9258

AUTOINDEXES 3 3688 1990
RBS 2 192 96
SYSTEM 1 10592 10592
TEMP 3 7162 4094
TOOLS 2 1606 1586
USERS 2 1012 992

Server Installation for Oracle 6–7

Running the Install Script

Running the Install Script

The installation script is a Bourne shell script located in the
AUTOTREE/autosys/install directory. This script creates required directories,
configures special files for your environment, installs runtime procedures, and
(for networks that are not NIS or NIS+) configures the internet demon.

To run the installation script:

1. Make sure you are logged on as “root”.

2. Ensure the ORACLE_HOME environment variable is set.

3. If you have not changed directories since loading the version, change to the
install directory by entering the following:
cd autosys/install

The install script (auto_install) will ask you for information as it executes,
supplying defaults whenever possible. For the basic configuration, we
recommend that you accept all the defaults.

4. Make sure the Oracle data server is up.

5. Execute the install script as follows:

./auto_install

Note: By default, output from auto_install and your responses to auto_install

prompts are written to a log file named
AUTOTREE/autosys/install/auto_install.log. To specify a different log file, use
the auto_install -f filename option.

If you are using NIS or NIS+, ensure that the steps described in the NIS or NIS+
Only: Configure Internet Demon Services see the section of the chapter,
“Preparing the Server for Installation,” in this guide, have been completed. The
services file must be edited before you can successfully run auto_install.

Note: The AutoSys software is compiled for either Sybase or Oracle prior to
shipment; it is not configurable during installation. The auto_install script prints
out which version you are installing.

6–8 Installation Guide

 Running the Install Script

Sample Server Installation Script

At various points during the installation, you will be asked to verify the
information that has been entered. When prompted, you can enter n (no) to go
back and correct any mistakes. At these verification prompts, you can cancel the
installation and start over.

The script always prompts for confirmation before any system files are modified.

After the script has been provided with all the information it needs to begin the
installation, a message beginning with the following line is displayed:
All the information needed to install AutoSys has been collected...
Do you wish to proceed? ([y]|n)>

Important! If you confirm at this point, you cannot cancel the installation.

Note: TNS_ADMIN specifies the path to the tnsnames.ora file. We highly

recommend that you specify this value to ensure proper communication between
Unicenter AutoSys JM and the database.

After the summary, the installation script continues with remote agent
information, described in the section Remote Agent Information.

Remote Agent Information

Up to this point, you can cancel the installation and start over. If you press Enter,
files will be modified and you will not be able to stop the installation. You will
see the following message followed by a series of informational messages
describing the progress of the installation:
Continuing installation...

If you want to make changes to the installation settings after this point, you can
rerun the installation after completion (see Rerunning the Installation in this
chapter).

At this point, this machine is now configured as an AutoSys server.

Server Installation for Oracle 6–9

Preparing the Installation

Rerunning the Installation

The auto_install script can be run again if necessary.

WARNING! For Oracle server installations, rerunning auto_install will cause the
database objects to be rebuilt; as a result, it will delete all the data that has been
entered into the AutoSys database.

For more information about installing or rebuilding a database, see the chapter
“Advanced Configurations,” in this guide.

Preparing the Installation

Unicenter AutoSys JM is now installed on the server machine on which the
installation script was run. Before continuing with the installation of license
keys, creating exec and edit superusers, and installing on the client machines,
you should test the software you have just installed.

The following procedures bring up the data server and event processor on the
server machine. They also test the connection to the remote agent on the server
machine, to ensure that the installation is successful to this point.

Note: The DNS server must be started before starting Unicenter AutoSys JM.

6–10 Installation Guide

 Preparing the Installation

Time Zone Setting

Before you start the event processor, you must ensure that the TZ environment
variable is set. The event processor references this setting to determine the
default time zone. Jobs with time-based starting conditions that do not specify a
time zone will have their start event scheduled based on the time zone under
which the event processor is running. This time zone is also used to report event
times, using the autorep command.

An example of how to set the TZ variable is shown following:

For C shell:
setenv TZ timezone

For Bourne shell and Korn shell:

TZ=timezone; export TZ

where:

timezone Specifies a valid time zone specification (such as: MST7MDT).

Set Up the Environment

To set up the environment, follow these steps:

1. Log on to the server machine as the owner of Unicenter AutoSys JM (for

example, ‘autosys’).

2. Set up the environment for this user by sourcing the proper file in
AUTOUSER. (Since AUTOUSER is not defined yet, you must enter the full
path.)

In the following examples, “fiji” is the name of the server machine, cd to your
autouser directory, and run the following command for your shell.

If you are running the C shell (csh), enter:

source ./autosys.csh.fiji

If you are running the Bourne shell (sh), enter:

. ./autosys.sh.fiji

If you are running the Korn shell (ksh), enter:

. ./autosys.ksh.fiji

Server Installation for Oracle 6–11

Preparing the Installation

Bundled Sybase Only: Start the Database

If you installed Unicenter AutoSys JM with a bundled database, the auto install
program automatically starts the dataserver. However, if you reboot, or shut
down, the dataserver will be shutdown and you must restart the dataserver
using the following procedures. (For unbundled Sybase users, the data server is
up already.)

If you are using the C or Korn shell, enter:

start_autodb

or:
$SYBASE/ASE-12_0/install/RUN_data server_name

start_autodb is an alias setup in the autosys.csh or autosys.ksh file for bundled

Sybase users only.

If you are using the Bourne shell, enter:

$SYBASE/ASE-12_0/install/RUN_data server_name

The default data server_name is AUTOSYSDB.

As the data server comes up, messages will appear on your screen. These are
messages from the data server. If there are problems, messages will continue to
be output to this window. That is why we recommend that you start the data
server in the console window.

The messages will look something like the following example.

The output begins with:

00:00000:00000:2003/04/08 09:12:43.76 kernel Use license file
/export/home/as45syb/sadb/SYSAM-1_0/licenses/license.dat.
00:00000:00000:2003/04/08 09:12:43.79 kernel Feature ASE_SERVER is over drafted
273048192 times.
00:00000:00000:2003/04/08 09:12:43.91 kernel Using config area from primary
master device.
00:00000:00000:2003/04/08 09:12:44.36 kernel Kernel memory at address 4202692608
(0xfa800000), size is 55721984 bytes
00:00000:00000:2003/04/08 09:12:44.37 kernel Using 1024 file descriptors.
00:00000:00000:2003/04/08 09:12:44.37 kernel Adaptive Server
Enterprise/12.0.0.1/P/SWR 9264 ESD 3/Sun_svr4/OS 5.6/1629/32bit/FBO/Wed Sep 6
22:14:20 2000
00:00000:00000:2003/04/08 09:12:44.37 kernel Confidential property of Sybase,
Inc.
00:00000:00000:2003/04/08 09:12:44.39 kernel Copyright 1987, 2000
00:00000:00000:2003/04/08 09:12:44.39 kernel Sybase, Inc. All rights reserved.

6–12 Installation Guide

 Preparing the Installation

The output ends with:

00:00000:00001:2003/04/08 09:12:49.72 server Recovery complete.
00:00000:00001:2003/04/08 09:12:49.72 server SQL Server's default sort order is:
00:00000:00001:2003/04/08 09:12:49.72 server 'bin_iso_1' (ID = 50)
00:00000:00001:2003/04/08 09:12:49.72 server on top of default character set:
00:00000:00001:2003/04/08 09:12:49.72 server 'iso_1' (ID = 1).
...

When the output display is complete, press Enter a few times; the command
prompt should reappear.

Start the Event Processor

Before you start the event processor, you must ensure that the TZ environment
variable is set. For more information on the TZ environment, see the section
Time Zone Setting, in this guide.

The event processor references this setting to determine the default time zone.

To start the event processor, enter:

eventor

When eventor is run, you will lose control of the open command prompt
window. To run any other commands while the eventor is running you must
open a new command window. This will let you see the eventor output while
running commands through the second command prompt.

Or:

To start the event processor, enter:

eventor –q

Running eventor –q allows the eventor to run silently, and returns a command
prompt. This will let you manually scroll through the eventor output without
losing the command prompt.

Notes: The eventor script is designed to make sure the environment is in the
right state before starting the event processor; specifically, it ensures that another
event processor is not already running.

Server Installation for Oracle 6–13

Configuring the Installation

Configuring the Installation

The following procedures must be completed before jobs are entered into the
database.

eTrust Access Control

If you installed eTrust AC, you must set your subscriber security word, before
proceeding. For more information on how to set the subscriber security word,
see the section eTrust Access Control in the chapter Security of the Unicenter
AutoSys Job Management for UNIX User Guide.

Define the Exec and Edit Superusers

If you selected not to install eTrust AC, you must establish your EDIT and EXEC
superusers. If you selected to install eTrust, skip this topic.

The exec superuser is the only user who has permission to stop the event
processor. The exec superuser can also start and stop all jobs, regardless of their
ownership or permissions.

The edit superuser is the only user who can change the database password and
remote authentication method, change the owner of a job, or edit any job,
regardless of who owns it.

Notes: Until the exec superuser is defined, the event processor cannot be
properly shut down with a sendevent -E STOP_DEMON command.

To define the exec and edit superusers, execute the autosys_secure program.
When autosys_secure is invoked, the following menu appears:
AutoSys Security Utility.
[1] Administer EDIT and EXEC superusers.
[2] Change AutoSys database password.
[3] Change AutoSys remote authentication method.
[4] Create AutoSys User@Host or Domain password.
[5] Change AutoSys User@Host or Domain password.
[6] Delete AutoSys User@Host or Domain password.
[7] Enable eTrust Access Control
[8] Exit autosys_secure
[A] Get Encrypted Password for Adapters
>

6–14 Installation Guide

 Configuring the Installation

The first time option [1] in the autosys_secure menu is chosen after Unicenter
AutoSys JM is installed, you are given another menu for edit and exec
superusers. Select one of the displayed options to continue. Both these privileges
can be assigned to the same user.

Important! Use caution when assigning edit and exec superuser privileges.
These privileges allow a user to modify behavior and change jobs.
AutoSys EDIT Super-User: autosys
...changed.
AutoSys EXEC Super-User: autosys
...changed.

After the initial assignments, only the edit superuser can change it. Option [1]
displays the current settings and allows the edit superuser to accept the same
users by pressing Enter, or change the users by entering a new specification.

The autosys_secure command is also used to change the database password for
the “autosys” user (the default password is “autosys”) and to enable remote
authentication. These options are explained in autosys_secure in the chapter
“Commands” of the Unicenter AutoSys Job Management for UNIX and
Windows Reference Guide.

Note: Any user with the proper environment can use Unicenter AutoSys JM;
you do not have to log on as the “autosys” user to use Unicenter AutoSys JM.

Verify Remote Agent and Database Accessibility

Use the autoping command to do the following:

■ Verify that the internet demon (inetd) is properly configured.

■ Verify that the remote agent on the server machine is functioning.

■ Check the machine’s database connection. If you are running dual event
servers, autoping checks both databases.

Server Installation for Oracle 6–15

Configuring the Installation

Internet Demon

If you are running NIS or NIS+, this verification is required. If you are not
running NIS or NIS+, the inetd is configured automatically when the installation
script is run; therefore, you can skip this step.

For more information on configuring the inetd, see the chapter Preparing the
Server for Installation, in this guide.

Remote Agent Verification

To verify that the remote agent on the server machine is functional, run the
autoping command. Assuming that the machine’s name is “fiji,” you would
enter:
autoping -m fiji

The following message appears:

AutoPinging Machine [fiji]
AutoPing WAS SUCCESSFUL!

If you do not get this message, the remote agent is not configured properly, and
as a result, Unicenter AutoSys JM cannot start jobs on that machine (even if it is
the same machine as the server).

The remote agent is only executed when a connection is made to a client (that is,
a job is started). Therefore, looking in the process table for the remote agent
executable most likely will not be very informative.

If the remote agent is not installed properly, you can still verify the environment
and install the license keys; however, you will not be able to run a job.

If there is a problem, it is generally due to the improper configuration of the

inetd, a missing or incorrect interfaces file, or an incorrect setting for Sybase in
the configuration file.

If you have any problems, see the topic Remote Agent Troubleshooting in the
chapter “Troubleshooting” in the Unicenter AutoSys Job Management for UNIX
User Guide.

6–16 Installation Guide

 Configuring the Installation

Database Connection Verification

To check the database connection on machine “fiji,” you would type:

autoping -m fiji -D

The following message appears:

AutoPinging Machine [fiji] AND checking the Remote Agent’s DB Access.
AutoPing WAS SUCCESSFUL!

If you do not get this message, the database is not accessible. For troubleshooting
information, see the chapter “Troubleshooting” in the Unicenter AutoSys Job
Management for UNIX User Guide.

Install the License Keys

These keys are generated by the Customer Service department at Computer

Associates. Permanent keys are based on the host name, host ID and
hardware type of the machines on which Unicenter AutoSys JM will run.

If you have not received your keys, contact Computer Associates Technical
Service at supportconnect.com.

You should install your license keys during the configuration of your Unicenter
AutoSys JM environment. However, if you do not install your license keys, you
will still be able to run jobs during the 30 day trial period. During this trial
period and thereafter you will receive license key warning and error messages.

Set up Autotrack

Now would be a good time to set up your desired autotrack tracking level.
autotrack tracks changes to the database (for example, job definition changes,
sendevent calls, and job overrides) and writes this information to the database.
Changes to job definitions made via JIL or the GUI can be tracked. Changes
made directly to the database through SQL commands cannot be tracked.

When you query for this information, autotrack prints a report to the screen, or
you can use standard UNIX file redirection to save the output to a file.

Server Installation for Oracle 6–17

Configuring the Installation

This facility is especially useful for:

■ Sites desiring careful monitoring of the job definition environment.

■ Sites where multiple users have permission to edit job definitions or send
AutoSys events.

The syntax of the command is as follows:

autotrack [-D data_server:database | -D TNSname] [-u 0|1|2] [-l]
[-h|H] [-v] [-F "from_time"] [-T "to_time"] [-U user_name] [-m machine] [-J
job_name] [-t autotrack_type]

Tip: Double quotes are required around the to_time and from_time
arguments.

To start tracking, use the autotrack -u command to set the tracking level to 1 or 2,
depending on the amount of detail you want tracked. By default, autotrack is set
to level 0 (no tracking). Only the exec superuser or edit superuser can change the
tracking level. For a complete description of this command, see the chapter
“Commands” of the Unicenter AutoSys Job Management for UNIX and
Windows Reference Guide.

6–18 Installation Guide

 Testing the Installation

Testing the Installation

After you have configured your installation, test the installation by creating a
test job and verify the Unicenter AutoSys JM environment, you set up
previously.

Create a Test Job

After you have installed the license keys, you will be ready to enter a test job to
verify that the database can be updated. A client key must be installed on any
machine on which you want to run jobs, including the server machine if you
want to run jobs on that machine.

Note: If the instance is being controlled by eTrust AC, then prior to executing
any command line interface or GUI programs ensure the Unicenter AutoSys JM
subscriber security word is set first through running the AutoSys Secure Utility.

For more information on autosys_secure, see the section Commands in the

Unicenter AutoSys Job Management for UNIX and Windows Reference Guide.

A test job called “test_install” is included with this version. The job definition is
in the file named $AUTOSYS/test/jil/test_install. If you view this job definition
in a text editor, you will see the following:
# JIL file to test the installation
# It will write a line to the Output File
insert_job: test_install
machine: localhost
command: /bin/echo “AUTOSYS install test”
std_out_file: /tmp/test_install.out
std_err_file: /tmp/test_install.err

Job definitions are specified using Job Information Language (or JIL). The jil
command is a language processor that parses the language and updates the
database. JIL is documented in the Unicenter AutoSys Job Management for
UNIX User Guide.

Server Installation for Oracle 6–19

Testing the Installation

If your machine is not aliased to localhost, you will have to modify the
“test_install” job to specify your machine’s actual name.

1. Edit $AUTOSYS/test/jil/test_install and modify the line that reads:

machine: localhost

Replace localhost with your machine’s host name, for example:

machine: fiji

2. Save and exit the test_install file.

3. To insert the “test_install” job into the database, enter the following
command at the operating system prompt:
jil < $AUTOSYS/test/jil/test_install

The output should appear as the following:

Insert/Updating Job: test_install
Database Change WAS Successful!
Exit Code = 0

If there is a problem, you will see the following message and some error
messages:
Database change was NOT successful
Exit Code = 1

To run the “test_install” job, an event must be sent to cause the job to start.

4. To send the event to start this job, enter the following (ksh or csh):
sj test_install

This command starts the job “test_install” by using the sj alias that is defined
in the environment file. The sj alias represents the full command line shown
following (which could also be used to start the job, if you do not have the
aliases defined):
sendevent -E STARTJOB -J test_install

The event to start the job is now in the database, but the job itself will not
start until the event processor is up and running.

6–20 Installation Guide

 Testing the Installation

Verify the Test Job

To verify that the job started and ran successfully, monitor the event processor
output log with the following command.
autosyslog -e

If the job ran successfully, the following message will be written to the
/tmp/test_install.out file:
AUTOSYS install test

This indicates that the basic Unicenter AutoSys JM environment is set up

properly.

If the job did not run successfully, you should see an error message indicating a
problem in the /tmp/test_install.err file.

To close the event processor output log, press Ctrl+C.

Verify the Environment and Configuration

After verifying the database is up, testing the database connection, and running
a test job, you need to test navigation through the data server. If this is
accomplished successfully, it confirms that the environment variables needed for
Unicenter AutoSys JM have been set up properly.

To test this, issue the report command as shown following:

autorep -J ALL

The following message appears:

Job Name Last Start Last End ST Run Pri/Xit

If the environment is not set up correctly, some diagnostic messages will be

displayed to inform you of what is incorrect. For troubleshooting information,
see the chapter “Troubleshooting” in the Unicenter AutoSys Job Management for
UNIX User Guide.

If all these steps have completed successfully, you have a properly installed
instance of Unicenter AutoSys JM.

Server Installation for Oracle 6–21

Chapter

Client Installation for Oracle

7
This chapter describes the steps for installing the client components of the
application software for Oracle. It contains all of the instructions necessary to
install the client for a basic configuration. Information on advanced
configurations are given in the chapter “Advanced Configurations,” in this
guide.

Before you begin the client installation, review the chapter “Preparing for
Installation,” in this guide, which describes the client configuration required
before Unicenter AutoSys JM can be installed. Also, ensure that the server has
been successfully installed and your client checklist has been filled out. Use the
information in your checklist during the installation.

Note: If you will be using the server machine as a client that is running jobs and
utilities on the server machine, you do not need to install the client software on
the server. The client software is installed during the server installation.

Client Installation for Oracle 7–1

Client Installation

Client Installation
Unicneter AutoSys JM can use a client machine in several ways. It can be used
as:

■ A machine on which to start jobs.

■ A machine to access, control, and monitor Unicneter AutoSys JM.

It is possible to install the client for running jobs only, but it is better to install it
for all of the above uses, as described in this chapter. If you want a client
machine to only start jobs, you can select that option during the installation.

Following is an example client checklist that has been filled in for a basic
configuration with Oracle. The information in this checklist will be used to
illustrate the various installation steps.

Client Checklist
Item Description
Platform Sun

Operating system/version Solaris 2.8

Different OS than Unicneter No

AutoSys JM server (y/n)

Host name maui

Host ID 987654yz

Password of root

Installing with bundled Sybase or Oracle

unbundled Sybase or Oracle

OS configuration required (y/n) No

OS configuration completed N/A

Install CCI Yes

Installation directory path name for /opt/CA/UnicenterAutoSysJM/

Unicneter AutoSys JM (AUTOSYS)

Directory path name for /opt/CA/UnicenterAutoSysJM/autouser

configuration and output files

7–2 Installation Guide

 Client Installation

Client Checklist
Item Description
(AUTOUSER)

Unicneter AutoSys JM instance ACE

name (AUTOSERV)

Install all clients, or jobs only All clients

Non-NIS, NIS, or NIS+ Non-NIS

configuration

Monitor type (color or Color

monochrome)

Name of user who will own autosys

Unicneter AutoSys JM files

Oracle Database
Value of ORACLE_HOME /var/opt/oracle

TNS alias name of the data server AUTOSYSDB

containing the tablespaces

TNS alias name configured in Yes

Net8/Oracle Net (y/n)

Value of TNS_ADMIN, if not /etc

default

Name of temporary tablespace temp

Name of the database user who has SYSTEM

been granted DBA role

Password of database user who has

been granted DBA role

Remote Agent

Full path name to remote agent /usr/local/bin

executable

Location of the inetd configuration /etc/inetd.conf

file

Name of the remote agent service auto_remote

Client Installation for Oracle 7–3

Loading the Software On the Client Machine

Client Checklist
Item Description
Port number for the remote agent 5280

For more information on CCI, see the appendix “Introducing CCI,” in this guide.

Loading the Software On the Client Machine

Follow these steps to load the software from the media to the client machine.
These steps assume /usr/vendor/autotree is the installation directory into
which the Unicneter AutoSys JM directory (AUTOSYS) is to be copied.

These steps assume the installation directory into which the Unicneter AutoSys
JM directory (AUTOSYS) is to be copied is;
/usr/vendor/autotree

To load the version:

1. Log on to the server machine as “root.”

2. Insert the media into the appropriate device.

3. Mount your CD-ROM following the appropriate steps for your operating
system. For example:
mount -r -t cdfs /dev/rz4c /cdrom

4. Run the installation program as follows:

./install_oracle.sh

Note: The installation appears as a graphical interface if Java 2 run-time is

available in the path with a suitable display. Otherwise, the installer uses a
menu-driven terminal window.

After you have extracted the files from the version, run the Oracle confirmation
utility described in the following section to verify that your database
environment is correct for Unicenter AutoSys JM.

To install the version, run the installation script as described in the topic
Running the Install Script in this chapter.

7–4 Installation Guide

 Run the Install Script

Run the Install Script

The installation script is a Bourne shell script located in the
AUTOTREE/autosys/install directory. This script creates required directories,
configures special files for your environment, installs runtime procedures, and
(for networks that are not NIS or NIS+) configures the internet demon.

To run the installation script:

1. Ensure that the ORACLE_HOME environment variable is set. (If Oracle is

not installed on the client machine, set ORACLE_HOME to /tmp.)

2. If you are not in the install directory, move there by entering:

cd autosys/install

In the following example, we will follow the recommended file installation,

with an Oracle database.

3. The installation must be done by “root”; if you have not already done so, log
on as “root.”

4. To execute the install script, enter the following:

./auto_install

Note: By default, output from auto_install and your responses to auto_install’s

prompts are written to a log file named
AUTOTREE/autosys/install/auto_install.log.
To specify a different log file, use the auto_install -f filename option.

Client Installation for Oracle 7–5

Run the Install Script

Client Installation Script

At various points during the installation, you will be asked to verify the
information that has been entered. When prompted, you can enter n (no) to go
back and correct any mistakes. At these verification prompts, you can cancel the
installation and start over.

The script prompts for confirmation before any system files are modified.

After you provide all the information the script needs to begin the installation, a
message that begins with the following line is displayed:
All the information needed to install AutoSys has been collected...
Do you wish to proceed? ([y]|n)>

Important! If you confirm at this point, you cannot cancel the installation.

The following option lets you select either all clients, or jobs only. If you select
“Jobs only,” the machine will be configured to execute Unicneter AutoSys JM
jobs only—no Unicneter AutoSys JM utilities can be used and the other client
software (for example, the GUIs) will be removed at the end of the installation.
Choose the type of client installation.
(1) All clients.
(2) Jobs only.
[1]> Enter

Note: TNS_ADMIN specifies the path to the tnsnames.ora file. We recommend

that you specify this value to ensure proper communication between Unicneter
AutoSys JM and the database.

After the summary, the installation script continues with remote agent
information, described in the topic “Remote Agent Verification,” in this chapter.

7–6 Installation Guide

 Remote Agent Verification

Remote Agent Installation

Up to this point, you can cancel the installation and start over. If you press Enter,
files will be modified and you will not be able to stop the installation. You will
see the following message:
Continuing installation...

This message is followed by a series of informational messages describing the

progress of the installation.

The next two lines of output would appear if you had installed jobs only.
AutoSys client installation for jobs only. Removing additional AutoSys clients...
AutoSys installation is complete.

At this point, this machine is now configured as an Unicneter AutoSys JM client.

Remote Agent Verification

To verify that the remote agent is functional, run the autoping command.
Assuming that the client machine’s name is “maui”, you would type:
autoping -m maui

The following message appears:

AutoPinging Machine [maui]
AutoPing WAS SUCCESSFUL!

If you do not get this message, the remote agent is not configured properly, and
as a result, Unicneter AutoSys JM cannot start jobs on that machine.

The remote agent is only executed when a connection is made to a client (that is,
a job is started). Therefore, looking in the process table for the remote agent
executable most likely will not be very informative.

If the remote agent is not installed properly, you can still verify the environment
and install the license keys; however, you will not be able to run a job.

Client Installation for Oracle 7–7

Remote Agent Verification

If there is a problem, it is generally due to the improper configuration of the

internet demon (inetd) or an incorrect setting for Oracle in the configuration file.

If you have any problems, see the Remote Agent Troubleshooting section in the
chapter “Troubleshooting” in the Unicenter AutoSys Job Management for UNIX
User Guide.

7–8 Installation Guide

 Low-Level Installation Procedures

Low-Level Installation Procedures

The installation script automatically performed the procedures described in this
section. They are explained here for reference so you can make modifications to
these settings without rerunning the installation.

Internet Demon Services

Unicneter AutoSys JM uses the internet demon to start up the remote agent on
the client machine. To manually set up a machine to use the demon (inetd), you
must perform the steps following.

Set Up Services

If you are using NIS or NIS+, the services file must be updated on the server, the
map must be remade and pushed out to the client by the system administrator.
For details see the topic NIS or NIS+ Only: Configure the Internet Demon
Services in this chapter.

If you are using NIS or NIS+, confirm that the NIS/NIS+ services are set up
correctly, and proceed to Step 2.

Note: If you are not using NIS, the services are located in:
/etc/services file

To set up services:

1. As “root,” add the following line to the /etc/services file

Auto_remote 5280/tcp # auto_remote

The default port number for the remote agent is 5280. If this number is
already in use by another internet service, or if you want to have multiple
versions of the remote agent installed on the same hardware, change this
number. In either case this number should match the port number recorded
in both your server and client checklist.

Note: The default service name for the remote agent is auto_remote. If
multiple versions of Unicneter AutoSys JM are to be run concurrently on the
same hardware, the remote agent service names must be different for each
version. Also, the remote agent service name must be the same in both the
/etc/services file and the internet demon configuration file /etc/inetd.conf.

For more information see the chapter “Advanced Configurations,” in this guide.

Client Installation for Oracle 7–9

Low-Level Installation Procedures

2. As “root,” edit the file named /etc/inetd.conf and add the following line:
Auto_remote stream tcp nowait root
/opt/CA/UnicenterAutoSysJM/sutosys/bin/auto_remote auto_remote

where:

auto_remote Specifies the service name used in the /etc/services file.

Note: This assumes that auto_remote has been installed in the

/opt/CA/UnicenterAutoSysJM/autosys/bin directory. The auto_remote
service can be installed in any directory, so make sure that the directory
where it is installed is the same as the one specified in that machine’s
inetd.conf file. This entry assumes that the internet demon uses the
/etc/inetd.conf file for its configuration. Check with your system
administrator for verification of the directory location.

3. Send a kill –1 inetd:

At times a kill –1 is not sufficient to reset the inetd. If you are unable to
connect to the remote agent, you may have to issue a kill –9, then restart
inetd. Check with your system administrator for assistance.

For HP-UX, enter inetd –k to restart the internet demon.

Profile Script

Before running the command specified in a command job, Unicneter AutoSys JM

will execute a Bourne shell script. Executing this script is the only way to set up
an environment in which the command will execute.

While the script can be specified at the individual job level, a default script must
be installed on every machine. An example script can be found in the file
$AUTOSYS/install/data/auto.profile. The default script should be copied into
/etc/auto.profile.

The /etc/auto.profile file also contains special descriptors, beginning with

#AUTOENV# which are used exclusively to control the remote agent’s
environment. Do not remove the #AUTOENV# descriptors.

7–10 Installation Guide

 Low-Level Installation Procedures

Executables

All the executables in the $AUTOSYS/bin directory must be accessible on the

client machine in order for it to access Unicneter AutoSys JM. They must be
either copied into the machine’s $AUTOSYS/bin directory, or mounted on the
directories where they were originally installed. The remote agent executable
(auto_remote) must reside locally on the client machine.

Oracle Environment Settings

For Unicneter AutoSys JM to communicate properly with Oracle, it relies on the

environment settings in the /etc/auto.profile file as shown in the following
sample:
#AUTOENV#TNS_ADMIN=/etc/tnsnames.ora
#AUTOENV#ORACLE_HOME=/var/opt/oracle

where:

#AUTOENV# Indicates a special environment descriptor just for the remote agent.

Important! Do not remove these environment descriptors.

Client Installation for Oracle 7–11

Low-Level Installation Procedures

User Interface Screens

Unicneter AutoSys JM uses a Motif graphical user interface for all user interface
screens and dialogs. The GUI display is defined by the application defaults file.
The installation script installs the application defaults file in:
/usr/lib/X11/app-defaults or /usr/openwin/lib/app-defaults

Consult your system administrator to verify which directory is used on your

system.

To install the GUI files yourself, you must copy the appropriate files for your
type of monitor:

■ For a color monitor, you issue the following four commands:

cp $AUTOSYS/install/data/Autosc.co /usr/lib/X11/app-defaults/Autosc
cp $AUTOSYS/install/data/Autocons.co /usr/lib/X11/app-defaults/Autocons
cp $AUTOSYS/install/data/Autocal.co /usr/lib/X11/app-defaults/Autocal
cp $AUTOSYS/install/data/Xpert.co /usr/lib/X11/app-defaults/Xpert

■ For a monochrome monitor, you issue the following four commands:

cp $AUTOSYS/install/data/Autosc.bw /usr/lib/X11/app-defaults/Autosc
cp $AUTOSYS/install/data/Autocons.bw /usr/lib/X11/app-defaults/Autocons
cp $AUTOSYS/install/data/Autocal.bw /usr/lib/X11/app-defaults/Autocal
cp $AUTOSYS/install/data/Xpert.bw /usr/lib/X11/app-defaults/Xpert

7–12 Installation Guide

 Low-Level Installation Procedures

Sun Workstations

For Sun Workstations running OPEN WINDOWS, the directories are different.
The following files should be installed in $OPENWINHOME/lib/app-defaults:
$AUTOSYS/install/data/Autosc.*
$AUTOSYS/install/data/Autocons.*
$AUTOSYS/install/data/Autocal.*
$AUTOSYS/install/data/Xpert.*

To install the previous files in $OPENWINHOME/lib/app-defaults, use the

following commands (we are using the files for a color monitor as an example):
cp $AUTOSYS/install/data/Autosc.co $OPENWINHOME/lib/app-defaults/Autosc
cp $AUTOSYS/install/data/Autocons.co $OPENWINHOME/lib/app-defaults/Autocons
cp $AUTOSYS/install/data/Autocal.co $OPENWINHOME/lib/app-defaults/Autocal
cp $AUTOSYS/install/data/Xpert.co $OPENWINHOME/lib/app-defaults/Xpert

The GUI screens will run under the OPEN LOOK window manager; however, an
additional key binding file must be installed for cursor control to work properly.
To do that, enter the following:
cp $AUTOSYS/install/data/XKeysymDB /usr/lib/X11

Note: If /usr/lib/X11 does not exist, it must be created before XKeysymDB is

copied.

For Sun Workstations running OPEN WINDOWS, you should also copy
XKeysymDB to $OPENWINHOME/lib.

Client Installation for Oracle 7–13

 Chapter

Advanced Configurations
8
This chapter describes how to install and configure advanced features of
Unicenter AutoSys JM, including installing and configuring high-availability
options and configuring multiple instances for cross-instance job dependencies.
It describes only the configuration file parameters that are used to set these
advanced features. For complete information on the configuration, including a
sample file, see the chapter “Configuring” in the Unicenter AutoSys Job
Management for UNIX User Guide.

The Configuration File

The high-availability options are controlled by parameters in the
$AUTOUSER/config.$AUTOSERV configuration file. Cross-instance
communication is set up in the $AUTOUSER/config.EXTERNAL file.

Each instance has its own configuration file called:

$AUTOUSER/config.$AUTOSERV

The $AUTOSERV value is the name of the instance with which the configuration
file is associated. Upon startup, Unicenter AutoSys JM reads the configuration
file to determine its behavior, including which databases to connect to and how
to react to certain error conditions. Also, the runtime behavior of the event
processor is based on the parameters found in this configuration file.

Advanced Configurations 8–1

Remote Command Service

Remote Command Service

The Remote Command Service (RCS) includes some configurable values and
files including the port number, number of lines to be retrieved from EPLOG,
Valid Hosts and IPs, and Valid Directories.

These parameters can be modified during the installation.

PORT NUMBER
The port on which Unicenter AutoSys Remote Command Service will listen
for remote command requests

The port number default value is:

4444

EPLOG LINES
Number of lines from the Event Processor log to retrieve and return to the
web server when handling an EPLOG request

The eplog lines default value is:

200

Note: After installation the PORT NUMBER and EPLOG LINES values cannot
be modified.

The installation allows the user to configure the VALID HOSTS and IPs and the
VALID DIRECTORIES files for the RCS. In order for the Unicenter AutoSys JM
Web Interface and the RCS to communicate, the hostname for the Unicenter
AutoSys JM Web Interface machine must be entered. In order to view the output
or error file through the Unicenter AutoSys JM Web Interface, the directory path
of the file must be entered.

After installation, the VALID HOST and IPs file and the VALID DIRECTORIES
file can be modified by editing the validips and valid_dirs files.

The files are by default located in the RCS data directory:

/opt/CA/SharedComponents/UnicenterAutoSys/data

8–2 Installation Guide

 Remote Command Service

VALID HOSTS and IPs

After the installation, you may add or remove valid machines by modifying
the validips. Open the file with a text editor and add an IP address or the
hostname of the AutoSys JM Web Interface machine to the list. RCS only
accepts requests from the machines listed in validips

Example validips file entries:

127.0.0.1
autosys
autosys-win32
146.124.55.132

VALID DIRS
The valid_dirs file contains a list of valid directories that the RCS uses to find
an output or error file from a job that has run successfully. To view a job log
through the Web Interface, the directory path of the output or error file must
be specified in this file.

Example valid_dirs file entries:

/tmp
/home/autosys/logs

The valid directory refers to the directory that contains the standard output
or error file that was specified in the job definition.

Example job definition using output or error file:

insert_job: example
machine: localhost
command: dir
std_out_file: /tmp/dir.out
std_err_file: /tmp/dir.err

For a user to view the output from the preceding job using the Web
Interface, the directory, /tmp must be specified as a valid directory. When
trying to view a log in which the directory is not an entry in the valid_dirs
file, the request will fail the Web Interface will display a message saying the
directory is not valid.

Note: RCS must be restarted after any modifications are made to either one
of these two files.

Starting and Stopping

RCS is started and stopped through the start_rcs and stop_rcs scripts located in
the autosys/bin directory.

Both start_rcs and stop_rcs must be run as root.

Advanced Configurations 8–3

Remote Command Service

Logging

All RCS messages including Unicenter AutoSys JM Web Interface requests and
errors are written to the RCS logfile, asrcslsn.log. These messages are useful for
viewing when a job may have been added, modified or deleted from the Event
Server, when a web user mapping is performed, or an EP or Joblog request is
issued through the Unicenter AutoSys JM Web Interface. This logfile can also be
used for troubleshooting. For example; a user trying to add a job through an
unknown Unicenter AutoSys JM Web Interface (web interface machine is not
listed as a valid machine in the validips configuration file). In this example, the
RCS log will inform the user which Unicenter AutoSys JM Web Interface
machine must be added to the validips configuration file.

Daily at midnight, the RCS logfile rolls over and the previous day's file is
renamed to asrcslsn.previous_date. A new logfile is then created to receive the
new (current) day’s messages. Since there is a unique RCS logfile for each day, it
is suggested regular maintenance be performed on the logfiles to ensure the
availability of disk space.

On UNIX, the logfiles are located at the following:

/opt/CA/SharedComponents/UnicenterAutoSys/logfiles

Debugging

When a problem occurs, RCS can write more specific system debug information
to the logfile. This is controlled through the system environment variable:
RCSDEBUG

To have RCS write this information to the log file, the value must be set to 1.

Set and export the variable using the syntax of your current shell.

Example bash shell:

RCSDEBUG=ON
export RCSDEBUG

8–4 Installation Guide

 Installing Dual-Event Servers

Installing Dual-Event Servers

One way that Unicenter AutoSys JM provides high-availability is by running
with two databases, or event servers. (The other way is by using a shadow event
processor, discussed in Installing a Shadow Event Processor in this chapter.)
When running in dual-server mode, Unicenter AutoSys JM keeps the two
databases synchronized and provides complete recovery when one of the servers
becomes unusable, disabled, or corrupted. These two event servers contain
identical information, including job definitions and events.

When processing events, the event processor reads from both event servers. If it
detects an event on one server and not on the other, it will copy the missing
event to the other server. In addition, the remote agent writes events to both
event servers.

To run in dual-server mode, you must add a second event server (database). The
event servers should run on different machines to prevent a single point of
failure.

For information on running with dual-event servers, see the chapter

“Introduction,” in this guide. For information on event server rollover recovery,
see Event Server Rollover Recovery in the chapter “Maintaining” in the
Unicenter AutoSys Job Management for UNIX User Guide.

Notes on Installing Dual-Event Servers

If you are using bundled Sybase databases, you can install two databases and
modify the appropriate configuration parameters. If you are using unbundled
databases, you need to install and configure the two databases before you can
use them. Then, you can set the appropriate configuration parameters.

When installing and configuring dual-event servers, consider the following:

■ With dual-server mode, both databases must be of the same type (that is,
both Sybase or both Oracle).

■ You must purchase a server license for each server.

■ The two event servers should reside on two different database servers,
running on different machines, to avoid a single point of failure.

■ The event processor will not start unless it can connect to both databases.

Advanced Configurations 8–5

Installing Dual-Event Servers

Overview of Dual-Server Installation

To implement dual-event servers:

1. Do one of the following:

■ For bundled Sybase, you can install two servers following the
instructions in the chapter “Server Installation for Sybase,” in this guide.
If you are currently running in single server mode, copy your installed
bundled data server to a different machine and change its name, as
described in Copying Bundled Sybase following.

■ For Oracle or unbundled Sybase, install event servers on two different

machines, as described in the Installing Unbundled Sybase or Installing
Oracle sections in this chapter.

2. Synchronize the two data servers, as described in the Synchronizing the

Event Servers section in this chapter.

3. Configure Unicenter AutoSys JM to run with dual-event servers, as

described in the Configuring for Dual-Event Servers section in this chapter.

These steps are explained in this chapter for either a Sybase or an Oracle
database.

Copying Bundled Sybase

Bundled Sybase users who want to move from single-server to dual-server mode
should copy their installed bundled data server to a different machine and
change its name.

8–6 Installation Guide

 Installing Dual-Event Servers

Event Servers on the Same Operating System

If the two machines have the same operating system, copy the software as
explained following.

To copy the software:

1. Create a new directory for the second data server, like:

mkdir /usr/vendor/autotree/sadb2

2. If $AUTOSYS/sadb is NFS-mounted on the second machine, copy the

existing data server directly into the new directory, for example:
cp -r /usr/vendor/autotree/sadb/* /usr/vendor/autotree/sadb2

Notes:
■ We recommend that the Sybase directory be local to the machine where
the second event server is to be run.

■ If the server installation directory is not visible on the second data server
machine, you need to log on to the second data server and perform two
remote copies. In the example following, fiji is the host name of the first
data server machine (the second command copies the auto_db_rename
script):
rcp -r fiji:/usr/vendor/autotree/sadb/ /usr/vendor/autotree/sadb2
rcp -r fiji:/usr/vendor/autotree/autosys/
install/usr/vendor/autotree/autosys/install

If your system does not support the rcp command, use another command
such as cp -r or tar.

3. Set the SYBASE environment variable to the location of the new data server,
like:
setenv SYBASE /usr/vendor/autotree/sadb2

or:
SYBASE=/usr/vendor/autotree/sadb2; export SYBASE

4. Change the name of the second data server from AUTOSYSDB to a different
name, such as AUTOSYSDB2, using the auto_db_rename script, like:
cd $AUTOSYS/install
./auto_db_rename

5. Configure the database as described in Configuring for Dual-Event Servers

in this chapter.

6. Synchronize the databases as described in Synchronizing the Event Servers

in this chapter.

Advanced Configurations 8–7

Installing Dual-Event Servers

Event Servers on Different Operating Systems

If the two machines do not have the same operating system, you must load the
data server from the media. The version media contains executables complied for
all supported platforms for the database you requested (Sybase or Oracle). The
media also includes a script for loading the correct files for your platform and a
text file named README that describes the contents of the media.

These steps assume /usr/vendor/autotree is the installation directory into

which the directory (AUTOSYS) is to be copied.

1. Log on to the client machine as “root.”

2. Insert the media into the appropriate device.

3. Change to the directory in which you will be installing the software, like:
cd /usr/vendor/autotree

4. Extract the version from the media.

For CD-ROM, mount your CD-ROM following the appropriate steps for
your operating system. For example:
mount –r –t cdfs /dev/rz4c /cdrom

Next, copy as_load.sh from the cdrom to the location where you want to
install Unicenter AutoSys JM. If as_load.sh is not executable, change its
permissions and run as_load from the cdrom. Usage:
./as_load.sh cdrom directory

5. The load script presents a numbered list of supported platforms. Enter the
number corresponding to the platform on which you want to install
Unicenter AutoSys JM. The load script extracts the appropriate files for the
chosen platform.

6. Set the SYBASE environment variable to the location of the new data server,
like:
setenv SYBASE /usr/vendor/autotree/sadb2

or:
SYBASE=/usr/vendor/autotree/sadb2; export SYBASE

8–8 Installation Guide

 Installing Dual-Event Servers

7. Change the name of the second data server, for example, from AUTOSYSDB
to AUTOSYSDB2, using the auto_db_rename script, like:
cd $AUTOSYS/install
./auto_db_rename

8. Configure the database as described in Configuring for Dual-Event Servers

in this chapter.

9. Synchronize the databases as described in Synchronizing the Event Servers

in this chapter.

Installing Unbundled Sybase

To install a second unbundled Sybase event server on a machine that does not
have Unicenter AutoSys JM installed on it:

1. Install the unbundled Sybase on the machine and configure it as described in

Configuring an Existing Unbundled Sybase Database in the chapter
“Preparing the Server for Installation,” in this guide making sure to keep the
database size the same as your original database.

2. Run the installation script to install Unicenter AutoSys JM.

3. Synchronize the databases as described in Synchronizing the Event Servers

in this chapter.

To install a second unbundled Sybase event server on a machine that already has
Unicenter AutoSys JM installed:

1. Install the unbundled Sybase on the machine and configure it as described in

Configuring an Existing Unbundled Sybase Database in the chapter
“Preparing the Server for Installation,” in this guide making sure that the
following is true:

■ The server name is different.

■ The database size is the same as your original database.

2. If you have not already done so, source the appropriate environment
variables. For details, see Environment in the chapter “Introduction,” in this
guide.

Advanced Configurations 8–9

Installing Dual-Event Servers

3. Load the database objects as described following (instead of running the

installation script):

a. Change to the $AUTOSYS/install directory by entering this:

cd $AUTOSYS/install

b. Into a new, empty database, load the database objects by issuing the
following command:
./auto_dbobj data_srvr sa_usr sa_pass db_name E

where:

data_srvr Indicates the name assigned to the new data server.

sa_usr Indicates the database system administrator user.

sa_pass Indicates the database system administrator’s password. If you do not know
this password, check with your database administrator.

db_name Indicates the name of the new database or tablespace.

E Indicates the server type (event server).

4. Configure the database as described in Configuring for Dual-Event Servers

in this chapter.

5. Synchronize the database as described in Synchronizing the Event Servers in

this chapter.

8–10 Installation Guide

 Installing Dual-Event Servers

Installing Oracle

To install a second Oracle event server on a machine that does not have
Unicenter AutoSys JM installed on it:

1. Install the Oracle database on a machine and configure it as described in

Configuring an Existing Oracle Database in the chapter “Preparing the
Server for Installation,” in this guide making sure that the following is true:

■ The Oracle TNS alias is different.

■ The names and sizes of the tablespaces are the same as the first database.

2. Run the installation script to install Unicenter AutoSys JM.

3. Synchronize the databases as described in Synchronizing the Event Servers

this chapter.

To install a second Oracle event server on a machine that already has Unicenter
AutoSys JM installed:

1. Install the Oracle database on the machine and configure it as described in

Configuring an Existing Oracle Database in the chapter “Preparing the
Server for Installation,” in this guide making sure that the following is true:

■ The Oracle instance name is different.

■ The database size is the same as your original database.

2. If you have not already done so, source the appropriate environment
variables. (For details, see the section Environment in the chapter
“Introduction,” in this guide.)

Advanced Configurations 8–11

Installing Dual-Event Servers

3. Load the database objects as described following (instead of running the

installation script):

a. Change to the $AUTOSYS/install directory by entering:

cd $AUTOSYS/install

b. Load the database objects by issuing the auto_dbobj command,

described following:
./auto_dbobj Server DBA_Username DBA_Password Data_Tablespace
Index_Tablespace Temp_Tablespace E

where:

Server TNS alias name for the Oracle database.

DBA_Username Indicates the username of a user with DBA privileges.

DBA_Password Indicates the password for the DBA_Username you entered.

Data_Tablespace Indicates the name of the data tablespace. The default value is AUTODATA.

Index_Tablespace Indicates the name of the index tablespace. The default value is
AUTOINDEXES.

Temp_Tablespace Indicates the name of the temporary tablespace. The default value is TEMP.

E Indicates the server type (event server).

4. Configure the database as described in Configuring Oracle in this chapter.

5. Synchronize the databases as described in Synchronizing the Event Servers

in this chapter.

8–12 Installation Guide

 Installing Dual-Event Servers

Configuring for Dual-Event Servers

Configuring Sybase

To configure for dual Sybase event servers

1. Modify the configuration file so that it points to two databases. Edit the
$AUTOUSER/config.$AUTOSERV file using any text editor.

In single server mode, there is only one event server listed in the
configuration file. A typical Sybase single server mode setting is:
# Specify the Databases
#
EventServer=AUTOSYSDB:autosys
# Sybase database example
#EventServer=SYBSERVER2:autosys

For example, assume you are working with the following setup:

■ The first event server has DSQUERY=AUTOSYSDB

■ The second event server has DSQUERY=AUTOSYSDB2

Both of these event servers use the database called “autosys.”

In this scenario, you would modify the configuration file to add a line to
define the second event server, like:
EventServer=AUTOSYSDB:autosys
EventServer=AUTOSYSDB2:autosys
# Sybase database example
#EventServer=SYBSERVER2:autosys

There must not be a comment character (#) at the beginning of the line that
defines the second event server.

Advanced Configurations 8–13

Installing Dual-Event Servers

2. In the $AUTOUSER/config.$AUTOSERV file, define the desired database

reconnect/rollover behavior. The DBEventReconnect parameter sets this
behavior, the default setting:
# Number of times for Event Processor to attempt
# to Reconnect to Event Servers
#
DBEventReconnect=50
#
# USE the following for Dual DataBases
# DBEventReconnect=50,5

By default, the reconnect/rollover behavior is set up for single server mode.

For dual-server mode, use the DBEventReconnect parameter that consists of
two values describing the connection and rollover behaviors.

Place a comment character (#) at the beginning of the line used for single
server mode, like:
# DBEventReconnect=50

Remove the comment character (#) from the beginning of the line used for
Dual-Server Mode, like:
DBEventReconnect=50,5

The default setting for dual-server mode specifies that the event processor
should attempt five connections with the event servers. If after five times it
cannot connect, it should rollover to single server mode, marking the other
event server as “down.” Once in single server mode, the event processor
should attempt a connection fifty times, and if it is unsuccessful, the event
processor shuts down.

Similarly, upon start up, the event processor makes five attempts to connect
to the event servers, and if unsuccessful, it will immediately rollover to
single server mode, using the event server that is still functioning.

3. Save and exit the $AUTOUSER/config.$AUTOSERV file.

8–14 Installation Guide

 Installing Dual-Event Servers

4. Next, you need to modify the interfaces files on all server and client
machines so that it has entries for both event servers.

On some platforms such as Solaris, the format of the interfaces file may look
like this, with entries for data servers residing on machines named fiji and
bermuda:
#
# AUTOSYSDB on fiji (192.9.100.90) using tcp
# services: query (6324) master (6324)
# console (6325)
#

AUTOSYSDB
query tli tcp /dev/tcp x:00>218b4c009645a
master tli tcp /dev/tcp x:00>218b4c009645a
console tli tcp /dev/tcp x:00>218b5c009645a
#
#
# AUTOSYSDB2 on bermuda (192.9.100.91) using tcp
# services: query (6324) master (6324)
# console (6325)
#
AUTOSYSDB2
query tli tcp /dev/tcp x:00>218b4c009645b
master tli tcp /dev/tcp x:00>218b4c009645b
console tli tcp /dev/tcp x:00>218b5c009645b

On other platforms, a typical interfaces file looks like the following example.
This example is for an AIX machine:
AUTOSYSDB
query tcp sun-ether fiji 6324
master tcp sun-ether fiji 6324
console tcp sun-ether fiji 6325

AUTOSYSDB2
query tcp sun-ether bermuda 6324
master tcp sun-ether bermuda 6324
console tcp sun-ether bermuda 6325

Note: In the interfaces file, a single tab must precede the first word of every line;
do not use spaces. A single space is used to delimit each element in an entry line.
Incorrect formatting will prevent communication with the database.

If the client and server machines have different operating systems and different
interfaces file formats, they cannot be directly copied from one to another. To
update the interfaces files on Solaris, Sequent, and NCR machines, use the autotli
command.

The autotli command creates an interfaces file data server entry and writes the
output to standard output. As a result, you can redirect this output to create
either a new interfaces file, or append an existing one.

Advanced Configurations 8–15

Installing Dual-Event Servers

The command following will add the AUTOSYSDB2 data server entry for
machine named “bermuda” and append it to an existing interfaces file. It can be
executed using C shell or Korn shell (the AUTOSYS variable must be set
already):
$AUTOSYS/install/autotli -s AUTOSYSDB2 -h bermuda - p6324 >> $SYBASE/interfaces

where:

-s AUTOSYSDB2 Specifies the name of the data server.

-h bermuda Specifies the host name.

- p6324 Specifies the data server port.

>> Appends the information to the $SYBASE/interfaces file. (Be sure to use two
redirect symbols ( >> ); a single redirect ( > ) symbol will overwrite the existing
file.)

8–16 Installation Guide

 Installing Dual-Event Servers

Configuring Oracle

Configure for dual Oracle event servers, with the following:

1. Modify the configuration file so that it points to two databases. Edit the
$AUTOUSER/config.$AUTOSERV file using any text editor.

In single server mode, there is only one event server listed in the
configuration file. A typical Oracle single server mode setting is:
# Specify the Database(s)
#
EventServer=AUTOSYSDB
# EventServer=AUTOSYSDB:autosys
# Sybase database example
#EventServer=SYBSERVER2:autosys
# Oracle database example
#EventServer=ORASERVER2

For example, assume you are working with the following setup:

■ The first event server has a TNS alias of AUTOSYSDB.

■ The second event server has a TNS alias of AUTOSYSDB2.

In this scenario, you would modify the configuration file to add a line to
define the second event server, like this (the added line is in bold font):
EventServer=AUTOSYSDB
EventServer=AUTOSYSDB2

There must not be a comment character (#) at the beginning of the line that
defines the second event server.

When Unicenter AutoSys JM was installed, tablespaces were made the

default tablespaces of the “autosys” user; therefore, the tablespaces do not
have to be explicitly defined in the previous configuration file entries.

Advanced Configurations 8–17

Installing Dual-Event Servers

2. In the $AUTOUSER/config.$AUTOSERV file, define the desired database

reconnect/rollover behavior. The DBEventReconnect parameter sets this
behavior, and this is the default setting:
# Number of times for Event Processor to attempt
# to Reconnect to Event Servers
#
DBEventReconnect=50
#
# USE the following for Dual DataBases
# DBEventReconnect=50,5

By default, the reconnect/rollover behavior is set up for single server mode.

For dual server mode, use the DBEventReconnect parameter that consists of
two values describing the connection and rollover behaviors.

Place a comment character (#) at the beginning of the line used for single-
server mode, like:
# DBEventReconnect=50

Remove the comment character (#) from the beginning of the line used for
dual-server mode, like:
DBEventReconnect=50,5

The default setting for dual server mode specifies that the event processor
should attempt five connections with the event servers. If a connection is not
successful after five attempts, the event processor should rollover to single
server mode, marking the other event server as “down.” Once in single
server mode, the event processor should attempt a connection 50 times, and
if it is unsuccessful, the event processor shuts down.

Similarly, upon start up, the event processor makes five attempts to connect
to the event server, and if unsuccessful, it will immediately rollover to single
server mode, using the event server that is still functioning.

3. Save and exit the $AUTOUSER/config.$AUTOSERV file.

8–18 Installation Guide

 Installing Dual-Event Servers

Synchronizing the Event Servers

The second event server must be synchronized with the first server before you
can begin processing using dual-server mode. This section describes this process.
These instructions apply to both Sybase and Oracle.

This synchronization procedure is also used if Unicenter AutoSys JM has rolled

over into single-server mode due to problems, and you want to return to
running with dual-event servers.

Stop the Event Processor

Before you synchronize the databases, make sure that no one is creating or
editing job definitions (either through jil or the GUI dialogs), then stop the event
processor, as shown in the following command (you must be the exec superuser
to do this):
sendevent -E STOP_DEMON

After the event processor is stopped, no additional jobs will be started.

Run the autobcp Script

Use the autobcp script to synchronize data servers on different machines to

prepare them for dual-server mode. This script creates two identical servers
based on the source data server.

The autobcp usage statement is as follows (this command is to be entered on a

single line):
autobcp source_server target_server dump_file autosys_password [source_db_name
target_db_name]

where:

source_server Indicates the name of the source Sybase data server or Oracle instance.

target_server Indicates the name of the target Sybase data server or Oracle instance.

dump_file Indicates the name of the temporary dump file.

autosys_password Indicates the “autosys” user password. By default, this is “autosys,” but you
could have changed this password using the autosys_secure command.

Advanced Configurations 8–19

Installing Dual-Event Servers

source_db_name Indicates the name of the source Sybase or Oracle database. If omitted, this
defaults to “autosys.”

target_db_name Indicates the name of the target Sybase or Oracle database. If omitted, this
defaults to “autosys.”

Before running the autobcp script, verify the following:

■ The AUTOSYS environment variable is correctly set.

■ The required database information is correctly set.

For Sybase: The SYBASE environment variable must be set and the
$SYBASE/interfaces file must contain entries for both the source
(AUTOSYSDB) and the target (AUTOSYSDB2) data servers.

For Oracle: The ORACLE_HOME environment variable must be set and the
TNS names file must contain valid entries for both the source and target data
servers.

■ There is sufficient disk space for the autobcp temporary output file.

■ Both data servers are running.

■ No one is executing JIL or using the GUI dialogs to change job definitions.

■ The event processor is not running.

For this example, assume that a new, target data server named AUTOSYSDB2 is
to be synchronized with an existing, source data server named AUTOSYSDB. For
your own process, substitute your own data server names. This example also
assumes the source and target database names are the default “autosys,” and
therefore do not have to be specified in the command.
$AUTOSYS/install/autobcp AUTOSYSDB AUTOSYSDB2 \
/tmp/dumpfile autosys | tee /tmp/autobcp.out

where:

AUTOSYSDB Indicates the name of the source Sybase data server or Oracle instance.

AUTOSYSDB2 Indicates the name of the target Sybase data server or Oracle instance.

/tmp/dumpfile Indicates the name of the temporary dump file

8–20 Installation Guide

 Installing Dual-Event Servers

autosys Indicates the “autosys” user password.

tee Indicates the command used to create a record of the autobcp output. It is
/tmp/autobcp.out recommended that you use the tee command to record the output of autobcp.

While autobcp is running, for each table in the target server, you will see autobcp
perform these steps:

1. Dump the table in the source data server to the output file you specified.

2. Delete the current data from the table in the target data server.

3. Load the data from the output file to the table in the target data server.

4. Dump the transaction log in the target data server (for Sybase only).

When autobcp has completed, you will see the following line:
"autobcp:Complete"

At this point, you can start the event processor.

Start the Event Processor

Bring up the event processor on the event processor machine using this
command:
eventor

If you are using a shadow event processor, use the following command to start
both the primary and shadow event processors:
eventor -M shadow_machine

The event processor should print a message indicating that it is in dual-server

mode.

The event processor marks both event servers as being in dual-server mode.
Client processes and commands check the flags in both event servers for
consistency. Therefore, it is imperative that you start the event processor before
you run any other commands.

Note: If Unicenter AutoSys JM is configured to run in dual server mode, the

event processor will not start unless both databases are available.

Advanced Configurations 8–21

Installing Dual-Event Servers

It is safe to run the autobcp script while jobs are running on client machines. In
the worst case, some events on the first event server may not be written to the
second event server. This is not a problem because the event processor always
reads from both event servers. If it finds an event on one server that is not on the
other, the event server copies the missing event to the appropriate event server.

If one server misses an event due to recovery or spurious network problems, this
feature also dynamically synchronizes both servers.

8–22 Installation Guide

 Installing a Shadow Event Processor

Installing a Shadow Event Processor

The event processor interprets and processes the events it reads in the event
server. The event processor schedules and starts jobs. If you run Unicenter
AutoSys JM with a shadow event processor, the shadow event processor will
take over interpreting and processing events if the primary event processor fails.
For information on running Unicenter AutoSys JM with a shadow event
processor, see the chapter “Introduction,” in this guide.

Notes on Installing a Shadow Event Processor

When installing a shadow event processor, consider the following:

■ The primary and shadow event processors and the third machine must all be
installed on the same type of machine, either UNIX or Windows.

■ Both event processor machines require installed event processors and remote
agents and valid server licenses.

■ The third machine requires an installed remote agent and a valid client
license.

■ The user who starts the event processor (the edit superuser) must have
accounts on all three machines.

■ Ensure that the configuration parameters are identical for both the primary
and shadow event processor machines (since the primary and shadow event
processors are typically installed on separate machines, and with separate
file systems for AUTOSYS and AUTOUSER). On UNIX, the
config.$AUTOSERV configuration file on both the primary and shadow
machines must contain identical settings for the third machine parameter.

■ Ensure that the primary and shadow event processor machines have all the
Unicenter AutoSys JM software, the AUTOSYS directories, as well as the
AUTOUSER directories, mounted locally. Otherwise, a problem with a file
server could stop both event processors.

Advanced Configurations 8–23

Installing a Shadow Event Processor

Installation Steps

To install a shadow event processor:

1. Perform a server installation on the machine where the shadow event

processor will run.

The management of both processors will be easier to maintain if the absolute

names of AUTOSYS and AUTOUSER are the same on both machines.

If these values are different, the /etc/auto.profile file must be edited on the
shadow machine, with the correct entries defined and exported. For
example, assume these are the values of AUTOSYS and AUTOUSER on the
shadow event processor machine:
/usr/vendor/autotree/autosys
/usr/vendor/autotree/autouser

Then, the /etc/auto.profile file would have the following entries:

AUTOSYS=/usr/vendor/autotree/autosys
export AUTOSYS
AUTOUSER=/usr/vendor/autotree/autouser
export AUTOUSER

Note: The primary and shadow event processors must be on the same
platform, either UNIX or Windows.

2. Install the remote agent on the third machine. To do this, perform a client
installation.

The third machine functions as a safeguard that prevents both event

processors from processing events at the same time.

Note: The third machine must have a remote agent installed on it, and it
must have a valid client license. In addition, the third machine must be
installed on the same type of machine on which the primary and shadow
event processors are installed, either Windows or UNIX.

3. Edit the configuration file on both the primary and shadow machines to
specify the name of the third machine. For example, for a third machine host
named “kodiak,” enter this in the configuration file on both the primary and
shadow machines:
ThirdMachine=kodiak

Note: The configuration files, $AUTOUSER/config.$AUTOSERV, must be

identical for both the primary and shadow machines. If they are not
identical, the primary and shadow event processor will not behave the same.

8–24 Installation Guide

 Installing a Shadow Event Processor

4. To start the primary and the shadow event processors simultaneously, enter
the following command on the primary event processor machine:
eventor -M shadow_machine

Note: If you try to start the primary and shadow event processors without
having a third machine specified in the configuration file, the shadow event
processor will not start.

Restoring the Primary Event Processor

To restore the primary event processor, which is down, after the shadow event
processor has taken over, you must stop the shadow event processor, and then
restart the primary.

Stop the event processor properly:

1. Log on as the exec superuser.

2. Issue the following command:

sendevent -E STOP_DEMON

This method allows the event processor to complete whatever processing it is

performing.

Restart the primary and the shadow event processor:

Issue the following command:

eventor -M shadow_machine

Advanced Configurations 8–25

Installing Multiple Instances

Installing Multiple Instances

You can install multiple instances of Unicenter AutoSys JM. Different instances
can run from the same executables and can have the same values for AUTOSYS
and AUTOUSER, both on the event processor machine and on remote agent
machines. However, each instance must have a unique value for AUTOSERV,
and each must have its own database (event server).

If you are installing multiple instances on UNIX machines only, you can use the
same remote agent port number for each instance. Therefore, you can use the
same remote agent to run jobs for all instances. However, if you are installing
multiple instances on both UNIX and Windows, you must specify unique remote
agent port numbers for each instance, as explained in the following section.

Configuring Multiple Instances Across Platforms

If you are running multiple instances across platforms, on both UNIX and
Windows, each instance must use different remote agent port numbers and
logging directories. You must do this because Unicenter AutoSys JM for
Windows requires that you install a remote agent for each instance. Therefore,
on Windows, each instance must have a unique remote agent port number, and
each must use the same port number on every remote agent machine. In
addition, each uses an instance-specific logging directory so that the remote
agent log files are separated by instance (AUTOSERV).

When you are installing on UNIX and want to run on both UNIX and Windows,
each instance must have the same configuration settings on every machine on
which it is installed. When you install a server, you must supply a unique
instance name and remote agent port number (“port number for auto_remote”)
for each instance, and you must supply the same values for all installations of
that instance. On UNIX, after you are done installing servers for each instance,
you can install a single remote agent on each client machine, then configure each
one to run jobs for multiple instances.

In addition, when installing event processors on UNIX, you must supply each
instance with unique AutoRemoteDir and AutoRemPort values, which are
located in the configuration file. When installing event processors on Windows,
you must supply each instance with a unique remote agent port number and
enterprise-wide logging directory values.

8–26 Installation Guide

 Installing Multiple Instances

In order to configure your UNIX remote agent installations to allow access to

multiple instances running on both UNIX and Windows, you must modify the
remote agent /etc/inetd.conf and /etc/services files, and set up the instance-
specific logging directories.

If you desire to do so, you can install a remote agent for each instance, supplying
each with unique remote agent port number during the installation process.
However, this approach will take up more space, and it is not necessary on
UNIX platforms.

Note: All instances that run jobs using one remote agent must have the same
type of event server, either Sybase or Oracle. A remote agent can only write to
one type of database.

To install multiple remote agents in a client machine, follow the process

described in either the chapter “Client Installation for Sybase” or the chapter
“Client Installation for Oracle,” in this guide.

Advanced Configurations 8–27

Installing Multiple Instances

Determining Instance Configuration Settings

If the event processor for an instance is on a UNIX machine, you should ensure
that the remote agent port number and the remote agent logging directory
settings in the configuration file are unique for that instance.

For example, if you were running a PRD instance with the port number of 5285,
you would modify the $AUTOUSER/config.PRD file in the following ways:
AutoRemoteDir=/PRD.tmp
...
# Port number of auto_remote
AutoRemPort=5285
...

You must ensure that the logging directory that you indicate exists on the remote
agent machines. For example, in this case, all remote agent machines that will
run jobs for the PRD instance must have a /PRD.tmp directory.

If your event processor is on a Windows machine, you would check the

Unicenter AutoSys Administrator settings. The Unicenter AutoSys
Administrator Remote Agent screen contains the TCP/IP Port # setting (that is,
AutoRemPort), and the Unicenter AutoSys Administrator Event Processor screen
contains the Enterprise Wide Logging Directory (that is, AutoRemoteDir). You
can set both of these parameters at installation time.

Note: If you are running with a shadow event processor, you must also modify
the configuration file on the shadow event processor machine.

For information on the configuration file, see the chapter “Configuring” in the
Unicenter AutoSys Job Management for UNIX User Guide. For information on
setting these configuration parameters on an Windows machine, see the chapter
“Administrator” in the Unicenter AutoSys Job Management for Windows User
Guide.

8–28 Installation Guide

 Installing Multiple Instances

Configuring a UNIX Remote Agent for Multiple Instances

This section describes how to configure one remote agent executable on UNIX to
allow access from multiple instances on both UNIX and Windows NT. To
configure the remote agent, you modify the remote agent port number (socket
connection) and logging directory. Before you do this, you must determine
instance-specific port number and remote agent logging directory.

Configure a remote agent to run multiple instances, with the following;

1. If running, stop all involved event processors.

Note: Stopping the event processor and making these changes does not
affect the currently running jobs. These jobs will run to completion.

2. Modify the /etc/services file. For example, the file may have an entry like:
auto_remote 5280/tcp

To modify the file so that you can run both the ACE and PRD instances on
that remote agent, replace the existing entry with these two entries:
auto_remote_ACE 5280/tcp # AutoSys ACE
auto_remote_PRD 5285/tcp # AutoSys PRD

where:

auto_remote_ACE Indicates the service name for the remote agent, which you have modified to be
instance-specific. The remote agent service name must be the same in both the
/etc/services file and the /etc/inetd.conf internet demon configuration file.

5280/tcp Indicates the port number for the remote agent. If you wish to have multiple
instances running on one remote agent, you must change the number for each
instance designation. This number must be the same value across all remote
agents for that instance.

Note: If your machine is running NIS or NIS+, you must edit the services
file, remake the map, and push it out to all clients, including the server. For
information on how to do this, contact your system administrator.

Advanced Configurations 8–29

Installing Multiple Instances

3. Modify the /etc/inetd.conf internet demon configuration file to match the

services file settings. For example, you may have an entry like:
auto_remote stream tcp nowait root /usr/vendor/autotree/
auto_remote auto_remote

To modify the file, include both the ACE and PRD instances by replacing the
existing entry with these entries:
auto_remote_ACE stream tcp nowait root /usr/vendor/autotree/auto_remote
auto_remote_ace
auto_remote_PRD stream tcp nowait root /usr/vendor/autotree/auto_remote
auto_remote_prd

4. Create instance-specific logging directories using directory names based on

those specified in each instance’s configuration file. (If your event processor
is running on Windows, this setting is in the Unicenter AutoSys
Administrator Enterprise-Wide Logging Directory.)

Note: The specified directory must exist on all client (remote agent)
machines.

Configuring Cross-Instance Job Dependencies

To configure cross-instance job dependencies:

1. Create a file named config.EXTERNAL in the instance’s $AUTOUSER

directory.

2. In the config.EXTERNAL file, add an entry similar to one of the following for
each instance for which cross-instance dependencies will be implemented.

■ For Sybase:
instance:EventServer=data server:database

■ For Oracle:
instance:EventServer=tnsname

where:

instance Indicates the three-letter instance ID for the target instance (for example, PRD).

EventServer Indicates the data server identifier. This is a literal keyword.

data server Indicates the name of the Sybase data server used by the target instance. This
name is the same one specified in the configuration file of that target instance.
The data server name must be unique for each event server parameter entered
in the file, regardless of the instance with which it is associated.

8–30 Installation Guide

 Installing Multiple Instances

database Specifies the name of the Sybase database used by the target instance.

tnsname Specifies the name of the Oracle data server used by the target instance. This
name is the same one specified by the event server parameter in the
configuration file of that target instance.

For example, if you were identifying a Sybase event server where PRD is the
target instance, AUTOSYSDB is the data server, and autosys is the database
name, the entry in the file would look like:
PRD:EventServer=AUTOSYSDB:autosys

Once you have created a config.EXTERNAL file for each involved instance, you
can define jobs to have cross-instance dependencies.

Tips on Creating the config.EXTERNAL File

When you create the config.EXTERNAL file, consider the following:

■ The config.EXTERNAL file can contain no more than 249 lines (or entries).

■ For instances that are running in dual-server mode, you must include an
entry for both servers in the config.EXTERNAL file. Furthermore, these
entries must appear together, consecutively, in the file; no other instance can
be inserted between them. For example, your configuration file may look
like:
ACE:EventServer=AUTOSYSDB0:autosys
PRD:EventServer=AUTOSYSDB1:autosys
PRD:EventServer=AUTOSYSDB2:autosys
XYZ:EventServer=AUTOSYSDB3:autosys

Advanced Configurations 8–31

Appendix

Introducing CAICCI
A
CAICCI (Computer Associates International Common Communication Interface)
is a transport layer that allows the asbIII process, which handles cross-platform
events, to communicate with Agents on AS/400, OpenVMS, UNIX, Windows,
and OS/390. On UNIX, CAICCI consists of several processes and a library. The
processes are responsible for network transmission, creating and maintaining
CAICCI resources. asbIII accesses the CAICCI API through the shared library.

On the UNIX platform, there are three demon processes:

■ caiccid
This process is referred to as the main CAICCI demon because it is started
first, builds the CAICCI resources and starts the other two CAICCI demons.

■ caicciclnd
This process is referred to as the clean demon because its responsibility
includes the maintenance of the CAICCI IPC resources.

■ caiccirmtd
This is the remote demon process, which is responsible for the transmission
of data across the network.

Installing CAICCI
The Unicenter AutoSys JM installer offers the option to install CAICCI with an
AutoSys server. If you select Unicenter CCI, it installs CAICCI automatically.
Later in the dialogs, the installer will ask for a list of remote hosts with which
CAICCI is to communicate. Enter their names separated by spaces. You may
change the list of remote hosts after installation by editing the file ccirmtd.prf as
described below.

Introducing CAICCI A–1

Configuring CAICCI

Configuring CAICCI
The asbIII process communicates to Agent machines and Connect using CAICCI.
You need to configure CAICCI to communicate with a particular machine.

You must log in as root to edit the CAICCI configuration files:

■ caiccid.prf

■ ccirmtd.prf

■ cciclnd.prf

Note: We do not recommend that you update the caiccid.prf configuration file
unless the file hits the max_recvrs limit.

caiccid.prf

The caiccid.prf file tells the main CAICCI demons what to do and specifies the
Max_Recvrs value.

Node-Specific Path Name

The caiccid.prf: file is found in the following location:

$CAIGLBL0000/cci/config/nodename/caiccid.prf

where:

nodename Identifies the machine on which the Enterprise Management CAICCI demons
are running.

The following is an example of the caiccid.prf file:

CLN_Demon = cciclnd startup
RMT_Demon = ccirmtd startup
Max_Recvrs = 48,32

A–2 Installation Guide

 Configuring CAICCI

CAICCI Demons

The following parameters specify what the CAICCI demons do and specifies the
Max_Recvrs parameter:

■ CLN_Demon = cciclnd startup—This setting tells CAICCI to start the

CAICCI clean demon when you start CAICCI.

■ RMT_Demon = ccirmtd startup—This setting tells CAICCI to start the

CAICCI remote demon when you start CAICCI.

■ Max_Recvrs = nn,mm—The value of nn defines the number of CAICCI

receivers which also determines the size of the shared memory segment for
RVT lists. The value of mm is the number of messages that CAICCI will
queue up. These parameter values are explained in Shared Memory for
RVTs, in this chapter.

Shared Memory for RVTs

Information about a receiver is kept in a structure called an RVT. Since all

applications must have access to information about a receiver, the information is
kept in shared memory as an RVT list. On UNIX, it may be viewed by using the
CAICCI show command. This produces blocks of data. The first block contains
global data and each subsequent block contains information specific to a
particular receiver. This information includes the CAICCI address, the process
ID of the application and whether the application is ready to accept data or has a
message pending.

On UNIX, the process that creates shared memory is the main CAICCI demon,
CAICCI. When CAICCI starts up it creates the shared memory segment;
therefore, CAICCI must know beforehand how large a memory segment to
create.

The value of nn determines the size of the shared memory segment because it is
the number of RVTs CAICCID creates. This has the effect of limiting the number
of application receivers. CAICCI is shipped with a default value nn=48. You may
need to change the default value to match your installation.

Introducing CAICCI A–3

Configuring CAICCI

Each application requires at least one RVT and each unprocessed CCI message
requires another. On a busy server, you may need to increase the value of nn. An
indication that you need to increase the value of nn is if you receive the
CAICCI_E_FREERVTS error message. This message is displayed on the system
log. On a busy server, you may need to increase the value of nn to 200 or 300.

After the value of nn is increased, asbIII may not start up because CAICCI has
not started. This sometimes happens because CAICCI must protect access to this
shared memory with the use of a semaphore group. CAICCI needs to create a
semaphore group with a semaphore identifier for each RVT plus three extras. On
most UNIX platforms, the number of semaphore identifiers in a semaphore
group is governed by the SEMMSL kernel parameter. It is important to be aware
of the following rule when increasing the first number of the Max_Recvrs
parameter, nn:
SEMMSL >= nn + 3

You may need to increase the SEMMSL value.

CAICCI requires, at most, two distinct semaphore identifiers. If CAICCI gets

ID=0, it will hold this group and request another. Unicenter® Network and
Systems Management (Unicenter NSM) has requirements for XXXMNI, which
should be added to requirements for other products using IPC (Inter-Process
Communication) resources.

In addition to storing an application’s CAICCI address, shared memory is also

used to store the data that the application is sending. Sometimes messages arrive
too quickly for the target application to dispose of them. In this case, an
application may request that CAICCI queue up messages. The number of
messages that CAICCI will queue up for each application is determined by the
second value of the Max_Recvr parameter—mm. The mm value may be set as
high as 700; however, CAICCI is designed to shut down when the 700th buffer is
filled to avoid problems with possible limited resources. For this reason, the
recommended maximum value of mm is 699.

If the Max_Recvr parameter is set to a value higher than allowed, it will default
to the maximum. Sometimes an application will hang or will be too busy to pick
up its messages. In a situation such as this, you will see the error message:
CAICCI_E_RECVBUSY Target [ ] queue is full, sender [ ]

A–4 Installation Guide

 Configuring CAICCI

The default behavior is for the sending application to sleep while waiting for
room on the buffer. This may work for an application using CAICCI but not for
the remote demon.

Customizing

The simplest way to enable CAICCI remote communications is to have the

configuration requirements built for you during your initial installation.

If you have already installed CAICCI, you can use the

$CAIGLBL0000/cci/scripts/reinstall script to enable CAICCI remote
communications.

1. During this procedure, the following prompt appears:

During the initial installation, several CCI parameter files were created.
Do you want to recreate these files as part of this reinstallation?
(y/n) (default: n)

Respond y to install the CAICCI remote demon.

2. You are then prompted for the names of the nodes with which the CAICCI
remote demon is to establish communications, as follows:
Please enter the name of the remote host or RETURN to end:

Reply with a single node name.

3. The prompt is repeated in order for you to specify another node with which
CAICCI will communicate. Respond with additional node names, one at a
time, until all of the nodes have been specified.

When you are done, press Enter twice to continue.

ccirmtd.prf

The ccirmtd.prf file identifies the local CAICCI node name, the UNIX host name,
and the block size for the local and remote machines.

Introducing CAICCI A–5

Configuring CAICCI

Node-Specific Path Name

The ccirmtd.prf file is found in the following location:

$CAIGLBL0000/cci/config/nodename/ccirmtd.prf

where:

nodename Identifies the machine on which the CAICCI demons are running.

Syntax
LOCAL = nodename cciname max_msg_size [startup | nostart] [port=1721 retry=n]
REMOTE = nodename cciname max_msg_size [startup | nostart] [port=1721 retry=n]

where:

nodename Indicates the hostname that will be passed to gethostbyname. This can be any
name resolvable to the correct IP address and does not have to have logical
connection to cciname.

cciname Indicates the logical name CAICCI will use to identify this host. This name is
determined by the ca_uname function at install time and by ca_nodename
during runtime. These functions are the equivalent of uname –n. This name can
be as long as 64 characters but an alias must be used for names greater than
eight characters.

max_message_size Specifies the maximum buffer that CAICCI will send or receive over the socket.
It is a good idea not to adjust this. Each side of the connection may have this set
to different values, up to 32KB. The lesser of the two values is used.

startup | nostart Tells ccirmtd whether or not to initiate a connection. Sometimes you may only
want one side to initiate the connection. This is handy for a UNIX admin client
when many people power down their PCs at night. You can eliminate many
annoying messages when CAICCI is recycled during the night if the server
does not start connections.

In addition, there are verbs of the form VERB=value:

■ RETRY=x—Determines how ccirmtd will behave if the connection is

dropped.

where x is one of the following:

0—ccirmtd will not retry the connection.

A–6 Installation Guide

 Configuring CAICCI

-1—ccirmtd will start with a two second retry interval and double after each
unsuccessful retry attempt.

> 0—ccirmtd will wait n seconds between retry attempts.

■ This is used in conjunction with the nostart option to allow the server to sit
passively and wait for incoming connection requests. If a client host goes
down the server will not attempt to reconnect, and we are again relieved of
messages requesting that we check to see if CAICCI is active on the client.

■ PORT=p—Allows us to specify an alternate port for this specific connection

only. The default port number is 1721.

For example:
LOCAL = abcdef31 abcdef31 32768 startup
REMOTE = abcdef33 abcdef33 32768 startup
REMOTE = abcdef33 abcdef33 32768 startup port=7000

cciclnd.prf

The cciclnd.prf file defines the number of seconds to sleep between system scans
for communications buffer and connections cleaning. The default time value for
cciclnd is one second. The default value should not be changed unless instructed
by Computer Associates Technical Support.

Node-Specific Path Name

The cciclnd.prf file is found in the following location:

$CAIGLBL0000/cci/config/nodename/cciclnd.prf

where:

nodename Identifies the machine on which the CAICCI demons are running.

Introducing CAICCI A–7

CAICCI Environment Variables

CAICCI Environment Variables

The following environment variables are available on the UNIX platform. The
best place to set them is in the $CAIGLBL0000/cci/scripts/rc file prior to the
invocation of the main CAICCI demon process (caiccid), unless otherwise noted.

CAI_CCI_DEBUG

Definition:

Enables or disables CAICCI traces.

Use:

Set to enable traces, unset to disable traces.

Components Affected:

All CAICCI processes and applications using CAICCI.

When to Use:

Use for tracing.

CAI_CCI_LOG

Definition:

The directory to which CCI trace file is written.

Use:

CAI_CCI_LOG=path, where path is directory for traces.

Components Affected:

All CCI processes and applications using CCI.

When to Use:

Use if a larger volume is required for trace output.

A–8 Installation Guide

 CAICCI Environment Variables

CAI_CCI_CONFIG

Definition:

Sets path to CCI configuration directory.

Use:

CAI_CCI_CONFIG=path where configuration files reside:

$path\–n

Components Affected:

All CCI processes.

CAI_CCI_SHMMIN

Definition:

Minimum size of shared memory segment CAICCI requests.

Use:

CAI_CCI_SHMMIN=SHMMIN, where SHMMIN is a kernel parameter.

Components Affected:

All CAICCI processes and applications using CAICCI.

When to Use:

When the SHMMIN kernel parameter is greater than 1.

Introducing CAICCI A–9

CAICCI Environment Variables

CAI_CCI_PORT1

Definition:

ccirmtd will bind to a specified port prior to connect calls.

Use:
CAI_CCI_PORT1=n

where:

n > 1024 K

Components Affected:

Remote demon process.

When to Use:

For firewalls or certain multi NIC situations.

CCI_SELECT_TIME

Definition:

Determines the time out for select after connect.

Use:
CCI_SELECT_TIME=n

where:

n >1

Components Affected:

Remote demon process.

When to Use:

Sometimes network conditions will cause the TCP/IP handshake to take a long
time to complete.

A–10 Installation Guide

 Starting and Stopping CAICCI

Starting and Stopping CAICCI

Note: You need to be logged in as root to start and stop CAICCI.

To start CAICCI, run the rc script:

$CAIGLBL0000/cci/scripts/rc

There should be three processes running for CAICCI:

$ ps -ef|grep cci
root 17733 17731 0 Jan 18 ? 30:36 /uni/cci_kit/cci/bin/ccirmtd
root 17732 17731 0 Jan 18 ? 1:20 /uni/cci_kit/cci/bin/cciclnd
root 17731 1 0 Jan 18 ? 1:25 /uni/cci_kit/cci/bin/caiccid

To stop CAICCI, run the cshut script:

$CAIGLBL0000/cci/scripts/cshut

If CAICCI hangs and you cannot shut it down, do the following:

1. Kill the three CAICCI demon processes, enter:

kill -9 <3 pids of cci>

2. Search the shared memory for the caiccid process, enter:

ipcs -a|grep 0000d

3. Remove the message queue for the caiccid process returned from Step 2,
enter:
ipcrm -q <message queue id>

4. Remove the shared memory for the caiccid process returned from Step 2,
enter:
ipcrm -m <shared memory id>

5. Remove the semaphore for the caiccid process returned from Step 2, enter:
ipcrm -s <semaphore id>

Introducing CAICCI A–11

Appendix

Platform Notes
B
This appendix describes platform-specific information.

DG/UX: TZ Variable Setting

On DG/UX, we have found that the TZ variable works best when set to values in
the form EST5EDT.

IBM AIX: GUI Display

In order to run the AutoSys GUIs on an IBM AIX machine, you must point to
Motif 1.2 shared libraries. If Motif 1.2 is not installed, contact your IBM
representative or your system administrator.

Sun Solaris: GUI Display

To use the GUIs (autosc, autocal, and autocons) on Sun Solaris systems, the
environment variable LD_LIBRARY_PATH must contain ‘/usr/openwin/lib’ so
that the linker/loader can find the Open Windows shared libraries at runtime.

Platform Notes B–1

 Removing Unicenter AutoSys JM
Appendix

C 4.5

If you are now using AutoSys and want to upgrade, see the Unicenter AutoSys
Job Management Upgrade for Windows User Guide for complete instructions
about how to upgrade AutoSys versions 3.x to AutoSys 4.5.

Before You Remove

Before removing Unicenter AutoSys JM, check to make sure that all of the
following are true:

■ A backup of the database exists (if you are keeping one). If you have a
bundled Sybase database, the program will remove it. If you have an
unbundled Sybase database, or an Oracle database, the program will not
alter it.

Note: The uninstall program gives you the option of deleting your database.
To delete the database, check the Remove Database check box on the
uninstall window.

■ No Unicenter AutoSys JM jobs are running.

■ No event processor services are running.

■ No Unicenter AutoSys JM processes are currently active or running.

■ No Unicenter AutoSys JM directories or files are open.

■ You are not accessing any directories or files in a Unicenter AutoSys JM

instance command prompt or from any other application.

Removing Unicenter AutoSys JM 4.5 C–1

Removing

■ eTrust™ must be stopped.

■ All Unicenter AutoSys JM windows are closed.

■ All other windows are closed.

Removing
To remove Unicenter AutoSys JM, follow these steps on each machine where you
installed a Unicenter AutoSys JM component for a particular instance, select one
of the following depending on which database you used:
lsm -e UnicenterAutoSysJM-ORA

or
lsm -e UnicenterAutoSysJM-SYB

All of these procedures retain the $AUTOUSER directories for your Unicenter
AutoSys JM instances for future reference. To remove them do the following:
rm -r $AUTOUSER

Where $AUTOUSER is the appropriate value for $AUTOUSER.

You can mount the product CD and repeat the original installation command of:
./install-oracle.sh

or
./install-sybase.sh

then select Remove from the Installation Option dialog.

The procedure listed previously, do not remove eTrust AC or the Unicenter CCI
since you may have licensed those products separately.

C–2 Installation Guide

 Removing

eTrust AC

To remove eTrust AC, log in as an eTrust AC administrator, su to root and run

the following commands:

$SEOSDIR/bin/secons -s
$SEOSDIR/bin/uninstall_eTrust

Where $seosdir indicates your eTrust AC installation directory (for example:

/opt/CA/eTrustAccessControl).

secons shuts down the eTrust AC daemons, and uninstall_eTrust removes eTrust
AC.

Important! Do not simply remove the eTrust AC installation directory without

running uninstall_eTrust. Doing so may prevent users from logging into the
system.

Unicenter CCI

To remove the Unicenter CCI, run as root, with the following:

export CAIGLBL0000
CAIGLBL0000=/opt/CA/CCISA
$CAIGLBL0000/cci/scripts/cshut
$CAIGLBL0000/scripts/setupCCISA -d
rm -r $CAIGLBL0000

Where CAIGLBL0000 is the location of the Unicenter CCI installation directory

(for example; /opt/CA/CCISA).

cshut shuts down the CCI daemons, and setupCCISA removes most of the files
and rm removes the rest.

Removing Unicenter AutoSys JM 4.5 C–3

 Index

machines, 1-9
owner, creating, 3-2
profile, 5-10, 5-11, 7-10, 7-11
system architecture, 1-6
A
AutoSys Administrator, 1-12

AIX. See IBM AIX, 3-7 autosys directory, 3-2

app-defaults file, 5-12, 7-12 AUTOSYS variable, 1-11

auto.profile file, 7-11 autosys.csh.hostname, 1-11

script, 5-11, 7-10
autosys.ksh.hostname, 1-11
Sybase interfaces, 5-10
autosys.sh.hostname, 1-11
auto_install
Oracle server, 6-8 autosys_secure
Sybase server, 4-4 defining superusers, 4-11, 6-14

auto_remote, 5-11, 7-11 autotrack, 4-14, 6-17

AUTOENV# AUTOTREE environment variable, 1-14, 3-2

definition, 5-10
autouser directory, 3-2
ORACLE_HOME, 7-11
profile script, 5-11, 7-10 AUTOUSER path, 2-15
SYBASE, 5-10 AUTOUSER variable, 1-11
TNS_ADMIN, 7-11

autoping, 4-12, 5-8, 6-15, 7-7

C
AUTOSERV variable, 1-11

AutoSys
CAI_CCI_Config, A-9
configuration file, 1-12
database, defined, 1-4 CAI_CCI_Debug, A-8
directory structure, 1-14 CAI_CCI_Log, A-8
environment, sourcing, 1-11
instances CAI_CCI_Port1, A-10
defined, 1-10 CAI_CCI_Shmmin, A-9
multiple, 1-18

Index–1
CCI checklist, 2-19
cciccid.prf, A-2 Client, 2-20
cciclnd.prf, A-7 Server, 2-19
ccirmtd.prf, A-5 cross-instance job dependencies, 1-20
Configuring, A-2 database verification, 4-18, 6-21
Environment Variables, A-8 file, 1-12
Introduction, A-1 in AutoSys Administrator, 1-12
RVT, A-3 installation:, 4-11, 6-14
Starting and Stopping, A-11
cross-instance configuration, 1-20
Troubleshooting Tools, A-8

CCI_Select_Time, A-10

ccicci.prf
D
Customizing, A-5
definition, A-2 database
defined, 1-4
cciclnd.prf, A-7
information, 1-12
checklist unrecoverable error, 1-25
client, 2-24
dataserver. See database, 1-4
existing Oracle database, 3-11
Oracle client, 7-2 DEC OSF/1. See Digital UNIX, 3-5
Oracle server example, 6-2
DG/UX
server, 2-21
TZ Variable Setting, B-1
Sybase client example, 5-2
Sybase server example, 4-1 Digital UNIX
unbundled Sybase database, 3-8 configuring for bundled Sybase, 3-5

client directory
checklist, 2-24 autosys, 3-2
configuring internet daemon for NIS and NIS+, autouser, 3-2
5-4 sadb, 3-2
installation, checklist example, 5-2 directory structure, 1-14
installation, Oracle, 7-1
installation, Sybase, 5-1 disk space requirement, 2-1
Oracle checklist, 7-2 DISPLAY variable, 1-11
client machine, 1-9 DSQUERY environment variable, 1-13, 3-9
client machines, 2-7 dual event servers
components, 2-4 defined, 1-4, 1-23
event processor, 1-5, 2-7 running, 1-25
event server, 1-4
remote agent, 1-5
E
config.$AUTOSERV file, 1-12

configuration edit superuser, 4-11, 6-14

Index–2 Installation Guide

environment H
databaser verification, 4-18, 6-21
Oracle, 1-13
HP-UX
sourcing, 1-11, 5-11
configuring for bundled Sybase, 3-6
sourcing before command job, 7-10
restarting inetd, 5-10
Sybase, 1-13

environment variables
CCI, A-8 I
DSQUERY, 1-13, 3-9
ORACLE_HOME, 1-13, 3-12
IBM AIX
SYBASE, 1-13, 3-9
configuring for bundled Sybase, 3-7
eTrust Motif 1.2 Requirement, B-1
user and host names, 2-8
identifying client machines, 2-7
eTrust AC:, 4-11, 6-14
identifying machines, 2-7
event processor PMDB, 2-10
defined, 1-5 policy manage host name, 2-10
machines, 2-7 policy manager user name, 2-9
See also event_demon
identifying machineseTrust Access Control, 2-8
eventor, and shadow event processor., 1-5
starting, 4-10, 6-13 identifying server machines, 2-7

event server inetd

defined, 1-4 configuring for NIS and NIS+, 3-3, 4-13, 6-16
error detection, 1-25 pinging, 4-12, 6-15
errors, unrecoverable, 1-25 services, setting up for NIS and NIS+, 5-9
information, database, 1-12
inetd file, 2-18
name, 2-15
See also database and dual event servers, 1-4 information
single, 1-25 AUTOUSER path, 2-15
bundled Sybase, 2-16
event_demon
data tablespace (Oracle), 2-17
defined, 1-5
database configuration (Oracle), 2-17
See also event processor, 1-5
DBA (Oracle), 2-17
eventor, 4-10, 6-13 eTrust client, 2-13
admin users, 2-13
exec superuser, 4-11, 6-14
server hosts, 2-13
existing Oracle checklist, 3-11 eTrust serve
admin hosts, 2-12
admin users, 2-12
G subscribers, 2-13
eTrust server, 2-12
GUI, app-defaults file, 5-12, 7-12 event server (Oracle), 2-16
event server host (Sybase), 2-15

Index–3
 event server name, 2-15 Sybase, 4-1
gathering, 2-12 Sybase client
index tablespace (Oracle), 2-17 bundled Sybase preparations, 5-4
inetd file, 2-18 GUI display, 5-12
instance, 2-15 loading software on client machine, 5-5
monitor type, 2-14 low level, 5-9
owner, 2-14 Sybase server, 4-1
password (Oracle), 2-17 testing, 4-7, 6-10
password (Sybase), 2-16
Installation
primary database (Sybase), 2-15
configuring:, 4-11, 6-14
remote agent, 2-18
License:, 4-14, 6-17
remote agent path, 2-18
testing:, 4-16, 6-19
remote agent port, 2-18
remote command service, 2-13 instances
directories, 2-14 AutoSys, 1-10
installation directory, 2-14 cross-instance configuration, 1-20
port number, 2-14 multiple
valid hosts, 2-14 running, 1-19
sa user (Sybase), 2-15
interfaces file, 3-9, 5-10
system files, 2-14
tnsnames.ora (Oracle), 2-16 internet daemon
unbundled Sybase, 2-16 configuring for NIS and NIS+, 3-3, 4-13, 6-16
Unicenter CCI, 2-13 services, for NIS and NIS+, 5-9
installation directory, 2-13
remote hosts, 2-13
wizard setup, 2-12 J
installation
changes to files and directories, 1-17 java based listener, 2-6
client
Oracle, 7-1
Sybase, 5-1 L
directory, creating, 3-2
gathering information, 2-12 listener, 2-6
Oracle client compatability, 2-6
GUI display, 7-12
loading software on client machine, 7-4
low level, 7-9 M
overview, 2-1
rerunning, 4-7, 6-10
machines
script
client, 1-9
Oracle server, 6-8, 7-5
identifying, 2-7
Sybase server, 4-4, 5-6
server, 1-9
server
Oracle, 6-1 memory requirement, 2-1

Index–4 Installation Guide

multiple instances OSF/1. See Digital UNIX, 3-5
running, 1-19
owner
multiple instances of AutoSys, 1-19 creating, AutoSys, 3-2

N P

NIS and NIS+ PMDB host name, 2-10

client inetd configuration, 5-4
policy manager host name, 2-10
server inetd configuration, 3-3
services file, 5-4 policy manager user name, 2-9

profile file, 5-11, 7-10

O
R
OPEN LOOK, 5-13, 7-13

OPEN WINDOWS, 5-13, 7-13 rcs, 2-5

Oraccle recon utility, 6-5

requirement, 2-1
remote agent
Oracle defined, 1-5
client checklist, 7-2 path to, 2-18
client installation, 7-1 pinging, 4-13, 5-8, 6-16, 7-7
configuring an existing database, 3-11 port, 2-18
data tablespace, 3-12 See also client, 1-5
environment, 1-13 service name, 2-18
environment settings, 7-11
remote command service, 2-5
index tablespace, 3-12
location of files, 1-13 remove Unicenter AutoSys JM, C-1
recon utility, 6-5 removing, C-2
server installation, 6-1 eTrust AC, C-3
server, checklist example, 6-2 Unicenter CCI, C-3
setup confirmation utility, 6-5
SQL*Net V2, 1-13 requirement
tablespace adaptive server, 2-2
data, 3-12 database, 2-4
index, 3-12 disk space, 2-1
temporary tablespace, 3-12 memory, 2-1
TNS names file, 1-13 Oracle, 2-1
tnsnames.ora file, 1-13, 3-12 Sybase, 2-1
variables, 1-13 RVT, A-3
ORACLE_HOME environment variable, 1-13, 3-12

Index–5
S requirement, 2-1
server installation, 4-1
SQL.INI file, 1-13
sadb directory, 3-2
unbundled, required database changes, 2-15
selecting components, 2-4 verifying database connection, 4-14, 6-17

server SYBASE environment variable, 1-13, 3-9

checklist, 2-21
system architecture, 1-6
configuring, 3-1
installation system components, 1-3
Oracle, 6-1 system files, changes to, 1-17
Sybase, 4-1
instance, 1-4 system requirements, 2-1
machine, 1-9

server installation, checklist example, 4-1

T
server machines, 2-7

services file test job, creating

configuring for NIS and NIS+, 3-3, 5-4 Oracle, 6-19
Sybase, 4-16
services, internet daemon for NIS and NIS+, 5-9
testing the server installation
shadow event processor
Oracle, 6-10
defined, 1-5, 1-25
Sybase, 4-7
running, 1-27
TNS alias name, 3-12
SMIT utility, 3-7
TNS names configuration file, 1-13
Solaris
configuring the bundled Sybase, 3-8 tnsnames.ora file, 1-13
GUI Display, B-1 Troubleshooting Tools, CCI, A-8
SQL*Net V2, 1-13

start_autodb, 4-9, 6-12

U
superusers
defining, 4-11, 6-14 unbundled Sybase checklist, 3-8
Sybase usr/vendor/autotree, 3-2
bundled
configuring the operating system, 3-5
starting, 4-9, 6-12 W
client installation, 5-1
configuring an existing database, 3-8
DSQUERY variable, 1-13 Windows NT, environment, 1-12
environment, 1-13 wizard setup, 2-12
environment variable, 1-13
interfaces file, 1-13, 3-9, 5-10

Index–6 Installation Guide