20596690 Autosys Job Management Unix Installation Guide

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

Chapter

1 Introduction to Unicenter AutoSys 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.

Event Processor

Event Server(database)

AutoSys Server(UNIX or NT)

RemoteAgent

NT Job

NT Client

RemoteAgent

Unix Job

UNIX Client


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.


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.


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

Event Processor

• Determines Actions

• Initiates Action: Start job on machine command:'rm/tmp/ mystuff/*'

PROCESS

2

1

Event Server

• Events

• Job Definitions

PROCESS

3

Local AreaNetwork

4

WorkStation_25Command

• Runs UNIX Command 'rm/tmp/mystuff/*' or Windows NT Command 'del C:\ tmp\*.*'

• Completes execution and exits with status

PROCESS

Remote Agent

• Receives instructions from Event Processor

• Initiates Action: Starts Child Process

• Waits for Exit Code (From Child Process)

• Sends Exit event back to Event Server

PROCESS

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.


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.


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.


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.


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.


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.


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.


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.


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

$AUTOUSER

autouser sadb

Configuration Files:config.$AUTOSERVautosys.sh.hostautosys.csh.hostetc.

interfaces file

archiveout

soundsbin includeinstall lib

$AUTOSYS $SYBASE

(bundled DB only)

install

bin code dbobj doc

data

sounds snmptest

bin jil demo

DATA OCS-12-0ASE-12-0

bin lib


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 theAutoSys Administrator settings in the Windows NT Registryand locates the Event Server and database configurationsetting (for example: EventServer=AUTOSYSDB:autosys).

Searches for AUTOSYSDB in the interfaces or SQL.INI file.

RDBMS

AutoSys Serverautosys_server

Uses hostname and port number entry to connect to Sybasedatabase (for example: AUTOSYSDB autosys_server6234).

Access AutoSys



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

Connecting to an Oracle Database

Reads the $AUTOUSER/config.$AUTOSERV file or theAutoSys Administrator settings in the Windows NT Registryand locates the Event Server and database configurationsetting (for example: EventServer=MYORACLEDB).

Searches for the TNS aliasMYORACLEDB in thetnsnames.ora file.

RDBMS

AutoSys ServerMYORACLEDB

Uses network configuation information to connect to SQL*Net V2 and the Oracle database.

Access AutoSys


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.


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.


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.


Running Cross-Instance Job Dependencies

One Instance of AutoSysACE

OS Fileconfig.ACE File

or NT Registry Settings

EventServer

EventProcessor

One Instance of AutoSysPRD

OS Fileconfig.PRD File


EventServer

EventProcessor

ClientMachine

Remote Agent for ACE instanceRemote 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.



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.


OS Fileconfig.ACE

config.EXTERNAL

EventServer

EventProcessor




EventServer

EventProcessor

condition: success(jobB^PRD)jobE

jobBcondition: success

(jobEÂCE)

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.



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.


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.



EventServer

#1

EventServer

#2reads

&writes

MACHINE A MACHINE B

reads&

writes

writes

UserCommand

RemoteMACHINE

EventProcessor

StartJob

RemoteAgent

Run Job



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



Important! We recommend that the p imary and shadow p ocessors reside on two different machines, to prevent a single point of failure.

r r

EventServer

#1

EventServer

#2reads

&writes

MACHINE A MACHINE B

reads&

writes

writes

PrimaryProcessor

StartJob

Run Job

ShadowProcessorPING

UserCommand

ClientMACHINE

RemoteAgent

.dibs file

ThirdMACHINE

RemoteAgent



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.


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.


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.


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.

Event Processor

Event Server(database)

AutoSys Server(UNIX or NT)

RemoteAgent

NT Job

NT Client

RemoteAgent

Unix Job

UNIX Client


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.


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.


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

Event Processor

• Determines Actions

• Initiates Action: Start job on machine command:'rm/tmp/ mystuff/*'

PROCESS

2

1

Event Server

• Events

• Job Definitions

PROCESS

3

Local AreaNetwork

4

WorkStation_25Command

