IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA

IBM® Tivoli® Netcool/OMNIbus Probe for CA Spectrum V9
(CORBA)
Version 6.0
Reference Guide
July 31, 2015
SC27-2722-08
IBM® Tivoli® Netcool/OMNIbus Probe for CA Spectrum V9
(CORBA)
Version 6.0
Reference Guide
July 31, 2015
SC27-2722-08
Notice
Before using this information and the product it supports, read the information in “Notices and Trademarks,” on page 37.
Edition notice
This edition (SC27-2722-08) applies to version 6.0 of IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9
(CORBA) and to all subsequent releases and modifications until otherwise indicated in new editions.
This edition replaces SC27-2722-05.
© Copyright IBM Corporation 2010, 2015.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Contents
About this guide . . . . . . . . . . . v
Document control page . . . . . . . . . . . v
Conventions used in this guide . . . . . . . . vi
IBM Tivoli Netcool/OMNIbus Probe for
CA Spectrum V9 (CORBA) . . . . . . . 1
Summary . . . . . . . . . . . . . . . 1
Installing probes . . . . . . . . . . . . . 2
Setting environment variables . . . . . . . . 3
Installing Spectrum utilities . . . . . . . . . 3
Firewall considerations . . . . . . . . . . . 4
Configuring SpectroSERVERs . . . . . . . . . 5
Configuring the probe . . . . . . . . . . . 5
Using the host configuration file . . . . . . . 5
Using lookup tables . . . . . . . . . . 10
Configuring ObjectServer host properties . . . 12
Data acquisition . . . . . . . . . . . . . 12
Configuring the event details extraction buffering
mechanism . . . . . . . . . . . . . 13
© Copyright IBM Corp. 2010, 2015
Specifying the event extraction method
probe uses. . . . . . . . . .
Resynchronization . . . . . . .
Filtering alarms . . . . . . . .
Backoff strategy . . . . . . . .
Command line interface . . . . .
Peer-to-peer failover functionality . .
Properties and command line options .
Elements . . . . . . . . . . .
Error messages . . . . . . . . .
ProbeWatch messages . . . . . . .
Running the probe . . . . . . . .
Troubleshooting . . . . . . . . .
Known issues. . . . . . . . . .
that the
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
13
14
15
16
16
18
19
25
27
32
34
34
35
Appendix. Notices and Trademarks . . 37
Notices . . .
Trademarks .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 37
. 39
iii
iv
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA): Reference Guide
About this guide
The following sections contain important information about using this guide.
Document control page
Use this information to track changes between versions of this guide.
The IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA)
documentation is provided in softcopy format only. To obtain the most recent
version, visit the IBM® Tivoli® Knowledge Center:
http://www-01.ibm.com/support/knowledgecenter/?lang=en#!/SSSHTQ/
omnibus/probes/common/Probes.html
Table 1. Document modification history
Document
version
Publication
date
Comments
SC27-2722-00
January 15,
2010
First IBM publication.
SC27-2722-01
December 31,
2010
Installation section replaced by “Installing probes” on
page 2.
“Firewall considerations” on page 4 added.
SC27-2722-02
March 02,
2012
Information about operating system conventions added in
“Conventions used in this guide” on page vi.
Requirements updated in “Summary” on page 1.
Information about installing CA Spectrum utilities added
in “Installing Spectrum utilities” on page 3.
Information about configuring ObjectServer host
properties added in “Configuring ObjectServer host
properties” on page 12.
Resynchronization information updated in
“Resynchronization” on page 14.
Information about filtering alarms updated in “Filtering
alarms” on page 15.
The following properties were added or updated in
“Properties and command line options” on page 19:
v MaxSpectrumSeverity
v ORBLocalHost
v ORBLocalPort
v ResyncOnFailover
v ResyncPrimaryOnly
v Retry
Timestamp filtering issue described in “Known issues” on
page 35.
© Copyright IBM Corp. 2010, 2015
v
Table 1. Document modification history (continued)
Document
version
Publication
date
Comments
SC27-2722-03
May 11, 2012
Description of the EventFormatFile host configuration
property updated in “Using the host configuration file”
on page 5.
SC27-2722-04
November 8,
2013
“Configuring the event details extraction buffering
mechanism” on page 13 added
“Specifying the event extraction method that the probe
uses” on page 13 added.
Descriptions for the following properties were added in
“Properties and command line options” on page 19:
v MaxSpectrumSeverity
v ORBLocalHost
v ORBLocalPort
v ResyncOnFailover
v ResyncPrimaryOnly
v Retry
SC27-2722-05
July 11, 2014
“Summary” on page 1 updated.
Information about using the probe with CA Spectrum
version 9.3 added to “Known issues” on page 35.
SC27-2722-08
July 31, 2015
Information about resolving the domain name
configuration was added to “Troubleshooting” on page
34.
Conventions used in this guide
All probe guides use standard conventions for operating system-dependent
environment variables and directory paths.
Operating system-dependent variables and paths
All probe guides use standard conventions for specifying environment variables
and describing directory paths, depending on what operating systems the probe is
supported on.
For probes supported on UNIX and Linux operating systems, probe guides use the
standard UNIX conventions such as $variable for environment variables and
forward slashes (/) in directory paths. For example:
$OMNIHOME/probes
For probes supported only on Windows operating systems, probe guides use the
standard Windows conventions such as %variable% for environment variables and
backward slashes (\) in directory paths. For example:
%OMNIHOME%\probes
For probes supported on UNIX, Linux, and Windows operating systems, probe
guides use the standard UNIX conventions for specifying environment variables
and describing directory paths. When using the Windows command line with
vi
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA): Reference Guide
these probes, replace the UNIX conventions used in the guide with Windows
conventions. If you are using the bash shell on a Windows system, you can use the
UNIX conventions.
Note: The names of environment variables are not always the same in Windows
and UNIX environments. For example, %TEMP% in Windows environments is
equivalent to $TMPDIR in UNIX and Linux environments. Where such variables are
described in the guide, both the UNIX and Windows conventions will be used.
Operating system-specific directory names
Where Tivoli Netcool/OMNIbus files are identified as located within an arch
directory under NCHOME or OMNIHOME, arch is a variable that represents your
operating system directory. For example:
$OMNIHOME/probes/arch
The following table lists the directory names used for each operating system.
Note: This probe may not support all of the operating systems specified in the
table.
Table 2. Directory names for the arch variable
Directory name represented by arch
Operating system
®
AIX systems
aix5
HP-UX PA-RISC-based systems
hpux11
HP-UX Integrity-based systems
hpux11hpia
Red Hat Linux and SUSE systems
linux2x86
Linux for System z
®
linux2s390
Solaris systems
solaris2
Windows systems
win32
OMNIHOME location
Probes and older versions of Tivoli Netcool/OMNIbus use the OMNIHOME
environment variable in many configuration files. Set the value of OMNIHOME as
follows:
v On UNIX and Linux, set $OMNIHOME to $NCHOME/omnibus.
v On Windows, set %OMNIHOME% to %NCHOME%\omnibus.
About this guide
vii
viii
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA): Reference Guide
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9
(CORBA)
The CA Spectrum element management system (EMS) uses SpectroSERVERs to
collect, process, and store information about managed network elements.
The Probe for CA Spectrum V9 (CORBA) collects alarm information from one or
more SpectroSERVERs using a proprietary Common Object Request Broker
Architecture (CORBA) interface.
This guide contains the following sections:
v “Summary”
v “Installing probes” on page 2
v “Setting environment variables” on page 3
v “Installing Spectrum utilities” on page 3
v “Firewall considerations” on page 4
v “Configuring SpectroSERVERs” on page 5
v
v
v
v
v
“Configuring the probe” on page 5
“Data acquisition” on page 12
“Properties and command line options” on page 19
“Elements” on page 25
“Error messages” on page 27
v “ProbeWatch messages” on page 32
v “Running the probe” on page 34
v “Troubleshooting” on page 34
v “Known issues” on page 35
Summary
Each probe works in a different way to acquire event data from its source, and
therefore has specific features, default values, and changeable properties. Use this
summary information to learn about this probe.
The following table provides a summary of the Probe for CA Spectrum V9
(CORBA).
Table 3. Summary
Probe target
CA Spectrum versions 9.0 - 9.3
Note: To run the probe with CA Spectrum version 9.3,
you must use the libraries supplied with an earlier
version, for example, CA Spectrum version 9.2.
Probe executable name
nco_p_spectrum_corba_v9
Probe installation package
omnibus-arch-probe-nco-p-spectrum-corba-v9-version
Package version
6.0
© Copyright IBM Corp. 2010, 2015
1
Table 3. Summary (continued)
Probe supported on
For details of supported operating systems, see the
following Release Notice on the IBM Software Support
website:
https://www-304.ibm.com/support/
docview.wss?uid=swg21641820
Properties file
$OMNIHOME/probes/arch/spectrum_corba_v9.props
Rules file
$OMNIHOME/probes/arch/spectrum_corba_v9.rules
Host configuration file
$OMNIHOME/probes/arch/spectrum_corba_v9_host.xml
Additional probe files
spectrum_corba_v9.xsd
SpectrumCause.pl
Requirements
For details of any additional software that this probe
requires, refer to the description.txt file that is
supplied in its download package.
Connection method
CORBA
Remote connectivity
The probe can connect to a remote device using a
CORBA interface.
Multicultural support
Available
For information about configuring multicultural
support, including language options, see the IBM Tivoli
Netcool/OMNIbus Installation and Deployment Guide.
Peer-to-peer failover functionality Available
IP environment
IPv4 and IPv6
Federal Information Processing
Standards (FIPS)
IBM Tivoli Netcool/OMNIbus V7.3.0, 7.3.1, 7.4.0, and
8.1 use the FIPS 140-2 approved cryptographic provider:
IBM Crypto for C (ICC) certificate 384 for cryptography.
This certificate is listed on the NIST website at
http://csrc.nist.gov/groups/STM/cmvp/documents/
140-1/1401val2004.htm. For details about configuring
Netcool/OMNIbus for FIPS 140-2 mode, see the IBM
Tivoli Netcool/OMNIbus Installation and Deployment Guide.
Installing probes
All probes are installed in a similar way. The process involves downloading the
appropriate installation package for your operating system, installing the
appropriate files for the version of Netcool/OMNIbus that you are running, and
configuring the probe to suit your environment.
The installation process consists of the following steps:
1. Downloading the installation package for the probe from the Passport
Advantage Online website.
Each probe has a single installation package for each operating system
supported. For details about how to locate and download the installation
package for your operating system, visit the following page on the IBM Tivoli
Knowledge Center:
http://www-01.ibm.com/support/knowledgecenter/SSSHTQ/omnibus/
probes/all_probes/wip/reference/install_download_intro.html
2. Installing the probe using the installation package.
2
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA): Reference Guide
The installation package contains the appropriate files for all supported
versions of Netcool/OMNIbus. For details about how to install the probe to
run with your version of Netcool/OMNIbus, visit the following page on the
IBM Tivoli Knowledge Center:
http://www-01.ibm.com/support/knowledgecenter/SSSHTQ/omnibus/
probes/all_probes/wip/reference/install_install_intro.html
3. Configuring the probe.
This guide contains details of the essential configuration required to run this
probe. It combines topics that are common to all probes and topics that are
peculiar to this probe. For details about additional configuration that is
common to all probes, see the IBM Tivoli Netcool/OMNIbus Probe and Gateway
Guide.
Setting environment variables
Environment variables are specific preset values that establish the working
environment of the probe.
The minimum requirement to run this probe is Java 6. The selection of the JRE
used for the probe's runtime environment adheres to the following order of
precedence:
1. The JRE specified by the $NCO_PROBE_JRE environment variable.
2. The JRE specified by the $JAVA_HOME environment variable.
3. The most recent JRE version available to Netcool/OMNIbus.
Note:
If the version of Netcool/OMNIbus that you are using did not come with Java 6,
you must perform one of the following actions before running the probe:
v Edit the $OMNIHOME/probes/java/nco_p_spectrum_corba_v9.env file to add the
Java 6 directory to the $NCO_PROBE_JRE environment variable.
v Add the Java 6 directory to the $JAVA_HOME environment variable of the probe's
host machine.
Installing Spectrum utilities
The probe requires access to a number of Java utilities that are supplied with your
CA Spectrum installation.
Copy the following files from $SPECROOT/lib to $OMNIHOME/probes/java/
nco_p_spectrum_corba_v9/:
v jsafeJCEFIPS.jar
v
v
v
v
v
v
v
global9x.jar
lm.jar
ssorb9x.jar
ssorbutil9x.jar
util9x.jar
utilapp9x.jar
utilnet9x.jar
v utilsrv9x.jar
v vbhelper9x.jar
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA)
3
v vbjorb.jar
v vbsec.jar
where $SPECROOT is the directory where CA Spectrum is installed and 9x is the
version of CA Spectrum that you are running.
Note: You will have to create the nco_p_spectrum_corba_v9 folder manually.
For probe installations on Linux operating systems, you must also copy the
following files to $OMNIHOME/probes/java/nco_p_spectrum_corba_v9/:
v sanct6.jar
v sanctuary.jar
Firewall considerations
When using CORBA probes in conjunction with a firewall, the firewall must be
configured so that the probe can connect to the target system.
Most CORBA probes can act as both a server (listening for connections from the
target system) and a client (connecting to the port on the target system to which
the system writes events). If you are using the probe in conjunction with a firewall,
you must add the appropriate firewall rules to enable this dual behavior.
There are three possible firewall protection scenarios, for which you must
determine port numbers before adding firewall rules:
1. If the host on which the probe is running is behind a firewall, you must
determine what remote host and port number the probe will connect to.
2. If the host on which the target system is running is behind a firewall, you must
determine the incoming port on which the probe will listen and to which the
target system will connect.
3. If each host is secured with its own firewall, you must determine the following
four ports:
a. The outgoing port (or port range) for the probe.
b. The hostname and port of the target system.
c. The outgoing port on which the target system sends events if the probe is
running as a client.
d. The incoming port on which the probe listens for incoming events.
Note: Most, but not all, CORBA probes listen on the port specified by the
ORBLocalPort property. The default value for this property is 0, which means that
an available port is selected at random. If the probe is behind a firewall, the value
of the ORBLocalPort property must be specified as a fixed port number.
CORBA probes that use EventManager or NotificationManager objects may use
different hosts and ports from those that use NamingService and EntryPoint
objects. If the probe is configured to get object references from a NamingService or
EntryPoint object, you must obtain the host and port information from the system
administrator of the target system. When you have this information, you can add
the appropriate firewall rules.
4
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA): Reference Guide
Configuring SpectroSERVERs
You must configure the SpectroSERVERs that you are using to enable them to
accept CORBA connections from the probe.
Configuring a SpectroSERVER to accept connections from the probe involves the
following tasks:
1. Using the Spectrum Control Panel (SCP) or OneClick to add the details of the
probe host system to the SpectroSERVER's server list.
Note: If you add a plus sign (+) to the sever list, all hosts will be able to
connect to the SpectroSERVER.
2. Creating a Spectrum User Model for the user ID that runs the probe.
3. Adding the user ID to the associated UserList.
For information about how to configure your SpectroSERVERs, see the following
CA Spectrum guides:
v CORBA API Programmers Guide (5010.pdf)
v Installation Guide (5136.pdf)
For more information about the Spectrum Control Panel (SCP), see Control Panel
User Guide (5029.pdf).
Configuring the probe
Global properties that affect all monitored SpectroSERVERs are specified using the
properties file spectrum_corba_v9.props. The details of each monitored
SpectroSERVER are specified using host-specific properties in the host
configuration file spectrum_corba_v9_host.xml.
Configuration options are described in the following topics:
v “Using the host configuration file”
v “Using lookup tables” on page 10
v “Configuring ObjectServer host properties” on page 12
Using the host configuration file
You must configure at least one SpectroSERVER in the host configuration file
supplied with the probe.
The host configuration file spectrum_corba_v9_host.xml is an XML file that
contains the details of each SpectroSERVER host that you want the probe to
monitor. It is installed to the following directory:
$OMNIHOME/probes/arch/
Use the HostFile property to specify the directory path to the host configuration
file.
In addition to specifying the details of each SpectroSERVER host, you can also use
the host configuration file to specify how the probe handles the alarms it retrieves
from each SpectroSERVER. The host configuration properties are XML elements, so
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA)
5
they cannot be accessed using the command line interface, but you can edit the file
in any text editor. The probe uses the XML schema file spectrum_corba_v9.xsd to
validate the host configuration file.
The following table lists the available configuration properties contained in the
host configuration file.
Table 4. Host configuration file properties
Property
Description
<SpectroServer Name=""
Domain="" IP="">
Use this property to specify the name, domain, and IP
address of the SpectroSERVER host machine.
...
Note: You must specify both the Name and the Domain value in
lowercase.
</SpectroServer>
<ModelAttributes Value="" Use this property to specify a comma-separated list of model
/>
attributes that the probe should extract in addition to the
default attributes.
You can specify alarm attributes by their identifiers (base 10
or base 16) or by their unique canonical names as specified by
the CA Spectrum type catalog.
Retrieved attributes become tokens that are available to the
rules file using their canonical names. The following example
creates the tokens $Security_String and $Notes:
<ModelAttributes Value="0x10009, 0x11564" />
You can specify a maximum of one ModelAttributes property
for each SpectroSERVER.
<AlarmAttributes Value="" Use this property to specify a comma-separated list of alarm
/>
attributes that the probe should extract in addition to the
default attributes.
You can specify alarm attributes by their identifiers (base 10
or base 16) or by their unique canonical names as specified by
the CA Spectrum type catalog.
Retrieved attributes become tokens that are available to the
rules file using their canonical names. The following example
creates the tokens $Cleared_By_User_Name and $Occurrences:
<AlarmAttributes Value= "Cleared_By_User_Name,
0x11fc5"/>
You can specify a maximum of one AlarmAttributes property
for each SpectroSERVER.
<TimeStampFile Value=""
/>
Use this property to specify the location of the file in which
the probe stores the timestamp of the last alarm it processed.
For example:
<TimeStampFile Value="/home/user/netcool/omnibus-v7.2.1solaris2/omnibus/probes/solaris2/server2.timestamp" />
You can specify a maximum of one TimeStampFile property
for each SpectroSERVER.
6
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA): Reference Guide
Table 4. Host configuration file properties (continued)
Property
Description
<FetchEventFormatFields
Value="false" />
Use this property to specify whether the probe retrieves the
event data fields attached to an alarm and makes them
available to the rules file This property takes the following
values:
true: The probe retrieves the event data fields.
false: The probe does not retrieve the event data fields.
The default is false.
Retrieved fields are made available to the rules file as tokens
in the format $Event_NAME, where NAME is the canonical name
of the attribute in the CA Spectrum type catalog. If an
attribute has no entry in the type catalog, NAME is given as its
identifier in hexadecimal format.
You can specify a maximum of one FetchEventFormatFields
property for each SpectroSERVER.
<FetchEventString
Value="false" />
Use this property to specify whether the probe creates event
messages using the originating event field data attached to an
alarm. This property takes the following values:
true: The probe creates event messages.
false: The probe does not creates event messages.
The default is false.
The event message is made available to the rules file as the
token $Event_Format_String.
This property requires that the FetchEventFormatFields
property is set to true and that the EventFormatFile property
contains a valid directory path.
You can specify a maximum of one FetchEventString
property for each SpectroSERVER.
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA)
7
Table 4. Host configuration file properties (continued)
Property
Description
<EventFormatFile Value="" Use this property to specify the local directory where the
/>
event format file that contains event data is located.
The default event format file is typically located in the
$SPECROOT/SG-Support/CsEvFormat directory (where
$SPECROOT is the directory where CA Spectrum is installed).
Custom event format files are typically located in the
$SPECROOT/custom/Events/CsEvFormat directory.
These event format files must be locally available on the host
where the probe is installed. If the probe is running on a
different host than CA Spectrum, you must copy the event
format files to the host where the probe is installed.
EventFormatFile should contain the directory path where all
these event format files are kept.
You can specify several instances of the EventFormatFile
property for each SpectroSERVER. The probe reads each
property in turn until it finds a match, so the order in which
they are listed is important if you have duplicate event
format files.
<ProbCauseLookupFile
Value="" />
Use this property to specify the location of the probable cause
lookup file.
For example:
<ProbCauseLookupFile Value="/home/user/netcool/
omnibusv7.2.1-solaris2/omnibus/probes/solaris2/
server1.lookup"/>
You can specify a maximum of one ProbCauseLookupFile
property for each SpectroSERVER.
You can generate probable cause lookup files using the
SpectrumCause.pl script supplied with the probe. For more
information, see “Using lookup tables” on page 10.
<ResyncInterval
Value="86400" />
Use this property to specify the time interval (in seconds) at
which the probe performs automatic resynchronizations.
The default is 86400 seconds (24 hours).
You can specify a maximum of one ResyncInterval property
for each SpectroSERVER.
8
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA): Reference Guide
Table 4. Host configuration file properties (continued)
Property
Description
<ResyncSQLCmd Value= ""
/>
Use this property to specify an SQL command to update the
ObjectServer during a resynchronization.
The default is UPDATE alerts.status SET Severity = 0 WHERE
LastOccurrence &lt;= %ResyncTime AND Node =
%SpectroServerName AND AlertKey NOT IN (%AlarmID_List)
You can specify a maximum of one ResyncSQLCmd property for
each SpectroSERVER.
For more information about this command, see
“Resynchronization” on page 14.
Note: The less-than sign (<) is a reserved character in XML.
When used in values for this property, it must be replaced by
the character entity “&lt;”. For example, in the SQL statement
above, LastOccurrence &lt;= %ResyncTime represents
LastOccurrence <= %ResyncTime. The XML character entity for
the greater-than sign (>) is “&gt;”.
Example 1
The following example of a host configuration file configures two SpectroSERVERs
for use with the probe. Alarms are handled according to the default settings on the
SpectroSERVER hosts.
<SpectroServer Name="server1" Domain="domain1" IP="server1.somedomain.com"
/>
<SpectroServer Name="server2" Domain="domain2" IP="server2.somedomain.com"
/>
Example 2
The following example of a host configuration file configures two SpectroSERVERs
and some of the alarm attributes.
<SpectroServer Name="server1" Domain="domain1" IP="server1.somedomain.com">
<ModelAttributes Value="0x10009,0x11564,0x23000e" />
<AlarmAttributes Value="0x11f9b,0x002305b8" />
<TimeStampFile Value="/home/user/netcool/omnibus-v7.2.1-solaris2/
omnibus/probes/solaris2/server1.timestamp" />
<FetchEventFormatFields Value="true" />
<FetchEventString Value="true" />
<EventFormatFile Value="/usr/SPECTRUM/SG-Support/CsEvFormat" />
<EventFormatFile Value="/usr/SPECTRUM/custom/CsEvFormat" />
<ProbCauseLookupFile Value="/home/user/netcool/omnibus-v7.2.1-solaris2/
omnibus/probes/solaris2/server1.lookup" />
<ResyncInterval Value="86400" />
<ResyncSQLCmd Value="UPDATE alerts.status SET Severity =0 WHERE
LastOccurrence &lt;= %ResyncTime AND
Node = %SpectroServerName AND
AlertKey NOT IN (%AlarmID_List)" />
</SpectroServer>
<SpectroServer Name="server2" Domain="domain2" IP="server2.somedomain.com">
<ModelAttributes Value="0x10009,0x11564,0x23000e" />
<TimeStampFile Value="/home/user/netcool/omnibus-v7.2.1-solaris2/
omnibus/probes/solaris2/server2.timestamp"
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA)
9
/>
<ProbCauseLookupFile Value="/home/user/netcool/omnibus-v7.2.1-solaris2/
omnibus/probes/solaris2/server2.lookup"
/>
<ResyncInterval Value="86400" />
<ResyncSQLCmd Value="UPDATE alerts.status SET Severity =
0 WHERE
LastOccurrence &lt;= %ResyncTime AND
Node = %SpectroServerName AND
AlertKey NOT IN (%AlarmID_List)" />
</SpectroServer>
Using lookup tables
You can use the SpectrumCause.pl Perl script supplied with the probe to create
lookup files. The lookup files contain tables that enable the rules file to match CA
Spectrum probable cause descriptions to the alarms generated by the
SpectroSERVER.
When you use lookup tables, the following tokens are generated in the rules file
with data extracted from the CA Spectrum probable cause files:
v $title
v $symptoms
v $prob_cause
v $recommended_actions
To enable the probe to use the CA Spectrum probable cause files, use the following
steps:
1. Run the SpectrumCause.pl script on the SpectroSERVER host, using the
following command:
perl SpectrumCause.pl spectrum_install_dir lookup_file_location
2.
3.
4.
5.
where spectrum_install_dir is the SpectroSERVER directory that contains the
CA Spectrum probable cause files and lookup_file_location is the full directory
path to the generated lookup file.
Copy the generated lookup file to the probe host, for example:
/home/user/netcool/omnibus-v7.2.1-solaris2/omnibus/probes/solaris2/
server1.lookup
If the probe is running, stop it.
Open the rules file spectrum_corba_v9.rules in a text editor.
Uncomment the following two lines in the rules file by removing the #
character:
#table spectrum_lookup_table="/etc/user/my.lookup"
#default = {"unavailable", "unavailable", "unavailable", "unavailable"}
6. In the first line, replace the lookup table name with your own site-specific
name and replace /etc/user/my.lookup with the directory path to the lookup
file.
For example:
table server1_lookup_table="/home/user/netcool/omnibus-v7.2.1-solaris2/
omnibus/probes/solaris2/server1.lookup"
default = {"unavailable", "unavailable", "unavailable", "unavailable"}
If you are using multiple SpectroSERVERs, repeat this step for each lookup
file that you are using. Each entry must have a unique lookup table name and
lookup file name, and be followed by the default line.
For example:
10
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA): Reference Guide
table server1_lookup_table="/home/user/netcool/omnibus-v7.2.1-solaris2/
omnibus/probes/solaris2/server1.lookup"
default = {"unavailable", "unavailable", "unavailable", "unavailable"}
table server2_lookup_table="/home/user/netcool/omnibus-v7.2.1-solaris2/
omnibus/probes/solaris2/server2.lookup"
default = {"unavailable", "unavailable", "unavailable", "unavailable"}
7. Uncomment the following lines:
if (exists($CauseNum))
{
#
# if (match(@Node, "your_spectrum_hostname_string"))
# {
#
[$title, $symptoms, $prob_cause, $recommended_actions] =
lookup($CauseNum, spectrum_lookup_table)
# }
}
8. Replace your_spectrum_hostname_string with the name of the SpectroSERVER
host as specified by the Name attribute of the SpectroServer property in the
host configuration file spectrum_corba_v9_host.xml.
9. Replace spectrum_lookup_table with the lookup table name that you specified in
Step 6.
10. If you are using multiple SpectroSERVERs, repeat Steps 7 to 9 for each lookup
file that you are using and use an else if statement for each additional entry.
For example:
#Lookup table needs $CauseNum
if (exists($CauseNum))
{
if (match(@Node, "spectroserver1"))
{
[$title, $symptoms, $prob_cause, $recommended_actions] =
lookup($CauseNum, server1_lookup_table)
}
else if (match(@Node, "spectroserver2"))
{
[$title, $symptoms, $prob_cause, $recommended_actions] =
lookup($CauseNum, server2_lookup_table)
}
11. Save and close the rules file.
12. In the host configuration file, add the location of the lookup file to the Value
attribute of the ProbCauseLookupFile property.
13. Restart the probe.
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA)
11
Configuring ObjectServer host properties
The probe uses a separate connection to the ObjectServer when it is performing a
resynchronization. You must configure this connection in the properties file.
To allow the probe to perform resynchronization operations with the ObjectServer,
you must specify appropriate values for the following properties in the properties
file:
v OS.Host - this property specifies the host name of the server on which the
ObjectServer is running. It must have the same value as the ObjectServer host
name specified in the $NCHOME/etc/omni.dat interfaces file.
v OS.Password - this property specifies the password that the probe uses to connect
to the ObjectServer.
v OS.Port - this property specifies the port through which the probe connects to
the ObjectServer. It must have the same value as the ObjectServer port specified
in the $NCHOME/etc/omni.dat interfaces file.
v OS.UserName - this property specifies the user name used to connect to the
ObjectServer.
v Server - this is a generic Netcool/OMNIbus property that specifies the name of
the ObjectServer host.
Data acquisition
Each probe uses a different method to acquire data. Which method the probe uses
depends on the target system from which it receives data.
The Probe for CA Spectrum V9 (CORBA) gathers events from SpectroSERVERs
using a proprietary Common Object Request Broker Architecture (CORBA)
interface.
When the probe starts, it connects to a SpectroSERVER using the details specified
by the SpectroServer property in the host configuration file ($OMNIHOME/probes/
arch/spectrum_corba_v9_host.xml). On connection, the probe listens for new
alarms from the SpectroSERVER.
The probe then initializes the CORBA status monitor to monitor the status of the
CORBA services. The probe checks the status of the CORBA services at intervals
specified by the SpectroServerPollInterval property.
Initially, the probe retrieves a list of all active alarms from the SpectroSERVER. On
subsequent connections, the probe retrieves all active alarms if the
AllAlarmsOnReStart property is enabled (set to 1). If the AllAlarmsOnReStart
property is disabled (set to 0), the probe only retrieves alarms that were generated
while the probe was disconnected.
When the AllAlarmsOnReStart property is disabled (the default setting), you must
use the TimeStampFile property in the host configuration file to specify a
timestamp file. This prevents the probe from performing a full resynchronization
every time it starts up.
If you are running two SpectroSERVERs in a failover configuration, the probe
indicates in the log file whether it is connected to the primary SpectroSERVER or
the secondary SpectroSERVER.
Data acquisition is further described in the following topics:
12
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA): Reference Guide
v
v
v
v
v
“Configuring the event details extraction buffering mechanism”
“Specifying the event extraction method that the probe uses”
“Resynchronization” on page 14
“Filtering alarms” on page 15
“Backoff strategy” on page 16
v “Command line interface” on page 16
v “Peer-to-peer failover functionality” on page 18
Configuring the event details extraction buffering mechanism
If you set the <FetchEventFormatFields> XML property to true, when the probe
receives an alarm from the SpectroSERVER, it makes a call to Archive Manager to
retrieve non-OE event fields attached to the alarm. Whatever alarms the probe is
listening to, it first writes them to a buffer, then starts processing the alarms one
event at a time. Once completed, the probe will take another alarm from the buffer
to process, and so forth.
The EventRetry and EventRetryTimeout properties specify how the probe retries
the extraction of non-OE events from the Archive Manager if the Archive Manager
service is down. Use the EventRetry property to specify how may times the probe
attempts to extract event details from Archive Manager before moving on to the
next alarm. Use the EventRetryTimeout property to specify how long the probe
waits to receive the event details before timing out and retrying the event
extraction request.
Specifying the event extraction method that the probe uses
The probe can either extract all events attached to an alarm (which requires
making an additional call to Archive Manager) or it can extract details of just the
Originating Event.
You can specify which method the probe uses to extract details of the events
attached to an alarm by setting the EventExtraction property to one of the
following values:
v AM Method: Using this method, the probe can retrieve details of one or more
events that raised the alarm. It requires the probe making an additional call to
Archive Manager (AM).
v OE Method: Using this method, the probe extracts from the alarm details of the
originating event that raised the alarm from the Originating Event (OE) byte
stream. It does not require the probe making an additional call to Archive
Manager and so avoids any delays that this may incur.
Note: You can run two SpectroSERVERs in a failover configuration, in which case
the probe can be configured to failover to a secondary SpectroSERVER if the
primary SpectroSERVER fails. When the probe is connected to the secondary
SpectroSERVER, it will always use the OE method to extract details of events
attached to an alarm regardless of setting of the EventExtraction property.
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA)
13
Resynchronization
If the probe loses the connection to a SpectroSERVER, there are three methods for
resynchronizing cleared alarms in the SpectroSERVER with the ObjectServer.
Resynchronization can be performed using the command line interface (CLI), the
SpectroSERVER resynchronization interval, and during the SpectroSERVER failover
process.
Note: Events that are deleted from the SpectroSERVER while the probe is
disconnected remain in the ObjectServer and must be manually cleared. If the
probe is using a timestamp file, some duplication of alarms may occur.
Resynchronization to the ObjectServer is performed using an SQL statement
specified by the ResyncSQLCmd property in the host configuration file. You can
configure the Value attribute of the ResyncSQLCmd property using the tokens listed
in the following table.
Table 5. ResyncSQLCmd property tokens
Token
Description
%AlarmID_List
The list of active alarm identifiers collected during
resynchronization.
%Manager
The same value as the generic Netcool/OMNIbus
Manager property.
%MinSpectrumSeverity
The same value as the MinSpectrumSeverity property.
%MaxSpectrumSeverity
The same value as the MaxSpectrumSeverity property.
%Name
The same value as the generic Netcool/OMNIbus Name
property.
%OS.Host
The same value as the OS.Host property.
%OS.Port
The same value as the OS.Port property.
%ResyncTime
The time at which the probe receives the requested
active alarm list.
%Server
The same value as the generic Netcool/OMNIbus
Server property.
%ServerBackup
The same value as the generic Netcool/OMNIbus
ServerBackup property.
%SpectroServerName
The name of the SpectroSERVER host as specified by
the Name attribute of the SpectroServer property in the
host configuration file.
%SpectroServerDomain
The domain of the SpectroSERVER host as specified by
the Domain attribute of the SpectroServer property in
the host configuration file.
%SpectroServerIP
The IP address of the SpectroSERVER host as specified
by the IP attribute of the SpectroServer property in
the host configuration file.
Resynchronization using the CLI
You can perform a manual resynchronization using the resync spectrumName
command, where spectrumName is the name of the SpectroSERVER host as
specified by the Name attribute of the SpectroServer property in the host
configuration file. For more information about using the CLI, see “Command line
interface” on page 16.
14
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA): Reference Guide
Using a resynchronization interval
You can use the ResyncInterval property in the host configuration file to set an
automatic resynchronization at specified intervals. The default is 86400 seconds (24
hours). You can specify different resynchronization intervals for each monitored
SpectroSERVER.
Using a SpectroSERVER failover configuration
If you are running two SpectroSERVERs in a failover configuration, you can use
the ResyncOnFailover property to trigger a resynchronization operation when the
probe fails over to the secondary SpectroSERVER. There is a possibility that the
secondary SpectroSERVER might not contain all available alarms while the
primary SpectroSERVER is down. To avoid data loss, you can use the
ResyncPrimaryOnly property to specify that the probe resynchronizes with the
primary SpectroSERVER only.
You can use the ResyncThreadMax property to specify the maximum number of
threads that the probe spawns to perform the resynchronization operation. Specify
a value of 0 to allow the probe to use an unlimited number of threads. The default
is 5.
Filtering alarms
You can restrict the alarms that the probe retrieves to a range of CA Spectrum
severity values. Alarm filtering is only available when the AllAlarmsOnRestart
property is disabled (set to 0).
Use the MinSpectrumSeverity property to specify the minimum severity level
threshold. The probe will not monitor alarms below this severity level. The default
is 0 (CA Spectrum severity Normal).
Use the MaxSpectrumSeverity property to specify the maximum severity level
threshold. The probe will not monitor alarms above this severity level. The default
is 6 (CA Spectrum severity Initial).
The following table lists the available CA Spectrum severity levels:
Table 6. CA Spectrum severity levels
Severity level
Description
0
Normal
1
Minor
2
Major
3
Critical
4
Maintenance
5
Suppressed
6
Initial
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA)
15
Backoff strategy
If the Retry property is set to 1, and the probe fails to establish a connection or
loses an existing connection to the device, the probe reverts to a backoff strategy.
The probe's backoff strategy is to attempt to reconnect to the SpectroSERVER at
intervals specified by the RetryInterval property.
If the Retry property is set to 0, and the probe is monitoring only one
SpectroSERVER, the probe will shut down when it loses the connection. If the
probe is monitoring more than one SpectroSERVER, it will not shut down.
Command line interface
The probe is supplied with a Command Line Interface (CLI). This interface enables
you to execute commands to acknowledge alarms and update fields in the
SpectroSERVER.
To use the CLI, you must use the CommandPort property to specify a port through
which commands will be sent. The default port is 7777. When you want to issue
commands, use Telnet to connect through this port. You can use the
CommandPortLimit property to limit the number of Telnet connections that the
probe can make at one time.
You can use the CLI to update the SpectroSERVER fields listed in the following
table.
Table 7. SpectroSERVER fields
SpectroSERVER field
Description
Acknowledged
This field indicates whether the alarm has been
acknowledged by a CA Spectrum operator.
AlarmStatus
This field indicates the status of the corrective action.
EventIDList
This field lists all the CA Spectrum events that resulted
in the alarm.
Troubleshooter
This field shows the name of the troubleshooter.
TroubleshooterModel
This field identifies the type of the troubleshooter.
TroubleTicketID
This field contains the trouble ticket number for an
alarm.
You can use Netcool/OMNIbus automations to reflect SpectroSERVER field
updates in the corresponding ObjectServer fields. For more information about
using automations, see the IBM Tivoli Netcool/OMNIbus Administration Guide
(SC14-7605).
CLI commands
The following table describes the commands that you can use with the CLI. The
spectrumName parameter used by the CLI commands requires the name of the
SpectroSERVER host as specified by the Name attribute of the SpectroServer
property in the host configuration file. The alarmID parameter must be given in
hexadecimal format.
16
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA): Reference Guide
Table 8. CLI commands
Command
Description
acknowledgeAlarm alarmID spectrumName Use this command to acknowledge an alarm by
specifying the alarm identifier and the
SpectroSERVER host name.
unacknowledgeAlarm alarmID
spectrumName
Use this command to unacknowledge an alarm
by specifying the alarm identifier and the
SpectroSERVER host name.
clearAlarm alarmID spectrumName
Use this command to clear an alarm by
specifying the alarm identifier and the
SpectroSERVER host name.
resync spectrumName
Use this command to resynchronize a
SpectroSERVER.
updateStatus alarmID status
spectrumName
Use this command to update the status of an
alarm by specifying the alarm identifier, the new
status, and the SpectroSERVER host name.
updateTroubleShooterName alarmID name Use this command to update the troubleshooter
spectrumName
name of an alarm by specifying the alarm
identifier, the new troubleshooter name, and the
SpectroSERVER host name.
updateTroubleTicket alarmID ticketID
spectrumName
Use this command to update the trouble ticket
number for an alarm by specifying the alarm
identifier, the new ticket identifier, and the
SpectroSERVER host name.
updateTroubleShooterModel alarmID
model spectrumName
Use this command to update the troubleshooter
type of an alarm by specifying the alarm
identifier, the new troubleshooter type, and the
SpectroSERVER host name.
updateEventList alarmID eventIDList
spectrumName
Use this command to update the event list of an
alarm by specifying the alarm identifier, the
event list identifier, and the SpectroSERVER host
name.
Note: This command feature is currently
unavailable. For details, see “Known issues” on
page 35.
CLI scripts
Because the CLI uses Telnet connections, you can connect to the probe from
anywhere by creating a desktop tool to open a Telnet connection, send a command,
and then close the connection. This means that simple scripts can be set up to
allow users to acknowledge selected events from the IBM Tivoli Netcool/OMNIbus
event list.
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA)
17
Peer-to-peer failover functionality
The probe supports failover configurations where two probes run simultaneously.
One probe acts as the master probe, sending events to the ObjectServer; the other
acts as the slave probe on standby. If the master probe fails, the slave probe
activates.
While the slave probe receives heartbeats from the master probe, it does not
forward events to the ObjectServer. If the master probe shuts down, the slave
probe stops receiving heartbeats from the master and any events it receives
thereafter are forwarded to the ObjectServer on behalf of the master probe. When
the master probe is running again, the slave probe continues to receive events, but
no longer sends them to the ObjectServer.
Example property file settings for peer-to-peer failover
You set the peer-to-peer failover mode in the properties files of the master and
slave probes. The settings differ for a master probe and slave probe.
Note: In the examples, make sure to use the full path for the property value. In
other words replace $OMNIHOME with the full path. For example:
/opt/IBM/tivoli/netcool.
The following example shows the peer-to-peer settings from the properties file of a
master probe:
Server
RulesFile
MessageLog
PeerHost
PeerPort
Mode
PidFile
:
:
:
:
:
:
:
"NCOMS"
"master_rules_file"
"master_log_file"
"slave_hostname"
5555 # [communication port between master and slave probe]
"master"
"master_pid_file"
The following example shows the peer-to-peer settings from the properties file of
the corresponding slave probe:
Server
RulesFile
MessageLog
PeerHost
PeerPort
Mode
PidFile
18
:
:
:
:
:
:
:
"NCOMS"
"slave_rules_file"
"slave_log_file"
"master_hostname"
5555 # [communication port between master and slave probe]
"slave"
"slave_pid_file"
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA): Reference Guide
Properties and command line options
You use properties to specify how the probe interacts with the device. You can
override the default values by using the properties file or the command line
options.
The following table describes the properties and command line options specific to
this probe. For more information about generic Netcool/OMNIbus properties and
command line options, see the IBM Tivoli Netcool/OMNIbus Probe and Gateway
Guide.
Table 9. Properties and command line options
Property name
Command line option
Description
AllAlarmsOnReStart
integer
-allalarmsonrestart
integer
Use this property to specify
whether the probe retrieves all
active alarms when it connects or
only those that have been created
since the last connection. This
property takes the following
values:
0: The probe only retrieves alarms
generated since the last
connection.
1: The probe retrieves all active
alarms; no alarm filter is applied
by the probe.
The default is 0.
CommandPort integer
-commandport integer
Use this property to specify the
port through which you will send
commands using the CLI.
The default is 7777.
Note: The CA Spectrum CLI also
uses port number 7777. You must
change one of these port numbers
to ensure that each CLI is using a
unique port.
CommandPortLimit integer
-commandportlimit integer Use this property to specify the
maximum number of Telnet
connections that the probe can
make using the command port.
The default is 10.
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA)
19
Table 9. Properties and command line options (continued)
Property name
Command line option
Description
EventExtraction string
-eventextraction string
Use this property to specify which
method the probe uses to extract
details of the events attached to an
alarm. This property takes the
following values:
AM: The probe makes an additional
call to Archive Manager (AM) to
retrieve details of one or more
events that raised the alarm.
OE: The probe extracts from the
alarm details of the originating
event that raised the alarm from
the OriginatingEvent (OE) byte
stream, and so does not make an
additional call to Archive
Manager.
The default is AM.
Note: When the probe is
connected to the secondary
SpectroSERVER, it will always use
the OE method to extract details
of events attached to an alarm
regardless of setting of the
EventExtraction property.
EventRetry integer
-eventretry integer
Use this property to specify how
many times the probe attempts to
extract from the Archive Manager
the event details associated with
an alarm event before moving on
to the next alarm.
The maximum that you can set
this property to is 5. If you set this
property to 0, the probe will not
retry the event details extraction.
The default is 3.
Note: If you set this property to a
value other than between 0 and 5,
the probe will use the default
value of 3.
20
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA): Reference Guide
Table 9. Properties and command line options (continued)
Property name
Command line option
Description
EventRetryTimeout integer
-eventretrytimeout
integer
Use this property to specify the
time (in seconds) that probe waits
to receive from the Archive
Manager the event details
associated with an alarm. If this
time is exceeded, the probe retries
the event extraction request. The
number of times that the probe
retries the event extraction is
specified by the EventRetry
property.
The maximum that you can set
this property to is 5 seconds. If
you set this property to 0, the
probe will not timeout while
waiting for the event details.
The default is 3.
Note: If you set this property to a
value other than between 0 and 5,
the probe will use the default
value of 3.
FlushBufferInterval
integer
-flushbufferinterval
integer
Use this property to specify how
often (in seconds) the probe
flushes all alerts in the buffer to
the ObjectServer.
The default is 0 (the probe does
not flush alerts to the
ObjectServer).
HostFile string
-hostfile string
Use this property to specify the
location of the host configuration
file spectrum_corba_v9_host.xml.
The default is "".
MaxSpectrumSeverity
integer
-maxspectrumseverity
integer
Use this property to specify the
maximum severity level above
which the probe will not retrieve
alarms.
The default is 6 (CA Spectrum
severity Initial).
MinSpectrumSeverity
integer
-minspectrumseverity
integer
Use this property to specify the
minimum severity level below
which the probe will not retrieve
alarms.
The default is 0 (CA Spectrum
severity Normal).
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA)
21
Table 9. Properties and command line options (continued)
Property name
Command line option
Description
ORBLocalHost string
-orblocalhost string
Use this property to specify the
local host name or IP address used
by the server-side ORB to place
the server's host name or IP
address into the IOR of a remote
object.
The default is "".
ORBLocalPort string
-orblocalport string
Use this property to specify the
local port to which the Object
Request Broker (ORB) listens for
connections from the probe.
The default is 0 (the ORB selects
an available port at random).
OS.Host string
-oshost string
Use this property to specify the
host name of the ObjectServer to
which the probe connects during
resynchronization operations.
The default is localhost.
OS.Password string
-ospassword string
Use this property to specify the
password of the ObjectServer to
which the probe connects during
resynchronization operations.
The default is "".
Use the nco_g_crypt utility
supplied with Netcool/OMNIbus
to encrypt the password. . For
information about using this
utility, see the IBM Tivoli
Netcool/OMNIbus Administration
Guide (SC14-7605).
OS.Port integer
-osport integer
Use this property to specify the
port number of the ObjectServer
to which the probe connects
during resynchronization
operations.
The default is 4100.
OS.UserName string
-osusername string
Use this property to specify the
user name used to connect to the
ObjectServer during
resynchronization operations.
The default is root.
22
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA): Reference Guide
Table 9. Properties and command line options (continued)
Property name
Command line option
Description
ResyncOnFailover integer
-resynconfailover integer
Use this property to specify
whether the probe performs a
resynchronization during the
SpectroSERVER failover process.
This property takes the following
values:
1: The probe performs a
resynchronization.
0: The probe does not perform a
resynchronization.
The default is 0.
ResyncPrimaryOnly integer
-resyncprimaryonly
integer
Use this property to make the
probe resynchronize with the
primary SpectroSERVER only
during the SpectroSERVER
failover process. This property
takes the following values:
1: The probe performs a
resynchronization with the
primary SpectroSERVER only.
0: The probe resynchronizes with
either SpectroSERVER.
The default is 1.
ResyncThreadMax integer
-resyncthreadmax integer
Use this property to specify the
maximum number of threads that
the probe spawns to perform a
resynchronization.
Specify a value of 0 to allow the
probe to use an unlimited number
of threads.
The default is 5.
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA)
23
Table 9. Properties and command line options (continued)
Property name
Command line option
Description
Retry integer
-retry integer
Use this property to specify
whether the probe attempts to
reconnect to a SpectroSERVER
after losing the connection.
This property takes the following
values:
1: The probe attempts to reconnect
with the SpectroSERVER at
intervals specified by the
RetryInterval property.
0: The probe does not attempt to
reconnect.
There are two scenarios of retry:
1. If Retry is set to 1 and the
probe is started when
Spectrum is down, the probe
will try to connect to
SpectroSERVER using the
RetryInterval property value.
When Spectrum is up and back
to service, the probe will
connect to Spectrum after the
next RetryInterval has
elapsed.
2. If Retry is set to 1, and
Spectrum goes down after the
probe has already started, the
probe will wait displaying the
message WAIT_AUTO_RECONNECT
every second until Spectrum is
back up to service. When
Spectrum is back up to service,
the probe will immediately be
able to receive events from
Spectrum.
The default is 1.
RetryInterval integer
-retryinterval integer
Use this property to define the
length of retry interval (in
seconds) for reconnecting to the
SpectroSERVER after being
disconnected.
The default is 30.
SpectroServer
PollInterval integer
-spectroserver
pollinterval integer
Use this property to specify the
interval (in seconds) at which the
probe polls the CORBA services to
check their availability.
The default is 20 seconds.
24
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA): Reference Guide
Elements
The probe breaks event data down into tokens and parses them into elements.
Elements are used to assign values to ObjectServer fields; the field values contain
the event details in a form that the ObjectServer understands.
The following table describes the elements that the probe generates. Not all the
elements described are generated for each event. The elements that the probe
generates depend on the event type.
Table 10. Elements
Element name
Element description
$Acknowledged
This element indicates if the alarm has been
acknowledged by a CA Spectrum operator.
$AlarmID
This element contains the identifier of the alarm.
The probe sends this element to the rules file as a
zero-padded 8-character hexadecimal string.
Note: The alarm ID changes when an event fails
over to a secondary SpectroSERVER.
$AlarmStatus
This element displays the status of the alarm.
$AlarmSource
This element indicates the source of the alarm.
The following values are currently supported:
v 0: specifies that the alarm is current.
v 1: specifies that the alarm is residual from a
previous run of the SpectroSERVER.
$ClearMe
This element indicates whether the event is a
resolution event.
A value of true sets the ObjectServer field @Type
to 2 in the rules file. This indicates that it is a
resolution event.
$CauseNum
This element shows the probable cause number
of the event. The probe sends this element to the
rules file as a zero-padded 8-character
hexadecimal string.
$ClearedBy
This element contains the user name associated
with the user who cleared the alarm through the
CA Spectrum API. This element is not present
when an alarm is created but it is added prior to
removal.
$CreationDate
This element contains the date when the alarm
was generated.
$DomainID
This element contains the domain ID of the
SpectroSERVER.
$EventIDList
This element contains the list of SpectroSERVER
event identifiers that triggered the alarm.
$IPAddress
This element contains the IP address of the
reporting node.
$ModelHandle
This element contains a model handle. A model
handle is a 32-bit number in which the
high-order 12 bits make up the landscape and the
remaining 20 bits make up the model identifier.
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA)
25
Table 10. Elements (continued)
26
Element name
Element description
$ModelID
This element shows the identifier of the model.
$ModelName
This element contains a description of the model.
$ModelType
This element shows the type of the device that
raised the alarm.
$Occurrences
This element shows the number of times that the
event has occurred.
$PrimaryAlarm
This element indicates the priority of the alarm in
the SpectroSERVER. A value of true identifies the
alarm as a primary alarm. Primary alarms have
the highest priority.
$Pre-existing
This element indicates whether the received event
is already present in the SpectroServer.
$Primary
This element indicates whether the probe is
connected to a primary SpectroSERVER or to a
secondary SpectroSERVER. A value of false
indicates that the probe is connected to a
secondary server.
$Priority
This element indicates the priority in the
SpectroSERVER.
$Severity
This element indicates the severity of the alarm in
the SpectroSERVER.
$TroubleShooter
This element displays the name of the specified
troubleshooter. This element maps to the
TroubleShooter SpectroSERVER field, which can
be updated using the updateTroubleShooterName
CLI command.
$TroubleShooterModel
This element displays the model type of the
specified troubleshooter. This element maps to
the TroubleShooterModel SpectroSERVER field,
which can be updated using the
updateTroubleShooterModel CLI command.
$TroubleTicketID
This element displays the identifier of the trouble
ticket associated with an alarm. This element
maps to the TroubleTicketID SpectroSERVER
field, which can be updated using the
updateTroubleTicket CLI command.
$UserClearable
This element indicates whether or not a client can
clear the alarm. This element is provided so that
client applications can indicate to users that the
alarm is not clearable. A client cannot control
whether an alarm is clearable.
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA): Reference Guide
Error messages
Error messages provide information about problems that occur while running the
probe. You can use the information that they contain to resolve such problems.
The following table describes the error messages specific to this probe. For
information about generic Netcool/OMNIbus error messages, see the IBM Tivoli
Netcool/OMNIbus Probe and Gateway Guide.
Table 11. Error messages
Error
Description
Action
Exception when attempting
to run status monitor
Probe shutting down
because CORBA Status
monitor not polling
successfully.
The probe could not initialize
the connection with the
CORBA interface and is
shutting down.
Check the SpectroSERVER
configuration.
Exception thrown when
attempting to start CORBA
service
Probe shutting down as
unable to access CORBA
service, please ensure
that server configuration
is complete and try again
Probe shutting down
because Probe unable to
access CORBA service
Exception when attempting
to establish a filter for
alarms
Probe shutting down as
unable to receive
alarms,please ensure that
the timestamp file
pointed to does not
contain corrupted data
Probe shutting down
because unable to
establish Alarm Watch
filter
Verify that the values set for
the Domain, Name, and IP
attributes of the
SpectroServer property are
correct in the host
configuration file.
Check the firewall settings in
your environment.
Check that the appropriate
additions were made to the
SpectroSERVER server list.
Verify that a Spectrum User
Model exists for the user ID
that runs the probe.
Exception when attempting
to establish an Alarm
Watch
Probe shutting down as
unable to receive
alarms,please ensure that
server configuration is
complete and try again
Probe shutting down
because unable to
establish Alarm Watch
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA)
27
Table 11. Error messages (continued)
Error
Description
Error occurred attempting The probe connection with
the CORBA interface has
to pass on details of
failed.
cleared alarms to the
Object Server.
Probe shutting down
because Problem
processing cleared
alarms.
Error occurred attempting
to pass updates to the
Object Server
Probe shutting down
because Problem
processing updated
alarms.
Error occurred attempting
to pass details of new
alarms to the Object
Server
Probe shutting down
because Problem
processing new alarms
Error in connecting to
CORBA interface
Error external to CORBA
framework
Probe shutting down
because External error in
connection to CORBA
interface
Exception thrown when
querying whether we are
accessing Primary
SpectroSERVER
Probe shutting down
because Problem querying
SpectroSERVER.
Connection to CORBA
interface has been lost.
Error internal to CORBA
interface
Probe shutting down
because Internal error in
CORBA interface,
connection lost
Error shutting down
connection to CORBA
interface
28
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA): Reference Guide
Action
Restart the probe.
Check whether the
SpectroSERVER
configurations have changed.
Verify that the
SpectroSERVER is running.
Table 11. Error messages (continued)
Error
Description
The probe failed to use the
Failed to pick up probe
timestamp file. These errors
property TimeStampFile
Not using timestamp file, are not fatal error messages.
proceeding to collect all
active alarms.
Action
Check the specific message
and verify that the timestamp
file is accessible.
Timestamp of alarms not
stored for re-sync
Unable to create
timestamp file
Unable to find time stamp
file
Unable to write to
timestamp file
Error closing timestamp
file
Error opening timestamp
file for reading
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA)
29
Table 11. Error messages (continued)
Error
Description
Action
Alarm + alarmID + Error
clearing alarm
Error clearing alarm
The probe failed to update an Verify that the alarm you are
event.
trying to update exists in the
SpectroSERVER.
Note: If the alarm is not
found, the SpectroSERVER
shows an error message.
Alarm + alarmID + Error
in Event ID List update
Error updating the event
ID List
Alarm + alarmID + Error
in Trouble Shooter Model
update
Error updating the
trouble shooter model
Alarm + alarmID + Error
in Trouble Ticket update
Error updating the
trouble ticket
Alarm + alarmID + Error
in Troubleshooter Name
update
Error updating the
trouble shooter name
Alarm + alarmID + Error
in status update
Error updating the alarm
status
Alarm + alarmID +Error in
unacknowledge
Error un-acknowledging
alarm
Alarm + alarmID + Error
in acknowledge
Error acknowledging alarm
30
Invalid spectrum alarm
severity:
MaxSpectrumSeverity is
greater than 6. Valid
spectrum alarm severity
value is from 0 to 6.
The value set for the
Set the MaxSpectrumSeverity
MaxSpectrumSeverity property property to a value between 0
is greater than the maximum to 6.
valid value. The valid values
for this property are between
0 to 6.
Invalid spectrum alarm
severity: the values of
MinSpectrumSeverity and
MaxSpectrumSeverity are
not in order. Valid
spectrum alarm severity
value is from 0 to 6.
The value set for the
MinSpectrumSeverity property
is greater than that set for the
MaxSpectrumSeverity property
.
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA): Reference Guide
Set the MinSpectrumSeverity
property to a value between 0
to 6, and less than that set for
the MaxSpectrumSeverity
property.
Table 11. Error messages (continued)
Error
Description
Invalid spectrum alarm
severity:
MinSpectrumSeverity is
less than 0. Valid
spectrum alarm severity
value is from 0 to 6.
Set the MinSpectrumSeverity
The value set for the
MinSpectrumSeverity property property to a value between 0
is less than 0, which is not
to 6.
valid.
[Command Port] Failed to
open listening socket:
java.lang.Illegal
ArgumentException: Port
value out of range:
<invalid value>
The value set for the
CommandPort property is not
valid.
[Command Port] Failed to
open listening socket:
java.net.BindException:
Address already in use
Set the CommandPort property
The probe failed to listen to
command port socket because to a value that is not already
in use.
the CommandPort property is
set to a value that is already
in use.
No SpectroServer is specified
Host parser exception :
in host configuration file.
file:///<host
configuration file path>
LineNumber=62
ColumnNumber=21
Msg=cvc-complextype.2.4.b: The content
of element
'ProbeHeadProperty' is
not complete. One of
'{SpectroServer}' is
expected. Error in
parsing host
configuration file. Probe
will shutdown
Host parser exception :
file:///<host
configuration file path>
LineNumber=51
ColumnNumber=37
Msg=cvc-complextype.2.4.a: Invalid
content was found
starting with element
'<property name in host
config file>'. One of
'{AlarmAttributes,
TimeStampFile,
FetchEventFormatFields,
FetchEventString,
EventFormatFile,
ProbCauseLookupFile,
ResyncInterval,
ResyncSQLCmd}' is
expected. Error in
parsing host
configuration file. Probe
will shutdown
Duplicate entries were found
in the host configuration file
for at least one of the
following properties:
AlarmAttributes,
TimeStampFile,
FetchEventFormatFields,
FetchEventString,
EventFormatFile,
ProbCauseLookupFile,
ResyncInterval,
ResyncSQLCmd.
Action
Set the CommandPort property
to a positive integer.
Specify at least one
SpectroServer in the host
configuration file.
Specify only one entry in the
host configuration file for any
of the properties listed.
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA)
31
Table 11. Error messages (continued)
Error
Description
Action
Retry value must be 0 or
1.
Retry is set to invalid value.
Change the value of Retry in
the properties file.
The Archive Manager service
is down and the probe could
not retrieve events for the
alarm from the Archive
Manager.
Restart the Archive Manager
service.
The probe could not detect
the host configuration file
because the path is invalid.
Set the a valid path to the
host configuration file for the
Host property.
Error in Retry property
value. Probe will
shutdown
[servername] failed to
retrieve related events:
[servername] no events
could be fetched
successfully for this
alarm
Unknown host
configuration file,
<invalid host path>
Error in parsing host
configuration file. Probe
will shutdown
ProbeWatch messages
During normal operations, the probe generates ProbeWatch messages and sends
them to the ObjectServer. These messages tell the ObjectServer how the probe is
running.
The following table describes the ProbeWatch messages that the probe generates.
For information about generic Netcool/OMNIbus ProbeWatch messages, see the
IBM Tivoli Netcool/OMNIbus Probe and Gateway Guide.
Table 12. ProbeWatch messages
32
ProbeWatch message
Description
Triggers/causes
Error in Retry property
value. Probe will
shutdown
The Retry property is set to
invalid value and so the
probe is shutting down.
An invalid value was set for
the Retry property.
Probe has lost connection The probe has lost the
to CORBA interface, error connection to the CORBA
external to CORBA
interface.
interface
The connection between the
SpectroSERVER and the CA
Spectrum EMS is down.
Probe has lost connection The probe has lost the
to CORBA interface. Error connection to the CORBA
internal to CORBA
interface.
interface
The connection between the
probe and the server is down
due to incorrect probe settings
or an inactive
SpectroSERVER.
New successful connection The probe connected to the
to the CORBA interface,
primary SpectroSERVER.
connected to the Primary
SpectroSERVER
The connection to the primary
SpectroSERVER was
successful.
New successful connection The probe connected to the
to the CORBA interface,
secondary SpectroSERVER.
connected to the
Secondary SpectroSERVER
The primary SpectroSERVER
has failed, and the probe has
connected to the secondary
SpectroSERVER.
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA): Reference Guide
Table 12. ProbeWatch messages (continued)
ProbeWatch message
Description
Triggers/causes
Start resync for
spectroServerName
The probe started the
resynchronization process
with the Spectrum server
indicated.
Either a resynchronization
was requested by a CLI
command, or one was
initiated automatically
following the elapsing of a
resynchronization interval, or
the failover of the Spectrum
server.
Complete resync for
spectroServerName
The probe's resynchronization The resynchronization with
with the Spectrum server
the Spectrum server indicated
indicated has completed.
completed successfully.
Probe successfully
connected to <target
host>
The probe started and is
running successfully.
The probe process was started
by the operator.
Running ...
The probe started and is
running successfully.
The probe process was started
by the operator.
Probe is shutting down
Going Down ...
The probe is shutting down.
The system has been
requested to shut down the
probe because the probe
process was terminated
manually by the operator.
<target host> head is
shutting down, remove
from active host list
CA Spectrum EMS is shutting
down after the probe
connected to SpectroSERVER.
This ProbeWatch will be
shown when the retry value
for the probe is set to 0.
CA Spectrum EMS that is
connecting to the probe is
shutting down. This is either
because the Spectrum service
has been stopped manually
by operator or has aborted.
Error in spectrum alarm
severity values. Probe
will shutdown.
Invalid values have been set
for either the
MaxSpectrumSeverity property
or the MinSpectrumSeverity
property .
Either the value set for the
MinSpectrumSeverity property
is higher than that set for the
MaxSpectrumSeverity, or the
value set for either
MinSpectrumSeverity or
MaxSpectrumSeverity is not
between 0 and 6.
Received connection from
127.0.0.1
The probe connected to
command port session and is
ready to receive CLI
commands.
The operator managed to
successfully telnet to the
command port.
Failed to open listening The probe failed to listen to
socket: java.lang.Illegal the command port socket.
ArgumentException: Port
value out of range:
<invalid value>
Failed to open listening
socket:
java.net.BindException:
Address already in use
The probe failed to listen to
the command port socket.
The CommandPort property is
set to an invalid value. Either
the value is not an integer, or
it is set to a negative value.
The CommandPort property is
set to a value that is not
already in use.
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA)
33
Table 12. ProbeWatch messages (continued)
ProbeWatch message
Description
Error in parsing host
The probe failed to parse the
configuration file. Probe host configuration file.
will shutdown
Triggers/causes
Either there are missing
values in the host
configuration file (for example
a missing SpectroServer host),
duplicate entries were found
in the host configuration file
for at least one of the
following properties:
AlarmAttributes,
TimeStampFile,
FetchEventFormatFields,
FetchEventString,
EventFormatFile,
ProbCauseLookupFile,
ResyncInterval,
ResyncSQLCmd, or the path to
the host configuration file
specified for the Host
property is an invalid path.
Running the probe
The probe is run from the command line.
To start the probe, use the following command:
$OMNIHOME/probes/nco_p_spectrum_corba_v9
Troubleshooting
Various issues arise as users work with the probe. Troubleshooting information is
provided to help you diagnose and resolve such issues.
Fails to Connect
The Probe for CA Spectrum V9 (CORBA) fails to connect to the SpectroSERVER
when configured with a host file. You may receive the following message when
configuring a host file:
07/01/10 10:36:39: Debug: [1 server1] Connecting to SpectroServer
07/01/10 10:36:39: Debug: CommandPort-> 7778
07/01/10 10:36:39: Debug: CommandPortLimit-> 10
07/01/10 10:36:39: Debug: [Command Port] Waiting for connections
07/01/10 10:36:42: Debug: [1 server1] Exception =
org.omg.CORBA.OBJECT_NOT_EXIST:
vmcid: 0x0 minor code: 0 completed: No
07/01/10 10:36:42: Error: Exception thrown when attempting to start CORBA service:
07/01/10 10:36:42: Error: Unable to access CORBA service, head is shutting down
This indicates that there is a connection issue between the probe and the
SpectroSERVER. A possible reason is that the probe cannot find the location of the
SpectroSERVER specified in the spectrum_corba_v9_host.xml host file.
To resolve this problem, set the domain property in host file to the SpectroServer
host FQDN which is reachable from probe host.
34
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA): Reference Guide
For the information about the required format of the connection information in the
host file, see “Using the host configuration file” on page 5.
Known issues
At the time of release, several known issues were reported that you should be
aware of when running the probe.
Using timestamp files
The TimeStampFile property in the host configuration file enables you to specify a
file in which the probe can log the timestamp of the last alarm it processed. When
the AllAlarmsOnRestart property is disabled, and a timestamp file is specified, the
alarms received by the probe are filtered according to this timestamp.
The timestamp filter works in the following way. Assume that the probe shuts
down and logs timestamp T to the timestamp file. Then the probe starts up again
and sets up two timestamp filters, TS1 and TS2. The value of the TS1 filter is equal
to the value of the last logged timestamp minus 48 hours (TS1 = T - 48 hours). The
value of the TS2 filter is equal to T (TS2 = T).
The purpose of the TS1 filter is to enable alarms up to 48 hours old, that were
cleared or updated while the SpectroSERVER was connected to the probe, to be
forwarded to the probe. So all alarms created after TS1 are forwarded to the probe.
However, the probe only accepts as active those alarms that were created after TS2.
The TS2 filter prevents alarms that have already been processed by the probe from
being resynchronized.
The issue arises because, although the probe will accept updates to alarms that were
created after TS1, it cannot logically accept updates made in the SpectroSERVER to
older alarms that it has already filtered out. To avoid this issue, do not use the
TimeStampFile property in the host configuration file.
Error using the UpdateEventList command
The UpdateEventList alarmID eventIDList spectrumName CLI command enables
you to update the event list of an alarm by specifying the alarm identifier, the
event list identifier and the SpectroSERVER host name.
This command feature is currently unavailable because when issued to the
SpectroSERVER, the command produces an exception with an error of
TYPE_RESTRICTION at the Spectrum API level.
SpectroSERVER automatically disconnecting the probe
When the total time taken by archive manager to retrieve events exceeds the time
set in the MAX_EVENT_ID_REQUEST_TIMEOUT field on SpectroSERVER, SpectroSERVER
will disconnect the probe, but will not inform the probe that it has been
disconnected. The probe will fail to retrieve any further events from
SpectroSERVER until you manually restart the probe.
Using the probe with CA Spectrum version 9.3
The probe will not work with the libraries copied from Spectrum version 9.3.
However, the probe will function correctly with Spectrum version 9.3 if the probe
is running on libraries from an older version, for example Spectrum version 9.2.
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA)
35
36
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA): Reference Guide
Appendix. Notices and Trademarks
This appendix contains the following sections:
v Notices
v Trademarks
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.
© Copyright IBM Corp. 2010, 2015
37
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 want to have information about it for the purpose
of enabling: (i) the exchange of information between independently created
programs and other programs (including this one) and (ii) the mutual use of the
information which has been exchanged, should contact:
IBM Corporation
Software Interoperability Coordinator, Department 49XA
3605 Highway 52 N
Rochester, MN 55901
U.S.A.
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 information 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.
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.
38
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA): Reference Guide
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.
Each copy or any portion of these sample programs or any derivative work, must
include a copyright notice as follows:
© (your company name) (year). Portions of this code are derived from IBM Corp.
Sample Programs. © Copyright IBM Corp. _enter the year or years_. All rights
reserved.
If you are viewing this information softcopy, the photographs and color
illustrations may not appear.
Trademarks
IBM, the IBM logo, ibm.com, AIX, Tivoli, zSeries, and Netcool are trademarks of
International Business Machines Corporation in the United States, other countries,
or both.
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.
Intel, Intel Inside (logos), MMX, and Pentium are trademarks of Intel Corporation
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.
Java™ and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in
the United States, other countries, or both.
Linux is a trademark of Linus Torvalds in the United States, other countries, or
both.
UNIX is a registered trademark of The Open Group in the United States and other
countries.
Appendix. Notices and Trademarks
39
40
IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 (CORBA): Reference Guide
Printed in USA
SC27-2722-08