Professional Documents
Culture Documents
IBM Netcool Impact 7.1 Best Practices v1.0-FIRST-EDITION1
IBM Netcool Impact 7.1 Best Practices v1.0-FIRST-EDITION1
1
Best Practices
Contents
About this publication ........................................................................................................................ v
Intended audience .......................................................................................................................................... v
What this publication contains...................................................................................................................... v
Publications .................................................................................................................................................... vi
Your Netcool/Impact Best Practices library .................................................................................... vi
Prerequisite publications ................................................................................................................... vii
Conventions used in this publication......................................................................................................... vii
Typeface conventions ........................................................................................................................ viii
Operating system-dependent variables and paths ........................................................................ viii
Chapter 1 Introduction ........................................................................................................................ 1
Chapter 2 Planning .............................................................................................................................. 2
Where to implement custom functionality .................................................................................................. 2
Requirements gathering................................................................................................................................. 4
Solution design based on requirements ....................................................................................................... 6
A starting point ..................................................................................................................................... 6
List of custom functionality required from Netcool/Impact .......................................................... 7
List of all components Netcool/Impact will interact with .............................................................. 8
List of all event sources ........................................................................................................................ 8
List of all Data Source Adaptors (DSAs) required and rates of access .......................................... 8
List of all Data Types (DTs) required ................................................................................................. 9
List of all Services required ............................................................................................................... 10
List of event processing functions .................................................................................................... 10
List of geographic sites ....................................................................................................................... 10
Estimate of peak event processing rate per site .............................................................................. 11
Estimate of number of concurrent users .......................................................................................... 12
Detailed specification of the Operator Views required ................................................................. 12
Exception handling specification ...................................................................................................... 13
Architectural considerations ....................................................................................................................... 14
Security and network restrictions ..................................................................................................... 15
Resiliency ............................................................................................................................................. 15
Create a diagram ................................................................................................................................. 16
Ports used by Impact .......................................................................................................................... 16
Hardware considerations ............................................................................................................................ 16
Hardware resiliency ........................................................................................................................... 16
CPU, memory and disk space resourcing........................................................................................ 17
Setting the memory for the Java Virtual Machine on the Impact profile .................................... 18
Network resourcing............................................................................................................................ 18
Other installation prerequisites .................................................................................................................. 18
Solution delivery ........................................................................................................................................... 18
Custom configuration ........................................................................................................................ 19
Documentation .................................................................................................................................... 20
Use of debug mode ....................................................................................................................................... 21
Stress testing prior to deployment into production ................................................................................. 22
Removal of temporary files ......................................................................................................................... 22
Chapter 4 Clustering.......................................................................................................................... 25
Make all components resilient .................................................................................................................... 26
High Availability within Impact ................................................................................................................. 26
Cluster operation ................................................................................................................................ 26
How many clusters should I deploy?......................................................................................................... 28
Split brain scenario ............................................................................................................................. 28
iii
Licensed Materials – Property of IBM
iv
Licensed Materials – Property of IBM
Intended audience
This publication is intended as essential reading for all technical staff that are responsible for:
Developing Netcool/Impact 7.1 solutions;
Installing and administering Netcool/Impact 7.1;
Supporting Netcool/Impact 7.1.
It is assumed that the reader has a working knowledge of Netcool/Impact and understands
the meaning of the Netcool/Impact terms and component names referred to in this
document.
Further information about Netcool/Impact 7.1 can be obtained from the official product
documentation available here:
http://ibm.biz/netcool_impact_docs
v
Licensed Materials – Property of IBM
Publications
This section lists publications in the Netcool/Impact library and related documents.
vi
Licensed Materials – Property of IBM
Prerequisite publications
To use the information in this publication effectively, you must have some prerequisite
knowledge, which you can obtain from the following publications:
IBM Netcool/Impact 7.1 Quick Start Guide
The Netcool/Impact Quick Start Guide helps you get started with a base configuration of
Netcool/Impact.
IBM Netcool/Impact 7.1 Release Notes
The Netcool/Impact Release Notes contains a description of requirements and getting
started issues are addressed in this document.
IBM Netcool/Impact 7.1 Administration Guide
The Netcool/Impact Administration Guide contains instructions on installing,
configuring, running, and monitoring Netcool/Impact.
IBM Netcool/Impact 7.1 DSA Reference Guide
The Netcool/Impact DSA Reference Guide contains information about Netcool/Impact
Data Source Adapters (DSAs).
IBM Netcool/Impact 7.1 Operator View Guide
The Netcool/Impact Operator View Guide contains instructions about creating Operator
Views.
IBM Netcool/Impact 7.1 Policy Reference Guide
The Netcool/Impact Policy Reference Guide contains descriptions and complete syntax
references for the Impact Policy Language (IPL) and JavaScript.
IBM Netcool/Impact 7.1 Solutions Guide
The Netcool/Impact contains end-to-end information about using features in
Netcool/Impact.
IBM Netcool/Impact 7.1 User Interface Guide
The Netcool/Impact User Interface Guide contains information about the user interface
in Netcool/Impact.
IBM Netcool/Impact 7.1 Integrations Guide
The Netcool/Impact Integrations Guide contains instructions on integrating
Netcool/Impact with other IBM software and other third-party software.
IBM Netcool/Impact 7.1 Troubleshooting Guide
The Netcool/Impact Troubleshooting Guide provides information about troubleshooting
the installation, customization, starting, and maintaining Netcool/Impact.
All the publications listed above can be accessed online here:
http://ibm.biz/netcool_impact_docs
vii
Licensed Materials – Property of IBM
Typeface conventions
This publication uses the following typeface conventions:
Bold
Lowercase commands and mixed case commands that are otherwise difficult to
distinguish from surrounding text
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:)
Keywords and parameters in text
Italic
Citations (examples: titles of publications, diskettes, and CDs)
Words defined in text (example: a nonswitched line is called a point-to-point line)
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.")
New terms in text (except in a definition list): a view is a frame in a workspace that
contains data
Variables and values you must provide: ... where myname represents....
Monospace
Examples and code examples
File names, programming keywords, and other elements that are difficult to
distinguish from surrounding text
Message text and prompts addressed to the user
Text that the user must type
Values for arguments or command options
viii
Licensed Materials – Property of IBM
Chapter 1 Introduction
This document details the best practices that should be employed when deploying
Netcool/Impact 7.1. This document is designed to help an engineer quickly and efficiently
install a working system and ensure that if another engineer subsequently has to work on a
deployment installed by someone else, they will easily understand what has been configured
and how.
Many of the best practice concepts covered in this document trace their origins to the Netcool
Certified Consultant programme. This document includes the relevant concepts from the
product’s roots and introduces new ones based on the new technologies and product features
in the latest releases of Netcool/Impact.
This document is intended to be read by anyone preparing to deploy or work with
Netcool/Impact version 7.1.
Page 1 of 71
Licensed Materials – Property of IBM
Chapter 2 Planning
Netcool/Impact is usually deployed along with other Netcool products as a part of a bigger
solution to meet the business requirements. Requirements are often best implemented by
using a combination of products within the solution ― for example: a requirement may be
partly implemented by a Netcool/OMNIbus Probe rules file, a Netcool/OMNIbus
ObjectServer trigger and a Netcool/Impact policy.
The requirements gathering process therefore is a key first step in architecting any Netcool
solution. Careful planning must be undertaken to ensure all necessary factors have been
considered before provisioning both the software and hardware components as well as
designing the architecture layout.
Once the requirements gathering exercise for the overall Netcool solution has been
completed, the Netcool Solution Architect will then assess the requirements and identify
which Netcool product or combination of products would be the best fit for implementing
each requirement. This exercise should be completed before anything else.
One of the outputs of this requirements gathering exercise will be to construct a list of all
custom functionality that will be performed by Netcool/Impact. This list of custom
functionality is just one of many items that will need to be defined as part of the
Netcool/Impact requirements gathering process.
This chapter provides guidance on how to go about the requirements gathering process with
respect to Netcool/Impact and also other points to consider when planning a
Netcool/Impact deployment.
Page 2 of 71
Licensed Materials – Property of IBM
Netcool/OMNIbus Probe The Probe rules file is where the incoming token stream is parsed and
rules file assigned to Netcool/OMNIbus ObjectServer fields prior to being sent to
the ObjectServer and potentially being processed by Netcool/Impact or
any other components.
It is a best practice to implement as much functionality as possible at the
Probe rules file level rather than leaving it up to other components such
as Netcool/OMNIbus ObjectServer triggers and Netcool/Impact policies
to deal with.
This practice helps to spread the processing load down to the end points
and means there is less data processing required at the points where the
events converge ― ie: within the ObjectServers. Minimising processing
load at the event convergence points ensures that the system is better able
to handle peak event flows ―for example: during an event storm.
Lookup files are useful at the Probe level for basic event enrichment so
long as the data set is fairly static. If the data in the lookup table is
dynamic, it is better to store it in a database table ― for example: within
an ObjectServer table or another database ― and then perform event
enrichment via an ObjectServer trigger or via Netcool/Impact.
Note that creating large custom tables may cause ObjectServer
performance to suffer. Custom tables and triggers, like any other custom
functionality, should be thoroughly tested before being put into
production.
External scripts External scripts (launched by external action procedures from within the
Netcool/OMNIbus ObjectServer) are used for carrying out actions that
require interaction with external systems. The nco_mail script is
designed to be launched by an external action procedure to send a
notification e-mail, for example. Netcool/Impact also has a policy
function called JRExecAction which can be used to do likewise.
Netcool/OMNIbus also has the ability to execute external scripts on
remote machines via the Netcool/OMNIbus Process Agent. Similarly,
Netcool/Impact has the CommandResponse function which allows you
to connect to a remote machine and interactively execute commands on
that remote machine.
See the Netcool/Impact 7.1 Policy Reference Guide for more information on
both of these Netcool/Impact functions.
Page 3 of 71
Licensed Materials – Property of IBM
An overview of the core features and typical use-cases of Netcool/Impact is available here:
http://ibm.biz/netcool_impact_uses
Requirements gathering
Once the requirements gathering process for the overall Netcool solution has been done and
how each requirement will be implemented has been established, the list of custom functions
to be performed by Netcool/Impact should be ready.
This list of custom functions will then form one part in a secondary requirements list that
contains requirements specific to Netcool/Impact. This secondary requirements list will
allow an initial sizing and architecture design to be done with respect to Netcool/Impact.
This section provides a suggested base set of requirements for the Netcool/Impact
requirements gathering process and explains how each one may affect the resulting
architecture. This will allow a Netcool Solutions Architect to produce an initial design for
Netcool/Impact and estimate reasonable initial component numbers.
Any design resulting from these initial requirements will constitute a starting point for the
solution and may need to change when additional components that add load are introduced
to the overall solution.
Note: Any resulting design should undergo extensive load testing prior to deployment
into production. Adjustments may need to be made to the design as a result of these tests.
Page 4 of 71
Licensed Materials – Property of IBM
A list of the event sources Netcool/Impact will interact with. Typically the primary event
source will be Netcool/OMNIbus however there may be others since Netcool/Impact is
capable of reading events from a wide range of data source types.
A list of the custom Data Source Adaptors (DSAs) that will be required to implement the
solution.
An estimate of the maximum access rate of each Data Source (DS) in terms of reads
and/or writes per second. This information in conjunction with the events-to-process
rate will enable you to calculate whether or not each given Data Source will handle the
load. The owner of each Data Source to be accessed ― for example: a DB2 Administrator
― should be consulted during this process in case further resource needs to be allocated
to the Data Source to accommodate the load Netcool/Impact will place on it.
A list of the custom Data Types (DTs) that will be required to implement the solution
including the field that will be the primary key for each one ― plus a list of the fields that
will be needed within each Data Type.
A list of the custom Netcool/Impact Services that will be required to implement the
solution.
Each of the Netcool/Impact custom functionality items that process event streams need
to be identified from the overall list of custom functionality items and grouped into two
categories:
One-time event processing functions ― for example: event enrichment;
Functions that are carried out repeatedly on events or functions that perform
correlation tasks ― for example: X events in Y seconds.
The purpose of this division is two-fold: first, Event Readers are configured to either
process events once only or repeatedly; second, in the case of a tiered Netcool/OMNIbus
architecture, one-time processing functions can potentially be pushed down to the
Collection ObjectServer layer thereby easing loading on the Aggregation layer. This
concept will be discussed in more detail in a later section of this document.
How many geographic sites Impact will need to be present at ― for example: when
Netcool/Impact is integrated with a geographically distributed Netcool/OMNIbus
system. In such circumstances, one Netcool/Impact cluster would typically be
provisioned for each geographic site to provide local resiliency and also so as to minimise
WAN traffic.
An estimate of the total number of events the Netcool/Impact cluster will be expected to
process from all sources per day (ie. event rate) ― including an estimate of the peak event
rate. System design should always be provisioned to manage peak rates plus have a
contingency factor built in case of event storms.
Note: Guidance on provisioning the number of cluster members needed and hardware
provisioning are both covered in a later section.
The value for the total number of events processed by Netcool/Impact per day should
also include each time an event is reprocessed ― since load is incurred on the
Netcool/Impact cluster for each processed event ― regardless of whether or not it has
been processed before.
This number should be calculated separately for each geographical site or
Netcool/Impact cluster, where applicable. This is necessary because it is likely that the
sizing requirements for each Netcool/Impact cluster will vary from one site to the next.
Page 5 of 71
Licensed Materials – Property of IBM
An estimate of the maximum number of concurrent users of the system. Typically the
Netcool/Impact GUI will only be accessed by Netcool Administrators ― however an
estimate should also be made as to the number of concurrent Operator View sessions, if
they are to be used within the Netcool solution.
A detailed specification of each of the Operator View dashboards that will be required.
Each specification should contain the following at the very least:
A description of how the dashboard is to be accessed ― for example: via a
Netcool/OMNIbus Web GUI Active Event List (AEL) right-click tool;
A mock-up sketch or otherwise of how the dashboard should look;
Specific details about what each section of the dashboard should contain including
what data is presented and which Data Source the data is to be sourced from;
If there are any active components such as buttons, the specification should define
what should happen when the buttons are clicked ― including what further
resources are accessed and what actions are carried out, where applicable.
A description of one or more exception handling policies to be created to catch and
handle any exceptions that are encountered during Netcool/Impact execution. It is
acceptable to simply use the default exception handler as part of the design, of course.
Each of the requirements listed above are expanded upon in the next section.
Note: See the section in this document entitled: Documentation for more information
regarding the recommended minimum solution delivery documentation.
The listed items in this section will enable an implementation team to rapidly build the
required system. Having well documented requirements will also enable the solution
maintenance team to more easily maintain the solution later on.
A starting point
It is a general Netcool best practice to include resiliency in any solution. For example, rather
than just installing a single standalone Netcool/Impact server, it is better to install two or
more Netcool/Impact servers configured as a cluster to provide resiliency in the event of an
outage of one or more cluster members.
The starting point for any Netcool/Impact installation therefore is a cluster of at least two
members where the Name Servers have been properly configured as a cluster. Each of the
initial two Netcool/Impact servers should also be configured to run an instance of the GUI
server. Then, depending on the load placed on the cluster by custom functionality,
additional Impact servers may need to be added to the cluster ― or additional clusters may
be needed. The need to add extra resource will become apparent during load testing.
Page 6 of 71
Licensed Materials – Property of IBM
Requirement: Populate Location field of all events with originating city name
Integration point: Collection layer Netcool/OMNIbus ObjectServers
DSA required: ObjectServer DSA – ″COL_V_1″
Data Type: ″col_status″
DSA required: DB2 DSA ― ″inventory_db″
Data Type: ″locations″
Service required: Event Reader ― ″COL_V_1_reader″
Policy: ″update_location″
Event Reader: ″COL_V_1_reader″
Event Reader filter: Location = ''
Policy pseudocode:
For each event:
Look up Node field in ″locations″ data type
Set Location field in event to City field in found record
If not found, set Location field to ″NOT FOUND″
Update ObjectServer with newly populated Location field
――
After all the requirements have been specified, it may become apparent that a number of
resources can be combined. For example, if there are a number of event enrichment
requirements, it is likely that these could be combined into a single policy. Hence the
definition of this custom functionality requirements list may necessarily undergo several
iterations before it is condensed and finalised.
Page 7 of 71
Licensed Materials – Property of IBM
List of all Data Source Adaptors (DSAs) required and rates of access
This item provides a summary list of all the Data Source Adaptors (DSAs) that
Netcool/Impact will connect to in order to perform its assigned tasks. The rate of access for
each Data Source is also provided. The Netcool implementation team will have to liaise with
the relevant Information Manager for each of the non-Netcool Data Source Adaptors in order
to ensure that the required rate of access is possible. (The rates of access to Netcool
datasources will have to be considered by the Netcool solution implementation team.)
Where the Data Source cannot support such a rate of access, the Data Source resourcing will
have to be increased.
EXAMPLE:
Continuing the previous example, the Netcool Solution Architect compiles the following list
of Data Source Adaptors (DSAs) that Netcool/Impact will use to carry out its assigned tasks:
Page 8 of 71
Licensed Materials – Property of IBM
Page 9 of 71
Licensed Materials – Property of IBM
Note: An Event Reader can be configured to process events just once ― or multiple times
each time the event is updated ― via the Get Updates check box. Dividing the processing
functions into these two categories therefore is important from an implementation standpoint
as it defines which Event Reader the function will be attached to.
EXAMPLE:
Continuing the previous example, the Netcool Solution Architect compiles and categorises
the following list of event processing functions that that Netcool/Impact carry out:
One-time functions:
1) Event enrichment of Location field from locations database.
2) Suppression of event if it is found to be in maintenance.
Repeated/correlation:
1) Creation of synthetic event to warn operators if there are more
than 10 critical events for any one Location.
Page 10 of 71
Licensed Materials – Property of IBM
EXAMPLE:
Continuing the previous example, Widgetcom has two data centres: one in Yokohama and one
in Auckland with a high bandwidth network connection between the two.
In accordance with Netcool/OMNIbus Best Practice, each geography will have its own data
centre with a separate Netcool/OMNIbus installation at each.
Note: See the best practice document entitled: “Netcool/OMNIbus large scale and
geographically distributed architectures - Best Practices” for more information on deploying
Netcool/OMNIbus in a geographically distributed manner. This document is available from
the IBM Netcool/OMNIbus wiki on the Netcool/OMNIbus best practices web site:
http://ibm.biz/nco_bps
Each of the two Netcool/OMNIbus installations will form a Web GUI datasource and the
Web GUI dashboards will combine events from both. The event processing requirements
will need to be carried out at both sites. The Netcool Solution Architect elects to deploy a
separate Netcool/Impact cluster within each data centre in order to provide local resiliency
and also to reduce WAN traffic.
Page 11 of 71
Licensed Materials – Property of IBM
Page 12 of 71
Licensed Materials – Property of IBM
the engineer that will be assigned. The engineer details will be based on the value of the
Location field within the event.
The Netcool Solution Architect completes the following Netcool/Impact Operator View
worksheet.
Page 13 of 71
Licensed Materials – Property of IBM
Note: Care should be taken when creating exception handlers based on Java exceptions
that they are at a specific enough level so as not to fire unintentionally.
Note: See the section entitled Exceptions in the Netcool/Impact 6.1 Policy Reference Guide for
more information and examples of custom exception handling.
EXAMPLE:
The Netcool/Impact solution includes interactions with two DB2 databases. Should either of
the databases not be available for whatever reason when Netcool/Impact tries to access
them, this will result in a failure.
If this should occur, Widgetcom have a requirement that execution should halt, a synthetic
event generated within the ObjectServer to alert the Netcool Administrators and a log file
entry written to the policy log file.
The Netcool Solution Architect notes down the following exception handler specification:
Architectural considerations
When attempting to calculate the number of Netcool components required during the design
of Netcool architectures, the previous sections referred to variables such as: number of users,
event processing rates, datasource loading ― and so on.
In addition to these factors, consideration should also be given to the geographical layout of
the locations to be managed, security and network restrictions, resiliency, and the loading
induced by custom functionality. Additional components may need to be added to resolve
architectural or business rule constraints.
Page 14 of 71
Licensed Materials – Property of IBM
Resiliency
High availability and resiliency is hallmark of Netcool product suite ― and therefore is an
important consideration for any Netcool deployment. Generally speaking, it is a best practice
that every Netcool component be deployed in a resilient manner. For this reason,
Netcool/Impact servers should be deployed in clusters of at least two servers.
Additional Netcool/Impact servers may need to be added to a cluster in order to provide
greater processing power ― however the need to deploy additional servers is dependent on
stress testing the system under "production conditions". The term "production conditions"
implies that the Netcool/Impact cluster is processing an amount of events that is likely to be
encountered in production when it is eventually deployed. In addition to this, the event
types should be representative in terms of type and event content so that they will be
processed by Netcool/Impact at a rate similar to what would be expected in production.
More details on provisioning numbers of servers are included in a later section of this
chapter.
To ensure the maximum level of resiliency and disaster recovery ability, cluster member
components should be installed on separate machines and ― where possible ― on different
sites from each other. Where it is not possible to distribute a Netcool/Impact cluster across
two physical sites ― for example: due to security of bandwidth constraints ― a cluster of two
or more Netcool/Impact servers should be deployed on each site: one as a primary cluster
and the other as a cold standby.
Note: Also see the section entitled: How many clusters should I deploy? later in this
document for other considerations around clustering ― particularly relating to deploying
Netcool/Impact across multiple sites or geographic locations.
Page 15 of 71
Licensed Materials – Property of IBM
Create a diagram
After geographical and architectural factors have been considered, it is very helpful and a
suggested best practice to create a diagram of the proposed Netcool solution in order to help
plan and visualise how the various components will connect to each other. With respect to
Netcool/Impact, the diagram should be detailed enough to show sub-components including
the Netcool/Impact servers, the Name Servers and the GUI servers.
Note: The diagram will necessarily be a work-in-progress until the testing phase has been
completed and the numbers of components have been finalised.
Note: A full listing of the ports used by Netcool/Impact 7.1 can be found in the
Netcool/Impact 7.1 Administration Guide.
Although it is possible to change the various ports used by Netcool/Impact during the
installation and configuration, it is recommended to use the default ports offered by the
installer.
Note: If installing the Netcool/OMNIbus Web GUI on the same host as Netcool/Impact,
there will be a port conflict between the respective UI components. It is suggested to simply
add 1000 to the Netcool/Impact UI port – ie. use port 17311 instead of the default of 16311.
Hardware considerations
Two main areas of planning a Netcool/Impact deployment with respect to hardware are
resiliency and resourcing.
Hardware resiliency
Each part of a Netcool/Impact solution should be resilient ― both in terms of software and
hardware. Software resiliency is implemented by having secondary components available
within each cluster to take over should the primary component fail. Hardware resiliency is
implemented by not having multiple Netcool/Impact servers collocated on the same physical
server.
When including hardware resiliency into an architectural design, the following points should
be considered so as to avoid having any potential single points of failure:
Loss of a physical or virtual server a component is running on;
Loss of an entire site where one or more components may be located.
EXAMPLE:
Widgetcom are planning a Netcool deployment initially with just a single Aggregation pair of
Netcool/OMNIbus ObjectServers and a cluster of two Netcool/Impact servers. They have
Page 16 of 71
Licensed Materials – Property of IBM
selected two sites located in different parts of the city as part of their Disaster Recovery plan
and have a reliable high bandwidth link set up between the two sites.
The Netcool Administrator elects to install the primary Aggregation ObjectServer on the first
site and the backup Aggregation ObjectServer on the second site. The Netcool/Impact
cluster of two servers will have the primary server installed on the first site and the
secondary server on the second site. This provides both functional and physical resiliency.
Component Recommendation
NOTES:
Netcool/Impact 7.1 is only available in a 64 bit version;
It is recommended that CPUs be 2 GHz or higher;
No additional hardware resource needs to be provisioned for the Name Server. The
Name Server is built in to the Netcool/Impact server as of version 6.1;
Add 2 GB RAM for machines where a Netcool/Impact GUI Server will also be running.
Please see the following link to the Netcool/Impact 7.1 Administration Guide for more
information about hardware requirements:
http://ibm.biz/netcool_impact_sysreqs
Page 17 of 71
Licensed Materials – Property of IBM
Note: The Netcool/Impact 7.1 Administration Guide provides information about minimum
hardware requirements. This guide however provides recommended hardware provisioning
for production systems. Development systems can use minimum guidelines however test
systems should match production environments as closely as possible so as to provide
legitimate validation of the performance capabilities of the engineered solution.
EXAMPLE:
Widgetcom need to deploy two Netcool/Impact servers in a clustered configuration for use in
a high load environment. To ensure resiliency, each cluster member will contain a
Netcool/Impact server component, a GUI Server component and a Name Server component.
The Netcool administrator specifies hardware requirements based on a “large”
Netcool/Impact scenario; consisting of two identical machines each provisioned with 8
cores/CPUs, 16 GB of memory and 20 GB of hard disk space.
Setting the memory for the Java Virtual Machine on the Impact profile
To ensure the JVM in which the Netcool/Impact server runs does not run out of memory
during normal, production operation, it is recommended to set the maximum memory limit
on the JVM to 80% of the available memory on the system. Information on how to configure
this can be found in the Netcool/Impact 7.1 Administration Guide:
http://ibm.biz/netcool_impact_jvm
Network resourcing
With respect to network requirements, components should be located in a data centre with
good network reliability and bandwidth. Network connection speeds of 100 Megabits per
second or higher are typically sufficient.
Solution delivery
Consideration as to how a Netcool solution will be delivered by a solution engineering team
should be given during the planning phase of any deployment project. The delivered
Page 18 of 71
Licensed Materials – Property of IBM
solution should include all custom configuration and all relevant documentation. The
concepts introduced in this section will be referred to throughout this document.
All deliverables should be reviewed with the end-customer before final project acceptance
and sign-off. The "end-customer" will normally be the primary stakeholder and owner of the
resulting Netcool deployment.
Custom configuration
The following list summarises the best practice approach for delivery of each of the custom
configuration components in a solution ― and ensures that a solution is as portable and
modular as possible.
All the items mentioned below should be collected together into a single directory location
and packaged up together (ie. using a zip or tar utility) for delivery along with the
documentation described in the next section.
It is recommended that each of the following Netcool/Impact component configurations be
delivered as follows:
One or more custom Netcool/Impact “projects” should be created so that custom
components can be assigned to the project(s). Note that a component can be associated
with more than one project. Associating custom components with projects makes the
export/import process between different systems easier ― for example: between test and
production.
Note: It is usual that external Data Sources will be different between development and
production environments. As such, Data Sources should normally be assigned to a different
project to the other custom components so that they are not exported from one environment
to another. In such cases, the Data Sources will have to be set up manually on initial
installation and configuration. Note that it only needs to be configured on the primary as the
secondary Impact servers in the cluster will synchronise to the primary automatically when
each one is started. See the Netcool/Impact 7.1 User Interface Guide for more information about
working with projects.
Name Server configuration is done at installation time and typically doesn’t require
modification after this point. The configuration of the Name Server cluster therefore
should be documented in the Detailed Design Document (DDD) and configured for each
system at the time of installation.
Note: See the section entitled: Documentation later in this document for more information
around what needs to go into the Detailed Design Document.
Operator Views can occasionally include auxiliary files ― for example: HTML or image
files ― that need to be included in the solution delivery. These files should be collected
using tar (UNIX) or a zip utility (Windows) so that they can be easily rolled out on a
target system.
Page 19 of 71
Licensed Materials – Property of IBM
NOTES:
Solution portability is important when deploying the solution to multiple locations ― for
example, when replicating an environment from development, to test and then to
production. A portable solution also makes it very easy for the environment to be
recreated elsewhere ― for example, by IBM Netcool Technical Support engineers in their
labs. Following the guidance above will result in a very portable solution.
Any configuration files that are modified by hand should be backed up before they are
changed. For example, any changes to files in the $IMPACT_HOME/etc/ directory
should be copied to a file of the same name with an appropriate file extension:
Thereafter, if any updates are made to the "live" file, a further backup copy should be
taken before making any changes. This will allow a rapid roll-back, if required.
A suggested naming convention for the backup copy filenames is to append them with a
.<date> file extension. For example:
Documentation
Clear and thorough documentation is key to the success of any Netcool solution delivery.
The solution delivery documentation would normally be produced by the engineering team
responsible for delivering the solution. The documentation set is essential for anyone
reviewing, deploying or maintaining the solution.
The Business Requirements Document
The first key document is the Business Requirements Document (BRD). The BRD should
contain a detailed description about every piece of custom functionality that will be required
by the Netcool deployment ― including pseudocode, where possible.
A necessary prerequisite to the production of the BRD would be for the solution delivery
team to undertake discussions with the business management and stakeholders in order to
compile a detailed list of the business requirements. The signed-off BRD is essential for
ensuring that solution scope does not creep during the solution development phase.
An example requirement pseudocode entry follows:
All incoming network events must have their Location field enriched with details from the inventory
database. Details must include:
Site city location;
Building name;
Room number.
Page 20 of 71
Licensed Materials – Property of IBM
Any events for Nodes not found in the inventory database should be cleared.
Note: The BRD will include requirements that will likely need more than just
Netcool/Impact to provide. For example, Netcool/OMNIbus is usually at the centre of most
Netcool solution deployments and requirements will likely be met by a combination of
products. The implementation details are not included in the BRD however ― just the
requirements themselves.
Note: If the solution delivery package contains implementation components for more than
one product, subdirectories should be created within the package for each product (eg:
omnibus/, impact/, etc.)
The documentation should be produced in the order listed above ― that is: the BRD first,
then the DDD and finally the SDPD. If there are any necessary changes to the requirements
at any stage of the development phase, the documents will have to be reviewed and modified
in the same order as they were initially produced.
Page 21 of 71
Licensed Materials – Property of IBM
Note: Monitoring of all Netcool components would be necessary during such testing to
ensure that all components have been engineered to handle such occurrences.
When loading up the Netcool system with data, it is important to use a representative set of
data similar to what production would likely hold. This will ensure that memory usage and
load will be similar to what would be encountered in production. There is limited value in
stress testing a system with synthetic events that are not acted upon by custom functionality.
Page 22 of 71
Licensed Materials – Property of IBM
Chapter 3 Installation
Full instructions for installing Netcool/Impact 7.1 can be found in the Netcool/Impact 7.1
Administration Guide.
http://www.ibm.com/support/fixcentral/swg/selectFixes?parent=ibm~Tivoli&product
=ibm/Tivoli/Prerequisite+Scanner&release=All&platform=All&function=all
As an example, see the following tech note for information about using the IBM Prerequisite
Scanner with Netcool/OMNIbus:
http://www.ibm.com/support/docview.wss?rs=3120&uid=swg21472859
Page 23 of 71
Licensed Materials – Property of IBM
The Xmx setting can be set to a value just short of the amount of physical memory that has
been provisioned for Netcool/Impact. For example, if 8 GB of memory has been provisioned
for the Netcool/Impact server’s use, Xmx could be set to 7,800 MB. With the additional 150
MB of memory that Netcool/Impact reserves on top of this, this would make the maximum
process size 7,950 MB ― which is just short of the 8 GB provisioned.
It is a best practice to run self monitoring on all elements for Netcool/Impact. Self
monitoring information will provide a Netcool Administrator essential information to enable
them to effectively monitor the installed Netcool/Impact system.
Note: For more information on configuring memory settings in Netcool/Impact and for
instructions on how to modify the Xms and Xmx properties, see the Netcool/Impact 7.1
Administration Guide available from here: http://ibm.biz/netcool_impact_docs
Page 24 of 71
Licensed Materials – Property of IBM
Chapter 4 Clustering
This chapter contains best practice information in relation to the clustering of
Netcool/Impact components. The two main components to consider are the Impact servers
and the Name Servers that provide clustering management services to the Impact servers.
Prior to Netcool/Impact 6.1, the Name Server was integrated into the GUI server. From
Netcool/Impact 6.1 onwards however, the Name Server is built in to the Impact server.
Hence there will be as many Name Servers present as there are Impact servers. Since one
Name Server is included with each Impact server, it is recommended to include all Name
Servers in the Name Server cluster setup.
The two main purposes of clustering Impact servers are to ensure resiliency and to provide
load-balancing capabilities. The main purpose of clustering Name Servers is to provide a
resilient cluster management service to the Impact servers.
Name Server cluster members are aware of each other as soon as they start and automatically
replicate any Impact server cluster management data between them. Impact servers, on the
other hand, have no awareness of each other when they start up ― and rely on Name Server
services to coordinate their cooperative activities. The primary purpose of the Name Servers
is to provide this clustering management to the Impact servers ― including the nomination
and management of who is the primary Impact server within each cluster.
Resiliency is provided within Netcool/Impact by having two or more Impact servers
configured to run together as a cluster. This ensures there is no single point of failure. It is
also important to properly configure the Name Servers to work together.
Note: For more detailed information on Netcool/Impact clustering and how to configure
it, see the Netcool/Impact 7.1 Administration Guide.
Page 25 of 71
Licensed Materials – Property of IBM
Impact Impact
server Impact server
server
cluster
Name
Name server Name
server cluster server
Host Host
Adding further Impact servers increases both the resiliency and the processing capabilities of
the Impact server cluster. Adding further Name Servers to a Name Server cluster will not
increase processing capabilities, however ― it will increase the resiliency of the Name Server
cluster management service.
Note: For detailed information on how to configure both Impact server and Name Server
clustering, see the Netcool/Impact 7.1 Administration Guide.
Cluster operation
This section briefly outlines how the two different Impact cluster types work.
NAME SERVER CLUSTERING
At least two Name Servers should be configured to work together as a cluster within any
Netcool/Impact deployment. Each Name Server participating in the cluster should, as part
of its configuration, include a listing of each of the cluster Name Server members
participating in the cluster ― including itself. The configuration of the Name Server listing
should be done uniformly across each cluster member so that each is aware of the other
cluster members on start-up.
Page 26 of 71
Licensed Materials – Property of IBM
On initial start-up, each Name Server cluster member will read its configuration and attempt
to establish communications with the other Name Server cluster members listed in the
configuration. Once a connection is established, a Name Server cluster member will attempt
to synchronise any Impact server cluster management data that may be held.
If a Name Server is unable to reach another Name Server listed in its cluster configuration ―
either because the remote Name Server has gone down or simply has not yet been started ― it
will periodically attempt to reconnect. Once successful connection has been established
between two Name Server cluster members, they will synchronise their cluster management
data.
If an update is made to any of the Name Server cluster members’ cluster management data ―
for example: a secondary Impact server joining the Impact server cluster, it is automatically
replicated to the other Name Server cluster members.
IMPACT SERVER CLUSTERING
An Impact server will always try to connect to the first available Name Server cluster
member in the order that they are defined in the nameserver.props file. Once an Impact
server registers itself with a Name Server, the Name Server cluster member will then
automatically share this information with the other Name Server cluster members.
Note: If an Impact server successfully connects to the first Name Server listed in its
nameserver.props file, it will not attempt to connect to any other Name Servers unless it
loses connection to the first one. Even then, it will attempt to re-establish connection to the
first Name Server listed in the nameserver.props file before trying the second one. If an
Impact server connects to a secondary Name Server due to an outage of the primary Name
Server, the Impact server will automatically fail back to the primary Name Server once it
comes back up again.
There are two scenarios that can occur when an Impact server connects to a Name Server.
The first scenario is where the first Impact server in an Impact server cluster is connecting to
a Name Server cluster:
Impact server → Name Server: “Hello, I am an Impact server running on: hosta, on port X;
and am a member of cluster NCI. Is there already an Impact server cluster member registered
with you under cluster name NCI?”
Name Server → Impact server: “No, you are the first. I will register you as the acting primary
for Impact server cluster NCI.”
The Impact server will start all its services and begin normal operation.
The second scenario is where an Impact server is attempting to join a cluster for which there
is already an acting primary running:
Impact server → Name Server: “Hello, I am an Impact server running on: hostb, on port Y;
and am a member of cluster NCI. Is there already an Impact server cluster member registered
with you under cluster name NCI?”
Name Server → Impact server: “Yes there is. The acting primary Impact server for cluster
NCI is located at hosta on port X. I will register you as a secondary for Impact server cluster
NCI.”
The Impact server will open a connection to the primary Impact server cluster member
on hosta/port X and request a resynchronisation.
The secondary Impact server will synchronise (overwrite) its configuration with that of
the acting primary Impact server of cluster NCI and assume a secondary role.
Page 27 of 71
Licensed Materials – Property of IBM
All Impact servers that register with a Name Server will periodically send a heartbeat and re-
verify who the current acting primary Impact server is for the cluster. If a Name Server fails
to receive a heartbeat from an Impact server, it will eventually mark that Impact server
cluster member as dead.
If the failed Impact server cluster member happens to be the primary, the first secondary
Impact server cluster member to check in with the Name Server thereafter will assume the
role of acting primary when the Name Server tells it that the primary Impact server has gone
down. Subsequent secondary Impact servers that check in with the Name Server will be
informed of the new acting primary at which time the remaining secondary Impact servers
will resynchronise with the new acting primary ― and operation will continue.
If the previous acting primary Impact server subsequently comes back up, it will go through
the normal Name Server connection process described above and assume a secondary role.
Note: It is possible to configure failback within an Impact server cluster ― that is, a
primary Impact server will reassume the role of primary cluster member when it comes back
up after an outage. This can be done by setting the property:
impact.server.preferredprimary to TRUE in the target Impact server’s properties file.
See the section entitled: The Impact Server properties file in the Netcool/Impact 7.1 Administration
Guide for more information on how to configure this behaviour. Also see this section for
information on how to configure any secondary Impact servers to wait for the primary
Impact server to start before they start.
Page 28 of 71
Licensed Materials – Property of IBM
If the network connectivity between sites A and B is unreliable, or if the connection between
the sites is not resilient and there is an outage, consideration should be given to what would
happen in such a scenario.
The process of operation of both the Impact server cluster and the Name Server cluster is
outlined in a previous section: Cluster operation. In the case of a network outage between the
two sites, the following would occur ― not necessarily in this order:
Both Name Servers would notice a loss of connectivity to its counterpart and assume that
the other is down. The secondary Name Server would assume the role of primary Name
Server for the cluster.
The primary Impact server would notice that the secondary Impact server is down and
continue operation since it can still reach its primary Name Server. The primary Name
Server would allow the primary Impact server to continue as a primary cluster member
since it is available.
The secondary Impact server would notice that the primary Impact server is unavailable
and so attempt to contact the primary Name Server ― which would also be unreachable.
The secondary Impact server would then attempt to contact the secondary Name Server
as per its nameserver.props file.
The secondary Impact server would go through the normal connection routine with the
secondary Name Server: first asking if a primary Impact server already exists for cluster
NCI and, if not, request that it becomes the primary.
The secondary Name Server will subsequently assign the secondary Impact server the
primary role within the cluster NCI. There would now be two separate Impact clusters
running ― neither aware that the other is up and running.
When the network connection is restored, the following would occur:
The Name Servers would re-establish contact with each other. Since the original primary
Name Server is listed as Name Server “0” in both Name Server configurations, the
Page 29 of 71
Licensed Materials – Property of IBM
primary will re-assume the role of primary Name Server ― hence the secondary Name
Server will synchronise to it.
When the secondary Impact server (who is currently running as a primary) next pings
the secondary Name Server, the secondary Impact server will be told that there is already
a primary Impact server present for the NCI cluster. The secondary Impact server will
then contact the primary Impact server, synchronise to it and then revert to the role of
secondary within the cluster. The secondary Impact server will also notice the
availability of the primary Name Server and reconnect to it since it is the first Name
Server in its nameserver.props file and hence it is the preferred Name Server.
In this scenario, both halves of the Impact cluster will run as two, separate clusters ― each
one attempting to carry out the cluster’s assigned tasks as the primary cluster member.
If the running of the two halves of the cluster separately in the event of a network outage
between sites is a desirable side effect, then such a deployment option could be considered.
If it is not desirable however, that backup site Impact processing continue in the event of a
network outage between the sites, then an alternative option is to deploy two clusters: one on
each site. The cluster on the secondary site will be a cold stand-by and can be started when it
is needed ― for example: in the case of a Disaster Recovery site failover.
Note: A best practice document is freely available that describes the geographically
distributed best practice Netcool/OMNIbus architecture. The document is entitled:
Netcool/OMNIbus Large scale and geographically distributed architectures and is available from
the Netcool/OMNIbus best practices site: http://ibm.biz/nco_bps
Since the underlying Netcool/OMNIbus systems at each region are independent of each
other and not connected, it is recommended to do likewise with Netcool/Impact. In a
geographically distributed scenario, each geographic location that requires Netcool/Impact
capabilities should have its own, separate cluster. The configuration can easily be ported
between the clusters using the export/import functionality plus gives the added benefit that
Netcool/Impact configurations can be different, when needed, based on differing regional
requirements.
EXAMPLE:
Widgetcom have deployed a separate Netcool/OMNIbus system at each of its data centres in
Sao Paolo, Brazil and Perth, Australia. They plan to use Web GUI to enable them to view
events from both locations in the same views. Advanced correlation and trouble ticketing
functionality is required from Netcool/Impact at both locations.
The Netcool Administrator elects to deploy a separate Netcool/Impact cluster within each
geography to provide the required functionality. This will help to avoid a “split brain”
scenario across geographical regions as well as to minimise WAN traffic due to data being
exchanged amongst geographically distributed Netcool/Impact cluster members.
Page 30 of 71
Licensed Materials – Property of IBM
Page 31 of 71
Licensed Materials – Property of IBM
Note: Detailed information regarding how to set up and configure each of the
Netcool/Impact Data Sources and Data Types can be found in the Netcool/Impact 7.1 DSA
Reference Guide – available from here: http://ibm.biz/netcool_impact_docs
IBM Netcool/Impact 7.1 Best Practices Chapter 5: Data Sources and Data Types
© Copyright IBM Corporation 2016.
Page 32 of 71
Licensed Materials – Property of IBM
Note: For more information on the embedded Derby Apache database and how to use it,
see the section entitled: Managing the database server in the Netcool/Impact 7.1 Administration
Guide – available from here: http://ibm.biz/netcool_impact_docs
IBM Netcool/Impact 7.1 Best Practices Chapter 5: Data Sources and Data Types
© Copyright IBM Corporation 2016.
Page 33 of 71
Licensed Materials – Property of IBM
Chapter 6 Policies
This chapter contains best practices principles in relation to the writing of Netcool/Impact
policies.
Generally speaking, the best practices relating to writing Impact policies are, for the most
part, good practices that apply to programming generally. This section covers more general
programming good practices plus a number of additional points that are Impact specific.
Note: Information on how to create policies including a detailed reference of each of the
policy language functions can be found in the: Netcool/Impact 7.1 Policy Reference Guide –
available from here: http://ibm.biz/netcool_impact_docs
////////////////////////////////////////////////////////////////////////
// EnrichLocation
//
// Created by: J. Smith (jsmith) 12/04/2013
//
// The purpose of this policy is to enrich all incoming events with
// each Node's location. This is done by looking the Node of each
// event up in the Inventory DB2 database. If the Node is not found
// in the Inventory database, the Location field is set to NOT FOUND.
// The Event Reader filter for this policy should be:
//
// Location = ''
//
////////////////////////////////////////////////////////////////////////
Page 34 of 71
Licensed Materials – Property of IBM
Page 35 of 71
Licensed Materials – Property of IBM
Use of comments
The use of comments within the context of programming is a fundamental best practice of
software engineering. It is also a best practice of solution development within the Netcool
suite. Including comments in-line in Impact policy code is a best practice ― and one which is
often neglected in Netcool/Impact deployments.
If a Netcool configuration is thoroughly commented, an engineer beginning work on an
existing system can deduce very quickly what a piece of functionality is supposed to do ―
and how it is supposed to do it.
For Netcool/Impact, extensive commenting should be present in all policies, configuration
files and anywhere else it makes sense to include them. This section contains a number of
best practice conventions which should be followed wherever possible.
Include a header at the beginning of every policy
The first lines of every custom policy created as part of a Netcool solution should include
information about the policy and include at the very least:
The name of the policy;
The creator and last modifier (if applicable) of the policy;
The date of creation and/or the date of last modification;
A thorough description in plain language of what the policy does and how it does it.
Page 36 of 71
Licensed Materials – Property of IBM
Note: For more information on implementing hibernations including examples, see the:
Netcool/Impact 7.1 Solutions Guide – available from here: http://ibm.biz/netcool_impact_docs
Page 37 of 71
Licensed Materials – Property of IBM
Note: For more information on the policy logger service and how to configure it, see the:
the Netcool/Impact 7.1 User Interface Guide and the: Netcool/Impact 7.1 Policy Reference Guide for
further examples on how to use the log statement. Both of these documents are available
from here: http://ibm.biz/netcool_impact_docs
It is recommended to encode log statements throughout custom policies. Not only will it
assist with the development phase, it will also provide a mechanism that can be “switched
on” via the policy logger service in a production system, in the event of an indeterminable
issue, to provide critically important debugging information.
EXAMPLE:
The Netcool solutions developer encodes the following policy fragment with additional log
statements to enable debugging to be done, should the need arise.
Page 38 of 71
Licensed Materials – Property of IBM
Note: For more information on exceptions and exception handling, see the section entitled:
Exception handling specification in Chapter 2 of this document.
Note: For more information about Netcool/Impact Event Isolation and Correlation, see
the: Netcool/Impact 7.1 Solutions Guide – available from here:
http://ibm.biz/netcool_impact_docs
Page 39 of 71
Licensed Materials – Property of IBM
Chapter 7 Services
This chapter contains best practices principles in relation to the configuration and use of
Netcool/Impact Services.
Note: For more information on the Event Processor Service, see the: Netcool/Impact 7.1 User
Interface Guide – available from here: http://ibm.biz/netcool_impact_docs
In setting up the minimum and maximum numbers of threads in the Event Processor of a
Netcool/Impact 7.1 server, the following guidelines should be followed.
Minimum number of threads: (number of CPUs/cores) + 1
Maximum number of threads: (number of CPUs/cores + 2) × 5
Note: The Event Processor Service should be restarted if any changes are made to its
configuration.
Page 40 of 71
Licensed Materials – Property of IBM
In a clustered environment, changes made to the event processor service via the GUI will
only be applied to the primary Impact Server and do not automatically propagate to the other
Impact servers in the cluster. It is recommended therefore to configure the Event Processor
via the Command Line Interface (CLI) or via the event processor service’s properties file.
Note: For more information about configuring the Event Processor Service in a clustered
environment, see the: Netcool/Impact 7.1 Administration Guide – available from here:
http://ibm.biz/netcool_impact_docs
EXAMPLE:
The Netcool Administrator is setting up a secondary Impact server on a dedicated machine
that has 4 available cores. Based on the best practice guidance, the minimum number of
threads is calculated to be (4) + 1 = 5. Based on the best practice guidance, the maximum
number of threads is calculated to be (4 + 2) × 5 = 30.
The Netcool Administrator connects to the secondary Impact server via the CLI, configures
the minimum and maximum thread settings for the Event Processor service and then restarts
the service:
READY
Update Service set MinNumThreads=5 where Name='EventProcessor';
Command Executed
READY
Update Service set MaxNumThreads=30 where Name='EventProcessor';
Command Executed
READY
Update Service set Running=FALSE where Name='EventProcessor';
Command Executed
READY
Update Service set Running=TRUE where Name='EventProcessor';
Command Executed
READY
Note: For more information and examples on how to configure the Event Processor
Service via the CLI, see the: Netcool/Impact 7.1 Administration Guide – available from here:
http://ibm.biz/netcool_impact_docs
Page 41 of 71
Licensed Materials – Property of IBM
performance testing to establish whether or not running at maximum throughput will impact
too much on the performance of the other processes.
Note: For more information on the Event Processor Service, see the: Netcool/Impact 7.1 User
Interface Guide – available from here: http://ibm.biz/netcool_impact_docs
Page 42 of 71
Licensed Materials – Property of IBM
Note: For more detailed information on the configuration of these two elements, see the:
Netcool/Impact 7.1 User Interface Guide – available from here:
http://ibm.biz/netcool_impact_docs
Page 43 of 71
Licensed Materials – Property of IBM
Caching data
If the data being read from the remote data source is fairly static, enabling data caching
should be considered. With data caching enabled, the Impact server will cache the results of
queries to the data source and refer to the cache when carrying out event processing before
going to the remote data source. If the data is found in the cache and has not yet expired, the
Impact server will use the cached copy of the data instead. The time-to-live setting will vary
depending on how frequently the target data changes.
If the remote data source dataset is relatively dynamic, then data caching is not
recommended. In such cases, it can quickly become inefficient to make the Impact server
cache and refer to data in its cache that it never or rarely actually uses.
Page 44 of 71
Licensed Materials – Property of IBM
Note: For more information on configuring the Policy Logger Service, see the:
Netcool/Impact 7.1 User Interface Guide – available from here:
http://ibm.biz/netcool_impact_docs
Note: See the section in this document entitled: Embedding log statements into policies for
tips on how to encode differing levels of log statements into your policy code.
Page 45 of 71
Licensed Materials – Property of IBM
Care must be taken therefore to ensure log statements are not executed by the Impact server
if it is anticipated that the result set will be significantly large ― even when the information
isn’t actually written to file, due to the defined log level.
This section outlines a mechanism that can be applied to ensure that log statements that
handle sizeable amounts of data are not executed unless they are required. At a high level,
the mechanism is as follows:
Create a global debug variable that is used as a debug level flag (SetGlobalVar function).
Use conditional constructs (ie. “if” statements) to control the path of execution within a
policy based on the value of the global debug variable. Log statements can then be
configured to only evaluate if the global debug variable is set to debug mode.
EXAMPLE:
The Netcool Solution Architect at Widgetcom wants to implement more detailed logging
messages within the production environment which can be activated when critical
production issues arise. She does not, however, wish to incur unnecessary performance
burdens on the Impact cluster while it is not necessary ― nor is it desirable to have a system
where policy changes are needed in order to activate the additional logging information.
The Netcool Solution Architect elects to insert key code fragments throughout the Impact
policies and use conditional statements combined with global variables to enable the
additional logging to be switched on or off.
An example Impact policy code fragment follows:
if (widgetcomdebug == true) {
Log(3,"Message : " + messageContent);
}
The variable widgetcomdebug will be toggled between true and false via an additional
policy. This additional policy will be activated as needed via the nci_trigger utility.
Page 46 of 71
Licensed Materials – Property of IBM
Page 47 of 71
Licensed Materials – Property of IBM
Machine start-up
It is a best practice to configure Netcool/Impact to start automatically when the machine it is
installed on boots up. This section contains instructions on how to set this up for both UNIX
and Windows operating systems.
UNIX
On a UNIX machine, the procedure involves creating a script in the init directory along with
soft links in the start-up directories to the script.
The script should be named /etc/init.d/nci and contain something like the following:
#!/bin/sh
IMPACT_HOME=/opt/IBM/Impact
export IMPACT_HOME
case "$1" in
'start')
su – netcool –c "${IMPACT_HOME}/ bin/startImpactServer.sh;
${IMPACT_HOME}/bin/startGUIServer.sh" &
;;
'stop')
su – netcool –c "${IMPACT_HOME}/ bin/stopImpactServer.sh;
${IMPACT_HOME}/bin/stopGUIServer.sh" &
;;
*)
echo "Usage: /etc/init.d/nci { start | stop }"
;;
esac
NOTES:
The installation directory may vary in your installation. Modify the environment
variables accordingly therefore.
The su command should be modified to match the installation user. This example
assumes Netcool/Impact is installed and run as the user: netcool.
This example assumes a GUI Server is installed on the same server. If the GUI Server is
not present, the command to start the GUI server should be omitted.
IBM Netcool/Impact 7.1 Best Practices Chapter 9: Final steps and considerations
© Copyright IBM Corporation 2016.
Page 48 of 71
Licensed Materials – Property of IBM
The script then needs to be protected from unauthorised view by setting the file permissions
appropriately:
Finally, the soft links need to be created to the start-up directories so that the script will be
called at the correct time during machine start-up and shut down:
ln -s /etc/init.d/nci /etc/rc0.d/K100nci
ln -s /etc/init.d/nci /etc/rc1.d/K100nci
ln -s /etc/init.d/nci /etc/rc2.d/S100nci
Windows
On a Windows machine, the auto-start process involves checking that the Windows service
that starts Netcool/Impact is set to start automatically when the machine starts.
Since this service is automatically created when the product is installed and, by default, set to
automatically start, it is likely that nothing further needs to be configured.
$IMPACT_HOME/bin/nci_export
$IMPACT_HOME/bin/nci_import
IBM Netcool/Impact 7.1 Best Practices Chapter 9: Final steps and considerations
© Copyright IBM Corporation 2016.
Page 49 of 71
Licensed Materials – Property of IBM
inadvertently overwrite the production data sources and data types when you import the
updated configuration from the development/test system.
EXAMPLE:
Widgetcom have completed testing the changes to the Impact custom configuration and are
ready to copy the updated content into production. In all the environments, the data sources
and data types are members of the DATASOURCES project and the rest of the custom
content are members of the WIDGETCOM project.
The Netcool Administrator uses the following command to export the configuration from the
test system:
The Netcool Administrator then tars up and copies the new custom configuration to the
production primary Impact server machine. The secondary Impact server is shut down at
this time in preparation for the import process.
The Netcool Administrator then un-tars the custom configuration package and uses the
following command to import the new custom configuration into the production primary
Impact server:
Finally, the Netcool Administrator restarts the secondary Impact server, ensures successful
resynchronisation and then monitors the system for a period of time until they are satisfied
that the new configuration is functioning correctly and within acceptable performance
parameters.
Self monitoring
Self-monitoring is used to monitor such aspects of Netcool/Impact runtime performance, as
memory status usage, event queue size, data source status, service status, and cluster status.
Enabling self monitoring causes an Impact cluster to monitor key performance indicators and
generate synthetic events within Netcool/OMNIbus. These key events are invaluable for a
Netcool Administrator to monitor Impact’s overall health and also for pre-empting potential
problems.
With full self monitoring enabled in Netcool/Impact, automated processes within
Netcool/OMNIbus can then be engineered to alert Netcool Administrators when critical self
monitoring events are generated ― for example: to send an email or an SMS.
IBM Netcool/Impact 7.1 Best Practices Chapter 9: Final steps and considerations
© Copyright IBM Corporation 2016.
Page 50 of 71
Licensed Materials – Property of IBM
It is a best practice to enable all Netcool/Impact self monitoring options on each Impact
cluster member. This includes development and test systems ― as it will provide valuable
insight into solution developers or testers as to how well suited the Impact solution is at
coping with the given expected loads.
Note: It is essential that any Netcool solution is tested thoroughly with a representative
dataset both in terms of quantity of data and the data’s content. This will provide suitable
validation of the solution prior to deploying into production.
You configure self-monitoring on each server instance separately, and each server runs the
self-monitoring feature independent of other cluster members. For a clustered
Netcool/Impact configuration therefore, self monitoring should be configured via the
$IMPACT_HOME/etc/servername_selfmonitoring.props properties file, or via the
command line interface. Using the GUI to configure self monitoring will configure the
primary Impact server only.
NOTES:
The sampling intervals for each self monitoring option should be set to the defaults;
All self monitoring options should be enabled for each Netcool/Impact server
participating in the cluster and set to auto-start when the server starts.
Note: For more information on Netcool/Impact 7.1 self monitoring, see the Netcool/Impact
7.1 Administration Guide available here: http://ibm.biz/netcool_impact_docs
IBM Netcool/Impact 7.1 Best Practices Chapter 9: Final steps and considerations
© Copyright IBM Corporation 2016.
Page 51 of 71
Licensed Materials – Property of IBM
Further reading
Page 52 of 71
Licensed Materials – Property of IBM
IBM Netcool/Impact 7.1 Best Practices Appendix A: Initial requirements gathering checklist
© Copyright IBM Corporation 2016.
Page 53 of 71
Licensed Materials – Property of IBM
IBM Netcool/Impact 7.1 Best Practices Appendix A: Initial requirements gathering checklist
© Copyright IBM Corporation 2016.
Page 54 of 71
Licensed Materials – Property of IBM
IBM Netcool/Impact 7.1 Best Practices Appendix A: Initial requirements gathering checklist
© Copyright IBM Corporation 2016.
Page 55 of 71
Licensed Materials – Property of IBM
List of all event sources Netcool/Impact will process events from ― page …… of ……:
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
IBM Netcool/Impact 7.1 Best Practices Appendix A: Initial requirements gathering checklist
© Copyright IBM Corporation 2016.
Page 56 of 71
Licensed Materials – Property of IBM
List of all custom Data Source Adaptors (DSAs) required by the solution ― page …… of ……:
NOTE: Include estimated reads/writes per second for each one.
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
IBM Netcool/Impact 7.1 Best Practices Appendix A: Initial requirements gathering checklist
© Copyright IBM Corporation 2016.
Page 57 of 71
Licensed Materials – Property of IBM
List of all custom Data Types (DTs) required by the solution ― page …… of ……:
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
IBM Netcool/Impact 7.1 Best Practices Appendix A: Initial requirements gathering checklist
© Copyright IBM Corporation 2016.
Page 58 of 71
Licensed Materials – Property of IBM
List of all custom Netcool/Impact Services required by the solution ― page …… of ……:
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
IBM Netcool/Impact 7.1 Best Practices Appendix A: Initial requirements gathering checklist
© Copyright IBM Corporation 2016.
Page 59 of 71
Licensed Materials – Property of IBM
IBM Netcool/Impact 7.1 Best Practices Appendix A: Initial requirements gathering checklist
© Copyright IBM Corporation 2016.
Page 60 of 71
Licensed Materials – Property of IBM
List of all custom event processing functionality (repeated or correlation) ― page …… of ……:
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
IBM Netcool/Impact 7.1 Best Practices Appendix A: Initial requirements gathering checklist
© Copyright IBM Corporation 2016.
Page 61 of 71
Licensed Materials – Property of IBM
Other notes:
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
IBM Netcool/Impact 7.1 Best Practices Appendix A: Initial requirements gathering checklist
© Copyright IBM Corporation 2016.
Page 62 of 71
Licensed Materials – Property of IBM
IBM Netcool/Impact 7.1 Best Practices Appendix A: Initial requirements gathering checklist
© Copyright IBM Corporation 2016.
Page 63 of 71
Licensed Materials – Property of IBM
Details of Operator View dashboard components (Data Sources, active component actions, etc):
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………
IBM Netcool/Impact 7.1 Best Practices Appendix A: Initial requirements gathering checklist
© Copyright IBM Corporation 2016.
Page 64 of 71
Licensed Materials – Property of IBM
IBM Netcool/Impact 7.1 Best Practices Appendix A: Initial requirements gathering checklist
© Copyright IBM Corporation 2016.
Page 65 of 71
Licensed Materials – Property of IBM
IBM Netcool/Impact 7.1 Best Practices Appendix A: Initial requirements gathering checklist
© Copyright IBM Corporation 2016.
Page 66 of 71
Licensed Materials – Property of IBM
Notices
This information was developed for products and services offered in the U.S.A.
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
Armonk, NY 10504-1785
U.S.A.
For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual
Property Department in your country or send inquiries, in writing, to:
IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106-0032, Japan
The following paragraph does not apply to the United Kingdom or any other country where
such provisions are inconsistent with local law: 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 states 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 Web sites are provided for convenience only
and do not in any manner serve as an endorsement of those Web sites. The materials at those
Web sites are not part of the materials for this IBM product and use of those Web sites is at
your own risk.
IBM may use or distribute any of the information you supply 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:
Page 67 of 71
Licensed Materials – Property of IBM
IBM Corporation
958/NH04
IBM Centre, St Leonards
601 Pacific Hwy
St Leonards, NSW, 2069
Australia
IBM Corporation
896471/H128B
76 Upper Ground
London
SE1 9PZ
United Kingdom
IBM Corporation
JBF1/SOM1 294
Route 100
Somers, NY, 10589-0100
United States of America
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.
Any performance data contained herein was determined in a controlled environment.
Therefore, the results obtained in other operating environments may vary significantly. Some
measurements may have been made on development-level systems and there is no guarantee
that these measurements will be the same on generally available systems. Furthermore, some
measurements may have been estimated through extrapolation. Actual results may vary.
Users of this document should verify the applicable data for their specific environment.
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.
All 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.
Page 68 of 71
Licensed Materials – Property of IBM
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 the
names and addresses used by an actual business enterprise 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.
If you are viewing this information softcopy, the photographs and color illustrations may not
appear.
Trademarks
These terms are trademarks of International Business Machines Corporation in the United
States, other countries, or both:
AIX
developerWorks
IBM
Lotus
Netcool
Tivoli
WebSphere
Adobe, Acrobat, Portable Document Format (PDF), PostScript, and all Adobe-based trademarks
are either registered trademarks or trademarks of Adobe Systems Incorporated in the United
States, other countries, or both.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of
Oracle, Inc. in the United States, other countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft
Corporation in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Intel is a registered trademark of Intel Corporation, Inc. in the United States, other countries,
or both.
Other company, product, or service names may be trademarks or service marks of others.
Page 69 of 71
Licensed Materials – Property of IBM