• Runs UNIX Command 'rm/tmp/mystuff/*' or Windows NT Command 'del C:\ tmp\*.*'

• Completes execution and exits with status

PROCESS

Remote Agent

• Receives instructions from Event Processor

• Initiates Action: Starts Child Process

• Waits for Exit Code (From Child Process)

• Sends Exit event back to Event Server

PROCESS

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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


$AUTOUSER

autouser sadb

Configuration Files:config.$AUTOSERVautosys.sh.hostautosys.csh.hostetc.

interfaces file

archiveout

soundsbin includeinstall lib

$AUTOSYS $SYBASE

(bundled DB only)

install

bin code dbobj doc

data

sounds snmptest

bin jil demo

DATA OCS-12-0ASE-12-0

bin lib



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 theAutoSys Administrator settings in the Windows NT Registryand locates the Event Server and database configurationsetting (for example: EventServer=AUTOSYSDB:autosys).

Searches for AUTOSYSDB in the interfaces or SQL.INI file.

RDBMS

AutoSys Serverautosys_server

Uses hostname and port number entry to connect to Sybasedatabase (for example: AUTOSYSDB autosys_server6234).

Access AutoSys



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

Connecting to an Oracle Database

Reads the $AUTOUSER/config.$AUTOSERV file or theAutoSys Administrator settings in the Windows NT Registryand locates the Event Server and database configurationsetting (for example: EventServer=MYORACLEDB).

Searches for the TNS aliasMYORACLEDB in thetnsnames.ora file.

RDBMS

AutoSys ServerMYORACLEDB

Uses network configuation information to connect to SQL*Net V2 and the Oracle database.

Access AutoSys


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.


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.


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.




OS Fileconfig.ACE File


EventServer

EventProcessor




EventServer

EventProcessor

ClientMachine

Remote Agent for ACE instanceRemote 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.



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.


OS Fileconfig.ACE

config.EXTERNAL

EventServer

EventProcessor




EventServer

EventProcessor

condition: success(jobB^PRD)jobE

jobBcondition: success

(jobEÂCE)

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.



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.



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.



EventServer

#1

EventServer

#2reads

&writes

MACHINE A MACHINE B

reads&

writes

writes

UserCommand

RemoteMACHINE

EventProcessor

StartJob

RemoteAgent

Run Job



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



Important! We recommend that the p imary and shadow p ocessors reside on two different machines, to prevent a single point of failure.

r r

EventServer

#1

EventServer

#2reads

&writes

MACHINE A MACHINE B

reads&

writes

writes

PrimaryProcessor

StartJob

Run Job

ShadowProcessorPING

UserCommand

ClientMACHINE

RemoteAgent

.dibs file

ThirdMACHINE

RemoteAgent



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.


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.


Chapter

2 Preparing for Installation

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


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 9000/800 HP 9000 D & E classes

HP-UX 11 64 MB (32-bit)

92 MB (64-bit)

IBM RISC System/6000

AIX 4.3.3 64 MB (32-bit)

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



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


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.



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



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 Web Interface 4.0

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


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.



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.



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.



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



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.


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.



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.



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.



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.



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.



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.



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.


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)


Port Number

Valid Hosts

Directories



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)


Port Number

Valid Hosts

Directories



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)



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



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



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)


Instance name (AUTOSERV) **

Install Full client or Jobs only



Name of user who will own software files

Name of data server that will contain database (DSQUERY)

**

Name of database in data server **





Client Checklist

Item Description




**


Value of TNS_ADMIN





Name of the remote agent service **

Port number for the remote agent **


Chapter

3 Preparing the Server for 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


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.



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



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.


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.



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 Disk I/O

You must enable asynchronous 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.



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.


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




Unbundled Sybase Checklist

Item Description



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.



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.


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


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)



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.



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.


Chapter

4 Server Installation for Sybase

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


512

Available disk space (600 MB bundled, 150 MB unbundled)

2.6 GB

License keys obtained and available? (y/n)

yes

Installation directory path name for Unicenter AutoSys JM (AUTOSYS)

/opt/CA/UnicenterAutoSysJM/


/opt/CA/UnicenterAutoSysJM/autouser

