PDF TNPM Installguide

IBM Tivoli Netcool Performance Manager 1.4.
2
Wireline Component
Document Revision R2E2
Installation Guide
IBM
Note
Before using this information and the product it supports, read the information in “Notices” on page 315.
© Copyright IBM Corporation 2006, 2016.

US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Contents
About this publication . . . . . . . . vii Jazz for Service Management . . . . . . . 64
Intended audience . . . . . . . . . . . . vii Java Runtime Environment (JRE) . . . . . . 64
What this publication contains . . . . . . . . vii Web browsers and settings for DataView reports 64
Tivoli Netcool Performance Manager - Wireline X Emulation . . . . . . . . . . . . . 65
Component . . . . . . . . . . . . . . ix IBM Tivoli Netcool/OMNIbus Web GUI
The Default UNIX Shell . . . . . . . . . . x integration. . . . . . . . . . . . . . 66
Service Management Connect. . . . . . . . . x Microsoft Office Version . . . . . . . . . 66
Tivoli Netcool Performance Manager technical
training . . . . . . . . . . . . . . . . x Chapter 3. Installing and configuring
Support information . . . . . . . . . . . . x the prerequisite software . . . . . . . 67
Conventions used in this publication . . . . . . xi Overview . . . . . . . . . . . . . . . 67
Typeface conventions . . . . . . . . . . xi Oracle . . . . . . . . . . . . . . . 67
IBM DB2 . . . . . . . . . . . . . . 68
Chapter 1. Introduction . . . . . . . . 1 Supported platforms . . . . . . . . . . 69
Tivoli Netcool Performance Manager architecture . . 1 Pre-Installation setup tasks . . . . . . . . . 69
Co-location rules . . . . . . . . . . . . 3 Setting up a remote X Window display . . . . 70
Inheritance . . . . . . . . . . . . . . 4 Changing the ethernet characteristics . . . . . 71
ServerTime synchronization . . . . . . . . 5 Adding the pvuser login name . . . . . . . 74
Disk Usage Server . . . . . . . . . . . 5 Setting the resource limits . . . . . . . . 76
Notable subcomponents and features . . . . . 7 Setting the shell limits (Linux only) . . . . . 76
Typical installation topology . . . . . . . . . 26 Setting the shell limits (Solaris only) . . . . . 77
Basic topology scenario . . . . . . . . . 27 Set the system parameters . . . . . . . . 77
Intermediate topology scenario . . . . . . . 28 Enable FTP on Linux systems . . . . . . . 79
Advanced topology scenario. . . . . . . . 29 Disable SELinux (Linux only) . . . . . . . 79
High Availability . . . . . . . . . . . 30 Set the kernel parameters . . . . . . . . . 80
Replace the native taring utility with gnu tar . . 84
Chapter 2. Requirements . . . . . . . 33 Installing libcrypto.so . . . . . . . . . . 85
IBM Prerequisite Scanner . . . . . . . . . . 33 Deployer pre-requisites . . . . . . . . . . 86
Plan your installation . . . . . . . . . . . 34 Operating system check . . . . . . . . . 86
Minimum requirements for installation . . . . . 35 Mount points check . . . . . . . . . . 86
Solaris hardware requirements . . . . . . . 35 Authentication between distributed servers . . . 86
AIX hardware requirements . . . . . . . . 35 Tivoli Netcool Performance Manager distribution. . 87
Linux hardware requirements . . . . . . . 36 Downloading the Tivoli Netcool Performance
Oracle and DB2 deployment space requirements 36 Manager distribution to disk . . . . . . . 87
Screen resolution . . . . . . . . . . . 41 General database setup tasks . . . . . . . . 88
Minimum requirements for a proof of concept Asynchronous I/O Support . . . . . . . . 88
installation . . . . . . . . . . . . . . 41 Specifying a basename for DB_USER_ROOT . . 89
Solaris hardware requirements (POC). . . . . 41 Specifying login passwords . . . . . . . . 90
AIX hardware requirements (POC) . . . . . 41 Assumed values . . . . . . . . . . . . 91
Linux hardware requirements (POC) . . . . . 42 Creating group and user ID for a DB2 server
Screen resolution . . . . . . . . . . . 42 installation . . . . . . . . . . . . . 92
Supported operating systems and modules . . . . 42 Creating group and user IDs for Data Server
Solaris 10 for SPARC platforms . . . . . . . 43 Client installation . . . . . . . . . . . 94
AIX platforms . . . . . . . . . . . . 46
Linux platforms . . . . . . . . . . . . 50 Chapter 4. Installing Jazz for Service
Required user names . . . . . . . . . . . 59 Management . . . . . . . . . . . . 97
pvuser . . . . . . . . . . . . . . . 59 Hardware and software requirements for installing
oracle . . . . . . . . . . . . . . . 59 Jazz for Service Management . . . . . . . . 97
db2 . . . . . . . . . . . . . . . . 60 Getting started with Jazz for Service Management 98
Ancillary software requirements . . . . . . . 60 Preparing your environment for a full
FTP support . . . . . . . . . . . . . 60 installation of Jazz for Service Management . . 101
OpenSSH and SFTP . . . . . . . . . . 61 Preparing your environment for a custom
File compression. . . . . . . . . . . . 62 installation . . . . . . . . . . . . . 102
DataView load balancing . . . . . . . . . 62 Location of Jazz for Service Management
Databases . . . . . . . . . . . . . . 62 software . . . . . . . . . . . . . . 103
© Copyright IBM Corp. 2006, 2016 iii

Overview of Jazz for Service Management Adding the hosts . . . . . . . . . . . 155
installation . . . . . . . . . . . . . . 103 Adding a database configurations component 157
Performing an upgrade installation . . . . . 104 Adding a DataMart . . . . . . . . . . 158
Performing a fresh installation. . . . . . . 106 Adding a Discovery Server . . . . . . . . 160
Uninstalling Jazz for Service Management . . . . 109 Discovering existing Dashboard Application
Upgrading Java . . . . . . . . . . . . 109 Services Hub . . . . . . . . . . . . 161
Adding a DataView . . . . . . . . . . 162
Chapter 5. Installing database . . . . 111 Adding the DataChannel administrative
Installing Oracle 12.1.0.2 server (64-bit) . . . . . 111 components . . . . . . . . . . . . . 163
Download the Oracle distribution to disk . . . 111 Adding a DataChannel . . . . . . . . . 163
Verify the required operating system packages 112 Adding a Collector . . . . . . . . . . 166
Running the Oracle server configuration script 112 Add a Cross Collector CME . . . . . . . 170
Setting a password for the Oracle login name 116 Saving the topology . . . . . . . . . . . 171
Run the preinstallation script . . . . . . . 116 Opening an existing topology file . . . . . 172
Running the rootpre.sh script (AIX only) . . . 117 Starting the Deployer. . . . . . . . . . . 172
Verifying PATH and Environment for the Oracle Primary Deployer . . . . . . . . . . . 173
login name . . . . . . . . . . . . . 118 Secondary Deployers . . . . . . . . . . 173
Set the ORACLE_SID variable . . . . . . . 118 Pre-deployment check . . . . . . . . . 174
Installing Oracle by using the menu-based script 119 Deploying the topology . . . . . . . . . . 174
Run the root.sh script . . . . . . . . . 121 Next steps . . . . . . . . . . . . . . 176
Set automatic startup of the database instance 122 Resuming a partially successful first-time
Configure the Oracle listener . . . . . . . 123 installation . . . . . . . . . . . . . . 177
Configure the Oracle net client . . . . . . 124
Installing Oracle 12.1.0.2 client 32-bit . . . . . 126 Chapter 7. Installing as a minimal
Download the Oracle distribution to disk . . . 127 deployment . . . . . . . . . . . . 179
Run the Oracle client configuration script . . . 127 Overview. . . . . . . . . . . . . . . 179
Setting a password for the Oracle login name 130 Before you begin . . . . . . . . . . . . 179
Run the preinstallation script . . . . . . . 130 Special consideration . . . . . . . . . . 180
Verifying PATH and Environment for the Oracle Overriding default values . . . . . . . . 180
login name . . . . . . . . . . . . . 131 Installing a minimal deployment . . . . . . . 181
Installing the Oracle client (32-bit) . . . . . 132 Starting the Launchpad . . . . . . . . . 181
Run the root.sh script . . . . . . . . . 134 Start the installation . . . . . . . . . . 182
Updating the Oracle user's .profile . . . . . 135 The post-installation script . . . . . . . . . 184
Configuring the Oracle Net client . . . . . 135 Next steps . . . . . . . . . . . . . 184
Installing DB2 Server 10.1.0.5 (64-bit) . . . . . 139
Download the IBM DB2 10.1 Fix Pack 5 Chapter 8. Modifying the current
distribution to disk . . . . . . . . . . 139
Verifying the required operating system
deployment . . . . . . . . . . . . 187
packages . . . . . . . . . . . . . . 140 Opening a deployed topology . . . . . . . . 187
Installing DB2 Server 10.1.0.5 . . . . . . . 140 Adding a new component . . . . . . . . . 188
Setting up a DB2 instance . . . . . . . . 142 Changing configuration parameters of existing
Updating /etc/services file . . . . . . . 142 Tivoli Netcool Performance Manager components . 190
DB2 instance variable registry settings . . . . 142 Moving components to a different host . . . . . 190
DB2 configuration settings . . . . . . . . 143 Moving a deployed collector to a different host . . 191
Starting the DB2 instance . . . . . . . . 143 Moving a deployed SNMP collector (scenario 1) 191
Installing IBM Data Server Client 10.1.0.5 (64-bit) 143 Moving a deployed UBA bulk collector. . . . 194
Downloading the IBM Data Server Client Changing the port for a collector . . . . . . . 197
10.1.0.5 distribution to disk . . . . . . . . 143 Modifying Dashboard Application Services Hub
Installing IBM Data Server Client (64-bit) . . . 144 and Tivoli Common Reporting ports . . . . . 198
Next steps . . . . . . . . . . . . . 147 Changing ports for the Dashboard Application
Services Hub . . . . . . . . . . . . 198
Port assignments . . . . . . . . . . . 199
Chapter 6. Installing in a distributed Viewing the application server profile . . . . 199
environment . . . . . . . . . . . . 149
Distributed installation process . . . . . . . 149 Chapter 9. Using the High Availability
Starting the Launchpad . . . . . . . . . . 151
Installing the Topology Editor . . . . . . . . 152
Manager . . . . . . . . . . . . . 201
Starting the Topology Editor . . . . . . . . 154 Overview. . . . . . . . . . . . . . . 201
Creating a new topology . . . . . . . . . 154 HAM basics . . . . . . . . . . . . . . 202
Adding and configuring the Tivoli Netcool The parts of a collector . . . . . . . . . 202
Performance Manager components . . . . . . 155 Clusters . . . . . . . . . . . . . . 203
HAM cluster configuration . . . . . . . . . 203
iv IBM Tivoli Netcool Performance Manager: Installation Guide

Types of spare hosts . . . . . . . . . . 204 Appendix C. Aggregation sets . . . . 249
Types of HAM clusters . . . . . . . . . 204 Overview. . . . . . . . . . . . . . . 249
Example HAM clusters . . . . . . . . . 205 Configuring aggregation sets . . . . . . . . 249
High Availability Manager configuration changes Installing aggregation sets . . . . . . . . . 253
to accommodate multiple collector . . . . . . 210 Start the Tivoli Netcool Performance Manager
Resource pools . . . . . . . . . . . . . 211 setup program . . . . . . . . . . . . 253
How the SNMP collector works . . . . . . . 211 Set aggregation set installation parameters . . 253
How failover works with the HAM and the Edit aggregation set parameters file . . . . . 256
SNMP collector . . . . . . . . . . . . 212 Linking DataView groups to timezones. . . . . 257
Obtaining collector status . . . . . . . . 213
Creating a HAM environment . . . . . . . . 214 Appendix D. Deployer CLI options 259
Topology prerequisites . . . . . . . . . 215
Using the -DTarget option . . . . . . . . . 261
Procedures . . . . . . . . . . . . . 215
Create the HAM and a HAM cluster . . . . 215
Adding the designated spare . . . . . . . 216 Appendix E. Secure file transfer
Add the managed definitions . . . . . . . 217 installation . . . . . . . . . . . . 263
Define the resource pools . . . . . . . . 218 Overview. . . . . . . . . . . . . . . 263
Save and start the HAM. . . . . . . . . 220 Enabling SFTP . . . . . . . . . . . . . 263
Creating an additional HAM environment. . . 221 Installing OpenSSH . . . . . . . . . . . 264
Modifying a HAM environment . . . . . . . 221 AIX systems . . . . . . . . . . . . . 264
Removing HAM components . . . . . . . 221 Solaris systems . . . . . . . . . . . . 266
Stopping and restarting modified components 222 Linux systems . . . . . . . . . . . . 268
Viewing the current configuration . . . . . . 223 Configuring OpenSSH . . . . . . . . . . 268
Show Collector Process... dialog . . . . . . 223 Configuring the OpenSSH server . . . . . . 268
Show Managed Definition... dialog . . . . . 224 Configuring OpenSSH client . . . . . . . 269
Generating public and private keys . . . . . 269
Chapter 10. Uninstalling components 225 Testing OpenSSH and SFTP . . . . . . . . 272
Removing a component from the topology . . . 225 Troubleshooting . . . . . . . . . . . . 273
Restrictions and behavior . . . . . . . . 225 Tivoli Netcool Performance Manager SFTP errors 273
Removing a component . . . . . . . . . 227
Removing multiple collectors . . . . . . . 228 Appendix F. LDAP integration . . . . 275
Uninstalling the entire Tivoli Netcool Performance Supported LDAP servers . . . . . . . . . 275
Manager system . . . . . . . . . . . . 228 LDAP configuration . . . . . . . . . . . 275
Order of uninstall . . . . . . . . . . . 228 Enable LDAP configuration . . . . . . . 275
Restrictions and behavior . . . . . . . . 229 Verifying the DataView installation . . . . . 276
Performing the uninstall. . . . . . . . . 229 Assigning Tivoli Netcool Performance Manager
Uninstalling the Topology Editor . . . . . . . 230 roles to LDAP users . . . . . . . . . . 277
Removing residual files . . . . . . . . . . 231
Appendix G. Installing an interim fix 279
Appendix A. Remote installation Overview. . . . . . . . . . . . . . . 279
issues . . . . . . . . . . . . . . 235 Installation rules . . . . . . . . . . . 279
When remote install is not possible . . . . . . 235 Behavior and restrictions . . . . . . . . 279
FTP is possible, but REXEC or RSH are not . . 235 Before you begin . . . . . . . . . . . . 280
Neither FTP nor REXEC/RSH are possible . . 236 Installing a patch . . . . . . . . . . . . 280
Installing on a remote host by using a secondary
deployer . . . . . . . . . . . . . . . 236 Appendix H. Error codes and log files 283
Error codes . . . . . . . . . . . . . . 283
Appendix B. DataChannel architecture 239 Deployer messages . . . . . . . . . . 283
Data collection . . . . . . . . . . . . . 239 Topology Editor messages . . . . . . . . 296
Data aggregation . . . . . . . . . . . 239 InstallAnywhere messages . . . . . . . . 300
Management programs and watchdog scripts 240 Log files . . . . . . . . . . . . . . . 302
DataChannel application programs . . . . . 241 COI log files. . . . . . . . . . . . . 302
Starting the DataLoad SNMP collector . . . . . 243 Deployer log file . . . . . . . . . . . 302
DataChannel management components in a Eclipse log file . . . . . . . . . . . . 303
distributed configuration . . . . . . . . . 244 Trace log file . . . . . . . . . . . . 303
Manually starting the Channel Manager
programs . . . . . . . . . . . . . . 244 Appendix I. Troubleshooting . . . . . 305
Adding DataChannels to an existing system . . . 245 Deployment problems . . . . . . . . . . 305
DataChannel terminology . . . . . . . . . 246 Saving installation configuration files . . . . 307
Contents v
Tivoli Netcool Performance Manager component Appendix J. Moving DataView content
problems . . . . . . . . . . . . . . . 308 between Dashboard Application
Topology Editor problems . . . . . . . . . 308
Services Hub servers . . . . . . . . 313
Tivoli Netcool Performance Manager DB2 database
The synchronize command . . . . . . . . . 313
schema fails . . . . . . . . . . . . . . 308
Telnet problems . . . . . . . . . . . . 309
Java problems . . . . . . . . . . . . . 309 Notices . . . . . . . . . . . . . . 315
Testing connectivity to the database . . . . . . 310 Trademarks . . . . . . . . . . . . . . 317
Testing external procedure call access . . . . . 310 Terms and conditions for product documentation 318
vi IBM Tivoli Netcool Performance Manager: Installation Guide

About this publication
IBM® Tivoli® Netcool® Performance Manager, Version 1.4.2 is a bundled product
consisting of two main components. A wireline component (formerly Tivoli
Netcool/Proviso), and a wireless component (formerly Tivoli Netcool Performance
Manager for Wireless).
The Installing Tivoli Netcool Performance Manager - Wireline Component tells you
how to install and configure Tivoli Netcool Performance Manager by using Oracle
and DB2® databases.
Note: If you are upgrading Tivoli Netcool Performance Manager, see the IBM
Tivoli Netcool Performance Manager Upgrade Guide - Wireline component.
Important: Before installing Tivoli Netcool Performance Manager, you are advised
to read the Installing Tivoli Netcool Performance Manager - Wireline Component.
Release notes can contain information specific to your installation that is not
contained in this guide. Failure to consult the release notes might result in a
corrupted, incomplete, or failed installation.
Intended audience
This information is intended for:
The audience who are network administrator or operations specialist responsible

for installing the Tivoli Netcool Performance Manager product suite on an
enterprise network.
To install Tivoli Netcool Performance Manager successfully, you must have a

thorough understanding of the following subjects:
v Basic principles of TCP/IP networks and network management
v SNMP concepts
v Administration of the Linux, Solaris, or AIX operating environment
v Administration of the Oracle database management system
v Administration of the IBM DB2 database management system
v Tivoli Netcool Performance Manager
What this publication contains

This publication contains the following sections:
v Chapter 1, “Introduction,” on page 1 this chapter provides an overview of the
Tivoli Netcool Performance Manager product suite and provides important
pre-installation setup information.
v Chapter 2, “Requirements,” on page 33 this chapter describes the complete set of
requirements for Tivoli Netcool Performance Manager 1.4.2
v Chapter 3, “Installing and configuring the prerequisite software,” on page 67
this chapter describes how to install and configure the Tivoli Netcool
Performance Manager 1.4.2
© Copyright IBM Corp. 2006, 2016 vii

v Chapter 4, “Installing Jazz for Service Management,” on page 97 this chapter
describes the Dashboard Application Services Hub administration tasks that
include setting up the console, managing users, exporting and importing data.
v Chapter 5, “Installing database,” on page 111 this chapter to install the Oracle
and DB2 database for Tivoli Netcool Performance Manager.
v Chapter 6, “Installing in a distributed environment,” on page 149
this chapter describes installation of Tivoli Netcool Performance Manager for the
first time in a fresh, distributed environment.
v Chapter 7, “Installing as a minimal deployment,” on page 179
this chapter describes the install Tivoli Netcool Performance Manager as a
minimal deployment.
v Chapter 8, “Modifying the current deployment,” on page 187
For this chapter describes how to modify an installation of Tivoli Netcool
Performance Manager.
v Chapter 9, “Using the High Availability Manager,” on page 201
this chapter describes the optional Tivoli Netcool Performance Manager. High
Availability Manager (HAM), including how to set up a HAM environment.
v Chapter 10, “Uninstalling components,” on page 225
this section provides information on how to uninstall components.
v Appendix A, “Remote installation issues,” on page 235 this chapter describes the
support for remote installation of all Tivoli Netcool Performance Manager
components.
v Appendix B, “DataChannel architecture,” on page 239 this chapter provides
detailed information about the DataChannel architecture.
v Appendix C, “Aggregation sets,” on page 249 this chapter describes the
configuration and installation of aggregation sets.
v Appendix D, “Deployer CLI options,” on page 259 this chapter describes about
the CLI options and their description.
v Appendix E, “Secure file transfer installation,” on page 263 this chapter describes
the OpenSSH installation, configuration, and testing process in detail for each
platform.
v Appendix F, “LDAP integration,” on page 275 this chapter describes in detail on
how to configure LDAP (Lightweight Directory Access Protocol) as a default
authentication/authorization mechanism for Tivoli Netcool Performance
Manager.
v Appendix G, “Installing an interim fix,” on page 279 this appendix describes
how to install an interim fix (or patch) release of Tivoli Netcool Performance
Manager.
v Appendix H, “Error codes and log files,” on page 283 this appendix lists the
Tivoli Netcool Performance Manager error messages and log files.
v Appendix I, “Troubleshooting,” on page 305 this appendix lists the problems that
might occur during an installation and how to resolve them.
v Appendix J, “Moving DataView content between Dashboard Application Services
Hub servers,” on page 313
viii IBM Tivoli Netcool Performance Manager: Installation Guide

Tivoli Netcool Performance Manager - Wireline Component
IBM Tivoli Netcool Performance Manager consists of a wireline component
(formerly Netcool/Proviso) and a wireless component (formerly Tivoli Netcool
Performance Manager for Wireless).
Tivoli Netcool Performance Manager - Wireline Component consists of the

following subcomponents:
v DataMart is a set of management, configuration, and troubleshooting GUIs. The
Tivoli Netcool Performance Manager System Administrator uses the GUIs to
define policies and configuration, and to verify and troubleshoot operations.
v DataLoad provides flexible, distributed data collection and data import of SNMP
and non-SNMP data to a centralized database.
v DataChannel aggregates the data collected through Tivoli Netcool Performance
Manager DataLoad for use by the Tivoli Netcool Performance Manager
DataView reporting functions. It also processes online calculations and detects
real-time threshold violations.
v DataView is a reliable application server for on-demand, web-based network
reports.
v Technology Packs extend the Tivoli Netcool Performance Manager system with
service-ready reports for network operations, business development, and
customer viewing.
The following figure shows the different Tivoli Netcool Performance Manager
modules.
Tivoli Netcool Performance Manager documentation consists of the following:

v Release notes
v Configuration recommendations
v Installation and upgrade information
v User guides
v Technical notes
v Online help
About this publication ix

The documentation is available for viewing and downloading on the information
center at http://www-01.ibm.com/support/knowledgecenter/SSBNJ7/welcome.
The Default UNIX Shell

The installation scripts and procedures in this manual generally presume, but do
not require, the use of the Korn or Bash shells, and only Korn shell syntax is
shown in examples.
If you are a user of the C shell or Tcsh, make the necessary adjustments in the
commands shown as examples throughout this manual.
This guide uses the following shell prompts in the examples:

v # (pound sign) indicates commands you perform when logged in as root.
v $ (dollar sign) indicates commands you perform when logged in as oracle for
Oracle database or db2 for IBM DB2 database or pvuser.
v SQL> indicates commands you perform SQL*Plus prompt.
v clpplus indicates the command line processor plus that provides a
command-line user interface that you can use to connect databases and to
define, edit, and run statements, scripts, and commands.
Service Management Connect

Connect, learn, and share with Service Management professionals: product support
technical experts who provide their perspectives and expertise.
Access Network and Service Assurance community at https://www.ibm.com/

developerworks/servicemanagement/nsa/index.html. Use Service Management
Connect in the following ways:
v Become involved with transparent development, an ongoing, open engagement
between other users and IBM developers of Tivoli products. You can access early
designs, sprint demonstrations, product roadmaps, and prerelease code.
v Connect one-on-one with the experts to collaborate and network about Tivoli
and the Network and Service Assurance community.
v Read blogs to benefit from the expertise and experience of others.
v Use wikis and forums to collaborate with the broader user community.
Related information:
Tivoli Netcool Performance Manager 1.4 community on developerWorks
Tivoli Netcool Performance Manager technical training

For Tivoli Netcool Performance Manager technical training information, see the
following Tivoli Netcool Performance Manager Training website at:
https://tnpmsupport.persistentsys.com/training.
Support information
If you have a problem with your IBM software, you want to resolve it quickly. IBM
provides the following ways for you to obtain the support you need:
Online
Access the IBM Software Support site at http://www.ibm.com/software/
support/probsub.html .
x IBM Tivoli Netcool Performance Manager: Installation Guide

IBM Support Assistant
The IBM Support Assistant is a free local software serviceability workbench
that helps you resolve questions and problems with IBM software
products. The Support Assistant provides quick access to support-related
information and serviceability tools for problem determination. To install
the Support Assistant software, go to http://www.ibm.com/software/
support/isa.
Troubleshooting Guide
For more information about resolving problems, see the problem
determination information for this product.
Conventions used in this publication

Several conventions are used in this publication for special terms, actions,
commands, and paths that are dependent on your operating system.
Typeface conventions
This publication uses the following typeface conventions:
Bold
v Lowercase commands and mixed case commands that are otherwise
difficult to distinguish from surrounding text
v Interface controls (check boxes, push buttons, radio buttons, spin
buttons, fields, folders, icons, list boxes, items inside list boxes,
multicolumn lists, containers, menu choices, menu names, tabs, property
sheets), labels (such as Tip:, and Operating system considerations:)
v Keywords and parameters in text
Italic
v Citations (examples: titles of publications, diskettes, and CDs)
v Words defined in text (example: a nonswitched line is called a
point-to-point line)
v Emphasis of words and letters (words as words example: "Use the word
that to introduce a restrictive clause."; letters as letters example: "The
LUN address must start with the letter L.")
v New terms in text (except in a definition list): a view is a frame in a
workspace that contains data.
v Variables and values you must provide: ... where myname represents....
Monospace
v Examples and code examples
v File names, programming keywords, and other elements that are difficult
to distinguish from surrounding text
v Message text and prompts addressed to the user
v Text that the user must type
v Values for arguments or command options
Bold monospace
v Command names, and names of macros and utilities that you can type
as commands
v Environment variable names in text
v Keywords
About this publication xi

v Parameter names in text: API structure parameters, command
parameters and arguments, and configuration parameters
v Process names
v Registry variable names in text
v Script names
xii IBM Tivoli Netcool Performance Manager: Installation Guide

Chapter 1. Introduction
Introduction to Tivoli Netcool Performance Manager installation.
This information provides an overview of the Tivoli Netcool Performance Manager

product suite and provides important pre-installation setup information. In
addition, this information provides an overview of the installation interface
introduced in version 1.4.2.
Tivoli Netcool Performance Manager 1.4.2 supports both Oracle and DB2
databases.
Attention: DB2 is supported on Linux only. Whereas, Oracle is supported on

Solaris, AIX®, and Linux systems.
Tivoli Netcool Performance Manager architecture

Tivoli Netcool Performance Manager system components.
The Tivoli Netcool Performance Manager components run on:
v SPARC-based servers from Oracle that run the Solaris operating

system
v servers from IBM
v servers
Exact, release-specific requirements, prerequisites, and recommendations for

hardware and software are described in detail in the Requirements topic.
You can work with Professional Services to plan and size the deployment of Tivoli
Netcool Performance Manager components in your environment.
The following diagram provides a high-level overview of the Tivoli Netcool

Performance Manager architecture.
© Copyright IBM Corp. 2006, 2016 1

The Tivoli Netcool Performance Manager system components are as follows:
v Tivoli Netcool Performance Manager database - The Tivoli Netcool
Performance Manager database is hosted on Oracle or IBM DB2.
v Tivoli Netcool Performance Manager DataMart - Tivoli Netcool Performance
Manager DataMart is the user and administrative interface to the Tivoli Netcool
Performance Manager database and to other Tivoli Netcool Performance
Manager components.
v Tivoli Netcool Performance Manager DataLoad - Tivoli Netcool Performance
Manager DataLoad consists of one or more components that collect network
statistical raw data from network devices and from network management
systems.
v Tivoli Netcool Performance Manager DataChannel - Tivoli Netcool
Performance Manager DataChannel is a collection of components that collect
data from DataLoad collectors, aggregate and process the data, and load the
data into the Tivoli Netcool Performance Manager database. DataChannel
components also serve as the escalation point for collected data that is
determined to be over threshold limits.
v Tivoli Netcool Performance Manager DataView - Tivoli Netcool Performance
Manager DataView is the web server that hosts and analyzes platform. This
platform is used to display web-based management reports based on network
data that is aggregated and placed in the Tivoli Netcool Performance Manager
database.
v Tivoli Netcool Performance Manager Technology Packs - Each technology pack
is a set of components that describes the format and structure of network
statistical data that is generated by network devices. Each technology pack is
specific for a particular device, or class of devices; or for a particular company's
devices; or for a protocol (such as standard SNMP values) common to many
devices.
v Dashboard Application Services Hub - The Dashboard Application Services
Hub application provides a database-aware web server foundation for the
web-based management reports displayed by Dashboard Application Services
Hub DataView.
2 IBM Tivoli Netcool Performance Manager: Installation Guide

Platform support
All subcomponents of the Tivoli Netcool Performance Manager - Wireline

Component can be installed on a mix of AIX, Linux, and Solaris operating systems;
that is, the operating systems on which the DataChannel, DataView, DataLoad, and
DataMart subcomponents are installed do not have to be of the same type.
Note: Dataview cannot be installed on a Solaris system as Jazz™ for Service

Management 1.1.2.1 is not supported on Solaris.
Co-location rules
Allowed component deployment numbers and co-location rules.
Table 1 lists how many of each component can be deployed per Tivoli Netcool
Performance Manager system and whether multiple instances can be installed on
the same server.
In this table:
v N - Depends on how many subchannels there are per channel, and how many
channels there are per system. For example, if there are 40 subchannels per
channel and 8 channels, theoretically N=320. However, the practical limit is
probably much lower.
v System - The entire Tivoli Netcool Performance Manager system.
v Per host - A single physical host can be partitioned using zones, which
effectively gives you multiple hosts.
Note: All CME, DLDR, FTE, and LDR components within a channel must share
the same filesystem.
Table 1. Co-location rules
Co-Location
Constraints
Number of Instances Co-Location Supported by
Component Allowed Constraints Deployer?
AMGR One per host that Yes
supports
DataChannel
components
BCOL v N per system Yes
v One per
corresponding
subchannel
CME One per subchannel Filesystem Yes
CMGR One per system Yes
Database One per system Yes
Database channel One per Yes
DataChannel;
maximum of 8
Chapter 1. Introduction 3
Table 1. Co-location rules (continued)
Co-Location
Constraints
Number of Instances Co-Location Supported by
Component Allowed Constraints Deployer?
DataLoad (SNMP v N per system Yes
collector)
v One per
corresponding
subchannel
v One per host
DataMart v N per system Yes
v One per host
DataView v N per system One per system.
v One per host
Discovery Server v N per system Co-locate with Yes
corresponding
v One per host
DataMart
DLDR One per channel Filesystem Yes
FTE One per subchannel Filesystem Yes
HAM N +M per system, Yes
where N is the
number of collectors
that HAM is
monitoring, and M is
the number of
standby collectors
LDR One per channel Filesystem Yes
Log One per system Yes
UBA (simple) v N per system Yes
v One per
corresponding
subchannel
UBA (complex) Pack-dependent Pack-dependent Pack-dependent
v In the Logical view of the Topology Editor, the DataChannel component contains
the subchannels, LDR, and DLDR components, with a maximum of 8 channels
per system. The subchannel contains the collector, FTE, and CME, with a
maximum of 40 subchannels per channel.
Inheritance
Inheritance is the method by which a parent object propagates its property values
to a child component.
The following rules should be kept in mind when dealing with these properties.
v A Child Property can be read only, but is not always.
v If the Child Property is not read only, then it can be changed to a value different
from the Parent Property.
v If the Parent Property changes, and the Child and Parent properties were the
same before the change, then the child property will be changed to reflect the
new Parent Property value

v If the Child Property changes, the Parent Property value will not be updated
v The Default Value of the Child Property is always the current Parent Property
value
Note: When performing an installation that uses non-default values, that is,
non-default usernames, passwords and locations, it is recommended that you
check both the Logical view and Physical view to ensure that they both contain the
correct values before proceeding with the installation.
Example
As an example of how a new component inherits property values:
The Disk Usage Server (DUS) is a child component of the Host object. The DUS
Remote User property inherits its value from the Host PV User Property on
creation of the DUS. The DUS property value will be taken from the Host property
value.
Child properties that have been inherited are marked as inherited.
As an example of what happens when you change inherited property values:
If we change the Host PV User Property value, it gets pushed down to the DUS
Remote User property value, updating it. The associated Default Value is also
updated.
If we change the DUS Remote User property value, that is the child value, it does
not propagate up to the host; the parent Host PV User Property value remains
unchanged.
Now the child and parent properties are out of sync, and if we change the parent
property value it is not reflected in the child property, though the default value
continues to be updated.
ServerTime synchronization
Sever synchronization requirements.
Tivoli Netcool Performance Manager requires that the clocks on all Solaris servers
running Tivoli Netcool Performance Manager modules be synchronized. IBM
recommends using NTP (or equivalent) to keep all Tivoli Netcool Performance
Manager synchronized to within 500 milliseconds.
Disk Usage Server

This Disk Usage Server component is responsible for maintaining the properties
necessary for quota management (flow control) of DataChannel.
The DataChannel component requires a Disk Usage Server. This component is

responsible for maintaining the properties necessary for quota management (flow
control) of DataChannel. DataChannel components can only be added to hosts that
include a Disk Usage Server.
Multiple Disk Usage Servers can be configured per host; therefore, allowing
multiple DataChannel directories to exist on a single host. There are two major
reasons why a user may want to configure multiple Disk Usage Servers:
Disk space is running low
Disk space may be impacted by the addition of a new DataChannel
component. In which case, the user may want to add a new file system
managed by a new Disk Usage Server
Separate disk quota management
The user may want to separately manage the quotas assigned to discrete
DataChannel components. For more information, see “Disk quota
management.”
The user can assign the management of a new file system to a Disk Usage Server
by editing the local_root_directory property of that Disk Usage Server using the
Topology Editor. The user can then add DataChannel components to the host, and
can assign the component to a Disk Usage Server, either in the creation wizard or
by editing the DUS_NUMBER property inside the component.
Disk quota management

Disk Quota Management description.
The addition of a Disk Usage Server endeavors to make the process of assigning
space to a component much easier than it has been previously. No longer is a user
required to calculate the requirements of each component and assign that space
individually, but components now work together to more effectively utilize the
space they have under the Disk Usage Server. Also, the user is relieved of trying to
figure out which component needs extra space and then changing the quota for
that component. Now, the user can just change the quota of the DUS and all
components on that Disk Usage Server will get the update and share the space on
an as needed basis.
Good judgement of space requirements is still needed. However, the estimating of

space requirements is being made at a higher level; and if an estimate is incorrect,
only one number needs to be changed instead of potentially updating the quota for
each component separately.
Flow control
Flow Control description.
Optimized flow control further eliminates problems with component level quotas.
Each component holds on to only a five hours of input and output, and once it has
reached this limit, it stops processing until the downstream component picks up
some of the data. This avoids the cascading scenario where one component stops
processing and the components feeding it begin to stockpile files, which results in
the quota being filled and causes all components to shut down because they have
run out of file space.
Installation or topology considerations

Installation or Topology considerations for flow control.
DataChannel components can only be added to hosts that include a Disk Usage
Server.

Notable subcomponents and features
The following sections describe a subset of the Tivoli Netcool Performance
Manager that should be considered before deciding on your topology
configuration.
DataLoad
The following sections provide information on the supported architecture
configurations of DataLoad.
Collectors:
Collectors description.
The DataLoad collector takes in the unrefined network data and stores it in a file
that Tivoli Netcool Performance Manager can read. This file is known as a binary
object format file (BOF).
The following processes are employed in the DataLoad module:

v SNMP Collector - The DataLoad SNMP Collector sends SNMP requests to
network objects. Only the data requested by the configuration that was defined
for those network objects is retrieved.
v Bulk Collector - The Bulk Collector uses a Bulk Adaptor, which is individually
written for specific network resources, to format the unrefined data into a file,
called a PVline file, which is passed to the Bulk Collector.
Multiple SNMP DataLoad collectors:
You can install multiple SNMP DataLoad collectors on the same host
In Tivoli Netcool Performance Manager 1.4.2, you can have multiple collectors per
host. This helps in reducing the server resources required. In certain customer sites,
they have up to 40 SNMP collectors that required 40 hosts (any of which might be
virtual hosts). In the current scenario multiple collectors are allowed on a single
host, which reduces the number of servers (physical or virtualized) but does not
change the disk or CPU requirements. A maximum of 16 collectors can be
configured on a single host. However, each multiple collector that is added
requires 4 GB RAM for efficient functioning.
This makes the solution cost-effective with minimum changes to the topology to
accommodate this for service providers with their current network and also for
service providers with growing networks.
CPU improvements came in the form of faster cores but now come as multiple
cores. This change in computer hardware architecture drives changes in how Tivoli
Netcool Performance Manager scales. Tivoli Netcool Performance Manager used to
scale by adding “commodity hardware” so you did not frequently encounter the
scenario where it was not necessary to put multiple SNMP DataLoad collectors on
a single box but now the “commodity hardware” is frequently a 4-16 core machine.
So this change adds value to Tivoli Netcool Performance Manager scalability.
This scenario results in:

v Reduction in number of operating system instances
v Reduction in related licensing, support, and maintenance costs
v Ease in handling the upgrade process
Installation or topology considerations:
Installation and topology considerations for collectors.
The DataLoad modules can be loaded on lightweight servers and placed as close to
the network as possible (often inside the network firewall). Because a DataLoad
module does not contain a database, the hardware can be relatively inexpensive
and can still reliably handle high volumes of data. The number of collectors is in
turn driven by the number of required Technology Packs.
Up to 320 DataLoad modules can be supported per Tivoli Netcool Performance

Manager installation.
The number of collectors in your system affect the topology configuration. You can
have multiple BULK collectors, UBA or BCOL, on a single host. Starting from
Tivoli Netcool Performance Manager 1.4.2, you can add and configure multiple
SNMP collectors on the same host. Following is the server deployment for multiple
SNMP DataLoad collectors.
Two servers with four DataChannels and four SNMP Collectors Topology.

DataChannel
configurations of DataChannel.
DataChannel subchannels:
Subchannel support.
Datachannel limit is increased from 8 to 16 in Tivoli Netcool Performance Manager

1.4. Tivoli Netcool Performance Manager supports up to 40 subchannels per
database channel.
DataChannel remote:
Supported DataChannel deployment types.
Tivoli Netcool Performance Manager supports two deployment types for

DataChannel:
v DataChannel Standard, usually deployed on the central site. This requires the
standard DataChannel module.
v DataChannel Remote Channel option, where the Sub-Channel component (also
called CME) is split from the rest of the central DataChannel and deployed on
the remote DataLoad server (usually on a remote site, behind a fire-wall).
This option is primarily intended for Managed Network Service Providers who
need to place the DataChannel component at an end-user site, co-located with the
data collector. The benefits of the DataChannel Remote option are:
v Allows Managed Network Service Providers to better align costs with revenues
as they scale their systems to support more end customers.
v Improves distributed Fault management
v Closer to alarm receiver and correlation
v Threshold detection resistant to disconnection
v Reduces hardware costs
v Leverages available CPU if remote DataLoad under loaded (unused CPU can be
used by DataChannel remote - CME)
Please refer to “SNMP version support” on page 26 for more information about
this option.
The following sections describe both deployment types in more detail.
DataChannel "Standard":
Standard DataChannel installation.
DataChannel "Standard", usually deployed on the central site. This requires the
standard DataChannel module.
DataChannel Standard Installation
For firewall configuration recommendations, see “Firewall configuration” on page
16.
DataChannel “Remote Channel Option”:
DataChannel remote installation.
In this mode, Tivoli Netcool Performance Manager allows the CME to be installed
on a remote system away from the rest of the DataChannel components (such as
customer premise equipment).
The DataChannel Remote system is composed of the following elements and obeys
the stated execution order:
1. Collector
2. File Transfer Engine
3. Complex Metric Engine
All DataChannel Remote elements must be installed on the same server and file
system.
Multiple DataChannel Remote systems can plug into the DataChannel system,
which is composed of the following elements and obeys the following order of
execution:
Loader Staging, which inovlves either of the following:

v Daily Loader: interacts with the Database Server
v Hourly Loader: interacts with the Database Server
Tivoli Netcool Performance Manager on Solaris 10:
Options when deploying Tivoli Netcool Performance Manager on Solaris.
This section describes some basic scenarios for introducing Tivoli Netcool
Performance Manager into the Solaris 10 operating environment, and options for
deploying Tivoli Netcool Performance Manager modules within Solaris 10
containers. It is not an attempt to describe all possible deployment options.

Multiple SNMP collectors are supported on the same Solaris 10 server, as long as
each collector is isolated in a separate Solaris 10 container.
Note: Do not install more than one DataLoad SNMP collector in any given Solaris
10 container. Installing two or more collectors in a container will cause
performance to degrade due to those collectors competing for CPU resources.
With the one exception noted above, all deployments of Tivoli Netcool
Performance Manager modules within Solaris 10 containers are possible - for
example:
v All modules can be installed within a single container on the same Solaris 10
server.
v Each module can be installed in a separate container on separate Solaris 10
servers.
v Any combination of module deployments in between the above deployments is
also possible (with the exception of the SNMP collector restriction noted above).
Note: In configuring Solaris containers for each Tivoli Netcool Performance

Manager component, follow the limitations for server CPU, disk, and memory
documented for those components.
New installs on Solaris 10:
A scenario, which describes a possible deployment of Tivoli Netcool Performance

Manager.
In this scenario, a customer is installing Tivoli Netcool Performance Manager at

their site for the first time, and chooses to do so on a Solaris 10 server.
The possible deployment of Tivoli Netcool Performance Manager modules on a

single Solaris 10 server is:
v DataLoad (DL)
v DataChannel (DC)
v DataMart (DM)
v Database (DB)
Note: DataView (DV) installation is only supported on RHEL and AIX.
Tivoli Netcool Performance Manager inventory deployment:
Tivoli Netcool Performance Manager supports an architecture for the Inventory

process.
Tivoli Netcool Performance Manager supports an architecture for the Inventory

process, which is especially evident at the SNMP Discovery level. The SNMP
Discovery portion of inventory collection is implemented as a permanently
running process (a daemon).
The new Inventory architecture provides several benefits:

v The logic for defining Element uniqueness rules, as well as Element "correlation"
(when the same network Element is discovered several times from several of its
interfaces) is now exposed (in the file inventory_elements.txt). This enables
you to adapt the rules for Elements that do not support the expected MIB
variables (the one Tivoli Netcool Performance Manager uses to implement the
uniqueness and correlation rules).
v The Inventory GUI supports several features, typically implemented with hook
scripts. The new architecture makes the hook scripts simpler and more
maintainable.
v Log messages issued by the Discovery process now comply with the centralized
LOG mechanism (that is, support has been added for logging to syslog).
The following sections explain the supported Inventory deployments (BULK and
SNMP) and help you making deployment choices related to the SNMP Discovery
server.
Tivoli Netcool Performance Manager Inventory is made up of Discovery,

Synchronization, and Grouping phases.
Content of the SNMP inventory component:
Requirements of the SNMP Inventory Component.
The SNMP Inventory component is made up of the following:

v Inventory CLI and Inventory GUI (profile management, as in 3.x)
v 4.0 SNMP Discovery server
v Hook scripts
The SNMP Inventory component is installed by the DataMart installation - except

the new 4.0 SNMP Discovery server, which is part of the DataChannel installation.
The SNMP Inventory component (especially the SNMP Discovery process) is

usually unique for the entire Tivoli Netcool Performance Manager system, and can
serve multiple SNMP Collectors.
However, if several SNMP Inventory components must be installed, they cannot be

installed on the same machine. In this case, you must install the entire DataMart
component on each machine.
For performance reasons. This configuration is unlikely given the low impact of
the Inventory process on the overall system.
Content of the BULK inventory component:
Requirements of the BULK Inventory Component.
The BULK Inventory process is made up of:

v Inventory CLI and Inventory GUI (profile management, as in 3.x)
v Cron'ed CLI pollinv
v Cron'ed CLI pollprofile
v Hook scripts
The BULK Inventory component is installed by the DataMart installation.
As will be explained in the following deployment scenarios, there cannot be

connectivity issues between Bulk Collector and BULK Inventory. Therefore, IBM
recommends the following approach:

v Bulk Collector and BULK Inventory should never be separated by a WAN
and/or firewall, NAT, or any component that may hinder the connection.
Note: These configurations (WAN, Firewall, or NAT) are not supported.

v For a critical use of the Bulk collector (for example, expected service levels,
billing, and so on), IBM recommends that you install a Bulk Inventory on the
same machine. In this case, you must run the DataMart installation as many
times as there are Bulk collectors.
v For a standard use of the Bulk collector, IBM recommends that you install a
unique Bulk Inventory on the DataMart machine. In this case, there should be a
very reliable connection between the Bulk Inventory and the Database, and
between the Bulk Inventory and the Bulk Collector (LAN).
DataChannel Central and Bulk Collector central:
Deployment configurations.
The deployment shown in the following figure is characterized by:

v DataChannel deployed centrally (Standard)
v BULK deployed centrally for critical usage
DataChannel Central and Bulk Collector Central (Critical)

v BULK deployed centrally for standard usage
DataChannel Central and Bulk Collector Central (Standard)
DataChannel Remote and Bulk Collector remote:
DataChannel Remote and Bulk Collector Remote
When DataChannel Remote is deployed (remotely), in order to process data flow

generated by a bulk collector, the same machine needs to support:
v Remote Sub-channel
v Remote Bulk Collector
v Remote Bulk Inventory
DataChannel Central and Bulk Collector remote:

v BULK deployed remotely
DataChannel Central and Bulk Collector Remote

Tivoli Netcool Performance Manager does not support Bulk Inventory processes
being on the other side of the firewall or though a WAN, compared to Bulk
Collector, as shown in the following figure:
Figure 6: Unsupported Firewall Configuration
DataChannel Central, SNMP Collector remote, and SNMP inventory central:

v SNMP collector deployed remotely
v SNMP Inventory deployed centrally
DataChannel Central, SNMP Collector Remote, and SNMP Inventory Central
DataChannel and SNMP Collector remote, and SNMP inventory central:
This deployment is characterized by:

v DataChannel deployed remotely
v SNMP collector deployed remotely
v SNMP Inventory deployed centrally
Figure 8: DataChannel and SNMP Collector Remote, and SNMP Inventory Central
Links to further information.

v For more information on collectors and inventory deployments, see the
"Configuring the Discovery Server" section in the Installing Tivoli Netcool
Performance Manager - Wireline Component
v For firewall recommendation related to the SNMP Discovery Server, see “SNMP
inventory” on page 24.
Firewall configuration:
Firewall Configuration.
The following sections explain firewall configurations.
DataChannel standard:
Firewall support for a DataChannel standard configuration.
This section explains Tivoli Netcool Performance Manager firewall support, and
the protocols to open through them. The direction of the connection opening is
shown by the following arrows.
Note: Modules are also centrally managed, so the management protocols also need
to open through the firewalls.
As shown in the following figure, aside from file transfer and database
connectivity, management protocols need to pass through the firewalls. DataMart,
using the internal 3002 protocol, manages SNMP Collectors. The Channel
Management modules, through CORBA, manage the Bulk Collectors and the
DataChannel modules. Additionally, these modules log through UDP to a remote
logger.
Note: You can use a different port other than port 3002.
Protocols Through Firewalls - DataChannel Standard

Channel management overview:
Channel management module communication.
The Channel Management modules communicate between machines supporting

the DataChannels, and these modules are the components that need static ports.
The set of management modules for all DataChannels includes a Channel Manager,
a Channel Name Server, a Log Server, and one Application Manager for each
machine supporting the DataChannels, Bulk Collectors, and the Discovery server.
For restrictive firewalls, the protocols used by these components need to be set
statically and the firewalls must be configured to allow these protocols through.
The Topology Editor can be used to statically set many of these ports.
Important: The Topology Editor can set the CORBA port for the management
components (except the log server, which does not use CORBA), but not for the
regular components (CMEs and FTEs, for example). Normally, the CORBA ports
for regular components are dynamic, because they communicate only with the
AMGR, which is on the same machine and not affected by firewalls.
Configuring a static port:
Configuring static ports by using the Topology Editor.
About this task
When you upgrade from an existing installation or installing for the first time, you
can configure the static ports by using the Topology Editor.
Note: If you have an installation configuration file, you can use it when you run
the Topology Editor. Or, you can re-enter all relevant information and save the
installation configuration file and use it for the next time you upgrade.
To configure static ports, follow these steps:
Procedure
1. Determine which ports you can set statically. For more information,
see.“Choosing static ports” on page 18. Open these ports in the appropriate
firewalls.
2. Set the ports for the following protocols in the Topology Editor:
v Log Server port
v IOR Server port
v Name service port
v Channel Manager CORBA port
v For each host: the Application Manager CORBA port
v For each Sub-Channel component: the trap port
Note: There are other protocols that you must open in the firewall that is not
configured here.
3. Install the DataChannel. Save the installer configuration file.
4. For each Bulk Collector that is running in DISCOVERY_MODE==noinventory,
manually edit the topology and add 3002_SERVICE_PORT for each Collector. For
example, BCOL.2.36.3002_SERVICE_PORT=4003
5. Restart the channel management and the channels.
DataView and DataMart also need ports that are opened in the firewall
see,“Standard Deployment of DataChannel” on page 19. See the DataView and
DataMart documentation for information about configuring ports, if necessary.
What to do next
For information on assigning static ports to some DataChannel components, see

Assigning static port to some DataChannel components on remote server
Assigning static port to some DataChannel components on remote server:
When the FTE and CME components are on remote DataChannel server, a static
port must be configured. Then, the FTE is able to communicate with PBL from the
local DataChannel.
Each component listens for inbound CORBA communications. By default, a

random port is selected and the port gets registered in the CNS shortly after
startup. You can override the default port by using the following configuration
setting:
PBL.CORBA_PORT = <port_number>
For example: PBL.CORBA_PORT = 9007
Note: This configured port must be allowed to access through the firewall.
Choosing static ports:
Choosing Static Ports.
About this task
You need to choose which ports to use. Ask your Network Administrator for these
ports or choose the ports yourself, based on “Standard Deployment of
DataChannel” on page 19. Some ports used by Tivoli Netcool Performance
Manager are standard ports, like FTP. Other ports you need to choose. You can use
the same port on different machines. For example, you can assign the same port to
all Application Managers.
There are several places you can look to see if a given port is already in use. First
choose the range, then check to see if it is in use.
When selecting ports, follow these guidelines:

v Choose your ports from the range 1024 to 32767. The other ranges are reserved
(or sometimes used) for other applications. Ports 1 to 1023 are reserved ports
and ports 32768 to 65535 are ephemeral ports.
v Check the file /etc/services on each machine and see if any of these ports are
being used by a different application
v As a fail-safe, run netstat -a to see if this port is in use by other applications.
Make sure the DataChannels and Channel Management are not running when
you check.
Active and Passive FTP (Alcatel-Lucent 5620 SAM technology pack only):
Alcatel-Lucent 5620 SAM Technology Pack support.
The Alcatel-Lucent 5620 SAM Technology Pack supports both active and passive
FTP through the firewall.
Use the following guidelines when specifying passive or active data transfer mode
in URI (Universal Resource Identifier) specifications:
v By default, the Alcatel-Lucent 5620 SAM uses active connections (traditional FTP
mode). You can, however, explicitly specify active data transfer mode by
appending ;mode=active to the end of the FTP (File Transfer Protocol) URI
(Universal Resource Identifier) as in the following example:
ftp://loginname:password@hostname//full/path/to/resource;mode=active
v To use passive data transfer mode, you must explicitly specify passive mode by
appending ;mode=passive to the end of the FTP URL as in ther following
example:
ftp://loginname:password@hostname//full/path/to/resource;mode=passive
For information on recommended ports, see the following URL:http://

slacksite.com/other/ftp.html
Standard Deployment of DataChannel:
Describes the standard deployment of Datachannel.
The following table lists the module-to-protocol mappings for the standard
deployment of DataChannel.
Note the following:

v The cells marked with an "X" identify the modules that are communicating with
one another.
v FM represents the TRAP receiver of the Fault Management external station. This
is not a Tivoli Netcool Performance Manager module.
Module-to-Protocol Mapping For DataChannel Standard Deployment

Port Type /
Dev DL DC DM DB DV WEB FM Module/ Pair Protocol Port # Dir. Property Setting in Topology Editor
X X SNMP Device SNMP for Static UDP 161 ◄►
- SNMP collection
DataLoad
X X Bulk Device - FTP or TFTP Device ►
Bulk DataLoad or other dependent
protocol
Port Type /
X X SNMP FTP for Static, ◄
DataLoad - collection non-
DataChannel configurable
TCP 20, 21 or
sFTP/TCP 22
X X SNMP Channel Static, ◄ For each SNMP Collector:
DataLoad - Manager configurable PVM_SNMP_COLL_SSDPORT=3002
DataChannel access to TCP 3002 PVM_SSDPORT=3002 (These are
SNMP Coll. entered using SERVICE_PORT in the
For Real Time Topology Editor: DataChannel >
Admin Components > Channel
Manager and DataChannel > Admin
Components > CORBA Naming
Server Host)
X X Bulk DataLoad FTP metric Static, ◄ See the Technical Note Tivoli
- DataChannel collection Or non- Netcool Performance Manager
SFTP configurable DataChannel Secure File Transfer
TCP 20, 21 Installation in the file tech note -
SFTP 22 sftp.pdf on the CD.
X X LOG UDP Static, ► DC configuration:
configurable GLOBAL.LOG_PORT
UDP 25000
X X CNS for Static, ► DC configuration:
acquiring the configurable GLOBAL.ORB_NAMESERVICE_PORT
name service TCP 45107
X X Channel Name Static, ► DC configuration:
Service ORB configurable CNS.CORBA_PORT
TCP 9005
X X Channel Static, ► DC configuration:
Manager ORB configurable CMGR.CORBA_PORT
TCP 9001
X X Application Static, ◄ DC configuration:
Manager ORB configurable AMGR.<hostname>. CORBA_PORT
TCP 9002 (AMGR.<hostname> is a property is
taken from the location chosen for
the Disk Usage Server host.)
X X Trapd service Static, ► DC configuration:
configurable CME.x.y.TRAPD_PORT
TCP 162
X X SNMP Automatic Static, ◄ On each SNMP Collector:
DataLoad - Discovery configurable PVM_SNMP_COLL_ SSDPORT=3002
DataMart TCP 3002 PVM_SSDPORT=3002 (These are
entered using SERVICE_PORT in the
X X TCP for Static, ◄
Topology Editor: DataChannel >
configuration configurable
Admin Components > Channel
reload trigger TCP 3002
Manager and DataChannel > Admin
Components > CORBA Naming
Server Host)
X X Bulk DataLoad FTP inventory Static, ►► See the Technical Note Tivoli
-DataMart Or SFTP non- Netcool Performance Manager
configurable DataChannel Secure File Transfer
TCP 20, 21 Installation in the file tech note -
SFTP 22 sftp.pdf on the CD.
X X TCP for Static, ◄ DC configuration:
configuration configurable BCOL.x.x.3002_SERVICE_PORT
reload trigger TCP 3002

Port Type /
X X SNMP NET 8 reloads Static, ► listener.ora on Oracle server:
DataLoad - configurable LISTENER =
database TCP 1521 (DESCRIPTION_LIST
X X Bulk DataLoad NET 8 reloads Static, ► =
- database configurable (DESCRIPTION =
(ADDRESS =
TCP 1521
(PROTOCOL =
X X DataChannel - NET 8 reloads Static, ► IPC)(KEY =
database configurable EXTPROC))
TCP 1521 )
(DESCRIPTION =
X X Database - NET 8 for Static, ◄ (ADDRESS =
DataView queries configurable (PROTOCOL =
TCP 1521 TCP)(HOST =
pl2dbs1)
(PORT = 1521))
)
)
tnsnames.ora on Oracle
server and all clients:
PV =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL =
TCP)(HOST =
pl2dbs1)
(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME =
PV.world)
)
)
X X Channel Name Static, ◄ DC configuration:
Service ORB Configurable CNS.CORBA_PORT
TCP 9005
X X Channel Static, ◄ DC configuration:
Manager ORB configurable CMGR.CORBA_PORT
for Near TCP 9001
Real-Time and
Real Time
access.
The following sections describe additional device-specific protocol mappings,

including:
v “Alcatel 5620 NM mappings”
v “Alcatel-Lucent 5620 SAM mappings” on page 22
v “Cisco CWM mappings” on page 22
v “Nortel CS2000 mappings” on page 22
v “Radcom Probe” on page 23
Alcatel 5620 NM mappings:
Alcatel 5620 NM Mappings.
The following table lists the module-to-protocol mappings for integrating with the
Alcatel 5620 NM.
Note: These ports are to be configured in addition to the ones described in

“Standard Deployment of DataChannel” on page 19, if a firewall sits between
Tivoli Netcool Performance Manager and the Alcatel 5620 NM servers.
Module-to-Protocol Mappings for Integrating with Alcatel 5620 NM

5620 NM DL DC DM DB DV WEB Module Pair Protocol Port Type / Direction
Port #
X X 5620 - CORBA Static, ◄
DataLoad connection to configurable
QCIF 5620 NM 8248
event bus
X X 5620 - FTP and FTP Static, non ◄
DataLoad Data for -configurable
Bulk Load binary TCP 20, 21
Balancer transfer
(BLB) during
remote
installation
Alcatel-Lucent 5620 SAM mappings:
Alcatel-Lucent 5620 SAM Mappings.
The following table lists the module to protocol mappings for integrating with the
Alcatel-Lucent 5620 SAM.

Tivoli Netcool Performance Manager and the Alcatel-Lucent 5620 SAM servers.
Module-to-Protocol Mappings for Integrating with Alcatel-Lucent 5620 SAM

5620 SAM DL DC DM DB DV WEB Module Pair Protocol Port Type / Direction
Port #
X X 5620 - SOAP/XML Static, ◄◄
DataLoad JMS configurable
SAMIF 8080 Static
configurable
1099
X X 5620 - FTP and FTP Static, non- ◄
DataLoad Data for configurable
Bulk Load binary TCP 20, 21
Balancer transfer
(BLB) during
remote
installation
Cisco CWM mappings:
Cisco CWM Mappings.
Cisco CWM.

Tivoli Netcool Performance Manager and the Cisco CWM servers.
Module-to-Protocol Mappings for Integrating with the Cisco CWM

CWM DL DC DM DB DV WEB Module Pair Protocol Port Type / Direction
Port #
X X CWM - Issue GETs Static UDP ◄►
DataLoad and SETs to 161 Static
Bulk the CWM UDP 162
Receive
Inventory
event TRAPs
X X CWM - Connection Static, ◄
DataLoad to Informix configurable
Bulk for getting TCP 8000
data files
Nortel CS2000 mappings:
Nortel CS2000 Mappings.

The following table lists module-to-protocol mappings for integrating with the
Nortel CS2000.

Tivoli Netcool Performance Manager and the Nortel CS2000 servers.
Module-to-Protocol Mappings for Integrating with the Nortel CS2000

CS2K DL DC DM DB DV WEB Module Pair Protocol Port Type / Direction
Port #
X X CS2K - FTP transfer Static, ►
DataLoad between configurable
Bulk DataLoad TCP 8000
and Nortel
EMS.
Radcom Probe:
Radcom Probe.
Radcom Probe.

Tivoli Netcool Performance Manager and the Radcom Probe servers.
Module-to-Protocol Mappings for Integrating with the Radcom Probe

Radcom DL DC DM DB DV WEB Module Pair Protocol Port Type / Port # Direction
Probe
X X Radcom Probe - Bulk SQL between Oracle SQL*Net ►
DataLoad Bulk DataLoad and default TCP 1521
Radcom QManager
Oracle DB.
DataChannel "Remote Channel Option":
Additional ports to open for the DataChannel "Remote Channel Option."
This section describes the additional ports to open for the DataChannel "Remote
Channel Option."
DataChannel "Remote Channel Option" Deployment
The following table lists the module to protocol for the DataChannel remote
option. For more information, see “SNMP version support” on page 26.
Module to Protocol Mappings for DataChannel Remote Option (Outside Firewall)

Dev DCR DCL DM DB DV WEB FM Module Pair Protocol Port Type / Direction Config Setting
Port #
X X DC Remote FTP metric Static, Non ◄◄ See document "Tivoli Netcool
(DCR) - DC collection Or Configurable Performance Manager DataChannel
Loader (DCL) SFTP TCP 20, 21 Secure File Transfer Installation
SFTP 22 -Technical Note " in file "tech note -
sftp.pdf" from the CD
X X LOG UDP Static, ► DC config GLOBAL.LOG_PORT
Configurable
UDP 25000
X X CNS for Static, ► DC config:
acquiring the Configurable GLOBAL.ORB_NAMESERVICE_PORT
name service TCP 45107
X X Channel Name Static, ► DC config: CNS.CORBA_PORT
Service ORB Configurable
TCP 9005
X X Channel Static, ► DC config: CMGR.CORBA_PORT
Manager ORB Configurable
TCP 9001
X X Application Static, ◄ DC config:
Manager ORB Configurable AMGR.<hostname>.CORBA_PORT
TCP 9002 (AMGR.<hostname> is a property is
taken from the location chosen for
the Disk Usage Server host.)
X X Trapd service Static, ► DC config: CME.x.y.TRAPD_PORT
Configurable
UDP 162
X X CME ORB for Static ◄ DC config: CME.x.y.CORBA_PORT
Near Real Configuration
Time TCP 9006
X X DC Remote NET 8 for Static, ► listener.ora and tnsnames.ora on
(DCR) - queries Configurable Oracle server. Port 1521 is supposed
database (DB) TCP 1521 to be already configured by standard
ports settings - see table above.
v DCR represents the Remote server supporting DataLoad and the Sub-Channel
component of DataChannel.
v DCL represents the other modules of the DataChannel (Loader), deployed
Locally.
v Fault Management external station - This is not a Tivoli Netcool Performance
Manager module.
v There is no default line created in the configuration file by the installer, but will
be leveraged if configured.
DataMart
configurations of DataMart.
SNMP inventory:
This section highlights the various protocol exchanged between Tivoli Netcool
Performance Manager components. It can be used to figure out the relevant
firewall configuration depending on where the various components reside (SNMP
Discovery process, DataChannel).
As described previously, in most cases the SNMP Discovery process is deployed on

the DataMart server and does not require you to open specific ports through
firewalls. In very specific cases, the SNMP Discovery process needs to be deployed
remotely, and requires you to open additional firewall ports.
“SNMP inventory” shows the protocols through firewalls deployment.

The following figure shows the most common deployment for Protocols Through
Firewalls - Central SNMP Discovery Process.
In Module-to-Protocol Mappings for the Tivoli Netcool Performance Manager SNMP

Discovery Process:
v DISC is the SNMP Discovery process, deployed on the DataLoad server.
v FM represents the Fault Management external station. This is not a Tivoli
Netcool Performance Manager module.
Module-to-Protocol Mappings for the Tivoli Netcool Performance Manager SNMP

Discovery Process
Dev DL DC DISC DM DB DV WEB FM Module Pair Protocol Port Type / Dir. Property Setting in Topology Editor
Port #
X X Discovery NET 8 Static, ► Listener.ora on server side,
server - reloads configurable tnsnames.ora on client side.
database TCP 1521
X X SNMP Disc server, Static, ◄
DataLoad - for non-
Discovery discovery configurable
server formula TCP 3002
executions
X X DataChannel LOG UDP Static, ◄ DC configuration: GLOBAL.LOG_
(CME not configurable PORT
involved) - UDP 25000
Discovery
X X CNS for Static, ◄ DC configuration:
server
acquiring configurable GLOBAL.ORB_NAMESERVICE_PORT
the name TCP 45107
service
X X Disc server's Channel Static, ◄ DC configuration: CNS.CORBA_
AMGR Name configurable PORT
talking to Service ORB TCP 9005
the
X X Channel Static, ◄ DC configuration:
DataChannel
Manager configurable CMGR.CORBA_PORT
ORB TCP 9001
X X Application Static, ► DC configuration: AMGR.
Manager configurable <hostname>. CORBA_PORT
ORB TCP 9002
X X Discovery Discovery Dynamic, ◄ DC configuration: DISC.
server - server ORB configurable <hostname>.1. CORBA_PORT (is
DataMart inherited from the DataMart host
inventory CORBA_PORT property.)
X X DataChannel CNS for Static, ◄ DC configuration:
(CME not acquiring configurable GLOBAL.ORB_NAMESERVICE_PORT
involved) - the name TCP 45107
DataMart service
inventory
Note: For most deployments, where the Discovery server is on the central site,
these ports do not have to be opened, except the one described in the second row
of
“SNMP inventory” on page 24
(if DataLoad is behind the firewall).
See Professional Services for more information.
SNMP version support:
Tivoli Netcool Performance Manager can automatically detect the SNMP version
supported by each element on the network, between SNMP Versions 1, 2c, and 3.
Tivoli Netcool Performance Manager supports the following PDU sets for the
following SNMP versions:
v SNMP Version 1 - Get / GetNext / Set
v SNMP Version 2c - Get / GetNext / GetBulk / Set
v SNMP Version 3 - Get / GetNext / GetBulk / Set, MD5 and SHA-1
authentication (with AES and DES private encryption)
Note: For more information about SNMPv3 support, see Installing libcrypto.so in
Installing Tivoli Netcool Performance Manager - Wireline Component.
Technology packs
Technology packs description.
Tivoli Netcool Performance Manager Technology Packs are custom designed

collections of MIBs, discovery formulas, collection formulas, complex formulas,
grouping rules, reporters, and other functions. Technology packs provide all Tivoli
Netcool Performance Manager needs to gather data for targeted devices.
Technology packs make it possible for Tivoli Netcool Performance Manager to
report on technology from multiple vendors.
Installation or topology considerations:
Installation and topology considerations for technology packs.
If you are creating a UBA collector, you must associate it with a specific technology
pack.
Note: General installation information for technology packs can be found in the
Installing and Configuring Technology Packs, pack-specific installation information is
also provided. Consult both sets of documentation for important installation or
topology information.
Note: To enable Cognos 10 common reporting in wireline technology packs, install

the JDBC Driver. For more information, see Installing and Using JDBC Driver. You
can find the tnpm-jdbc.tar file in this location: /<JazzSM_HOME>/products/tnpm/
dataview/misc/jdbc. By default, <JazzSM_HOME> is /opt/IBM/JazzSM.
Typical installation topology

Example topology scenarios.
Table 2 provides an example of where to install Tivoli Netcool Performance

Manager components, using four servers. Use this example as a guide to help you
determine where to install the Tivoli Netcool Performance Manager components in
your environment.

Basic topology scenario
A basic example topology.
Table 2. Tivoli Netcool Performance Manager basic topology scenario
Tivoli Netcool Performance
Manager Components
Server Name Hosted Notes
delphi v Oracle/DB2 server Install the Topology Editor
and primary deployer on this
v Tivoli Netcool
system.
Performance Manager
Database
v Tivoli Netcool
Performance Manager
DataMart
v Tivoli Netcool
Performance Manager
Discovery Server
corinth v Oracle/DB2 client You could install Tivoli
Netcool Performance
v Tivoli Netcool
Manager components
Performance Manager
remotely on this system.
DataLoad, SNMP collector
v Tivoli Netcool
Performance Manager
DataLoad, Bulk Load
collector
sparta v Oracle/DB2 client You could install Tivoli
Netcool Performance
v Tivoli Netcool
Manager components
Performance Manager
remotely on this system
DataChannel
athens v Oracle/DB2 client You could install Tivoli
Netcool Performance
v Jazz for Service
Manager components
Management
v Tivoli Netcool Your configuration can use a
Performance Manager pre-existing Jazz for Service
DataView Management, or install and
include a new instance.
Intermediate topology scenario
An intermediate example topology scenario.
Table 3. Tivoli Netcool Performance Manager intermediate topology scenario
Manager Components

v Tivoli Netcool
system.
Performance Manager
Database
v Tivoli Netcool
Performance Manager
DataMart
v Tivoli Netcool
Performance Manager
Discovery Server

Netcool Performance
v Tivoli Netcool
Manager components
Performance Manager
v Tivoli Netcool
Performance Manager
DataLoad, Bulk Load
collector

Netcool Performance
v Tivoli Netcool
Manager components
Performance Manager
DataChannel
thessaloniki v Oracle/DB2 client You could install Tivoli

Netcool Performance
v Tivoli Netcool
Manager components
Performance Manager
DataChannel
Also running the Channel This server contains a
Manager. duplicate set of collectors to
v Tivoli Netcool allow for high availability.
Performance Manager
v Tivoli Netcool
Performance Manager
DataLoad, Bulk Load
collector
v High Availability Manager

Netcool Performance
v Jazz for Service
Manager components
Management

This scenario has an added copy of both collectors on corinth to a second
machine, thessaloniki, for the purposes of failover. HAM only manages SNMP
collectors; therefore, the HAM in this scenario will manage availability of the
DataLoad SNMP collector and not the Bulk Load collector. The HAM must be put
on the same machine as the channel manager.
Advanced topology scenario

An advanced example topology scenario.
Table 4. Tivoli Netcool Performance Manager advanced topology scenario
Manager Components

v Tivoli Netcool
system.
Performance Manager
Database
v Tivoli Netcool
Performance Manager
DataMart
v Tivoli Netcool
Performance Manager
Discovery Server

Netcool Performance
v Tivoli Netcool
Manager components
Performance Manager
v Tivoli Netcool
Performance Manager
DataLoad, Bulk Load
collector

Netcool Performance
v Tivoli Netcool
Manager components
Performance Manager
DataChannel
thessaloniki v Oracle/DB2 client You could install Tivoli

Netcool Performance
v Tivoli Netcool
Manager components
Performance Manager
DataChannel
Also running the Channel
Manager.
v Tivoli Netcool
Performance Manager
v Tivoli Netcool
Performance Manager
DataLoad, Bulk Load
collector
v High Availability Manager
Table 4. Tivoli Netcool Performance Manager advanced topology scenario (continued)
Manager Components

Netcool Performance
v Jazz for Service
Manager components
Management
rhodes v Oracle/DB2 client You could install Tivoli

Netcool Performance
v Jazz for Service
Manager components
Management
High Availability
High Availability description.
High availability can be implemented for Tivoli Netcool Performance Manager in

two forms:
High Availability Manager (HAM)
A DataChannel component that can be configured to handle availability of
SNMP collectors.
For information on High Availability for DB2 database, see High Availability
and Disaster Recovery Options for DB2 for Linux, UNIX, and Windows from
the following location:
http://www.redbooks.ibm.com/redbooks/pdfs/sg247363.pdf.
To know more about Tivoli Netcool Performance Manager wireline on Red
Hat Enterprise Linux (RHEL) in a High Availability (HA) configuration
with High Availability Disaster Recovery feature (HADR), see
https://www.ibm.com/developerworks/community/wikis/form/api/
wiki/2eed5677-1246-4b21-9e6a-3b0866204ca4/page/807bc74b-e4c1-4c18-
ab69-d8b9da5dfea8/attachment/d5c45034-a140-465b-a11a-f4052ac3a094/
media/High%20Availability%20for%20Tivoli%20Netcool%20Performance
%20Manager%20133-v12.docx
Veritas Cluster or Sun Cluster (referred to as HA within the documentation)
This method of implementing high availability has a much broader scope
and can cover all or a combination of the database, DataChannel, DataMart
and DataView components.
The following High Availability (HA) documents are available for download from
the Integrated Service Management Library (ISML), https://www-304.ibm.com/
software/brandcatalog/ismlibrary/.
Tivoli Netcool Performance Manager Wireline Cluster Operations Guide 1.4.2
Describes an example system that was configured to provide high
availability.

Tivoli Netcool Performance Manager Wireline High Availability Installation and
Configuration 1.3
Describes the steps necessary to install and configure components of Tivoli
Netcool Performance Manager in a highly available configuration.
Tivoli Netcool Performance Manager Wireline High Availability Overview 1.3
Describes high availability solutions for the Tivoli Netcool Performance
Manager product.
Sun Cluster Tivoli Netcool Performance Manager Wireline Agent Guide 1.1
Describes how Sun Clusters can be used with Tivoli Netcool Performance
Manager to create a high availability Tivoli Netcool Performance Manager
system.
For more information about High Availability Manager, see Chapter 9, “Using the
High Availability Manager,” on page 201.
Installation or topology considerations

Installation and topology considerations for the High Availability Manager.
The HAM must be put on the same machine as the channel manager.
Chapter 2. Requirements
Details of all Tivoli Netcool Performance Manager requirements.
A complete set of requirements for Tivoli Netcool Performance Manager 1.4.2.
IBM Prerequisite Scanner

IBM Prerequisite Scanner is a stand-alone prerequisite checking tool that analyzes
system environments before the installation or upgrade of a Tivoli product or IBM
solution.
The IBM Prerequisite Scanner can be used to check for the presence of Tivoli
Netcool Performance Manager requirements.
Important: The compatible version of Prerequisite scanner for Tivoli Netcool

Performance Manager 1.4.2 is v1.2.0.18.
Product codes that are used to support Tivoli Netcool Performance Manager are as
follows:
Product code Platform Description

TND UNIX IBM Tivoli Netcool
Performance Manager with
IBM DB2
TNO UNIX IBM Tivoli Netcool
Performance Manager with
Oracle
This table shows the environment variables that must be set for
Tivoli Netcool Performance Manager after the Oracle database is installed to verify
that the installation is successful:
Product version Installation option Environment variable

IBM Tivoli Netcool Impact Oracle server TNPM_ORACLE_SERVER
Performance Manager installation only
Version 1.4.1 and 1.4.2
Impact Oracle client TNPM_ORACLE_CLIENT
installation only
Standalone installation for TNPM_STAND_ALONE
Oracle database
To use the IBM Prerequisite Scanner on Tivoli Netcool Performance Manager 1.4.2,
you must install the 1.4.2.0-TIV-TNPM-IF0005 interim fix from IBM Fix Central.
Note: You must run the IBM Prerequisite Scanner tool as db2 user. If you are using
a non-default DB2 username, you must use the same name to run this tool.

Plan your installation
You can choose to install a full installation of Tivoli Netcool Performance Manager
1.4.2 in a stand-alone environment or in a distributed environment.
Pre-requisite software
Table 5. Pre-requisite software
Product Version
Operating system 64-bit only v Red Hat Enterprise Linux (RHEL) 6.x and 7.2 if you
are doing a fresh install
v Red Hat Enterprise Linux (RHEL) 6.x for Tivoli
Netcool Performance Manager upgrade
v IBM AIX 6.1 or 7.1
v Oracle Solaris 10 update 6
Note: For the required packages, see
“Supported operating systems and modules” on page
42.
Databases
v Oracle Database 12c support (12.1.0.2)

v Support for 64-bit Oracle Database 12c (12.1.0.2)
v Enterprise Edition on Solaris (SPARC), Linux and AIX
v Oracle 12c Enterprise Edition must include the
partitioning option.
v IBM DB2 Enterprise Server Edition 10.1.0.5, Linux

64-bit only
v IBM Data Server Client 10.1.0.5 64-bit only
Note: You must install the IBM Data Server Client
(64-bit) in a distributed environment only. It is not
required in a standalone environment. In a distributed
environment, install the DB2 client software on each
server where you plan to install a Tivoli Netcool
Performance Manager component, with the exception of
where you installed the DB2 server.
Java v Java Runtime Environment (JRE) 1.8, 32-bit for all
browsers
v IBM-JRE 1.7, 64-bit is required for DataView that runs
on Dashboard Application Services Hub that is
installed together with the Jazz for Service
Management 1.1.2.1
Tivoli Common Reporting Tivoli Common Reporting 3.1.2.1
Jazz for Service Management Jazz for Service Management 1.1.2.1
Note: See Jazz for Service Management 1.1.2.1 at IBM
Knowledge Center.
Web browsers v Internet Explorer 11.0
v Mozilla Firefox ESR 24, 31 and 38
Note: Enable JavaScript and cookies

Note: Jazz for Service Management includes installation media for Jazz for Service
Management, IBM DB2, IBM WebSphere Application Server, and the Quick Start
Guide. Jazz for Service Management has a number of integration services:
v Administration Services
v Administration Services UI
v IBM Dashboard Application Services Hub
v Jazz for Service Management extension for IBM WebSphere
v Registry Services
v Security Services
v IBM Tivoli Common Reporting
Minimum requirements for installation

The minimum required host specifications for a Tivoli Netcool Performance
Manager deployment.
Solaris hardware requirements
Tivoli Netcool Performance Manager hardware requirements for the Solaris

environment.
Tivoli Netcool Performance Manager has the following minimum hardware

requirements for the Solaris environment.
v 4 x SPARC64 VI (dual-core) 2.4 GHz or 3 x SPARC64 VII (quad-core) 2.88 GHz
processor
v 16 GB Memory
v 2 x 146 GB HDD
If you are deploying in a distributed environment, each server/zone requires:
1 x SPARC64 VI (dual-core) 2.4 GHz or 1 x SPARC64 VII, (quad-core) 2.88 GHz

processor, 4 GB RAM, 146 GB disk space.
AIX hardware requirements
Tivoli Netcool Performance Manager hardware requirements for the AIX

environment.
Tivoli Netcool Performance Manager has the following minimum requirements for
the AIX environment:
v 3 x POWER7 (Quad Core) 3.0 GHz processor or or 2 x POWER8 (Octo Core)
2.32 GHz processor
v 16 GB Memory
v 2-x-146 GB HDD
If you are deploying in a distributed environment, each server/LPAR requires:

v 1 x POWER7 (Quad Core) 3.0 GHz processor or 0.5 x POWER8 (Octo Core) 2.32
GHz processor
Chapter 2. Requirements 35
v 4-GB RAM; 146 GB disk space.
Other deployment configurations must be sized by IBM Professional Services.
Linux hardware requirements
Tivoli Netcool Performance Manager has a minimal deployment space requirement

on Linux.
Tivoli Netcool Performance Manager has the following minimum requirements for
the Linux environment:
v 3 x Intel Xeon 5500/5600 series processors (quad-core), 2.4 GHz or greater.
v 16 GB memory
v 2 x 300 GB HDD
If you are deploying in a distributed environment, each server/Virtual Machine

requires:
v 1 x Intel Xeon 5500/5600 series processor (quad-core) 2.4 GHz
v 4 GB RAM
v 300 GB disk space
Other deployment configurations must be sized by IBM Professional Services.
Oracle and DB2 deployment space requirements

Tivoli Netcool Performance Manager has a minimal deployment space requirement
for Oracle servers.
When you install Oracle, the following host must confirm the
previously stated hardware requirements for AIX, Solaris, and Linux. However, the
database may experience problems if sufficient swap space is not provided.
v The same amount of Swap as RAM must be present on the Oracle server host in
a distributed Tivoli Netcool Performance Manager system.
v Twice as much Swap as RAM must be present on the Oracle server host for a
Tivoli Netcool Performance Manager proof of concept install.
Table 6. RAM Swap Space
RAM Swap Space
Between 1 GB and 2 GB 1.5 times the size of RAM
Between 2 GB and 16 GB Equal to the size of RAM
More than 16 GB 16 GB
Physical database design
A high-quality physical database design is an important factor in a successful

database deployment. The choices and decisions that are made during physical
database design have a long lasting effect and far reaching impact in terms of
overall database health and day-to-day administrative overhead that is incurred in
a data center. Understanding DB2 features and how it can be applied to meet the

business needs is crucial to come up with a high-quality physical database design
that can adapt to evolving business requirements over time.
A high-quality physical database design must consider the following items:

v Business service level agreement (SLA)
v I/O bandwidth
v Performance objectives such as response time and throughput
v Recovery time
v Maintenance window
v Administrative overhead
v Reliability, availability, and serviceability (RAS)
v Data (lifecycle) management
As your business requirements change, you must reassess your physical database
design. This reassessment must include periodic revisions of the design. If
necessary, make configuration and data layout changes to meet your business
requirements.
v Minimize I/O traffic.
v Balance design features that optimize query performance concurrently with
transaction performance and maintenance operations.
v Improve the performance of administration tasks such as index creation or
backup and recovery processing.
v Reduce the time database administrators spend in regular maintenance tasks.
v Minimize backup and recovery elapsed time.
v Reassess overall database design as business requirements change.
Use the following design best practices for RAS:

v Design your business infrastructure with a solid sizing and capacity planning for
current and future needs as the business grows.
v Identify and eliminate single point of failures (SPOF) in the business
infrastructure.
v Implement redundancy in your infrastructure such as networks and mirrored
disks.
v Implement high availability and disaster recovery solutions in all layers of
business infrastructure such as, database, application, and middleware.
v For DB2 databases:
– Use separate high performing disks for data, transaction logs, and archived
logs.
– Use mirrored logs for redundancy.
– Create a backup and restore plan for backing up databases, table paces, and
transactional logs.
For more information about DB2 product configurations and best practices, see
https://ibm.biz/Bdx2ew.
Disk and memory requirements
Ensure that an appropriate amount of disk space is available for your DB2
environment, and allocate memory accordingly.
Disk requirements
The disk space that is required for your product depends on the type of
installation you choose and the type of file system you have. The DB2 Setup
wizard provides dynamic size estimates based on the components that are selected
during a typical, compact, or custom installation.
Remember to include disk space for required databases, software, and

communication products. Ensure that the file system is not mounted with
concurrent I/O (CIO) option.
On Linux and UNIX operating systems, 2 GB of free space in the /tmp directory is
recommended, and at least 512 MB of free space in the directory is required.
Note: On Linux and UNIX operating systems, you must install your DB2 product
in an empty directory. If the directory that you have specified as the install path
contains subdirectories or files, your DB2 installation might fail.
Memory requirements
Memory requirements are affected by the size and complexity of your database
system, the extent of database activity, and the number of clients accessing your
system. At a minimum, a DB2 database system requires 256 MB of RAM. For a
system running just a DB2 product and the DB2 GUI tools, a minimum of 512 MB
of RAM is required. However, 1 GB of RAM is recommended for improved
performance. These requirements do not include any additional memory
requirements for other software that is running on your system. For IBM data
server client support, these memory requirements are for a base of five concurrent
client connections. For every additional five client connections, an extra 16 MB of
RAM is required.
For DB2 server products, the self-tuning memory manager (STMM) simplifies the
task of memory configuration by automatically setting values for several memory
configuration parameters. When enabled, the memory tuner dynamically
distributes available memory resources among several memory consumers
including sort, the package cache, the lock list, and buffer pools.
Paging space requirements
DB2 requires paging, also called swap to be enabled. This configuration is required
to support various functions in DB2, which monitor or depend on knowledge of
swap/paging space utilization. The actual amount of swap/paging space that is
required varies across systems and is not solely based on memory utilization by
application software.
A reasonable minimum swap/paging space configuration for most systems is

25-50% of RAM. These higher requirements are due to virtual memory
pre-allocated per database instance, and retained virtual memory in the case of
STMM tuning multiple databases. More swap/paging space might be wanted to
provision for unanticipated memory overcommitment on a system.
For more information about Prerequisites for a DB2 database server installation (Linux
and UNIX), see http://www-01.ibm.com/support/knowledgecenter/
SSEPGG_10.1.0/com.ibm.db2.luw.qb.server.doc/doc/c0059823.html

Some DB2 configuration parameters settings
When a DB2 database instance or a database is created, a corresponding

configuration file is created with default parameter values. You can modify these
parameter values to improve performance and other characteristics of the instance
or database. It is recommended that the two parameters; instance_memory and
database_memory are set to the default values in Tivoli Netcool Performance
Manager 1.4.2.
The disk space and memory that is allocated by the database manager that is
based on default values of the parameters might be sufficient to meet your needs.
In some situations, however, you might not be able to achieve maximum
performance by using these default values.
Each transaction processing environment is unique in one or more aspects. These

differences can have a profound impact on the performance of the database
manager when using the default configuration. For this reason, you might be
required to tune your configuration for your environment.
Configuration files contain parameters that define values such as the resources
allocated to the DB2 database products and to individual databases, and the
diagnostic level. There are two types of configuration files:
The database manager configuration file for each DB2 instance
The database manager configuration file is created when a DB2 instance is
created. The parameters that it contains affect system resources at the
instance level, independent of any one database that is part of that
instance. Values for many of these parameters can be changed from the
system default values to improve performance or increase capacity,
depending on your system's configuration.
Database manager configuration parameters are stored in a file named
db2systm. This file is created when the instance of the database manager is
created. In Linux and UNIX environments, this file can be found in the
sqllib subdirectory for the instance of the database manager.
The database configuration file for each individual database
A database configuration file is created when a database is created, and is
located where that database exists. There is one configuration file per
database. Its parameters specify, among other things, the amount of
resource to be allocated to that database. Values for many of the
parameters can be changed to improve performance or increase capacity.
Different changes might be required, depending on the type of activity in a
specific database.
All database configuration parameters are stored in a file named
SQLDBCONF. These files cannot be directly edited, and can be changed or
viewed via a supplied API or by a tool, which calls that API.
To change the database manager configuration parameters, use UPDATE
DATABASE MANAGER CONFIGURATION command. Database configuration
parameters can be changed by using UPDATE DATABASE CONFIGURATION
command.
Attention: If you edit db2systm, SQLDBCON, or SQLDBCONF by using a
method other than those provided by the database manager, you might
make the database unusable. Do not change these files by using methods
other than those documented and supported by the database manager.
instance_memory
The instance_memory is the database manager instance memory
configuration parameter. This parameter specifies the maximum amount of
memory that can be allocated for a database partition if you are using DB2
database products with memory usage restrictions or if you set it to a
specific value. In Tivoli Netcool Performance Manager 1.4.2, set this
parameter to AUTOMATIC. This setting allows instance memory to grow as
needed.
database_memory
The database_memory is configuration parameter specifies the size of the
database memory set. The database memory size counts towards any
instance memory limit in effect. The setting must be large enough to
accommodate the following configurable memory pools: bufferpools, the
database heap, the locklist, the utility heap, the package cache, the catalog
cache, the shared sort heap, and an additional minimum overflow area of
5%. In Tivoli Netcool Performance Manager 1.4.2, set this parameter to
AUTOMATIC. The initial database memory size is calculated based on the
underlying configuration requirements.
logprimary
Number of primary log files configuration parameter.
This parameter allows you to specify the number of primary log files to be
preallocated. The primary log files establish a fixed amount of storage that
is allocated to the recovery log files.
logsecond
Number of secondary log files configuration parameter.
This parameter specifies the number of secondary log files that are created
and used for recovery log files. The secondary log files are created only as
needed.
Following database configuration parameter values are set in the DB2 database for
IBM Tivoli Netcool Performance Manager 1.4.2.
Log file size (4 KB) (LOGFILSIZ) = 8192
This parameter defines the size of each primary and secondary log file. The
size of these log files limits the number of log records that can be written
to them before they become full and a new log file is required.
v Number of primary log files (LOGPRIMARY) = 50
v Number of secondary log files (LOGSECOND) = -1
For more information about these and other parameters, see http://www-
01.ibm.com/support/knowledgecenter/SSEPGG_10.1.0/
com.ibm.db2.luw.admin.config.doc/doc/c0004555.html?cp=SSEPGG_10.1.0%2F2-2-4

Screen resolution
Recommended screen resolution details.
A screen resolution of 1024 x 768 pixels or higher is recommended when you run
the deployer.
Minimum requirements for a proof of concept installation

Tivoli Netcool Performance Manager has minimum required host specifications for
Proof of Concept (POC) deployments.
Note: The minimum requirements do not account for extra functions such as Tivoli
Netcool/OMNIbus Web GUI, IBM Cognos and MDE, each have extra memory and
CPU impacts.
Solaris hardware requirements (POC)
The minimum system requirements for a proof of concept installation on Solaris.

v 2 x SPARC64 VI (dual-core) 2.4 GHz or 2 x SPARC64 VII (quad-core) 2.88 GHz
processor.
v 16 GB Memory
v 1 x 146 GB HDD
To support:
v SNMP data only.
v All Tivoli Netcool Performance Manager components that are deployed on a
single server.
v Number of resources that are supported up to 20,000.
v 3 SNMP Technology Packs based on MIB II, Cisco Device, and IPSLA.
v 15-minute polling
v Number of DataView users who are limited to less than three.
AIX hardware requirements (POC)
The minimum system requirements for a proof of concept installation on AIX.

v 2 x POWER7 (Quad Core) 3.0 GHz processor or 1 x POWER8 (Octo Core) 2.32
GHz processor
v 16 GB Memory
v 1 x 146 GB HDD
To support:
v SNMP data only.
single server.
v Number of resources that are supported up to 20,000.
v 3 SNMP Technology Packs based on MIB-II, Cisco Device, and IPSLA.
v 15-minute polling
v Number of DataView users who are limited to less than three.
Note: Extra features such as Tivoli Netcool/OMNIbus Web GUI and Mass Data
Extraction (MDE) are not accounted for in this spec. They have extra memory and
CPU impacts.
Linux hardware requirements (POC)
The minimum system requirements for a proof of concept installation on Linux.

v 2 x Intel Xeon 5500/5600 series processors (quad-core), 2.4 GHz or greater
v 16 GB memory
v 1 x 300 GB HDD
To support:
v SNMP data only
single server
v Number of resources that are supported up to 20,000
v 3 SNMP Technology Packs based on MIB-II, Cisco Device, and IPSLA
v 15-minute polling
v Number of DataView users who are limited to less than three
Screen resolution
A screen resolution of 1024 x 768 pixels or higher is recommended when you run
the deployer.
Supported operating systems and modules

The supported operating systems, modules, and third-party applications for IBM
Tivoli Netcool Performance Manager, Version 1.4.2.
The following sections list the supported operating systems, modules, and
third-party applications for IBM Tivoli Netcool Performance Manager, Version
1.4.2.
All subcomponents of the Tivoli Netcool Performance Manager - Wireline

Component can be installed on a mix of AIX, Linux, and Solaris operating systems;
that is, the operating systems on which the DataChannel, DataView, DataLoad and
DataMart subcomponents are installed do not have to be of the same type. The
supported versions of AIX, Linux and Solaris operating systems are discussed in
this document.
For more information, see the Release notes - IBM Tivoli Netcool Performance Manager,
Version 1.4.2 , which contains the version numbers for each Tivoli Netcool
Performance Manager module in Version 1.4.2.
Attention: DB2 is supported on Linux only. Whereas, Oracle is supported on

Solaris, AIX, and Linux systems.

Important: DataView can be installed on the server which has Jazz for Service
Management 1.1.2.1 installed. Jazz for Service Management 1.1.2.1 is supported
only on AIX and Linux. Thus, in Tivoli Netcool Performance Manager 1.4.2,
DataView can be installed on AIX or Linux platform only.
Solaris 10 for SPARC platforms
Supported Solaris systems.
Operating systems and kernel

Supported operating system and kernel version.
Solaris 10 update 6 (released in October 2008).
Update level can be checked from /etc/release file.
Applying a kernel patch or a Solaris patch bundle is not the equivalent to

installing the specific Solaris 10 "update 6" image.
Kernel Parameters
Solaris 10 uses the resource control facility to implement the System V IPC.
However, Oracle recommends that you set both resource control and /etc/system/
parameters. Operating system parameters that are not replaced by resource
controls continue to affect performance and security on Solaris 10 systems.
Parameter Replaced by Resource Control Minimum Value
noexec_user_stack NA (can be set in /etc/system only) 1
semsys:seminfo_semmni project.max-sem-ids 100
semsys:seminfo_semmsl process.max-sem-nsems 256
shmsys:shminfo_shmmax project.max-shm-memory 4294967295
shmsys:shminfo_shmmni project.max-shm-ids 100
Note: project.max-shm-memory represent the maximum shared memory available

for a project, so the value for this parameter must be greater than sum of all SGA
size.
Refer to the following document for checking/setting kernel parameter values by

using resource control: Note 429191.1 Kernel setup for Solaris 10 using project files.
v The 'umask' setting for the oracle user must be 022.
v Hostname command must return the fully qualified hostname as either %
hostname or % hostname.domainname.
Solaris 10 requirements
Required packages and patches for the Solaris 10 system.
Tivoli Netcool Performance Manager requires at a minimum the End-User

distribution of Solaris 10.
Required packages:
Required packages for the Solaris 10 system.
Before you install the Oracle server, ensure that the following Solaris packages are
installed on your system:
v SUNWarc
v SUNWbtool
v SUNWcsl
v SUNWhea
v SUNWi15cs
v SUNWi1cs
v SUNWi1of
v SUNWlibC
v SUNWlibm
v SUNWlibms
v SUNWsprot
v SUNWtoo
v SUNWxwfnt
To verify that the required Solaris packages are installed:

1. Enter the following command at the shell prompt:
# pkginfo -i SUNWarc SUNWbtool SUNWhea SUNWlibm SUNWlibms SUNWsprot
SUNWtoo SUNWuiu8
The following output confirms that the specified Solaris packages are installed
correctly:
system SUNWarc Archive Libraries
system SUNWbtool CCS tools bundled with SunOS
system SUNWhea SunOS Header Files
system SUNWlibm Forte Developer Bundled libm
system SUNWlibms Forte Developer Bundled shared libm
system SUNWsprot Solaris Bundled tools
system SUNWtoo Programming Tools
...
2. If these packages are not on your system, see the Solaris Installation Guide for
instructions on installing supplementary package software.
Required patches:
Required patches for the Solaris 10 system.
To determine the patch level on your system, enter the following command:
uname -v
Note: All Tivoli Netcool Performance Manager modules are tested to run on an
End-User distribution of Solaris 10.
The following list of minimum Solaris patches is required:

v For all Installations:
– 120753-06: SunOS 5.10: Microtasking libraries (libmtsk) patch
– 139574-03: SunOS 5.10: file crle ldd stings elfdump patch
– 141444-09
– 141414-02

To determine whether an operating system patch is installed, enter a command
similar to the following:
1. Enter the command:
/usr/sbin/patchadd -p | grep patch_number(without version number)
For example, to determine whether any version of the 120753-06 patch is
installed, use the following command:
/usr/sbin/patchadd -p | grep 120753
Solaris 10 virtualized containers

If you are using Solaris 10 virtualized containers, you must create containers with
"whole root" partitions.
If you are using Solaris 10 virtualized containers, you must create containers with
"whole root" partitions. Tivoli Netcool Performance Manager does not work in
containers with “sparse root” partitions.
Note: The Tivoli Netcool Performance Manager Self Monitoring Pack and SSM
packs do not report data correctly in virtualized environments, due to
compatibility issues of the underlying SSM agents in these configurations. The
MIB-II pack can also have difficulties discovering resources in virtualized server
environments.
DataMart
DataMart requirements if you are using Solaris 10.
Configure the default language of Solaris to English.
IBM Java Runtime Environment (JRE) 1.7.
DataLoad
DataLoad requirements if you are using Solaris 10.
DataChannel
DataChannel requirements if you are using Solaris 10.
The DataChannel components require X libraries to be installed. The graphical

tools in DataChannel also require a running X server, which can be on a different
host.
Technology packs
Technology pack requirements if you are using Solaris 10.
Installation of technology packs on Solaris 10 requires JRE 1.7 (32-bit). The correct
version is installed with the Topology Editor in the following default location:
/opt/IBM/proviso/topologyEditor/jre/bin
AIX platforms
Supported AIX systems.
Tivoli Netcool Performance Manager can be installed and operated in a virtualized

AIX environment.
Note: Tivoli Netcool Performance Manager on AIX does not support connection to
a Solaris-based Oracle database.
Note: The Tivoli Netcool Performance Manager Self Monitoring Pack and SSM
packs do not report data correctly in virtualized environments, due to
compatibility issues of the underlying SSM agents in these configurations. The
MIB-II pack can also have difficulties discovering resources in virtualized server
environments.
Operating system
Supported operating system and kernel version.
IBM Tivoli Netcool Performance Manager, Version 1.4.2 supports:

v AIX 6.1 TL 04 SP1 (6100-04-01), 64-bit kernel
v AIX 7.1 POWER7 TL 0 SP3 (7100-00-03), 64-bit kernel
v AIX 7.1 POWER8 TL 03 SP3 (7100-03-03), 64-bit kernel
To verify your AIX release level:
As root, enter the following command at the shell prompt:

# oslevel -r
This command returns a string that represents the maintenance level for your AIX
system.
For AIX 6.1: If the operating system version is lower than AIX 6.1 Technology
Level 4 SP 1, then upgrade your operating system to this or a later level.
For AIX 7.1: If the operating system version is lower than AIX 7.1 POWER7
Technology Level 0 plus SP 3, or POWER8 Technology Level 3 plus SP 3 then
upgrade your operating system to this or a later level. AIX maintenance packages
are available from the following website: http://www-933.ibm.com/support/
fixcentral/
Required files and fixes
Files and fixes that are required by Oracle and Tivoli Netcool Performance
Manager for the AIX system.

AIX 6.1
The following operating system file sets are required for AIX 6.1:
v bos.adt.base
v bos.adt.lib
v bos.adt.libm
v bos.perf.libperfstat 6.1.2.1 or later
v bos.perf.perfstat
v bos.perf.proctools
v xlC.aix61.rte:10.1.0.0 or later
v gpfs.base 3.2.1.8 or later
If you are using the minimum operating system TL level for AIX 6L listed above,
then install all AIX 6L 6.1 Authorized Problem Analysis Reports (APARs) for AIX
6.1 TL 02 SP1, and the following AIX fixes:
v IZ41855
v IZ51456
v IZ52319
These 6.1 fixes are already present in the following TL levels:

v AIX 6.1 TL-02 SP-04 and later
v AIX 6.1 TL-03 SP-02 and later
v AIX 6.1 TL-04
The following AIX fixes are required also:

v IZ97457
v IZ89165
Note: See Oracle Metalink Note: 1264074.1 and Note: 1379753.1 for other AIX 6.1
patches that might be required
AIX 7.1
The following operating system file sets are required for AIX 7.1:
v bos.adt.base
v bos.adt.lib
v bos.adt.libm
v bos.perf.libperfstat
v bos.perf.perfstat
v bos.perf.proctools
v xlC.aix61.rte:10.1.0.0 or later
v xlC.rte:10.1.0.0 or later
If you are using the minimum operating system TL level for AIX 7.1 listed above,
then install all AIX 7L 7.1 Authorized Problem Analysis Reports (APARs) for AIX
7.1 TL 0 SP1, and the following AIX fixes:
v IZ87216
v IZ87564
v IZ89165
v IZ97035
Note: See Oracle Metalink Note: 1264074.1 and Note: 1379753.1 for other AIX 7.1
patches that might be required.
Determining installed file sets
To determine whether the required file sets are installed and committed, enter a
command similar to the following:
# lslpp -l bos.adt.base bos.adt.lib bos.adt.libm bos.perf.perfstat \
bos.perf.libperfstat bos.perf.proctools
To determine the supported kernel mode, enter a command similar to the

following:
# getconf KERNEL_BITMODE
Determining installed APAR fixes
To determine whether an APAR is installed, enter a command similar to the

following:
# /usr/sbin/instfix -i -k "IZ42940 IZ49516 IZ52331 IZ41855 IZ52319"
If an APAR is not installed, then download it from the following website and
install it: http://www-933.ibm.com/support/fixcentral/
Set resource limits

The default user process limits are not adequate and must be reset.
On AIX systems, the default user process limits are not adequate for Tivoli Netcool
Performance Manager. For detailed information on setting the correct user process
limits, see set Resource Limits in the Installing Tivoli Netcool Performance Manager -
Wireline Component.
DataMart
DataMart requirements if you are using AIX.
Java Runtime Environment (JRE) 1.7 or higher (for the Database Information
module).
DataLoad
DataLoad requirements if you are using AIX.
No special requirements.
DataChannel
DataChannel requirements if you are using AIX.
The following DataChannel components require X libraries to be installed:

v Bulk Collector
v CME
v DLDR
v FTE
v FED (also requires that an X Server is running)
v LDR
v The showVersion utility.
Technology packs
Technology pack requirements if you are using AIX.
Installation of technology packs on AIX 6.1 requires JRE 1.7 (32-bit). The correct
version is installed with the Topology Editor in the following default location:
/opt/IBM/proviso/topologyEditor/jre/bin
Viewing the documentation on AIX systems
Viewing the documentation requires that you can run Adobe Acrobat Reader.
To run on AIX systems, Adobe Acrobat Reader requires GIMP Toolkit (GTK+)
Version 2.2.2 or higher. You can download the toolkit from the following URL:
http://www-03.ibm.com/servers/aix/products/aixos/linux/download.html
In addition, you must install all the dependent packages for GTK+. You can install
GTK+ and its dependent packages either before or after the installation of Acrobat
Reader.
At the time of publication, the latest version of GTK+ is gtk2-2.8.3-9, and the
latest versions of the dependent packages are as follows:
v libpng-1.2.8-5
v libtiff-3.6.1-4
v libjpeg-6b-6
v gettext-0.10.40-6
v glib2-2.8.1-3
v atk-1.10.3-2
v freetype2-2.1.7-5
v xrender-0.8.4-7
v expat-1.95.7-4
v fontconfig-2.2.2-5
v xft-2.1.6-5
v cairo-1.0.2-6
v pango-1.10.0-2
v xcursor-1.0.2-3
v gtk2-2.8.3-9
To fulfill dependency requirements, you must install these Red Hat Package
Managers (RPMs) in the order specified.
Installing an RPM:
1. To install an RPM, use the following syntax:
rpm -i rpm_filename
2. To see a list of the RPMs that are installed, enter the following command:
rpm -qa
Acrobat Reader and LDAP:
By default, AIX systems do not have LDAP installed.
By default, AIX systems do not have LDAP installed. If the AIX system does not
have LDAP installed and you run Acrobat Reader, a warning message is displayed.
Click OK to have Acrobat Reader proceed normally.
To remove the error message, delete or rename /opt/acrobat/Reader/rs6000aix/

plug_ins/PPKLite.api, where /opt/acrobat is the installation path.
Linux platforms
Supported Linux Systems
IBM Tivoli Netcool Performance Manager, Version 1.4.2 can be installed and
operated in an environment that is using VMware partitions. Here are the details
the Linux environment prerequisites for Tivoli Netcool Performance Manager.
Operating system
Supported operating system and kernel versions.
Table 7. Tivoli Netcool Performance Manager supports the following Linux systems.
v Linux hosts running 64-bit Red Hat v Linux hosts running 64-bit Red Hat
Enterprise Linux Version 6.x or 7.2 with Enterprise Linux Version 6.x or 7.2 with
Oracle 12c for fresh install DB2 Version 10.1.0.5 for fresh install
v RHEL 6.x for upgrade option only. option.
v RHEL 6.x for upgrade option only.
To check the version of your operating To check the version of your operating
system, enter: system, enter:
# cat /etc/redhat-release # cat /etc/redhat-release
This command must return the output This command must return the output
similar to: similar to:
Red Hat Enterprise Linux Server Red Hat Enterprise Linux Server
release 6.x release 6.x
To verify the processor type, run the To verify the processor type, run the
following command: following command:
uname -p uname -p
To verify the machine type, run the To verify the machine type, run the
uname -m uname -m

Table 7. Tivoli Netcool Performance Manager supports the following Linux
systems. (continued)
To verify the hardware platform, run the To verify the hardware platform, run the
uname -i uname -i
All results should contain the output: All results should contain the output:
x86_64 x86_64
Database
Database requirements if you are using Linux.
It is recommended that you consult Metalink Note 880989.1, Requirements For

Installing Oracle, which has a full list of Oracle requirements for RHEL. Oracle
keeps this list up to date.
Note: See Note 225710.1 for supported kernels and Note 265262.1 for "Things to
know about Linux." https://support.oracle.com/CSP/main/article?cmd=show
&type=NOT&id=265262.1
Required packages for Oracle on Red Hat Enterprise Linux 6.x
Required packages if you are using Linux.
The following is a list of packages for Red Hat Enterprise Linux 6.x:
v binutils-2.20.51.0.2-5.11.el6 (x86_64)
v compat-libcap1-1.10-1 (x86_64)
v compat-libstdc++-33-3.2.3-69.el6 (i686) - both architectures are required.
v compat-libstdc++-33-3.2.3-69.el6 (x86_64) - both architectures are required.
v glibc-2.12-1.7.el6 (i686) - both architectures are required.
v glibc-2.12-1.7.el6 (x86_64) - both architectures are required.
v glibc-common-2.5-24 (x86_64)
v ksh-*.el6 (x86_64) - any version of ksh is acceptable.
v libaio-0.3.107-10.el6 (i686) - both architectures are required.
v libaio-0.3.107-10.el6 (x86_64) - both architectures are required.
v libgcc-4.4.4-13.el6 (i686) - both architectures are required.
v libgcc-4.4.4-13.el6 (x86_64)
v libstdc++-4.4.4-13.el6 (i686)
v libstdc++-4.4.4-13.el6 (x86_64)
v libXext-* (i686) - any version.
v libX11-* (i686)
v libxcb-* (i686)
v libXau-* (i686)
v make-3.81-19.el6 (x86_64)
v libXtst-1.0.99.2-3.el6.i686
Note: These are minimum required versions. Also, for some architectures both of
the i386 and x86_64 package versions must be verified.
For example, both the i386 and the x86_64 architectures for glibc-2.5-24 must be
installed.
Also required are:

v elfutils-libelf-devel-0.125-3.el5.x86_64.rpm
which in turn requires the following:
– elfutils-libelf-devel and
– elfutils-libelf-devel-static
One depends upon the other.
Therefore, they must be installed together, in one (1)rpm -ivh command as
follows:
rpm -ivh elfutils-libelf-devel-0.125-3.el5.x86_64.rpm elfutils-libelf-devel-static
-0.125-3.el5.x86_64.rpm
v glibc-headers-2.5-24.x86_64.rpm
– kernel-headers-2.6.18-92.el5.x86_64.rpm
– glibc-devel-2.12-1.7.el6 (i686).rpm - both architectures are required.
– glibc-devel-2.12-1.7.el6 (x86_64).rpm- both architectures are required.
v gcc-4.4.4-13.el6 (x86_64.rpm)
– libgomp-4.1.2-42.el5.x86_64.rpm
– libstdc++-devel-4.4.4-13.el6 (x86_64).rpm
– libstdc++-devel-4.4.4-13.el6 (i686).rpm
– gcc-c++-4.4.4-13.el6 (x86_64).rpm
– libaio-devel-0.3.107-10.el6 (i686).rpm - both architectures are required.
– libaio-devel-0.3.107-10.el6 (x86_64).rpm - both architectures are required.
– sysstat-9.0.4-11.el6 (x86_64).rpm
– unixODBC-2.2.11-7.1.x86_64.rpm - both architectures are required.
– unixODBC-2.2.11-7.1.i386.rpm - both architectures are required.
– unixODBC-devel-2.2.11-7.1.x86_64.rpm - both architectures are required.
– ODBC-devel-2.2.11-7.1.i386.rpm - both architectures are required.
The following packages are required and checked for by the check_os.ini
application:
v libXp-1.0.0-i386
v libXp-1.0.0-x86_64
v libXpm-3.5.5-x86_64
v libstdc++-devel-4.1.1-x86_64
v glibc-devel-2.5-i386
v glibc-devel-2.5-x86_64
v gcc-c++-4.1.2-x86_64
v openmotif-2.3.3-4.el6.i686

v openmotif-2.3.1-i386
v openmotif-2.3.1-x86_64
v gtk2.i686 2.18.9-6.el6
v cairo-1.8.8-3.1.el6.i686
v atk-1.28.0-2.el6.i686
v openssl098e-0.9.8e-17.el6.i686
Required packages for Oracle on Red Hat Enterprise Linux 7.2
The following is a list of packages for Red Hat Enterprise Linux 7.2:
v binutils.x86_64
v compat-libcap1.x86_64
v compat-libstdc++-33.i686
v compat-libstdc++-33.x86_64
v glibc.i686
v glibc.x86_64
v glibc-common.x86_64
v ksh.x86_64
v libaio.i686
v libaio.x86_64
v libaio-devel.i686
v libaio-devel.x86_64
v libgcc.i686
v libgcc.x86_64
v libstdc++.i686
v libstdc++.x86_64
v libXext.i686
v libXext.x86_64
v libX11.i686
v libX11.x86_64
v libxcb.i686
v libxcb.x86_64
v libXau.i686
v libXau.x86_64
v make.x86_64
v libXtst.i686
v libXtst.x86_64
v libXi.i686
v libXi.x86_64
v sysstat.x86_64
v unixODBC.x86_64
v unixODBC-devel.x86_64
v zlib-devel.x86_64
v zlib-devel.i686
v elfutils-libelf-devel.x86_64
v glibc-headers.x86_64
v gcc.x86_64
v libXp.i686
v libXp.x86_64
v libXpm.x86_64
v libstdc++-devel.i686
v libstdc++-devel.x86_64
v glibc-devel.i686
v glibc-devel.x86_64
v gcc-c++.x86_64
v gtk2.i686
v cairo.i686
v atk.i686
v vsftpd.x86_64
v xterm.x86_64
v motif.i686
v motif.x86_64
v openssl.x86_64
v openssl098e.i686
v libcanberra.i686
v libcanberra-devel.*
v PackageKit-gtk3-module.i686
v adwaita-gtk2-theme.i686
the i686 and x86_64 package versions must be verified.
For example, both the i686 and the x86_64 architectures for glibc-2.5-24 must be
installed.
Required packages for IBM DB2 on Red Hat Enterprise Linux 6.x
The following list shows the package requirements for Red Hat Enterprise Linux
distributions:
v libpam.so.0 (32-bit) is required for DB2 database servers to run 32-bit non-SQL
routines.
v libaio.so.1 is required for DB2 database servers that are using asynchronous
I/O.
v libstdc++.so.6 is required for DB2 database servers and clients.

Table 8. Package requirements for Red Hat Enterprise Linux
Package name Description
libaio Contains the asynchronous library that is
required for DB2 database servers.
compat-libstdc++ Contains libstdc++.so.6 (not required for
Linux on POWER)
The following tables list the package requirements for Red Hat Enterprise Linux
distributions for DB2 partitioned database servers.
v The ksh93 Korn shell is required for RHEL5 systems. The pdksh Korn Shell
package is required for all other DB2 database systems.
v A remote shell utility is required for partitioned database systems. DB2 database
systems support the following remote shell utilities:
– rsh
– ssh
By default, DB2 database systems use rsh when you run commands on
remote DB2 nodes, for example, when you start a remote DB2 database
partition. To use the DB2 database system default, the rsh-server package
must be installed (see following table). More information about rsh and ssh is
available in the DB2 Information Center.
If you choose to use the rsh remote shell utility, inetd (or xinetd) must be
installed and running as well. If you choose to use the ssh remote shell utility,
you must set the DB2RSHCMD communication variable immediately after the
DB2 installation is complete. If this registry variable is not set, rsh is used.
v The nfs-utils Network file system support package is required for partitioned
database systems.
All required packages must be installed and configured before you continue with
the DB2 database system setup. For general Linux information, see your Linux
distribution documentation.
Table 9. Package requirements for Red Hat Enterprise Linux
Directory Package name Description
/System Environment/Shell pdksh or ksh93 Korn Shell.
/Applications/Internet openssh This package contains a set
of client programs, which
allow users to run
commands on a remote
computer via a Secure Shell.
This package is not required
if you use the default
configuration of DB2
database systems with rsh.
/System Environment/ openssh-server This package contains a set
Daemons of server programs, which
allow users to run
commands from a remote
computer via a Secure Shell.
This package is not required
if you use the default
configuration of DB2
database systems with rsh.
Table 9. Package requirements for Red Hat Enterprise Linux (continued)
Directory Package name Description
/System Environment/ rsh-server This package contains a set
Daemons of programs, which allow
users to run commands on a
remote computer. Required
for partitioned database
environments. This package
is not required if you
configure DB2 database
systems to use ssh.
/System Environment/ nfs-utils Network File System support
Daemons package. It allows access to
local files from remote
computers.
Extra packages that are required:

v binutils-2.17.50.0.6-6.el5 (x86_64)
v compat-libstdc++-33-3.2.3-61 (x86_64)
v compat-libstdc++-33-3.2.3-61 (i386)
v elfutils-libelf-0.125-3.el5 (x86_64)
v glibc-2.5-24 (x86_64)
v glibc-2.5-24 (i686) - both architectures are required.
v glibc-common-2.5-24 (x86_64)
v ksh-20060214-1.7 (x86_64)
v libaio-0.3.106-3.2 (x86_64)
v libaio-0.3.106-3.2 (i386)
v libgcc-4.1.2-42.el5 (i386)
v libgcc-4.1.2-42.el5 (x86_64)
v libstdc++-4.1.2-42.el5 (i386)
v make-3.81-3.el5 (x86_64)
the i386 and x86_ 64 package versions must be verified. For example, both the i386
and the x86_64 architectures for glibc-2.5-24 must be installed.
v elfutils-libelf-devel-0.125-3.el5.x86_64.rpm
Requires the following interdependent packages:
– elfutils-libelf-devel
– elfutils-libelf-devel-static
Note: Since these packages are interdependent, they must be installed

together by using the following command:
rpm -ivh elfutils-libelf-devel-0.125-3.el5.x86_64.rpm
elfutils-libelf-devel-static-0.125-3.el5
v glibc-headers-2.5-24.x86_64.rpm
Requires the following packages:
– kernel-headers-2.6.18-92.el5.x86_64.rpm
– glibc-devel-2.5-24.x86_64.rpm
– glibc-devel-2.5-24.i386.rpm

v gcc-4.1.2-42.el5.x86_64.rpm
Requires the following packages:
– libgomp-4.1.2-42.el5.x86_64.rpm
– libstdc++-devel-4.1.2-42.el5.x86_64.rpm
– gcc-c++-4.1.2-42.el5.x86_64.rpm
– libaio-devel-0.3.106-3.2.x86_64.rpm
– libaio-devel-0.3.106-3.2.i386.rpm
– sysstat-7.0.2-1.el5.x86_64.rpm
– unixODBC-2.2.11-7.1.x86_64.rpm
– unixODBC-2.2.11-7.1.i386.rpm
– unixODBC-devel-2.2.11-7.1.x86_64.rpm
– unixODBC-devel-2.2.11-7.1.i386.rpm
v The following packages are required and checked for by the check_os.ini
application:
– libXp-1.0.0-i386
– libXp-1.0.0-x86_64
– libXpm-3.5.5-x86_64
– libstdc++-devel-4.1.1-x86_6
– glibc-devel-2.5-i386
– glibc-devel-2.5-x86_64
– gcc-c++-4.1.2-x86_64
– motif-2.3.4-7.el7.i386
– motif-2.3.4-7.el7.x86_64
Run the db2prereqcheck command to check if your system meets the prerequisites
for the installation of a specific version of DB2 for Linux, UNIX, and Windows. For
example, run the following commands:
./db2prereqcheck -v 10.1.0.5 -s
DBT3533I The db2prereqcheck utility has confirmed that all installation prerequisites
were met for DB2 database "server " "". Version: "10.1.0.5"
were met for DB2 database "server " "with DB2 pureScale feature ". Version: "10.1.0.5"
Required packages for IBM DB2 on Red Hat Enterprise Linux 7.2
Required packages if you are using Linux 7.2.
The following list shows the package requirements for Red Hat Enterprise Linux
distributions:
v binutils.x86_64
v compat-libstdc++-33.x86_64
v compat-libstdc++-33.i686
v elfutils-libelf.x86_64
v glibc.x86_64
v glibc.i686
v glibc-common.x86_64
v ksh.x86_64
v libaio.x86_64
v libaio.i686
v libgcc.i686
v libgcc.x86_64
v libstdc++.i686
v make.x86_64
v elfutils-libelf-devel.x86_64
v glibc-headers.x86_64
v gcc.x86_64
v libXp.i686
v libXp.x86_64
v libXpm.x86_64
v libstdc++-devel.x86_64
v glibc-devel.i686
v glibc-devel.x86_64
v gcc-c++.x86_64
v vsftpd.x86_64
v nfs-utils.x86_64
v pam.x86_64
v motif.i686
v motif.x86_64
v openssl.x86_64
v openssl098e.i686
v libcanberra.i686
v libcanberra-devel.*
v PackageKit-gtk3-module.i686
v adwaita-gtk2-theme.i686
All required packages must be installed and configured before you continue with
the DB2 database system setup. For general Linux information, see your Linux
distribution documentation.
the i686 and x86_64 package versions must be verified. For example, both the i686
and the x86_64 architectures for glibc-2.5-24 must be installed.
Run the db2prereqcheck command to check if your system meets the prerequisites
for the installation of a specific version of DB2 for Linux, UNIX, and Windows. For
example, run the following commands:
./db2prereqcheck -v 10.1.0.5 -s
were met for DB2 database "server " "". Version: "10.1.0.5"
were met for DB2 database "server " "with DB2 pureScale feature ". Version: "10.1.0.5"
DataMart
DataMart requirements if you are using Linux.

Java Runtime Environment (JRE) 1.7 or higher (for the Database Information
module).
DataLoad
DataLoad requirements if you are using Linux.
DataChannel
DataChannel requirements if you are using Linux.
Required user names

There are two user names that must be created when installing Tivoli Netcool
Two specific user names are required on any server hosting Tivoli Netcool
Performance Manager components, they are:
pvuser
A dedicated Tivoli Netcool Performance Manager Unix user.
oracle A dedicated Oracle user.
db2 A dedicated DB2 user.
pvuser
The pvuser user name.
The Tivoli Netcool Performance Manager UNIX user pvuser must be added to each
server that is hosting a Tivoli Netcool Performance Manager component. The Tivoli
Netcool Performance Manager UNIX user, which is referred to as pvuser
throughout the documentation, can be named by using any string as required by
your organizations naming standards.
oracle
The oracle user name.
The Oracle user is added to each server that is hosting a Tivoli Netcool
Performance Manager component. This user is added during Oracle client or
server installation. The default username that is used is oracle.
However, this Oracle username can be named by using any string as required by
your organizations naming standards.
If you are installing Oracle by using a non-default username, then the non-default
user must be created with Korn shell as its login shell.
# useradd -g <group> -G <group_2> -m -d <home_dir>/<username> -k /etc/skel -s /bin/ksh <username>
Where:
v <group> is the name of the primary group to be assigned to the new user.
v <group_2> is the name of the subsequent group to be assigned to the new user.
v <home_dir> is the home directory for the new user.
v <username> is the name of the new user, which can be set to any string.
For example:
useradd -g dba -G oinstall -m -d /export/home/oracle2 -k /etc/skel -s /bin/ksh oracle2
Note: If you choose a non-default Oracle username, you must use the same name
across all instances of Oracle Client and Server throughout your Tivoli Netcool
Performance Manager system.
db2
The db2 user name.
The DB2 user db2 is added to each server hosting a Tivoli Netcool Performance
Manager component. This user is added when installing either DB2 client or
server. The default username used is db2; however, this DB2 username can be
named using any string as required by your organizations naming standards.
Note: If you want to select a non-default DB2 username, you must use the same
name across all instances of DB2 client and server throughout your Tivoli Netcool
Performance Manager system.
Ancillary software requirements

Extra and third-party software requirements.
Extra software packages required by Tivoli Netcool Performance Manager.
FTP support
Tivoli Netcool Performance Manager requires FTP support.
The FTP (File Transfer Protocol) version that is used to transfer files between Tivoli
Netcool Performance Manager components is delivered with Solaris 10.
AIX also uses FTP to transfer files between Tivoli Netcool Performance Manager
components.
Tivoli Netcool Performance Manager supports the following file transport protocols
between Tivoli Netcool Performance Manager components and third-party
equipment (for example, EMS):
v FTP Solaris 10
v Microsoft Internet Information Services (IIS) FTP server

OpenSSH and SFTP
Tivoli Netcool Performance Manager requires OpenSSH and SFTP support.
Tivoli Netcool Performance Manager supports encrypted Secure File Transfer

(SFTP) and FTP to move data files from DataLoad to DataChannel, or from
DataChannel Remote to the DataChannel Loader.
Tivoli Netcool Performance Manager SFTP is compatible only with OpenSSH

server and client version 3.1p 1 and above. OpenSSH is freely downloadable and
distributable (http://www.openssh.org). OpenSSH is supported on Solaris, AIX,
and Linux. Other SSH versions such as F-Secure, the SSH bundled in Solaris 10
and the SSH bundled with AIX is not compatible.
If you use the SFTP capability, you must obtain, install, generate keys for, maintain,
and support OpenSSH and any packages that are required by OpenSSH.
See Tivoli Netcool Performance Manager Technical Note: DataChannel Secure File Transfer
Installation for more information about installing and configuring OpenSSH.
AIX requirements
AIX requirements in order to use OpenSSH and SFTP.
The following table lists additional prerequisites that must be installed on an AIX
system, and where these packages can be found:
Table 10. Additional Prerequisites
Package Location
openssl-0.9.7g-1.aix5.1.ppc.rpm https://www14.software.ibm.com/webapp/
iwm/web/preLogin.do?source=aixtbx
openssh-4.1p1_53.tar.Z https://sourceforge.net/projects/openssh-
aix/
bos.adt.libm AIX installation CD.
Solaris requirements
Solaris requirements in order to use OpenSSH and SFTP.
The following are additional prerequisites that must be installed on an Solaris

systems:
v openssh- SSH client (openssh-4.5p1-sol-sparc-local.gz or higher).
v zlib - zlib compression and decompression library (zlib-1.2.3-sol9-sparc-
local.gz or higher).
Linux requirements
Linux requirements in order to use OpenSSH and SFTP.
OpenSSH is required for VSFTP to work with Tivoli Netcool Performance Manager.
OpenSSH is installed by default on any RHEL system.
By default, FTP is not enabled on Linux systems. You must enable FTP on your
Linux host to carry out the installation of Tivoli Netcool Performance Manager.
To enable FTP on your Linux host, run the following command as root:
/etc/init.d/vsftpd start
File compression
File compression support.
Archives that are delivered as part of the IBM Tivoli Netcool Performance Manager
distribution are created by using GNU TAR. This program must be used for the
decompression of archives.
DataView load balancing

Load balancing support.
IBM Tivoli Netcool Performance Manager supports the use of an external load
balancer to optimize the use of available DataView instances.
The load balancer must support the following basic features:

v Basic IP-based load balancing
v Sticky sessions based on incoming IP
v Up/down status based on checking for a listening port
Link to CSS Basic Configuration Guide: http://www.cisco.com/en/US/docs/

app_ntwk_services/data_center_app_services/css11500series/v7.20/configuration/
basic/guide/bsccfggd.html
Databases
Tivoli Netcool Performance Manager 1.4.2 supports both the databases, Oracle and
IBM DB2.
Oracle support
Oracle server support and hidden Oracle parameters.
License recommendations
When purchasing a license from Oracle, IBM recommends a Processor license

rather than a Named User Plus license.
Oracle defines a Named User in such a way that it includes not only actual human
users, but also non-human-operated devices. In other words, you would require a
Named User Plus license for every resource that Tivoli Netcool Performance
Manager polls, which would be very expensive.
http://www.oracle.com .
Oracle server support

Oracle 12c Enterprise Edition for Solaris (SPARC) and Linux AIX are 64-bit
only. Oracle 12c Enterprise Edition must include the partitioning option.
The database no longer provides 32-bit libraries, therefore you must install
the Oracle client on every host of the Tivoli Netcool Performance Manager.
Note: Tivoli Netcool Performance Manager must be installed and run as a

standalone database. It must not be placed on a server that already has a
database as the installation program will likely to interfere. The co-hosting
of Tivoli Netcool Performance Manager also affects performance in
unknown ways. If a co-host is required then the Customer should seek out
Professional Services for support.
Hidden Oracle parameters
This section lists all of the Oracle '_', or hidden parameters, used by Tivoli
Netcool Performance Manager:
v _partition_view_enabled = TRUE
v _unnest_subquery = FALSE
v _gby_hash_aggregation_enabled = FALSE
DB2 servers and IBM Data Server clients
DB2 server and client support.

DB2 server support
IBM DB2 Enterprise Server Edition 10.1.0.5, Linux 64-bit only.

unknown ways. If a co-host is required then the Customer must seek IBM
DB2 client support
IBM Data Server Client 10.1.0.5 Linux 64-bit only.

unknown ways. If a co-host is required then the Customer must seek IBM
For more information about DB2 servers, see http://www.ibm.com/
software/data/db2/.
Jazz for Service Management
Dashboard Application Services Hub is replacing the Tivoli Integrated Portal.
Jazz for Service Management contains the following components:

v Dashboard Application Services Hub
v Security Services
v Registry Services
v Reporting Services environment
v Tivoli Common Reporting
Note: The supported Tivoli Common Reporting is 3.1.2.1
Java Runtime Environment (JRE)

Required Java support.
Java Runtime Environment (JRE) 1.7 (32-bit) is required for all servers hosting
Tivoli Netcool Performance Manager components.
Web browsers and settings for DataView reports

Supported browsers.
The following browsers are required to support the web client and provide access
to DataView reports:
Important: No other browser types are supported.

Table 11. Windows Clients
Windows 7
v Microsoft Internet Explorer 11.0

v Mozilla Firefox ESR 24, 31 and 38
Note: When you are using Windows Internet Explorer, IBM recommends that you
have available at least 1 GB of memory
Table 12. UNIX Clients
AIX RHEL Solaris 10
Mozilla Firefox 3.6 Mozilla Firefox ESR 24, 31 Mozilla Firefox ESR 24, 31
and 38 and 38
The following are required browser settings:

v Enable JavaScript
v Enable cookies
Browser requirements for the Launchpad

Web browser requirements for the Launchpad.
The new Launchpad has been tested on the following browsers:

v Mozilla Firefox ESR 17 and 24
v Mozilla Firefox 3.6
v Red Hat Enterprise Linux (RHEL) 6.x

– Mozilla Firefox ESR 24 and 31
v Red Hat Enterprise Linux (RHEL) 7.2
– Mozilla Firefox ESR 38
For information about downloading and installing these browsers, see the
following web sites:
v http://www.mozilla.org/
v http://www-03.ibm.com/systems/p/os/aix/browsers/index.html
Note: You must be a registered user to use this site.
Screen resolution
A screen resolution of 1152 x 864 pixels or higher is recommended for the display
of DataView reports. Some reports may experience rendering issues at lower
resolutions.
Report Studio - Cognos

Report Studio support.
Report Studio is only supported by Microsoft Internet Explorer.
X Emulation
Remote desktop support.
For DataMart GUI access, Tivoli Netcool Performance Manager supports the
following:
v Native X Terminals
v Exceed V 6.x
The following libraries are required for Exceed to work with Eclipse:
v libgtk 2.10.1
v libgib 2.12.1
v libfreetype 2.1.10
v libatk 1.12.1
v libcairo 1.2.6
v libxft 2.1.6
v libpango 1.14.0
v Real VNC server 4.0
IBM Tivoli Netcool/OMNIbus Web GUI integration
IBM Tivoli Netcool/OMNIbus Web GUI, Version 8.1 support.
The IBM Tivoli Netcool/OMNIbus Web GUI Integration Guide for Wireline describes
how to integrate IBM Tivoli Netcool/OMNIbus Web GUI and Jazz for Service
Management 1.1.2.1 with the wireline component of Tivoli Netcool Performance
Manager.
Tivoli Netcool Performance Manager 1.4.2 supports:
Jazz for Service Management 1.1.2.1 and IBM Tivoli Netcool/OMNIbus Web GUI
8.1.
The web browsers supported by IBM Tivoli Netcool/OMNIbus Web GUI and
Tivoli Netcool Performance Manager are listed in the following table.
Table 13. Web clients browsers supported by IBM Tivoli Netcool/OMNIbus Web GUI
Browser Version Operating system
Internet Explorer 11.0 Windows 7
Mozilla Firefox ESR 24
Windows 7
31
38
Red Hat
Enterprise Linux (RHEL) 6.x
or 7.2
Note: When you are using Internet Explorer, IBM recommends that you have at
least 1 GB of memory available.
Microsoft Office Version

Microsoft Office support.
The Tivoli Netcool Performance Manager DataView Scheduled Report option

generates files compatible with Microsoft Office Word 2002 or higher.

Chapter 3. Installing and configuring the prerequisite software
Installing and configuring the prerequisite software required by Tivoli Netcool

Overview
Before you begin the Tivoli Netcool Performance Manager installation, you must
install the prerequisite software that is listed in the Requirements chapter.
You need the following software for database of your choice.
Oracle
Software required if you are using Oracle as your database.

Oracle server
You must install the 64-bit Oracle server. To use Oracle with Tivoli Netcool
Performance Manager, you must install Oracle as described in this chapter
- do not use a separate Oracle installation method provided by Oracle
Corporation.
Oracle client
You must install the 32-bit Oracle client. You must have at least one
computer where you install:
v Tivoli Netcool Performance Manager
v 64-bit Oracle server
v 32-bit Oracle client
This computer is the Oracle Database server. You must install the Oracle
server at /opt/oracle/product/12.1.0 and the Oracle client at
/opt/oracle/product/12.1.0-client32.
When you complete the steps that are given, the Oracle server and client are
installed and running, with table spaces sized and ready to accept the installation
of a Tivoli Netcool Performance Manager DataMart database. You can
communicate with Oracle by using the SQLPlus command-line utility.
Use IBM-provided installation scripts to install and configure the Oracle database
from the Oracle distribution. For use with Tivoli Netcool Performance Manager,
you must install Oracle as described. Do not use a separate Oracle installation
method that is provided by Oracle Corporation. You must obtain the official Oracle
distribution from your delivery site (after purchase of an Oracle license). See the
Requirements for recommendations when you purchase a license from Oracle.
Note: The Tivoli Netcool Performance Manager script that is used to install Oracle
is platform-independent and can be used to install on Solaris, AIX, or Linux,
regardless of the operating system distribution media.

OpenSSH
You must install and configure OpenSSH before you install Tivoli Netcool
Performance Manager. For details, see Appendix E, “Secure file transfer
installation,” on page 263. Linux systems require the installation of VSFTP
(Very Secure FTP).
Web browser
The launchpad requires a web browser. IBM suggests you to use Mozilla
with the launchpad. For the complete list of supported browsers, see the
Requirements.
Java Java is used by DataMart, DataLoad, and the technology packs. You must
ensure that you are using the IBM JRE and not the RHEL JRE. The IBM
JRE is supplied with the Topology Editor. To ensure that you are using the
right JRE you can either: Set the JRE path to conform the one that is used
by the Topology Editor, you can do it by using the following commands
(by using the default location for the primary deployer):
PATH=/opt/IBM/proviso/topologyEditor/jre/bin:$PATH
export $PATH
For a remote server that does not host the primary deployer, you must
download and install the required JRE, and set the correct JRE path. See
Requirements for JRE download details.
Note: See Requirements for the complete list of prerequisite software and their
supported versions.
IBM DB2
Software required if you are using DB2 as your database.

IBM DB2 Enterprise Server Edition 10.1.0.5, Linux 64-bit
You must install DB2 Server software on a system where you plan to
install a Tivoli Netcool Performance Manager database component. For
more information about installing DB2 Version 10.1.0.5 Server, see
http://www-01.ibm.com/support/knowledgecenter/SSEPGG_10.1.0/
com.ibm.db2.luw.qb.server.doc/doc/c0060076.html
IBM Data Server Client 10.1.0.5, Linux 64-bit
You must install DB2 client software on each system where you plan to
install a Tivoli Netcool Performance Manager component, except for the
system where you installed the DB2 server.
When you complete the steps here, the DB2 server and client is installed
and running, with table spaces sized and ready to accept the installation of
a Tivoli Netcool Performance Manager DataMart database. You can
communicate with DB2 by using the clpplus command-line utility.
Other software:
OpenSSH
You must install and configure OpenSSH before you install Tivoli Netcool
Performance Manager. For details, see Appendix E, “Secure file transfer
installation,” on page 263. Linux systems require the installation of VSFTP
(Very Secure FTP).
Web browser
The launchpad requires a web browser. IBM suggests you to use Mozilla

with the launchpad. For the complete list of supported browsers, see the
Configuration Recommendations document.
Java Java is used by DataMart, DataLoad, and the technology packs. You must
ensure that you are using the IBM JRE and not the Red Hat Enterprise
Linux JRE. The IBM JRE is supplied with the Topology Editor. To ensure
that you are using the right JRE you can either: Set the JRE path to
conform the one that is used by the Topology Editor, you can do it by
using the following commands (by using the default location for the
primary deployer):
export $PATH
For a remote server that does not host the primary deployer, you must
download and install the required JRE, and set the correct JRE path. See
the Configuration Recommendations document for JRE download details.
Note: See the Configuration Recommendations document for the complete list of
prerequisite software and their supported versions.
Supported platforms
The platforms supported by Tivoli Netcool Performance Manager.
Refer to the following table for platform requirement information.
Tivoli Netcool Performance Manager

Component Required Operating Systems
All Tivoli Netcool Performance Manager v Solaris 10 Update 6 (released in October,
Components: 2008)
v Database v AIX 6.1 TL 04 SP1 ("6100-04-01), 64-bit
v DataView kernel
v DataChannel AIX 7.1 POWER7 TL 0 SP3 ("7100-00-03")
v DataLoad 64-bit kernel
v DataMart AIX 7.1 TL 03 SP3 ("7100-03-03") 64-bit
kernel
v Red Hat Enterprise Linux Server release
6.x or 7.2 for fresh installation
Red Hat Enterprise Linux 6.x for upgrade
Pre-Installation setup tasks

Before installing the prerequisite software, perform the tasks outlined in this
section.
Chapter 3. Installing and configuring the prerequisite software 69

Setting up a remote X Window display
Setting Up a Remote X Window Display.
About this task
For most installations, it does not matter whether you use a Telnet, rlogin, Xterm,
or Terminal window to get to a shell prompt.
Some installation steps must be performed from a window that supports the X
Window server protocols. This means that the steps described in later chapters
must be run from an Xterm window on a remote system or from a terminal
window on the target system's graphical display.
Note: See the Configuration Recommendations document for the list of supported X
emulators.
Specifying the DISPLAY environment variable

If you use an X Window System shell window such as Xterm, you must set the
DISPLAY environment variable to point to the IP address and screen number of
the system you are using.
About this task
Command sequences in this manual do not remind you at every stage to set this
variable.
If you use the su command to become different users, be especially vigilant to set
DISPLAY before running X Window System-compliant programs.
Procedure
In general, set DISPLAY as follows:

$ DISPLAY=Host_IP_Address:0.0 $ export DISPLAY
To make sure the DISPLAY environment variable is set, use the echo command:
$ echo $DISPLAY
Disabling access control to the display

If you encounter error messages when trying to run X Window System-based
programs, you might need to temporarily disable X Window System access control
so an installation step can proceed.
About this task
To disable access control:
Procedure
1. Set the DISPLAY environment variable.
2. Enter the following command when logged in as root:
# /usr/openwin/bin/xhost +
Note: Disabling access control is what enables access to the current machine
from X clients on other machines.

Changing the ethernet characteristics
Before installing Tivoli Netcool Performance Manager, you must force both the
ethernet adapter and the port on the switch to 100 full duplex mode -
autonegotiate settings are not enough.
AIX systems
Changing ethernet characteristics on AIX.
About this task
To change the setting to full duplex:
Note: If the AIX node is a virtual partition, you must perform these steps on the
virtual I/O server (including the reboot).
Procedure
1. Using the System Management Interface Tool (SMIT), navigate to Devices >
Communication > Ethernet Adapter > Adapter > Change/Show
Characteristics of an Ethernet Adapter.
2. Select your ethernet adapter (the default is ent0).
3. Change the setting Apply change to DATABASE only to yes.
4. Set the port on the switch or router that the AIX node is plugged into to
100_Full_Duplex.
5. Reboot your system.
Solaris systems
This section describes how to set a network interface card (NIC) and a BGE
network driver to full duplex mode.
NIC:
Change the NIC to full duplex mode on Solaris systems
About this task
To change the NIC to full duplex mode:
Procedure
1. Determine which type of adapter you have by running the following command:
ifconfig -a
2. To determine the current settings of the NIC, run the command ndd -get
/dev/hme with one of the following parameters:
Command Parameter Description

link_status Determines whether the link is up
v 1 - Up
v 0 - Down
link_speed Determines the link speed
v 0 - 10Mb/sec
v 1 - 100Mb/sec

Command Parameter Description
link_mode Determines the duplex mode
v 0 - Half duplex
v 1 - Full duplex
adv_autoneg_cap Determines whether auto negotiation is on
v 0 - Off
v 1 - On
For example:
ndd -get /dev/hme link_status
In these commands, /dev/hme is your NIC; you might need to substitute your
own /dev/xxx.
3. To set your NIC to 100Mb/s with full duplex for the current session, run the
following commands:
ndd -set /dev/hme adv_100hdx_cap 0
ndd -set /dev/hme adv_100fdx_cap 1
ndd -set /dev/hme adv_autoneg_cap 0
However, these commands change the NIC settings for the current session only.
If you reboot, the settings will be lost. To make the settings permanent, edit the
/etc/system file and add the following entries:
set hme:hme_adv_autoneg_cap=0
set hme:hme_adv_100hdx_cap=0
set hme:hme_adv_100fdx_cap=1
4. Verify that your NIC is functioning as required by rerunning the commands
listed in Step 2.
BGE network driver:
Change a BGE network driver to full duplex mode.
About this task
To change a BGE network driver to full duplex mode.
Procedure
1. To determine the link speed and current duplex setting, run the following
command:
% kstat bge:0 | egrep ’speed|duplex’
The output is similar to the following:
duplex full
ifspeed 100000000
link_duplex 2
link_speed 100
The parameters are as follows:
Parameter Description
link_duplex Determines the duplex setting

v 1 - Half-duplex
v 2 - Full duplex

Parameter Description
link_speed Determines the link speed

v 10 - 10 Mb/sec
v 100 - 100 Mb/sec
v 1000 - 1 Gb/sec
2. Create a file namedbge.conf in the /platform/uname -i/kernel/drv directory

(for example, /platform/SUNW,Sun-Fire-V210/kernel/drv/bge.conf).
3. Add the following lines to the file:
speed=100;
full duplex=1;
4. Reboot the machine to have your changes take effect.
Linux systems
Enabling 100 full duplex mode on Linux systems.
About this task
Use your primary network interface to enable 100 full duplex mode.
To check if full duplex is enabled:
Procedure
1. Enter the following command:
# dmesg | grep -i duplex
This should result in output similar to the following:
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
2. Confirm the output contains the words:
Full Duplex
If this is not contained within the output, you must enable full duplex mode.
The example output resulting from the command executed in step 1:
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
indicate that the primary network interface is eth0.
The actions specified in the following process presume that your primary
network interface is eth0.
Enabling full duplex mode on Linux:
To enable full duplex mode.
Procedure
1. Open the file ifcfg-eth0, which is contained in:
/etc/sysconfig/network-scripts/
2. Add the ETHTOOL_OPTS setting by adding the following text:
ETHTOOL_OPTS="speed 100 duplex full autoneg off"
Note: The ETHTOOL_OPTS speed setting can be set to either 100 or 1000
depending on speed of connection available 100Mbit/s or 1000Mbit/s
(1Gbit/s).

Adding the pvuser login name
pvuser is the default name used within this document to describe the required
Tivoli Netcool Performance Manager UNIX user.
The required user can be given any name of your choosing. However, for the
remainder of this document this user is referred to as "pvuser".
Decide in advance where to place the home directory of the pvuser login
username. Use a standard home directory mounted on /home or /export/home, as
available.
Note: Do not place the home directory in the same location as the Tivoli Netcool
Performance Manager program files. That is, do not use /opt/proviso or any other
directory in /opt for the home directory.
Add the pvuser login name to every system on which you install a Tivoli Netcool
Performance Manager component, including the system hosting the Oracle or DB2
server.
Adding pvuser to a Standalone Computer

Use the steps in this section to add the pvuser login name to each standalone
computer.
About this task
These steps add the login name only to the local system files on each computer
(that is, to the local /etc/passwd and /etc/shadow files). If your network uses a
network-wide database of login names such as Yellow Pages or Network
Information Services (NIS or NIS+), see “Adding pvuser on an NIS-managed
network” on page 75.
To add pvuser:
Procedure
1. Log in as root.
2. Set and export the DISPLAY environment variable. (see“Setting up a remote X
Window display” on page 70.)
3. If one does not already exist, create a group to which you can add pvuser. You
can create a group with the name of your choice using the following command:
groupadd <group>
where:
v <group> is the name of the new group, for example, staff.
4. At a shell prompt, run the following command:
# useradd -g <group> -m -d <home_dir>/<username> -k /etc/skel -s /bin/ksh <username>
Where:
v <group> is the name of the group to which you want to add pvuser.
v <home_dir> is the home directory for the new user, for example,
/export/home/ can be used as the example home directory.
v <username> is the name of the new user. This can be set to any string.
Note: For the remainder of this information this user will be referred to as
pvuser.

5. Set a password for pvuser:
# passwd pvuser
The system prompts you to specify a new password twice. The default pvuser
password assumed by the Tivoli Netcool Performance Manager installer is PV.
This can be set to a password conforming to your organization's standards.
6. Test logging in as pvuser, either by logging out and back in, or with the su
command, such as:
# su - pvuser
Confirm that you are logged in as pvuser with the id command:
$ id
These instructions create a pvuser login name with the following attributes:
Attribute Value
login name pvuser
member of group staff

home directory /export/home/pvuser
login shell Korn shell (/bin/ksh)

copy skeleton setup files (.profile, and so on) /etc/skel
from this directory
Note: The pvuser account must have write access to the /tmp directory.
Multiple computer considerations

If you are creating the pvuser login name on more than one computer in your
network, avoid confusion by specifying the same user ID number for each pvuser
login name on each computer.
When you create the first pvuser login name, log in as pvuser and run the id
command. The system responds with the user name and user ID number (and the
group name and group ID number). For example:
$ id uid=1001(pvuser) gid=10(staff)
When you create the pvuser login name on the next computer, add the -u option to
the useradd command to specify the same user ID number:
# useradd -g <group> -m -d <home_dir>/pvuser -k /etc/skel -s /bin/ksh -u 1001 pvuser
Where:
v <group> is the name of the group to which you want to add pvuser.
v <home_dir> is the home directory for the new user, for example, /export/home/
can be used as the example home directory.
v <username> is the name of the new user. This can be set to any string.
Adding pvuser on an NIS-managed network

Adding pvuser on an NIS-Managed Network.
If your site's network uses NIS or NIS+ to manage a distributed set of login names,
see your network administrator to determine whether pvuser must be added to
each Tivoli Netcool Performance Manager computer's local setup files, or to the
network login name database.

Setting the resource limits
On AIX systems, it is possible that the default user process limits are not adequate
for Tivoli Netcool Performance Manager.
About this task
If the default user process limits are not adequate for Tivoli Netcool Performance
Manager, do the following.
To set the user process limits on AIX systems:
Procedure
1. Log in as root.
2. Change your working directory to /etc/security by entering the following
command:
# cd /etc/security
3. Make a backup copy of the limits file by entering the following command:
# cp limits limits.ORIG
4. Using a text editor, open the limits file and set the following values:
default: fsize = -1 core = -1 cpu = -1 data = -1 rss = 65536 stack = 65536 nofiles = 2000
totalProcesses = 800
Note: Apply these settings to every AIX system running a Tivoli Netcool
Performance Manager program: the database server, DataLoad servers,
DataChannel servers, and DataMart servers.
5. Write and quit the file.
6. After modifying the settings, log off every Tivoli Netcool Performance Manager
user and then log in again for the changes to take effect.
Setting the shell limits (Linux only)
Set the shell limits for the oracle user.
About this task
On Linux systems, it is possible that the default user process limits are not
adequate for Tivoli Netcool Performance Manager. To improve the performance of
the software, you must increase the shell limits for the Oracle user.
Procedure
Add the following settings to the /etc/security/limits.conf file:

<Oracle username> soft nproc 2047
<Oracle username> hard nproc 16384
<Oracle username> soft nofile 1024
<Oracle username> hard nofile 65536
<Oracle username> soft stack 10240
Note: Use tabs between the fields instead of spaces for the settings to work
effectively.
Important: The default Oracle username is oracle. If you are installing Oracle by
using a non-default Oracle username, use the non-default username in the
/etc/security/limits.conf.

Setting the shell limits (Solaris only)
Set the shell limits for the oracle user.
About this task
On Solaris systems, it is possible that the default user process limits are not
adequate for Tivoli Netcool Performance Manager. To improve the performance of
the software, you must increase the shell limits for the oracle user.
Procedure
1. Run the following command:
# plimit –n soft_limit,hard_limit $$
# plimit -n 2048,65536 $$
2. To verify that the limits was updated correctly, run the following command:
# prctl -n process.max-file-descriptor $$
Set the system parameters
Before you install the Oracle server, you must set the Solaris shared memory and
semaphore parameters.
About this task
If using Solaris 10 containers, typically the variable in /etc/system is set only in

the root container, and project variables are set for each container. Refer to Solaris
10 container documentation for further information.
When you install Tivoli Netcool Performance Manager, you specify the size of the
deployment - small, medium, or large. The value you select affects the Oracle
PROCESSES parameter. You must set the appropriate kernel parameter level in
order for the deployment to work properly.
Note: These entries are only for the system running the Oracle server, not the
Oracle client.
To set Solaris system parameters:
Procedure
1. Set the NOEXEC_USER_STACK parameter in the system file:
a. Log in as root.
b. Change to the /etc directory:
# cd /etc
c. Create a backup of the file named system, and open the file with a text
editor.
d. Set the parameter NOEXEC_USER_STACK to 1, by adding the following line at
the bottom of the file:
set NOEXEC_USER_STACK=1
e. Save and exit the system file.
2. Set resource controls correctly.

The parameters affected by the deployment size are project.max-sem-ids,
process.max-sem-nsems, project.max-shm-memory, and project.max-shm-ids.
These parameters define the maximum size of a semaphore set and the
maximum number of semaphores in the system.
a. In Solaris 10, kernel parameters are replaced by resource controls. ), section
2.6: Configuring Kernel Parameters. See also Oracle Metalink ID 169706.1,
Oracle Database on Unix AIX, HP-UX, Linux, Mac OS X, Solaris, Tru64 Unix
Operating Systems Installation and Configuration Requirements Quick
Reference (8.0.5 to 11.2), which lists Solaris requirements.
b. Oracle recommends the following values, noting that they are guidelines
and should be tuned for production database systems. If you use a custom
configuration, you must change the values of the parameters to the
appropriate level.
Resource Control Recommended Value

project.max-sem-ids 100
process.max-sem-nsems 256
project.max-shm-memory 429496725
project.max-shm-ids 100
c. Log in as the Oracle user (for example, oracle).

d. To find the current kernel parameter settings, check the project id, and then
check the resource control settings for that project id:
$ id -p
uid=4074(oracle) gid=9999(dba) projid=3(default)
$ prctl -n project.max-shm-memory -i project 3
project: 3: default
NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT
project.max-shm-memory
privileged 1.95GB - deny -
system 16.0EB max deny -
$ prctl -n project.max-sem-ids -i project 3
project: 1: user.root
project.max-sem-ids
privileged 128 - deny -
system 16.8M max deny -
$ prctl -n project.max-shm-ids -i project 3
project: 3: default
project.max-shm-ids
$ prctl -n process.max-sem-nsems $$
process: 12134: bash
process.max-sem-nsems
e. To change values, check the Solaris documentation for complete information

on projects. Here is one example, which sets the value of
project.max-shm-memory to 4GB. Log in as root and add a project, attached
to the dba group (assuming the oracle user is part of the dba group), and
set the value:
# projadd -p 100 -G dba -c "Oracle Project" \
-K "project.max-shm-memory=(privileged,4G,deny)" group.dba

f. Check by logging back in as oracle, checking with id -p that the projid is
now the new project number 100, and run prctl again to check that the
max-shm-memory value has been updated.
$ id -p
uid=4074(oracle) gid=9999(dba) projid=100(group.dba)
bash-3.00$ prctl -n project.max-shm-memory -i project 100
project: 100: group.dba
project.max-shm-memory
privileged 4.00GB - deny -
system 16.0EB max deny -
3. Reboot your system before continuing to the next step.
Enable FTP on Linux systems
By default, FTP is not enabled on Linux systems.
About this task
To enable FTP on your Linux host:
Procedure
1. Log in as root:
2. Change to the following directory:
# /etc/init.d
# ./vsftpd start
Disable SELinux (Linux only)

Tivoli Netcool Performance Manager is not installed properly if the SELinux
security policy is set to "enforcing".
About this task
To change the SELinux security policy is set to "enforcing", you must:
Procedure
1. Log in as root.
2. Open the SELinux config file for editing:
$ cat /etc/selinux/config
3. Change the line in the file.
SELINUX=enforcing
To:
SELINUX=disabled
Note: You can also set the SELINUX setting to permissive. Setting SELINUX to
permissive results in a number of warnings at installation time, but it allows
the installation code to run.
4. To effect the changes, reboot the system with the following command:
$ reboot

Set the kernel parameters
Required changes to Linux kernel parameters.
About this task
The following steps have been taken from the Metalink Note 421308, which is
available from the Oracle website.
Procedure
1. Add the following the lines in the file /etc/sysctl.conf
v kernel.shmall = physical RAM size / pagesize For most systems, this will be
the value 2097152.
See Note 301830.1, which is available from the Oracle website, for more
information.
v kernel.shmmax = 1/2 of physical RAM, but not greater than 4GB.
This would be the value 2147483648 for a system with 4Gb of physical RAM.
v kernel.shmmni = 4096
v kernel.sem = 250 32000 100 128
v fs.file-max = 6815744
v net.ipv4.ip_local_port_range =9000 65500
v net.core.rmem_default = 262144
v net.core.rmem_max = 4194304
v net.core.wmem_default = 262144
v net.core.wmem_max = 1048576
v fs.aio-max-nr = 1048576
2. To effect these changes, execute the command:
# sysctl -p
Kernel parameters for DB2 database server installation (Linux)
The configuration or modification of kernel parameters for DB2 database server

installation depends on your operating system.
Kernel parameter requirements (Linux)
The database manager uses a formula to automatically adjust kernel parameter

settings and eliminate the need for manual updates to these settings.
Interprocess communication kernel parameters
When instances are started, if an interprocess communication (IPC)

kernel parameter is below the enforced minimum value, the database manager
updates it to enforced minimum value. The IPC kernel parameter values changed
when a DB2 instance is started do not persist when the system is rebooted. After a
reboot, kernel settings might be lower than the enforced values until a DB2

instance is started. By adjusting any kernel parameter settings, the database
manger prevents unnecessary resource errors. For the information about supported
Linux distributions, see http://www-01.ibm.com/software/data/db2/linux-unix-
windows.
Table 14. Enforced minimum settings for Linux interprocess communication kernel
parameters
IPC kernel parameter Enforced minimum setting
kernel.shmmni (SHMMNI) 256 * <size of RAM in GB>
kernel.shmmax (SHMMAX) <size of RAM in bytes>1
kernel.shmall (SHMALL) 2 * <size of RAM in the default system page
size> 2
kernel.sem (SEMMNI) 256 * <size of RAM in GB>
kernel.sem (SEMMSL) 250
kernel.sem (SEMMNS) 256 000
kernel.sem (SEMOPM) 32
kernel.msgmni (MSGMNI) 1 024 * <size of RAM in GB>
kernel.msgmax (MSGMAX) 65 536
3
kernel.msgmnb (MSGMNB) 65 536
1. On 32-bit Linux operating systems, the enforced minimum setting for SHMMAX is limited
to 4 294 967 295 bytes.
2. SHMALL limits the total amount of virtual shared memory that can be allocated on a
system. Each DB2 data server efficiently manages the amount of system memory it
consumes, also know as committed memory. The DB2 data server allocates more virtual
memory than it commits to support memory preallocation and dynamic memory
management. Memory preallocation benefits performance. Dynamic memory management
is the process of growing and shrinking real memory usage within separate virtual shared
memory areas. To support memory preallocation and dynamic memory management
effectively data servers frequently have to allocate more virtual shared memory on a
system than the amount of physical RAM. The kernel requires this value as a number of
pages.
3. Load performance might benefit from a larger message queue size limit, specified in
bytes by MSGMNB. You can view message queue usage can by running the ipcs -q
command. If the message queues are at capacity, or reaching capacity, during load
operations, consider increasing the number of bytes the message queue size limit.
Other recommended kernel parameter settings
Other recommended kernel parameter settings are listed in the

following table.

Table 15. Configuring other Linux kernel parameters
Configuring the kernel parameters for DB2
Recommended kernel parameter setting data server
vm.swappiness=0 This parameter defines how prone the kernel
is to swapping application memory out of
physical random access memory (RAM). The
default setting is vm.swappiness=60. The
recommended kernel parameter setting,
vm.swappiness=0, configures the kernel to
give preference to keeping application
memory in RAM instead of assigning more
memory for file caching. This setting avoids
unnecessary paging and excessive use of
swap space. This setting is especially
important for data servers configured to use
the self-tuning memory manager (STMM).
vm.overcommit_memory=0 This parameter influences how much virtual
memory the kernel permits allocating. The
default setting, vm.overcommit_memory=0, sets
the kernel to disallow individual processes
from making excessively large allocations,
however the total allocated virtual memory
is unlimited. Having unlimited virtual
memory is important for DB2 data servers,
which retain additional unused virtual
memory allocations for dynamic memory
management. Unreferenced allocated
memory is not backed by RAM or paging
space on Linux systems. Avoid setting
vm.overcommit_memory=2, as this setting
limits the total amount of virtual memory
that can be allocated, which can result in
unexpected errors.
Modifying kernel parameters (Linux):
The database manager uses a formula to automatically adjust kernel parameter

settings and eliminate the need for manual updates to these settings.
Before you begin
You must have root authority to modify kernel parameters.
Procedure
To update kernel parameters on Red Hat and SUSE Linux, follow these steps:
1. Run the ipcs -l command to list the current kernel parameter settings.
2. Analyze the command output to determine whether you have to change kernel
settings or not by comparing the current values with the enforced minimum
settings at http://www-01.ibm.com/support/knowledgecenter/
SSEPGG_10.1.0/com.ibm.db2.luw.qb.server.doc/doc/
c0057140.html?cp=SSEPGG_10.1.0%2F2-0-1-2-2-0-10-1&lang=en. The following
text is an example of the ipcs command output with comments added after //
to show what the parameter names are:

# ipcs -l
------ Shared Memory Limits --------
max number of segments = 4096 // SHMMNI
max seg size (kbytes) = 32768 // SHMMAX
max total shared memory (kbytes) = 8388608 // SHMALL
min seg size (bytes) = 1
------ Semaphore Limits --------
max number of arrays = 1024 // SEMMNI
max semaphores per array = 250 // SEMMSL
max semaphores system wide = 256000 // SEMMNS
max ops per semop call = 32 // SEMOPM
semaphore max value = 32767
------ Messages: Limits --------
max queues system wide = 1024 // MSGMNI
max size of message (bytes) = 65536 // MSGMAX
default max size of queue (bytes) = 65536 // MSGMNB
v Beginning with the first section on Shared Memory Limits, the SHMMAX
limit is the maximum size of a shared memory segment on a Linux system.
The SHMALL limit is the maximum allocation of shared memory pages on a
system.
– It is recommended to set the SHMMAX value to be equal to the amount
of physical memory on your system. However, the minimum required on
x86 systems is 268435456 (256 MB) and for 64-bit systems, it is 1073741824
(1 GB).
– The SHMALL parameter is set to 8 GB by default (8388608 KB = 8 GB). If
you have more physical memory than 8 GB, and it is to be used for DB2,
then this parameter increases to approximately 90% of your computer's
physical memory. For instance, if you have a computer system with 16 GB
of memory to be used primarily for DB2, then SHMALL should be set to
3774873 (90% of 16 GB is 14.4 GB; 14.4 GB is then divided by 4 KB, which
is the base page size). The ipcs output converted SHMALL into kilobytes.
The kernel requires this value as a number of pages. If you are upgrading
to DB2 Version 10.1 and you are not using the default SHMALL setting,
you must increase the SHMALL setting by an additional 4 GB. This
increase in memory is required by the fast communication manager (FCM)
for additional buffers or channels.
v The next section covers the amount of semaphores available to the operating
system. The kernel parameter sem consists of four tokens, SEMMSL,
SEMMNS, SEMOPM and SEMMNI. SEMMNS is the result of SEMMSL
multiplied by SEMMNI. The database manager requires that the number of
arrays (SEMMNI) be increased as necessary. Typically, SEMMNI should be
twice the maximum number of agents expected on the system multiplied by
the number of logical partitions on the database server computer plus the
number of local application connections on the database server computer.
v The third section covers messages on the system.
– The MSGMNI parameter affects the number of agents that can be started; the
MSGMAX parameter affects the size of the message that can be sent in a
queue, and the MSGMNB parameter affects the size of the queue.
– The MSGMAX parameter should be changed to 64 KB (that is, 65536 bytes),
and the MSGMNB parameter should be increased to 65536.
3. Modify the kernel parameters that you have to adjust by editing the
/etc/sysctl.conf file. If this file does not exist, create it. The following lines are
examples of what should be placed into the file:

#Example for a computer with 16GB of RAM:
kernel.shmmni=4096
kernel.shmmax=17179869184
kernel.shmall=8388608
#kernel.sem=<SEMMSL> <SEMMNS> <SEMOPM> <SEMMNI>
kernel.sem=250 1024000 32 4096
kernel.msgmni=16384
kernel.msgmax=65536
kernel.msgmnb=65536
4. Run sysctl with -p parameter to load in sysctl settings from the default file
/etc/sysctl.conf:
sysctl -p
5. Optional: Have the changes persist after every reboot:
v (SUSE Linux) Make boot.sysctl active.
v (Red Hat) The rc.sysinit initialization script reads the /etc/sysctl.conf file
automatically.
IBM DB2 10.1 for Linux, UNIX, and Windows documentation on IBM
Knowledge Center
Replace the native taring utility with gnu tar

Replace the native taring utility with GNU tar.
Before you begin
Check the version of tar command you have at present by entering the following
command:
#tar --version
For a GNU tar utility the output would conform to the following:
tar (GNU tar) 1.14
Copyright (C) 2004 Free Software Foundation, Inc.
This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute it under the terms of the GNU General Public License;
see the file named COPYING for details.
Written by John Gilmore and Jay Fenlason.
If the resulting output does not indicate a GNU tar utility then perform the
following steps.
Procedure
1. Find the native tar location.
#which tar
/usr/bin/tar
2. Move the native binary tar command:
#cd /usr/bin
#mv tar tar_
3. Install the GNU tar, which can be obtained from the toolbox site:
For example, refer the following toolbox site for AIX http://www-03.ibm.com/
systems/power/software/aix/linux/toolbox/download.html
Set the install location to be something similar to /opt/freeware/bin/tar
4. Create a gnu tar soft link:

ln -s /opt/freeware/bin/tar /usr/bin/tar
5. Validate that the tar command is gnu tar:
#tar --version
Resulting output should be as stated in prerequisite step.
Installing libcrypto.so
For starting up DataLoad process correctly upon installation and for full SNMPv3
support, SNMP DataLoad must have access to the libcrypto.so.
About this task
Note: If you are running on a Linux platform, please start with step
3 onwards. The libcrypto.so file is delivered as standard on Linux platforms,
hence step 1 and 2 are not required.
For each new and existing SNMP DataLoad, you must perform the following steps.
Procedure
1. Install the OpenSSL package. This package can be downloaded from
http://www.openssl.org/.
2. As root, extract and install the libcrypto.so file by using the following code:
# cd /usr/lib
# ar -xv ./libcrypto.a
# ln -s libcrypto.so.0.9.8 libcrypto.so
3. Remove the existing link for libcrypto.so if any by using the following code:
# cd /usr/lib
# rm -rf libcrypto.so
4. Create a link for libcrypto.so which links to libcrypto.so.0.9.8e using the
following code:
# cd /usr/lib
# ln -s libcrypto.so.0.9.8e libcrypto.so
5. Update the dataload.env file so that the LD_LIBRARY_PATH (on Solaris & Linux)
or LIBPATH (on AIX) environment variables include the path:
/usr/lib
What to do next
Check the variable is set by doing the following steps:
1. Open a fresh shell.
2. Verify that the environment variables are set correctly in dataload.env file.
3. Source the dataload.env file.
4. Bounce the SNMP DataLoad process.
Upon DataLoad process startup with a valid library, the collector logs the
following log messages:
INFO:CRYPTOLIB_LOADED Library ’libcrypto.so’ (OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008, 0x90802f)
has been loaded.
INFO:SNMPV3_SUPPORT_OK Full SNMPv3 support Auth(None,MD5,SHA-1) x Priv(None,DES,AES) is available.

Deployer pre-requisites
Minimum filesystem specification and pre-requisites for the Deployer script.
The Deployer will check the for the items described under the following headings.
You should ensure that all elements are installed before running the deployer.
Operating system check

The Deployer will fail if the required patches listed in this file are not installed.
The Deployer performs a check on the operating system versions and that the
minimum required packages are installed.
For more information on the complete set of requirements for installation on Linux,
AIX and Solaris, consult the Requirements chapter.
Mount points check

The Deployer assesses the available filesystem space for the defined mount point
locations.
The space requirements are calculated based on:

v The defined topology: The more components added to a single server the more
space is required on that server.
v The component install location: Any directory set as the install location for a
component requires sufficient space to store that component. The default install
directory is /opt. You do not have to use the default. This can be set to any
directory location that has sufficient space.
v Remote installation of components: If components are being installed remotely,
sufficient space must be assigned in the /tmp directory to store the software
before it can be transferred to the remote servers.
For a statement of minimum space requirements per server in a distributed install

or for a single server in a proof of concept install, consult the Configuration
Recommendations documentation.
Authentication between distributed servers

Why you must authenticate between distributed servers.
If you are performing an installation that has a topology covering a set of

distributed servers, ensure that RSA keys have been cached between servers for
root and pvuser prior to installation. If there are new servers that form part of
installation topology which have not been authenticated, the installation will fail.
Note: pvuser is the required Tivoli Netcool Performance Manager Unix user.
Adding this user to your system is described in “Adding the pvuser login name”
on page 74.

Tivoli Netcool Performance Manager distribution
How to get the product distribution.
The Tivoli Netcool Performance Manager distribution is available as an electronic

image. These instructions assume that you are installing from an electronic image.
If you install the product from an electronic image, be sure to keep a copy of the
distribution image in a well-known directory because you will need this image in
the future to make changes to the environment, including uninstalling Tivoli
Netcool Performance Manager.
The Tivoli Netcool Performance Manager distribution contains the software

required to install Tivoli Netcool Performance Manager 1.4.2.
Downloading the Tivoli Netcool Performance Manager

distribution to disk
To download the Tivoli Netcool Performance Manager distribution to a directory
on a target server's hard disk:
About this task
Whether you are installing the product from an electronic image, you must copy
the distribution to a writeable location on the local filesystem before beginning the
installation.
To download the Tivoli Netcool Performance Manager distribution to a directory

on the host from which you intend to run the Topology Editor:
Procedure
1. On the target host, log in as the Tivoli Netcool Performance Manager user, such
as pvuser.
2. Create a directory to hold the contents of your Tivoli Netcool Performance
Manager distribution. For example:
$ mkdir /var/tmp/cdproviso
Note: Any further references to this directory within the install are made by
using the token <DIST_DIR>.
You can run a variety of scripts and programs from directories residing in the
directory created on the hard drive, including:
v Oracle server configuration script
v Pre-installation script
v Installation script
v Tivoli Netcool Performance Manager setup program
3. Download the Tivoli Netcool Performance Manager distribution to the host
directory created in the previous step and expand the contents of the
distribution package.

General database setup tasks
How to install a database for use with Tivoli Netcool Performance Manager.
To install database you need:

v An appropriately sized server with the operating system installed and running
(for the database server).
Note: For a basic overview of the minimum CPU speed, memory size, and disk
configuration requirements for your Tivoli Netcool Performance Manager
installation, see the Requirements. For more detailed information you can
contact IBM Professional Services.
v The current version of Tivoli Netcool Performance Manager software.
v The downloaded files for the database installation.
v If you are installing database on an AIX system, follow the instructions in
“Asynchronous I/O Support” before installing database.
Before installing database, read the setup and password information.
Note: Tivoli Netcool Performance Manager should be installed and run as a

standalone database. It should not be placed on a server that already has a
database as the installation program will likely interfere. The co-hosting of Tivoli
Netcool Performance Manager also affects performance in unknown ways. If a
co-host is required then the you must contact IBM Professional Services for
support.
Asynchronous I/O Support
Before installing Oracle on AIX 5.3 systems, you must set up asynchronous I/O
(AIO), or the installation might fail.
About this task
Note: Asynchronous I/O (AIO) is not required for AIX 6.1 or later.
To set up asynchronous I/O:

v Log in as root.
v Enter the following command to check the current status of AIO support:
# lsdev -Cc aio
The status should be Available.

v If the status shown is Defined, change the STATE to be configured at system
restart option to Available by entering the following command:
# smit chaio
v Reboot the system.
v Re-enter the following command to check the current status of AIO support:
# lsdev -Cc aio
Verify that the status is set to Available.

v Continue with “Running the Oracle server configuration script” on page 112.
Specifying a basename for DB_USER_ROOT

and
Tivoli Netcool Performance Manager components use distinct login names so that
database access can be controlled separately by component, and for database
troubleshooting clarity.
About this task
The Tivoli Netcool Performance Manager installation generates the appropriate

login names for each Tivoli Netcool Performance Manager subsystem.
Procedure
Provide a basename, which the installation retains as the variable
DB_USER_ROOT.
Note: This is not an operating system environment variable, but a variable used
internally by the installer.
The default DB_USER_ROOT value is PV. IBM recommends you to retain the default
value.
Important: Avoid changing default values of DB_USER_ROOT (PV) and

DB_ROOT_NAME (pv).
Restriction: DB_USER_PASSWD is restricted to alpha numeric characters only.

Ensure that DB_USER_PASSWD does not contain any spaces or special characters,
otherwise Proviso Database installation will fail.
Results
Login names are generated from the DB_USER_ROOT basename by appending a

function or subsystem identifier to the basename, as in the following examples:
v PV_ADMIN
v PV_INSTALL
v PV_LDR
v PV_CHANNEL
v PV_COLL
v PV_CHNL_MANAGER
v PV_GUI
In addition, separate login names are generated for each Tivoli Netcool
Performance Manager DataChannel and subsystem, identified by an appended
channel number, as in the following examples:
v PV_CHANNEL_01
v PV_CHANNEL_02
v PV_LDR_01
v PV_LDR_02

Specifying login passwords
and
For each component that requires a database login name, you must provide a
password for that login name.
About this task

In every case, the installer uses the default password, PV.
Passwords are case-sensitive, so PV and pv is not the same password.
Procedure
You can retain the default password, or enter passwords of your own according to
your site password standards.
You should use the same password for all Tivoli Netcool Performance Manager
subsystem login names. If you use different passwords for each login name, keep a
record of the passwords you assign to each login name.
Important: Avoid using any special characters in any password field, (for
example, @, \, /) while installing Tivoli Netcool Performance Manager with DB2.
Results
The Tivoli Netcool Performance Manager installer uses PV for three default values,
as described in Table 5.
Table 5: Uses of PV as Default Values
Installer Default Value Used As Recommendation

PV Default value of the In all instances, use the
DB_USER_ROOT variable, the default value PV, unless your
basename on which login site has an explicit naming
names are generated standard or an explicit
password policy.
PV Default password for all
login names
PV Default database name, also
called the TNS name for
Oracle.
What to do next
Note: If you use a non-default value, you must remember to use the same value in
all installation stages. For example, in Oracle, if you set your TNS name to PROV
instead of PV, you must override the default PV entry in all subsequent steps that
call for the TNS name.

Assumed values
The steps in this information assume the following default values:
Setting Assumed Value

delphi
Hostname of the and
server
Server program files installed in
v -/opt/oracle
v -/opt/db2
v /opt/oracle
v _BASE
v /opt/db2
Note: DB2_BASE directory should be
v _BASE
same as home directory of DB2 instance
user.
Important: If you are using non-default
path for DB2 installation directory, you
must modify the DB2_BASE parameter in
Topology Editor also.
Operating system login name for: v oracle
v db2
v user
Note: The default name created is oracle
v user and db2 for Oracle and IBM DB2 databases
respectively. However, you can set another
name for the DB2 or Oracle user.
Password for: v oracle
v db2
v user
Important: Avoid using any special
characters in any password field, (for
v user
example, @, \, /) while installing Tivoli
Netcool Performance Manager with DB2.
PV
v _NAME
v _NAME
TNS name for Tivoli Netcool Performance PV
Manager database instance
v /opt/oracle/product/ 12.1.0
v installed in
v /opt/db2/product/10.1.0
ORACLE_HOME
Note: The value of ORACLE_HOME or
v installed in DATABASE_HOME cannot contain soft links
DATABASE_HOME to other directories or file systems. Be sure
to specify the entire absolute path to Oracle
or DB2.Tivoli Netcool Performance Manager
expects an Optimal Flexible Architecture
(OFA) structure where DATABASE_HOME
or ORACLE_HOME is a sub-directory to
DB2_BASE or ORACLE_BASE.
Important: If you are using non-default
path for DB2 installation directory, you must
modify DB2_BASE parameter in Topology
Editor also.

Setting Assumed Value
system
Oracle login name for database

administrator (DBA)
manager
Password for Oracle DBA login name

PV
DB_USER_ROOT
v /raid_2/oradata
Path for Oracle data, mount point 1 v /raid_2/db2data
Path for DB2 data, mount point 1
v /raid_3/oradata
Path for Oracle data, mount point 2 v /raid_3/db2data
Path for DB2 data, mount point 2
Note: If your site has established naming or password conventions, you can
substitute site-specific values for these settings. However, IBM strongly
recommends using the default values the first time you install Tivoli Netcool
Performance Manager. See “Specifying a basename for DB_USER_ROOT” on page
89 for more information.
Creating group and user ID for a DB2 server installation
You can use the DB2 Setup wizard to create the users and groups during the
installation process. If you want, you can create them ahead of time.
Before you begin
To perform this task, you must have root user authority to create users and
groups.
About this task
Two users and groups are required.
The user and group names that are used in the following instructions are
documented in the following table. You can specify your own user and group
names if they adhere to system naming rules and DB2 naming rules.
The user IDs you create are required to complete subsequent setup tasks.

Table 16. Default users and groups
User Description Example user name Example group name
Instance owner The DB2 instance is db2 db2iadm
created in the
instance owner home
directory. This user
ID controls all DB2
processes and owns
all file systems and
devices that are used
by the databases that
are contained within
the instance. The
default user is db2
and the default
group is db2iadm.
Fenced user The fenced user is db2fenc db2fadm
used to run
user-defined
functions (UDFs) and
stored procedures
outside of the
address space that is
used by the DB2
database. The default
user is db2fenc and
the default group is
db2fadm. If you do
not need this level of
security, for example
in a test
environment, you can
use your instance
owner as your fenced
user.
User ID restrictions
User IDs have the following restrictions and requirements:

v Must have a primary group other than guests, admins, users, and local.
v Can include lowercase letters (a-z), numbers (0-9), and the underscore character
(_).
v Cannot be longer than eight characters
v Cannot begin with IBM, SYS, SQL, or a number.
v Cannot be a DB2 reserved word (USERS, ADMINS, GUESTS, PUBLIC, or
LOCAL), or an SQL reserved word.
v Cannot use any user IDs with root privilege for the DB2 instance ID, DAS ID, or
fenced ID.
v Cannot include accented characters.
Procedure
To create the required groups and user IDs for DB2 database systems, follow these
steps:
1. Log in as root user.
2. To create groups on Linux operating systems, enter the following commands:
Note: These command line examples do not contain passwords. You can use
the passwd username command from the command line to set the password.
groupadd db2iadm
groupadd db2fadm
3. Create users for each group by using the following commands:
useradd -g db2iadm -m -d /opt/db2 db2
useradd -g db2fadm -m -d /home/db2fenc db2fenc
4. Set initial password by using the following commands:
passwd db2
Changing password for user db2.
New UNIX password: db2
BAD PASSWORD: it is WAY too short
Retype new UNIX password: db2
passwd: all authentication tokens updated successfully.
passwd db2fenc
Changing password for user db2fenc.
New UNIX password: db2fenc
BAD PASSWORD: it is based on a dictionary
Retype new UNIX password: db2fenc
5. Relax the permission on home directory of db2 user as you want to install DB2
inside it by using the following command:
chmod 707 /opt/db2
Creating group and user IDs for Data Server Client installation
One user and one group are required.
About this task

You require only the Instance owner. For more information about the Instance
owner and user ID restrictions, see “Creating group and user ID for a DB2 server
installation” on page 92.
Procedure
To create the required groups and user IDs for Data Server Client installation,
follow these steps:
1. Log in as a user with root user authority.
2. To create groups on Linux operating systems, enter the following commands:
Note: These command line examples do not contain passwords. They are
examples only. You can use the passwd username command from the
command line to set the password.
groupadd db2iadm
3. Create users for each group by using the following commands:
useradd -g db2iadm -m -d /opt/db2 db2
4. Set initial password by using the following commands:
passwd db2
Changing password for user db2.
New UNIX password: db2

BAD PASSWORD: it is WAY too short
Retype new UNIX password: db2
5. Relax the permission on home directory of db2 user as we want to install the
Data Server Client inside it by using the following command:
chmod 707 /opt/db2

Chapter 4. Installing Jazz for Service Management
You can use either a launchpad or IBM Installation Manager to install and
configure Jazz for Service Management. You can install and configure one or more
integration services on one or more servers. You can optionally install IBM DB2
and IBM WebSphere® Application Server. The installation configures Jazz for
Service Management for basic authentication and SSL communications by default.
About this task

To plan the Jazz for Service Management installation, you must choose your
installation scenario. This choice depends on different factors, for example, number
of integration services to install, by using existing database and application server
middleware, installation mode, server topologies, or user type.
These factors determine your installation scenario that you use to install Jazz for
Service Management. You can also use the decision maps. See Installation decision
maps.
Important:
v Do not install Jazz for Service Management 1.1.2.1 on a Solaris machine in a
distributed or a stand-alone environment.
v For minimal installation of Tivoli Netcool Performance Manager, use only
smadmin as the administration user name and smadmin1 as the administration
password for Jazz for Service Management. The default administration user
name is smadmin.
v To start or stop the server, you must log in with the same user that you used to
install Jazz for Service Management. If Jazz for Service Management is installed
with non-root user, never restart Jazz for Service Management application
servers with root user, or else the Dashboard Application Services Hub becomes
unusable.
Installing Jazz for Service Management
Common directory locations
Hardware and software requirements for installing Jazz for Service

Management
Jazz for Service Management and its integration services have hardware and
software requirements, including supported middleware and installation
technologies.
Important: Jazz for Service Management installation is not supported on Solaris

platform.
Important: You must add the following list of Linux libraries, which are
prerequisite when you install Jazz for Service Management. If you do not include
these libraries, it can cause failure of prerequisite scanner or the installation of Jazz
for Service Management.

os.lib.libSM.so.6_32
os.lib.libICE.so.6_32
os.lib.libfreetype.so.6_32
os.lib.libuuid.so.1_32
os.lib.libfontconfig.so.1_32
os.lib.libjpeg.so.62_32
os.lib.libpng12.so.0_32
os.lib.libz.so.1_32
os.lib.libstdc.so.5_32
os.lib.libstdc.so.6_32
Jazz for Service Management Detailed System Requirements
Getting started with Jazz for Service Management

Consult these summaries of tasks for installation, configuration, and other user
tasks to meet your goals.
Procedure
1. Planning and installing Jazz for Service Management
Task Description
Plan your installation You can perform a full or custom installation
of Jazz for Service Management based on
the integration services to install, business
and security policies, your target
environments, and user types.
See Planning your deployment.

Prepare your environment Prepare your environment whether you
perform a full or custom installation. Some
tasks are common to both installation
scenarios, while some tasks are exclusive to
a single installation scenario or integration
service.
See Preparing your environment.

Perform a full installation Use this installation scenario to install and
configure IBM® DB2®, IBM WebSphere®
Application Server, and Jazz for Service
Management on a single server.
Full installation scenario silently installs

DB2, WebSphere Application Server,
Installation Manager, and the following
integration services: Administration Services,
Dashboard Application Services Hub,
Registry Services, Reporting Services, and
Security Services. The launchpad can run
Prerequisite Scanner to scan for full
installation prerequisites.
See Full installations.

Task Description
Perform a custom installation Use this installation scenario to install and
configure one or more integration services
on different servers.
You can choose to install WebSphere

Application Server and Installation Manager,
if you do have existing installations of these
products. You can use Installation Manager
to interactively install and configure the
following integration services:
Administration Services, Dashboard
Application Services Hub, Registry Services,
and Security Services on one, two, or three
servers.
See Custom installations by using

Installation Manager.
See Custom installations by using silent

mode.
Install Tivoli Common Reporting Install Tivoli Common Reporting, its content
store, and its optional components. To install
into an application serving environment
with Dashboard Application Services Hub,
ensure that Dashboard Application Services
Hub is already installed.
Note: You can choose to install Tivoli
Common Reporting during the full
installation flow.
See Installing Reporting Services.

Perform postinstallation tasks Verify the installation and perform optional
Tivoli Common Reporting tasks.
See Post-installation tasks.
2. Configuring Jazz for Service Management
Chapter 4. Installing Jazz for Service Management 99

Task Description
Cross-service You can configure a central user registry,
such as a Lightweight Directory Access
Protocol (LDAP) registry, for Jazz for Service
Management user management and
authentication.
Configure WebSphere Application Server to

use a central federated repository with an
LDAP user registry. After configuration, you
can add users to the federated repository.
You can configure the integration services

for single sign-on, so that users can access
Jazz for Service Management applications by
logging in only once.
During installation, the global security

configuration is enabled that applies to the
security policy for all administrative
functions in each Jazz for Service
Management application server. The
configuration is also used as a default
security policy for user applications.
See Configuring Jazz for Service

Management.
Dashboard Application Services Hub For installations of Dashboard Application
Services Hub with large user populations,
you can set up a load balancing cluster of
console nodes with identical configurations
to evenly distribute user sessions.
You can choose to configure Dashboard

Application Services Hub to use Tivoli
Access Manager WebSEAL Version to
manage authentication.
You can also configure the Context Menu

Service (CMS) to use a remote database,
which can be used by products to share
information outside of the Dashboard
Application Services Hub environment.
See Configuring Dashboard Application

Services Hub.
Security Services Security Services is configured during
installation except for single sign-on with
LDAP, which is done by configuring Jazz for
Service Management for SSO. You can
update the configuration, for example,
applying new versions of tokens.
See Configuring Security Services.

Task Description
Tivoli Common Reporting After you install Tivoli Common Reporting,
prepare your report packages to be able to
generate, publish, and edit your reports.
You can configure database connection

details to a data source other than DB2.
See Configuring Tivoli Common Reporting.
Getting started with Jazz for Service Management
Preparing your environment for a full installation of Jazz for

Service Management
Perform these tasks to ensure that your environment is ready for the full
installation of Jazz for Service Management, such as checking prerequisites.
Before you begin
Before you install Jazz for Service Management, refer to the technical notes for Jazz
for Service Management. The technical notes provide information about
late-breaking issues, limitations, and workarounds.
v Technotes documenting issues in Jazz for Service Management Version 1.1.2.1
Note: Some antivirus software can interfere with the Jazz for Service Management
installation process. Before you install Jazz for Service Management, ensure that
you disable the antivirus software and restart the target machine.
About this task
If your target system does not have a browser that is installed to support
installation by using the launchpad, use the Installation Manager GUI.
Procedure
1. Ensure that your target environment meets the hardware and software
requirements for Jazz for Service Management and its integration services.
See Hardware and software requirements.
2. Set up a local file system.
See Setting up a local file system for a full installation.
3. If you want to use an alternative temporary directory for installing the
integrations services, see Specifying an alternative temporary directory for
installation.
4. If you do not intend to install Jazz for Service Management to the default
installation directory or use the default temporary directory, you must modify
the Prerequisite Scanner configuration files to check whether these non-default
directories have the available disk space. See Editing default configuration files
for non-default installation locations.
5. Perform the full installation.
See “Performing a fresh installation” on page 106.

Jazz for Service Management on IBM Knowledge Center
IBM DB2 on IBM Knowledge Center
IBM Installation Manager on IBM Knowledge Center
IBM Prerequisite Scanner on IBM Knowledge Center
IBM WebSphere Application Server on IBM Knowledge Center
Preparing your environment for a custom installation

Perform these tasks to ensure that your environment is ready for the custom
installation of Jazz for Service Management, such as checking prerequisites.
Before you begin

Before you install Jazz for Service Management, refer to the technical notes for Jazz
for Service Management. The technical notes provide information about
late-breaking issues, limitations, and workarounds.
Note: Some antivirus software can interfere with the Jazz for Service Management
installation process. Before you install Jazz for Service Management, ensure that
you disable the antivirus software and restart the target machine.
About this task
If your target system does not have a browser that is installed to support
installation by using the launchpad, use the Installation Manager GUI.
Procedure
1. Choose your preferred topology.
See Custom installation scenario.
2. Ensure that your target environment meets the hardware and software
requirements for Jazz for Service Management and its integration services.
See Hardware and software requirements.
3. Set up a local file system.
See Setting up a local file system for a custom installation.
4. If you want to use an alternative temporary directory for installing the
integrations services, see Specifying an alternative temporary directory for
installation.
5. If you do not want to install Jazz for Service Management and its supporting
middleware to the default installation locations, you must modify the
Prerequisite Scanner configuration files to check whether these non-default
locations have the available disk space.
See Editing default configuration files for non-default installation locations.
6. On each target Jazz for Service Management server, run Prerequisite Scanner to
scan and verify that your target environment meets the hardware and software
requirements for Jazz for Service Management.
See Running Prerequisite Scanner by using convenience scripts.

7. Set up DB2 on the target database server. It is needed by Registry Services or
Tivoli Common Reporting only.
v If you want to install Jazz for Service Management as a root user, see Setting
up DB2 as a root user.
v If you want to install Jazz for Service Management as a non-root user, see
Setting up DB2 as a non-root user.
Custom installations by using launchpad custom workflow
Custom installations by using Installation Manager
Custom installations by using silent mode
Location of Jazz for Service Management software

Describes the location of the Jazz for Service Management 1.1.2.1 software.
1.1.2-TIV-JazzSM-multi-FP001.zip - 64 bit, multiplatform software package

repository contains the following Jazz for Service Management integration services
and components:
v Administration Services Version 1.1.2.1
v Administration Services UI Version 1.1.2.1
v IBM Dashboard Application Services Hub 3.1.2.1
v Jazz for Service Management extension for IBM WebSphere Version 1.1.2.1
v Registry Services 1.1.2.1
v Security Services 1.1.2.1
v IBM Tivoli Common Reporting 3.1.2.1
Note: Jazz for Service Management Version 1.1.2.1 is a full refresh of Jazz for
Service Management Version 1.1 Base with Modification 2, Fix Pack 1.
You can download Jazz for Service Management, Version 1.1.2.1 from IBM Fix
Central.
Jazz for Service Management Version 1.1.2.1 Readme
Download Jazz for Service Management Version 1.1.2.1
Overview of Jazz for Service Management installation

Jazz for Service Management, Version 1.1.2.1 can be installed or updated, when
you install it along with earlier Jazz for Service Management versions, for example,
1.1.1.0.
Before you begin
Attention: Ensure that the package that you have downloaded is the latest
refresh of Jazz for Service Management, Version 1.1.2.1.
1. Check that your environment meets the current requirements by running IBM
Prerequisite Scanner. Specify the update parameter when you run the relevant
Prerequisite Scanner convenience script.
See Running Prerequisite Scanner by running the convenience scripts
See Running Prerequisite Scanner manually
2. Before you update Jazz for Service Management, see the late-breaking issues,
limitations, and workarounds from here:
http://www.ibm.com/support/search.wss?q=jazzsm1121relnotes
3. Update your existing Installation Manager to Version 1.8.1 or later, before you
update Jazz for Service Management.
4. Tivoli Common Reporting 3.1.2.1 supports rolling back and upgrading, but if a
rollback fails in its early stages, then you need to manually roll it back.
See Restoring Cognos if Tivoli Common Reporting update fails on multiple
platforms.
Back up your jazzSM_Home/reporting/cognos directory before you begin the
update.
About this task

Typically, there are two scenarios for installing Jazz for Service Management:
v Upgrade installation, if you have an earlier version of Jazz for Service
Management on your system.
See “Performing an upgrade installation.”
v Fresh installation.
See “Performing a fresh installation” on page 106.
Performing an upgrade installation

Use this installation procedure if you already have an earlier version of Jazz for
Service Management on your system. For example, 1.1.1.0.
Before you begin
Download platform-specific IBM Cognos Business Intelligence Reporting for Tivoli

Common Reporting Version 3.1.2.1 (3.1.2.1-TIV-JazzSM-TCR-COGNOS-
platform.tar.gz or the .zip) from Passport Advantage.
Note: You must update the installed integration services in the same application
server profile to the same fix pack level.
About this task

Use IBM Installation Manager in GUI or silent modes to first update the Jazz for
Service Management extension for IBM WebSphere. Then install Jazz for Service
Management Version 1.1.2.1 for the following installed integration services:
v IBM Dashboard Application Services Hub
v Registry Services
v Security Services
v Tivoli Common Reporting
You must update the installed integration services in the same application server
profile to the same fix pack level.

Procedure
1. Download and extract 1.1.2-TIV-JazzSM-multi-FP001.zip file to a local
directory from Fix Central page.
For example, <JazzSM_FP_Home>
2. On each machine that has an Jazz for Service Management application server,
update the Jazz for Service Management extension for IBM WebSphere.
Updating the WebSphere security extension by using Installation Manager
GUI mode
Updating the WebSphere security extension by using Installation Manager
silent mode
3. In a command window, open the /opt/IBM/InstallationManager/eclipse/
IBM/InstallationManager/eclipse directory and run the following command:
./IBMIM
4. Set up the fix pack repository preference.
a. Select File > Preferences.
b. In the Preferences > Repositories pane, click Add Repository.
c. Click Browse and browse to the following location of the file:
<JazzSM_FP_Home>/1.1.2-TIV-JazzSM-multi-FP001/JazzSMFPRepository/
disk1/diskTag.inf
d. Click Apply.
e. Click OK.
f. Click OK to close the Repositories pane.
5. On the Installation Manager home page, click Update. The Update Packages
window opens.
6. Select the Jazz for Service Management software package group in which the
integration services are installed, and then click Next.
7. Select each check box that is associated with each installed component that
you want to update, and click Next.
The Licenses pane opens.
8. Review the license agreement for the software packages, and accept the terms,
and click Next.
The Features pane opens.
9. Select the features that you want to update, and click Next.
10. In the Common Configurations tab, enter password for smadmin user.
11. Click Validate.
12. After the validation completes successfully, click Next.
13. Continue with the installation and specify the configuration details for the
integration service that you want to update.
For more information, see Integration services installation overview.
14. In the Summary pane, review the software packages that you want to install
and click Update. After Installation Manager updates the fix pack, it displays
a message.
15. Click Finish.
What to do next
v Apply the 1.1.2.1-TIV-JazzSM-DASH-Cumulative-Patch-0005 interim fix of Jazz

v Verify the installation of the integration services.
Applying fix pack by using Installation Manager GUI mode
Applying fix pack by using Installation Manager silent mode
Jazz for Service Management Version 1.1.2.1 Readme
Restarting Jazz for Service Management application servers
Download Cumulative Patches - UI Services (DASH)
Performing a fresh installation

20 GB of free disk space is required for a fresh installation.
Procedure
1. Download and extract 1.1.2-TIV-JazzSM-multi-FP001.zip file to a different
local directory from Fix Central.
For example, <JazzSM_FP_Home>
Note: 6 GB of free disk space is needed for a fresh installation.

2. Add the <JazzSM_FP_Home>/1.1.2-TIV-JazzSM-multi-FP001/
JazzSMFPRepository/disk1/diskTag.inf file along with the repository
locations for any other earlier Jazz for Service Management versions to
Installation Manager > File > Preferences > Add Repository.
3. Start the launchpad by using the following command:
<<JazzSM_FP_Home>>/launchpad.sh
Restriction: Ensure that the path to the <JazzSM_FP_Home> directory does not
contain any spaces or special characters, otherwise the launchpad does not
start.
Important:
v It is recommended that you have only one instance of the launchpad open
at a time.
v If DB2, Tivoli Common Reporting, or WebSphere Application Server
repository is available on a shared network drive, ensure that you run the
launchpad from the local file system to access the repository on the shared
drive, and install Jazz for Service Management.
4. Click Full.
The Full Installation window opens.
5. Review the instructions in the Full Installation window, and click Next. The
Full Installation > Software License Agreement window opens.
Important: If your environment already contains DB2, WebSphere Application

Server, or any of the Jazz for Service Management services that are installed,
you cannot proceed with Full Installation. To proceed with Full Installation,
you must uninstall them or you must use Custom workflow instead.
6. Review the license agreements and accept the terms, and click Next.
The Installation Images Location window opens.

7. Click Scan to run Prerequisite Scanner and scan your environment for the Jazz
for Service Management requirements.
The launchpad runs the convenience script for a full installation and displays
the overall result in the Prerequisite Scan window. To view the details, click
Detailed Scan Results. The results can be as follows:
Fail
If the target environment does not meet any of the prerequisite checks,
Prerequisite Scanner returns an overall FAIL result for the
environment. The tool displays the scan results for the individual
prerequisite properties in the command window.
If Prerequisite Scanner returns this result, take the appropriate actions;
for example, install the missing operating system packages, increase
disk space for the file systems, or modify the configuration settings of
the target environment to match the expected values in the scan
results.
CAUTION:
You can continue with the full installation without taking
appropriate action, but it might fail or install with issues.
Pass
If the target environment meets all prerequisite checks, Prerequisite
Scanner returns an overall PASS result for the environment.
If Prerequisite Scanner returns this result, you can install Jazz for
Service Management.
8. Click Next.
The Basic Settings window opens.
9. Verify, use, or enter the default values as needed:
Option Description
User name The administration user ID for the database,
application servers, and Jazz for Service
Management integration services. The
default value is smadmin.
Restriction: On Linux systems only: The
length of the user ID must be a maximum of
8 characters; otherwise, the installation
program cannot create the DB2 instance.
Password and Confirm password The password that is associated with any
users created by the full installation. The
password must have a minimum of 8
alphanumeric characters and must not
contain special characters or space.
Local host name The fully qualified name or IP address of the
local server on which you install the
software. The default value is the fully
qualified host name that the launchpad
retrieves from the local server. If it is not a
valid value, you can change the value.

Option Description
WebSphere Home The installation location for IBM WebSphere
Application Server (WAS_HOME). The
default location if not specified is
/opt/IBM/WebSphere/AppServer on Linux
and AIX systems.
DB2 Home The installation location for IBM DB2
(DB2_HOME). The default location if not
specified is /opt/ibm/db2 on Linux and AIX
systems.
Important: If you are installing Tivoli

Netcool Performance Manager with DB2
database, make sure that you set the DB2
HOME directory to /opt/db2/product/
10.5.0 during Jazz for Service Management
installation.
Jazz for Service Management Home The installation location for Jazz for Service
Management (JazzSM_HOME). The default
location if not specified is /opt/IBM/JazzSM
on Linux and AIX systems.
10. Click Next.

The Installation Summary window opens.
11. Click Install.
After the installation is complete, the launchpad displays the overall result of
the installation in the Installation Results window.
Results
The generic and offering specific log files that are generated during the full
installation are saved in the following locations:
On UNIX systems: $HOME/jazzsm_launchpad/logs/.
What to do next
v Apply the 1.1.2.1-TIV-JazzSM-DASH-Cumulative-Patch-0005 interim fix of Jazz
v Verify the installation of the integration services.
Related tasks:
“Performing an upgrade installation” on page 104
Use this installation procedure if you already have an earlier version of Jazz for
Service Management on your system. For example, 1.1.1.0.
Installing Reporting Services
Verifying the installation
Verifying the Reporting Services installation
Restarting Jazz for Service Management application servers
Download Cumulative Patches - UI Services (DASH)

Uninstalling Jazz for Service Management
You can uninstall most integration services and the application server by using
Installation Manager GUI mode or silent mode. You might need to clean up your
environment after either a successful uninstallation or a failed installation.
About this task

Attention: You cannot roll back Tivoli Common Reporting Version 3.1.2.1 as it
supports only fresh installation. You can perform a full uninstallation of Tivoli
Common Reporting.
Procedure
Use IBM Installation Manager in GUI or silent modes to uninstall Jazz for Service
Management Version 1.1.2.1.
See Uninstalling fix packs by using Installation Manager GUI mode.
See Uninstalling fix packs by using Installation Manager silent mode.
Important: When you revert to the previous version of Jazz for Service
Management, Installation Manager does not automatically account for interim
fixes. You must manually install interim fixes after you roll back.
Uninstalling fix packs
Uninstalling Jazz for Service Management and related software
Upgrading Java
Ensure that you configure the IBM WebSphere Application Server to run with Java
7 after successfully installing Jazz for Service Management 1.1.2.1
About this task
Important: The IBM WebSphere Application Server must be running with Java 7
before you proceed to upgrade Tivoli Netcool Performance Manager DataView
component.
To upgrade to Java 7, follow these steps:
Procedure
1. On the relevant Jazz for Service Management server, open a command window.
2. Run the following command to configure IBMWebSphere Application Server to
run with Java 7:
/opt/IBM/WebSphere/AppServer/bin/managesdk.sh -enableProfile -profileName
JazzSMProfile -sdkname 1.7_64 -enableServers
The output is as follows:

CWSDK1017I: Profile JazzSMProfile now enabled to use SDK 1.7_64.
CWSDK1001I: Successfully performed the requested managesdk task.

What to do next
You must restart Jazz for Service Management 1.1.2.1 application server after you
complete the Java upgrade step.
Starting Jazz for Service Management application servers
Stopping Jazz for Service Management application servers

Chapter 5. Installing database
Instructions on how to install the Oracle and DB2 database for Tivoli Netcool
The following topics mention in detail about:

v “Installing Oracle 12.1.0.2 server (64-bit)”
v “Installing Oracle 12.1.0.2 client 32-bit” on page 126
v “Installing DB2 Server 10.1.0.5 (64-bit)” on page 139
v “Installing IBM Data Server Client 10.1.0.5 (64-bit)” on page 143
Note: You need to regularly purge the metric data either by manually purging or
by using cron job. For more information, see Purging metric data topic under
Administering Database guide.
Installing Oracle 12.1.0.2 server (64-bit)
Instructions on how to install the Oracle 12.1.0.2 server (64-bit).
To install Oracle 12.1.0.2 server (64-bit), you can use the scripts provided as part of
Tivoli Netcool Performance Manager.
Download the Oracle distribution to disk

The Oracle installation files must be in place before you can begin the installation
of Oracle.
About this task
Note: Oracle 12.1.0.2 client (32-bit) must be installed into a new ORACLE_HOME.
Procedure
1. Log in as root.
3. Create a directory to hold the contents of the Oracle distribution. For example:
# mkdir /var/tmp/oracle12102
4. Download the Oracle files to the /var/tmp/oracle12102 directory.
5. Extract the Oracle distribution files that now exist in the /var/tmp/oracle12102
directory.
Results
The directory created and to which the Oracle 12.1.0.2 distribution is downloaded
from now on be referred to by using <ORA_DIST_DIR>.

Before beginning this task, make sure that you have:
v Downloaded the Tivoli Netcool Performance Manager distribution to disk.
The directory that is created and to which the Tivoli Netcool Performance
Manager distribution is downloaded from now on be referred to by using
<DIST_DIR>.
What to do next
Before you proceed to the next step, make sure that you obtain the upgrade
instructions provided by Oracle. The instructions contain information on
performing steps that are required for the upgrade that are not documented in this
guide.
See your database administrator to determine whether there are any

company-specific requirements for installing Oracle in your environment.
Verify the required operating system packages

Before installing the Oracle server, make sure the all required packages are
installed on your system.
Procedure
1. Make sure all the required Solaris packages and patches are installed on your
system. All required packages and patches are specified in the Configuration
Recommendations.
2. If these packages are not on your system, see the relevant operating system
Installation Guide for instructions on installing supplementary package
software.
Running the Oracle server configuration script

In this step, you set up the Oracle environment by using the script that is provided
with the Tivoli Netcool Performance Manager DataMart files on the Tivoli Netcool
Performance Manager distribution.
About this task
This script automatically creates the following configuration:

v Adds the dba and install groups to /etc/group
v Adds the login name oracle, whose primary group membership is dba and
secondary group membership is oinstall.
Note: You must use the same Oracle username across all instances of Oracle
Client and Server throughout your Tivoli Netcool Performance Manager system.
v Creates the Oracle directory structure
v Creates startup and shutdown scripts for Oracle server processes
Note: If the oracle user is not created, the script creates this user for you, and
ORACLE_BASE is set as the user home directory. If you would prefer to use a
different home directory for the oracle user, create the oracle user before you run
the script. The script does not create an oracle user if one exists.
Note: It is likely that you have create the dba and install groups and the oracle
user. However, this script must still be run to create the required Oracle directory
structure.

To configure the Oracle installation environment by using the script:
Procedure
1. As root, set the ORACLE_BASE and ORACLE_HOME environment variables.
For example:
# export ORACLE_BASE=/opt/oracle/
# export ORACLE_HOME=/opt/oracle/product/12.1.0
Note: The script places this variable into the oracle login account's .profile
file.
To check that the variable is set correctly, enter the following command:
# env | grep ORA
systems:
# cd <DIST_DIR>/proviso/SOLARIS/DataBase/SOL10/oracle/instance
systems:
# cd <DIST_DIR>/proviso/AIX/DataBase/AIX<version_num>/oracle/instance
systems:
# cd <DIST_DIR>/proviso/RHEL/DataBase/RHEL<version_num>/oracle/instance
where:
<DIST_DIR> is the directory on the hard disk drive where you copied the
contents of the Tivoli Netcool Performance Manager distribution in “Download
the Oracle distribution to disk” on page 127.
3. Run the Oracle configuration script by entering the following command:
# ./configure_ora
Important: If permission to the $ORACLE_BASE directory is not granted, the

install database step fails during deployment. During Oracle installation, the
/opt/oracle folder that is created by configure_ora script has no permission
that is granted to any other users. Therefore, after you run the configure_ora
script, assign the following permission to the $ORACLE_BASE directory (for
example, /opt/oracle):
a. Log in as oracle user.
b. Run the following command:
chmod 755 /opt/oracle
The following screen is displayed:
Chapter 5. Installing database 113

--------------------------------------------------
Setting the Oracle environment
<Current Date>
--------------------------------------------------
OS ........... : [ Linux 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:39 EDT 2010 ]
Host ......... : [ <Hostname> ]
Logname ...... : [ root ]
ORACLE_BASE .. : [ /opt/oracle ]
ORACLE_HOME .. : [ /opt/oracle/product/12.1.0 ]
DBA group ................. : [ dba ]

OUI inventory group ....... : [ oinstall ]
Oracle software owner ..... : [ oracle ]
Configure Oracle release .. : [ 12.1.0 ]
Menu :
1. Modify Oracle software owner.
2. Next supported release.
3. Check environment.
0. Exit
Choice :
4. Type 3 at the Choice prompt and press Enter.

The script creates the dba and oinstall groups and the ORACLE_BASE directory,
unless they exist:
Checking environment...
Checking for group [ dba ] --> Created.
Checking for group [ oinstall ] --> Created.
Checking ORACLE_BASE
** WARNING
** ORACLE_BASE directory does not exist.
** [ /opt/oracle ]
**
** Create it ? (n/y) y
5. Type y and press Enter.

The script creates the /opt/oracle directory and continues as follows:
Checking for user [ oracle ]
** WARNING
** User [ oracle ] does not exist.
**
** Create it locally ? (n/y) y
6. Type y and press Enter.

The script creates the oracle user and continues as follows:

--> Created.
Checking for oracle directory tree :
[ /opt/oracle/product ] --> Created.
[ /opt/oracle/product/12.1.0 ] --> Created.
[ /opt/oracle/product/12.1.0/dbs ] --> Created.
[ /opt/oracle/admin ] --> Created.
[ /opt/oracle/admin/skeleton ] --> Created.
[ /opt/oracle/admin/skeleton/lib ] --> Ok.
[ /opt/oracle/admin/skeleton/lib/libpvmextc.so ] --> Created.
[ /opt/oracle/admin/skeleton/lib/libmultiTask.so ] --> Created.
[ /opt/oracle/admin/skeleton/lib/libcmu.so ] --> Created.
[ /opt/oracle/admin/skeleton/bin ] --> Ok.
[ /opt/oracle/admin/skeleton/bin/snmptrap ] --> Created.
[ /opt/oracle/local ] --> Created.
Checking for oracle .profile file --> Created.
Checking for dbora file --> Created.
/etc/rc0.d/K10dbora link --> Created.
/etc/rc1.d/K10dbora link --> Created.
/etc/rc2.d/S99dbora link --> Created.
Checking for dbora configuration files :
/var/opt/oracle/oratab --> Created.
/var/opt/oracle/lsnrtab --> Created.
Press Enter to continue...
7. Press the Enter key to continue. The main screen is refreshed.

8. Type 0 and press Enter to exit the script.
Note: You must set a password for the oracle login name.
Structure created by the configure_ora script

The configure_ora script creates the Oracle directory structure.
The following example shows the directory structure that is created for Oracle,
where ORACLE_BASE was set to /opt/oracle:
/opt/oracle/product
12.1.0.2
12.1.0.2/dbs
/opt/oracle/admin
/opt/oracle/admin/skeleton
/opt/oracle/admin/skeleton/bin
/opt/oracle/local
The script creates the following setup files:
Specific files:
v /etc/init.d/dbora, which starts the Oracle Listener and database server
automatically on each system restart
v Symbolic links to /etc/init.d/dbora in /etc/rc0.d, /etc/rc1.d, and /etc/rc2.d
v Oracle configuration files /var/opt/oracle/oratab and lsnrtab.
Specific files:
v /etc/inittab is modified to contain the dbstart and lsnrctlstartup calls.
v /etc/rc.shutdown is modified to contain the dbshut and lsnrctl stop
commands.
v Oracle configuration files /etc/oratab and /etc/lsnrtab.
Note: AIX does not use init.d.
Common files:

v A .profile file for the oracle user that contains the following lines:
# -- Begin Oracle Settings --

umask 022
ORACLE_BASE=/opt/oracle
ORACLE_HOME=$ORACLE_BASE/product/12.1.0
NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1
ORA_NLS33=$ORACLE_HOME/ocommon/nls/admin/data
LD_LIBRARY_PATH=$ORACLE_HOME/lib
TNS_ADMIN=$ORACLE_HOME/network/admin
PATH=$PATH:$ORACLE_HOME/bin:/usr/ccs/bin
EXTPROC_DLLS=ONLY:${LD_LIBRARY_PATH}/libpvmextc.so
export PATH ORACLE_BASE ORACLE_HOME NLS_LANG
export ORA_NLS33 LD_LIBRARY_PATH TNS_ADMIN
export EXTPROC_DLLS
# -- End Oracle Settings --
Note:
v The value of ORACLE_HOME cannot contain soft links to other directories or
file systems. Be sure to specify the entire absolute path to Oracle.
v You must add the ORACLE_SID variable to this file later, in “Set the
ORACLE_SID variable” on page 118.
Setting a password for the Oracle login name

You must assign a password for the oracle login name to maintain system
security.
About this task

The configure_ora script that you ran in the previous section creates the oracle
login name. You must assign a password for the oracle login name to maintain
system security, and because subsequent installation steps expect the password to
be already set.
To set a password:
Procedure
1. Log in as root.
# passwd oracle
3. Enter and reenter the password (oracle, by default) as prompted. The
password is set.
Run the preinstallation script

Run the preinstallation script to verify your readiness to install Oracle.
Procedure
1. As root, change directory using the following command:
systems:
# cd <DIST_DIR>/proviso/SOLARIS/DataBase/SOL10/oracle/instance/ora_installer
systems:
# cd <DIST_DIR>/proviso/AIX/DataBase/AIX<version_num>/oracle/instance/ora_installer
systems:

# cd <DIST_DIR>/proviso/RHEL/DataBase/RHEL<version_num>/oracle/instance/ora_installer
where:
<DIST_DIR> is the directory on the hard drive where you copied the contents of
the Tivoli Netcool Performance Manager distribution in “Download the Oracle
distribution to disk” on page 127.
2. Set the ORACLE_BASE environment variable. For example:
# ORACLE_BASE=/opt/oracle
# export ORACLE_BASE
Note: You must use the same ORACLE_BASE setting that you specified in
“Run the Oracle server configuration script”.
# ./pre_install_as_root
The following messages indicate success:
Checking that you are logged in as root --> Ok.
Checking ORACLE_BASE --> Ok.
Checking oraInst.loc file --> Ok.
If the script shows an error, correct the situation causing the error before
proceeding to the next step.
Running the rootpre.sh script (AIX only)
To run the rootpre.sh script.
Procedure
1. Log in as root or as a superuser.
3. Change to the directory <ORA_DIST_DIR>/database.
Note: The Oracle server (64-bit) distribution is downloaded to <ORA_DIST_DIR>

as per the instructions in the section “Download the Oracle distribution to
disk” on page 127.
./rootpre.sh
rootpre.sh may return an error like the following:
Configuring Asynchronous I/O....
Asynchronous I/O is not installed on this system.
This error can safely be ignored.
Note: For more information on this Oracle error, see Oracle Metalink Article
282036.1.

Verifying PATH and Environment for the Oracle login name
Before proceeding to install Oracle files, make sure the /usr/ccs/bin directory is in
the PATH environment variable for the oracle login name.
About this task
To verify the PATH and environment:
Procedure
1. Log in as oracle. Set and export the DISPLAY environment variable.
If you are using the su command to become oracle, use a hyphen as the second
argument so the oracle user login environment is loaded:
# su - oracle
2. Verify that the environment variable ORACLE_BASE has been set by entering
the following command:
$ env | grep ORA
If the response does not include ORACLE_BASE=/opt/oracle, stop and make sure
the .profile file was set for the oracle user, as described in “Run the Oracle
client configuration script” on page 127.
3. To verify the path, enter the following command:
$ echo $PATH
The output must show that /usr/ccs/bin is part of the search path. For
example:
/usr/bin:/opt/oracle/product/12.1.0/bin:/usr/ccs/bin
a. If this directory is not in the path, add it by entering the following

commands:
$ PATH=$PATH:/usr/ccs/bin
$ export PATH
Set the ORACLE_SID variable

A system identifier (SID) identifies each Oracle database instance for internal
connectivity on the Oracle server itself. (Connectivity from Oracle Clients to the
server is controlled by the TNS names system configured later.) The environment
variable for the system identifier is ORACLE_SID.
About this task

Decide on an SID to use for your Tivoli Netcool Performance Manager database
instance. The assumed default for the Tivoli Netcool Performance Manager
installation is PV. IBM recommends using this default SID unless your site has
established Oracle SID naming conventions.
To set the ORACLE_SID environment variable:
Procedure
1. Log in as oracle.
2. Open the .profile file with a text editor.
3. Add the following line anywhere between the Begin and End Oracle Settings
comment lines:
ORACLE_SID=PV; export ORACLE_SID

For example:
umask 022
ORACLE_HOME=/opt/oracle/product/12.1.0
ORACLE_SID=PV; export ORACLE_SID
PATH=$PATH:$ORACLE_HOME/bin:/usr/ccs/bin:/usr/delphi/bin
export ORA_NLS33 LD_LIBRARY_PATH TNS_ADMIN
export EXTPROC_DLLS
4. Save and exit the .profile file.
5. Enter the following shell command to activate the change to your profile:
$ . ./.profile
6. Make sure the variable was set by entering the following command:
$ env | grep ORACLE_SID
Installing Oracle by using the menu-based script

To install the Oracle database files by using a menu-based system.
Before you begin
Add the following group to the oraInst.loc file.
From /etc/oraInst.loc, add:

inst_group=oinstall

inst_group=oinstall
From /var/opt/oracle/oraInst.loc, add:

inst_group=oinstall
About this task
It is recommended that you use the menu-based script method.
Note: The Oracle installation script that is provided by IBM is used to install
Oracle server, Oracle client, and upgrade patches to an existing Oracle server or
Client installation.
To install the Oracle server (64-bit) using the menu-based script:
Procedure
1. As Oracle, change directory by using the following command:
systems:
systems:

/ora_installer
systems:
where:
<DIST_DIR> is the directory on the hard disk drive where you copied the
contents of the Tivoli Netcool Performance Manager distribution in
“Download the Oracle distribution to disk” on page 127.
2. Enter the following command to start the installer:
$ ./perform_oracle_inst
The installation menu is displayed:
--------------------------------------------------
perform_oracle_inst
Installation of oracle binaries
<Current Date>
--------------------------------------------------
Host ......... : [ tnpmuslnx0110.myhost.example.com ]
Logname ...... : [ oracle ]
Install Oracle release .... : [ 12.1.0 ]
Installation type.......... : [ Server ]
Enter the appropriate letter to modify the entries below:
a) ORACLE_BASE .. : [ /opt/oracle ]
b) ORACLE_HOME .. : [ /opt/oracle/product/12.1.0 ]
c) DBA group ..................... : [ dba ]
d) OUI Inventory group ........... : [ oinstall ]
e) Oracle Software owner ......... : [ oracle ]
f) Directory where CDs were copied:
[ <ORA_DIST_DIR> ]
Menu :
1. Next supported release
2. Set install type to: Client
3. Perform install
0. Exit
Choice :
3. Verify the following settings:

v The Oracle release number is 12.1.0.
v The Installation type field is Server.
This field cycles between three settings: Server, Client, and Patch. Type 2 at
the Choice prompt and press Enter until Server is displayed.
4. Type f at the Choice prompt and press Enter.
5. At the Choice prompt, enter the full path to the directory that contains the
installation files, <ORA_DIST_DIR>. For example:
Choice: f
Enter new value for CD directory: /var/tmp/oracle12102
6. Type a at the Choice prompt and press Enter.

7. At the Choice prompt, enter the full path to the oracle base directory created
for Oracle 12.1.0.2. The default is /opt/oracle.
8. Type b at the Choice prompt and press Enter.
9. At the Choice prompt, enter the full path to the oracle home directory created
for Oracle 12.1.0.2. The default is /opt/oracle/product/12.1.0.
10. Edit other menu settings as required. For example, if you used non-default
values for ORACLE_BASE or ORACLE_HOME, enter your settings until the menu
shows that they correctly point to the directories created for Oracle 12.1.0.2.

11. To begin the Oracle installation, type 3 at the Choice prompt and press Enter.
The installation script checks the environment, then asks if you want to
perform the installation.
12. Type Y at the Choice prompt and press Enter. The installation script starts
installing Oracle and displays a series of status messages.
Note: You can safely ignore any font.properties not found messages in the
output.
When the installation reaches the In Summary Page stage, the installation
slows down significantly while Oracle files are copied and linked.
13. The following message is displayed when the installation completes:
In End of Installation Page
The installation of Oracle12c Database was successful.
Check /opt/oracle/oraInventory/logs/silentInstall2011-09-28_04-23-53PM.log
for more details.
The Oracle installation has completed. Check the
messages above to determine if the install completed
successfully. If you do not see successful completion
messages, consult the install log at:
/opt/oracle/oraInventory/logs
Press C to continue...
Note: For any installation error, write down the log file location to aid in
troubleshooting.
14. Type C and press Enter to return to the installation menu.
15. Type 0 and press Enter to exit the installation menu.
What to do next
Note: Review the Oracle installation logs at $ORACLE_BASE/oraInventory/logs for

errors as some fatal errors might be reported in the log, but the native Oracle
installer reports success in standard output.
Run the root.sh script

After successfully running an Oracle client or server installation, you must run the
root.sh script.
About this task
This step is also required after an Oracle patch installation. See “Verify the required
operating system packages” on page 112.
To run the root.sh script:
Procedure
1. Log in as root or become superuser. Set the DISPLAY environment variable.
2. Change to the directory where Oracle server files were installed. (This is the
directory as set in the ORACLE_HOME environment variable.) For example:
# cd /opt/oracle/product/12.1.0
./root.sh
Messages like the following are displayed:

Running Oracle12c root.sh script...
# ./root.sh
Check /opt/oracle/product/12.1.0/install/root_
<server_hostname>_2014-03-18_13-45-04.log for the output of root script
File contents:
Performing root user operation for Oracle 12c
The following environment variables are set as:

ORACLE_OWNER= oracle
ORACLE_HOME= /opt/oracle/product/12.1.0
Entries will be added to the /etc/oratab file as needed by

Database Configuration Assistant when a database is created
Finished running generic part of root script.
Now product-specific root actions will be performed.
Finished product-specific root actions.
Set automatic startup of the database instance

You must configure your Oracle host to automatically start the Tivoli Netcool
Performance Manager database instance at system startup time.
About this task
To set up automatic startup:
Procedure
2. Depending on your operating system, change to the following directory:
systems:
$ cd /var/opt/oracle
systems:
$ cd /etc
systems:
$ cd /etc
3. Edit the oratab file with a text editor. The last line of this file looks like this
example:
*:/opt/oracle/product/12.1.0:N
4. Make the following edits to this line:
v Replace * with $ ORACLE_SID (PV by default).
v Replace N with Y.
The last line must now be:
PV:/opt/oracle/product/12.1.0:Y
5. Save and close the oratab file.

Configure the Oracle listener
How to configure the Oracle Listener.
About this task
Note: Instead of creating the listener.ora file manually, as described in the steps
that follow, you can create it by running the Oracle Net Configuration Assistant
utility. See the Oracle Corporation documentation for information about Net
Configuration Assistant.
The Oracle Listener process manages database connection requests from Oracle
clients to an Oracle server.
To configure the Oracle Listener:
Procedure
2. Change to one of the following directories:
$ cd $TNS_ADMIN
or
$ cd /opt/oracle/product/12.1.0/network/admin
3. Copy the sample listener.ora contained in the /opt/oracle/admin/skeleton/
bin directory:
$ cp /opt/oracle/admin/skeleton/bin/template.example_tnpm.listener.ora listener.ora
Note: By Oracle convention, the keywords in this file are in uppercase but
uppercase is not required.
# listener.ora network configuration file in directory
# /opt/oracle/product/12.1.0/network/admin
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP) (HOST = {HOST}) (PORT = 1521))
)
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC) (KEY = EXTPROC))
)
)
)
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = /opt/oracle/product/12.1.0)
(PROGRAM = extproc)
)
(SID_DESC =
(GLOBAL_DBNAME = PV.WORLD)
(SID_NAME = PV)
(ORACLE_HOME = /opt/oracle/product/12.1.0)
)
)
4. Using a text editor, change the following:
a. Replace the string yourhost in the line (HOST = yourhost) with the name of
your Oracle server.

Note: Specify the host using the hostname only, do not use the IP address.
b. You also need to edit the file with SID and Oracle Home directory.
c. (optional) Replace the default port number 1521 in the line (PORT =1521 )
with your required port number.
d. Write and quit the file.
5. Depending on your operating system, change to the following directory:
systems:
$ cd /var/opt/oracle
systems:
$ cd /etc
systems:
$ cd /etc
6. Edit the lsnrtab file and add a line in the following format to the end of the
file (after the initial comments):
LISTENER:value_of_ORACLE-HOME:Y
For example:
LISTENER:/opt/oracle/product/12.1.0:Y
In this syntax, LISTENER is the name of the listener process.
8. Test that the listener process works correctly by starting it manually using the
following command:
lsnrctl start
(The lsnrctl command also accepts the stop and status arguments.) Look for
a successful completion message.
Configure the Oracle net client

You must configure an Oracle Net client by setting up the TNS (Transport Network
Substrate) service names for your Tivoli Netcool Performance Manager database
instance.
About this task
To set up the TNS service names
Procedure
2. Change to one of the following directories:
$ cd $TNS_ADMIN
or
$ cd /opt/oracle/product/12.1.0/network/admin
3. Create the sqlnet.ora file, which will manage Oracle network operations. You
must create an sqlnet.ora file for both Oracle server and Oracle client
installations. Follow these steps:
a. Copy the sample sqlnet.ora file, template.example_tnpm.sqlnet.ora,
contained in the opt/oracle/admin/skeleton/bin/ directory:
$ cp /opt/oracle/admin/skeleton/bin/template.example_tnpm.sqlnet.ora sqlnet.ora
b. Add the following lines to this file:

NAMES.DIRECTORY_PATH=(TNSNAMES)
NAMES.DEFAULT_DOMAIN=WORLD
SQLNET.ALLOWED_LOGON_VERSION_CLIENT=8
SQLNET.ALLOWED_LOGON_VERSION_SERVER=8
For example:
# sqlnet.ora network configuration file in
Note: If you do not use WORLD as the DEFAULT_DOMAIN value, make

sure you enter the same value for DEFAULT_DOMAIN in both sqlnet.ora
and tnsnames.ora.
c. Write and quit the sqlnet.ora file.
d. Restart the listener process using the following command:
lsnrctl stop
lsnrctl start
Look for a successful completion message.
4. Create the tnsnames.ora file, which maintains the relationships between logical
node names and physical locations of Oracle Servers in the network. You can
do this by copying the existing sample file:
cp /opt/oracle/admin/skeleton/bin/template.example_tnpm.tnsnames.ora tnsnames.ora
Follow these steps:
a. Enter lines similar to the following example, using the actual name of your
Oracle server in the HOST=delphi line and replacing {SID} with PV or your
Oracle SID.
# tnsnames.ora network configuration file in
#
# The EXTPROC entry only needs to exist in the
# tnsnames.ora file on the Oracle server.
# For Oracle client installations, tnsnames.ora
# only needs the PV.WORLD entry.
EXTPROC_CONNECTION_DATA.WORLD =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = IPC)
(KEY = EXTPROC)
)
)
(CONNECT_DATA = (SID = PLSExtProc)
(PRESENTATION = RO)
)
)
PV.WORLD =
(DESCRIPTION =
(ENABLE=BROKEN)
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = delphi)
(PORT = 1521)
)
)
(CONNECT_DATA =

(SERVICE_NAME = PV.WORLD)
(INSTANCE_NAME = PV)
)
)
Note: Indents in this file must be preserved.

Note the following:
v You can use the value in the INSTANCE_NAME field as the TNS entry
when installing Tivoli Netcool Performance Manager DataMart.
v IBM strongly recommends that you include the line (ENABLE=BROKEN)
in the PV.WORLD entry, as shown in the example. This parameter setting
prevents CME processes from hanging in the event that the CME is
disconnected from the database before results are returned to the CME.
v If configuring tnsnames.ora for a server installation, be sure to append
the same domain suffix to all entries including EXTPROC_CONNECTION_DATA
that you specified for the NAMES.DEFAULT_DOMAIN entry in the
sqlnet.orafile. That is, append.WORLD to each entry.
b. Write and quit the file.
5. Test the Oracle Net configuration by entering a command with the following
syntax:
tnsping Net_service_name.domain 10
For example:
$ tnsping PV.WORLD 10
Look for successful completion messages (OK).
To test without using the domain suffix, enter a command with the following
syntax:
tnsping Net_service_name 10
For example:
$ tnsping PV 10
Note: If either test is not successful, check your configuration and retest.
Installing Oracle 12.1.0.2 client 32-bit
Instructions on how to install the Oracle 12.1.0.2 client (32-bit).
The deployer and Topology Editor use Oracle 12.1.0.2 client (32-bit). The deployer
must run on the Host DB server. Therefore, in the Tivoli Netcool Performance
Manager, Oracle 12.1.0.2 client (32-bit) must be installed.
You must specify a different directory path for the Oracle 12.1.0.2 client (32-bit)
from the directory specified when installing the Oracle 12.1.0.2 server. For example,
assuming that Oracle 12.1.0.2 server is installed in /opt/oracle/product/12.1.0
then you must install the Oracle 12.1.0.2 client (32-bit) in /opt/oracle/product/
12.1.0-client32.
You must install Oracle client 32-bit on all machines except for the server that
hosts the Tivoli Netcool Performance Manager database server. Should there be
another Tivoli Netcool Performance Manager component on the server hosting the
Tivoli Netcool Performance Manager database server, the client must also be
installed on that server, having a separate ORACLE_HOME for both Oracle client
and server.

Download the Oracle distribution to disk
The Oracle installation files must be in place before you can begin the installation
of Oracle.
About this task
Note: Oracle 12.1.0.2 client (32-bit) must be installed into a new ORACLE_HOME.
Procedure
1. Log in as root.
3. Create a directory to hold the contents of the Oracle distribution. For example:
# mkdir /var/tmp/oracle12102
4. Download the Oracle files to the /var/tmp/oracle12102 directory.
5. Extract the Oracle distribution files that now exist in the /var/tmp/oracle12102
directory.
6. Create a soft link for the client32 folder from the
Oracle distribution files directory:
# cd /var/tmp/oracle12102
# ln -s client32 client
Results
The directory created and to which the Oracle 12.1.0.2 distribution is downloaded
from now on be referred to by using <ORA_DIST_DIR>.
Before beginning this task, make sure that you have:

The directory that is created and to which the Tivoli Netcool Performance
Manager distribution is downloaded from now on be referred to by using
<DIST_DIR>.
What to do next
Before you proceed to the next step, make sure that you obtain the upgrade
instructions provided by Oracle. The instructions contain information on
performing steps that are required for the upgrade that are not documented in this
guide.

company-specific requirements for installing Oracle in your environment.
Run the Oracle client configuration script

The Oracle client configuration shell script creates the environment for the client
software installation on the local system.
About this task
This script is named configure_client and is located with the Tivoli Netcool
Performance Manager files downloaded as part of the Tivoli Netcool Performance
Manager distribution. If you are performing this step as part of an upgrade

procedure, make sure that you run the configuration script provided with the
target version of Tivoli Netcool Performance Manager.
The client configuration script makes the following changes to the local system:
v Adds the dba and oinstall groups to /etc/group.
v Adds the Solaris login name oracle, whose primary group membership is dba,
and secondary group membership is oinstall.
Note: You must use the same Oracle username across all instances of Oracle
Client and Server throughout your Tivoli Netcool Performance Manager system.
v Creates the Oracle client directory structure. When you create the environment
for Oracle 12.1.0.2, the default location for this directory structure is
/opt/oracle/product/12.1.0-client32. You specify this directory as the target
location when you install the Oracle client.
Note: None of the above changes are made if the changes are already in place.
To configure the Oracle installation environment:
Procedure
1. Log in as root.
2. Set the ORACLE_BASE environment variable to point to the top-level directory
where you want the Oracle client files installed. The default installation
directory is /opt/oracle.
For example:
Note: The configure_client script places this variable into the oracle login
name's .profile file.
To check that the variable is set correctly, enter the following command:
# env | grep ORA
3. Set the ORACLE_HOME environment variable. For example:
# ORACLE_HOME=/opt/oracle/product/12.1.0-client32
# export ORACLE_HOME
Note: The value defined in the configure_client script for ORACLE_HOME is the
value needed in the Topology Editor for Oracle Home on the host level.
systems:
# cd <DIST_DIR>/proviso/SOLARIS/DataBase/SOL10/oracle/instance
systems:
systems:
# cd <DIST_DIR>/proviso/RHEL/DataBase/RHEL<version_num>/oracle/instance
where:
5. Run the Oracle configuration script using the following command:

# ./configure_client
The following screen is displayed:
--------------------------------------------------
configure_client
Setting the Oracle client environment
Tue Dec 6 14:51:23 CST 2011
--------------------------------------------------
OS ........... : [ SunOS 5.10 Generic_141444-09 ]
Host ......... : [ l3provsol1z3 ]
Logname ...... : [ root ]
ORACLE_BASE .. : [ /opt/oracle ]
ORACLE_HOME .. : [ /opt/oracle/product/12.1.0-client32]
DBA group ................. : [ dba ]
OUI Inventory group ....... : [ oinstall ]
Oracle Software owner ..... : [ oracle ]
Configure Oracle release .. : [12.1.0]
Menu :
1. Modify Oracle software owner.
2. Next supported release.
3. Check environment.
0. Exit
Choice :
6. Type 3 at the Choice prompt and press Enter.

The script creates the dba and oinstall groups, and the ORACLE_BASE directory,
unless they already exist.
Checking environment...
Checking for group [ dba ] --> Created.
Checking for group [ oinstall ] --> Created.
Checking ORACLE_BASE
** WARNING
** ORACLE_BASE directory does not exist.
** [ /opt/oracle ]
**
** Create it ? (n/y) y
If prompted, type y and press Enter.

The script creates the /opt/oracle directory and continues as follows:
Checking for user [ oracle ]
** WARNING
** User [ oracle ] does not exist.
**
** Create it locally ? (n/y) y
If prompted, type y to create the oracle user and press Enter.

The script creates the oracle user and continues as follows:
--> Created.
Checking for oracle directory tree :
[ /opt/oracle/product/12.1.0 ] --> Created.
Checking for oracle .profile file --> Created.
Press Enter to continue...
7. Press Enter to continue. The configure_client main screen is displayed.

8. Type 0 and press Enter to exit the script.

What to do next
Note: Install database step fails during deployment if permission to the

$ORACLE_BASE directory is not granted. During Oracle installation, the /opt/oracle
folder that is created by configure_client script has no permission that is granted
to any other users. Therefore, after you run the configure_client script, assign the
following permission to the $ORACLE_BASE directory (for example, /opt/oracle):
1. Log in as oracle user.
chmod 755 /opt/oracle
Setting a password for the Oracle login name

You must assign a password for the oracle login name to maintain system
security.
About this task
The configure_ora script that you ran in the previous section creates the oracle
login name. You must assign a password for the oracle login name to maintain
system security, and because subsequent installation steps expect the password to
be already set.
To set a password:
Procedure
1. Log in as root.
# passwd oracle
3. Enter and reenter the password (oracle, by default) as prompted. The
password is set.
Run the preinstallation script

Run the preinstallation script to verify your readiness to install Oracle.
Procedure
1. As root, change directory using the following command:
systems:
systems:
# cd <DIST_DIR>/proviso/AIX/DataBase/AIX<version_num>/oracle/instance/ora_installer
systems:
where:
2. Set the ORACLE_BASE environment variable. For example:

Note: You must use the same ORACLE_BASE setting that you specified in
“Run the Oracle server configuration script”.
# ./pre_install_as_root
The following messages indicate success:
Checking that you are logged in as root --> Ok.
Checking ORACLE_BASE --> Ok.
Checking oraInst.loc file --> Ok.
If the script shows an error, correct the situation causing the error before
proceeding to the next step.
Verifying PATH and Environment for the Oracle login name

Before proceeding to install Oracle files, make sure the /usr/ccs/bin directory is in
the PATH environment variable for the oracle login name.
About this task
To verify the PATH and environment:
Procedure
1. Log in as oracle. Set and export the DISPLAY environment variable.
If you are using the su command to become oracle, use a hyphen as the second
argument so the oracle user login environment is loaded:
# su - oracle
2. Verify that the environment variable ORACLE_BASE has been set by entering
the following command:
$ env | grep ORA
If the response does not include ORACLE_BASE=/opt/oracle, stop and make sure
the .profile file was set for the oracle user, as described in “Run the Oracle
client configuration script” on page 127.
3. To verify the path, enter the following command:
$ echo $PATH
The output must show that /usr/ccs/bin is part of the search path. For
example:
/usr/bin:/opt/oracle/product/12.1.0/bin:/usr/ccs/bin
a. If this directory is not in the path, add it by entering the following

commands:
$ PATH=$PATH:/usr/ccs/bin
$ export PATH

Installing the Oracle client (32-bit)
The Oracle installation script is a shell script that you can use to install the Oracle
server, Oracle client software, or patches to existing installations of the Oracle
server and client.
Before you begin
Add the following group to the oraInst.loc file.

inst_group=oinstall

inst_group=oinstall
From /var/opt/oracle/oraInst.loc, add:

inst_group=oinstall
About this task

This script is named perform_oracle_inst and is located with the Tivoli Netcool
Performance Manager files that you obtained in “Download the Oracle distribution
to disk” on page 127. This script is provided by IBM as part of the Tivoli Netcool
Performance Manager installation package.
An Oracle client installation is not usable until the following Net configuration
files are configured and installed:
v tnsnames.ora
v sqlnet.ora
These files are configured in later steps.
To install the Oracle client:
Procedure
systems:
systems:
/ora_installer
systems:
Where:
v <DIST_DIR> is the directory on the hard disk drive where you copied the
contents of the Tivoli Netcool Performance Manager distribution in
“Download the Oracle distribution to disk” on page 127.
3. Enter the following command to start the installer:

$ ./perform_oracle_inst
The installation menu is displayed:
--------------------------------------------------
perform_oracle_inst
Installation of oracle binaries
Tue Jun 18 10:42:54 PDT 2013
--------------------------------------------------
Host ......... : [ tnpmuslnx0110.persistent.co.in ]
Logname ...... : [ oracle ]
Install Oracle release .... : [ 12.1.0.2]

Installation type.......... : [ Client ]
Enter the appropriate letter to modify the entries below:
a)ORACLE_BASE .. : [ /opt/oracle ]
b)ORACLE_HOME .. : [ /opt/oracle/product/12.1.0-client32 ]
c)DBA group ..................... : [ dba ]
d)OUI Inventory group ........... : [ oinstall ]
e)Oracle Software owner ......... : [ oracle ]
f)Directory where CDs were copied:
[ ]
Menu :
1. Next supported release
2. Set install type to: Client
3. Perform install
0. Exit
Choice :
Note:
a. The ORACLE_HOME must match the ORACLE_HOME set in the deployer for the
server on which the client is being installed.
b. Make sure the listener process is down before you start installing Oracle
12.1.0.2 client (32-bit).
4. Enter f at the Choice prompt and press Enter.
5. Enter the full path to the <ORA_DIST_DIR>, as created in “Download the
Oracle distribution to disk” on page 127. For example:
Choice: f
Enter new value for CD directory: /var/tmp/oracle12102
6. Edit any other menu settings as necessary. Make sure that the values for
ORACLE_BASE and ORACLE_HOME correspond to the locations you specified when
you ran the Oracle client configuration script.
7. To start the Oracle installation, type 3 at the Choice prompt and press Enter.
8. The installation script checks the environment, then asks whether you want to
perform the installation. Type Y at the Choice prompt and press Enter. The
installation script starts installing Oracle and displays a series of status
messages.
Note: You can safely ignore any font.properties not foundmessages in the
output.
When the installation reaches the In Summary Page stage, the installation
slows down significantly while Oracle files are copied and linked.
9. On AIX, you are asked if the script named rootpre.sh is run.

To run this script:
a. Open another window.

b. Log in as root.
c. cd to /var/tmp/oracle12102/database/rootpre
d. run rootpre.sh
e. Then, answer Y to the installation script.
10. When the installation process is finished, the installation displays a success
message. Write down the log file location to aid in troubleshooting if there is
an installation error.
11. Type C and press Enter to return to the installation menu.
12. Type 0 and press Enter to exit the installation menu.
13. Perform the steps in “Run the root.sh script” on page 121.
Run the root.sh script

After successfully running an Oracle client or server installation, you must run the
root.sh script.
About this task
This step is also required after an Oracle patch installation. See “Verify the required
operating system packages” on page 112.
To run the root.sh script:
Procedure
1. Log in as root or become superuser. Set the DISPLAY environment variable.
2. Change to the directory where Oracle client files were installed. (This is the
directory as set in the ORACLE_HOME environment variable.) For example:
# cd /opt/oracle/product/12.1.0-client32
./root.sh
Messages like the following are displayed:
Running Oracle12c root.sh script...
# ./root.sh
Check /opt/oracle/product/12.1.0-client32/install/root_
<server_hostname>_2014-03-18_13-45-04.log for the output of root script
File contents:
Performing root user operation for Oracle 12c
The following environment variables are set as:

ORACLE_OWNER= oracle
ORACLE_HOME= /opt/oracle/product/12.1.0-client32
Entries will be added to the /etc/oratab file as needed by

Database Configuration Assistant when a database is created
Finished running generic part of root script.
Now product-specific root actions will be performed.
Finished product-specific root actions.

Updating the Oracle user's .profile
Modify the oracle user's .profile file.
Procedure
1. On the primary host server that hosts the Tivoli Netcool Performance Manager
database server, make sure that ORACLE_HOME points to $ORACLE_BASE/product/
12.1.0.
2. On the secondary host servers, that hosts any of the Tivoli Netcool Performance
Manager components, make sure that ORACLE_HOME points to
$ORACLE_BASE/product/12.1.0-client32.
3. If there is not already an entry for TNS_ADMIN, add one.
When complete, the .profile must look similar to:
umask 022
ORACLE_HOME=$ORACLE_BASE/product/12.1.0
PATH=$PATH:$ORACLE_HOME/bin:/usr/ccs/bin:/usr/local/bin

export ORA_NLS33 LD_LIBRARY_PATH TNS_ADMIN EXTPROC_DLLS
ORACLE_SID=PV
Export ORACLE_SID
4. Source the .profile file to apply the changes by using the following command:
$ cd /opt/oracle.
$ ./.profile
Configuring the Oracle Net client

You must configure the Oracle Net client by setting up the TNS (Transport
Network Substrate) service names for your Tivoli Netcool Performance Manager
database instance.
About this task
Next, you configure the Oracle Net client by setting up the TNS (Transport
Network Substrate) service names for your Tivoli Netcool Performance Manager
database instance. You must perform this step for each instance of the Oracle client
software that you installed on the system.
Procedure
v You must configure sqlnet.ora and tnsnames.ora files for both Oracle server
and Oracle client installations. However, the tnsnames.ora file for client
installations must not have the EXTPROC_CONNECTION_DATA section.
v If you are installing DataView and one or more other Tivoli Netcool
Performance Manager components on the same system, you must make sure
that the tnsnames.ora and sqlnet.ora files for each set of client software are

identical. The easiest way to do this is to create these files when you are
configuring the first client instance for Net and then to copy it to the
corresponding directory when you configure the second instance.
Creating the sqlnet.ora file

The sqlnet.ora file manages Oracle network operations. You can create a new
sqlnet.ora file, or FTP the file from your Oracle server.
About this task
To set up the TNS service names:
Procedure
2. Change the directory to Oracle 12.1.0.2 client (32-bit):
$ cd /opt/oracle/product/12.1.0-client32/network/admin
3. Create the sqlnet.ora file, which manages Oracle network operations. You
must create an sqlnet.ora file for both Oracle server and Oracle client
installations. Follow these steps:
a. Copy the sqlnet.ora file that was created earlier during the configuration
of oracle server net client, from /opt/oracle/product/12.1.0/network/admin
directory.
$ cp /opt/oracle/product/12.1.0/network/admin/sqlnet.ora .
b. Add the following lines to this file:
For example:
# sqlnet.ora network configuration file in
Note: If you do not use WORLD as the DEFAULT_DOMAIN value, make sure that
you enter the same value for DEFAULT_DOMAIN in both sqlnet.ora and
tnsnames.ora.
c. Write and quit the sqlnet.ora file.
d. Restart the listener process by using the following commands:
lsnrctl stop
lsnrctl start
Look for a successful completion message.
Creating the tnsnames.ora file

The tnsnames.ora file maintains the relationships between logical node names and
physical locations of Oracle servers in the network.

About this task
You can create a new tnsnames.ora file, or FTP the file from your Oracle server.
To create the tnsnames.ora file:
Procedure
1. FTP the following file from your Oracle server:
/opt/oracle/admin/skeleton/bin/template.example_tnpm.tnsnames.ora
2. Add the following lines:
#
# For Oracle client installations, tnsnames.ora
# only needs the PV.WORLD entry.
PV.WORLD =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = yourhost)
(PORT = 1521)
)
)
(CONNECT_DATA =
(SERVICE_NAME = PV.WORLD)
(INSTANCE_NAME = PV)
)
)
Note: Indents in this file must be preserved.

3. Replace the string yourhost in the line (HOST = yourhost) with the name of
your Oracle server.
Note the following:
v You can use the value in the INSTANCE_NAME field as the TNS entry
when installing DataMart.
v If you reconfigure the Oracle client to connect to a different Oracle database
in another Tivoli Netcool Performance Manager installation, be sure that you
update the HOST entry in the tnsnames.ora file, then restart the Oracle
client.
v Specify the host by using the hostname only, do not use the IP address.
4. (optional) Replace the default port number 1521 in the line (PORT = 1521) with
your required port number.
Tivoli Netcool Performance Manager non-default installation
6. For a non-default Tivoli Netcool Performance Manager installation, where
oracle is installed with a non-default parameter, add the following lines.
For example, ORACLE_SID is set to PVR during oracle installation. The
tnsnames.ora file must have the following entries.
PV.WORLD =
(DESCRIPTION =
(ENABLE=BROKEN)
(ADDRESS_LIST =
(ADDRESS =

(PROTOCOL = TCP)
(HOST = yourhost)
(PORT = 1521)
)
)
(CONNECT_DATA =
(SERVICE_NAME = PVR.WORLD)
(INSTANCE_NAME = PVR)
)
)
PVR.WORLD =
(DESCRIPTION =
(ENABLE=BROKEN)
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = yourhost)
(PORT = 1521)
)
)
(CONNECT_DATA =
(SERVICE_NAME = PVR.WORLD)
(INSTANCE_NAME = PVR)
)
)
Testing the Oracle net configuration

The steps required to test the Oracle Net configuration.
About this task
To test the Oracle Net configuration:
Procedure
2. Enter a command with the following syntax:
tnsping Net_service_name 10
For example: tnsping PV.WORLD 10
3. Test again, using the same Net instance name without the domain suffix:
tnsping PV 10
Look for successful completion messages (OK).
Testing the 32-bit SQLPlus

Memory fault might cause proviso database installation to fail. Run the following
steps to test the Oracle client 32-bit SQLPlus.
About this task
To avoid the memory fault issue, run the following steps:
Procedure
1. Log in as root.
2. Set the environment variable to # ORACLE_HOME=/opt/oracle/product/12.1.0-
client32
3. Run the SQLPlus by using the sqlplus from the Oracle 32-bit client version. For
example:

/opt/oracle/product/12.1.0-client32/bin/sqlplus
If the SQL login prompt returns, it should not cause any memory fault issue
during proviso database installation.
4. If a segmentation or memory fault occurs, create a zero length file under the
following path: /etc/sysconfig
For example:
touch /etc/sysconfig/64bit_strstr_via_64bit_strstr_sse2_unaligned
5. Rerun step 3 to ensure that you are not hitting any memory fault issues.
Installing DB2 Server 10.1.0.5 (64-bit)
The DB2 Server 10.1.0.5 (64-bit) version provides both 64-bit and 32-bit libraries.
Therefore, you need not install the DB2 client on Tivoli Netcool Performance
Manager Database server. However, DB2 client is required on every other host
where you want to install the Tivoli Netcool Performance Manager components.
About this task
Instructions on how to install the DB2 Server 10.1.0.5 (64-bit).
Important: In stand-alone environment, you do not need to install the DB2 Server
10.1.0.5 separately. You can use the DB2 server that you installed with Jazz for
Service Management.
DB2 Version 10.1 Fix Pack 5 for Linux, UNIX, and Windows
Download the IBM® DB2® 10.1 Fix Pack 5 distribution to disk

The DB2 installation files must be in place before you begin the installation of DB2.
Procedure
1. Log in as root.
3. Create a directory to hold the contents of the DB2 distribution. For example:
# mkdir /var/tmp/db2setup1010
4. Download the DB2 files to the /var/tmp/db2setup1010 directory.
5. Extract the DB2 distribution files that now exist in the /var/tmp/db2setup1010
directory.
What to do next

company-specific requirements for installing DB2 in your environment. The
directory created and to which the DB2 distribution is downloaded from now on is
referred as <DB2_DIST_DIR>.

Verifying the required operating system packages
Before you install the DB2 server, make sure that all required packages are
installed on your system.
Procedure
1. Make sure all the required Linux packages are installed on your system. All
packages and patches are specified in the Configuration Recommendations.
2. If these packages are not on your system, see the relevant operating system
Installation Guide for instructions on installing supplementary package
software.
Installing DB2 Server 10.1.0.5

To start the DB2 Setup wizard, use these steps.
Procedure
1. Change to the directory where the DB2 database product distribution is copied
by entering the following command:
cd <DB2_DIST_DIR>
2. If you have downloaded the DB2 database product image, extract the product
file by using the following commands:
gunzip <product>.tar.gz
tar -xvf product.tar
Where product is the name of the product that you downloaded.

3. Change directory to <DB2_DIST_DIR>/server.
4. Start DB2 installation by entering the following command:
./db2_install
Important: The db2_install command is deprecated and might be removed in

a future release. In this release it works as expected.
You see the following output:

./db2_install
Default directory for installation of products - /opt/ibm/db2/V10.1
***********************************************************
Install into default directory (/opt/ibm/db2/V10.1) ? [yes/no]
no
Enter the full path of the base installation directory:
------------------------------------------------
/opt/db2/product/10.1.0
Specify one of the following keywords to install DB2 products.
AESE
ESE
CONSV
WSE
EXP
CLIENT
RTCL
Enter "help" to redisplay product names.
Enter "quit" to exit.
***********************************************************
ESE
******************************************************
Do you want to install the DB2 pureScale Feature? [yes/no]
no
DB2 installation is being initialized.
Total number of tasks to be performed: 46

Total estimated time for all tasks to be performed: 1383 second(s)
Task #1 start
Description: Checking license agreement acceptance
Estimated time 1 second(s)
Task #1 end
Task #2 start
Description: Base Client Support for installation with root privileges
Task #2 end
Task #3 start
Description: Product Messages - English
Task #3 end
Task #4 start
Description: Base client support
Task #4 end
Task #5 start
Description: Java Runtime Support
Task #5 end
Task #6 start
Description: Java Help (HTML) - English
Task #6 end
.
.
.
.
.
.
The execution completed successfully.

For more information see the DB2 installation log at
"/tmp/db2_install.log.20295".
Note: The output above shows that the total number of tasks to be performed
are 46. But the installation log shows 48 tasks. This is a known limitation.
Results
DB2 Server 10.1.0.5 server is installed in /opt/db2/product/10.1.0 directory.
Setting up a DB2 instance

A DB2 instance is an environment in which you store data and run applications.
Before you begin

You must have root user authority.
Procedure
Use the db2icrt command to create an instance by using the following steps:
Run the following commands:

cd /opt/db2/product/10.1.0/instance
./db2icrt -u db2fenc db2
Updating /etc/services file

Port usage is specified in the /etc/services file
Procedure
Ensure that the DB2_db2 service-name is using port 60000. If not, update the
following line in /etc/services file:
DB2_db2 60000/tcp
Note: Here the DB2 port is hardcoded to use 60000 since the default DB2 port
number 50000 is preoccupied by the DB2 that is installed with Jazz for Service
Management.
DB2 instance variable registry settings

Procedure
1. Log in as db2 (instance user).
2. Run the following commands to set listening port and communication protocol:
[db2@tnpminlnx0119 ~]$ db2 update dbm cfg using svcename 60000
DB20000I The UPDATE DATABASE MANAGER CONFIGURATION command completed
successfully.
[db2@tnpminlnx0119 ~]$ db2set db2comm=TCPIP

DB2 configuration settings
Procedure
2. Run the following command to add an entry to the opt/db2/sqllib/cfg/
db2cli.ini file.
$ db2 update cli cfg for section db2ci using StrWorkaround 1

The following line is added to the /opt/db2/sqllib/cfg/db2cli.ini file.
[db2ci]
StrWorkaround=1
Starting the DB2 instance

Procedure
2. Run the following commands to start the instance if it is not already running:
db2start
Results
If instance is not running, then the command will start the instance. If it is already
running, then you may receive following message:
The database manager is already active
Installing IBM Data Server Client 10.1.0.5 (64-bit)
In a Tivoli Netcool Performance Manager system, you must install the Data Server
Client (64-bit) in a distributed environment only. It is not required in a stand-alone
environment. In a distributed environment, install the DB2 client software on each
server where you plan to install a Tivoli Netcool Performance Manager component,
except for the system where you installed the DB2 server.
About this task
Instructions on how to install the IBM Data Server Client 10.1.0.5 (64-bit).
Downloading the IBM Data Server Client 10.1.0.5 distribution

to disk
The DB2 installation files must be in place before you can begin the installation of
DB2.
Before you begin
Before you begin this task, make sure that you have:
The directory to which the Tivoli Netcool Performance Manager distribution is
downloaded is referred to as <DIST_DIR>.

About this task
DB2 client installation is performed on distributed environment only.
Procedure
1. Log in as root.
2. Create a directory to hold the contents of the Data Server Client distribution.
For example:
# mkdir /var/tmp/db2setup1010
3. Download the Data Server Client files to the /var/tmp/db2setup1010 directory.
4. Extract the Data Server Client distribution files that now exist in the
/var/tmp/db2setup1010 directory. The directory to which the IBM Data Server
Client 10.1.0.5 distribution is downloaded is referred to as <DB2_DIST_DIR>.
Installing IBM Data Server Client (64-bit)

To start the DB2 Setup wizard, use these steps.
Procedure
1. Change to the directory where the DB2 database product distribution is copied
by entering the following command:
cd <DB2_DIST_DIR>
2. If you have downloaded the DB2 database product image, extract the product
file by using the following commands:
gzip <product>.tar.gz
tar -xvf product.tar
Where product is the name of the product that you downloaded.

3. Change directory to <DB2_DIST_DIR>/server.
4. Start DB2 installation by entering the following command:
./db2_install
You see the following output:

./db2_install
Default directory for installation of products - /opt/ibm/db2/V10.1
***********************************************************
Install into default directory (/opt/ibm/db2/V10.1) ? [yes/no]
no
Enter the full path of the base installation directory:
------------------------------------------------
/opt/db2/product/10.1.0
Specify one of the following keywords to install DB2 products.
AESE
ESE
CONSV
WSE
EXP
CLIENT
RTCL
Enter "help" to redisplay product names.
Enter "quit" to exit.
***********************************************************
CLIENT
***********************************************************
DB2 installation is being initialized.
Total number of tasks to be performed: 31

Total estimated time for all tasks to be performed: 807 second(s)
Task #1 start
Description: Checking license agreement acceptance
Task #1 end
Task #2 start
Description: Base Client Support for installation with root privileges
Task #2 end
Task #3 start
Description: Product Messages - English
Task #3 end.
.
.
.
.
.
The execution completed successfully.
For more information see the DB2 installation log at

"/tmp/db2_install.log.20296".
Results
DB2 Data Server Client client is installed in /opt/db2/product/10.1.0 directory.
Setting up a DB2 instance

A DB2 instance is an environment in which you store data and run applications.
Before you begin
You must have root user authority.

Procedure
Use the db2icrt command to create an instance by using the following steps:
Run the following commands:

cd /opt/db2/product/10.1.0/instance
./db2icrt -s client db2
DB2 catalog settings

About this task
These steps must be performed on every host that has the IBM Data Server Client
installed.
Procedure
1. Log in with the instance user that is db2.
2. Run the following commands:
db2 catalog tcpip node <node_name> remote <DB2_Server_Host> server 60000
db2 catalog db <DB_NAME> at node <node_name>
Note: Provide hostname or IP address of DB2 server in the command instead

of <DB2_Server_Host>.
You can replace the database name (by default, PV) and <node name> in the
command with any string of your choice. For example, NodeA.
Results
When you complete the catalog settings, you might receive the following warning
message:
DB21056W Directory changes may not be effective until the directory cache is refreshed
You can ignore this message.
Copying or overwriting extra lib32 files

You must copy two extra lib32 files after you install the IBM Data Server Client.
These files can be obtained from the installation media, and then copied to the
<DATABASE_HOME>/lib32 directory.
About this task
Copy the libdb2ci.so.1 and libdb2.so.1 files to the <DATABASE_HOME>/lib32

directory.
Procedure
1. Log in as root user and run following commands:
Note: Thelibdb2.so.1 file exists in the <DATABASE_HOME>/lib32 directory. But

you must overwrite with the file from the installation media.
cp <DIST_DIR>/proviso/RHEL/DataBase/RHEL<version_number>/db2/instance/libdb2ci.so.1 <DATABASE_HOM
cp <DIST_DIR>/proviso/RHEL/DataBase/RHEL<version_number>/db2/instance/libdb2.so.1 <DATABASE_HOME>
Where,
The <DIST_DIR> is the directory path where you downloaded the Tivoli
Netcool Performance Manager distribution. For example,/var/tmp/cdproviso/.

The <DATABASE_HOME> is the directory path where you installed IBM Data
Server Client. For example, /opt/db2/product/10.1.0.
2. Create soft links for these files by running the following commands:
ln -s <DATABASE_HOME>/lib32/libdb2ci.so.1 <DATABASE_HOME>/lib32/libdb2ci.so
ln -s <DATABASE_HOME>/lib32/libdb2.so.1 <DATABASE_HOME>/lib32/libdb2.so
Next steps
The steps that follow installation of the prerequisite software.
Once you have installed the prerequisite software, you are ready to begin the
actual installation of Tivoli Netcool Performance Manager. Depending on the type
of installation you require, follow the directions in the appropriate chapter:
v If you are planning on Installing Tivoli Netcool Performance Manager as a
distributed environment that uses clustering for high availability, review the
Tivoli Netcool Performance Manager High Availability documentation, which is
available for download by going to https://www-304.ibm.com/software/
brandcatalog/ismlibrary/details?catalog.label=1TW10NP54 and searching for
"Netcool Proviso High Availability Documentation".

Chapter 6. Installing in a distributed environment
This section describes how to install Tivoli Netcool Performance Manager for the
first time in a fresh, distributed environment.
Note:
v Before installing Tivoli Netcool Performance Manager, ensure if JRE 1.7 is
installed. If this prerequisite is not installed, the Dataview installation actually
fails and the install DataView step incorrectly shows as passed.
For information about installing the Tivoli Netcool Performance Manager

components using a minimal deployment, see Chapter 7, “Installing as a minimal
deployment,” on page 179.
Distributed installation process

The main steps involved in a distributed installation.
A production Tivoli Netcool Performance Manager system that generates and

produces management reports for a real-world network is likely to be installed on
several servers. Tivoli Netcool Performance Manager components can be installed
to run on as few as two or three servers, up to dozens of servers.
The following figure shows the installation flow.

Before installing Tivoli Netcool Performance Manager, you must have installed the
prerequisite software. For detailed information, see Chapter 3, “Installing and
configuring the prerequisite software,” on page 67.
Important: If you are using a Solaris platform for installing Tivoli Netcool
Performance Manager, ensure that Jazz™ for Service Management is either installed
on Linux or AIX systems. Jazz™ for Service Management installation is not
supported on Solaris platform.
In addition, you must have decided how you want to configure your system. Refer
to the following sections:
v “Co-location rules” on page 3
v “Typical installation topology” on page 26
v Appendix A, “Remote installation issues,” on page 235

The general steps used to install Tivoli Netcool Performance Manager are as
follows:
v Start the launchpad.
v Install the Topology Editor.
v Start the Topology Editor.
v Create the topology.
v Add the Tivoli Netcool Performance Manager components.
v Save the topology to an XML file.
v Start the deployer.
v Install Tivoli Netcool Performance Manager using the deployer.
The following sections describe each of these steps in detail.
Note: Before you start the installation, verify that all the database tests have been
performed. Otherwise, the installation might fail. See Chapter 3, “Installing and
configuring the prerequisite software,” on page 67 for information about tnsping.
Starting the Launchpad

The steps required to start the Launchpad.
About this task
To start the Launchpad:
Procedure
1. Log in as root.
2. Set and export the DISPLAY variable.
See “Setting up a remote X Window display” on page 70.
3. Set and export the BROWSER variable to point to your Web browser. For
example:
systems:
# BROWSER=/usr/bin/firefox
# export BROWSER
systems:
# BROWSER=/usr/mozilla/firefox/firefox
# export BROWSER
systems:
# export BROWSER
Note: The BROWSER command cannot include any spaces around the equal
sign.
4. Change directory to the directory where the launchpad resides.
systems:
# cd <DIST_DIR>/ proviso/SOLARIS
systems:
# cd <DIST_DIR>/proviso/AIX
Chapter 6. Installing in a distributed environment 151

systems:
# cd <DIST_DIR>/proviso/RHEL
the Tivoli Netcool Performance Manager distribution.
For more information see “Downloading the Tivoli Netcool Performance
Manager distribution to disk” on page 87.
5. Enter the following command to start the Launchpad:
# ./launchpad.sh
Installing the Topology Editor

The steps that are required to install the Topology Editor.
About this task
Only one instance of the Topology Editor can exist in the Tivoli Netcool
Performance Manager environment. Install the Topology Editor on the same
system that hosts database server.
You can install the Topology Editor from the launchpad or from the command line.
To install the Topology Editor:
Procedure
1. You can begin the Topology Editor installation procedure from the command
line or from the Launchpad.
From the launchpad:
a. On the launchpad, click the Install Topology Editor option in the list of
tasks.
b. On the Install Topology Editor page, click the Install Topology Editor link.
From the command line:
a. Log in as root.
b. Change directory to the directory that contains the Topology Editor
installation script:
systems:
# cd <DIST_DIR>/proviso/SOLARIS/Install/SOL10/topologyEditor/Disk1/InstData/VM
systems:
# cd <DIST_DIR>/proviso/AIX/Install/topologyEditor/Disk1/InstData/VM
systems:
# cd <DIST_DIR>/proviso/RHEL/Install/topologyEditor/Disk1/InstData/VM
<DIST_DIR> is the directory on the hard disk where you copied the
contents of the Tivoli Netcool Performance Manager distribution.
For more information, see “Downloading the Tivoli Netcool Performance
c. Enter the following command:
# ./installer.bin
2. The installation wizard opens in a separate window, displaying a welcome
page. Click Next.

3. Review and accept the license agreement, then click Next.
4. Confirm that the wizard is pointing to the correct directory. The default is
/opt/IBM/proviso. If you have installed the Topology Editor on this system,
the installer does not prompt you for an installation directory and instead
uses the directory where you last installed the application.
5. Select the database from DBMS Selection window.
6. Click Next to continue.
7. Confirm that the wizard is pointing to the correct base installation directory,
or click Choose to browse to another directory. Following are the installation
directories: JDBC driver:
v
/opt/oracle/product/12.1.0-client32/jdbc/lib
v
/opt/db2/product/10.1.0/java
8. Click Next to continue.
9. Review the installation information, then click Install.
10. When the installation is complete, click Done to close the wizard.
The installation wizard installs the Topology Editor and an instance of the
deployer in the following directories:
Interface Directory
Topology Editor install_dir/topologyEditor
For example:
/opt/IBM/proviso/topologyEditor
Deployer install_dir/deployer
For example:
/opt/IBM/proviso/deployer
Results
The combination of the Topology Editor and the deployer is referred to as the
primary deployer.
For more information, see “Resuming a partially successful first-time installation”

on page 177.
Note: To uninstall the Topology Editor, follow the instructions in “Uninstalling the
Topology Editor” on page 230. Do not delete the /opt/IBM directory. Doing so can
cause problems when you try to reinstall the Topology Editor.
If the /opt/IBM directory is accidentally deleted, do the following steps:

1. Change to the /var directory.
2. Rename the hidden file .com.zerog.registry.xml (for example, rename it to
.com.zerog.registry.xml backup).
3. Reinstall the Topology Editor.
4. Rename the backup file to the original name (.com.zerog.registry.xml).

What to do next
Once you have installed Topology Editor, you need to extract the
<DIST_DIR>/license.tar to <install_dir>/license manually.
For example:
$ cp <DIST_DIR>/license.tar /opt/IBM/proviso/license
$ tar -xvf license.tar
Starting the Topology Editor

After you install the Topology Editor, you can start it from either the launchpad or
from the command line.
Procedure
v To start the Topology Editor from the launchpad:
1. If the Install Topology Editor page is not already open, click the Install
Topology Editor option in the list of tasks to open it.
2. On the Install Topology Editor page, click the Start Topology Editor link.
Note: For a non-default installation, you are prompt to enter the path to the
location where the Topology Editor is installed.
v To start the Topology Editor from the command line:
1. Log in as root.
2. Change directory to the directory in which you installed the Topology Editor.
For example:
# cd /opt/IBM/proviso/topologyEditor
# ./topologyEditor
Note: If your DISPLAY environment variable is not set, the Topology Editor
fails with a Java assertion message (core memory dump).
If you are running the Topology Editor for an AIX 6.1 or AIX 7.1
environment, use the command:
# ./topologyEditor -vm /opt/IBM/proviso/topologyEditor/jre/bin/java
Creating a new topology

The steps that are required to create a new topology.
Procedure
1. In the Topology Editor, select Topology > Create new topology.
The New Topology window is displayed.
2. Enter the Number of resources to be managed by Tivoli Netcool Performance
Manager.
Note: Topology size is calculated depending upon the number of resources to

be managed. The default value is 10000. The size of your deployment affects
the database sizing.
3. Click Finish.
The Topology Editor creates the following entities:

v In the Logical view, five items are listed: Tivoli Netcool Performance
Manager Topology, Cross Collector CMEs, DataChannels, DataMarts, and
Dashboard Application Services Hub.
v In the Physical view, there is a new Hosts folder.
Adding and configuring the Tivoli Netcool Performance Manager

components
Your next step is to add and configure the individual Tivoli Netcool Performance
Manager components.
Note: When you install with non-default values, that is, non-default user names,
passwords and locations, it is adviced that you check both the Logical view and
Physical view to ensure that they both contain the correct values before you
proceed with the installation.
Adding the hosts

The first step is to specify all the servers that host Tivoli Netcool Performance
Manager components.
About this task
Each host that you define has an associated property named PV User. PV User is
the default operating system for all Tivoli Netcool Performance Manager
components.
You can override this setting in the Advanced Properties tab when you set the
deployment properties for individual components (for example, DataMart and
DataView). You can install and run different components on the same system as
different users.
Note: DataChannel components always use the default user that is associated with
the host.
The user account that is used to transfer files that are used FTP or SCP/SFTP during
installation is always the PV User that is defined at the host level, rather than
component level.
To add a single host to the topology:
Procedure
1. In the Physical view, right-click the Hosts folder and select Add Host from the
menu. The Add Host window opens.
2. Specify the details for the host computer.
The fields are as follows:
v HOSTNAME - Enter the name of the host (for example, delphi).
v Operating System - Specifies the operating system (for example, SOLARIS).
This field is completed for you.
v Database Home - Specifies the default Oracle or DB2 database home
directory for all Tivoli Netcool Performance Manager components that are
installed on the system:
– The default directory for ORACLE_HOME is /opt/oracle/product/12.1.0-
client32

– The default directory for DB2_HOME is /opt/db2/product/10.1.0
v PV User - Specifies the default Tivoli Netcool Performance Manager UNIX
user (for example, pvuser) for all Tivoli Netcool Performance Manager
components that are installed on the system.
v PV User Password - Specifies the password for the default Tivoli Netcool
Performance Manager user (for example, PV).
v Create Disk Usage Server for this Host? - Selecting this check box creates a
DataChannel subcomponent to handle disk quota and flow control.
If you do not choose to create a Disk Usage Server, click Finish to create the
host. The Topology Editor adds the host under the Hosts folder in the Physical
view. If you choose to create a Disk Usage Server, click Next and the Add Host
window is displayed where you can add details for your Disk Usage Server.
3. Specify the details for the Disk Usage Server.
The fields are as follows:
v Local Root Directory - The local DataChannel root directory. With Local Root
Directory, you can differentiate between a local directory and a remote
directory that is mounted to allow for FTP access.
v Remote Root Directory - Remote directory that is mounted for FTP access.
With Remote Root Directory, you can differentiate between a local directory
and a remote directory that is mounted to allow for FTP access.
v FC FSLL - FC FSLL is the Flow Control Free Space Low Limit property.
When this set limit is reached the Disk Usage Server contacts all components
who reside in this root directory and tell them to free up all space possible.
v FC QUOTA - FC QUOTA is the Flow Control Quota property. This property
allows you to set the amount of disk space in bytes available to Tivoli
Netcool Performance Manager components on this file system.
v Remote User - User account is used when you attempt to access this Disk
Usage Server remotely.
v Remote User Password - User account password is used when you attempt
to access this Disk Usage Server remotely.
v Secure file transfer to be used - Boolean indicator that identifies if ssh must
be used when you attempt to access this directory remotely.
v Port Number - Port number to use for remote access (sftp) in case it is a
non-default port.
Click Finish to create the host. The Topology Editor adds the host under the
Hosts folder in the Physical view.
Note: The DataChannel properties are completed automatically at a later stage.
Adding multiple hosts

You can add multiple hosts at one time.
About this task
To add multiple hosts to the topology:
Procedure
1. In the Physical view, right-click the Hosts folder and select Add Multiple Host
from the menu. The Add Multiple Hosts window opens.
2. Add new hosts by typing their names into the Host Name field as a
comma-separated list.
3. Click Next.
4. Configure all added hosts.
With Configure hosts dialog you can enter configuration settings and apply
these settings to one or more of the specified hosts set.
To apply configuration settings to one or more of the specified host sets:
a. Enter the appropriate host configuration values. All configuration options
are described in Steps 2, and 3 of the previous process, “Adding the hosts”
on page 155.
b. Select the check box opposite each of the hosts to which you want to apply
the entered values.
c. Click Next. The hosts for which all configuration settings that are specified
disappear from the set of selectable hosts.
d. Repeat steps a, b, and c until all hosts are configured.
5. Click Finish.
Adding a database configurations component

The Database Configurations component hosts all the database-specific parameters.
About this task
You define the parameters once, and their values are propagated as needed to the
underlying installation scripts.
To add a Database Configurations component:
Procedure
1. In the Logical view, right-click the Tivoli Netcool Performance Manager
Topology component and select Add Database Configurations from the menu.
The host selection window opens.
2. You must add the Database Configuration component to the same server that
hosts the database server (for example, delphi). Select the appropriate host
using the drop-down list.
3. Click Next to configure the mount points for the database.
4. Add the correct number of mount points.
To add a new mount point, click Add Mount Point. A new, blank row is added
to the window. Fill in the fields as appropriate for the new mount point.
5. Enter the required configuration information for each mount point.
a. Enter the mount point location:
v Mount Point Directory Name, for example:
– /raid_2/oradata
– /raid_2/db2data
Note: The mount point directories can be named using any string as
required by your organizations naming standards.
v Used for Metadata Tablespaces? (A check mark indicates True.)
v Used for Temporary Tablespaces? (A check mark indicates True.)
v Used for Metric Tablespaces? (A check mark indicates True.)
v Used for System Tablespaces and Redo? (A check mark indicates True.)
b. Click Back to return to the original page.
c. Click Finish to create the component.
The Topology Editor adds the new Database Configurations component to the
Logical view.
6. Highlight the Database Configurations component to display its properties.
Review the property values to make sure they are valid. For the complete list
of properties for this component, see the Properties Reference.
The Database Configurations component has the following subelements:
v Channel tablespace configurations
v Database Channels
v Database Clients configurations
v Tablespace configurations
v Temporary tablespace configurations
Note: Before you install Tivoli Netcool Performance Manager, verify that the
following directory structures are created:
v raid_2/oradata and raid_3/oradata
v raid_2/db2data and raid_3/db2data
Adding a DataMart
The steps required to add a DataMart component to your topology.
About this task
Tivoli Netcool Performance Manager DataMart is normally installed on the same

server on which you installed database server and the Tivoli Netcool Performance
Manager database configuration. However, there is no requirement that forces
DataMart to reside on the database server.
Note the following:

v If you are installing DataMart on an AIX system or any remote AIX, Linux or
Solaris system, you must add the IBM JRE to the PATH environment variable for
the Tivoli Netcool Performance Manager UNIX user, pvuser.
v You must ensure you are using the IBM JRE and not the RHEL JRE. The IBM
JRE is supplied with the Topology Editor. To ensure you are using the right JRE
you can either:
– Set the JRE path to conform to that used by the Topology Editor, do this
using the following commands (using the default location for the primary
deployer):
export $PATH
– For a remote server, that is one that does not host the primary deployer, you
must download and install the required JRE, and set the correct JRE path. See
Requirements chapter for JRE download details.
To add a DataMart component:
Procedure
1. In the Logical view, right-click the DataMarts folder and select Add DataMart
from the menu. The host selection host window is displayed.
2. Using the drop-down list of available hosts, select the machine on which
DataMart must be installed (for example, delphi).

3. Click Finish.
The Topology Editor adds the new DataMart x component (for example,
DataMart 1) under the DataMarts folder in the Logical view.
4. Highlight the DataMart x component to display its properties. Review the
property values to make sure they are valid. You can specify an alternate
installation user for the DataMart component by changing the values of the
USER_LOGIN and USER_PASSWORDproperties in the Advanced Properties tab. For
the complete list of properties for this component, see the Database properties
in Properties Reference.
Event notification scripts

When you install the DataMart component, two event notification scripts are
installed.
The scripts are called as needed by tablespace size checking routines in Oracle or
DB2 and in Tivoli Netcool Performance Manager, if either routine detects low disk
space conditions on a disk partition hosting a portion of the Tivoli Netcool
Performance Manager database. Both scripts by default send their notifications by
e-mail to a local login name.
The two files and their installation locations for the two databases are as follows:
v The script installed as $ORACLE_BASE/admin/$ORACLE_SID/bin/notifyDBSpace

notifies the login name oracle by e-mail of impending database space problems.
This script is called as needed by an Oracle routine that periodically checks for
available disk space.
v The script installed as /opt/datamart/bin/notifyDBSpace notifies the login name
pvuser of the same condition. This script is called as needed by the Hourly
Loader component of Tivoli Netcool Performance Manager DataChannel. The
loader checks for available disk space before attempting its hourly upload of
data to the database.
v The script that is installed as $DB2_BASE/tnpm_dbadmin/db2/bin notifies the login

name db2 by email of impending database space problems. This script is called
as needed by a DB2 routine that periodically checks for available disk space.
v The script that is installed as /opt/datamart/bin/notifyDBSpace notifies the
login name pvuser of the same condition. This script is called as needed by the
Hourly Loader component of Tivoli Netcool Performance Manager DataChannel.
The loader checks for available disk space before attempting its hourly upload of
data to the database.
Either file for both databases can be customized to send its warnings to a different
e-mail address on the local machine, to an SMTP server for transmission to a
remote machine, or to send the notices to the local network's SNMP fault
management system (that is, to an SNMP trap manager). You can modify either
script to send notifications to an SNMP trap, instead of, or in addition to its
default e-mail notification.

Adding a Discovery Server
The Discovery Server is the Tivoli Netcool Performance Manager component
responsible for SNMP discovery.
About this task
You can add a discovery server for each DataMart defined in the topology.
To add a Discovery Server:
Procedure
In the Logical view, right-click the DataMart x folder and select Add Discovery
server from the menu.
The Topology Editor displays the new Discovery Server under the DataMart n
folder in the Logical view.
Adding multiple Discovery Servers

The steps required to add multiple Discovery servers.
About this task
If you want to run multiple Discovery servers on multiple hosts in your

environment, you must perform additional steps at deployment to make sure that
each host system contains identical inventory files and identical copies of the
inventory hook script. IBM recommends that you only use identically-configured
instances of the Discovery Server.
The inventory files used by the Discovery Server are configuration files named
inventory_elements.txt and inventory_subelements.txt. These files are located in
the $PVMHOME/conf directory of the system where you install the DataMart
component. Some technology packs provide custom sub-elements inventory files
with names different from inventory_subelements.txt that are also used by the
Discovery Server.
To add multiple Discovery Servers, do the following:
Procedure
v Install the primary instance of DataMart and the Discovery Server on one target
host system.
v Install and configure any required technology packs on the primary host. You
modify the contents of the inventory files during this step.
v Install secondary instances of DataMart and the Discovery Server on
corresponding target host systems.
v Replicate the inventory files from the system where the primary instance of
DataMart is running to the $PVMHOME/conf directory on the secondary hosts. You
must also replicate the InventoryHook.sh script that is located in the
$PVMHOME/bin directory and any other files that this script requires.

Discovering existing Dashboard Application Services Hub
How to update your topology so it sees existing Dashboard Application Services
Hub (DASH) instances on your system.
About this task
To discover existing Dashboard Application Services Hub:
This step runs an asynchronous check for existing Dashboard Application Services
Hub on each selected DataView host. If a Dashboard Application Services Hub is
discovered on a host, the discovered Dashboard Application Services Hub detail is
added to the topology.
Procedure
1. In the Physical view, right-click the Hosts folder and select Add Host from the
menu. Add the host that has an existing Dashboard Application Services Hub
you want to discover.
2. Go to the Logical view, right-click on the DASHs folder and select Import
existing Dashboard Application Services Hubs from host from the menu. The
Run Dashboard Application Services Hub Discovery Wizard Page is
displayed.
3. Select the check box for each host on which you want the Dashboard
Application Services Hub discovery.
4. Enter the value for DASH Installation User and DASH Installation Password.
You can modify this value if you want to do the Dashboard Application
Services Hub installation with non-root user. For example,
DASH_INSTALLATION_USER = ncadmin. For more information about, see Installing
as a root user or non-root user.
5. Click Import DASH.
If the discovered Dashboard Application Services Hub is an old version, it is
flagged within the topology for upgrade.
The deployer takes the appropriate action when run. You find that the
discovered DASH status as "[DASH found on: <host name>]".
6. Click Next.
7. Configure Dashboard Application Services Hub properties.
a. Enter the appropriate host configuration values.
TCR_INSTALLATION_DIRECTORY
The directory in which Tivoli Common Reporting is installed.
DASH_INSTALLATION_DIRECTORY
The directory in which DASH is installed.
Note: The directory that is displayed during installation is a default

directory. Ensure if the directory is correct and modify it accordingly.
WAS_USER_NAME
The WAS user name.
Note: WAS_USER_NAME is the administrator user property. By

default, the value of this property is smadmin. If you change the
value, you must specifically mention it in Configure properties for
multiple DASHs window.

WAS_PASSWORD
The WAS password.
Note: WAS_PASSWORD should be the same as the administration

password set for Jazz for Service Management.
If you would like to configure LDAP for DASH, see Appendix F, “LDAP
integration,” on page 275.
b. Select the check box opposite each of the DASH hosts to which you want to
apply the entered values.
c. Click Next.
The hosts for which all configuration settings are specified disappear from
the set of selectable hosts.
d. Repeat steps a, b, and c until all hosts are configured.
8. Click Next to add the discovered DASHs to the topology.
Note: The Tivoli Netcool Performance Manager user or Proviso user (for
example, pvuser). In a non-root DASH orTivoli Common Reporting and
DataView installation, the value of Tivoli Netcool Performance Manager user or
Proviso user must be the non-root user (for example, ncadmin). For more
information about the Technology Pack/App Pack, refer to Installing and
Configuring Technology Packs.
Adding a DataView
The steps that are required to add DataView components.
About this task
Note: To display DataView real-time charts, you must have the Java runtime
environment (JRE) installed on the browser where the charts are to be displayed.
You can download the JRE from the Oracle and Sun Microsystems download page
at http://www.oracle.com/technetwork/java/javase/downloads/index.html
Note: If you are reusing an existing DASH that was installed by a user other than
root, the default deployment of DataView will encounter problems. To avoid these
problems, you must remove the offending DASH from your topology and add
both the DASH and DataView as a separate post deployment step.
To add a DataView component:
Procedure
In the Logical view, right-click on a DASH and select Add DataView from the
menu. The DataView is automatically added inheriting its properties from the
DASH instance.
Note:
v When you install non-root DataView on remote host, it asks the password of
non-root user.
v Tivoli Netcool Performance Manager Data Provider is installed as part of Tivoli
Netcool Performance Manager 1.4.2 DataView component installation. After you
complete the installation of Tivoli Netcool Performance Manager, see Using Tivoli
Netcool Performance Manager Data Provider 1.4.2 guide to start using the Data
Provider.

Adding the DataChannel administrative components
The steps required to add DataChannel Administrative components.
Procedure
1. In the Logical view, right-click the DataChannels folder and select Add
Administrative Components from the menu. The host selection window opens.
2. Using the drop-down list of available hosts, select the machine that you want
to be the Channel Manager host for your DataChannel configuration (for
example, corinth).
3. Click Finish.
The Topology Editor adds a set of new components to the Logical view:
Channel Manager
Enables you to start and stop individual DataChannels and monitor the
state of various DataChannel programs. There is one Channel Manager
for the entire DataChannel configuration. The Channel Manager
components are installed on the first host you specify.
CORBA Naming Server
Provides near real-time data to DataView.
High Availability Managers
This is mainly used for large installations that want to use redundant
SNMP collection paths. The HAM constantly monitors the availability
of one or more SNMP collection hosts, and switches collection to a
backup host (called a spare) if a primary host becomes unavailable.
Log Server
Used to store user, debug, and error information.
Plan Builder
Creates the metric data routing and processing plan for the other
components in the DataChannel.
Custom DataChannel properties
These are the custom property values that apply to all DataChannel
components.
Global DataChannel properties
These are the global property values that apply to all DataChannel
components.
Adding a DataChannel
A DataChannel is a software module that receives and processes network statistical
information from both SNMP and non-SNMP (BULK) sources.
About this task
This statistical information is then loaded into a database where it can be queried
by SQL applications and captured as raw data or displayed on a portal in a variety
of reports.
Typically, collectors are associated with technology packs, a suite of Tivoli Netcool
Performance Manager programs specific to a particular network device or
technology. A technology pack tells the collector what kind of data to collect on
target devices and how to process that data. See the Technology Pack Installation
Guide for detailed information about technology packs.

To add a DataChannel:
Procedure
DataChannel from the menu. The Configure the DataChannel window is
displayed.
2. Using the drop-down list of available hosts, select the machine that will host
the DataChannel (for example, corinth).
3. Accept the default channel number (for example, 1).
4. Click Finish.
The Topology Editor adds the new DataChannel (for example, DataChannel 1)
to the Logical view.
5. Highlight the DataChannel to display its properties. Note that the DataChannel
always installs and runs as the default user for the host (the Tivoli Netcool
Performance Manager UNIX username, pvuser). Review the other property
values to make sure they are valid. For the complete list of properties for this
component, see the Properties Reference Guide.
The DataChannel has the following subelements:
Daily Loader x
Processes 24 hours of raw data every day, merges it together, then loads
it into the database. The loader process provides statistics on metric
channel tables and metric tablespaces.
Hourly Loader x
Reads files output by the Complex Metric Engine (CME) and loads the
data into the database every hour. The loader process provides statistics
on metric channel tables and metric tablespaces.
The Topology Editor includes the channel number in the element names. For
example, DataChannel 1 would have Daily Loader 1 and File Transfer Engine 1.
Note: When you add DataChannel x, the Problems view shows that the
Input_Components property for the Hourly Loader is blank. This missing value
will automatically be filled in when you add a DataLoad collector (as described
in the next section) and the error will be resolved.
Separating the data and executable directories

You can separate the data and executable directories for your DataChannel
About this task
Note: Separating the data and executable directories is only possible during the
first installation activity. After the installation, you cannot modify the topology to
separate the data and the executable directories.
Do the following, if you want to separate the data and executable directories for
your DataChannel:
Procedure
1. Create two directories on the DataChannel host, for example, DATA_DIR to hold
the data and EXE_DIR to hold the executable.
2. Change the LOCAL_ROOT_DIRECTORY value on that host 's Disk Usage Server to
the data root folder DATA_DIR.

In the Host advanced properties, you see the DATA_DIR value that is propagated
to all DC folder values for the host.
3. Change DC_ROOT_EXE_DIRECTORY to the executable directory EXE_DIR.
This change propagates to the DC configuration directory, the DataChannel Bin
Directory, and the Datachannel executable file name.
Note: For advanced information about DataChannels, see Appendix B,

“DataChannel architecture,” on page 239.
Adding a DataChannel Remote (DCR)

A DataChannel is a software module that receives and processes network statistical
information from both SNMP and non-SNMP (BULK) sources. A DataChannel
remote is A DataChannel installation configuration in which the subchannel, CME
and FTE components are installed and run on one host, while the Loader
components are installed and run on another host.
About this task
In a DataChannel remote configuration, the subchannel hosts can continue

processing data and detecting threshold violations, even while disconnected from
the Channel Manager server.
The following task assumes that we are placing the LDR and DLDR on the current
host, called, for example, hostname1; and that we are placing the subchannel, CME
and FTE, on another host, called, for example, hostname2.
To add a remote DataChannel:
Procedure
1. If it is not already open, open the Topology Editor (see “Starting the Topology
Editor” on page 154).
2. In the Topology Editor, select Topology > Open existing topology. The Open
Topology window is displayed.
3. For the topology source, select From database and click Next.
4. In the Physical View. Add a new host, hostname2, to the downloaded topology.
DataChannel from the menu. The Configure the DataChannel window is
displayed.
6. Using the drop-down list of available hosts, select the computer that hosts the
DataChannel, hostname1.
7. Accept the default channel number (for example, 1).
8. Click Finish.
The Topology Editor adds the new DataChannel (for example, DataChannel2)
to the Logical view.
9. Right-click on the new DataChannel, DataChannel2, and select Add SNMP
Collector.
10. Select server hostname2 as the host.
The Collector 2.2 is added.
11. Right-click on the Complex Metric Engine.2.2 and choose Change Host.
12. Select server hostname2 as the host.
The File Transfer Engine 2.2 is added to hostname2.

Results
The setup must look as follows:

v DataChannel 2 - hostname1
v Collector 2.2 - hostname1
v Collector SNMP - hostname2
v Complex Metric Engine.2.2 - hostname2
v File Transfer Engine 2.2 - hostname2
v Daily Loader 2 - hostname1
v Hourly Loader 2 - hostname1
This accomplishes FTE and CME to be on one server and LDR and DLDR to be on
another server.
Adding a Collector
Collectors collect and process raw statistical data about network devices obtained
from various network resources.
The collectors send the received data through a DataChannel for loading into the
Tivoli Netcool Performance Manager database. Note that collectors do not need to
be on the same machine as the database server and DataMart.
Collector types
Collector types and their description, plus the steps required to associate a
collector with a Technology Pack.
About this task
There are two basic types of collectors:

SNMP collector
Collects data using SNMP polling directly to network services. Specify this
collector type if you plan to install a Tivoli Netcool Performance Manager
SNMP technology pack. These technology packs operate in networking
environments where the associated devices on which they operate use an
SNMP protocol.
Bulk DataLoad collector
Imports data from files. The files can have multiple origins, including log
files generated by network devices, files generated by SNMP collectors on
remote networks, or files generated by a non-Tivoli Netcool Performance
Manager network management database
There are two types of bulk collectors:

UBA A Universal Bulk Adapter (UBA) Collector that handles bulk input files
generated by non-SNMP devices. Specify this collector type if you plan to
install a Tivoli Netcool Performance Manager UBA technology pack,
including Alcatel 5620 NM, Alcatel 5620 SAM, and Cisco CWM.
BCOL A bulk Collector that retrieves and interprets the flat file output of network
devices or network management systems. This collector type is not
recommended for Tivoli Netcool Performance Manager UBA technology
packs, and is used in custom technology packs.

If you are creating a UBA collector, you must associate it with a specific technology
pack. For this reason, IBM recommends that you install the relevant technology
pack before creating the UBA collector. Therefore, you would perform the
following sequence of steps:
Procedure
1. Install Tivoli Netcool Performance Manager, without creating the UBA collector.
2. Download and install the technology pack.
3. Open the deployed topology file to load the technology pack and add the UBA
collector for it.
Note: For detailed information about UBA technology packs and the
installation process, see the Installing and Configuring Technology Packs.
Configure the installed pack by following the instructions in the pack-specific
user's guide.
Restrictions
There are a number of collector restrictions that must be noted.
Note the following restrictions:

v The maximum collector identification number is 999.
v There is no relationship between the channel number and the collector number
(that is, there is no predefined range for collector numbers based on channel
number). Therefore, collector 555 could be attached to DataChannel 7.
v Each database channel can have a maximum of 40 subchannels (and therefore,
40 collectors).
v In Tivoli Netcool Performance Manager, Version 1.4.2 the maximum number of
DataChannels that can be created is increased to 16. In previous version this
number was 8.
v Memory required for each collector is 4 GB.
v The range of port numbers that can be used for the collectors is 3002 to 3999. All
the collectors’ numbers must be unique.
Viewing the list of collectors

Describes the procedure to view the list of collectors.
Procedure
1. Launch DataMart.
2. Click Collector Information from the Monitor tab. This window lists all the
collectors that are loaded from the database.
3. Select a collector from the list, and then click the other tabs to review specific
collector information. The following collector information is available:
Table 17. List of collectors
Column Description
Number Indicates the collector identifier number.
Status Indicates the collector status. For example,
"Running" or "Not Running."
Server Indicates the host name or IP address of the
system on which the collector is installed.
Port Indicates the communication port number
for the collector.

Table 17. List of collectors (continued)
Column Description
Type Indicates the collector type.
Installation Directory Indicates the directory where the collector is
installed.
To view collector information:

4. Click Collector Information from the Monitor tab.
5. Select a collector from the list.
6. Click the Collector Information tab. The State and theActions groups display
all the information about that particular collector.
Creating and adding multiple SNMP collectors

How to create an SNMP collector.
About this task
To add an SNMP collector:
Procedure
1. In the Logical view, right-click the DataChannel x folder.
The pop-up menu lists the following options:
v Add Collector SNMP - Creates an SNMP collector.
v Add Collector UBA - Creates a UBA collector.
v Add Collector BCOL - Creates a BCOL collector. This collector type is used in
custom technology packs. DataMart must be added to the topology before a
BCOL collector can be added.
Select Add Collector SNMP. The Configure Collector window is displayed.
2. Using the drop-down list of available hosts on the Configure Collector window,
select the computer that hosts the collector . (for example, corinth)
3. Accept the default collector number (for example, 1).
The default collector number is seen in the collector number property.
However, you need not accept the collector number. You can edit the collector
number and port number as per your requirement. The collector number
ranges from 1-999 of which 500 and 501 are restricted for other purpose. The
port number ranges from 3002 to 3999 and 3003 by default is the watched
process.
4. Repeat the steps from 2 to 4 for as many SNMP collectors you want to add.
Ensure that the collector number and port number should be unique for all the
SNMP Collectors.
5. Click Finish.
The maximum number of SNMP components (SNMP Collector and SNMP
Spare) on a host is 16.
The Topology Editor displays the new collector under the DataChannel x folder
in the Logical view.
Note: The port number property is not editable in the Topology Editor once it
is selected in the Configure Collector Window. If you want to change the port
number, you must remove the collector from the topology by right-clicking on
it and choosing remove. Then add the collector back and edit the port in the
Configure Collector Window.

6. Highlight the collector to view its properties. The Topology Editor displays
both the SNMP collector core parameters and the SNMP technology
pack-specific parameters. The core parameters are configured with all SNMP
technology packs. You can specify an alternate installation user for the SNMP
collector by changing the values of the pv_user, pv_user_group and
pv_user_password properties in the Advanced Properties tab. Review the
values for the parameters to make sure they are valid.
Important: Irrespective of the number of collectors that you add, the directory
is created only on /opt/dataload.
Note: For information about the core parameters, see Properties Reference.
Results
The collector has two components:

v Complex Metric Engine x - Perform calculations on the collected data.
v File Transfer Engine (FTE) x - Transfers files from the collector's output
directories and places them in the input directory of the CME.
The FTE writes data to the file /var/adm/wtmpx on each system that hosts a
collector. As part of routine maintenance, check the size of this file to prevent it
from growing too large.
Note: Your Solaris version can be configured with strict access default settings for
secure environments. Strict FTP access settings might interfere with automatic
transfers between a DataChannel subchannel and the DataLoad server. Check for
FTP lockouts in /etc/ftpd/ftpusers, and check for strict FTP rules in
/etc/ftpd/ftpaccess.
Note: The Topology Editor includes the channel and collector numbers in the
element names. For example, DataChannel 1 could have Collector SNMP 1.1, with
Complex Metric Engine 1.1. and File Transfer Engine 1.1.
Starting the DataLoad SNMP collector

After you have started the DataChannel components, check every server that hosts
a DataLoad SNMP collector to make sure the collectors are running.
About this task
To check whether a collector is running, run the following command:
ps -ef | grep -i pvmd
If the collector is running, you will see output similar to the following:
pvuser 27118 1 15 10:03:27 pts/4 0:06 /opt/dataload/bin/pvmd –nologo -noherald
/opt/dataload/bin/dc.im -headless -a S
If a collector is not running, perform the following steps:
Procedure
1. Log in to the server that is running Tivoli Netcool Performance Manager SNMP
DataLoad by entering the username and password you specified when
installing SNMP DataLoad..

2. Source the DataLoad environment file by entering the following command:
./$DLHOME/dataLoad.env.
Where $DLHOME is the location where SNMP DataLoad is installed on the system
(/opt/dataload, by default).
Note: If DataLoad shares the same server as DataMart, make sure you unset
the environment variable by issuing the following command from a BASH shell
command line:
unset PV_PRODUCT.
3. Change to the DataLoad bin directory by entering the following command:
cd $PVMHOME/bin.
4. Start a DataLoad SNMP collector using the following command:
pvmdmgr start -i <instance_no>.
To stop the DataLoad SNMP collector, use the following command:
pvmdmgr stop -i <instance_no>.
Note: You will not be able to start or stop the remote collector by using the
PVM user interface. You can use the command line interface instead.
Add a Cross Collector CME

The steps required to add a Cross Collector CME.
Procedure
1. In the Logical view, right-click the Cross Collector CME folder and select Add
Cross Collector CME from the menu. The Specify the Cross Collector CME
details window is displayed.
2. Using the drop-down list of available hosts, select the machine that hosts the
Cross-Collector CME . (for example, corinth)
3. Select the desired Disk Usage Server on the selected host.
4. Select the desired channel number (for example, 1).
5. Click Finish.
The Topology Editor adds the new Cross-Collector CME (for example,
Cross-Collector CME 2000) to the Logical view.
6. Highlight the Cross-Collector CME to display its properties.
Note: The Cross-Collector CME always installs and runs as the default user for
the host (the Tivoli Netcool Performance Manager UNIX username, pvuser).
7. Review the other property values to make sure they are valid. For the complete
list of properties for this component, see the Properties Reference
8. After running the deployer to install the Cross-Collector CME you will need to
restart the CMGR process.
Note: You notice that dccmd start all does not start the Cross-Collector CME at
this point.
9. You must first deploy a formula against the Cross-Collector CME using the
DataChannel frmi tool.
Run the frmi tool. The following is an example command:
frmi ecma_formula.js -labels formula_labels.txt
Where:
v The format of formula_labels.txt is 2 columns separated by an "=" sign.
v First column is Full Path to formula.

v Second is the number of the Cross-Collector CME.
v The file formula_labels.txt is of the format:
Path_to_ECMA_formulas~Formula1Name=2000
Path_to_ECMA_formulas~Formula2Name=2001
Note: When a Cross-Collector CME (CC-CME) is installed on the system and

formulas are applied against it, the removal of collectors that the CC-CME
depends on is not supported. This is an exceptional case, that is, if you have
not installed a CC-CME, collectors can be removed.
Adding multiple Cross Collectors

About this task
To add multiple Cross Collectors:
Procedure
1. In the Logical view, right-click the Cross Collector CME folder and select Add
multiple Cross Collectors from the menu. The Add Cross Collector CME
window is displayed.
2. (Optional) Click Add Hosts to add to the set of Cross Collector hosts. Only
hosts that have a DUS can be added.
Note: It is recommended that you have 20 Cross Collector CMEs spread across
the set of topology hosts.
3. Set the number of Cross Collector CMEs for the set of hosts, there are two ways
you can do this:
v Click Calculate Defaults to use the wizard to calculate the recommended
spread across the added hosts. This sets the number of Cross Collector CMEs
to the default value.
v To manually set the number of cross collector for each host, use the
drop-down menu opposite each host name.
4. Click Finish.
Saving the topology

When you are satisfied with the infrastructure, verify that all the property values
are correct and that any problems have been resolved, then save the topology to an
XML file.
About this task
To save the topology as an XML file:
Procedure
1. In the Topology Editor, select Topology then either Save Topology As or Save
Topology.
Click Browse to navigate to the directory in which to save the file. By default,
the topology is saved as topology.xml file in the topologyEditor directory.
2. Accept the default value or choose another name or location, then click OK to
close the file browser window.
3. The file name and path is displayed in the original window. Click Finish to
save the file and close the window.

You are now ready to deploy the topology file (see “Starting the Deployer”).
Note: Until you actually deploy the topology file, you can continue making
changes to it as needed by following the directions in “Opening an existing
topology file.”
See Chapter 8, “Modifying the current deployment,” on page 187 for more
information about making changes to a deployed topology file.
Note: Only when you begin the process of deploying a topology is it saved to
the database. For more information, see “Deploying the topology” on page 174.
Opening an existing topology file

As you create the topology, you can save the file and update it as needed.
About this task
To open a topology file that exists but that has not yet been deployed:
Procedure
3. For the topology source, click local then use Browse to navigate to the correct
directory and file. Once you have selected the file, click OK. The selected file is
displayed in the Open Topology window.
Click Finish.
The topology is displayed in the Topology Editor.
4. Change the topology as needed.
Starting the Deployer

The primary deployer is installed on the same machine as the Topology Editor. You
first run the topology file on the primary deployer, and then run secondary
installers on the other machines in the distributed environment.
See “Resuming a partially successful first-time installation” on page 177 for more
information about the difference between primary and secondary deployers.
Note: Before you start the deployer, verify that all the database tests have been
configuring the prerequisite software,” on page 67 for more information.

Primary Deployer
The steps that are required to run the primary deployer from the Topology Editor
Procedure
Click Run > Run Deployer for Installation.
Note: When you use the Run menu options (install or uninstall), the deployer uses
the last saved topology file, not the current one. Be sure to save the topology file
before you use a Run command.
Secondary Deployers
A secondary deployer is only required if remote installation using the primary
deployer is not possible.
About this task
For more information on why you may need to use a secondary deployer, see
Appendix A, “Remote installation issues,” on page 235.
To run a secondary deployer:
Procedure
v To run a secondary deployer from the launchpad:
1. On the launchpad, click Start the Deployer.
2. On the Start Deployer page, click the Start Deployer link.
v To run a secondary deployer from the command line:
1. Log in as root.
2. Change to the directory containing the deployer within the downloaded
Tivoli Netcool Performance Manager distribution:
systems:
# cd <DIST_DIR>/proviso/SOLARIS/Install/SOL10/deployer/
systems:
# cd <DIST_DIR>/proviso/AIX/Install/deployer/
systems:
# cd <DIST_DIR>/proviso/RHEL/Install/deployer/
<DIST_DIR> is the directory on the hard drive where you copied the contents
of the Tivoli Netcool Performance Manager distribution in “Downloading the
Tivoli Netcool Performance Manager distribution to disk” on page 87.
# ./deployer.bin
Note: See Appendix D, “Deployer CLI options,” on page 259 for the list of
supported command-line options.

Pre-deployment check
The Deployer fails if the required patches listed in this file are not installed.
About this task
The Deployer performs a check on the operating system versions and that the
minimum required packages are installed. The Deployer checks for the files as
listed in the relevant check_os.ini file.
The check_os.ini can be found at:
v The check_os.ini file detailing Solaris requirements can be found

at:
/SOLARIS/Install/SOL10/deployer/proviso/bin/Check/check_os.ini
v The check_os.ini file detailing AIX requirements can be found at:

/AIX/Install/deployer/proviso/bin/Check/check_os.ini
v The check_os.ini file detailing Linux requirements can be found

at:
/RHEL/Install/deployer/proviso/bin/Check/check_os.ini
Procedure
v To check if the required packages are installed:
1. Click Run > Run Deployer for Installation to start the Deployer.
2. Select the Check prerequisites check box.
3. Click Next.
The check returns a failure if any of the required files are missing.
v To repair a failure:
1. Log in as root.
2. Install the packages listed as missing.
3. (Linux only) If any motif package is listed as missing:
Install the missing motif package and update the package DB using the
command:
# updatedb
4. Rerun the check prerequisites step.
Deploying the topology

How to deploy your defined topology.
About this task
The deployer displays a series of pages to guide you through the Tivoli Netcool
Performance Manager installation. The installation steps are displayed in a table,
you can run each step individually or to run all the steps at a time. For more
information about the deployer interface, see “Primary Deployer” on page 173.
Important: By default, Tivoli Netcool Performance Manager uses Monday to

determine when a new week begins. If you want to specify a different day, you
must change the FIRST_WEEK_DAY parameter in the Database Registry using the
dbRegEdit utility. This parameter can be changed only when you first deploy the
topology that installs your Tivoli Netcool Performance Manager environment, and

it must be changed BEFORE the Database Channel is installed. For more
information, see the Tivoli Netcool Performance Manager Registry and Space
Management Tech Note. If you must stop the installation, you can resume it later.
For more information, see “Resuming a partially successful first-time installation”
on page 177.
To deploy the Tivoli Netcool Performance Manager topology:
Procedure
1. The deployer opens, displaying a welcome page. Click Next to continue.
2. If you started the deployer from the launchpad or from the command line,
enter the full path to your topology file, or click Choose to navigate to the
correct location. Click Next to continue.
Note: If you start the deployer from within the Topology Editor, this step is
skipped.
The database access window prompts for the security credentials.
3. Enter the host name (for example, delphi) and database administrator
password (for example, PV), and verify the other values (port number, SID, and
user name). If the database does not yet exist, these parameters must match the
values you specified when you created the database configuration component
(see “Adding a database configurations component” on page 157). Click Next
to continue.
4. The node selection window shows the target systems and how the files are
transferred (see “Secondary Deployers” on page 173 for an explanation of this
window). The table has one row for each computer where at least one Tivoli
Netcool Performance Manager component is installed.
The default settings are as follows:
v The Enable check box is selected. If this option is not selected, no actions are
performed on that computer.
v If selected scripts are run to verify that the prerequisite software is installed,
the Check prerequisites check box is not selected.
v Remote execution is enabled, by using both RSH and SSH.
If remote execution cannot be enabled due to a particular customer 's
security protocols, see Appendix A, “Remote installation issues,” on page 235
and “Resuming a partially successful first-time installation” on page 177.
v File transfer by using FTP is enabled.
If wanted, reset the values as appropriate for your deployment.
Click Next to continue.
5. Provide media location details.
The Tivoli Netcool Performance Manager Media Location for components
window is displayed, listing component and component platform.
a. Click Choose the Proviso Media. You are asked to provide location of the
media for each component.
b. Enter the base directory in which your media is located. If any of the
component media is not within the directory that is specified, you are asked
to provide media location detail for that component.
6. Click Run All to run all the steps in sequence.
7. The deployer prompts you for the location of the setup files. Use the file
selection window to navigate to the top-level directory for your operating
system to avoid further prompts.

For example:
<DIST_DIR>/RHEL/
the Tivoli Netcool Performance Manager distribution in “Downloading the
Tivoli Netcool Performance Manager distribution to disk” on page 87.
Note: This assumes that the Tivoli Netcool Performance Manager distribution
was downloaded to the folder /var/tmp/cdproviso as per the instructions in
“Downloading the Tivoli Netcool Performance Manager distribution to disk” on
page 87.
If Dataview is configured to install on a remote host, the Run Remote DASH
Install step is included. This step prompts the user to enter the root password.
The deployer requires this information in order to run as root on the remote
host and perform the Dataview installation.
8. When all the steps are completed successfully, click Done to close the wizard.
Note: During Tivoli Netcool Performance Manager installation process, DASH

password will be added into /tmp/ProvisoConsumer/log.txt. For best practice,
please remove the /tmp/ProvisoConsumer directory or keep a backup of this
directory for reference purposes but make sure this backup folder is secured.
Next steps
The steps to perform after deployment.
Installing and configuring a technology pack and other post

installation tasks
The next step is to install the technology packs, as described in Installing and
configuring a technology pack.
Once you have created the topology and installed Tivoli Netcool Performance
Manager, it is very easy to make changes to the environment. Simply open the
deployed topology file (loading it from the database), make your changes, and run
the deployer with the updated topology file as input. For more information about
performing incremental installations, see Chapter 8, “Modifying the current
deployment,” on page 187.
Note: After your initial deployment, always load the topology file from the
database to make any additional changes (such as adding or removing a
component), because it reflects the current status of your environment. Once you
have made your changes, you must deploy the updated topology so that it is
propagated to the database. To make any subsequent changes following this
deployment, you must load the topology file from the database again.
To improve performance, IBM recommends that you regularly compute the

statistics on metadata tables. You can compute these statistics by creating a cron
entry that executes the dbMgr (Database Manager Utility) analyzeMetaDataTables
command at intervals.
The following example shows a cron entry that checks statistics every hour at 30
minutes past the hour. Note that the ForceCollection option is set to N, so that
statistics will only be calculated when the internal calendar determines that it is
necessary, and not every hour:

0 5 * * * [ -f /opt/DM/dataMart.env ] && [ -x /opt/DM/bin/dbMgr ] && .
/opt/DM/dataMart.env && dbMgr analyzeMetaDataTables A N
For more information on dbMgr and the analyzeMetaDataTables command, see the
Tivoli Netcool Performance Manager IBM Tivoli Netcool Performance Manager:
Database Administration Guide.
For each new SNMP DataLoad, change the env file of the Tivoli Netcool
Performance Manager user to add the directory with the openssh libcrypto so to
the LD_LIBRARY_PATH (or LIBPATH).
Resuming a partially successful first-time installation

If your installation fails due to some reason, you can resume the installation
process.
About this task
In this scenario, you try deploying a Tivoli Netcool Performance Manager topology
for the first time. You define the topology and start the installation. Although some
of the components of the Tivoli Netcool Performance Manager topology are
installed successfully, the overall installation does not complete successfully.
It addition, it is possible to skip a section of the installation. For example, a remote

node might not be accessible for some reason. After you skip this portion of the
installation, resume the installation to continue with the remaining steps. The
deployer lists only those steps that are needed to complete the installation on the
missing node.
For example, suppose that during the first installation, database is not running, so
the database check failed. Stop the installation and start the database, then resume
the installation.
To resume a partial installation:
Procedure
1. After you have corrected the problem, restart the deployer by using the
following command:
a. Log in as root.
b. Change directory to the directory that contains the deployer. For example:
# cd /opt/IBM/proviso/deployer
c. Enter the following command:
# ./deployer.bin -Daction=resume
If you use the resume option, you can resume the installation exactly where you
left off.
Note: If you are asked to select a topology file to resume your installation,
select the topology file that you saved before you begin the installation.
3. Accept the default location of the base installation directory of database JDBC
driver:
Oracle /opt/oracle/product/12.1.0-client32
DB2 /jdbc/lib, /opt/db2/product/10.1.0.

Or, click Choose to navigate to another directory. Click Next to continue.
4. The steps page shows the installation steps in the same state they were in when
you stopped the installation (with the completed steps marked Success, the
failed step marked Error, and the remaining steps marked Held).
5. Select the step that previously failed, reset it to Ready, then click Run Next.
Verify that this installation step now completes successfully.
6. Run any remaining installation steps, verifying that they complete successfully.
7. At the end of the installation, the deployer loads the updated topology
information into the database.

Chapter 7. Installing as a minimal deployment
Describes how to install Tivoli Netcool Performance Manager as a minimal
deployment.
Overview
A minimal deployment installation is used primarily for demonstration or
evaluation purposes, and installs the product on the smallest number of machines
possible, with minimal user input.
When you perform a minimal deployment installation, the Tivoli Netcool

Performance Manager components are installed on the server you are running the
deployer from.
Before you begin

Before installing Tivoli Netcool Performance Manager, you must have installed the
prerequisite software.
For detailed information, see Chapter 3, “Installing and configuring the prerequisite
software,” on page 67.
Note: Before you start the installation, verify that all the database tests have been
configuring the prerequisite software,” on page 67 for information about tnsping.
If you are setting up a demonstration or evaluation system, it is possible to install

all Tivoli Netcool Performance Manager components on a single server for Linux,
Solaris or AIX systems. In this case your installation process will go as follows:

Special consideration
By default, Tivoli Netcool Performance Manager uses Monday to determine when
a new week begins.
If you wish to specify a different day, you must change the FIRST_WEEK_DAY
parameter in the Database Registry using the dbRegEdit utility. This parameter can
only be changed when you first deploy the topology that installs your Tivoli
Netcool Performance Manager environment, and it must be changed BEFORE the
Database Channel is installed. For more information, see the Tivoli Netcool
Performance Manager Database Administration Guide.
No resume of partial install available

There is no resume functionality available to a minimal deployment installation.
As a result a minimal deployment installation must be carried out in full if it is to

be attempted.
Overriding default values

When performing a minimal deployment installation you must accept all default
values. The exceptions are listed in this section.
The exceptions to this are:

v Location of the database jdbc driver.
The default is /opt/oracle/product/12.1.0/jdbc/lib
The default is /opt/db2/product/10.1.0/java

v Tivoli Netcool Performance Manager installation destination folder.
The default is /opt/proviso
v server parameters. The defaults are:

– Oracle Base: /opt/oracle
– Oracle home: /opt/oracle/product/12.1.0-client32
– Oracle Port: 1521
v server parameters. The defaults are:

– DB2 Base:/opt/db2
– Database Home:/opt/db2/product/10.1.0
– DB2 Port: 60000

Installing a minimal deployment
This section provides step-by-step instructions for installing Tivoli Netcool
Performance Manager on a single Solaris, AIX or Linux server.
Starting the Launchpad

The steps required to start the Launchpad.
About this task
To start the Launchpad:
Procedure
1. Log in as root.
2. Set and export the DISPLAY variable.
See “Setting up a remote X Window display” on page 70.
3. Set and export the BROWSER variable to point to your Web browser. For
example:
systems:
# export BROWSER
systems:
# BROWSER=/usr/mozilla/firefox/firefox
# export BROWSER
systems:
# export BROWSER
Note: The BROWSER command cannot include any spaces around the equal
sign.
4. Change directory to the directory where the launchpad resides.
systems:
# cd <DIST_DIR>/ proviso/SOLARIS
systems:
# cd <DIST_DIR>/proviso/AIX
systems:
# cd <DIST_DIR>/proviso/RHEL
the Tivoli Netcool Performance Manager distribution.
For more information see “Downloading the Tivoli Netcool Performance
5. Enter the following command to start the Launchpad:
# ./launchpad.sh
Chapter 7. Installing as a minimal deployment 181

Start the installation
Steps required to install.
About this task
A minimal deployment installation uses a predefined topology file.
To start the installation:
Procedure
1. On the launchpad, click the Install Tivoli Netcool Performance Manager for
Minimal Deployment option in the list of tasks, then click the Install Tivoli
Netcool Performance Manager 1.4.2 for Minimal Deployment link to start the
deployer.
Alternatively, you can start the deployer from the command line, as follows:
a. Log in as root.
b. Set and export your DISPLAY variable (see “Setting up a remote X
Window display” on page 70).
c. Change directory to the directory that contains the deployer:
systems:
# cd <DIST_DIR>/proviso/SOLARIS/Install/SOL10/deployer
systems:
# cd <DIST_DIR>/proviso/AIX/Install/deployer
systems:
# cd <DIST_DIR>/proviso/RHEL/Install/deployer
d. Enter the following command:
# ./deployer.bin -Daction=poc -DPrimary=true
3. Accept the terms of the license agreement, then click Next.
4. Accept the default location of the base installation directory of the JDBC
driver:
/opt/oracle/product/12.1.0-client32/jdbc/lib)
or click Choose to navigate to another directory. Click Next to continue.

5. The deployer prompts for the directory in which to install Tivoli Netcool
Performance Manager. Accept the default value (/opt/proviso) or click
Choose to navigate to another directory. Click Next to continue.
6. Verify the following additional information about the database:
Base
The base directory for the Oracle installation (for example,
/opt/oracle). Accept the provided path or click Choose to navigate to
another directory.

Base
The base directory for the DB2 installation (for example, /opt/db2).
Accept the provided path or click Choose to go to another directory.
Database Home
The root directory of the database /opt/oracle/product/12.1.0-
client32)
The root directory of the database /opt/db2/product/10.1.0'

v Accept the provided path or click Choose to navigate to another directory.
v Port: The port used for Oracle communications. The default

value is 1521.
v Port: The port that is used for DB2 communications. The

value is 60000.
7. The node selection window shows the target system and how the files will be
transferred. These settings are ignored for a minimal deployment installation
because all the components are installed on a single server.
8. Provide media location details. The Tivoli Netcool Performance Manager
Media Location for components window is displayed, listing component and
component platform.
a. Click Choose the Proviso Media. You will be asked to provide location of
the media for each component.
b. Enter the base directory in which your media is located. If any of the
component media is not within the directory specified, you will be asked
to provide media location detail for that component.
9. The deployer displays summary information about the installation. Review the
information, then click Next to begin the installation.
The deployer displays the table of installation steps (see “Pre-deployment
check” on page 174 for an overview of the steps table). Note the following:
v If an installation step fails, see Appendix H, “Error codes and log files,” on
page 283 for debugging information. Continue the installation by following
the instructions in “Resuming a partially successful first-time installation”
on page 177
v Some of the installation steps can take a long time to complete. However, if
an installation step fails, it will fail in a short amount of time.
10. Click Run All to run all the steps in sequence.
11. When all the steps have completed successfully, click Done to close the
wizard.
12. Run chmod -R 777 on /opt/IBM/tivoli in order to make all files in the
Dashboard Application Services Hub directory structure accessible.
Your installation is complete. See “The post-installation script” on page 184 for
information about the post-installation script, or “Next steps” on page 184 for
what to do next.

The post-installation script
The post-installation script is run automatically when installation is complete.
About this task
For a minimal deployment the script performs four actions:
Procedure
1. Starts the DataChannel.
2. Starts the DataLoad SNMP Collector, if it is not already running.
3. Creates a DataView user named tnpm.
4. Gives the poc user permission to view reports under the NOC Reporting group,
with the default password of tnpm.
Results
The script writes a detailed log to the file /var/tmp/poc-post-

install.${TIMESTAMP}.log.
Next steps
The steps to be performed following the deployment of your system.
When the installation is complete, you are ready to perform the final configuration
tasks that enable you to view reports on the health of your network. These steps
are documented in detail in the Tivoli Netcool Performance Manager
documentation set.
For each new SNMP DataLoad, change the env file of the Tivoli Netcool
Performance Manager user to add the directory with the openssh libcrypto.so to
the LD_LIBRARY_PATH (or LIBPATH).
Download the MIB-II files

The minimal deployment version installs the MIB-II Technology Pack.
About this task
Before beginning the installation, you must download both the Technology Pack
Installer and the MIB-II jar files.
To download these files, access either of the following distributions:
Procedure
v The product distribution site: https://www-112.ibm.com/software/howtobuy/
softwareandservices
Located on the product distribution site are the ProvisoPackInstaller.jar file,
the bundled jar file, and individual stand-alone technology pack jar files.
v (Optional) The Tivoli Netcool Performance Manager CD distribution, which
contains the ProvisoPackInstaller.jar file and the jar files for the Starter Kit
components.
See your IBM customer representative for more information about obtaining
software.

Note: Technology Pack Installer and the MIB-II jar files must be in the same
directory (for example, AP), and no other application jar files should be present,
if there are any more jars in that folder the installation step will fail due to "too
many jars" in the specified folder. In addition, you must add the AP directory to
the Tivoli Netcool Performance Manager distribution's directory structure.

Chapter 8. Modifying the current deployment
Describes how to modify an installation of Tivoli Netcool Performance Manager.
It is possible to modify Tivoli Netcool Performance Manager after it has been

installed. To add, delete or upgrade components, load the deployed topology from
the database, make your changes, and run the deployer with the updated topology
as input.
Note: You must run the updated topology through the deployer in order for your
changes to take effect.
Note the following:

v After your initial deployment, always load the topology from the database to
make any additional changes (such as adding or removing a component),
because it reflects the current status of your environment. Once you have made
your changes, you must deploy the updated topology so that it is propagated to
the database. To make any subsequent changes following this deployment, you
must load the topology from the database again.
v You might have a situation where you have modified a topology by both adding
new components and removing components (marking them "To Be Removed").
However, the deployer can work in only one mode at a time - installation mode
or uninstallation mode. In this situation, first run the deployer in uninstallation
mode, then run it again in installation mode.
For information about deleting components from an existing topology, see

“Removing a component from the topology” on page 225.
Migrating between platforms
It is possible to migrate components between platforms when performing the

Tivoli Netcool Performance Manager upgrade.
The only supported migration path is from Solaris to AIX. There is no support for
any other platform migration scenario.
Opening a deployed topology

Once you have installed Tivoli Netcool Performance Manager, you can perform
incremental installations by modifying the topology that is stored in the database.
About this task
You retrieve the topology, modify it, then pass the updated data to the deployer.
When the installation is complete, the deployer stores the revised topology data in
the database.

To open a deployed topology:
Procedure
3. For the topology source, select and click Next.
4. Verify that all of the fields for the database connection are filled in with the
correct values:
Database hostname
The name of the database host. The default value is localhost.
Port
The port number used for communication with the database. The
default value is 1521.
The port number used for communication with the database. The
default value is 60000.
Database user
The user name used to access the database. The default value is
PV_INSTALL
Database Password
The password for the database user account. For example, PV.
DB Name
The SID for the database. The default value is PV.
The name of database. The default value is PV.

If desired, click Save as defaults to save these values for future incremental
installations.
5. Click Finish.
Results
The topology is retrieved from the database and is displayed in the Topology
Editor.
Adding a new component

After you have deployed your topology, you might need to make changes to it.
About this task
For example, you might want to add another SNMP collector.
To add a new component to the topology:

Procedure
2. Open the existing topology (see “Opening a deployed topology” on page 187).
3. In the Logical view of the Topology Editor, right-click the folder for the
component you want to add.
4. Select Add XXX from the pop-up menu, where XXX is the name of the
component you want to add.
5. The Topology Editor prompts for whatever information is needed to create the
component. See the appropriate section for the component you want to add:
v “Adding the hosts” on page 155
v “Adding a database configurations component” on page 157
v “Adding a DataMart” on page 158
v “Adding a Discovery Server” on page 160
v “Discovering existing Dashboard Application Services Hub” on page 161
v “Adding a DataView” on page 162
v “Adding the DataChannel administrative components” on page 163
v “Adding a DataChannel” on page 163
v “Adding a Collector” on page 166
Note: that if you add a collector to a topology that has already been
deployed, you must manually bounce the DataChannel management
components (cnsw, logw, cmgrw, amgrw). For more information, see “Manually
starting the Channel Manager programs” on page 244.
v “Creating and adding multiple SNMP collectors” on page 168
v “Adding a Discovery Server” on page 160
6. The new component is displayed in the Logical view of the Topology Editor.
7. Save the updated topology. You must save the topology after you add the
component and before you run the deployer. This step is not optional.
8. Run the deployer (see “Starting the Deployer” on page 172), passing the
updated topology as input.
The deployer can determine that most of the components described in the
topology are already installed, and installs only the new component.
9. When the installation ends successfully, the deployer uploads the updated
topology into the database.
For information about removing a component from the Tivoli Netcool
Performance Manager environment, see “Removing a component from the
topology” on page 225.
Example
In this example, you update the installed version of Tivoli Netcool Performance
Manager to add a new DataChannel and two SNMP DataLoaders to the existing
system.
To update the Tivoli Netcool Performance Manager installation:

3. In the Logical view of the Topology Editor, right-click the DataChannels folder.
Chapter 8. Modifying the current deployment 189

4. Select Add Data Channel from the pop-up menu. Following the directions in
“Adding a DataChannel” on page 163, add the following components:
a. Add a new DataChannel (Data Channel 2) with two different SNMP
DataLoaders to the topology. The Topology Editor creates the new
DataChannel.
b. Add two SNMP collectors to the channel structure created by the Topology
Editor. The editor automatically creates a Daily Loader component, an
Hourly Loader component, and two Sub Channels with an FTE component
and a CME component.
5. Save the updated topology.
topology are already installed, and installs only the new components (in the
example, DataChannel 5 with two new subchannels and DataLoaders).
7. When the installation ends, successful or not, the deployer uploads the updated
topology into the database.
Changing configuration parameters of existing Tivoli Netcool

Performance Manager components
Configuration information is stored in the database. This enables the
DataChannel-related components to retrieve the configuration from the database at
run time.
You set the configuration information using the Topology Editor. As with the other
components, if you make changes to the configuration values, you must pass the
updated topology data to the deployer to have the changes propagated to both the
environment and the database.
Note: After the updated configuration has been stored in the database, you must
manually start, stop, or bounce the affected DataChannel component to have your
changes take effect.
Moving components to a different host

You can use the Topology Editor to move components between hosts.
About this task
You can move all components between hosts when they have not yet been
installed and are in the configured state. You can move SNMP and UBA collectors
when they are in the configured state or after they have been deployed and are in
the installed state.
If the component in the topology has not yet been deployed and is in the
configured state, the Topology Editor provides a Change Host option in the
pop-up menu when you click the component name in the Logical view. This
option allows you to change the host associated with the component prior to
deployment.
If the component is an SNMP or UBA collector that was previously deployed and
is in the installed state, the Topology Editor provides a Migrate option in the

pop-up menu. This option instructs the deployer to uninstall the component from
the previous host and re-install it on the new system.
For instructions on moving deployed SNMP and UBA collectors after deployment,
see “Moving a deployed collector to a different host.” For instructions on moving
components that have not yet been deployed, see the information below.
Note: The movement of installed DataChannel Remote components is not

supported. All other components can be moved.
To change the host associated with a component before deployment:
Procedure
1. Start the Topology Editor (if it is not already running) and open the topology
that includes the component's current host (see “Starting the Topology Editor”
on page 154 and “Opening a deployed topology” on page 187).
2. In the Logical view, navigate to the name of the component to move.
3. Right-click the component name, then click Change Host from the pop-up
menu.
The Migrate Component dialog appears, containing a drop-down list of hosts
where you can move the component.
4. Select the name of the new host from the list, then click Finish.
The name of the new host appears in the Properties tab.
Moving a deployed collector to a different host

You can move a deployed SNMP or UBA collector to a different host. The
instructions for doing so differ for SNMP collectors and UBA collectors.
After you move a collector to a new host, it may take up to an hour for the change
to be registered in the database.
Moving a deployed SNMP collector (scenario 1)

The steps required to move a deployed SNMP collector to a different host if
collector is the last SNMP collector on original host.
About this task
Note: To avoid the loss of collected data, leave the collector running on the
original host until you complete Step 7 on page 108.
To move a deployed SNMP collector to a different host then follow these steps:
Procedure
that includes the collector's current host (see “Starting the Topology Editor” on
page 154 and “Opening a deployed topology” on page 187).
2. In the Logical view, navigate to the name of the collector to move. For example
if moving SNMP 1.1, navigate as follows:
DataChannels > DataChannel 1 > Collector 1.1 > Collector SNMP.1.1
3. Right-click the collector name (for example, Collector SNMP 1.1), then click
Migrate from the pop-up menu.

The Migrate Collector dialog appears, containing a drop-down list of hosts
where you can move the collector.
Note: If you are moving a collector that has not been deployed, select Change
host from the pop-up menu (Migrate is grayed out). After the Migrate Collector
dialog appears, continue with the steps below.
In the Physical view, the status of the collector on the new host is Configured.
The status of the collector on the original host is To be uninstalled. You will
remove the collector from the original host in Step 9.
Note: If you are migrating a collector that has not been deployed, the name of
the original host is automatically removed from the Physical view.
5. Click Topology > Save Topology to save the topology data.
6. Click Run > Run Deployer for Installation to run the deployer, passing the
updated topology as input. For more information on running the deployer, see
“Starting the Deployer” on page 172.
The deployer installs the collector on the new host and starts it.
Note: Both collectors are now collecting data - the original collector on the
original host, and the new collector on the new host.
7. Before continuing with the steps below, note the current time, and wait until a
time period equivalent to two of the collector's collection periods elapses.
Doing so guards against data loss between collections on the original host and
the start of collections on the new host.
Because data collection on the new host is likely to begin sometime after the
first collection period begins, the data collected during the first collection
period will likely be incomplete. By waiting for two collection time periods to
elapse, you can be confident that data for one full collection period will be
collected.
The default collection period is 15 to 30 minutes. You can find the collection
period for the sub-element, sub-element group, or collection formula associated
with the collector in the DataMart Request Editor. For information on viewing
and setting a collection period, see the Configuring and Operating DataMart.
8. Bounce the FTE for the collector on the collector's new host, as in the following
example:
./dccmd bounce FTE.1.1
The FTE now recognizes the collector's configuration on the new host, and will
begin retrieving data from the collector's output directory on the new host.
9. In the current Topology Editor session, click Run > Run Deployer for
Uninstallation. Remove the collector from original host and save the topology.
Run deployer for Uninstallation.
Note: This step is not necessary if you are moving a collector that has not been
deployed.
Moving a deployed SNMP collector (scenario 2)

The steps required to move a deployed SNMP collector to a different host if
collector is not the last SNMP collector on original host.
About this task
To move a deployed SNMP collector to a different host then follow these steps:

Procedure
2. In the Logical view, navigate to the name of the collector to move. For example
if moving SNMP 1.1, navigate as follows:
DataChannels > DataChannel 1 > Collector 1.1 > Collector SNMP.1.1
3. Right-click the collector name (for example, Collector SNMP 1.1), then click
Migrate from the pop-up menu.
Note: If you are moving a collector that has not been deployed, select Change
host from the pop-up menu (Migrate is grayed out). After the Migrate Collector
dialog appears, continue with the steps below.
4. Select the name of new host from list, and then click Finish. In the Physical
view, the status of collector on the new host is configured.
The deployer installs the collector on the new host and starts it.
Note: Both collectors are now collecting data - the original collector on the
original host, and the new collector on the new host.
7. Bounce the FTE for the collector on the collector's new host, as in the following
example:
./dccmd bounce FTE.1.1
The FTE now recognizes the collector's configuration on the new host, and will
begin retrieving data from the collector's output directory on the new host.
Note: There is no need to click Run Deployer for Uninstallation in this case.
Moving a deployed SNMP collector to or from a HAM

environment
If you move a deployed SNMP collector into or out of a High Availability Manager
(HAM) environment, you must perform the steps in this section.
About this task
To move a deployed SNMP collector to or from a HAM environment:
Procedure
1. Move the collector as described in “Moving a deployed SNMP collector
(scenario 1)” on page 191.
Note: If you are moving a spare collector out of the HAM environment, the
navigation path is different than the path shown in Step 2 of the above
instructions. For example, suppose you have a single HAM environment with a
cluster MyCluster on host MyHost, and you are moving the second SNMP
spare out of the HAM. The navigation path to the spare would be as follows:

DataChannels > Administrative Components > High Availability Managers >
HAM MyServer.1 > MyCluster > Collector Processes > Collection Process
SNMP Spare 2.
2. Log in as Tivoli Netcool Performance Manager UNIX user, pvuser, on the
collector's new host.
3. Change to the directory where DataLoad is installed. For example:
cd /opt/dataload
4. Source the DataLoad environment:
. ./dataLoad.env
5. Stop the SNMP collector:
pvmdmgr stop
6. Edit the file dataLoad.env and set the field DL_HA_MODE as follows:
v Set DL_HA_MODE=true if you moved the collector onto a HAM host.
v Set DL_HA_MODE=false if you moved the collector off of a HAM host.
7. Edit the file dataLoad.env and set the field DL_HA_MODE_1 as follows:
v Set DL_HA_MODE_1=true if you moved the collector onto a HAM host.
v Set DL_HA_MODE_1=false if you moved the collector off of a HAM host.
8. Source the DataLoad environment again:
. ./dataLoad.env
9. Start the SNMP collector:
pvmdmgr start
Note: If you move an SNMP collector to or from a HAM host, you

must bounce the HAM. For information, see “Stopping and restarting modified
components” on page 222.
Moving a deployed UBA bulk collector

The steps required to move a deployed UBA collector to a different host.
About this task
Note: You cannot move BCOL collectors, or UBA collectors that have a BLB or
QCIF subcomponent. If you want to move a UBA collector that has these
subcomponents, you must manually remove it from the old host in the topology
and then add it to the new host.
To move a deployed UBA collector to a different host:
Procedure
1. Log in as pvuser to the DataChannel host where the UBA collector is running.
2. Change to the directory where DataChannel is installed. For example:
cd /opt/datachannel
3. Source the DataChannel environment:
. dataChannel.env
4. Stop the collector's UBA and FTE components. For example, to stop these
components for UBA collector 1.1, run the following commands:
dccmd stop UBA.1.1
and...
dccmd stop FTE.1.1

For information on the dccmd command, see the Tivoli Netcool Performance
Manager Command Line Interface Guide.
Note: Some technology packs have additional pack-specific components that

must be shut down - namely, BLB (bulk load balancer) and IF (inventory file)
components. IF component names have the format xxxIF, where xxx is a
pack-specific name. For example, Cisco CWM packs have a CWMIF
component, Alcatel 5620 SAM packs have a SAMIF component, and Alcatel
5620 NM packs have a QCIF component. Other packs do not use these
technology-specific components.
5. Tar up the UBA collector's UBA directory. You will copy this directory to the
collector's new host later in the procedure (Step 13).
For example, to tar up a UBA directory for UBA collector 1.1, run the
following command:
Note: This step is not necessary if the collector's current host and the new
host share a file system.
tar -cvf UBA_1_1.tar ./UBA.1.1/*
Note: Some technology packs have additional pack-specific directories that

need to be moved. These directories have the same names
as the corresponding pack-specific components described in Step 4.
7. In the Logical view, navigate to the name of the collector to move - for
example, Collector UBA.1.1.
8. Right-click the collector name and select Migrate from the pop-up menu.
In the Physical view, the status of the collector on the new host is Configured.
The collector is no longer listed under the original host.
Note: If the UBA collector was the only DataChannel component on the
original host, the collector will be listed under that host,
and its status will be "To be uninstalled." You can remove the DataChannel
installation from the original host after you finish the steps below. For
information on removing DataChannel from the host, see “Removing a
component from the topology” on page 225.
10. Click Topology > Save Topology to save the topology.
If DataChannel is not already installed on the new host, this step installs it.
12. Click Run > Run Deployer for Uninstallation to remove the collector from
the original host, passing the updated topology as input. For more
information, see “Removing a component from the topology” on page 225.
13. Copy any directory you tarred in Step 5 and the associated JavaScript files to
the new host.
Note: This step is not necessary if the collector's original host and the new
host share a file system.

For example, to copy UBA_1_1.tar and the JavaScript files from the collector's
original host:
a. Log in as pvuser to the UBA collector's new host.
b. Change to the directory where DataChannel is installed. For example:
cd /opt/datachannel
c. FTP to the collector's original host.
d. Run the following commands to copy the tar file to the new host. For
example:
cd /opt/datachannel
get UBA_1_1.tar
bye
tar -xvf UBA_1_1.tar
e. Change to the directory where the JavaScript files for the technology pack
associated with the collector are located:
cd /opt/datachannel/scripts
f. FTP the JavaScript files from the /opt/datachannel/scripts directory on the
original host to the /opt/datachannel/scripts directory on the new host.
14. Log in as pvuser to the Channel Manager host where the Administrator
Components (including CMGR) are running.
15. Stop and restart the Channel Manager by performing the following steps:
a. Change to the $DC_HOME directory (typically, /opt/datachannel).
b. Source the DataChannel environment:
. dataChannel.env
c. Get the CMGR process ID by running the following command:
ps -ef | grep CMGR
The process ID appears in the output immediately after the user ID, as
shown below in bold:
pvuser 6561 6560 0 Aug 21 ? 3:04 /opt/datachannel/bin/CMGR_visualn/dc.im
-a CMGRpvuser 25976 24244 0 11:39:38 pts/7 0:00 grep CMGR
d. Stop the CMGR process. For example, if 6561 is the CMGR process ID:
kill -9 6561
e. Change to the $DC_HOME/bin directory (typically, /opt/datachannel/bin).
f. Restart CMGR by running the following command:
./cmgrw
16. Log in as pvuser to the UBA collector's new host and change to the
$DC_HOME/bin directory (typically, /opt/datachannel/bin).
17. Run the following command to verify that Application Manager (AMGR) is
running on the new host:
./findvisual
If the AMGR process is running, you will see output that includes an entry
like the following:
pvuser 6684 6683 0 Aug 21 ? 3:43 /opt/datachannel/bin/AMGR_visual -nologo
/opt/datachannel/bin/dc.im -a AMGR -lo
Note: If AMGR is not running on the new host, do not continue. Verify that
you have performed the preceding steps correctly.
18. Start the collector's UBA and FTE components on the new host. For example,
to start these components for collector 1.1, run the following commands:
./dccmd start UBA.1.1
and...

./dccmd start FTE.1.1
Note: If any pack-specific components were shut down on the old host (see
Step 4), you must also start those components on the new host.
Changing the port for a collector

You can use the Topology Editor to change the port associated with a collector.
About this task
To change the port associated with a collector after deployment:
Procedure
(see “Starting the Topology Editor” on page 154 and “Opening a deployed
topology” on page 187).
2. In the Logical view, navigate to the collector.
3. Highlight the collector to view its properties.
The Topology Editor displays both the collector core parameters and the
technology pack-specific parameters.
4. Edit the port parameter within the list, SERVICE_PORT, then click Finish.
7. When deployment is complete, log onto the server hosting the collector.
8. Log in as Tivoli Netcool Performance Manager UNIX user, pvuser, on the
collector's host.
cd /opt/dataload
. ./dataLoad.env
11. Stop the SNMP collector:
pvmdmgr stop
12. Edit the file dataLoad.env and set the field DL_ADMIN_TCP_PORT.
For example:
DL_ADMIN_TCP_PORT=8800
. ./dataLoad.env
14. Start the SNMP collector:
pvmdmgr start

Modifying Dashboard Application Services Hub and Tivoli Common
Reporting ports
You can update the ports used by Dashboard Application Services Hub and Tivoli
Common Reporting.
The Dashboard Application Services Hub specific ports defined and used to build
the topology.xml file are as follows:
WAS_WC_defaulthost 16310
COGNOS_CONTENT_DATABASE_PORT 1557
IAGLOBAL_LDAP_PORT 389
Changing ports for the Dashboard Application Services Hub

You can assign new ports to an installed Dashboard Application Services Hub
console.
Procedure
1. Create a properties file containing values such as host name that match your
environment. The exemplary properties file below uses default values. Modify
the values to match your environment. Save the file in any location.
WAS_HOME=C:/IBM/JazzSM
was.install.root=C:/IBM/JazzSM
profileName=DASHProfile
profilePath=C:/IBM/JazzSM/profiles
templatePath=C:/IBM/JazzSM/profileTemplates/default
nodeName=DASHNode
cellName=DASHCell
hostName=your_JazzSM_host
portsFile=C:/IBM/JazzSM/properties/DASHPortDef.properties
2. Edit the JazzSM_install_dir/properties/DASHPortDef.properties file to
contain the desired port numbers.
3. Stop the Jazz for Service Management server by navigating to the directory in
the command-line interface. For more information, see
Stopping Jazz for Service Management application servers.
Important: To stop the server, you must log in with the same user that you
used to install Tivoli Common Reporting.
4. In the command-line interface, navigate to the TCR_install_dir/bin directory.
ws_ant.bat -propertyfile C:/temp/tcrwas.props
-file "C:/IBM/JazzSM/profileTemplates/default/actions/updatePorts.ant"
C:/temp/tcrwas.props is the path to the properties file created in Step 1.

6. Change the port numbers in IBMCognos® Configuration:
a. Open IBM Cognos Configuration by running the following command:
TCR_component_dir\cognos\bin\tcr_cogconfig.bat
TCR_install_dir/cognos/bin/tcr_cogconfig.sh
b. In the Environment section, change the port numbers to the desired values,
as in Step 2.
c. Save your settings and close IBM Cognos Configuration.

7. Start the Jazz for Service Management server by navigating to the directory in
the command-line interface. For more information, see Starting Jazz for Service
Management application servers.
Important: To start the server, you must log in with the same user that you
used to install Jazz for Service Management.
Port assignments
The application server requires a set of sequentially numbered ports.
The sequence of ports is supplied during installation in the response file. The
installer checks that the number of required ports (starting with the initial port
value) are available before assigning them. If one of the ports in the sequence is
already in use, the installer automatically terminates the installation process and
you must specify a different range of ports in the response file.
Viewing the application server profile

Open the application server profile to review the port number assignments and
other information.
About this task
The profile of the application server is available as a text file on the computer
where it is installed.
Procedure
1. Locate the /opt/IBM/JazzSM/profile/logs directory.
2. Open AboutThisProfile.txt in a text editor.
Example
This is the profile for an installation in a Windows environment as it appears in

/opt/IBM/JazzSM/profile/logs/AboutThisProfile.txt:
Application server environment to create: Application server
Location: /opt/IBM/JazzSM/profile/DASHProfile
Disk space required: 200 MB
Profile name: DASHProfile
Make this profile the default: True
Node name: DASHNode Host name: <myJazzSMserver>.ibm.com
Enable administrative security (recommended): True
Administrative consoleport: 16315
Administrative console secure port: 16316
HTTP transport port: 16310
HTTPS transport port: 16311
Bootstrap port: 16312
SOAP connector port: 16313
Run application server as a service: False
Create a Web server definition: False

Chapter 9. Using the High Availability Manager
Describes the optional Tivoli Netcool Performance Manager High Availability

Manager (HAM), including how to set up a HAM environment.
Overview
The High Availability Manager (HAM) is an optional component for large
installations that want to use redundant SNMP collection paths.
The HAM constantly monitors the availability of one or more SNMP collection
hosts, and switches collection to a backup host (called a spare) if a primary host
becomes unavailable.
The following figure shows a simple HAM configuration with one primary host
and one spare. In the panel on the left, the primary host is operating normally.
SNMP data is being collected from the network and channeled to the primary host.
In the panel on the right, the HAM has detected that the primary host is
unavailable, so it dynamically unbinds the collection path from the primary host
and binds it to the spare.
Important: The High Availability Manager configuration is recommended only

when the primary and spare collectors are on different hosts.

HAM basics
An SNMP collector collects data from a specific set of network resources according
to a set of configuration properties.
A collector has two basic parts: the collector process running on the host computer,
and the collector profile that defines the collector's properties.
Note: Do not confuse a "collector profile" with an "inventory profile." A collector

profile contains properties used in the collection of data from network resources -
properties such as collector number, polling interval, and output directory for the
collected data. An inventory profile contains information used to discover network
resources - properties such as the addresses of the resources to look for and the
mode of discovery.
A collector that is not part of a HAM environment is static - that is, the collector
process and the collector profile are inseparable. But in a HAM environment, the
collector process and collector profile are managed as separate entities. This means
that if a collector process is unavailable (due to a collector process crash or a host
machine outage), the HAM can dynamically reconfigure the collector, allowing
data collection to continue. The HAM does so by unbinding the collector profile
from the unavailable collector process on the primary host, and then binding the
collector profile to a collector process on a backup (spare) host.
Note: It may take several minutes for the HAM to reconfigure a collector,
depending on the amount of data being collected.
The parts of a collector

Collector parts and their description.
When you set up a HAM configuration in the Topology Editor, you manage the
two parts of a collector - the collector process and the collector profile - through
the following folders in the Logical view:
Collector Processes
A collector process is a UNIX process representing a runtime instance of a
collector. A collector process is identified by the name of the host where
the process is running and by the collector process port (typically, 3002). A
host can have just one SNMP collector process.
Managed Definitions
A managed definition identifies a collector profile through the unique
collector number defined in the profile.
Every managed definition has a default binding to a host and to the
collector process on that host. The default host and collector process are
called the managed definition's primary host and collector process. A host
that you designate as a spare host has a collector process but no default
managed definition.
The following figure shows the parts of a collector that you manage through the
Collector Process and Managed Definition folders. In the figure, the HAM
dynamically unbinds the collector profile from the collector process on the primary
host, and then binds the profile to the collector process on the spare. This dynamic
re-binding of the collector is accomplished when the HAM binds the managed
definition - in this case, represented by the unique collector ID, Collector 1 - to the
collector process on the spare.

Clusters
A HAM environment can consist of a single set of hosts or multiple sets of hosts.
Each set of hosts in a HAM environment is called a cluster.
A cluster is a logical grouping of hosts and collector processes that are managed by
a HAM.
The use of multiple clusters is optional. Whether you use multiple clusters or just
one has no affect on the operation of the HAM. Clusters simply give you a way to
separate one group of collectors from another, so that you can better deploy and
manage your primary and spare collectors in a way that is appropriate for your
needs.
Multiple clusters may be useful if you have a large number of SNMP collector
hosts to manage, or if the hosts are located in various geographic areas.
The clusters in a given HAM environment are distinct from one another. In other
words, the HAM cannot bind a managed definition in one cluster to a collector
process in another.
HAM cluster configuration

For host failover to occur, a HAM cluster must have at least one available spare
host.
The cluster can have as few as two hosts - one primary and one spare. Or, it can
have multiple primary hosts with one or more spares ready to replace primary
hosts that become unavailable.
The ratio of primary hosts to spare hosts is expressed as p + s. For example, a

HAM cluster with four primary hosts and two spares is referred to as a 4+2
cluster.
Chapter 9. Using the High Availability Manager 203

Types of spare hosts
There are two types of spare hosts:
Designated spare
The sole purpose of this type of spare in a HAM cluster is to act as a
backup host.
A designated spare has a collector process, but no default managed
definition. Its collector process remains idle until the HAM detects an
outage on one of the active hosts, and binds that host's managed definition
to the spare's collector process.
A HAM cluster must have at least one designated spare.
Floating spare
This type of spare is a primary host that can also act as a backup host for
one or more managed definitions.
Types of HAM clusters

The types of HAM clusters that can be created.
When the HAM binds a managed definition to a spare (either a designated spare
or a floating spare), the spare becomes an active component of the collector. It
remains so unless you explicitly reassign the managed definition back to its
primary host or to another available host in the HAM cluster. This is an important
fact to consider when you plan the hosts to include in a HAM cluster.
There are two types of HAM clusters:

Fixed spare cluster
In this type of cluster, failover can occur only to designated spares. There
are no floating spares in this type of cluster.
When the HAM binds a managed definition to the spare, the spare
temporarily takes the place of the primary that has become unavailable.
When the primary becomes available again, you must reassign the
managed definition back to the primary (or to another available host). The
primary then resumes its data collection operations, and the spare resumes
its role as backup host.
If you do not reassign the managed definition back to the primary, the
primary cannot participate in further collection operations. Since the
primary is not configured as a floating spare, it also cannot act as a spare
now that its collector process is idle. As a result, the HAM cluster loses its
failover capabilities if no other spare is available.
Note: A primary host cannot act as a spare unless it is configured as a

floating spare.
Floating spare cluster
This type of cluster has one or more primary hosts that can also act as a
spare. Failover can occur to a floating spare or to a designated spare.
You do not need to reassign the managed definition back to this type of
primary, as you do with primaries in a fixed spare cluster. When a floating
spare primary becomes available again, it assumes the role of a spare.
You can designate some or all of the primaries in a HAM cluster as
floating spares. If all the primaries in a HAM cluster are floating spares,

you should never have to reassign a managed definition to another
available host in order to maintain failover capability.
Note: IBM recommends that all the primaries in a cluster be of the same
type - either all floating spares or no floating spares.
Example HAM clusters

Examples of HAM cluster options.
The Tivoli Netcool Performance Manager High Availability Manager feature is

designed to provide great flexibility in setting up a HAM cluster. The following
illustrations show just a few of the possible variations.
1 + 1, fixed spare
A fixed spare cluster with one primary host and one designated spare.
The figure below shows a fixed spare cluster with one primary host and one
designated spare:
v In the panel on the left, Primary1 is functioning normally. The designated spare
is idle.
v In the panel on the right, Primary1 experiences an outage. The HAM unbinds
the collector from Primary1 and binds it to the designated spare.
v With the spare in use and no other spares in the HAM cluster, failover can no
longer occur - even after Primary1 returns to service. For failover to be possible
again, you must reassign Collector 1 to Primary1. This idles the collector process
on the spare, making it available for the next failover operation if Primary 1 fails
again.
Note: When a designated spare serves as the only spare for a single primary, as in
a 1+1 fixed spare cluster, the HAM pre-loads the primary's collector definition on
the spare. This results in a fast failover with a likely loss of no more than one
collection cycle.
The following table shows the bindings that the HAM can and cannot make in this
cluster:
Collector Possible Host Bindings Host Bindings Not Possible

Collector 1 Primary1 (default binding) -
Designated spare

2 + 1, fixed spare
A fixed spare cluster with two primary hosts and one designated spare
The figure below shows a fixed spare cluster with two primary hosts and one
designated spare:
v In the panel on the left, Primary1 and Primary2 are functioning normally. The
designated spare is idle.
v With the spare in use and no other spares in the HAM cluster, failover can no
longer occur - even after Primary2 returns to service. For failover to be possible
again, you must reassign Collector 2 to Primary2. This idles the collector process
on the spare, making it available for the next failover operation.
cluster:

Collector 1 Primary1 (default binding) Primary2
Designated spare
Designated spare
Note: Due to multi collector functionality, we can also add Collector 1 and
Collector 2 on the same Primary host.
2 + 1, both primaries are floating spares

Both primaries are floating spares.
The figure below shows a floating spare cluster with two primary hosts and one
designated spare, with each primary configured as a floating spare:
v In the panel on the left, Primary1 and Primary2 are functioning normally. The
designated spare is idle.
v When Primary2 returns to service, it will assume the role of spare, meaning its
collector process remains idle. The host originally defined as the dedicated spare
continues as the active platform for Collector 2.

v The following figure shows the same cluster after Primary2 has returned to
service. In the panel on the left, Primary2 is idle, prepared to act as backup if
needed.
the collector from Primary1 and binds it to the floating spare, Primary2.
cluster:

Primary2
Designated spare
Collector 2 Primary1 -
Primary2 (default binding)
Designated spare
3+ 2, fixed spares
A fixed spare cluster with three primary hosts and two designated spares.
The figure below shows a fixed spare cluster with three primary hosts and two
designated spares:
v In the panel on the left, all three primaries are functioning normally. The
designated spares are idle.

the collector from Primary3 and binds it to Designated Spare 2. The HAM chose
Designated Spare 2 over Designated Spare 1 because the managed definition for
Collector 3 set the failover priority in that order.
Note: Each managed definition sets its own failover priority. Failover priority
can be defined differently in different managed definitions.
v With one spare in use and one other spare available (Designated Spare 1),
failover is now limited to the one available spare - even after Primary3 returns
to service. For dual failover to be possible again, you must reassign Collector 3
to Primary3.
Note: Due to multi collector functionality, we can add multiple designated

spares on a host.
cluster:

Designated Spare 1 Primary3
Designated Spare 2
Designated Spare 2
Designated Spare 2
3+ 2, all primaries are floating spares

A floating spare cluster with three primary hosts and two designated spares, with
each primary configured as a floating spare.

The figure below shows a floating spare cluster with three primary hosts and two
designated spares, with each primary configured as a floating spare:
v In the panel on the left, Primary3 had previously experienced an outage. The
HAM unbound its default collector (Collector 3) from Primary3, and bound the
collector to the first available spare in the managed definition's priority list,
which happened to be Designated Spare 2. Now that Primary3 is available
again, it is acting as a spare, while Designated Spare 2 remains the active
collector process for Collector 3.
Collector 2 from Primary2, and binds it to the first available spare in the
managed definition's priority list. This happens to be the floating spare
Primary3.
v When Primary2 becomes available again, there will once more be two spares
available - Primary2 and Designated Spare 1.
cluster:

Primary2
Primary3
Designated Spare 1
Designated Spare 2
Primary3
Designated Spare 1
Designated Spare 2

Primary2
Designated Spare 1
Designated Spare 2
High Availability Manager configuration changes to accommodate

multiple collector
It is advised that there are enough spare SNMP DL processes allocated on different
physical servers to support outages that take down entire physical servers.
Since previous installations of Tivoli Netcool Performance Manager only supported

multiple SNMP processes on a single physical server via virtualization; this change
makes it more likely that you will have to consider the possibility of an outage that
encompasses multiple SNMP DL processes. The HAM configuration must reflect
the increased risk of a single point of failure at the physical server level because of
the process consolidation that this change allows.

Resource pools
When you configure a managed definition in the Topology Editor, you specify the
hosts that the HAM can bind to the managed definition, and also the priority order
in which the hosts are to be bound. This list of hosts is called the resource pool for
the managed definition.
A resource pool includes:

v The managed definition's primary host and collector process (that is, the host
and collector process that are bound to the managed definition by default).
v Zero or more other primary hosts in the cluster.
If you add a primary host to a managed definition's resource pool, that primary
host becomes a floating spare for the managed definition.
v Zero or more designated spares in the cluster.
Typically, each managed definition includes one or more designated spares in its
resource pool.
Note: If no managed definitions include a designated spare in their resource

pools, there will be no available spares in the cluster, and therefore failover
cannot occur in the cluster.
How the SNMP collector works

The SNMP collector capability and behaviour.
The SNMP collector is state-based and designed both to perform initialization and
termination actions, and to "change state" in response to events generated by the
HAM or as a result of internally-generated events (like a timeout, for example).
The following table lists the events that the SNMP collector understands and
indicates whether they can be generated by the HAM.
Event HAM-Generated Description

Load Yes Load collection profile, do
not begin scheduling
collections.
Pause Yes Stop scheduling collections;
do not unload profile.
Reset Yes Reset expiration timer.
Start Yes Start scheduling collections.
Stop Yes Stop scheduling collections;
unload profile
Timeout No Expiration timer expires;
start scheduling collections.
The SNMP collector can reside in one of the following states, as shown in the
following table:

SNMP Collector State Event Description
Idle N/A Initial state; a collector
number may or may not be
assigned; the collection
profile has not been loaded.
Loading Load Intermediate state between
Idle and Ready. Occurs after
a Load event. Collector
number is assigned, and the
collection profile is being
loaded.
Ready N/A Collector number assigned,
profile loaded, but not
scheduling requests or
performing collections.
Starting Start Intermediate state between
Idle and Running. Occurs
after a Start event. Collector
number assigned, and profile
is being loaded.
Running N/A Actively performing requests
and collections.
Stopping Stop/Pause Intermediate state between
Running and Idle.
The following state diagram shows how the SNMP collector transitions through its
various states depending upon events or time-outs:
How failover works with the HAM and the SNMP collector
How Failover Works With the HAM and the SNMP Collector
The following tables illustrate how the HAM communicates with the SNMP
collectors during failover for a 1+1 cluster and a 2+1 cluster.

Table 18. HAM and SNMP Collector in a 1+1 Cluster
State of Primary State of Spare Events and Actions
Running Idle The HAM sends the spare
the Load event for the
specified collection profile.
Running Ready The HAM sends a Pause
event to the spare to extend
the timeout. Note: If the
timeout expires, the spare
will perform start actions
and transition to a Running
state.
Running Running The HAM sends a Pause
event to the collector process
that has been in a Running
state for a shorter amount of
time.
No response Ready The HAM sends a Start
event to the spare.
Table 19. HAM and SNMP Collector in a 2+1 Cluster

State of Primary State of Spare Events and Actions
Running Idle No action
Running Ready No action
Running Running The HAM sends a Stop event
to the collector process that
has been in Running state for
the shorter amount of time.
No Response Idle The HAM sends a Start
event to the spare.
No Response Ready The HAM sends a Start
event to the spare.
Because more than one physical system may produce SNMP collections, the File
Transfer Engine (FTE) must check every capable system for a specific profile. The
FTE retrieves all output for the specific profile. Any duplicated collections are
reconciled by the Complex Metrics Engine (CME).
Obtaining collector status

How to get the status of a collector.
To obtain status on the SNMP collectors managed by the HAM, enter the following
command on the command line:
$ dccmd status HAM.<hostname>.1
The dccmd command returns output similar to the following:

COMPONENT APPLICATION HOST STATUS ES DURATION EXTENDED STATUS
HAM.DCAIX2.1 HAM DCAIX2 running 10010 1.1 Ok: (box1:3012 ->
Running 1.1 for 5h2m26s); No avail spare; Check: dcaix2:3002, birdnestb:3002 1.2 Ok: (box2:3002 ->
Running 1.2 for 5h9m36s); No avail spare; Check: box4:3002, box5:3002 1.3 Not
Running; No avail spare;
Check: box4:3002, box5:3002

The following list describes EXTENDED STATUS information:
v 1.1 - Load # Collection profile 1.1
v Ok: - Status of the load. Ok means it is properly collected, Not Running indicates
a severe problem (data losses)
v (box1:3012 -> Running 1.1 for 5h2m26s)- The collector that is currently
performing the load, with its status and uptime.
v No avail spare - List of possible spare, if something happens to the collector
currently working. In this example there is no spare available, a failover would
fail. A list of host:port would indicate the possible spare machines.
v Check: box4:3002, box5:3002 - Indicates what is currently wrong with the
system/configuration. Machines box4:3002 and box5:3002 should be spare but
are either not running, or not reachable. The user is instructed to check these
machines.
For a 1-to-1 failover configuration, the dccmd command might return output like
the following:
$ dccmd status HAM.SERVER.1
COMPONENT APPLICATION HOST STATUS ES DURATION EXTENDED STATUS
HAM.SERVER.1 HAM SERVER running 10010 1.1 Ok: (box1:3002 ->
Running 1.1 for 5h2m26s); 1 avail spare: (box2:3002 -> Ready 1.1)
This preceding output shows that Collector 1.1 is in a Running state on Box1, and
that the Collector on Box2 is in a Ready state, with the profile for Collector 1.1
loaded.
Creating a HAM environment

This section describes the steps required to create a 3+1 HAM environment with a
single cluster, and with all three primaries configured as floating spares.
About this task
This is just one of the many variations a HAM environment can have. The
procedures described in the following sections indicate the specific steps where
you can vary the configuration.
Note: If you are setting up a new Tivoli Netcool Performance Manager

environment and plan to use a HAM in that environment, perform the following
tasks in the following order:
Procedure
1. Install all collectors.
2. Configure and start the HAM.
3. Install all technology packs.
4. Perform the discovery.

Topology prerequisites
The minimum component prerequisite.
A 3+1 HAM cluster requires that you have a topology with the following
minimum components:
v Three hosts, each bound to an SNMP collector. These act as the primary hosts.
You can create a managed definition for each of the primary hosts.
v One additional host that is not bound to an SNMP collector. This acts as the
designated spare.
For information on installing these components, see “Adding a new component”

on page 188.
Procedures
The general procedures for creating a single-cluster HAM with one designated
spare and three floating spares.
Create the HAM and a HAM cluster

To create a High Availability Manager with a single cluster
Procedure
where you want to add the HAM (see “Starting the Topology Editor” on page
154 and “Opening a deployed topology” on page 187).
2. In the Logical view, right-click High Availability Managers, located at
DataChannels > Administrative Components.
3. Select Add High Availability Manager from the pop-up menu.
The Add High Availability Manager Wizard appears.
4. In the Available hosts field, select the host where you want to add the HAM.
Note: You can install the HAM on a host where a collector process is installed,
but you cannot install more than one HAM on a host.
5. In the Identifier field, accept the default identifier.
The identifier has the following format:
HAM.<HostName>.< n >
where HostName is the name of the host you selected in Step 4, and n is a
HAM-assigned sequential number, beginning with 1, that uniquely identifies
this HAM from others that may be defined on other hosts.
6. Click Finish.
The HAM identifier appears under the High Availability Managers folder.
7. Right-click the identifier of the HAM you just created.
8. Select Add Cluster from the pop-up menu.
The Add Cluster Monitor Wizard appears.
9. In the Identifier field, type a name for the cluster and click Finish.
The cluster name appears under the HAM identifier folder you added in
Step 6. The following folders appear under the cluster name:
v Collector Processes
v Managed Definitions

Note: To add additional clusters to the environment, repeat Step 7 through
Step 9.
Adding the designated spare

How to create and add a designated spare.
About this task

To create a designated spare, you must have a host that is defined in the Physical
view with no SNMP collector assigned to it. For information about adding a host
to a topology, see “Adding the hosts” on page 155
To add a designated spare to a cluster:
Procedure
1. In the Logical view, right-click the Collector Processes folder that you created
in Step 9 of the previous section, “Create the HAM and a HAM cluster” on
page 215.
2. Select Add Collection Process SNMP Spare from the menu.
The Add Collection Process SNMP Spare - Configure Collector Process SNMP
Spare dialog is diaplayed.
3. In the Available hosts field, select the host that you want to make the
designated spare.
4. The Port field, specifies the next available port number, for the spare's collector
process. You can modify the port number. then click Finish.
Under the cluster's Collector Processes folder, the entry Collection Process
SNMP Spare <n > appears, where n is a HAM-assigned sequential number,
beginning with 1, that uniquely identifies this designated spare from others
that may be defined in this cluster.
Note: Repeat Step 1 through Step 4 to add an extra designated spare to the
cluster.
Important: The spare collector should have a unique port number.
What to do next
If you be make changes to an already existing configuration, ensure the
dataLoad.env file contains all the right settings:
cd /opt/dataload
. ./dataLoad.env
3. Make sure that DL_HA_MODE field in the dataLoad.env file and set to
DL_HA_MODE=true.
4. Make sure that DL_HA_MODE_1 field in the dataLoad.env file and set to
DL_HA_MODE_1=true.
. ./dataLoad.env

Add the managed definitions
A managed definition allows the HAM to bind a collector profile to a collector
process.
About this task
Note: When you add a managed definition to a HAM cluster, the associated
collector process is automatically added to the cluster's Collector Processes folder.
To add a managed definition to a HAM cluster:
Procedure
1. In the Logical view, right-click the Managed Definitions folder that you
created in “Create the HAM and a HAM cluster” on page 215.
2. Select Add Managed Definition from the pop-up menu.
The Add Managed Definition - Choose Managed Definition dialog appears.
3. In the Collector number field, select the unique collector number to associate
with this managed definition.
4. Click Finish.
The following entries now appear for the cluster:
v Under the cluster's Managed Definitions folder, the entry Managed
Definition < n > appears, where n is the collector number you selected in
Step 3.
v Under the cluster's Collector Processes folder, the entry Collector Process
[HostName] appears, where HostName is the host that will be bound to the
SNMP collector you selected in Step 3. This host is the managed definition's
primary host.
Note: Repeat Step 1 though to Step 4 to add another managed definition to the
cluster.
Example
When you finish adding managed definitions for a 3+1 HAM cluster, the Logical
and Physical views might look like the following:

In this example, the hosts dcsol1a, dcsol1b, and docserver1 are the primaries, and
docserver2 is the designated spare.
Define the resource pools

A resource pool is a list of the spares, in priority order, that the HAM can bind to a
particular managed definition.
About this task
When you create a managed definition, the managed definition's primary host is
the only host in its resource pool. To enable the HAM to bind a managed
definition to other hosts, you must add more hosts to the managed definition's
resource pool.
To add hosts to a managed definition's resource pool:
Procedure
1. Right-click a managed definition in the cluster's Managed Definitions folder.
2. Select Configure Managed Definition from the pop-up menu.
The Configure Managed Definition - Collector Process Selection dialog appears,
as shown below. In this example, the resource pool being configured is for
Managed Definition 1 (that is, the managed definition associated with Collector
1).

3. In the Additional Collector Processes list, check the box next to each host to
add to the managed definition's resource pool.
Typically, you will add at least the designated spare (in this example,
docserver2) to the resource pool. If you add a primary host to the resource
pool, that host becomes a floating spare for the managed definition.
Note: You must add at least one of the hosts in the Additional Collector
Processes list to the resource pool.
Since the goal in this example is to configure all primaries as floating spares,
the designated spare and the two primaries (docserver1 and dcsol1a) will be
added to the resource pool.
4. When finished checking the hosts to add to the resource pool, click Next.
Note: If you add just one host to the resource pool, the Next button is not
enabled. Click Finish to complete the definition of this resource pool. Return to
Step 1 to define a resource pool for the next managed definition in the cluster,
or skip to “Save and start the HAM” on page 220 if you are finished defining
resource pools.
The Configure Managed Definition - Collector Process Order dialog appears, as
shown below:

5. Specify the failover priority order for this managed definition. To do so:
a. Select a host to move up or down in the priority list, then click the Up or
Down button until the host is positioned where you want.
b. Continue moving hosts until the priority list is ordered as you want.
c. Click Finish.
In this example, if the primary associated with Managed Definition 1 fails, the
HAM will attempt to bind the managed definition to the floating spare dcsol1a.
If dcsol1a is in use or otherwise unavailable, the HAM attempts to bind the
managed definition to docserver1. The designated spare docserver2 is last in
priority.
6. Return to Step 1 to define a resource pool for the next managed definition in
the cluster, or continue with the next section if you are finished defining
resource pools.
Save and start the HAM

When you finish configuring the HAM as described in the previous sections, you
are ready to save the configuration and start the HAM.
About this task
To save and start the HAM:
Procedure
1. Click Topology > Save Topology to save the topology file containing the HAM
configuration.
updated topology file as input.
3. Open a terminal window on the DataChannel host.
4. Log in as pvuser.
5. Change your working directory to the DataChannel bin directory
(/opt/datachannel/bin by default), as follows:
cd /opt/datachannel/bin
6. Bounce (stop and restart) the Channel Manager. For instructions, see Step 15 on
page 111.
dccmd start ham

Monitoring of the HAM environment begins.
For information on using dccmd, see Tivoli Netcool Performance Manager
Command Line Interface.
Creating an additional HAM environment

How to create a HAM environment.
Typically, one HAM is sufficient to manage all the collectors you require in your
HAM environment. But for performance reasons, very large Tivoli Netcool
Performance Manager deployments involving dozens or hundreds of collector
processes might benefit from more than one HAM environment.
HAM environments are completely separate from one another. A host in one HAM
environment cannot fail over to a host in another HAM environment.
To create an additional HAM environment, perform all of the procedures described

in “Creating a HAM environment” on page 214.
Modifying a HAM environment

How to modify a HAM environment.
You can modify a HAM environment by performing any of the procedures in

“Creating a HAM environment” on page 214. For example, you can add collectors,
add clusters, configure a primary host as a floating spare, change the failover
priority order of a resource pool, and make a number of other changes to the
environment, including moving collectors into or out of a HAM environment.
For information on moving a deployed SNMP collector into or out of a HAM

environment, see “Moving a deployed SNMP collector to or from a HAM
environment” on page 193.
You can also modify the configuration parameters of the HAM components that
are writable. For information on modifying configuration parameters, see
“Changing configuration parameters of existing Tivoli Netcool Performance
Manager components” on page 190.
Removing HAM components

How to remove HAM components.
You can remove HAM components from the environment by right-clicking the
component name and selecting Remove from the pop-up menu. The selected
component and any subcomponents will be removed. When you remove SNMP
spare from a host, ensure that it is a SNMP component and check if it is the last
(SNMP and SNMP Spare) on the host.
If the collector is the last SNMP collector on that host:
1. Click Remove in the Logical View and save the topology.
2. Click Run > Run Deployer for Uninstallation.
If the collector is not the last SNMP collector on original host:
3. Click Remove in the Logical View and save the topology.
4. Click Run > Run Deployer for Installation.
5. Set the DL_HA_MODE field in the dataLoad.env file to FALSE.

. ./dataLoad.env
Before you can remove a designated spare (Collection Process SNMP Spare), you
must remove the spare from any resource pools it may belong to. To remove a
designated spare from a resource pool, open the managed definition that contains
the resource pool, and clear the check box next to the name of the designated spare
to remove. For information about managing resource pools, see “Define the
resource pools” on page 218
Stopping and restarting modified components

How to stop and restart modified components.
About this task
If you change the configuration of a HAM or any HAM components, or if you add
or remove an existing collector to or from a HAM environment, you must bounce
(stop and restart) the Tivoli Netcool Performance Manager components you
changed The is generally true for all Tivoli Netcool Performance Manager
components that you change, not just HAM.
To bounce a component:
Procedure
1. Open a terminal window on the DataChannel host.
2. Log in as pvuser.
(/opt/datachannel/bin by default), as follows:
cd /opt/datachannel/bin
4. Run the bounce command in the following format:
dccmd bounce <component>
For example:
v To bounce the HAM with the identifier HAM.dcsol1b.1, run:
dccmd bounce ham.dcsol1b.1
v To bounce all HAMs in the topology, run:
dccmd bounce ham.*.*
v To bounce the FTE for collector 1.1 that is managed by a HAM, run:
dccmd bounce fte.1.1
You do not need to bounce the HAM that the FTE and collector are in.
For information on using dccmd, see Tivoli Netcool Performance Manager
Command Line Interface.
5. Bounce the Channel Manager. For instructions, see Step 15.

Viewing the current configuration
During the process of creating or modifying a HAM cluster, it is useful to check
how the individual collector processes and managed definitions are currently
configured.
About this task

To view the current configuration of a collector process or managed definition:
Procedure
1. Right-click the collector process or managed definition to view.
2. Select Show from the menu.
The Show Collector Process... or Show Managed Definition... dialog is
displayed. The following sections describe the contents of these dialogs.
Show Collector Process... dialog

Dialog box description.
The following figure shows a collector process configured with three managed
definitions.
The configuration values are described as follows:

v dcsol1a. The primary host where this collector process runs.
v 3002. The port through which the collector process receives SNMP data.
v 3 2 (Primary) 1. The managed definitions that the HAM can bind to this
collector process. The values have the following meanings:
– 3. The managed definition for Collector 3.
– 2 (Primary). The managed definition for Collector 2. This is the default
managed definition for the collector process.
– 1. The managed definition for Collector 1.

Show Managed Definition... dialog
Dialog box description.
The Show Managed Definition... dialog contains the resource pool for a particular
managed definition.
This dialog contains the same information that appears in the Show Collector
Process... dialog, but for multiple hosts instead of just one. As such, this dialog
gives you a broader view of the cluster's configuration than a Show Managed
Definition... dialog.
The following figure shows a managed definition's resource pool configured with
four hosts:
Note the following about this managed definition's resource pool:

v The priority order of the hosts is from top to bottom - therefore, the first
collector process that the HAM will attempt to bind to this managed definition
is the one on host dcsol1a. The collector process on host docserver2 is last in the
priority list.
v The first three hosts are floating spares. They are flagged as such by each having
a primary managed definition.
v The host docserver2 is the only designated spare in the resource pool. It is
flagged as such by not having a primary managed definition.

Chapter 10. Uninstalling components
Provides information on how to uninstall components.
When you perform an uninstall, the "uninstaller" is the same deployer used to
install Tivoli Netcool Performance Manager.
Removing a component from the topology

How to remove an installed component from the topology.
You might have a situation where you have modified a topology by both adding
new components and removing components (marking them "To Be Removed").
However, the deployer can work in only one mode at a time - installation mode or
uninstallation mode. In this situation, first run the deployer in uninstallation mode,
then run it again in installation mode, except when you are uninstalling dataload.
See, “Restrictions and behavior” for Dataload restrictions.
Note: After the deployer has completed an uninstall, you must open the topology
(loaded from the database) in the Topology Editor before performing any
additional operations.
Uninstallation of HAM is not supported on IBM Tivoli Netcool Performance

Manager, Version 1.4.2.
Restrictions and behavior

Restrictions and behavior to observe when you perform an uninstall.
Before you remove a component, note the following information:

v You can remove a component from the topology if you have uninstalled the
components that depend on it. To uninstall a component, you must remove it
from the topology and then run the deployer in uninstall mode and run the
actions related to uninstalling the component.
v You can remove a host only if no components are configured or installed on it.
v If you remove a component and redeploy the file, the Topology Editor view is
not refreshed automatically. Reload the topology file from the database to view
the updated topology.
Note: After the components are marked for deletion, the topology must be
consumed by the deployer to propagate the required changes and load the
updated file in the database. When you open the database version of the topology,
the "removed" component disappears from the topology.
To remove one or more components from the topology where the host system no
longer exists or is unreachable on the network, do the following steps:

1. Open the Topology Editor and remove all components that are related to the
host system
2. Remove the host system from the topology
3. Redeploy the topology, ignoring any messages that are related to the
non-existent or unreachable host.
4. At deployment, the modified topology is saved to the database without the
components that were previously installed on the host system.
Note: After the manual uninstall is completed, the DataView instance will remain
in the topology after the uninstall operation completes, this is not usually the case
for uninstalled components.
DataLoad restrictions
v If you are removing SNMP/Spare collectors that are installed on host, such that
it is not the last SNMP/Spare collectors, then after you make changes to the
Topology, save it and always Run the deployer for Installation option.
v If you are removing the last SNMP/Spare collector, or all the SNMP/Spare
collectors on a host, then after you make changes to the Topology, save it and
always Run the deployer for Uninstallation option.
v You must not remove all SNMP/Spare collectors on a host and add
SNMP/Spare collectors to the same host in one step. If you want to remove and
add collectors on a host, first remove all collectors on the host, and then Save
topology. Run for Uninstallation and reopen topology from database. Add
collectors on that host, Save topology, and then Run for Installation.
DataChannel restrictions
v You can remove the DataChannel Administrative Component only after all the
DataChannels have been removed.
v If you are uninstalling a DataChannel component, the component must first be
stopped. If you are uninstalling all DataChannel components on a host, then you
must remove the DataChannel entries from the crontab.
v If you delete a DataChannel or collector, the working directories (such as the
FTE and CME) are not removed; you must delete these directories manually.
v When a Cross-Collector CME (CC-CME) is installed on the system and formulas
are applied against it, the removal of collectors that the CC-CME depends on is
not supported. It is an exceptional case, that is, if you have not installed a
CC-CME, collectors can be removed.
DataView restrictions
Uninstall DataView manually if other products are installed in the same Dashboard
Application Services Hub instance. Use the following procedure to uninstall a
DataView component:
1. Run the uninstall command:
/opt/IBM/JazzSM/products/tnpm/dataview/bin/uninstall.sh /opt/IBM/JazzSM
<DASH_administrator_username> <DASH_administrator_password>
2. Remove the DataView directory:
rm -rf /opt/IBM/JazzSM/products/tnpm/dataview
In the Topology Editor:

3. Remove the DataView component.
4. Save the topology.

5. Run the deployer for uninstallation.
6. Mark the DataView step successful.
7. Run the unregister DataView step.
Important: Delete all the existing Tivoli Netcool/OMNIbus Web GUI integration
dashboard pages before you run the uninstallation script. Otherwise, the
uninstallation might fail with the following error message:
GYMVC0001E: Error occurred: com.ibm.ws.scripting.ScriptingException:
com.ibm.ws.scripting.ScriptingException: WASX7418E: Application update for isc failed:
see previous messages for details.
Removing a component
To remove component from the topology.
Procedure
3. In the Logical view of the Topology Editor, right-click the component you want
to delete and select Remove from the pop-up menu.
4. The editor marks the component as To Be Removed and removes it from the
display.
6. Run the deployer (see “Starting the Deployer” on page 172).
Note: If you forgot to save the modified topology, the deployer will prompt
you to save it first.
topology file are already installed, and removes the component that is no
longer part of the topology.
7. The deployer displays the installation steps page, which lists the steps required
to remove the component. Note that the name of the component to be removed
includes the suffix "R" (for "Remove"). For example, if you are deleting a
DataChannel, the listed component is DCR.
8. Click Run All to run the steps needed to delete the component.
9. When the installation ends successfully, the deployer uploads the updated
topology file into the database. Click Done to close the wizard.
Note: If you remove a component and redeploy the file, the Topology Editor
view is not refreshed automatically. Reload the topology file from the database
to view the updated topology.
What to do next
If you have uninstalled DataChannel Components, you need to bounce CMGR

after you have run the deployer, so that it picks up the updated configuration and
realize the components have been removed. If you do not bounce CMGR after the
deployer runs then you get errors when the components are restarted.
Chapter 10. Uninstalling components 227

Removing multiple collectors
Removing all SNMP and spare collectors on a host.
Procedure
3. In the Logical view of the Topology Editor, right-click the SNMP collector or
spare collector you want to delete and select Remove from the pop-up menu.
4. Repeat step 2 for all SNMP collectors and spare collectors on the host that you
want to remove.
If there are no more SNMP or Spare collectors remaining on host:
6. Save Topology, and then click Run > Run Deployer for Uninstallation.
If there are SNMP or Spare collectors installed on host even after removing
some collectors:
7. Save Topology, and then click Run > Run Deployer for Installation.
Uninstalling the entire Tivoli Netcool Performance Manager system

How to uninstall the entire system.
To uninstall Tivoli Netcool Performance Manager, you must have the CD or the
original electronic image. The uninstaller will prompt you for the location of the
image.
Order of uninstall
The order in which you must uninstall components.
About this task
For all deployments, you must use the Topology Editor to uninstall the Tivoli
Netcool Performance Manager components in the following order:
Procedure
1. DataLoad and DataChannel
When uninstalling DataChannel from a host, you must run ./dccmd stop all,
disable, or delete the dataload cron processes and manually stop (kill -9) any
running channel processes (identified by running findvisual). For more
information about the findvisual command, see Appendix B, “DataChannel
architecture,” on page 239
2. DataMart
3. DataChannel Administrative Components and any remaining DataChannel
components.
4. DataView
5. Tivoli Netcool Performance Manager Database (remove only after all the other
components have been removed). The database determines the operating
platform of the Tivoli Netcool Performance Manager environment.

Important: From the deployer installation steps page, run only the Uninstall
Proviso Database step. User can ignore Load Channel Configuration, and
Load Collector Configuration steps.
Note: An error message is seen when user clicks Done, to close the deployer
wizard.
User can ignore the error, click OK to proceed to close the deployer wizard.
Restrictions and behavior

Before you uninstall Tivoli Netcool Performance Manager you must note the
following restrictions and behavior:
v If you need to stop the uninstallation before it is complete, you can resume it.
The uninstaller relies on the /tmp/ProvisoConsumer directory to store the
information needed to resume an uninstall. However, if the ProvisoConsumer
directory is removed for any reason, the -Daction=resume command will not
work.
Note: When you reboot your server, the contents of /tmp might get cleaned out.
v When you run the uninstaller, it finds the components that are marked as
"Installed", marks them as "To Be Removed", then deletes them in order. The
deployer is able to determine the correct steps to be performed. However, if the
component is not in the Installed state (for example, the component was not
started), the Topology Editor deletes the component from the topology - not the
uninstaller.
v When the uninstallation is complete, some data files still remain on the disk. You
must remove these files manually. See “Removing residual files” on page 231 for
the list of files that must be deleted manually.
v If you are not removing the last collector on a host, it is recommended that you
first remove the other components on the host. Save topology. Run for
Uninstallation. To remove collectors, see, “Removing multiple collectors” on
page 228.
Performing the uninstall

How to uninstall the Tivoli Netcool Performance Manager installation.
Before you begin

The unistall procedure assumes that you update the topology file:
3. In the Logical view of the Topology Editor, right-click each component that you
want to delete and select Remove from the menu.
4. The editor marks all components that you selected for removal as To Be
Removed and removes it from the display.
About this task
To remove a Tivoli Netcool Performance Manager installation:

Procedure
1. You can start the uninstaller from within the Topology Editor or from the
command line.
To start the uninstaller from the Topology Editor:
v Select Run > Run Deployer for Uninstallation.
To start the uninstaller from the command line:
a. Log in as root.
b. Set and export your DISPLAY variable (see “Setting up a remote X Window
display” on page 70).
c. Change directory to the directory that contains the deployer. For example:
# cd /opt/IBM/proviso/deployer
d. Enter the following command:
# ./deployer.bin -Daction=uninstall
2. The uninstaller opens, displaying a welcome page. Click Next to continue.
3. Accept the default location of the base installation directory of the database
JDBC driver:
v - /opt/oracle/product/12.1.0-client32/jdbc/lib)
v - /opt/db2/product/10.1.0/java
Or click Choose to browse to another directory. Click Next to continue. A
dialog opens, asking whether you want to load a topology from disk.
4. Click No.
A dialog box opens asking for you to enter the details of the updated topology
file.
5. Enter the name of the topology file you updated as described in the "Before
you begin" section.
6. The database access window prompts for the security credentials. Enter the
host name (for example, delphi) and database administrator password (for
example, PV), and verify the other values (port number, SID or DB_NAME, and
user name). Click Next to continue. The topology as stored in the database is
then compared with the topology loaded from the file.
7. The uninstaller displays several status messages, and then displays a message
stating that the environment status was successfully downloaded and saved to
the file /tmp/ProvisoConsumer/Discovery.xml. Click Next to continue.
8. Repeat the process on each system in the deployment.
Note: After the removal of each component by using the Topology Editor, you
must reload the topology from the Database.
Uninstalling the Topology Editor

How to uninstall the Topology Editor.
About this task

To uninstall the Topology Editor, follow the instructions in the section. Do not
delete the /opt/IBM directory. Doing so causes problem when you try to reinstall
the Topology Editor. If the /opt/IBM directory is accidentally deleted, do the
workaround that is documented in “Installing the Topology Editor” on page 152.

Note: Uninstall Tivoli Netcool Performance Manager before you uninstall the
Topology Editor.
To uninstall the Topology Editor:
Procedure
1. Log in as root.
2. Set and export your DISPLAY variable (see “Setting up a remote X Window
display” on page 70).
3. Change directory to the install_dir/uninstall directory. For example:
# cd /opt/IBM/proviso/uninstall
#./Uninstall_Topology_Editor
5. The uninstall wizard opens. Click Uninstall to uninstall the Topology Editor.
6. When the script is finished, click Done.
Note: Uninstalling Topology Editor will not remove the *.txt language files
from /opt/IBM/proviso/license. It needs to be manually removed.
Removing residual files

How to remove the possible residual files that may exist after the uninstall process.
About this task
When you uninstall Tivoli Netcool Performance Manager, some of the files remain
on the disk and must be removed manually. After you exit from the deployer (in
uninstall mode), you must delete these residual files and directories manually.
Perform the following steps:
Procedure
1. Log in as database instance name. For example, oracle for Oracle and db2 for
DB2.
2. Enter the following commands to stop:
sqlplus "/ as sysdba"

shutdown abort
exit
lsnrctl stop
db2stop force
3. As root, enter the following commands to delete these files and directories:

Table 20. Oracle and IBM DB2 commands to delete these files and directories
rm -fR /tmp/PvInstall rm -fR /tmp/PvInstall

rm -fR /var/tmp/PvInstall rm -fR /var/tmp/PvInstall
rm -fR /opt/Proviso rm -fR /opt/Proviso
rm -fR /opt/proviso rm -fR /opt/proviso
rm -fR $ORACLE_BASE/admin/PV rm -fR $DB2_BASE/tnpm_dbadmin
rm -fR $ORACLE_BASE/admin/skeleton rm -fR $DB2_BASE/create_db.ini
rm -fR $ORACLE_HOME/dbs/initPV.ora rm -fR $DB2_BASE/sqllib/function/
rm -fR $ORACLE_HOME/dbs/lkPV libpvmextc.so
rm -fR $ORACLE_HOME/dbs/orapwPV rm -fR $DB2_BASE/sqllib/function/
rm -fR $ORACLE_HOME/lib/libpvmextc.so libmultiTask.so
rm -fR $ORACLE_HOME/lib/libmultiTask.so rm -fR $DB2_BASE/sqllib/function/
rm -fR $ORACLE_HOME/lib/libcmu.so libcmu.so
rm -fR $ORACLE_HOME/bin/snmptrap rm -fR $DB2_BASE/tnpm_dbadmin/db2/
rm -fR $ORACLE_HOME/bin/notifyDBSpace bin/snmptrap
rm -fR $ORACLE_HOME/bin/notifyConnection rm -fR $DB2_BASE/tnpm_dbadmin/db2/
rm -rf /tmp/import_chnl_reg.udef.log bin/notifyDBSpace
rm -fR $DB2_BASE/tnpm_dbadmin/db2/
bin/notifyConnection
rm -rf /tmp/import_chnl_reg.udef.log
where:
v $ORACLE_BASE: /opt/oracle
v $DB2_BASE: /opt/db2 and
v $ORACLE_HOME: /opt/oracle/product/12.1.0
v $DB2_HOME: /opt/db2/opt/db2/product/10.1.0
4. Enter the following commands to clear your database mount points and
remove any files in those directories:
Table 21. Commands to clear your Oracle or DB2 mount points
rm -r /raid_2/oradata/* rm -fR /raid_2/db2data/*

rm -r /raid_3/oradata/* rm -fR /raid_3/db2data/*
5. Enter the following command to delete the temporary area used by the
deployer:
rm -fr /tmp/ProvisoConsumer
6. Delete the installer file using the following command:
rm /var/.com*
7. Delete the startup file, netpvmd.
v For use the command:

rm /etc/init.d/netpvmd
v For AIX, use the command:

rm /etc/rc.d/init.d/netpvmd
v For Linux, use the command:

rm /etc/init.d/netpvmd
Note: The netpvmd startup and stop files are also present in /etc/rc2.d and
/etc/rc3.d as S99netpvmd and K99netpvmd. These files must also be removed.

What to do next
Following Tivoli Common Reporting uninstallation:
To prevent any possible system instability caused by residual processes

post-uninstall of Tivoli Common Reporting, run thetcr Clean.sh script on all
systems where Tivoli Common Reporting is uninstalled:
1. On the host where the Tivoli Common Reporting installation failed, change to
the directory containing tcr Clean.sh:
cd /opt/IBM/proviso/deployer/proviso/bin/Util/
2. Run tcr Clean.sh
3. When prompted, enter the location where Tivoli Common Reporting was
installed.
Note: If you have uninstalled Tivoli Common Reporting on a remote host, thetcr
Clean.sh file is sent by using ftp to the remote host for execution.

Appendix A. Remote installation issues
Remote installation of all Tivoli Netcool Performance Manager components is
supported.
A remote installation refers to installation on any host that is not the primary
deployer, that is, the host running the Topology Editor. For some systems, security
settings may not allow for components to be installed remotely. Before deploying
on such a system, you must be familiar with the information in this appendix.
When remote install is not possible

What to do when remote installation is not possible.
There may arise situations where a remote host does not support FTP or the
remote execution of files.
A remote host may not support FTP or the remote execution of files.
It is possible your topology may include hosts one which:

v FTP is possible, but REXEC/RSH are not.
v Neither FTP nor REXEC/RSH are possible
This section describes how to deploy in these situations.
FTP is possible, but REXEC or RSH are not

In situations where FTP is possible but remote execution or remote shell are not.
About this task

For any remote host where FTP is possible, but REXEC or RSH are not,
deployment of the required component or components must be carried out using
the following steps.
There are two options for deployment.
Procedure
v Option 1:
1. Unselect the Remote Command Execution option during the installation. The
deployer creates and transfers the directory with the required component
package in it.
2. As root, log in to the remote system and manually run the run.sh script.
v Option 2:
Follow the directions outlined in “Installing on a remote host by using a
secondary deployer” on page 236.

Neither FTP nor REXEC/RSH are possible
In situations where FTP, remote execution and remote shell are not possible.
About this task
For any remote host where neither FTP nor REXEC or RSH are possible the
deployment of the required component or components must be carried out using
the following steps.
There are two options for deployment.
Procedure
v Option 1:
1. Unselect the FTP option during the installation. The deployer creates a
directory containing the required component package.
2. Copy the required component directory to the target system.
3. As root, log in to the remote system and manually run the run.sh script.
v Option 2:
Follow the directions outlined in “Installing on a remote host by using a
secondary deployer.”
Installing on a remote host by using a secondary deployer

The general procedure for installing a component on a remote host by using a
secondary deployer.
About this task
A secondary deployer is used when the host you want to install on does not
support remote installation.
The following steps describe how to install a Tivoli Netcool Performance Manager
component by using a secondary deployer. For the purpose of clarity, name the
primary deployer host as delphi, and the host on which you want to install a
component by using the secondary deployer that you can name corinth.
Procedure
1. Copy the Tivoli Netcool Performance Manager distribution to the server on
which you would like to set up the secondary deployer, that is, copy the
distribution to corinth. For more information about copying the Tivoli Netcool
Performance Manager distribution to a server, see “Downloading the Tivoli
Netcool Performance Manager distribution to disk” on page 87.
2. Open the Topology Editor on the primary deployer host, that is, on delphi, and
add the remote component to the topology definition.
You must complete this task already when you create your original topology
definition. If you already have added the remote component to your topology
definition, skip to the next step.
3. Deploy the new topology that contains the added component by using the
Topology Editor. You can do this by clicking Run> > Run Deployer for
Installation. This pushes the edited topology to the database.
4. Do the following, to open the Deployer on corinth:

a. Connect to corinth, change to the directory where you download the
product distribution, and start the deployer either in graphical mode (by
starting the Launchpad and clicking Start Deployer) or CLI mode (by
browsing to the directory that contains the deployer and entering the
command ./deployer.bin).
b. Enter the database credentials when prompted. The deployer connects to
the database.
For more information about how to run a secondary deployer, see
“Secondary Deployers” on page 173.
Note: The secondary deployer sees the topology data and knows that the
required component is still to be installed on corinth when you do step 3.
5. Follow the on screen instructions to install the wanted component.
Note: You cannot start the deployer simultaneously from two different hosts.
Only one deployer can be active at one time.
Appendix A. Remote installation issues 237

Appendix B. DataChannel architecture
Provides detailed information about the DataChannel architecture.
Data collection
DataChannel data collection.
A Tivoli Netcool Performance Manager DataChannel consists of a number of

components, including the following:
v File Transfer Engine (FTE)
v Complex Metric Engine (CME)
v Daily Database Loader (DLDR)
v Hourly Database Loader (LDR)
v Plan Builder (PBL)
v Channel Manager
The FTE, DLDR, LDR, and PBL components are assigned to each configured
DataChannel. The FTE and CME components are assigned to one or more
Collector subchannels.
Data is produced by Tivoli Netcool Performance Manager DataLoad Collectors.

Both SNMP and BULK Collectors are fed into a subchannel's channel processor.
Data moves through the CME and is synchronized in the Hourly Loader. The
Hourly Loader computes group aggregations from resource aggregation records.
The Daily Loader provides statistics on metric channel tables and metric
tablespaces and inserts data into the database.
Data is moved from one channel component to another as files. These files are
written to and read from staging directories between each component. Within each
staging directory there are subdirectories named do, output, and done. The do
subdirectory contains files that are waiting to be processed by a channel
component. The output subdirectory stores data for the next channel component to
work on. After files are processed, they are moved to the done directory. All file
movement is accomplished by the FTE component.
Data aggregation
A DataChannel aggregates data collected by collectors for eventual use by
DataView reports.
The DataChannel provides online statistical calculations of raw collected data, and
detects real-time threshold violations.
Aggregations include:
v Resource aggregation for every metric and resource
v Group aggregation for every group
v User-defined aggregation computed from raw data
Threshold detections in real time include:

v Raw data violating configured thresholds

v Raw data violating configured thresholds and exceeding the threshold during a
specific duration of time
v Averaged data violating configured thresholds
Management programs and watchdog scripts

Lists the names and corresponding watchdog scripts for the DataChannel
management programs.
The following table lists the names and corresponding watchdog scripts for the
DataChannel management programs running on different DataChannel hosts.
Table 10: Programs and Scripts
Corresponding
Component Program Executable* Watchdog Script Notes
Channel Name CNS cnsw Runs on the host
Server running the Channel
Manager.
Log Server LOG logw
Channel Manager CMGR cmgrw
Application Manager AMGR amgrw One per subchannel
host and one on the
Channel Manager
host.
* The actual component's executable file seen in the output of ps -ef is named XXX_visual ,
where XXX is an entry in this column. For example, the file running for CMGR is seen as
CMGR_visual.
The watchdog scripts run every few minutes from cron. Their function is to
monitor their corresponding management component, and to restart it if necessary.
You can add watchdog scripts for the Channel Manager programs to the crontab
for the pvuser on each host on which you installed a DataChannel component.
To add watchdog scripts to the crontab:

1. Log in as pvuser. Make sure this login occurs on the server running the
Channel Manager components.
2. At a shell prompt, go to the DataChannel conf subdirectory. For example:
$ cd /opt/datachannel/conf
3. Open the file dc.cron with a text editor. (The dc.cron files differ for different
hosts running different DataChannel programs. The following example shows
the dc.cron file for the host running the Channel Manager programs.)
0,5,10,15,20,25,30,35,40,45,50,55 1-31 1-12 0-6 /opt/datachannel/bin/cnsw
> /dev/null 2>&1
1,6,11,16,21.26,31,36,41,46,51,56 1-31 1-12 0-6 /opt/datachannel/bin/logw
> /dev/null 2>&1
2,7,12,17,22.27,32,37,42,47,52,57 1-31 1-12 0-6 /opt/datachannel/bin/cmgrw
> /dev/null 2>&1
3,8,13,18,23.28,33,38,43,48,53,58 1-31 1-12 0-6 /opt/datachannel/bin/amgrw
> /dev/null 2>&1
4. Copy the lines in the dc.cron file to the clipboard.

5. At another shell prompt, edit the crontab for the current user.

export EDITOR=vi
crontab -e
A text editor session opens, showing the current crontab settings.
6. Paste the lines from the dc.cron tab into the crontab file. For example:
0 * * * * [ -f /opt/datamart/dataMart.env ] && [ -x /opt/datamart/bin/pollinv ]
&& ....
0,5,10,15,20,25,30,35,40,45,50,55 1-31 1-12 0-6 /opt/datachannel/bin/cnsw >
/dev/null 2>&1
1,6,11,16,21,26,31,36,41,46,51,56 1-31 1-12 0-6 /opt/datachannel/bin/logw >
/dev/null 2>&1
2,7,12,17,22,27,32,37,42,47,52,57 1-31 1-12 0-6 /opt/datachannel/bin/cmgrw >
/dev/null 2>&1
3,8,13,18,23,28,33,38,43,48,53,58 1-31 1-12 0-6 /opt/datachannel/bin/amgrw >
/dev/null 2>&1
7. Save and exit the crontab file.

8. Repeat steps 1 to 8 on each DataChannel host, with this difference:
The dc.cron file on collector and loader hosts will have only one line, like this
example:
0,5,10,15,20,25,30,35,40,45,50,55 1-31 1-12 0-6
/opt/datachannel/bin/amgrw > /dev/null 2>&1
On such hosts, this is the only line you need to add to the pvuser crontab.
DataChannel application programs

DataChannel Application Program names and descriptions.
The DataChannel subchannel application programs are listed in Table 11.
Table 11: DataChannel Subchannel Application Program Names
DataChannel Program* Description Example

BCOL.n.c Bulk Collector process for BCOL.1.2
channel n, with Collector
number c
UBA.n.c UBA Bulk Collector process UBA.1.100
for channel n, with Collector
number c
CME.n.s Complex Metric Engine for CME.2.1
channel n, Collector number
s
DLDR.n Daily Loader for channel n DLDR.1
LDR.n Hourly Loader for channel n LDR.2
FTE.n. File Transfer Engine for FTE.1.1
channel n
PBL.n. Plan Builder for channel n PBL.1
* The actual application's executable file visible in the output of ps -ef is named
XXX_visual, where XXX is an entry in this column.
Note: For historical reasons, the SNMP DataLoad collector is managed by Tivoli
Netcool Performance Manager DataMart, and does not appear in Table 11.
Appendix B. DataChannel architecture 241

Starting the DataChannel management programs
How to check if DataChannel management programs are running and then start
application programs.
Procedure
v Verify that the DataChannel management programs are running:
1. Log in as pvuser on each DataChannel host.
2. Change to the DataChannel installation's bin subdirectory. For example:
$ cd /opt/datachannel/bin
3. Run the findvisual command:
$ ./findvisual
In the resulting output, look for:
– The AMGR process on every DataChannel host
– The CNS, CMGR, LOG, and AMGR processes on the Channel Manager
host
v If the DataChannel management programs are running on all DataChannel
hosts, start the application programs on all DataChannel hosts by following
these steps:
1. Log in as pvuser. Make sure this login occurs on the host running the
Channel Manager programs.
2. Change to the DataChannel installation's bin subdirectory. For example:
3. Run the following command to start all DataChannel applications on all
configured DataChannel hosts:
./dccmd start all
The command shows a success message like the following example.
Done: 12 components started, 0 components already running
See the Command Line Interface Reference for information about the dccmd
command.
There is a Java process associated with the LOG server that must be stopped
should the proviso.log need to be re-created:
1. To find this Java process, enter the following:
ps -eaf | grep LOG
The output should be similar to the following:
pvuser 15774 15773 0 Nov 29 ?
7:59 java -Xms256m -Xmx384m com.ibm.tivoli.analytics.Main -a LOG
2. Kill this process using the command:
kill -9 15774
15774 - is the pid of the Java process as discovered using the grep command.
3. Restart the LOGW process.

Starting the DataLoad SNMP collector
How to start the DataLoad SNMP Collector
About this task
Once you have started the DataChannel components, check every server that hosts
a DataLoad SNMP collector. to make sure the collectors are running. To check
whether a collector is running, run the following command:
ps -ef | grep -i pvmd
If the collector is running, you will see output similar to the following:
pvuser 27118 1 15 10:03:27 pts/4 0:06 /opt/dataload/bin/pvmd -nologo
-noherald /opt/dataload/bin/dc.im -headless -a S
If a collector is not running, perform the following steps:
Procedure
1. Log into the server that is running Tivoli Netcool Performance Manager SNMP
DataLoad by entering the username and password you specified when
installing SNMP DataLoad.
2. Source the DataLoad environment file by entering the following command:
./$DLHOME/dataLoad.env
where $DLHOME is the location where SNMP DataLoad is installed on the system
(/opt/dataload, by default).
Note: If DataLoad shares the same server as DataMart, make sure you unset
the environment variable by issuing the following command from a BASH shell
command line:
unset PV_PRODUCT
3. Change to the DataLoad bin directory by entering the following command:
cd $PVMHOME/bin
4. Start the DataLoad SNMP collector using the following command:
pvmdmgr start
The command displays the following message when the SNMP collector has
been successfully started:
PVM Collecting Daemon is running.
Results
The script controlling the starting and stopping of SNMP collectors, pvmdmgr,
prevents the possibility that multiple collector instances can be running
simultaneously.
If a user starts a second instance, that second instance will die by itself in under
two minutes without ever contacting or confusing the relevant watchdog script.

DataChannel management components in a distributed configuration
A description of the DataChannel management components.
Two channels running on the same system share a common Application Manager
(AMGR) that has a watchdog script, amgrw. The AMGR is responsible for starting,
monitoring through watchdog scripts, and gathering status for each application
server process for the system it runs on. Application programs include the FTE,
CME, LDR, and DLDR programs.
An example of multiple processes running on the same host is:

v Application Manager (AMGR)
v Complex Metric Engines (CME)
v File Transfer Engines (FTE)
v Hourly Data Loaders (LDR)
v Daily Data Loaders (DLDR)
Each program has its own set of program and staging directories.
Manually starting the Channel Manager programs

If you need to manually start the Channel Manager programs, you must do so in a
certain order.
About this task
After a manual start, the program's watchdog script restarts the program as
required.
Procedure
v To start the Channel Manager programs manually:
1. Log in as pvuser on the host running the Channel Manager programs.
2. At a shell prompt, change to the dataChannel/bin subdirectory. For example:
3. Enter the following commands at a shell prompt, in this order:
For the Channel Name Server, enter:
./cnsw
For the Log Server, enter:
./logw
For the Channel Manager, enter:
./cmgrw
For the Application Manager, enter:
./amgrw
v To manually start the DataChannel programs on all hosts in your DataChannel
configuration:
1. Start the Channel Manager programs, as described in the previous section.
2. On each DataChannel host, start the amgrw script.
3. On the Channel Manager host, start the application programs as described in
“Starting the DataChannel management programs” on page 242.

Adding DataChannels to an existing system
How to add DataChannels to an existing system.
About this task
If you add and configure a new remote DataChannel using the Topology Editor
after the initial deployment of your topology, the system will not pick up these
changes, unless the user manually stop starts the relevant processes, as explained
in Chapter 8, “Modifying the current deployment,” on page 187.
To shut down the DataChannel:
Note: The DataChannel CMGR, CNS, AMGR, and LOG visual processes must
remain running until you have gathered the DataChannel parameters from your
environment.
Procedure
1. On the DataChannel host, log in as the component user, such as pvuser.
(/opt/datachannel/bin by default) using the following command: $ cd
/opt/datachannel/bin
3. Shut down the DataChannel FTE.
Prior to shutting down all DataChannel components, some DataChannel work
queues must be emptied.
To shut down the DataChannel FTE and empty the work queues:
$ ./dccmd stop FTE.*
4. Let all DataChannel components continue to process until the .../do directories
for the FTE and CME components contain no files.
The .../do directories are located in the subdirectories of $DCHOME (typically,
/opt/datachannel) that contain the DataChannel components - for example,
FTE.1.1, CME.1.1.
5. Shut down all CMEs on the same hour (So the operator state files will be in
synch with each other). To accomplish this:
a. Identify the leading CME by either looking at the do and done directories
in each CME and the DAT files inside there; or using dccmd status all to see
which CME is reporting the latest hour in its processing status.
b. All CMEs on that hour must be stopped and then continue using the same
approach to finding the hour being processed and stop each CME as it
reaches the same hour until all CMEs are stopped. CMEs are stopped using
the command:
$ ./dccmd stop CME
6. Use the following dccmd commands to stop the DataChannel applications:
$ ./dccmd stop DLDR
$ ./dccmd stop LDR
$ ./dccmd stop FTE
$ ./dccmd stop DISC
$ ./dccmd stop UBA (if required)
Note: For details on how to restart a DataChannel, see “Manually starting the
Channel Manager programs” on page 244.

DataChannel terminology
Terms used throughout the Tivoli Netcool Performance Manager DataChannel
installation procedure.
Collector Subchannel
A subdivision of a DataChannel, with each Collector subchannel associated
with a single Collector and CME. The division into Collector subchannels
helps eliminate latency or loss of data caused by delayed Collectors. If a
Collector subchannel disconnects for a period of time, only that Collector is
affected, and all other Collector subchannels continue processing. The
number of Collector subchannels per DataChannel differs according to the
needs of a particular deployment. See the Requirements for information
related to system configuration requirements. The terms Collector and
Collectors are used to refer to Collector subchannel and Collector
subchannels.
Complex Metric Engine (CME)
A DataChannel program that performs on-the-fly calculations on raw
metrics data for a DataChannel. These calculations include time
aggregations for resources, as well as statistical calculations using raw data,
thresholds, properties, and constants as inputs. If CME formulas are
defined for the incoming metrics data, the values are processed by those
formulas. The CME synchronizes metadata at the beginning of each hour,
and only processes the metadata that exists for the hour.
CORBA (Common Object Request Broker Architecture)
An industry-standard programming architecture that enables pieces of
programs, called objects, to communicate with one another regardless of
the programming language that they were written in or the operating
system they are running on.
Daily Database Loader (DLDR)
A DataChannel program that gathers statistical data processed by a
DataChannel's CME and inserts it into the Tivoli Netcool Performance
Manager database. There is one Daily Loader for each DataChannel; it is
part of the channel processor component of the DataChannel.
DataChannel Remote (DCR)
A DataChannel installation configuration in which the subchannel, CME
and FTE components are installed and run on one host, while the Loader
components are installed and run on another host. In this configuration,
the subchannel hosts can continue processing data and detecting threshold
violations, even while disconnected from the Channel Manager server.
DataChannel Standard
A DataChannel installation configuration in which all component programs
of each subchannel are installed and run on the same server. DataChannel
Standard installation is described.
DataLoad Bulk Collector
A DataLoad program that processes different data formats and resource
files supplied by network devices, network management platforms,
network probes, and other types of resources such as BMC Patrol. The
Bulk Collector translates bulk statistics provided in flat files into Tivoli
Netcool Performance Manager metadata and data. If operating in
synchronized inventory mode, the Bulk Collector passes the resources and
properties to the Tivoli Netcool Performance Manager DataMart Inventory
application.

DataLoad SNMP Collector
A DataLoad program that collects data from network resources via SNMP
polling. The SNMP Collector provides raw data files to the DataChannel
for processing by the CME.
DataLoad UBA Bulk Collector
A DataLoad program that imports data from files (referred to as Bulk input
files) generated by non-SNMP devices, including Alcatel 5620 NM, Alcatel
SAM, and Cisco CWM. These Bulk input files contain formats that the
Bulk Collector is unable to handle.
Discovery Server (DISC)
A DataChannel program that runs as a daemon to perform an inventory of
SNMP network devices from which to gather statistical data.
Hourly Database Loader (LDR)
A DataChannel program that serves as the point of data synchronization
and merging, and of late data processing, for each DataChannel. The
Hourly Loader gathers files generated by the CME, computes group
aggregations from the individual resource aggregation records, and loads
the data into the Tivoli Netcool Performance Manager database.
File Transfer Engine (FTE)
A DataChannel program that periodically scans the Collector output
directories, examines the global execution plan to determine which
computation requests require the data, then sorts the incoming data for
storage.
Next-Hour Policy
Specifies the number of seconds to wait past the hour for files to arrive
before the next hourly directory is created. The default value causes the
DataChannel to wait until 15 minutes after the hour before it starts
processing data for the next hour. To avoid losing data, you need to set a
percentage and a time-out period during the configuration of the CME.
Plan Builder (PBL)
A DataChannel program that creates the metric data routing and
processing plan for the other components in the DataChannel.

Appendix C. Aggregation sets
Describes how to configure and install aggregation sets.
Overview
An aggregation set is a grouping of network management raw data and computed
statistical information stored in the Tivoli Netcool Performance Manager database
for a single timezone.
For example, if your company provides network services to customers in both the
Eastern and Central US timezones, you must configure two aggregation sets.
Because each aggregation set is closely linked with a timezone, aggregation sets are
sometimes referred to as timezones in the in Tivoli Netcool Performance Manager
documentation. However, the two concepts are separate.
Note: "Aggregation set" is abbreviated to "Aggset" in some setup program menus.
Configuring aggregation sets

How to configure aggregation sets.
About this task
When you configure an aggregation set, the following information is stored in the
database:
v The timezone ID number associated with this aggregation set.
v The timezone offset from GMT, in seconds.
v Optionally, the dates that Daylight Savings Time (DST) begins and ends in the
associated timezone for each year from the present through 2014. (Or you can
configure an aggregation set to ignore DST transitions.)
You configure an aggregation set either by creating a new set or by modifying an

existing set. The first aggregation set is installed by default when you install Tivoli
Netcool Performance Manager Datamart, so if your network will monitor only one
timezone, you need only to configure the existing set.
To configure an aggregation set:
Procedure
1. Log in as root. (Remain logged in as root for the remainder of this appendix.)
2. At a shell prompt, change to the directory where Tivoli Netcool Performance
Manager DataMart program files are installed. For example:
# cd /opt/datamart
3. Load the DataMart environment variables into your current shell's
environment using the following command:
# . ./dataMart.env
4. Change to the bin directory:
# cd bin

# ./create_modify_aggset_def
The following menu is displayed:
--------------------------------------------------
Tivoli Netcool Performance Manager Database
Date: <Current Date> <Current Time>
Script name: create_modify_aggset_def
Script revision: <revision_number>
- Aggregation set creation
- Aggregation set modification
- DST configuration for an aggregation set
--------------------------------------------------
Database user................. : [ PV_ADMIN ]

Database user password........ : [ ]
Menu :
1. Input password for PV_ADMIN.

2. Configure an aggset.
0. Exit
Choice : 1
6. Type 1 at the Choice prompt and pressEnter to enter the password for
PV_ADMIN. The script prompts twice for the password you set up for PV_ADMIN.
==> Enter password for PV_ADMIN : PV
==> Re-enter password : PV
Note: The script obtains the DB_USER_ROOT setting from the Tivoli Netcool
Performance Manager database configured in previous chapters, and
constructs the name of the Tivoli Netcool Performance Manager database
administrative login name, PV_ADMIN, from that base. If you set a different
setting, the "Database user" entry reflects your settings. For example, if you
previously set DB_USER_ROOTDB_USER_ROOT=PROV, this script would generate the
administrative login name PROV_ADMIN.
7. To configure the first aggregation set, type 2 at the Choice prompt and press
Enter twice.
The script shows the current settings for the aggregation set with ID 0
(configured by default):
The following Time Zones are defined into the Database :
___________________________________________________________________________________
id | Date (in GMT) | offset in | Name | Aggsetstatus
| | seconds | |
___________________________________________________________________________________
0 | 1970/01/01 00:00:00 | 0 | GMT | Aggset created
==> Press <Enter> to continue ....
You can use this aggregation set as-is, or modify it to create a new timezone.
8. Press Enter. A list of predefined timezones and their timezone numbers is
displayed:

Num | OffSet | Time zone Name | Short | Long
| Hours | | Description | Description
___________________________________________________________________________________
[ 1] : -10:00 | America/Adak | HAST | Hawaii-Aleutian Standard Time
[ 2] : -10:00 | Pacific/Rarotonga | CKT | Cook Is. Time
[ 3] : -09:00 | America/Anchorage | AKST | Alaska Standard Time
[ 4] : -09:00 | AST | AKST | Alaska Standard Time
[ 5] : -08:00 | PST | PST | Pacific Standard Time
[ 6] : -07:00 | MST | MST | Mountain Standard Time
[ 7] : -06:00 | America/Mexico_City| CST | Central Standard Time
[ 8] : -06:00 | CST | CST | Central Standard Time
[ 9] : -05:00 | EST | EST | Eastern Standard Time
[10] : -04:00 | America/Santiago | CLT | Chile Time
[11] : -03:00 | America/Sao_Paulo | BRT | Brazil Time
[12] : -01:00 | Atlantic/Azores | AZOT | Azores Time
[13] : 000:00 | Europe/London | GMT | Greenwich Mean Time
[14] : +01:00 | Europe/Paris | CET | Central European Time
[15] : +01:00 | ECT | CET | Central European Time
[16] : +02:00 | Africa/Cairo | EET | Eastern European Time
[17] : +02:00 | Europe/Helsinki | EET | Eastern European Time
[18] : +02:00 | Europe/Bucharest | EET | Eastern European Time
[19] : +03:00 | Asia/Baghdad | AST | Arabia Standard Time
[20] : +03:00 | Europe/Moscow | MSK | Moscow Standard Time
[21] : +04:00 | Asia/Baku | AZT | Azerbaijan Time
[22] : +05:00 | Asia/Yekaterinburg | YEKT | Yekaterinburg Time
[23] : +06:00 | Asia/Novosibirsk | NOVT | Novosibirsk Time
[24] : +07:00 | Asia/Krasnoyarsk | KRAT | Krasnoyarsk Time
[25] : +08:00 | Asia/Irkutsk | IRKT | Irkutsk Time
[26] : +09:00 | Asia/Yakutsk | YAKT | Yakutsk Time
[27] : +10:00 | Australia/Sydney | EST | Eastern Standard Time (New
South Wales)
[28] : +11:00 | Pacific/Noumea | NCT | New Caledonia Time
[29] : +12:00 | Pacific/Auckland | NZST | New Zealand Standard Time
[30] : +12:00 | Asia/Anadyr | ANAT | Anadyr Time
==> Select Time Zone number [1-30 ] (E : Exit) : 9
9. Type the number of the timezone you want to associate with aggregation set
0. For example, type 9 for Eastern Standard Time.
The script prompts:
==> Select an Aggset ID to add/modify (E: Exit) : 0
To associate the specified timezone, EST, with the database's default
aggregation set, type 0.
10. The script asks whether you want your aggregation set to include Daylight
Saving Time (DST) transition dates:
Does your Time Zone manage DST [Y/N] : Y
For most time zones, type Y and press Enter.
11. The script displays the results:
Appendix C. Aggregation sets 251

Complete with Success ...
The following Time Zone has been modified:
___________________________________________________________________________________
id | Date (in GMT) | offset in | Name | Aggset status
| | seconds | |
___________________________________________________________________________________
0 | 1970/01/01 00:00:00 | 0 | GMT | Aggset created
0 | 2004/09/29 22:00:00 | -14400 | EST_2004_DST | Aggset created
0 | 2004/10/31 06:00:00 | -18000 | EST_2004 | Aggset created
Note: The dates that appear in your output will most likely be different from
the dates that appear in the example.
12. Press Enter to return to the script's main menu.
13. To configure a second aggregation set, type 2 at the Choice prompt and press
Enter three times.
14. Specify the timezone number of your second timezone. For example, type 8 to
specify Central Standard Time.
The script prompts:
==> Select an Aggset ID to add/modify (E: Exit) : 1
If you enter a set number that does not exist in the database, the script creates
a new aggregation set with that number. Type the next available set number,
1.
15. Respond Y to the timezone management query.
The script shows the results of creating the second aggregation set:
____________
The following Time Zone has been modified :
___________________________________________________________________________________
id | Date (in GMT) | offset in | Name | Aggset status
| | seconds | |
___________________________________________________________________________________
1 | 2004/09/29 23:00:00 | -18000 | CST_2004_DST | Aggset created
1 | 2004/10/31 07:00:00 | -21600 | CST_2004 | Aggset created
16. Press Enter to return to the main menu, where you can add more aggregation
sets, or type 0 to exit.

The next step is to install the aggregation sets on the server on which you
installed Tivoli Netcool Performance Manager DataMart.
Installing aggregation sets

How to install aggregation sets.
When you install DataMart, aggregation set 0 is automatically installed. If you

configured only the default aggregation set (in “Configuring aggregation sets” on
page 249), you can skip this section. However, if you configured the time zones for
additional aggregation sets, you must install the non-zero sets using the steps in
this section.
Start the Tivoli Netcool Performance Manager setup program

How to start the Tivoli Netcool Performance Manager Setup Program.
About this task
Start the setup program by following these steps:
Procedure
1. Make sure your EDITOR environment variable is set.
2. Change to the /opt/Proviso directory:
cd /opt/Proviso
3. Start the setup program:
./setup
The setup program's main menu is displayed:
Tivoli Netcool Performance Manager <version number> - [Main Menu]
1. Install
2. Upgrade
3. Uninstall
0. Exit
Choice [1]> 1
4. Type 1 at the Choice prompt and press Enter. The Install menu is displayed:
Tivoli Netcool Performance Manager <version number> - [Install]
1. Tivoli Netcool Performance Manager Database Configuration
0. Previous Menu
Choice [1]> 1
Set aggregation set installation parameters

How to set the aggregation set installation parameters.
Procedure
1. Type 1 at the Choice prompt and press Enter. Setup displays the installation
environment menu:

Tivoli Netcool Performance Manager Database Configuration <version number> -
[installation environment]
1. PROVISO_HOME : /opt/Proviso
2. DATABASE_DEF_HOME : -
3. CHANNELS_DEF_HOME : -
4. AGGRSETS_DEF_HOME : -
5. Continue
0. Exit
Choice [5]> 5
Note: Menu options 2, 3, and 4 are used later in the installation process.
2. Make sure the value for PROVISO_HOME is the same one you used when
you installed the database configuration. If it is not, type 1 at the Choice
prompt and correct the directory location.
3. The script displays the component installation menu:
Tivoli Netcool Performance Manager Database Configuration <version number> -
[component installation]
1. Database
2. Channel
3. Aggregation set
0. Exit
Choice [1]> 3
4. Type 3 at the Choice prompt and press Enter. The script displays the
installation environment menu:
Tivoli Netcool Performance Manager Aggregation Set <version number> -
[installation environment]
1. PROVISO_HOME : /opt/Proviso
2. DATABASE_HOME : /opt/oracle/product/12.1.0 or /opt/db2/product/10.1.0
3. ORACLE_SID : PV
4. DB_USER_ROOT : -
5. Continue
0. Previous Menu
Choice [5]> 4
5. Type 4 at the Choice prompt and press Enter to specify the same value for
DB_USER_ROOT that you specified in previous chapters. This manual's
default value is PV.
Enter value for DB_USER_ROOT [] : PV
6. Make sure that the values for PROVISO_HOME, DATABASE_HOME, and
ORACLE_SID or DB_NAME are the same ones you entered in previous
chapters. Correct the values if necessary.
7. Type 5 at the Choice prompt and press Enter. Setup displays the Aggregation
Set installation options menu:
Tivoli Netcool Performance Manager Aggregation Set <version number> -
[installation options]
1. List of configured aggregation sets
2. List of installed aggregation sets
3. Number of the aggregation set to install : -
4. Channel where to install aggregation set : (all)
5. Start date of aggregation set : <Current Date>
6. Continue
0. Back to options menu
Choice [6]>
Note: Do not change the value for option 4. Retain the default value, "all."

8. The first time you use any menu option, the script prompts for the password
for PV_ADMIN:
Enter password for PV_ADMIN : PV
9. Use menu option 1 to list the aggregation sets you configured in “Configuring
aggregation sets” on page 249. The script displays a list similar to the
following:
============= LIST OF CONFIGURED AGGREGATION SETS ============
Num Effect Time Name Time lag
---- --------------------- ------------------------------------------- --------
0 01-01-1970 00:00:00 GMT +0h
04-01-2007 07:00:00 EST_2007_DST -4h
04-02-2006 07:00:00 EST_2006_DST -4h
04-03-2005 07:00:00 EST_2005_DST -4h
04-04-2010 07:00:00 EST_2010_DST -4h
04-05-2009 07:00:00 EST_2009_DST -4h
04-06-2008 07:00:00 EST_2008_DST -4h
09-29-2004 22:00:00 EST_2004_DST -4h
10-25-2009 06:00:00 EST_2009 -5h
10-26-2008 06:00:00 EST_2008 -5h
10-28-2007 06:00:00 EST_2007 -5h
10-29-2006 06:00:00 EST_2006 -5h
10-30-2005 06:00:00 EST_2005 -5h
10-31-2004 06:00:00 EST_2004 -5h
10-31-2010 06:00:00 EST_2010 -5h
1 04-01-2007 08:00:00 CST_2007_DST -5h
04-02-2006 08:00:00 CST_2006_DST -5h
04-03-2005 08:00:00 CST_2005_DST -5h
04-04-2010 08:00:00 CST_2010_DST -5h
04-05-2009 08:00:00 CST_2009_DST -5h
04-06-2008 08:00:00 CST_2008_DST -5h
09-29-2004 23:00:00 CST_2004_DST -5h
10-25-2009 07:00:00 CST_2009 -6h
10-26-2008 07:00:00 CST_2008 -6h
10-28-2007 07:00:00 CST_2007 -6h
10-29-2006 07:00:00 CST_2006 -6h
10-30-2005 07:00:00 CST_2005 -6h
10-31-2004 07:00:00 CST_2004 -6h
10-31-2010 07:00:00 CST_2010 -6h
2 aggregation sets configured
Press enter...
10. Select option 2 to list the aggregation sets already installed. The output is
similar to the following:
============== LIST OF CREATED AGGREGATION SETS ==============
============ X: created ==== #: partially created ============
Channels 0
| 1
AggSets -----------------------------------------------------------------------
| 0 X
Press enter...
Remember that aggregation set 0 is automatically installed when you install

the database channel, and continues to be installed even if you modified set 0
by assigning a different timezone.
11. Select option 3 to designate the aggregation set to install. In the examples
above, set 0 is already installed, but set 1 is waiting to be installed. Thus, enter
1 at the prompt:
Enter Aggregation Set number between 1 and 998 : 1
12. By default, the date to start collecting data on the designated aggregation set
is today's date. You can instead use menu option 5 to designate a future date
to start collecting data. Set an appropriate future date for your installation.

Enter start date (GMT) using Oracle or DB2 format ’yyyy.mm.dd-hh24’ : 2009.08.31-00
WARNING! Start date is set in the future.
No loading is allowed until start date (GMT) is reached.
Do you confirm the start date (Y/N) [N] ? y
13. When all menu parameters are set, type 6 at the Choice prompt and press
Enter.
Edit aggregation set parameters file

How to edit the aggregation set parameters file
About this task
Procedure
1. The script prompts that it will start the editor specified in the EDITOR
environment variable and open the aggregation set parameters file. Press Enter.
An editing session opens containing the aggsetreg.udef configuration file, as
shown in this example:
#
# Tivoli Netcool Performance Manager Datamart
# <Current Date>
#
#
# Channel C01: GROUPS DAILY aggregates storage
#
[AGGSETREG/C01/1DGA/TABLE/CURRENT]
PARTITION_EXTENTS=5
PARTITION_SIZE=100K
#
[AGGSETREG/C01/1DGA/TABLE/HISTORIC]
PARTITION_EXTENTS=5
PARTITION_SIZE=100K
#
[AGGSETREG/C01/1DGA/TABLESPACE/CURRENT]
CREATION_PATH=/raid_2/oradata
EXTENT_SIZE=64K
SIZE=10M
#
[AGGSETREG/C01/1DGA/TABLESPACE/HISTORIC]
CREATION_PATH=/raid_3/oradata
EXTENT_SIZE=64K
SIZE=10M
#
# Channel C01: RESOURCES DAILY aggregates storage
#
[AGGSETREG/C01/1DRA/TABLE/CURRENT]
PARTITION_EXTENTS=5
PARTITION_SIZE=100K
#
...
2. Do not make changes to this file unless you have explicit instructions from
Professional Services.
Only if you have guidelines from Professional Services for advanced
configuration of your aggregation sets, make the suggested edits.
Save and close the file.
3. When you close the configuration file, the script checks the file parameters and
starts installing the aggregation set. The installation takes three to ten minutes,
depending on the speed of your server.
A message like the following is displayed when the installation completes:

P R O V I S O A g g r e g a t i o n S e t <version number>
||||||||||||||||||||||||
AggregationSet installed
Tivoli Netcool Performance Manager Aggregation Set 1 on Channel 1 successfully installed !
Press Enter...
Linking DataView groups to timezones

Once you have configured and installed the aggregation sets, you must link
DataView groups to a timezone.
About this task
You can link a defined timezone to a calendar you create in the DataView GUI, or
the CME Permanent calendar (a 24-hour calendar).
When you link a group to a specific timezone and calendar, all subgroups inherit
the same timezone and calendar.
Procedure
v Best practice:
Use a separate calendar for each timezone. If you link multiple timezones to the
same calendar, a change to one timezone calendar setting will affect all the
timezones linked to that calendar.
v To link a group to a timezone:
1. Create a calendar with the DataView GUI, or use the default CME
Permanent calendar.
2. Create a text file (for example, linkGroupTZ.txt) with the following format:
– Each line has three fields separated by |_|.
– The first field is a DataView group name.
– The second field is a timezone name from the Tivoli Netcool Performance
Manager internal timezone list. See “Configuring aggregation sets” on
page 249 for a list of timezone names.
– The third field is the name of the calendar you create, or CME Permanent.
The following example line demonstrates the file format:
~Group~USEast|_|EST_2005_DST|_|CME Permanent|_|
Enter as many lines as you have timezone entries in your aggregation set
configuration.
3. At a shell prompt, enter a command similar to the following, which uses the
Resource Manager's CLI to link the group to the timezone:
resmgr -import segp -colNames "npath tz.name cal.name" -file linkGroupTZ.txt
v To unlink a timezone:
– Use the resmgr command. For example:
resmgr -delete linkGroupSE_TZC -colNames "npath tz.name cal.name" -file linkGroupTZ.txt
v To review timezone to group associations:
– Use the resmgr command. For example:
resmgr -export segp -colNames "name tz.name cal.name" -file link.txt

Appendix D. Deployer CLI options
Deployer CLI options and their descriptions.
To run the deployer from the command line, entering the following command:
# ./deployer.bin [options]
The deployer.bin command accepts the following options:
Option Description
-Daction=patch Performs a patch installation of Tivoli

Netcool Performance Manager. See
Appendix G, “Installing an interim fix,” on
page 279 for more information.
-Daction=resume Resumes an interrupted installation at the

current step. Note that this option is possible
only when the /tmp/ProvisoConsumer
directory is available. See “Resuming a
partially successful first-time installation” on
page 177 for more information.
-Daction=uninstall Uninstalls all components marked "To Be

Removed" in the current topology file. See
“Uninstalling the entire Tivoli Netcool
Performance Manager system” on page 228
for more information.
-DCheckUser=true Specifies whether the deployer checks to see

if it is running as root before performing
install operations. Possible values are true
and false. For most install scenarios,
running the deployer as the operating
system root is required. You can use this
option to override root user checking.
Default is true.
Enables you to specify the database client
home, so the wizard screen that prompts
-DOracleClient=oracle_client_home you for that information is skipped.
-DDB2Client=DB2_client_home
Specifies the hostname or IP address where

the database server resides.
-DOracleServerHost=hostname
-DDB2ServerHost=hostname

Option Description
Specifies the communication port used by
the database server. Default is 1521 for
-DOracleServerPort=port Oracle and 60000 for IBM DB2.
-DDB2ServerPort=port
Specifies the database server ID. Default is

PV.
-DOracleSID=sid
-DDBName=database name
Specifies the administrator username for the

database server. Default is PV_INSTALL.
-DOracleAdminUser=admin_user
-DDB2AdminUser=admin_user
Specifies the administrator password for the

database server. Default is PV.
-DOracleAdminPassword=
admin_password
-DDB2AdminPassword=
admin_password
-DPrimary=true Indicates that the deployer is running on the

primary server. This option is used by the
Topology Editor to invoke the deployer. Use
this option to force a channel configuration
update in the database.
-DTarget=id Instructs the deployer to install or uninstall
the component specified using the id
parameter, regardless of the current status of
the component in the topology. Use this
option to force an install or uninstall of a
component in a high-availability (HA)
environment, or when fixing an incomplete
or damaged installation. Table 12 contains a
list of possible values for the id parameter.
-DTopologyFile=topology_file_path Tells the deployer to use the specified
topology file instead of prompting for the
file.
-DTrace=true Causes the deployer to log additional
diagnostic information.

Option Description
-DUsehostname=hostname Enables you to override the hostname that
the deployer uses to define where it is
running. This option is useful when
hostname aliasing is used and none of the
hostnames listed in the topology.xml file
match the hostname of the machine where
the deployer is running.
Using the -DTarget option

How to use the -DTarget option to force an install or uninstall of a component or
damaged installation.
You can use the -DTarget option to force an install or uninstall of a component in a
high-availability (HA) environment, or when fixing an incomplete or damaged
installation. The -DTarget option uses the following syntax:
deployer.bin -DTarget=id
where id is a supported target identifier code.
If you are using the -DTarget option to force the uninstall of a component, you
must also specify the -Daction=uninstall option when you run the deployer
application. The following example shows how to force the uninstallation of
DataMart on the local system:
deployer.bin -Daction=uninstall -DTarget=DMR
Table 12 shows the possible values for the id parameter.
Table 12: Target Identifier Codes
Value Description
DB Instructs the deployer to install the database
setup components on the local machine.
DM Instructs the deployer to install the
DataMart component on the local machine.
DV Instructs the deployer to install the
DataView component on the local machine.
DC Instructs the deployer to install the
DataChannel component on the local
machine.
DL Instructs the deployer to install the
DataLoad component on the local machine.
DBR Instructs the deployer to remove the
database setup components from the local
machine. Requires the -Daction=uninstall
option.
DMR Instructs the deployer to remove the
DataMart component from the local
option.
Appendix D. Deployer CLI options 261

Value Description
DVR Instructs the deployer to remove the
DataView component from the local
option.
DCR Instructs the deployer to remove the
DataChannel component from the local
option.
DLR Instructs the deployer to remove the
DataLoad component from the local
option.
DBU Instructs the deployer to upgrade the
database setup components on the local
machine.
DMU Instructs the deployer to upgrade the
DataMart component on the local machine.
DVU Instructs the deployer to upgrade the
DataView component on the local machine.
DCU Instructs the deployer to upgrade the
DataChannel component on the local
machine.
DLU Instructs the deployer to upgrade the
DataLoad component on the local machine.
When you run the deployer using the -DTarget option, note the following:
v The deployer does not perform component registration in the versioning tables
of the database.
v The deployer does not upload modified topology information to the database.
v The deployer does not allow you to you select other nodes besides the local
node in the Node Selection panel.
v In the case of an uninstall, the deployer does not remove the component from
the topology.

Appendix E. Secure file transfer installation
This section describes the OpenSSH installation, configuration, and testing process
in detail for each platform.
Overview
How to install OpenSSH for Secure File Transfer (SFTP) among Tivoli Netcool
Performance Manager components.
This document explains how to install OpenSSH for Secure File Transfer (SFTP)
among Tivoli Netcool Performance Manager components. You must be proficient in
your operating system and have a basic understanding of public/private key
encryption when working with SFTP. For the purposes of this document, an SFTP
"client" is the node that initiates the SFTP connection and login attempt, while the
SFTP "server" is the node that accepts the connection and permits the login
attempt. This distinction is important for generating public/private keys and
authorization, as the SFTP server should have the public key of the SFTP client in
its authorized hosts file. This process is described in more detail later.
For Tivoli Netcool Performance Manager to use SFTP for the remote execution of
components and file transfer, OpenSSH must be configured for key-based
authentication when connecting from the Tivoli Netcool Performance Manager
account on the client (the host running the Tivoli Netcool Performance Manager
process that needs to use SFTP) to the account on the server. In addition, the host
keys must be established such that the host key confirmation prompt is not
displayed during the connection.
Enabling SFTP
The use of SFTP is supported in Tivoli Netcool Performance Manager.
Tivoli Netcool Performance Manager SFTP can be enabled for a single component,
set of components, or all components as needed. This table shows the Tivoli
Netcool Performance Manager components that support SFTP:
Client Server Description

Node on which DataChannel All other DataChannel nodes Installer can use SFTP to
resides. to be installed. install Tivoli Netcool
Performance Manager
software to remote locations.
Bulk Collector DataMart Inventory Transfer of inventory files.
FTE Bulk Collector FTE transfers files from
BCOL to CME.
FTE DataLoad SNMP collector Transfer of SNMP data.
CME/LDR Remote CME Downstream CME and LDR
both transfer files from
remote CME.
Note: This document is intended only as a guideline to installing OpenSSH. Tivoli

Netcool Performance Manager calls the ssh binary file directly and uses the SFTP

protocol to transfer files, so the essential Tivoli Netcool Performance Manager
requirement is that OpenSSH is used and public key authentication is enabled. The
following procedures are examples of one method of installing and configuring
OpenSSH. The precise method and final configuration for your site should be
decided by your local operating system security administrator.
For detailed information about OpenSSH and its command syntax, visit the
following URL:
http://www.openssh.com/manual.html
Installing OpenSSH
This section describes the steps necessary to install OpenSSH on AIX, Solaris and
Linux.
Note: The following sections refer to the earliest supported version of the required
packages. Refer to the OpenSSH documentation for information about updated
versions.
AIX systems
To install OpenSSH on AIX systems you must follow all steps described in this
section.
Download the required software packages

How to download the required packages.
Procedure
1. In your browser, enter the following URL:
http://www-03.ibm.com/servers/aix/products/aixos/linux/download.html
2. From the AIX Toolbox for Linux Applications page, download the following
files according to the instructions to each Tivoli Netcool Performance Manager
system where SFTP is to be used:
v prngd - Pseudo Random Number Generation Daemon (prngd-0.9.29-
1.aix5.1.ppc.rpm or later).
v zlib - zlib compression and decompression library (zlib-1.2.2-
4.aix5.1.ppc.rpm or later).
3. From the AIX Toolbox for Linux Applications page, click the AIX Toolbox
Cryptographic Content link.
4. Download the following files to each Tivoli Netcool Performance Manager
openssl-0.9.7g-1.aix5.1.ppc.rpm or later
5. In your browser, enter the following URL:
http://sourceforge.net/projects/openssh-aix
6. From the OpenSSH on AIX page, search for and download the following files
according to the instructions to each Tivoli Netcool Performance Manager
openssh-4.1p1_53.tar.Z or later

Install the required packages
How to install the required packages on each Tivoli Netcool Performance Manager
system where SFTP is to be used.
Procedure
1. Log in to the system as root.
2. Change your working directory to the location where the software packages
have been downloaded by using the following command:
# cd /download/location
3. Run the RPM Packaging Manager for each package, in the specified order,
using the following commands:
# rpm -i zlib
# rpm -i prndg
# rpm -i openssl
4. Uncompress and untar the openssh tar file by entering the following
commands:
$ uncompress openssh-4.1p1_53.tar.Z
$ tar xvf openssh-4.1p1_53.tar
5. Using the System Management Interface Tool (SMIT), install the openssh
package.
6. Exit from SMIT.
Configure OpenSSH server to start up on system boot

After installing the OpenSSH server and client, you must configure the OpenSSH
server to start up on system boot.
Procedure
To configure the server to start on system boot, modify the /etc/rc.d/rc2.d/Ssshd

init script as follows:
#! /usr/bin/sh
#
# start/stop the secure shell daemon
case "$1" in
’start’)
# Start the ssh daemon
if [ -x /usr/local/sbin/sshd ]; then
echo "starting SSHD daemon"
/usr/local/sbin/sshd & fi
;;
’stop’)
# Stop the ssh daemon
kill -9 `ps -eaf | grep /usr/local/sbin/sshd | grep -v grep |
awk ’{print $2}’ | xargs`
;;
*)
echo "usage: sshd {start|stop}"
;;
Appendix E. Secure file transfer installation 265

Solaris systems
OpenSSH is required for SFTP to work with Tivoli Netcool Performance Manager
on Solaris systems.
The version of SSH installed with the Solaris 10 operating system is not supported.
Note: The following sections refer to the current version of the required packages.
Refer to the OpenSSH documentation for information about updated versions.
To install OpenSSH on Solaris systems, follow all steps described in this section.
Download the required software packages

How to download the required packages.
Procedure
1. In your browser, enter the following URL: http://www.sunfreeware.com
2. From the Freeware for Solaris page, follow the instructions to download the
following files to each Tivoli Netcool Performance Manager system where SFTP
is to be used. Ensure that you download the correct files for your version of
Solaris.
v gcc - Compiler. Ensure that you download the full Solaris package and not
just the source code (gcc-3.2.3-sol9-sparc-local.gz or later).
v openssh - SSH client (openssh-4.5p1-sol-sparc-local.gz or later).
v openssl - SSL executable files and libraries (openssl-0.9.8d-sol9-sparc-local.gz
or later).
v zlib - zlib compression and decompression library (zlib-1.2.3-sol9-sparc-
local.gz or later).
What to do next
Note: The user should ensure they have the libcrypto.so.0.9.8 instead of
libcrypto.so.1.0.0. to use OpenSSH on Solaris.
Install the required software packages

How to install the required software packages.
About this task
To install the required packages, do the following on each Tivoli Netcool

Performance Manager system where SFTP is to be used:
Procedure
2. Change your working directory to the location where the software packages
have been downloaded using the following command:
# cd /download/location
3. Copy the downloaded software packages to /usr/local/src, or a similar
location, using the following commands:

# cp gcc-version-sparc-local.gz /usr/local/src
# cp zlib-version-sparc-local.gz /usr/local/src
# cp openssl-version-sparc-local.gz /usr/local/src
# cp openssh-version-sparc-local.gz /usr/local/src
4. Change your working directory to /usr/local/src using the following
command:
# cd /usr/local/src
5. Install the gcc compiler:
a. Uncompress gcc using the following command:
gunzip gcc-version-sparc-local.gz
b. Add the gcc package using the following command:
pkgadd -d gcc-version-sparc-local
6. Install the zlib compression library:
a. Uncompress zlib using the following command:
gunzip zlib-version-sparc-local.gz
b. Add the zlib package using the following command:
pkgadd -d zlib-version-sparc-local
7. Install the OpenSSL executable and binary files:
a. Uncompress OpenSSL using the following command:
gunzip openssl-version-sparc-local.gz
b. Add the OpenSSL package using the following command:
pkgadd -d openssl-version-sparc-local
8. Install the OpenSSH client:
a. Uncompress OpenSSH using the following command:
gunzip openssh-version-sparc-local.gz
b. Add the OpenSSH package using the following command:
pkgadd -d openssh-version-sparc-local
c. Create a group and user for sshd using the following commands:
groupadd sshd
useradd -g sshd sshd
9. Optional: Remove Sun SSH from the path and link OpenSSH:
a. Change your working directory to /usr/bin using the following command:
cd /usr/bin
b. Move the Sun SSH files and link the OpenSSH files using the following
commands:
# mv ssh ssh.sun
# mv ssh-add ssh-add.sun
# mv ssh-agent ssh-agent.sun
# mv ssh-keygen ssh-keygen.sun
# mv ssh-keyscan ssh-keyscan.sun
# ln -s /usr/local/bin/ssh ssh
# ln -s /usr/local/bin/ssh-add ssh-add
# ln -s /usr/local/bin/ssh-agent ssh-agent
# ln -s /usr/local/bin/ssh-keygen ssh-keygen
# ln -s /usr/local/bin/ssh-keyscan ssh-keyscan
Configure OpenSSH server to start up on system boot

After installing the OpenSSH server and client, you must configure the OpenSSH
server to start up on system boot.
About this task
To configure the server to start on system boot:

Procedure
1. Create or modify the /etc/init.d/sshd init script as follows:
#! /bin/sh
#
# start/stop the secure shell daemon
case "$1" in
’start’)
# Start the ssh daemon

if [ -x /usr/sbin/sshd ]; then
echo "starting SSHD daemon"
/usr/sbin/sshd &
fi
;;
’stop’)
# Stop the ssh daemon
/usr/bin/pkill -x sshd
;;
*)
echo "usage: /etc/init.d/sshd {start|stop}"
;;
2. Check that /etc/rc3.d/S89sshd exists (or any sshd startup script exists) and is
a soft link to /etc/init.d/sshd.
If not, create it using the following command:
ln -s /etc/init.d/sshd /etc/rc3.d/S89sshd
Linux systems
OpenSSH is required for VSFTP to work with Tivoli Netcool Performance Manager.
OpenSSH is installed by default on any RHEL system.
Configuring OpenSSH
This section describes how to configure the OpenSSH server and client.
Configuring the OpenSSH server

How to configuring the OpenSSH Server on Linux.
About this task
To configure the OpenSSH Server, follow these steps on each Tivoli Netcool
Performance Manager system where SFTP is to be used:
Procedure
2. Change your working directory to the location where the OpenSSH Server was
installed (/usr/local/etc/sshd_config by default) using the following
command:
# cd /usr/local/etc
3. Using the text editor of your choice, open the sshd_config file. This is an
example of a sshd_config file:

#***************************************************************************
# sshd_config
# This is the sshd server system-wide configuration file. See sshd(8)
# for more information.
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.
Port 22
Protocol 2
ListenAddress 0.0.0.0
HostKey /usr/local/etc/ssh_host_dsa_key
SyslogFacility AUTH
LogLevel INFO
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
RhostsAuthentication no
RhostsRSAAuthentication no
HostbasedAuthentication no
PasswordAuthentication yes
ChallengeResponseAuthentication no
Subsystem sftp /usr/local/libexec/sftp-server
#****************************************************************
4. Locate the Protocol parameter. For security purposes, it is recommended that
this parameter is set to Protcol 2 as follows:
Protocol 2
5. Locate the HostKeys for protocol version 2 parameter and ensure that it is
set as follows:
HostKey /usr/local/etc/ssh_host_dsa_key
6. Locate the PubkeyAuthentication parameter and ensure that it is set as follows:
PubkeyAuthentication yes
7. Locate the PasswordAuthentication parameter and ensure that it is set as
follows:
PasswordAuthentication yes
8. Locate the Subsystem parameter and ensure that the SFTP subsystem and path
are correct. Using defaults, the Subsystem parameter appears as follows:
Subsystem sftp /usr/local/libexec/sftp-server
Configuring OpenSSH client

How to configure OpenSSH client.
The OpenSSH client requires no configuration if it used in its default form. The
default location for the OpenSSH client file is /usr/local/etc/ssh_config.
Generating public and private keys

By default, OpenSSH generates public and private keys for the root user. You must
generate public and private keys with the Tivoli Netcool Performance Manager
user for the SFTP functions to work in Tivoli Netcool Performance Manager.
About this task
To generate public and private keys:
Procedure
1. Log in as pvuser on the node that will be the SFTP client. This node is
referred to as SFTPclient in these instructions, but you must replace
SFTPclient with the name of your node.

2. Create an .ssh directory in the home directory of the Tivoli Netcool
Performance Manager user, set permissions to x/r/w for owner (700), then
change to the directory using the following commands:
$ mkdir ~/.ssh
$ chmod 700 ~/.ssh
$ cd ~/.ssh
3. Generate a DSA public and private key with no passphrase (DSA encryption
is used as an example). The following example shows a UNIX server called
SFTPclient:
$ /usr/local/bin/ssh-keygen -t dsa -f SFTPclient -P ""
Generating public/private dsa key pair.

Your identification has been saved in SFTPclient.
Your public key has been saved in SFTPclient.pub.
The key fingerprint is: 77:67:2f:34:d4:2c:66:db:9b:1f:9a:36:fe:c7:07:c6 pvuser@SFTPclient
4. The previous command generates two files, SFTPclient (the private key) and
SFTPclient.pub (the public key). Copy the private key to id_dsa in the ~/.ssh
directory by entering the following command:
$ cp -p ~/.ssh/SFTPclient ~/.ssh/id_dsa
id_dsa identifies the node when it contacts other nodes.
5. To permit Tivoli Netcool Performance Manager components on SFTPclient to
communicate, you must append the contents of the SFTPclient.pub key file to
the file authorized_keys in the ~/.ssh directory by using the following
commands:
cd ~/.ssh
cat SFTPclient.pub >> authorized_keys
6. Log on to the other node that will be the SFTP server. This node is referred to
as SFTPserver in these instructions, but you must replace SFTPserver with the
name of your node.
7. Repeat Step 1 through Step 5 on the SFTPserver node, replacing SFTPclient
with SFTPserver.
8. Copy (with FTP, scp, or a similar utility) the public key from SFTPclient to
SFTPserver and append the contents of the key file to the file authorized_keys
in the ~/.ssh directory. If you cut and paste lines, be careful not to introduce
carriage returns.
Use the following FTP session as an example:
SFTPserver:~/.ssh> ftp SFTPclient
Connected to SFTPclient.
220 SFTPclient FTP server (SunOS 5.8) ready.
Name (SFTPclient:pvuser): pvuser
331 Password required for pvuser.
Password:
230 User pvuser logged in.

ftp> bin
200 Type set to I.
ftp> get .ssh/SFTPclient.pub
200 PORT command successful.
150 Binary data connection for .ssh/SFTPclient.pub
226 Binary Transfer complete.
local: .ssh/SFTPclient.pub remote: .ssh/SFTPclient.pub
ftp> quit
221 Goodbye.
SFTPserver:~/.ssh> cat SFTPclient.pub >> authorized_keys
9. Optional: If you want to set up bidirectional SFTP, repeat Step 8, but from the
SFTserver node to the SFTPclient node.

Note: This step is not needed for Tivoli Netcool Performance Manager.
Use the following FTP session as an example:
SFTPclient:~/.ssh> ftp SFTPserver
Connected to SFTPserver.
220 SFTPserver FTP server (SunOS 5.8) ready.
Name (SFTPserver:pvuser): pvuser
331 Password required for pvuser.
Password:
230 User pvuser logged in.
ftp> bin
180 Tivoli Netcool Performance Manager Installation Guide, Version 1.4.2
200 Type set to I.
ftp> get .ssh/SFTPserver.pub
200 PORT command successful.
150 Binary data connection for .ssh/SFTPserver.pub
226 Binary Transfer complete.
local: .ssh/SFTPserver.pub remote: .ssh/SFTPserver.pub
ftp> quit
221 Goodbye.
SFTPclient:~/.ssh> cat SFTPserver.pub >> authorized_keys
10. When finished, the SFTPclient and SFTPserver should look similar to the
following:
SFTPclient:~/.ssh> ls -al ~/.ssh
total 10
drwx------ 2 pvuser pvuser 512 Nov 25 16:56 .

drwxr-xr-x 28 pvuser pvuser 1024 Nov 25 15:25 ..
-rw------- 1 pvuser pvuser 883 Nov 25 15:21 id_dsa
-rw-r--r-- 1 pvuser pvuser 836 Nov 25 16:33 known_hosts
SFTPserver:~/.ssh> ls -al ~/.ssh

total 10
drwx------ 2 pvuser pvuser 512 Nov 25 16:56 .

drwxr-xr-x 28 pvuser pvuser 1024 Nov 25 15:25 ..
-rw------- 1 pvuser pvuser 883 Nov 25 15:21 id_dsa
-rw-r--r-- 1 pvuser pvuser 836 Nov 25 16:33 known_hosts
The important files are:
v authorized_keys, which contains the public keys of the nodes that are
authorized to connect to this node
v id_dsa, which contains the private key of the node it is on
v known_hosts, which contains the public keys of the node that you want to
connect to
For security, the private key (id_dsa) should be -rw------. Likewise, the
public key Node<number>.pub, authorized_keys, and known_hosts should be
-rw-r--r--.
The directory itself should be -rwx-----.
Note: The directory that contains the .ssh directory might also need to be
writable by owner.
11. The first time you connect using SSH or SFTP to the other node, it will ask if
the public key fingerprint is correct, and then save that fingerprint in
known_hosts. Optionally, you can manually populate the client's known_hosts
file with the server's public host key (by default, /usr/local/etc/
ssh_host_dsa_key.pub).
For large-scale deployments, a more efficient and reliable procedure is:
a. From one host, ssh to each SFTP server and accept the fingerprint. This
builds a master known_hosts file with all the necessary hosts.

b. Copy that master file to every other SFTP client.
Note: If the known_hosts file has not been populated and secure file
transfer (SFTP) is attempted through Tivoli Netcool Performance Manager,
SFTP fails with vague errors.
Testing OpenSSH and SFTP

How to test OpenSSH and SFTP.
About this task
For the following tests, the commands normally work without asking for a
password. If you are prompted for a password, public/private key encryption is
not working.
Ensure that you specify the full path to the ssh and sshd binary files. Otherwise,
you might use another previously installed SSH client or server.
To test OpenSSH and SFTP:
Procedure
1. On both nodes, kill any existing sshd processes and start the sshd process from
the packages you installed, by entering the following commands:
pkill -9 sshd;/usr/local/sbin/sshd &
The path can be different depending on the installation.
2. From SFTPclient, run the following command:
/usr/local/bin/ssh SFTPserver
3. From SFTPclient, run the following command:
/usr/local/bin/sftp SFTPserver
4. Optional: If you set up bidirectional SFTP, run the following command from
SFTPserver:
/usr/local/bin/ssh SFTPclient
5. Optional: If you set up bidirectional SFTP, run the following command from
SFTPserver:
/usr/local/bin/sftp SFTPclient
6. If all tests allow you to log in without specifying a password, follow the Tivoli
Netcool Performance Manager instructions on how to enable SFTP in each
Tivoli Netcool Performance Manager component. Make sure to specify the full
path to SSH in the Tivoli Netcool Performance Manager configuration files. In
addition, make sure the user that Tivoli Netcool Performance Manager is run as
is the same as the user that you used to generate keys.

Troubleshooting
How to troubleshoot OpenSSH and its public keys.
About this task
If you find that OpenSSH is not working properly with public keys:
Procedure
1. Check the ~/known_hosts file on the node acting as the SSH client and make
sure the client host name and IP information is present and correct.
2. Check the ~/authorized_keys file on the node acting as the SSH server and
make sure that the client public key is present and correct. Ensure that the
permissions are -rw-r--r--.
3. Check the ~/id.dsa file on the node acting as the SSH client and make sure
that the client's private key is present and correct. Ensure that the permissions
are -rw-------.
4. Check the ~/.ssh directory on both nodes to ensure that the permissions on
the directories are -rwx------.
5. Check for syntax errors (common ones are misspelling authorized_keys and
known_hosts without the "s" at the end). In addition, if you copied and pasted
keys into known hosts or authorized keys files, you probably have introduced
carriage returns in the middle of a single, very long line.
6. Check the ~ (home directory) permissions to ensure that they are only writable
by owner.
7. If the permissions are correct, kill the sshd process and restart in debug mode
as follows:
pkill -9 sshd /usr/local/sbin/sshd -d
8. Test SSH again in verbose mode on the other node by entering the following
command:
/usr/local/bin/ssh -v SFTPserver
9. Read the debugging information about both client and server and
troubleshoot from there.
10. Check the log file /var/adm/messages for additional troubleshooting
information.
Tivoli Netcool Performance Manager SFTP errors

Errors that you may encounter.
In the Tivoli Netcool Performance Manager log files, you might see the following
errors:
v [DC10120] FTPERR error: incompatible version, result: sftp status:
SSH2_FX_FAILURE:: incompatible version, log:
This error indicates that the SSH server (sshd) is SSH2 rather than OpenSSH.
OpenSSH is required for Tivoli Netcool Performance Manager to function
correctly.
v [DC10120] FTPERR error: bad version msg, result: sftp status:
SSH2_FX_NO_CONNECTION:: connection not established - check ssh
configuration, log:

This error indicates that the SSH configuration is incorrect or the wrong version
of the SSH server (sshd) is running. OpenSSH is required for Tivoli Netcool
Performance Manager to function correctly.

Appendix F. LDAP integration
Detailed information on how to configure LDAP (Lightweight Directory Access
Protocol) as a default authentication/authorization mechanism for Tivoli Netcool
Supported LDAP servers

A list of LDAP servers supported by Tivoli Netcool Performance Manager.
v Domino 6.5.4, 7.0
v IBM Tivoli Directory Server 6.3
v IBM z/OS Security Server 1.6, 1.7
v IBM z/OS.e Security Server 1.6, 1.7
v Microsoft Active Directory 2000, 2003
v Novell eDirectory 8.7.3, 8.8
LDAP configuration
There are two scenarios for LDAP Configuration; Configure LDAP during
installation of Tivoli Netcool Performance Manager and configure LDAP after the
Tivoli Netcool Performance Manager installation is complete.
For postinstallation of LDAP configuration, see http://www-01.ibm.com/support/

knowledgecenter/SSEKCU_1.1.0.3/com.ibm.psc.doc_1.1.0.3/config/
psc_t_config_user_registry.html. After this process is complete, do the following
tasks:
v Restart the Jazz for Service Management server after the configuration is
complete.
v Assign Tivoli Netcool Performance Manager roles to LDAP users. For more
information, see “Assigning Tivoli Netcool Performance Manager roles to LDAP
users” on page 277
The configuration of LDAP as a default authentication and authorization

mechanism for Tivoli Netcool Performance Manager is achieved by using the
Topology Editor. Follow the steps from “Enable LDAP configuration” onwards
until “Assigning Tivoli Netcool Performance Manager roles to LDAP users” on
page 277.
Enable LDAP configuration

The LDAP configuration option becomes available after adding a Dashboard
Application Services Hub to your topology.
About this task
Note: The process of installing a Dashboard Application Services Hub is described

in Chapter 4, “Installing Jazz for Service Management,” on page 97.
To enable LDAP configuration:

Procedure
1. In Logical View of Topology Editor, select the Dashboard Application Services
Hub that you have installed.
2. Open Advanced Properties.
3. Click the checkbox opposite the
IAGLOBAL_USER_REGISTRY_LDAP_SELECTED property. This enables
LDAP.
4. In Advanced Properties, enter the LDAP connection details. This requires that
you populate the following fields:
WAS_USER_NAME
This is the name you have registered as the Advanced Properties user.
For example, "smadmin".
IAGLOBAL_LDAP_BIND_DN
This username specified must have read and write permissions in
LDAP 3. Typically this will be an LDAP administrator username. For
example "cn=Directory Manager".
IALOCAL_LDAP_BIND_PASSWORD
This is the password for the Bind Distinguished Name specified.
IAGLOBAL_LDAP_NAME
This is the LDAP server host name. Should this LDAP server exist
behind firewall, make sure that this host has been authenticated.
IAGLOBAL_LDAP_PORT
For example, "1389".
IAGLOBAL_LDAP_REPOSITORY_ID
This is a string used to identify the LDAP repository, which can be set
to the string of your choice.
IAGLOBAL_LDAP_BASE_ENTRY
The distinguished name of a base entry in LDAP.
For example, for IBM the base entry is o=IBM, c=US.
Verifying the DataView installation

Verify that the correct users are within the correct groups.
About this task
When the DataView installation is complete, it should have created two users and
two groups in LDAP:
Users:
v tnpm
v tnpmScheduler
Groups:
v tnpmUsers
v tnpmAdministrators

Procedure
Verify from the UI that the users tnpm and tnpmScheduler are members of the
tnpmAdministrators group.
Assigning Tivoli Netcool Performance Manager roles to LDAP

users
To successfully authenticate your LDAP user, you need to assign them to one of
the appropriate roles
Procedure
To successfully authenticate you LDAP user, you must assign them to one of the
following roles:
v tnpmUser
v tnpmAdministrator
This can be done by smadmin user, by navigating to Users and Groups > User
Roles, and assigning the correct roles.
Alternatively tipcli.sh can be used for assigning roles to the user.
JazzSM/profile/bin/tipcli.sh MapRolesToUser --username
JazzSM_HOME<DASH_admin_user> --password <DASH_admin_password>
--userID <userUniqueId> --rolesList <roleName>
Where <userUniqueId> is the concatenation of user name and realm in which user
information is stored.
For example:
JazzSM_HOME/JazzSM/profile/bin/tipcli.sh MapRolesToUser --username
<DASH_admin_user> --password <DASH_admin_password> --userID
uid=<user_name>,dc=<server>,dc=<server>,dc=<company>,dc=com --rolesList
tnpmUser
Roles specific to an application, such as tnpmUser for Tivoli Netcool Performance

Manager are not stored in LDAP. For example, if you assign a Tivoli Netcool
Performance Manager role to an LDAP user on DASH_instance1, you must also
assign the same role to the user on DASH_instance2. Otherwise, the user cannot
authenticate on DASH_instance2.
What to do next
Assign tnpmUser and tnpmAdministrator roles to the LDAP users at the Jazz for
Service Management User Roles page after LDAP integration is done. Otherwise,
LDAP users might not able to view the DataView reports.
Appendix F. LDAP integration 277

Appendix G. Installing an interim fix
Describes how to install an interim fix (or patch) release of Tivoli Netcool
Overview
Interim fix installation overview.
Unlike major, minor, and maintenance releases, which are planned, patch releases
(interim fixes and fix packs) are unscheduled and are delivered under the
following circumstances:
v A customer is experiencing a "blocking" problem and cannot wait for a
scheduled release for the fix.
v The customer's support contract specifies a timeframe for delivering a fix for a
blocking problem and that timeframe does not correspond with a scheduled
release.
v Development determines that a patch is necessary.
Note: Patches are designed to be incorporated into the next scheduled release,
assuming there is adequate time to integrate the code.
Installation rules
Rules that apply to the installation of patches.
Note the following installation rules for patch installations:

v Apply fix to Database before any other components.
v Fixes for the Database and DataMart must be installed on that host.
v Fixes for the DataChannel, DataLoad, DataMart and DataView can be installed
remotely from the local host in a distributed system.
v Fix packs are installed on general availability (GA) products.
v Sequentially numbered fix packs can be installed on any fix pack with a lower
number.
v Interim fixes must be installed on the absolute fix pack.
The patch installer verifies that your installation conforms to these rules.
Behavior and restrictions

Behaviour and restrictions that apply to the installation of patches.
If remote installation of a component is not possible, the deployer grays out the
any remote component host on the node selection page.
The maintenance deployer must run locally on each DataMart host to apply a
patch.

Before you begin
What you must do before you begin a patch installation.
A patch release updates the file system for the component that the patch is
intended for and updates the versioning information in the database.
To verify that the versioning was updated correctly for the components in the
database, you can run several queries both before and after the installation and
compare the results. For detailed information, see the Tivoli Netcool Performance
Manager Technical Note: Tools for Version Reporting document.
Installing a patch
How to install a patch.
About this task
To install a patch:
Procedure
1. You must have received or downloaded the maintenance package from IBM
Support. The maintenance package contains the Maintenance Descriptor File,
an XML file that describes the contents of the fix pack. Follow the instructions
in the README for the fix pack release to obtain the maintenance package
and unzip the files.
Note: for each tar.gz file, you must unzip them, and then un-tar them. For
example:
gunzip filename.tar.gz
tar -xvf filename.tar
2. Log in as root.
3. Set and export your DISPLAY environment variable (see “Setting up a remote
X Window display” on page 70).
4. Start the patch deployer using one of the following methods:
From the launchpad:
a. Click Start Tivoli Netcool Performance Manager Maintenance Deployer
option in the list of tasks.
b. Click the Start Tivoli Netcool Performance Manager Maintenance
Deployer link.
From the command line:
v Run the following command:
# ./deployer.bin -Daction=patch
5. The deployer displays a welcome page. Click Next to continue.
6. Accept the default location of the base installation directory of the database
JDBC driver.
/opt/oracle/product/12.1.0-client32

or, click Choose to navigate to another directory. Click Next to continue.
7. On the patch folder page, click Choose to select the patch you want to install.
8. Navigate to the directory that contains the files for the fix pack, and click into
the appropriate directory. Click Select to select that directory, then click Next
to continue.
9. A pop-up window asks whether you want to download the topology file.
Click Yes.
10. Verify that all of the fields for the database connection are filled in with the
correct values:
Database hostname
Enter the name of the database host.
Port
Specifies the port number used for communication with the

database. The default value is 1521.
Specifies the port number used for communication with the

database. The default value is 60000.
Database user
Specifies the username used to access the database. The default value
is PV_INSTALL.
Database Password
Enter the password for the database user account (for example, PV).
Database name
Specifies the SID for the database. The default value is PV.
Specifies the name of database. The default value is PV.

Click Next.
11. When the topology has been downloaded from the database, click Next.
12. The node selection window shows the target systems and how the files will be
transferred. The table has one row for each machine where at least one Tivoli
Netcool Performance Manager component will be installed. Verify the settings,
then click Next to continue.
13. The deployer displays summary information about the installation. Review the
information, then click Next.
The deployer displays the table of installation steps.
14. Run through each installation step just as you would for a normal installation.
15. When all the steps have completed successfully, click Done to close the
wizard.
Appendix G. Installing an interim fix 281

Appendix H. Error codes and log files
This appendix lists the Tivoli Netcool Performance Manager error messages and
log files.
See Appendix I, “Troubleshooting,” on page 305 for information about

troubleshooting problems with the Tivoli Netcool Performance Manager
installation.
Error codes
The following sections describe the error messages generated by the Deployer, the
Toplogy Editor and InstallAnywhere.
Deployer messages
The Deployer messages.
Table 13 lists the error messages returned by the Tivoli Netcool Performance
Manager deployer.
Table 13: Deployer Messages
Error Code Description User Action
DataMart Messages
GYMCI5101E The DataMart installation See the DataMart installer
failed. logs for details.
Database Configuration Messages
GYMCI5201E The database installation See the root_install_dir
failed. See the installation log /database/install/log/
for details. Oracle_SID /install.log file.
GYMCI5202E The database uninstallation Check the syntax and run
script failed because of a the script again.
syntax error. This script must
be run as oracle. For
example: ./uninstall_db
/var/tmp/PvInstall/
install.cfg.silent
GYMCI5204E The database could not be Check that all the required
removed because some Oracle variables are set and
Oracle environment variables try again.
are not correctly set. Some or
all of the Oracle environment
variables are not set (for
example, ORACLE_HOME,
ORACLE_SID, or
ORACLE_BASE).

GYMCI5205E An error occurred when See the Oracle alert file for
trying to start the Oracle possible startup errors.
database. Resolve any problems
reported in the log and try
again.
GYMCI5206E An error occurred when See the Oracle alert file for
trying to shut down the possible shutdown errors.
Oracle database. Resolve any problems
reported in the log and try
again.
GYMCI5207E An error occurred while See the Oracle alert file for
querying the database to details of errors. You might
determine the data files that need to manually delete
are owned by the database. Oracle data files using
operating system commands.
GYMCI5208E This version of IBM Tivoli See the installation guide to
Netcool Performance know list of supported
Manager is not supported on operating systems.
the host operating system.
GYMCI5209E The database could not be Check that all the required
removed because some DB2 DB2 variables are set and try
environment variables are again.
not correctly set.
GYMCI5210E The database doesn't exists. Check whether the database
exists or not and try again.
GYMCI5211E An error occurred while the Check log files to get more
dropping database. details
DataChannel Messages
GYMCI5301E The database channel See the file root_install_dir
installation failed. See the /channel/install/log/
installation log for details. Oracle_SID/install.log.
GYMCI5401E An error occurred while See the message produced
running a script. with the error code for more
details.
GYMCI5402E Unable to find an expected See the message produced
file. with the error code for more
details.
GYMCI5403E The data in one of the files is See the message produced
not valid. with the error code for more
details.
file or expected data. with the error code for more
details.
GYMCI5405E Scripts cannot function Unset the variable and try
correctly because the again.
LD_ASSUME_KERNEL
variable is set.
GYMCI5406E An action parameter is See the message produced
missing. with the error code for more
details.

processing the tar command. with the error code for more
details.
GYMCI5408E The product version you are See the message produced
trying to install seems to be with the error code for more
for a different operating details.
system.
GYMCI5409E Unable to locate installed See the message produced
package information for the with the error code for more
operating system. details.
GYMCI5410E A file has an unexpected See the message produced
owner, group, or with the error code for more
permissions. details.
GYMCI5411E A problem was found by the See the message produced
PvCheck module when with the error code for more
checking the environment. details.
GYMCI5412E The installation module See the messages in standard
failed. error for more details.
GYMCI5413E The patch installation failed. See the messages in standard
error for more details.
GYMCI5414E The remove action failed. See the messages in standard
GYMCI5415E An unrecoverable error See the message produced
occurred while running the with the error code for more
script. details.
Dataload Messages
GYMCI5501E An error occurred when See the message produced
running the script. with the error code for more
details.
file. with the error code for more
details.
GYMCI5503E The data in one of the files is See the message produced
not valid. with the error code for more
details.
file or expected data. with the error code for more
details.
GYMCI5505E Scripts cannot function Unset the variable and try
correctly because the again.
LD_ASSUME_KERNEL
variable is set.
GYMCI5506E An action parameter is See the message produced
missing. with the error code for more
details.
processing the tar command. with the error code for more
details.
Appendix H. Error codes and log files 285

GYMCI5508E The product version you are See the message produced
trying to install seems to be with the error code for more
for a different operating details.
system.
GYMCI5509E Unable to locate installed See the message produced
package information for the with the error code for more
operating system. details.
GYMCI5510E A file has an unexpected See the message produced
owner, group or permissions. with the error code for more
details.
GYMCI5511E A problem was found by the See the message produced
PvCheck module when with the error code for more
checking the environment. details.
GYMCI5512E The installation module See the message produced
failed. with the error code for more
details.
GYMCI5513E The patch installation failed. See the messages in standard
GYMCI5514E The remove action failed. See the messages in standard
GYMCI5515E An unrecoverable error See the message produced
occurred while running the with the error code for more
script. details.
Prerequisite Checkers: Operating System
GYMCI6001E The syntax of the Correct the syntax and try
check_osscript is not correct. again.
The specified component
does not exist. The syntax
is:check_os
PROVISO_COMPONENT
where
PROVISO_COMPONENT is
DL, DC, DM, DB, or DV.
GYMCI6002E This version of IBM Tivoli See the check_os.ini file for
Tivoli Netcool Performance a list of supported operating
Manager is not supported on systems.
the host operating system.
GYMCI6003E The specified component Ensure that you have
does not exist or is not specified the correct
supported on this operating component. If you have, the
system. operating system must be
upgraded before the
component can be installed.
GYMCI6004E The operating system is not Check the product
at the prerequisite patch documentation for a list of
level. Some required required patches. Apply any
operating system patches are missing patches and try
not installed. again.
GYMCI6005E The host operating system is Perform the installation on a
not supported for this supported operating system.
installation.

GYMCI6006E In the /etc/security/limits Check the values in the
file, some values are missing check_os.ini and edit the
or incorrect. Values must not default stanza in the
be lower than specified in /etc/security/limits file so
the check_os.ini file. that valid values are
specified for all required
limits.
Prerequisite Checkers: Database
GYMCI6101E The syntax of the check_db Correct the syntax and try
script is not correct. The again.
syntax is: check_db [client -
server] [new - upgrade]
[ORACLE_SID or
tnsnames.ora entry]
GYMCI6102E The host operating system is Perform the installation on a
not supported for this supported operating system.
installation.
GYMCI6103E This version of the IBM See the check_os.ini file for
Tivoli Tivoli Netcool a list of supported operating
Performance Manager system versions.
database is not supported on
the current version of the
host operating system.
GYMCI6104E Some required Oracle Check the Oracle users
variables are missing or environment files (for
undefined. example, .profile and
.bash_profile).
GYMCI6105E An Oracle binary is missing Ensure that Oracle is
or not valid. correctly installed.
GYMCI6106E The instance of Oracle Check the list of supported
installed on the host is not at Oracle versions in the
a supported version. check_db.ini file.
GYMCI6107E Unable to contact the Oracle Check that your Oracle
server using the tnsping listener is running on the
utility with the specified database server. Start the
ORACLE_SID. listener if it is not running.
GYMCI6108E An Oracle instance is Check whether you have
running on the host where selected the correct host for a
you have requested a new new Oracle server
server installation. installation. If the selected
host is correct, remove the
existing Oracle instance first.
GYMCI6109E The number of bits (32 or 64) Check the list of supported
for the Oracle binary does Oracle versions in the
not match the values defined check_db.ini file.
in the check_db.ini file.
GYMCI6110E The installation method Pass the New or Upgrade
passed to the script is not option to the script.
valid. Valid installation
methods are New and
Upgrade.

GYMCI6111E The installation type passed Pass the Client or Server
to the script is not valid. option to the script.
Valid installation methods
are Client and Server.
GYMCI6112E The script was run with Check that a new server
options set for a new server installation is the correct
installation, but an Oracle action for this SID. If it is,
instance configuration file remove the existing Oracle
(init.ora) already exists for instance configuration files.
the specified SID. The
presence of the init.ora file
indicates the presence of an
Oracle instance.
GYMCI6113E A symbolic link was found Remove any symbolic links.
in the Oracle home path. The Specify the Oracle home path
Oracle home path cannot using only real directories.
contain any symbolic links.
GYMCI6114W Cannot contact the Oracle Check that the Oracle
Listener. The tnsping utility Listener is running. Start it if
was run to check the Oracle necessary.
Listener status, but, the
Listener could not be
contacted.
GYMCI6115E The semaphore and shared Check that the required
memory check failed. The /etc/system parameters are
sysdef command was used to set up for Oracle. Check that
check the values for the values of these
semaphores and shared parameters meet the
memory. The command did minimum values listed in the
not report the minimum check_db.ini file.
value for a particular
semaphore or shared
memory.
GYMCI6116E Could not find the Ensure that the bos.adt.lib
bos.adt.lib package in the package is installed and
COMMITTED state. The committed and then try
package might not be again.
installed. The package is
either not installed or not in
a COMMITTED state.
GYMCI6117E Could not log in to the Check that the database and
database. The verify base Oracle Listener are up and
option was used. The option running. If not, start them.
attempts to log into the
database to ensure it is
running. However, the script
could not log in to the
database.
GYMCI6118E The checkextc script failed. Check that the Tivoli Netcool
The verify base option was Performance Manager
used. The option runs the database was created
checkextc script to ensure properly.
external procedure calls can
be performed.

GYMCI6119E The tnsnames.ora file is Check that the tnsnames.ora
missing. A tnsnames.ora file file exists in the
in should exist in ORACLE_HOME
ORACLE_HOME /network/admin directory. If
/network/admin directory. it does not, create it.
GYMCI6120E Some required DB2 variables Check log files to get more
are missing or undefined. details.
GYMCI6121E A DB2 binary is missing or Ensure that DB2 is correctly
not valid. installed.
GYMCI6122E The instance of DB2 installed Check the list of supported
on the host is not a DB2 versions in the
supported version. check_DB2_[version]_db.ini
file.
GYMCI6123E A DB2 instance is not Check whether you have
running on the host where selected the correct host for a
you have requested a new new DB2 server installation.
server installation. If the selected host is correct,
start DB2 instance first.
GYMCI6124E The number of bits (32 or 64) Check the list of supported
for the DB2 binary does not DB2 versions in the
match the values defined in check_DB2_[version]_db.ini
the file.
check_DB2_[version]_db.ini
file.
GYMCI6125E A symbolic link was found Specify the Database Home
in the Database Home path. path by using only real
Remove any symbolic links. directories.
GYMCI6126E The RHEL kernel parameter Check that the values of
check failed. Check that the these parameters meet the
required /etc/system minimum values that are
parameters are setup for listed in the
DB2. check_DB2_[version]_db.ini
file.
Minimal Deployment: Post-Installation Messages
GYMCI7500E An internal processing error Check the logs and the
occurred in the script. output from the script. Look
for incorrect configuration or
improper invocation.
GYMCI7501E The required configuration Check for errors that
or messages files for the occurred during the
poc-post-install script are not installation steps.
in the same directory as the
script. These files should be
unpacked by the installer
together with the script.
GYMCI7502E An environment file is Check the poc-post-install
missing or is in the wrong configuration file. The
location. missing environment file and
expected path is identified in
the log file.

GYMCI7503E The SNMP DataLoad did not Check the SNMP DataLoad
start. The SNMP DataLoad log for errors during startup.
process (pvmd) failed to
start.
GYMCI7504E The network inventory Check the inventory log for
failed. New devices cannot errors. Ensure the DISC
be discovered unless the server and SNMP DataLoad
inventory runs successfully. (Collector) processes are
running.
GYMCI7505E The Report Grouping Check the inventory log file
operation failed. This action for more details of the
does not depend on any Report Grouping failure.
external application
processes. The database must
be running, and correct
DataMart grouping rule
definitions are required.
GYMCI7506E The DataChannel command Ensure that the required
line failed. It is possible that processes are running. Check
the CNS, CMGR, and AMGR the proviso.log for details of
processes are not running. the failure.
GYMCI7507E The Report User was not Ensure that the database is
created. The web user will running, and check for error
not be able to view reports. logs in the DataMart logs
The DataMart resmgr utility directory.
is used to add this
configuration to the
database. It is possible that
the database is not running.
GYMCI7508E Failed to associate a Report Ensure that the database is
User to a group. The report running, and check for error
user is associated with a logs in the DataMart logs
group to allow the user to directory. Ensure that the
view reports. The DataMart specified report group exists.
resmgr utility is used to add
this configuration to the
database. It is possible that
the database is not running.
GYMCI7509E A report user could not be Check for error and trace
deleted from the database. logs in the DataMart logs
directory.
GYMCI7510E Failed to create a Web User. Check the Web/application
The user will not be able to server log file for errors.
authenticate with the Ensure that the
Web/application server. Web/application server is
running.
GYMCI7511E The Web group could not be Check the Web/application
created, and the Web user server log file for errors.
might not be properly Ensure that the
configured to view reports. Web/application server is
running.

GYMCI7512E Failed to associate the Web Check the Web/application
User with a group. The Web server log file for errors.
user might not be properly Ensure that the
configured to view reports Web/application server is
unless successfully associated running. This step relies on
with a group. the database component
only.
GYMCI7513E Failed to delete Web Users. Check the Web/application
Web user authentication was server logs.
not removed.
GYMCI7514E The Channel Naming Service Check for walkback or error
failed to start. files in the DataChannel log
Cross-application or state directory.
communication cannot
function.
GYMCI7515E The central LOG server Check for walkback or error
failed to start. Logging for files in the DataChannel log
DataChannel will be or state directory.
unavailable.
GYMCI7516E The Channel Manager failed Check the proviso.log file
to start. DataChannel for errors. Check for
applications cannot be walkback or error files in the
started or stopped. DataChannel log or state
Application status will be directory.
unavailable.
GYMCI7517E The Application Manager Check the proviso.log file
failed to start. DataChannel for errors. Check for
applications cannot be walkback or error files in the
started or stopped. DataChannel log or state
Application status will be directory.
unavailable.
GYMCI7518E Failed to create the DV user Check the poc-post-install
group. The DV user will login /var/tmp for more
remain in the Orphans details on the error
group. condition.
GYMCI7519E Failed to associate the DV Check the poc-post-install
user to the DV group. The login /var/tmp for more
DV user will remain in the details on the error
Orphans group. condition.
GYMCI7520E The Web Application server Start the Web Application
is not running or took too server as documented.
long to start up.
GYMCI7597E The MIB-II Technology Pack Add the MIB2 Technology
jar file was not found in the Pack JAR file to the directory.
specified directory. Remove other JAR files and
try again.
GYMCI7598E Too many jar files are present Remove the other JAR files
in the specified directory. and try again.
Only two jar file can be
present in the directory: the
ProvisoPackInstaller.jar and
the MIB-II Technology Pack
jar.

GYMCI7599E The Technology Pack
installer failed. Check the
Technology Pack installer
logs for details.
GYMCI6126E The RHEL kernel parameter Check that the values of
check failed. Check that the these parameters meet the
required /etc/system minimum values that are
parameters are setup for listed in the
DB2. check_DB2_[version]_db.ini
file.
Installer Action Messages and IA Flow Messages
GYMCI9998E Unable to find a message for See the installation log for
the key. The message was more details.
not retrieved from the
message catalog.
GYMCI9999E An unknown error occurred See the installation log for
for the component name more details.
with the error code. The
message could not be
retrieved from the catalog.
GYMCI9001E An error occurred during See the installation log for
installation. An exception has more details.
been generated during an
installation step.
GYMCI9002E An unrecoverable error See the installation log for
occurred when running the more details.
command .
GYMCI9003E An unrecoverable error See the installation log for
occurred while running a more details.
command.
GYMCI9004E An error occurred while See the installation log for
connecting to the database. more details.
performing a database more details.
operation.
GYMCI9006E Remote File Transfer has To continue, change the step
been disabled. property to Allow Remote
Execution and run the step
again, or manually transfer
the directory to the host.
When the transfer is
completed, change the step
status to Success and
continue the installation.
remotely connecting to more details.
target. There are connection
problems with the host.
connecting to target. There more details.
are connection problems with
the host.

copying install_dir. more details.
GYMCI9010E Remote Command Execution To continue: 1. Change the
has been disabled. step property to Set Allow
Remote Execution 2. Run the
step again. Or, manually
transfer the directory to the
host. When the transfer is
completed, change the step
status to Success and
continue the installation.
GYMCI9011E An error occurred during file See the installation log for
creation. more details.
loading the discovered more details.
topology file.
loading the topology file. more details.
GYMCI9014E The installation engine See the installation log for
encountered an more details.
unrecoverable error.
saving the topology file. more details.
GYMCI9016E The installer cannot proceed See the installation log for
with the installation because more details.
there is insufficient disk
space on the local host.
GYMCI9017E The installer cannot Ensure that the correct host
download the topology from name, port, and SID were
the specified database. Verify specified and that the
that the Tivoli Netcool database has been started.
Performance Manager
database exists and that it
has been started. If it does
not exist, launch the installer,
providing a topology file.
GYMCI9018E The installer cannot connect Ensure that you provide the
to the specified database correct user name and
indicated because of password.
incorrect credentials.
GYMCI9019W The installer could not Check that the Tivoli Netcool
establish a connection to the Performance Manager
specified database. Check database can be contacted.
that the Tivoli Netcool
Performance Manager
database can be contacted.
Click Next to proceed
without checking the current
environment status.
GYMCI9020E The database connection Ensure that you provide the
parameters do not match correct parameters.
those in the topology file.

loading the Oracle client jar. more details.
GYMCI9022E The configuration file name See the installation log for
was not found. The step more details.
cannot run.
GYMCI9023W There appear to be no See the installation log for
differences between the more details.
desired topology state and
the current state of the Tivoli
Netcool Performance
Manager installation. The
installer shows this message
when it determines there is
not work that it can do.
Normally, this occurs when
the Tivoli Netcool
Performance Manager system
is already at the desired
state. However, it can also
occur when there are
component dependencies
that are not satisfied.
GYMCI9024E The operating system Correct the topology file.
specified for this node in the
topology file is not correct.
GYMCI9025E The path is not valid or you Correct the parameter and
do not have permissions to try again.
write to it.
GYMCI9026E The path is not a valid Correct the parameter and
Oracle path. The sqlplus try again.
command could not be
found.
GYMCI9027E The specified port is not Correct the parameter and
valid. try again.
GYMCI9028E At least one parameter is Specify values for the
null. required parameters.
GYMCI9029E The specified host name Ensure that host names
contains unsupported include only supported
characters. characters.
GYMCI9030E The specified host cannot be Ensure that the host name is
contacted. correct and check that the
host is available.
GYMCI9031E The path not exists on the Correct the path and try
local system. again.

GYMCI9032E An error occurred while See the log file for further
saving the topology. It has details.
not been uploaded to the
Manager database. This error
occurs when there is a
database connection error or
when the Tivoli Netcool
Performance Manager
database has not yet been
created
GYMCI9033E One of the following Check the log file for further
parameters must be set to 1: details. Redefine the
param1 param2 parameters and try again.
creating mount point details.
directories.
changing the ownership or details.
the group of mount point
directories.
GYMCI9036E The machine hostname was If a host name alias is used,
not found in the Tivoli make the machine host name
Netcool Performance match the host name in the
Manager model model. Alternatively, use the
(topology.xml file). The option
machine where the installer -DUsehostname=hostname to
is running is not part of the override the machine host
Tivoli Netcool Performance name used by the installer.
Manager topology.
GYMCI9037E The Deployer version you Use a Deployer at a version
are using is not compatible that supports the
with the component that you deployment of the
are trying to install. component you are trying to
install.
GYMCI9038E The XML file cannot be read Ensure the file is not
or cannot be parsed. corrupted. See the log file for
more details.
GYMCI9039E The deployment cannot See the log file for more
proceed, because an error details. Check that there is
occurred the deployment sufficient disk space and that
plan was being generated. the Deployer images are not
corrupted.
GYMCI9040E The Deployer cannot manage See the log file for more
the indicated component on details about the condition
the specified node. that was detected.
GYMCI9041E The user ID you specified is Check that you have
not defined on the target specified the correct user ID.
system.
GYMCI9042E You specified a host that is Check that you have
running on an unsupported specified the correct host
platform. name.
GYMCI9043E The value you specified is Specify one of the supported
not supported. values.

GYMCI9044I To continue, go to the step See the installation log for
property, set Allow Remote more details.
Execution, and rerun the
step or manually transfer the
directory on the host. When
the transfer is completed, put
this step in a Success state
and continue the installation.
GYMCI9045I To continue, go to the step See the installation log for
property, set allow Remote more details.
Execution and re-execute the
step or logon to host and
perform task manually. Make
sure the command completes
with a ZERO return code
then put this step in the
Success state and continue
with the rest of the
installation steps.
GYMCI9046I Remote Command Execution See the installation log for
has been disabled by CLI more details.
directive.
GYMCI9047I There may not be enough See the installation log for
space to install all selected more details.
components
loading the DB2 client jar. more details.
GYMCI9049E The path is not a valid DB2 Correct the parameter and
path. The clpplus command try again.
could not be found.
GYMCI9050E Run for uninstallation of Remove all Collectors on
Dataload only when you are host and try again
uninstalling all Dataloads for
host/hosts.
Topology Editor messages

The Topology Editor messages.
Table 14 lists the error messages returned by the Topology Editor.
Table 14: Topology Editor Messages

GYM0001E A connection error was Check the error log and trace
caused by an SQL failure files for the possible cause of
when running the report. the problem. Check that the
Details are logged in the database is up and that the
trace file. There is a connection credentials are
connection problem with the correct. Correct the problem
database. Possible problems and try the operation again.
include: The database is not
running. The database
password provided when the
engine was created is wrong
or has been changed.
GYMCI0000E Folder name containing Ensure that you have the
technology pack metadata correct location for the
files was not found. The technology pack metadata
specified folder does not files and try the operation
exist. again.
GYMCI0001E An internal error, associated Contact IBM Software
with the XML parser Support.
configuration, occurred.
GYMCI0002I No item has been found that Ensure that you enter the
satisfies the filtering criteria. correct filtering criteria and
try the operation again.
GYMCI0003E An error occurred when Ensure that you have
reading XML file name. The selected the correct file and
XML file might be corrupt or try the operation again.
in an incorrect format.
GYMCI0004E The input value must be an Correct the input value and
integer. try the operation again.
GYMCI0005E An unexpected element was Ensure that you have
found when reading the selected the correct file and
XML file. try the operation again.
GYMCI0006E A value must be specified. Correct the input value and
retry the operation.
GYMCI0007E The value must represent a Correct the input value and
log filter matching regular try the operation again.
expression expression.
GYMCI0008E Metadata file name was not Ensure that you have the
found. The specified file does correct file name and path
not exist. and retry the operation.
GYMCI0009E Metadata file name is Contact IBM Software
corrupted. Support.
GYMCI0010E Metadata file name was Click Yes to replace the file
already imported. Do you or No to cancel the
want to replace it? operation.
GYMCI0011E Object name was not found Ensure that you have the
in the repository. The correct object name and try
specified object does not the operation again.
exist.
GYMCI0012E The specified value must Ensure that you have the
identify an existing directory. correct directory name and
The specified directory does try the operation again.
not exist.

GYMCI0013E Removing object from host in No user action required.
Physical View.
GYMCI0014E File name does not exist. Ensure that you have the
correct file name and try the
operation again.
GYMCI0015E An unexpected error Ensure that there is sufficient
occurred writing file name. space to write the file in the
See the trace file for details. file system where the
Topology Editor is running.
GYMCI0016E The user or password that Correct the login credentials
you specified is wrong. and try the operation again.
GYMCI0017E The value specified for at Correct the input value or
least one of the following values and try the operation
fields is not valid: host name, again.
port, or SID.
GYMCI0018E The file name is corrupted. Select a valid XML file.
GYMCI0019E An unexpected error Ensure that the database is
occurred when retrieving up and running and that you
data from the database. See can connect to it.
the trace file for details.
GYMCI0020E An unexpected error Select a valid XML file.
occurred when parsing file
name. See the trace file for
details.
GYMCI0021E An unexpected error Contact IBM Software
occurred. See the trace file Support.
for details.
GYMCI0022E The input value must be a Correct the input value and
boolean. try the operation again.
GYMCI0023E The specified value must be Correct the input value and
one of the following try the operation again.
operating systems: AIX,
SOLARIS, or Linux.
GYMCI0024E The value must be a software Correct the input value and
version number in the format try the operation again.
n.n.n or n.n.n.n. For example
7.1.2, or 7.1.2.1.
GYMCI0025E The value must be an integer Correct the input value and
in the range minValue to try the operation again.
maxValue, inclusive.
GYMCI0026E The value must be a Correct the input value and
comma-separated list of try the operation again.
strings.
GYMCI0027E The value must be a file size Correct the input value and
expressed in kilobytes. For try the operation again.
example, 1024K.
expressed in megabytes. For try the operation again.
example, 512M.

expressed in kilobytes or try the operation again.
megabytes. For example
1024K or 512M.
GYMCI0030E The value must be an FTP or Correct the input value and
SFTP connection string. For try the operation again.
example,
ftp://
username:password@hostname/
directory.
GYMCI0031E The value must be a Correct the input value and
comma-separated list of try the operation again.
directories. For example,
/opt, /var/tmp, /home.
GYMCI0032E Value cannot be a Supply the unqualified host
fully-qualified domain name, name without the domain.
IP address, or name Do not use the IP address or
containing hyphen or period. a name that contains
hyphens.
GYMCI0033E Metadata file name contains Contact IBM Software
an technology pack with a Support.
wrong structure.
GYMCI0034E Value should be in the Specify a date that is within
format YYYY-MM-DD, the range and in the correct
cannot be a date prior than format.
1970-01-01, or later than the
current date.
GYMCI0035E The meta-data file contains Obtain a valid meta-data file
an technology pack with the and try again.
wrong structure.
GYMCI0036E Value should be in the Correct the input value and
format YYYY-MM-DD, retry the operation.
cannot be a date prior than
1970-01-01, or later than the
current date.
GYMCI0037E The operation failed because Ensure that the file name
the specified file does not and path you specified is
exist. correct and retry the
operation.
GYMCI0038E The operation failed because See the trace file for more
of an error while validating details.
the host name mappings file.
GYMCI0039E The host name retrieved by Correct the entry for the
the upgrade process is not specified host name in the
valid. Fully qualified host topology definition.
names, IP addresses and
names containing hyphens or
periods are not supported.
GYMCI0040E The upgrade process Remove the entry for the
retrieved two entries for the fully qualified host name.
specified host name. The
fully qualified host name is
not supported.

GYMCI0040W The upgrade process did not Check that the default
retrieve a valid value for the assigned is appropriate and
specified property. A default change it if necessary.
value has been used.
GYMCI0041E No component is present on Specify a host where at least
the specified host. one component is present.
GYMCI0042E The operation failed because Correct the input value and
the input value is not the retry the operation.
correct data type. The correct
data type is Long.
GYMCI0043E The operation failed because Correct the input value and
the input value is not valid. retry the operation.
GYMCI0044W The upgrade process did not Check that the default
retrieve a valid value for the assigned is appropriate and
specified property. A default change it if necessary.
value has been used.
InstallAnywhere messages
The InstallAnywhere messages.
™
Table 14 lists the InstallAnywhere error messages. These messages could be
returned by either the deployer or the Topology Editor. See the InstallAnywhere
documentation for more information about these error codes and how to resolve
them.
Table 15: Install Anywhere Messages
Error Code Description

0 Success: The installation completed
successfully without any warnings or errors.
1 The installation completed successfully, but
one or more of the actions from the
installation sequence caused a warning or a
non-fatal error.
8 The silent installation failed because of step
Error errors.
-1 One or more of the actions from the
installation sequence caused a fatal error.
1000 The installation was cancelled by the user.
1001 The installation includes an invalid
command-line option.
2000 Unhandled error.
2001 The installation failed the authorization
check, may indicate an expired version.
2002 The installation failed a rules check. A rule
placed on the installer itself failed.
2003 An unresolved dependency in silent mode
caused the installer to exit.

Error Code Description
2004 The installation failed because not enough
disk space was detected during the
execution of the Install action.
2005 The installation failed while trying to install
on a Windows 64-bit system, but installation
did not include support for Windows 64-bit
systems.
2006 The installation failed because it was
launched in a UI mode that is not supported
by this installer.
3000 Unhandled error specific to a launcher.
3001 The installation failed due to an error
specific to the lax.main.class property.
specific to the lax.main.method property.
3003 The installation was unable to access the
method specified in the lax.main.method
property.
3004 The installation failed due to an exception
error caused by the lax.main.method
property.
3005 The installation failed because no value was
assigned to the lax.application.name
property.
value assigned to the
lax.nl.java.launcher.main.class property.
specific to the
lax.nl.java.launcher.main.class property.
specific to the
lax.nl.java.launcher.main.method property.
method specified in the
lax.nl.launcher.java.main.method property.
4000 A Java executable could not be found at the
directory specified by the java.home system
property.
4001 An incorrect path to the installer jar caused
the relauncher to launch incorrectly.

Log files
A description of the files that are used to log errors for the Tivoli Netcool
Performance Manager components and its underlying framework.
Several files are used to log errors for the Tivoli Netcool Performance Manager
components and its underlying framework. These log files include:
v “COI log files”
v “Deployer log file”
v “Eclipse log file” on page 303
v “Trace log file” on page 303
See the Technology Pack Installation Guide for information about the technology pack
log files.
COI log files

COI log files description.
The Composite Offering Installer (COI) adds a layer called the COI Plan to the
Tivoli Netcool Performance Manager installation. The COI Plan consists of a set of
COI Machine Plans, one for each machine where Tivoli Netcool Performance
Manager components should be installed. A COI Machine Plan is a collection of
COI Steps to be run on the corresponding machine.
The COI Plan is created in the directory /tmp/ProvisoConsumer/Plan.
The COI provides the following log files:
Table 16: COI Log Files
Log File Description Log File Location

Contains detailed
MachinePlan_machinename_ [INSTALL_mmdd_hh.mm].log /tmp/ProvisoConsumer/Plan/
information about the MachinePlan_machinename/logs/
For example: tasks executed by the
MachinePlan_delphi_[INSTALL _0610_10.37].log COI steps on the
specified machine
DeploymentPlan.log Contains high-level tmp/ProvisoConsumer/Plan/

information about the logs/INSTALL_mmdd_hh.mm
COI Plan execution
Deployer log file

Deployer log file description.
Installation errors and messages are written to the file /tmp/ProvisoConsumer/

log.txt. The log file supports two levels:
v High (FINEST) - This is the default and only setting.

Eclipse log file
Eclipse log file description.
The Eclipse framework logs severe problems in a file under the Topology Editor
installation directory (for example, /opt/IBM/Proviso/topologyEditor/workspace/
.metadata). By default, the Eclipse log file is named .log. You should not need to
look there unless there is a problem with the underlying Eclipse framework.
Trace log file

Trace Log File description.
About this task
The trace log file is located in the Topology Editor installation directory (for
example, /opt/IBM/Proviso/topologyEditor). By default, this file is named
topologyEditorTrace and the default trace level is FINE.
To change the trace level:
Procedure
1. In the Topology Editor, select Window > Preferences. The Log Preferences
window opens.
2. Select the new trace level. If desired, change the name of the log file.
3. Click Apply to apply your changes. To revert back to the default values, click
Restore Defaults.
4. Click OK to close the window.

Appendix I. Troubleshooting
This section lists problems that might occur during an installation and how to
resolve them. The problems are grouped by the interface or component exhibiting
the problem.
Deployment problems
A list of deployment problem descriptions and solutions.
Problem Solution
The deployer window does not automatically Cause: In some cases (for example, when you export the display on
become the focus window after launching a VNC session on Linux systems), the deployer window does not
from it from the Topology Editor. get the focus.
User action: Click on the deployer window or move other windows

to make the deployer window the focus window.
1. When the user tries to launch the Firefox Cause: Cairo 1.4.10 may not support the requested image format.
browser an error is displayed regarding
User action: Start VNC server using the following command:
the Cairo 1.4.10 package.
/usr/bin/X11/vncserver -depth 24 -geometry 1280x1024
2. In the Topology Editor, the minimize and
maximize buttons are red in color.
Note: This is an in-built feature in Eclipse
4.2.2. See, http://stackoverflow.com/
questions/12245102/eclipse-juno-red-
minimize-and-maximize-buttons-on-linux
In a fresh installation, the database Cause: You did not perform the necessary preparatory steps.
installation step fails.
User action: This step verifies that the Oracle Listener is working
properly before actually creating the Tivoli Netcool Performance
Manager database. If the step fails: 1. Complete the necessary
manual steps (see “Configure the Oracle listener” on page 123). 2.
Change the status of the step to Ready. 3. Resume the installation.
The step should complete successfully.

Problem Solution
An installation step hangs. Cause: There are many possible causes.
User action:
1. Make sure the installation step is really in a hung state. For
example, the Tivoli Netcool Performance Manager
database-related steps might take more than an hour to complete;
other steps complete in far less time.
2. Determine which child process is causing the hang. First, find the
installer process by entering the following command:
ps -ef
The installer process has an entry similar to this one:

root 12899 7290 10 13:43:31 pts/7 0:10
/tmp/install.dir.12899/Solaris/resource/
jre/jre/bin/java -Djava.compiler=NONE -
3. Find the process that has that process number (for example,
12899) as its father. Continue until you find the last process.
4. Kill the last process using the following command:
kill -9
At this point, the status of the hung step will change to

Error.
5. If you can determine the cause of the hang, fix the problem and
resume the installation. Otherwise, collect the log files and
contact IBM for support.
The deployer hangs when displaying the Cause: The NFS file system is not working properly. User action:
Preview page. (This step normally takes only Run the df -k command and make sure that all NFS mounted file
a few seconds). systems are working properly. When the problem has been
corrected, restart the deployer.
There is a problem with remote command Cause: The deployer uses either RSH or OpenSSH to perform
execution. remote command execution. You must configure OpenSSH to make
this connection possible.
User action: After configuring OpenSSH, run the test program

provided in deployer_root/proviso/data/Utils/testremote.sh to test
your configuration, where deployer_root is the root directory for the
deployer. For example:
/export/home/pvuser/443/SOLARIS/Install/ SOL9/deployer
Installation messages report success, but This is screen noise and can safely be ignored.
might include messages similar to the
following: Fatal Error]:4:1: An invalid
XML character (Unicode: 0x1b) was found
in the element content of the document.
When you click the Done button to complete Cause: You stopped a fresh installation before the installing and
a fresh installation, the deployer displays configuring the Tivoli Netcool Performance Manager database.
database access error messages.
User action:If the Tivoli Netcool Performance Manager database has
not been installed, complete the installation using the
-Daction=resume option (see “Resuming a partially successful
first-time installation” on page 177). If the database has been
installed, there is another problem. Contact IBM Software Support.

Problem Solution
Data does not appear in real-time reports, Cause: When it starts, the channel manager (CMGR) places
and right-clicking on a real-time report does information in the database that is needed for real-time reports to
not display the option menu. This problem start correctly. During installation, a cron job is created that starts
can occur with a silent installation on a CMGR. A silent installation might run fast enough that the cron job
Solaris system. does not run before DataView is started. In this case, CMGR does
not add the required information to the database, and real-time
reports do not start up correctly.
User action:
1. Make sure that the CMGR process is running (see “Management
programs and watchdog scripts” on page 240 and “Starting the
DataChannel management programs” on page 242).
2. Restart DataView.
Saving installation configuration files

Installation configuration files can be used to troubleshoot a Tivoli Netcool
Performance Manager installation.
When you install Tivoli Netcool Performance Manager components, the deployer
creates a set of temporary configuration files that are used during the installation
process. These files specify the components that are to be installed on a target
system and the deployment information required to install them. You can use these
configuration files to troubleshoot a Tivoli Netcool Performance Manager
installation.
The temporary configuration files are normally removed from the target system
when the deployer completes the installation process. You can prevent the
deployer from removing the files by editing the installer XML file associated with a
component. This file is named n_comp_name.xml, where n is an index number
generated by the deployer and comp is a string that identifies the component.
Possible values for the comp string are DataView, DataMart, DataView, DBChannel and
DBSetup. Installer XML files are located by default in the /tmp/ProvisoConsumer/
Plan/MachinePlan_hostname directory, where hostname is the host name of the
target system.
To prevent the deployer from removing the temporary files associated with a
component install, open the corresponding install XML file and modify the
following element so that the value of the arg2 property is false:
<equals arg1="${remove.temporary.files}" arg2="true"/>
The following excerpt from the file shows the resulting XML element:
<equals arg1="${remove.temporary.files}" arg2="false"/>
When you contact IBM support about a Tivoli Netcool Performance Manager
installation problem, the support staff might ask you for these files. You can create
a tar file or zip archive that contains the entire contents of the
/tmp/ProvisoConsumer directory and send it to the IBM support staff for assistance.
Appendix I. Troubleshooting 307

Tivoli Netcool Performance Manager component problems
A list of Tivoli Netcool Performance Manager component problems and solutions.
Problem Solution
A Tivoli Netcool Performance Manager Cause: The component is installed, but has
component is still listed as Configured in not been started. User action: Start the
the Topology Editor even though is installed. component. Its status changes to Installed.
A new channel component was deployed, or Cause: The channel components need to be
the channel configuration was changed, but bounced. User action: Bounce the
the change has no effect. components, as described in Appendix B,
“DataChannel architecture,” on page 239.
Topology Editor problems

A list of Topology Editor problems and solutions.
Problem Solution
The Topology Editor won't open and the application Cause: You forgot to set and export your DISPLAY
window shows a Java exception (core dump). variable. User action: 1. Enter the following commands:
$ DISPLAY=Host_IP_Address:0.0 $ export DISPLAY
2. Restart the Topology Editor.

The splash screen for the Topology Editor is displayed, Cause: You did not log in as root. User action: 1. Log in
but the Topology Editor doesn't start and no explanatory as root. 2. Restart the Topology Editor.
message is displayed.
The Topology Editor reports the following error when Cause: You tried to add a UBA collector for an SNMP
you attempt to add a UBA collector: GYMCI0504E An technology pack. User action: Make sure that you read
internal error occurred while processing file pack the Tivoli Netcool Performance Manager technology
packs release notes before you install and configure a
Where pack is the name of the application jar file. In pack and before you add any collectors. The release
addition, the Topology Editor log file contains the notes contain information on whether a specific
following error: YYYY-MM-DD HH:MM:SS SEVERE technology pack is a UBA or SNMP pack. UBA and
FileHelper Manifest of file pack is corrupted. It SNMP packs require you to perform different
was not possible to determine if its install type configuration steps. Before you install and configure an
is bundle or standalone. technology pack, you must also read the information in
"Before You Begin" on page Chapter 6:-129 and follow
the steps listed in that section.
Tivoli Netcool Performance Manager DB2 database schema fails

Symptoms
The following error might cause the Tivoli Netcool Performance Manager database
schema installation to fail.
SQL0440N No authorized routine named "DB2AUTH.ADD_USER_PL" of type "PROCEDURE"
having compatible arguments was found.
This error indicates that the db2auth related files, which are needed during the DB2
database installation are missing. These files are normally copied over during

Tivoli Netcool Performance Manager installation process but if for some reason the
files are not copied over, the Tivoli Netcool Performance Manager database schema
installation fails.
Resolving the problem

You need to manually copy the db2auth related files from the Tivoli Netcool
Performance Manager distribution directory to /opt/db2ns/sqllib/security64/
plugin/group directory.
For example:
# cd <DIST_DIR>/proviso/RHEL/DataBase/RHEL<version_num>/db2/instance
# cp db2authDaemon db2auth.so /opt/db2ns/sqllib/security64/plugin/group
# ls -lrt /opt/db2ns/sqllib/security64/plugin/group
-rwxr-xr-x 1 root root 39041 Sep 28 06:34 db2authDaemon
-rwxr-xr-x 1 root root 39865 Sep 28 06:34 db2auth.so
Telnet problems
A list of Topology Editor problems and solutions.
Problem Solution
Telnet client fails at initial connection and reports the Cause: Length of the DISPLAY variable passed via the
following error: Not enough room in buffer for display telnet client is too long (for example,
location option reply Can occur when you start Tivoli XYZ-DA03430B70B-009034197130.example.com:0.0). User
Netcool Performance Manager components from a action: Set the value of the DISPLAY variable using the
Solaris 10 system where the user interface is displayed IP address of the local system, or the hostname only
remotely on a Windows desktop using an X Window tool without the domain name. Then, reconnect to the Solaris
like Exceed. 10 machine using the telnet client.
Java problems
A list of Java problems and solutions.
Problem Solution
Installer reports a Java Not Found error Cause: The installer expected, but did not
during installation of technology packs. find, Java executables in the path reported in
the error message. The technology pack
installation requires the correct path in order
to function. User action: Create a symbolic
link from the reported directory to the
directory on the system where the Java
executables are installed, for example:
ln -s bin_path $JAVA_HOME/bin/java
where bin_path is the directory where the

binaries are located. After you create the
symbolic link, you must re-start the
technology pack installation.

Testing connectivity to the database
How to test the connectivity to the Oracle database.
About this task
To test client connectivity to the Oracle database:
Procedure
1. Make sure you are logged in as oracle and that the DISPLAY environment
variable is set.
$ sqlplus system/password@PV.WORLD
In this syntax:
v password is the password you set for the Oracle system login name. (The
default password is manager.)
v PV is the TNS name for your Tivoli Netcool Performance Manager database
defined in your Oracle Net configuration.
For example:
$ sqlplus system/manager@PV.WORLD
3. Output like the following example indicates a successful connection:
SQL*Plus: Release 12.1.0.2.0 - Production on <Current Date>
Copyright (c) 1982, 2010, Oracle Corporation. All rights reserved.
Connected to:
Oracle12c Enterprise Edition Release 12.1.0.2 - Production
With the Partitioning option
JServer Release 12.1.0.2.0 - Production
SQL>
4. Type exit at the SQL> prompt.
Testing external procedure call access
In the Oracle Net configuration, you set up an Oracle listener to wait for
connections using external procedure calls.
About this task

The shared library libpvmextc.so executes system commands from stored Oracle
procedures. This file is installed in the $ORACLE_BASE/admin/PV/lib directory
(where PV is the ORACLE_SID). A symbolic link to this library file is created by the
configure_db script in the $ORACLE_HOME/lib directory.
To test external procedure call access:
Procedure
1. Make sure you are logged in as oracle and that the DISPLAY environment
variable is set.
2. At a shell prompt, change to the following directory path:
$ cd $ORACLE_BASE/admin/skeleton/bin
3. Run the checkextc script, using the system database login name and password
as a parameter:
$ ./checkextc system/password
For example:
$ ./checkextc system/manager
4. Output like the following example indicates a successful test.
checkextc - Checking the installation of the library libpvmextc.so
This program try to execute the following unix commands

from a PL/SQL stored procedure.
1- Check ExternalCall : echo "UNIX : Check libpvmextc.so configuration."
2- Check Version
3- Check ExternalPipe : pwd
ORACLE : Connecting to Oracle ...

ORACLE : Creating library LibExtCall ...
ORACLE : Creating function ExternalCall ...
ORACLE : Calling function ExternalCall ...
UNIX : Check libpvmextc.so configuration succeeded.
ORACLE : Creating function Version ...
ORACLE : Calling function Version ...
UNIX : Check Version libpvmextc.so - Revision: 1.0.1.1
ORACLE : Creating function ExternalPipe ...
ORACLE : Calling function ExternalPipe ...
UNIX : Check ExternalPipe - /var/opt/oracle
ORACLE : Dropping function Version ...
ORACLE : Dropping function ExternalCall ...
ORACLE : Dropping function ExternalPipe ...
ORACLE : Dropping library LibExtCall ...

Appendix J. Moving DataView content between Dashboard
Application Services Hub servers
You can use the synchronize command to move custom DataView content between
Dashboard Application Services Hub servers.
You can copy your custom DataView content, such as JSP pages, CSS and images,
from a remote Dashboard Application Services Hub server to a local Dashboard
Application Services Hub server. All remote content is copied to the local content
directory at JazzSM_HOME/products/tnpm/dataview/legacy/content.
The synchronize command

Copies custom DataView content, such as JSP pages, CSS and images, from a
remote Dashboard Application Services Hub to a local Dashboard Application
Services Hub. All remote content is copied to the local content directory at
<DASH_location>//products/tnpm/dataview/legacy/content.
Location
<DASH_location>/products/tnpm/dataview/legacy/bin
Where <DASH_location> is the Dashboard Application Services Hub installation

directory, by default /opt/IBM/JazzSM.
Required privileges
Adequate privileges are required to read and write files to the file system. You
must run this command from the UNIX command line as the Tivoli Netcool
Performance Manager UNIX user (by default, pvuser), or a user with similar or
greater privileges.
Syntax
synchronize.sh -dashuser <DASH_username> -dashpassword <DASH_password>

-sourceuser <source_username> -sourcepassword <source_password> -sourceurl
<source_url> [-pattern <pattern>]
Parameters
<DASH_username>
A Dashboard Application Services Hub user name for the local Dashboard
Application Services Hub.
<DASH_password>
The Dashboard Application Services Hub user password for the local
<source_username>
A Dashboard Application Services Hub user name for the remote Dashboard
Application Services Hub.

<source_password>
The Dashboard Application Services Hub user password for the remote
<source_url>
The URL of the remote server, including the port and DataView context.
Optional parameter
<pattern>
The name pattern that identifies the types of files to filter for the
synchronization. Wildcards * and ? are supported. To synchronize all files, omit
the pattern; do not use * on its own to synchronize all files.
Example
The following command synchronizes the DataView custom .jsp file content from
a remote Dashboard Application Services Hub or Tivoli Integrated Portal to a local
Dashboard Application Services Hub:
./synchronize.sh -dashuser smadmin -dashpassword
smadmin1 -sourceuser tipadmin -sourcepassword
tipadmin -sourceurl http://10.44.240.70:16710/PV -pattern *.jsp
./synchronize.sh -dashuser smadmin -dashpassword

smadmin1 -sourceuser tipadmin -sourcepassword
tipadmin -sourceurl http://10.44.240.70:16310/PV
By default, the <source_url> is:

http://server.ibm.com:16310/PV

Notices
This information was developed for products and services offered in the US. This
material might be available from IBM in other languages. However, you may be
required to own a copy of the product or product version in that language in order
to access it.
IBM may not offer the products, services, or features discussed in this document in
other countries. Consult your local IBM representative for information on the
products and services currently available in your area. Any reference to an IBM
product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product,
program, or service that does not infringe any IBM intellectual property right may
be used instead. However, it is the user's responsibility to evaluate and verify the
operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter
described in this document. The furnishing of this document does not grant you
any license to these patents. You can send license inquiries, in writing, to:
IBM Director of Licensing

IBM Corporation
North Castle Drive, MD-NC119
Armonk, NY 10504-1785
US
For license inquiries regarding double-byte character set (DBCS) information,

contact the IBM Intellectual Property Department in your country or send
inquiries, in writing, to:
Intellectual Property Licensing

Legal and Intellectual Property Law
IBM Japan Ltd.
19-21, Nihonbashi-Hakozakicho, Chuo-ku
Tokyo 103-8510, Japan
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS

PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. Some jurisdictions do not allow disclaimer of
express or implied warranties in certain transactions, therefore, this statement may
not apply to you.
This information could include technical inaccuracies or typographical errors.

Changes are periodically made to the information herein; these changes will be
incorporated in new editions of the publication. IBM may make improvements
and/or changes in the product(s) and/or the program(s) described in this
publication at any time without notice.
Any references in this information to non-IBM websites are provided for

convenience only and do not in any manner serve as an endorsement of those

websites. The materials at those websites are not part of the materials for this IBM
product and use of those websites is at your own risk.
IBM may use or distribute any of the information you provide in any way it
believes appropriate without incurring any obligation to you.
Licensees of this program who wish to have information about it for the purpose
of enabling: (i) the exchange of information between independently created
programs and other programs (including this one) and (ii) the mutual use of the
information which has been exchanged, should contact:
IBM Director of Licensing

IBM Corporation
North Castle Drive, MD-NC119
Armonk, NY 10504-1785
US
Such information may be available, subject to appropriate terms and conditions,

including in some cases, payment of a fee.
The licensed program described in this document and all licensed material
available for it are provided by IBM under terms of the IBM Customer Agreement,
IBM International Program License Agreement or any equivalent agreement
between us.
The performance data discussed herein is presented as derived under specific

operating conditions. Actual results may vary.
The client examples cited are presented for illustrative purposes only. Actual
performance results may vary depending on specific configurations and operating
conditions.
Information concerning non-IBM products was obtained from the suppliers of

those products, their published announcements or other publicly available sources.
IBM has not tested those products and cannot confirm the accuracy of
performance, compatibility or any other claims related to non-IBM products.
Questions on the capabilities of non-IBM products should be addressed to the
suppliers of those products.
Statements regarding IBM's future direction or intent are subject to change or

withdrawal without notice, and represent goals and objectives only.
All IBM prices shown are IBM's suggested retail prices, are current and are subject
to change without notice. Dealer prices may vary.
This information is for planning purposes only. The information herein is subject to
change before the products described become available.
This information contains examples of data and reports used in daily business
operations. To illustrate them as completely as possible, the examples include the
names of individuals, companies, brands, and products. All of these names are
fictitious and any similarity to actual people or business enterprises is entirely
coincidental.
COPYRIGHT LICENSE:

This information contains sample application programs in source language, which
illustrate programming techniques on various operating platforms. You may copy,
modify, and distribute these sample programs in any form without payment to
IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating
platform for which the sample programs are written. These examples have not
been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or
imply reliability, serviceability, or function of these programs. The sample
programs are provided "AS IS", without warranty of any kind. IBM shall not be
liable for any damages arising out of your use of the sample programs.
Each copy or any portion of these sample programs or any derivative work must
include a copyright notice as follows:
© (your company name) (year).

Portions of this code are derived from IBM Corp. Sample Programs.
© Copyright IBM Corp. _enter the year or years_.
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of
International Business Machines Corp., registered in many jurisdictions worldwide.
Other product and service names might be trademarks of IBM or other companies.
A current list of IBM trademarks is available on the web at "Copyright and
trademark information" at www.ibm.com/legal/copytrade.shtml.
Adobe, Acrobat, PostScript and all Adobe-based trademarks are either registered
trademarks or trademarks of Adobe Systems Incorporated in the United States,
other countries, or both.
IT Infrastructure Library is a registered trademark of the Central Computer and

Telecommunications Agency which is now part of the Office of Government
Commerce.
Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo,
Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or
registered trademarks of Intel Corporation or its subsidiaries in the United States
and other countries.
Linux is a registered trademark of Linus Torvalds in the United States, other

countries, or both
Microsoft and Windows are trademarks of Microsoft Corporation in the United

States, other countries, or both.
ITIL is a registered trademark, and a registered community trademark of The

Minister for the Cabinet Office, and is registered in the U.S. Patent and Trademark
Office.
UNIX is a registered trademark of The Open Group in the United States and other
countries.
Notices 317
Java and all Java-based trademarks and logos
are trademarks or registered trademarks of
Oracle and/or its affiliates.
Cell Broadband Engine is a trademark of Sony Computer Entertainment, Inc. in the

United States, other countries, or both and is used under license therefrom.
Linear Tape-Open, LTO, the LTO Logo, Ultrium, and the Ultrium logo are
trademarks of HP, IBM Corp. and Quantum in the U.S. and other countries.
Terms and conditions for product documentation

Permissions for the use of these publications are granted subject to the following
terms and conditions.
Applicability
These terms and conditions are in addition to any terms of use for the IBM
website.
Personal use
You may reproduce these publications for your personal, noncommercial use
provided that all proprietary notices are preserved. You may not distribute, display
or make derivative work of these publications, or any portion thereof, without the
express consent of IBM.
Commercial use
You may reproduce, distribute and display these publications solely within your
enterprise provided that all proprietary notices are preserved. You may not make
derivative works of these publications, or reproduce, distribute or display these
publications or any portion thereof outside your enterprise, without the express
consent of IBM.
Rights
Except as expressly granted in this permission, no other permissions, licenses or

rights are granted, either express or implied, to the publications or any
information, data, software or other intellectual property contained therein.
IBM reserves the right to withdraw the permissions granted herein whenever, in its
discretion, the use of the publications is detrimental to its interest or, as
determined by IBM, the above instructions are not being properly followed.
You may not download, export or re-export this information except in full
compliance with all applicable laws and regulations, including all United States
export laws and regulations.

IBM MAKES NO GUARANTEE ABOUT THE CONTENT OF THESE
PUBLICATIONS. THE PUBLICATIONS ARE PROVIDED "AS-IS" AND WITHOUT
WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING
BUT NOT LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILITY,
NON-INFRINGEMENT, AND FITNESS FOR A PARTICULAR PURPOSE.
Notices 319
IBM®
Printed in USA

PDF TNPM Installguide

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

PDF TNPM Installguide

Transféré par

Droits d'auteur :

Formats disponibles

IBM Tivoli Netcool Performance Manager 1.4.

© Copyright IBM Corporation 2006, 2016.

© Copyright IBM Corp. 2006, 2016 iii

iv IBM Tivoli Netcool Performance Manager: Installation Guide

vi IBM Tivoli Netcool Performance Manager: Installation Guide

The audience who are network administrator or operations specialist responsible

To install Tivoli Netcool Performance Manager successfully, you must have a

What this publication contains

© Copyright IBM Corp. 2006, 2016 vii

viii IBM Tivoli Netcool Performance Manager: Installation Guide

Tivoli Netcool Performance Manager - Wireline Component consists of the

Tivoli Netcool Performance Manager documentation consists of the following:

About this publication ix

The Default UNIX Shell

This guide uses the following shell prompts in the examples:

Service Management Connect

Access Network and Service Assurance community at https://www.ibm.com/

Tivoli Netcool Performance Manager 1.4 community on developerWorks

Tivoli Netcool Performance Manager technical training

x IBM Tivoli Netcool Performance Manager: Installation Guide

Conventions used in this publication

About this publication xi

xii IBM Tivoli Netcool Performance Manager: Installation Guide

This information provides an overview of the Tivoli Netcool Performance Manager

Attention: DB2 is supported on Linux only. Whereas, Oracle is supported on

Tivoli Netcool Performance Manager architecture

The Tivoli Netcool Performance Manager components run on:

v SPARC-based servers from Oracle that run the Solaris operating

v servers from IBM

Exact, release-specific requirements, prerequisites, and recommendations for

The following diagram provides a high-level overview of the Tivoli Netcool

© Copyright IBM Corp. 2006, 2016 1

2 IBM Tivoli Netcool Performance Manager: Installation Guide

All subcomponents of the Tivoli Netcool Performance Manager - Wireline

Note: Dataview cannot be installed on a Solaris system as Jazz™ for Service

4 IBM Tivoli Netcool Performance Manager: Installation Guide

Child properties that have been inherited are marked as inherited.

As an example of what happens when you change inherited property values:

Disk Usage Server

The DataChannel component requires a Disk Usage Server. This component is

Disk quota management

Good judgement of space requirements is still needed. However, the estimating of

Installation or topology considerations

6 IBM Tivoli Netcool Performance Manager: Installation Guide

The following processes are employed in the DataLoad module:

Multiple SNMP DataLoad collectors:

This scenario results in:

Installation and topology considerations for collectors.

Up to 320 DataLoad modules can be supported per Tivoli Netcool Performance

8 IBM Tivoli Netcool Performance Manager: Installation Guide

Datachannel limit is increased from 8 to 16 in Tivoli Netcool Performance Manager

Supported DataChannel deployment types.

Tivoli Netcool Performance Manager supports two deployment types for

The following sections describe both deployment types in more detail.

Standard DataChannel installation.

DataChannel Standard Installation

DataChannel “Remote Channel Option”:

DataChannel remote installation.

Loader Staging, which inovlves either of the following:

Tivoli Netcool Performance Manager on Solaris 10:

Options when deploying Tivoli Netcool Performance Manager on Solaris.

10 IBM Tivoli Netcool Performance Manager: Installation Guide

Note: In configuring Solaris containers for each Tivoli Netcool Performance