Install CCI yes

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


Bundled Sybase

OS configuration required? (y/n) yes

OS configuration completed? (y/n) yes

Name of data server that will contain Database (DSQUERY)

AUTOSYSDB

Name of Database in data server autosys


/opt/CA/UnicenterAutoSysJM/sadb


sa


Server Installation

Server Checklist

Item Description



/opt/CA/UnicenterAutoSysJM/autosys/bin


/etc

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


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.



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.



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.


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.



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



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:


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.

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:


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.


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 >



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.



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.



Database Connection Verification

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

autoping -m fiji -D


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.



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_ ime and from_time targuments.

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.


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.



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.




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


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.

Chapter

5 Client Installation for Sybase

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


Different OS than Unicenter AutoSys JM server (y/n)

No

Host name crete

Host ID 987654yz

Password of root


Bundled Sybase

Install CCI Yes

If installing Bundled Sybase on NCR, OS configuration is required. Is this completed

N/A

Installation directory pathname for Unicenter AutoSys JM (AUTOSYS)


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


Client Installation

Client Checklist

Item Description configuration and output files (AUTOUSER)


Install all clients, or jobs only all clients


Non-NIS


Color


Sybase Database

Name of data server that will contain Database (DSQUERY)

AUTOSYSDB

Name of Database in data server autosys


/opt/CA/UnicenterAutoSysJM/sadb


sa


Remote Agent

Full pathname to remote agent executable

/usr/local/bin


/etc/inetd.conf



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


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.


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


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.





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


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


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.


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.


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.



You will see the following message followed by a series of informational messages describing the progress of the 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


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.



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.



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.



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.



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.



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



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


Chapter

6 Server Installation for Oracle

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


Host name Hawaii

Host ID 1234567ab

Password of root


512

Available disk space (350 MB recommended)

4 GB

Keys obtained and available (y/n) Yes

Install CCI Yes

Installation directory pathname (AUTOSYS)





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

Monitor type (color or monochrome) Color



Oracle

OS configuration required (y/n) Yes


Server Installation

Server Checklist

Item Description

OS configuration completed (y/n) Yes

Oracle Database

Value of ORACLE_HOME /var/opt/oracle


AUTOSYSDB


Yes

Name of the data tablespace autodata

Size of the data tablespace (100 MB recommended)

100

Name of the index tablespace autoindexes

Size of the index tablespace (40 MB recommended)

40

Value of TNS_ADMIN /etc

Name of temporary tablespace temp


SYSTEM


Remote Agent


/opt/CA/UnicenterAutoSysJM/autosys/bin


/etc



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


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.





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


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.



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



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 ètc/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


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.


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.


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:



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:


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.



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 delet all the data that has been entered into the AutoSys database.

e

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.



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



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:


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:


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.



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.


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.


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:


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.



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 >



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.



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.


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


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



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.




Database Connection Verification

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

autoping -m fiji -D


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.



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_ ime and from_time targuments.

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.



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.



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.



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


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.


Chapter

7 Client Installation for Oracle

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


Different OS than Unicneter AutoSys JM server (y/n)

No

Host name maui

Host ID 987654yz

Password of root


Oracle

OS configuration required (y/n) No

OS configuration completed N/A

Install CCI Yes

Installation directory path name for Unicneter AutoSys JM (AUTOSYS)


Directory path name for configuration and output files



Client Installation

Client Checklist

Item Description (AUTOUSER)

Unicneter AutoSys JM instance name (AUTOSERV)

ACE

Install all clients, or jobs only All clients


Non-NIS


Color

Name of user who will own Unicneter AutoSys JM files

autosys

Oracle Database

Value of ORACLE_HOME /var/opt/oracle


AUTOSYSDB


Yes

Value of TNS_ADMIN, if not default

/etc

Name of temporary tablespace temp


SYSTEM

Password of database user who has been granted DBA role

Remote Agent


/usr/local/bin


/etc/inetd.conf



Loading the Software On the Client Machine

Client Checklist

Item Description


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;


To load the version:

1. Log on to the server machine as “root.”





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


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.


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



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:



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.


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.



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:


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


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.





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.



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.



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.



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.



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



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.


Chapter

8 Advanced Configurations

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



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.



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


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.



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.



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.



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


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



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



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.


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.



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


5. Synchronize the database as described in Synchronizing the Event Servers in this chapter.



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



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.




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.



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.



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.



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



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.



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.



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.



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



autosys Indicates the “autosys” user password.

tee /tmp/autobcp.out

Indicates the command used to create a record of the autobcp output. It is 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.


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.



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.


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.



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.



4. To start the primary and the shadow event processors simultaneously, enter the following command on the primary event processor 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:



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.



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.



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.



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.



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.



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


Appendix

A Introducing CAICCI

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.


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 [ ]


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.


Configuring CAICCI


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.


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.


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.


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.


All CCI processes and applications using CCI.

When to Use:

Use if a larger volume is required for trace output.



CAI_CCI_CONFIG

Definition:

Sets path to CCI configuration directory.

Use:

CAI_CCI_CONFIG=path where configuration files reside:

$path\–n


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.


All CAICCI processes and applications using CAICCI.

When to Use:

When the SHMMIN kernel parameter is greater than 1.



CAI_CCI_PORT1

Definition:

ccirmtd will bind to a specified port prior to connect calls.

Use:

CAI_CCI_PORT1=n

where:

n > 1024 K


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


Remote demon process.

When to Use:

Sometimes network conditions will cause the TCP/IP handshake to take a long time to complete.


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>

Appendix

B Platform Notes

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

Appendix

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

autosys_secure Oracle server, 6-8 defining superusers, 4-11, 6-14 Sybase server, 4-4

autotrack, 4-14, 6-17 auto_remote, 5-11, 7-11

AUTOTREE environment variable, 1-14, 3-2 AUTOENV# definition, 5-10 autouser directory, 3-2 ORACLE_HOME, 7-11

AUTOUSER path, 2-15 profile script, 5-11, 7-10 SYBASE, 5-10 AUTOUSER variable, 1-11 TNS_ADM N, 7-11 I

autoping, 4-12, 5-8, 6-15, 7-7 C

AUTOSERV variable, 1-11

AutoSys CAI_CCI_Config, A-9 configuration file, 1-12

CAI_CCI_Debug, A-8 database, defined, 1-4 directory structure, 1-14 CAI_CCI_Log, A-8 environment, sourcing, 1-11

CAI_CCI_Port1, A-10 instances defined, 1-10 CAI_CCI_Shmmin, A-9 multiple, 1-18

Index–1

checklist, 2-19 CCI Client, 2-20 cciccid.prf, A-2 Server, 2-19 cciclnd.prf, A-7

cross-instance job dependencies, 1-20 ccirmtd.prf, A-5 database verification, 4-18, 6-21 Configuring, A-2 file, 1-12 Environment Variables, A-8 in AutoSys Administrator, 1-12 Introduction, A-1 installation:, 4-11, 6-14 RVT, A-3

Starting and Stopping, A-11 cross-instance configuration, 1-20 Troubleshooting Tools, A-8

CCI_Select_Time, A-10 D ccicci.prf

Customizing, A-5 database definition, A-2

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 DEC OSF/1. See Digital UNIX, 3-5 Oracle client, 7-2

Oracle server example, 6-2 DG/UX server, 2-21 TZ Variable Setting, B-1 Sybase client example, 5-2

Digital UNIX Sybase server example, 4-1 configuring for bundled Sybase, 3-5 unbundled Sybase database, 3-8

directory client autosys, 3-2 checklist, 2-24 autouser, 3-2 configuring internet daemon for NIS and NIS+,

5-4 sadb, 3-2 installation, checklist example, 5-2 directory structure, 1-14 installation, Oracle, 7-1

disk space requirement, 2-1 installation, Sybase, 5-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 defined, 1-4, 1-23 components, 2-4 running, 1-25 event processor, 1-5, 2-7

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

H environment 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

I CCI, A-8 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

identifying server machines, 2-7 starting, 4-10, 6-13

inetd event server configuring for NIS and NIS+, 3-3, 4-13, 6-16 defined, 1-4 pinging, 4-12, 6-15 error detection, 1-25 services, setting up for NIS and NIS+, 5-9 errors, unrecoverable, 1-25

information, database, 1-12 inetd file, 2-18 name, 2-15

information See also database and dual event servers, 1-4 AUTOUSER path, 2-15 single, 1-25 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

eTrust client, 2-13 eventor, 4-10, 6-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 event server (Oracle), 2-16 GUI, app-defaults file, 5-12, 7-12 event server host (Sybase), 2-15

Index–3

Sybase, 4-1 event server name, 2-15 Sybase client gathering, 2-12

bundled Sybase preparations, 5-4 index tablespace (Oracle), 2-17 GUI display, 5-12 inetd file, 2-18 loading software on client machine, 5-5 instance, 2-15 low level, 5-9 monitor type, 2-14

Sybase server, 4-1 owner, 2-14 testing, 4-7, 6-10 password (Oracle), 2-17

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

instances remote command service, 2-13 AutoSys, 1-10 directories, 2-14 cross-instance configuration, 1-20 installation directory, 2-14 multiple port number, 2-14

running, 1-19 valid hosts, 2-14 sa user (Sybase), 2-15 interfaces file, 3-9, 5-10 system files, 2-14

internet daemon tnsnames.ora (Oracle), 2-16 configuring for NIS and NIS+, 3-3, 4-13, 6-16 unbundled Sybase, 2-16 services, for NIS and NIS+, 5-9 Unicenter CCI, 2-13

installation directory, 2-13 remote hosts, 2-13

J wizard setup, 2-12

installation java based listener, 2-6 changes to files and directories, 1-17

client Oracle, 7-1

L Sybase, 5-1 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

M low level, 7-9 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 memory requirement, 2-1 Oracle, 6-1


OSF/1. See Digital UNIX, 3-5 multiple instances running, 1-19 owner

creating, AutoSys, 3-2 multiple instances of AutoSys, 1-19

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

policy manager user name, 2-9 services file, 5-4

profile file, 5-11, 7-10

O R

OPEN LOOK, 5-13, 7-13

rcs, 2-5 OPEN WINDOWS, 5-13, 7-13

recon utility, 6-5 Oraccle requirement, 2-1 remote agent

defined, 1-5 Oracle path to, 2-18 client checklist, 7-2 pinging, 4-13, 5-8, 6-16, 7-7 client installation, 7-1 port, 2-18 configuring an existing database, 3-11 See also client, 1-5 data tablespace, 3-12 service name, 2-18 environment, 1-13

environment settings, 7-11 remote command service, 2-5 index tablespace, 3-12

remove Unicenter AutoSys JM, C-1 location of files, 1-13 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

requirement SQL*Net V2, 1-13 adaptive server, 2-2 tablespace database, 2-4 data, 3-12 disk space, 2-1 index, 3-12 memory, 2-1 temporary tablespace, 3-12 Oracle, 2-1 TNS names file, 1-13 Sybase, 2-1 tnsnames.ora file, 1-13, 3-12

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 verifying database connection, 4-14, 6-17 selecting components, 2-4

SYBASE environment variable, 1-13, 3-9 server checklist, 2-21 system architecture, 1-6 configuring, 3-1

system components, 1-3 installation Oracle, 6-1 system files, changes to, 1-17 Sybase, 4-1

system requirements, 2-1 instance, 1-4 machine, 1-9

server installation, checklist example, 4-1 T server machines, 2-7

test job, creating services file Oracle, 6-19 configuring for NIS and NIS+, 3-3, 5-4 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

tnsnames.ora file, 1-13 configuring the bundled Sybase, 3-8 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

W starting, 4-9, 6-12 client installation, 5-1 configuring an existing database, 3-8

Windows NT, environment, 1-12 DSQUERY variable, 1-13 environment, 1-13 wizard setup, 2-12 environment variable, 1-13 interfaces file, 1-13, 3-9, 5-10


Documents

20596690 Autosys Job Management Unix Installation Guide