IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 … … · Installing Spectrum utilities .....3 ... Where Tivoli Netcool/OMNIbus files are identified as located within an arch

IBM® Tivoli® Netcool/OMNIbus Probe for CA Spectrum V9(CORBA)Version 6.0

Reference GuideJuly 31, 2015

SC27-2722-08

��

IBM® Tivoli® Netcool/OMNIbus Probe for CA Spectrum V9(CORBA)Version 6.0

Reference GuideJuly 31, 2015

SC27-2722-08

��

NoticeBefore 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 Contractwith IBM Corp.

Contents

About this guide . . . . . . . . . . . vDocument control page . . . . . . . . . . . vConventions used in this guide . . . . . . . . vi

IBM Tivoli Netcool/OMNIbus Probe forCA Spectrum V9 (CORBA) . . . . . . . 1Summary . . . . . . . . . . . . . . . 1Installing probes . . . . . . . . . . . . . 2Setting environment variables . . . . . . . . 3Installing Spectrum utilities . . . . . . . . . 3Firewall considerations . . . . . . . . . . . 4Configuring SpectroSERVERs . . . . . . . . . 5Configuring the probe . . . . . . . . . . . 5

Using the host configuration file . . . . . . . 5Using lookup tables . . . . . . . . . . 10Configuring ObjectServer host properties . . . 12

Data acquisition . . . . . . . . . . . . . 12Configuring the event details extraction bufferingmechanism . . . . . . . . . . . . . 13

Specifying the event extraction method that theprobe uses. . . . . . . . . . . . . . 13Resynchronization . . . . . . . . . . . 14Filtering alarms . . . . . . . . . . . . 15Backoff strategy . . . . . . . . . . . . 16Command line interface . . . . . . . . . 16Peer-to-peer failover functionality . . . . . . 18

Properties and command line options . . . . . 19Elements . . . . . . . . . . . . . . . 25Error messages . . . . . . . . . . . . . 27ProbeWatch messages . . . . . . . . . . . 32Running the probe . . . . . . . . . . . . 34Troubleshooting . . . . . . . . . . . . . 34Known issues. . . . . . . . . . . . . . 35

Appendix. Notices and Trademarks . . 37Notices . . . . . . . . . . . . . . . . 37Trademarks . . . . . . . . . . . . . . 39

© Copyright IBM Corp. 2010, 2015 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 pageUse 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 recentversion, 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

Documentversion

Publicationdate

Comments

SC27-2722-00 January 15,2010

First IBM publication.

SC27-2722-01 December 31,2010

Installation section replaced by “Installing probes” onpage 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 addedin “Installing Spectrum utilities” on page 3.

Information about configuring ObjectServer hostproperties added in “Configuring ObjectServer hostproperties” on page 12.

Resynchronization information updated in“Resynchronization” on page 14.

Information about filtering alarms updated in “Filteringalarms” 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” onpage 35.

© Copyright IBM Corp. 2010, 2015 v



Table 1. Document modification history (continued)

Documentversion

Publicationdate

Comments

SC27-2722-03 May 11, 2012 Description of the EventFormatFile host configurationproperty updated in “Using the host configuration file”on page 5.

SC27-2722-04 November 8,2013

“Configuring the event details extraction bufferingmechanism” on page 13 added

“Specifying the event extraction method that the probeuses” 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 Spectrumversion 9.3 added to “Known issues” on page 35.

SC27-2722-08 July 31, 2015 Information about resolving the domain nameconfiguration was added to “Troubleshooting” on page34.

Conventions used in this guideAll probe guides use standard conventions for operating system-dependentenvironment variables and directory paths.

Operating system-dependent variables and paths

All probe guides use standard conventions for specifying environment variablesand describing directory paths, depending on what operating systems the probe issupported on.

For probes supported on UNIX and Linux operating systems, probe guides use thestandard UNIX conventions such as $variable for environment variables andforward slashes (/) in directory paths. For example:

$OMNIHOME/probes

For probes supported only on Windows operating systems, probe guides use thestandard Windows conventions such as %variable% for environment variables andbackward slashes (\) in directory paths. For example:

%OMNIHOME%\probes

For probes supported on UNIX, Linux, and Windows operating systems, probeguides use the standard UNIX conventions for specifying environment variablesand 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 Windowsconventions. If you are using the bash shell on a Windows system, you can use theUNIX conventions.

Note: The names of environment variables are not always the same in Windowsand UNIX environments. For example, %TEMP% in Windows environments isequivalent to $TMPDIR in UNIX and Linux environments. Where such variables aredescribed 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 archdirectory under NCHOME or OMNIHOME, arch is a variable that represents youroperating 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 thetable.

Table 2. Directory names for the arch variable

Operating system Directory name represented by arch

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 OMNIHOMEenvironment variable in many configuration files. Set the value of OMNIHOME asfollows: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 tocollect, process, and store information about managed network elements.

The Probe for CA Spectrum V9 (CORBA) collects alarm information from one ormore SpectroSERVERs using a proprietary Common Object Request BrokerArchitecture (CORBA) interface.

This guide contains the following sections:v “Summary”v “Installing probes” on page 2v “Setting environment variables” on page 3v “Installing Spectrum utilities” on page 3v “Firewall considerations” on page 4v “Configuring SpectroSERVERs” on page 5v “Configuring the probe” on page 5v “Data acquisition” on page 12v “Properties and command line options” on page 19v “Elements” on page 25v “Error messages” on page 27v “ProbeWatch messages” on page 32v “Running the probe” on page 34v “Troubleshooting” on page 34v “Known issues” on page 35

SummaryEach probe works in a different way to acquire event data from its source, andtherefore has specific features, default values, and changeable properties. Use thissummary 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 earlierversion, 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 thefollowing Release Notice on the IBM Software Supportwebsite:

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 proberequires, refer to the description.txt file that issupplied in its download package.

Connection method CORBA

Remote connectivity The probe can connect to a remote device using aCORBA interface.

Multicultural support Available

For information about configuring multiculturalsupport, including language options, see the IBM TivoliNetcool/OMNIbus Installation and Deployment Guide.

Peer-to-peer failover functionality Available

IP environment IPv4 and IPv6

Federal Information ProcessingStandards (FIPS)

IBM Tivoli Netcool/OMNIbus V7.3.0, 7.3.1, 7.4.0, and8.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 athttp://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2004.htm. For details about configuringNetcool/OMNIbus for FIPS 140-2 mode, see the IBMTivoli Netcool/OMNIbus Installation and Deployment Guide.

Installing probesAll probes are installed in a similar way. The process involves downloading theappropriate installation package for your operating system, installing theappropriate files for the version of Netcool/OMNIbus that you are running, andconfiguring 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 systemsupported. For details about how to locate and download the installationpackage for your operating system, visit the following page on the IBM TivoliKnowledge 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



http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2004.htm

http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2004.htm

http://www-01.ibm.com/support/knowledgecenter/SSSHTQ/omnibus/probes/all_probes/wip/reference/install_download_intro.html

http://www-01.ibm.com/support/knowledgecenter/SSSHTQ/omnibus/probes/all_probes/wip/reference/install_download_intro.html

The installation package contains the appropriate files for all supportedversions of Netcool/OMNIbus. For details about how to install the probe torun with your version of Netcool/OMNIbus, visit the following page on theIBM 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 thisprobe. It combines topics that are common to all probes and topics that arepeculiar to this probe. For details about additional configuration that iscommon to all probes, see the IBM Tivoli Netcool/OMNIbus Probe and GatewayGuide.

Setting environment variablesEnvironment variables are specific preset values that establish the workingenvironment of the probe.

The minimum requirement to run this probe is Java 6. The selection of the JREused for the probe's runtime environment adheres to the following order ofprecedence: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 utilitiesThe probe requires access to a number of Java utilities that are supplied with yourCA Spectrum installation.

Copy the following files from $SPECROOT/lib to $OMNIHOME/probes/java/nco_p_spectrum_corba_v9/:v jsafeJCEFIPS.jar

v global9x.jar

v lm.jar

v ssorb9x.jar

v ssorbutil9x.jar

v util9x.jar

v utilapp9x.jar

v utilnet9x.jar

v utilsrv9x.jar

v vbhelper9x.jar

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

http://www-01.ibm.com/support/knowledgecenter/SSSHTQ/omnibus/probes/all_probes/wip/reference/install_install_intro.html

http://www-01.ibm.com/support/knowledgecenter/SSSHTQ/omnibus/probes/all_probes/wip/reference/install_install_intro.html

v vbjorb.jar

v vbsec.jar

where $SPECROOT is the directory where CA Spectrum is installed and 9x is theversion 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 thefollowing files to $OMNIHOME/probes/java/nco_p_spectrum_corba_v9/:v sanct6.jar

v sanctuary.jar

Firewall considerationsWhen using CORBA probes in conjunction with a firewall, the firewall must beconfigured so that the probe can connect to the target system.

Most CORBA probes can act as both a server (listening for connections from thetarget system) and a client (connecting to the port on the target system to whichthe 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 mustdetermine 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 thetarget system will connect.

3. If each host is secured with its own firewall, you must determine the followingfour 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 theORBLocalPort property. The default value for this property is 0, which means thatan available port is selected at random. If the probe is behind a firewall, the valueof the ORBLocalPort property must be specified as a fixed port number.

CORBA probes that use EventManager or NotificationManager objects may usedifferent hosts and ports from those that use NamingService and EntryPointobjects. If the probe is configured to get object references from a NamingService orEntryPoint object, you must obtain the host and port information from the systemadministrator of the target system. When you have this information, you can addthe appropriate firewall rules.


Configuring SpectroSERVERsYou must configure the SpectroSERVERs that you are using to enable them toaccept CORBA connections from the probe.

Configuring a SpectroSERVER to accept connections from the probe involves thefollowing 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 toconnect 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 followingCA 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 PanelUser Guide (5029.pdf).

Configuring the probeGlobal properties that affect all monitored SpectroSERVERs are specified using theproperties file spectrum_corba_v9.props. The details of each monitoredSpectroSERVER are specified using host-specific properties in the hostconfiguration 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 10v “Configuring ObjectServer host properties” on page 12

Using the host configuration fileYou must configure at least one SpectroSERVER in the host configuration filesupplied with the probe.

The host configuration file spectrum_corba_v9_host.xml is an XML file thatcontains the details of each SpectroSERVER host that you want the probe tomonitor. It is installed to the following directory:

$OMNIHOME/probes/arch/

Use the HostFile property to specify the directory path to the host configurationfile.

In addition to specifying the details of each SpectroSERVER host, you can also usethe host configuration file to specify how the probe handles the alarms it retrievesfrom each SpectroSERVER. The host configuration properties are XML elements, so


they cannot be accessed using the command line interface, but you can edit the filein any text editor. The probe uses the XML schema file spectrum_corba_v9.xsd tovalidate the host configuration file.

The following table lists the available configuration properties contained in thehost configuration file.

Table 4. Host configuration file properties

Property Description

<SpectroServer Name=""Domain="" IP="">

...

</SpectroServer>

Use this property to specify the name, domain, and IPaddress of the SpectroSERVER host machine.

Note: You must specify both the Name and the Domain value inlowercase.

<ModelAttributes Value=""/>

Use this property to specify a comma-separated list of modelattributes that the probe should extract in addition to thedefault attributes.

You can specify alarm attributes by their identifiers (base 10or base 16) or by their unique canonical names as specified bythe CA Spectrum type catalog.

Retrieved attributes become tokens that are available to therules file using their canonical names. The following examplecreates the tokens $Security_String and $Notes:

<ModelAttributes Value="0x10009, 0x11564" />

You can specify a maximum of one ModelAttributes propertyfor each SpectroSERVER.

<AlarmAttributes Value=""/>

Use this property to specify a comma-separated list of alarmattributes that the probe should extract in addition to thedefault attributes.

You can specify alarm attributes by their identifiers (base 10or base 16) or by their unique canonical names as specified bythe CA Spectrum type catalog.

Retrieved attributes become tokens that are available to therules file using their canonical names. The following examplecreates the tokens $Cleared_By_User_Name and $Occurrences:

<AlarmAttributes Value= "Cleared_By_User_Name,0x11fc5"/>

You can specify a maximum of one AlarmAttributes propertyfor each SpectroSERVER.

<TimeStampFile Value=""/>

Use this property to specify the location of the file in whichthe probe stores the timestamp of the last alarm it processed.

For example:

<TimeStampFile Value="/home/user/netcool/omnibus-v7.2.1-solaris2/omnibus/probes/solaris2/server2.timestamp" />

You can specify a maximum of one TimeStampFile propertyfor each SpectroSERVER.


Table 4. Host configuration file properties (continued)


<FetchEventFormatFieldsValue="false" />

Use this property to specify whether the probe retrieves theevent data fields attached to an alarm and makes themavailable to the rules file This property takes the followingvalues:

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 tokensin the format $Event_NAME, where NAME is the canonical nameof the attribute in the CA Spectrum type catalog. If anattribute has no entry in the type catalog, NAME is given as itsidentifier in hexadecimal format.

You can specify a maximum of one FetchEventFormatFieldsproperty for each SpectroSERVER.

<FetchEventStringValue="false" />

Use this property to specify whether the probe creates eventmessages using the originating event field data attached to analarm. 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 thetoken $Event_Format_String.

This property requires that the FetchEventFormatFieldsproperty is set to true and that the EventFormatFile propertycontains a valid directory path.

You can specify a maximum of one FetchEventStringproperty for each SpectroSERVER.




<EventFormatFile Value=""/>

Use this property to specify the local directory where theevent 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 hostwhere the probe is installed. If the probe is running on adifferent host than CA Spectrum, you must copy the eventformat files to the host where the probe is installed.EventFormatFile should contain the directory path where allthese event format files are kept.

You can specify several instances of the EventFormatFileproperty for each SpectroSERVER. The probe reads eachproperty in turn until it finds a match, so the order in whichthey are listed is important if you have duplicate eventformat files.

<ProbCauseLookupFileValue="" />

Use this property to specify the location of the probable causelookup file.

For example:

<ProbCauseLookupFile Value="/home/user/netcool/omnibusv7.2.1-solaris2/omnibus/probes/solaris2/server1.lookup"/>

You can specify a maximum of one ProbCauseLookupFileproperty for each SpectroSERVER.

You can generate probable cause lookup files using theSpectrumCause.pl script supplied with the probe. For moreinformation, see “Using lookup tables” on page 10.

<ResyncIntervalValue="86400" />

Use this property to specify the time interval (in seconds) atwhich the probe performs automatic resynchronizations.

The default is 86400 seconds (24 hours).

You can specify a maximum of one ResyncInterval propertyfor each SpectroSERVER.




<ResyncSQLCmd Value= ""/>

Use this property to specify an SQL command to update theObjectServer during a resynchronization.

The default is UPDATE alerts.status SET Severity = 0 WHERELastOccurrence <= %ResyncTime AND Node =%SpectroServerName AND AlertKey NOT IN (%AlarmID_List)

You can specify a maximum of one ResyncSQLCmd property foreach 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 bythe character entity “<”. For example, in the SQL statementabove, LastOccurrence <= %ResyncTime representsLastOccurrence <= %ResyncTime. The XML character entity forthe greater-than sign (>) is “>”.

Example 1

The following example of a host configuration file configures two SpectroSERVERsfor use with the probe. Alarms are handled according to the default settings on theSpectroSERVER 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 SpectroSERVERsand 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 <= %ResyncTime ANDNode = %SpectroServerName ANDAlertKey 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"


/><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 WHERELastOccurrence <= %ResyncTime ANDNode = %SpectroServerName ANDAlertKey NOT IN (%AlarmID_List)" />

</SpectroServer>

Using lookup tablesYou can use the SpectrumCause.pl Perl script supplied with the probe to createlookup files. The lookup files contain tables that enable the rules file to match CASpectrum probable cause descriptions to the alarms generated by theSpectroSERVER.

When you use lookup tables, the following tokens are generated in the rules filewith 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 followingsteps:1. Run the SpectrumCause.pl script on the SpectroSERVER host, using the

following command:perl SpectrumCause.pl spectrum_install_dir lookup_file_location

where spectrum_install_dir is the SpectroSERVER directory that contains theCA Spectrum probable cause files and lookup_file_location is the full directorypath to the generated lookup file.

2. Copy the generated lookup file to the probe host, for example:/home/user/netcool/omnibus-v7.2.1-solaris2/omnibus/probes/solaris2/server1.lookup

3. If the probe is running, stop it.4. Open the rules file spectrum_corba_v9.rules in a text editor.5. 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-specificname and replace /etc/user/my.lookup with the directory path to the lookupfile.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 lookupfile that you are using. Each entry must have a unique lookup table name andlookup file name, and be followed by the default line.For example:


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 SpectroSERVERhost as specified by the Name attribute of the SpectroServer property in thehost configuration file spectrum_corba_v9_host.xml.

9. Replace spectrum_lookup_table with the lookup table name that you specified inStep 6.

10. If you are using multiple SpectroSERVERs, repeat Steps 7 to 9 for each lookupfile 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.


Configuring ObjectServer host propertiesThe probe uses a separate connection to the ObjectServer when it is performing aresynchronization. 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 propertiesfile: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 hostname specified in the $NCHOME/etc/omni.dat interfaces file.

v OS.Password - this property specifies the password that the probe uses to connectto the ObjectServer.

v OS.Port - this property specifies the port through which the probe connects tothe ObjectServer. It must have the same value as the ObjectServer port specifiedin the $NCHOME/etc/omni.dat interfaces file.

v OS.UserName - this property specifies the user name used to connect to theObjectServer.

v Server - this is a generic Netcool/OMNIbus property that specifies the name ofthe ObjectServer host.

Data acquisitionEach probe uses a different method to acquire data. Which method the probe usesdepends on the target system from which it receives data.

The Probe for CA Spectrum V9 (CORBA) gathers events from SpectroSERVERsusing a proprietary Common Object Request Broker Architecture (CORBA)interface.

When the probe starts, it connects to a SpectroSERVER using the details specifiedby the SpectroServer property in the host configuration file ($OMNIHOME/probes/arch/spectrum_corba_v9_host.xml). On connection, the probe listens for newalarms from the SpectroSERVER.

The probe then initializes the CORBA status monitor to monitor the status of theCORBA services. The probe checks the status of the CORBA services at intervalsspecified by the SpectroServerPollInterval property.

Initially, the probe retrieves a list of all active alarms from the SpectroSERVER. Onsubsequent connections, the probe retrieves all active alarms if theAllAlarmsOnReStart property is enabled (set to 1). If the AllAlarmsOnReStartproperty is disabled (set to 0), the probe only retrieves alarms that were generatedwhile the probe was disconnected.

When the AllAlarmsOnReStart property is disabled (the default setting), you mustuse the TimeStampFile property in the host configuration file to specify atimestamp file. This prevents the probe from performing a full resynchronizationevery time it starts up.

If you are running two SpectroSERVERs in a failover configuration, the probeindicates in the log file whether it is connected to the primary SpectroSERVER orthe secondary SpectroSERVER.

Data acquisition is further described in the following topics:


v “Configuring the event details extraction buffering mechanism”v “Specifying the event extraction method that the probe uses”v “Resynchronization” on page 14v “Filtering alarms” on page 15v “Backoff strategy” on page 16v “Command line interface” on page 16v “Peer-to-peer failover functionality” on page 18

Configuring the event details extraction buffering mechanismIf you set the <FetchEventFormatFields> XML property to true, when the probereceives an alarm from the SpectroSERVER, it makes a call to Archive Manager toretrieve non-OE event fields attached to the alarm. Whatever alarms the probe islistening to, it first writes them to a buffer, then starts processing the alarms oneevent at a time. Once completed, the probe will take another alarm from the bufferto process, and so forth.

The EventRetry and EventRetryTimeout properties specify how the probe retriesthe extraction of non-OE events from the Archive Manager if the Archive Managerservice is down. Use the EventRetry property to specify how may times the probeattempts to extract event details from Archive Manager before moving on to thenext alarm. Use the EventRetryTimeout property to specify how long the probewaits to receive the event details before timing out and retrying the eventextraction request.

Specifying the event extraction method that the probe usesThe probe can either extract all events attached to an alarm (which requiresmaking an additional call to Archive Manager) or it can extract details of just theOriginating Event.

You can specify which method the probe uses to extract details of the eventsattached to an alarm by setting the EventExtraction property to one of thefollowing 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 toArchive Manager (AM).

v OE Method: Using this method, the probe extracts from the alarm details of theoriginating event that raised the alarm from the Originating Event (OE) bytestream. It does not require the probe making an additional call to ArchiveManager and so avoids any delays that this may incur.

Note: You can run two SpectroSERVERs in a failover configuration, in which casethe probe can be configured to failover to a secondary SpectroSERVER if theprimary SpectroSERVER fails. When the probe is connected to the secondarySpectroSERVER, it will always use the OE method to extract details of eventsattached to an alarm regardless of setting of the EventExtraction property.


ResynchronizationIf the probe loses the connection to a SpectroSERVER, there are three methods forresynchronizing cleared alarms in the SpectroSERVER with the ObjectServer.Resynchronization can be performed using the command line interface (CLI), theSpectroSERVER resynchronization interval, and during the SpectroSERVER failoverprocess.

Note: Events that are deleted from the SpectroSERVER while the probe isdisconnected remain in the ObjectServer and must be manually cleared. If theprobe is using a timestamp file, some duplication of alarms may occur.

Resynchronization to the ObjectServer is performed using an SQL statementspecified by the ResyncSQLCmd property in the host configuration file. You canconfigure the Value attribute of the ResyncSQLCmd property using the tokens listedin the following table.

Table 5. ResyncSQLCmd property tokens

Token Description

%AlarmID_List The list of active alarm identifiers collected duringresynchronization.

%Manager The same value as the generic Netcool/OMNIbusManager 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 Nameproperty.

%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 requestedactive alarm list.

%Server The same value as the generic Netcool/OMNIbusServer property.

%ServerBackup The same value as the generic Netcool/OMNIbusServerBackup property.

%SpectroServerName The name of the SpectroSERVER host as specified bythe Name attribute of the SpectroServer property in thehost configuration file.

%SpectroServerDomain The domain of the SpectroSERVER host as specified bythe Domain attribute of the SpectroServer property inthe host configuration file.

%SpectroServerIP The IP address of the SpectroSERVER host as specifiedby the IP attribute of the SpectroServer property inthe host configuration file.

Resynchronization using the CLI

You can perform a manual resynchronization using the resync spectrumNamecommand, where spectrumName is the name of the SpectroSERVER host asspecified by the Name attribute of the SpectroServer property in the hostconfiguration file. For more information about using the CLI, see “Command lineinterface” on page 16.


Using a resynchronization interval

You can use the ResyncInterval property in the host configuration file to set anautomatic resynchronization at specified intervals. The default is 86400 seconds (24hours). You can specify different resynchronization intervals for each monitoredSpectroSERVER.

Using a SpectroSERVER failover configuration

If you are running two SpectroSERVERs in a failover configuration, you can usethe ResyncOnFailover property to trigger a resynchronization operation when theprobe fails over to the secondary SpectroSERVER. There is a possibility that thesecondary SpectroSERVER might not contain all available alarms while theprimary SpectroSERVER is down. To avoid data loss, you can use theResyncPrimaryOnly property to specify that the probe resynchronizes with theprimary SpectroSERVER only.

You can use the ResyncThreadMax property to specify the maximum number ofthreads that the probe spawns to perform the resynchronization operation. Specifya value of 0 to allow the probe to use an unlimited number of threads. The defaultis 5.

Filtering alarmsYou can restrict the alarms that the probe retrieves to a range of CA Spectrumseverity values. Alarm filtering is only available when the AllAlarmsOnRestartproperty is disabled (set to 0).

Use the MinSpectrumSeverity property to specify the minimum severity levelthreshold. The probe will not monitor alarms below this severity level. The defaultis 0 (CA Spectrum severity Normal).

Use the MaxSpectrumSeverity property to specify the maximum severity levelthreshold. The probe will not monitor alarms above this severity level. The defaultis 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


Backoff strategyIf the Retry property is set to 1, and the probe fails to establish a connection orloses 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 atintervals specified by the RetryInterval property.

If the Retry property is set to 0, and the probe is monitoring only oneSpectroSERVER, the probe will shut down when it loses the connection. If theprobe is monitoring more than one SpectroSERVER, it will not shut down.

Command line interfaceThe probe is supplied with a Command Line Interface (CLI). This interface enablesyou to execute commands to acknowledge alarms and update fields in theSpectroSERVER.

To use the CLI, you must use the CommandPort property to specify a port throughwhich commands will be sent. The default port is 7777. When you want to issuecommands, use Telnet to connect through this port. You can use theCommandPortLimit property to limit the number of Telnet connections that theprobe can make at one time.

You can use the CLI to update the SpectroSERVER fields listed in the followingtable.

Table 7. SpectroSERVER fields

SpectroSERVER field Description

Acknowledged This field indicates whether the alarm has beenacknowledged 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 resultedin 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 analarm.

You can use Netcool/OMNIbus automations to reflect SpectroSERVER fieldupdates in the corresponding ObjectServer fields. For more information aboutusing 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. ThespectrumName parameter used by the CLI commands requires the name of theSpectroSERVER host as specified by the Name attribute of the SpectroServerproperty in the host configuration file. The alarmID parameter must be given inhexadecimal format.


Table 8. CLI commands

Command Description

acknowledgeAlarm alarmID spectrumName Use this command to acknowledge an alarm byspecifying the alarm identifier and theSpectroSERVER host name.

unacknowledgeAlarm alarmIDspectrumName

Use this command to unacknowledge an alarmby specifying the alarm identifier and theSpectroSERVER host name.

clearAlarm alarmID spectrumName Use this command to clear an alarm byspecifying the alarm identifier and theSpectroSERVER host name.

resync spectrumName Use this command to resynchronize aSpectroSERVER.

updateStatus alarmID statusspectrumName

Use this command to update the status of analarm by specifying the alarm identifier, the newstatus, and the SpectroSERVER host name.

updateTroubleShooterName alarmID namespectrumName

Use this command to update the troubleshootername of an alarm by specifying the alarmidentifier, the new troubleshooter name, and theSpectroSERVER host name.

updateTroubleTicket alarmID ticketIDspectrumName

Use this command to update the trouble ticketnumber for an alarm by specifying the alarmidentifier, the new ticket identifier, and theSpectroSERVER host name.

updateTroubleShooterModel alarmIDmodel spectrumName

Use this command to update the troubleshootertype of an alarm by specifying the alarmidentifier, the new troubleshooter type, and theSpectroSERVER host name.

updateEventList alarmID eventIDListspectrumName

Use this command to update the event list of analarm by specifying the alarm identifier, theevent list identifier, and the SpectroSERVER hostname.

Note: This command feature is currentlyunavailable. For details, see “Known issues” onpage 35.

CLI scripts

Because the CLI uses Telnet connections, you can connect to the probe fromanywhere 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 toallow users to acknowledge selected events from the IBM Tivoli Netcool/OMNIbusevent list.


Peer-to-peer failover functionalityThe probe supports failover configurations where two probes run simultaneously.One probe acts as the master probe, sending events to the ObjectServer; the otheracts as the slave probe on standby. If the master probe fails, the slave probeactivates.

While the slave probe receives heartbeats from the master probe, it does notforward events to the ObjectServer. If the master probe shuts down, the slaveprobe stops receiving heartbeats from the master and any events it receivesthereafter are forwarded to the ObjectServer on behalf of the master probe. Whenthe master probe is running again, the slave probe continues to receive events, butno 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 andslave 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. Inother 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 amaster probe:Server : "NCOMS"RulesFile : "master_rules_file"MessageLog : "master_log_file"PeerHost : "slave_hostname"PeerPort : 5555 # [communication port between master and slave probe]Mode : "master"PidFile : "master_pid_file"

The following example shows the peer-to-peer settings from the properties file ofthe corresponding slave probe:Server : "NCOMS"RulesFile : "slave_rules_file"MessageLog : "slave_log_file"PeerHost : "master_hostname"PeerPort : 5555 # [communication port between master and slave probe]Mode : "slave"PidFile : "slave_pid_file"


Properties and command line optionsYou use properties to specify how the probe interacts with the device. You canoverride the default values by using the properties file or the command lineoptions.

The following table describes the properties and command line options specific tothis probe. For more information about generic Netcool/OMNIbus properties andcommand line options, see the IBM Tivoli Netcool/OMNIbus Probe and GatewayGuide.

Table 9. Properties and command line options

Property name Command line option Description

AllAlarmsOnReStartinteger

-allalarmsonrestartinteger

Use this property to specifywhether the probe retrieves allactive alarms when it connects oronly those that have been createdsince the last connection. Thisproperty takes the followingvalues:

0: The probe only retrieves alarmsgenerated since the lastconnection.

1: The probe retrieves all activealarms; no alarm filter is appliedby the probe.

The default is 0.

CommandPort integer -commandport integer Use this property to specify theport through which you will sendcommands using the CLI.

The default is 7777.

Note: The CA Spectrum CLI alsouses port number 7777. You mustchange one of these port numbersto ensure that each CLI is using aunique port.

CommandPortLimit integer -commandportlimit integer Use this property to specify themaximum number of Telnetconnections that the probe canmake using the command port.

The default is 10.


Table 9. Properties and command line options (continued)


EventExtraction string -eventextraction string Use this property to specify whichmethod the probe uses to extractdetails of the events attached to analarm. This property takes thefollowing values:

AM: The probe makes an additionalcall to Archive Manager (AM) toretrieve details of one or moreevents that raised the alarm.

OE: The probe extracts from thealarm details of the originatingevent that raised the alarm fromthe OriginatingEvent (OE) bytestream, and so does not make anadditional call to ArchiveManager.

The default is AM.

Note: When the probe isconnected to the secondarySpectroSERVER, it will always usethe OE method to extract detailsof events attached to an alarmregardless of setting of theEventExtraction property.

EventRetry integer -eventretry integer Use this property to specify howmany times the probe attempts toextract from the Archive Managerthe event details associated withan alarm event before moving onto the next alarm.

The maximum that you can setthis property to is 5. If you set thisproperty to 0, the probe will notretry the event details extraction.

The default is 3.

Note: If you set this property to avalue other than between 0 and 5,the probe will use the defaultvalue of 3.




EventRetryTimeout integer -eventretrytimeoutinteger

Use this property to specify thetime (in seconds) that probe waitsto receive from the ArchiveManager the event detailsassociated with an alarm. If thistime is exceeded, the probe retriesthe event extraction request. Thenumber of times that the proberetries the event extraction isspecified by the EventRetryproperty.

The maximum that you can setthis property to is 5 seconds. Ifyou set this property to 0, theprobe will not timeout whilewaiting for the event details.

The default is 3.

Note: If you set this property to avalue other than between 0 and 5,the probe will use the defaultvalue of 3.

FlushBufferIntervalinteger

-flushbufferintervalinteger

Use this property to specify howoften (in seconds) the probeflushes all alerts in the buffer tothe ObjectServer.

The default is 0 (the probe doesnot flush alerts to theObjectServer).

HostFile string -hostfile string Use this property to specify thelocation of the host configurationfile spectrum_corba_v9_host.xml.

The default is "".

MaxSpectrumSeverityinteger

-maxspectrumseverityinteger

Use this property to specify themaximum severity level abovewhich the probe will not retrievealarms.

The default is 6 (CA Spectrumseverity Initial).

MinSpectrumSeverityinteger

-minspectrumseverityinteger

Use this property to specify theminimum severity level belowwhich the probe will not retrievealarms.

The default is 0 (CA Spectrumseverity Normal).




ORBLocalHost string -orblocalhost string Use this property to specify thelocal host name or IP address usedby the server-side ORB to placethe server's host name or IPaddress into the IOR of a remoteobject.

The default is "".

ORBLocalPort string -orblocalport string Use this property to specify thelocal port to which the ObjectRequest Broker (ORB) listens forconnections from the probe.

The default is 0 (the ORB selectsan available port at random).

OS.Host string -oshost string Use this property to specify thehost name of the ObjectServer towhich the probe connects duringresynchronization operations.

The default is localhost.

OS.Password string -ospassword string Use this property to specify thepassword of the ObjectServer towhich the probe connects duringresynchronization operations.

The default is "".

Use the nco_g_crypt utilitysupplied with Netcool/OMNIbusto encrypt the password. . Forinformation about using thisutility, see the IBM TivoliNetcool/OMNIbus AdministrationGuide (SC14-7605).

OS.Port integer -osport integer Use this property to specify theport number of the ObjectServerto which the probe connectsduring resynchronizationoperations.

The default is 4100.

OS.UserName string -osusername string Use this property to specify theuser name used to connect to theObjectServer duringresynchronization operations.

The default is root.




ResyncOnFailover integer -resynconfailover integer Use this property to specifywhether the probe performs aresynchronization during theSpectroSERVER failover process.This property takes the followingvalues:

1: The probe performs aresynchronization.

0: The probe does not perform aresynchronization.

The default is 0.

ResyncPrimaryOnly integer -resyncprimaryonlyinteger

Use this property to make theprobe resynchronize with theprimary SpectroSERVER onlyduring the SpectroSERVERfailover process. This propertytakes the following values:

1: The probe performs aresynchronization with theprimary SpectroSERVER only.

0: The probe resynchronizes witheither SpectroSERVER.

The default is 1.

ResyncThreadMax integer -resyncthreadmax integer Use this property to specify themaximum number of threads thatthe probe spawns to perform aresynchronization.

Specify a value of 0 to allow theprobe to use an unlimited numberof threads.

The default is 5.




Retry integer -retry integer Use this property to specifywhether the probe attempts toreconnect to a SpectroSERVERafter losing the connection.

This property takes the followingvalues:

1: The probe attempts to reconnectwith the SpectroSERVER atintervals specified by theRetryInterval property.

0: The probe does not attempt toreconnect.

There are two scenarios of retry:

1. If Retry is set to 1 and theprobe is started whenSpectrum is down, the probewill try to connect toSpectroSERVER using theRetryInterval property value.When Spectrum is up and backto service, the probe willconnect to Spectrum after thenext RetryInterval haselapsed.

2. If Retry is set to 1, andSpectrum goes down after theprobe has already started, theprobe will wait displaying themessage WAIT_AUTO_RECONNECTevery second until Spectrum isback up to service. WhenSpectrum is back up to service,the probe will immediately beable to receive events fromSpectrum.

The default is 1.

RetryInterval integer -retryinterval integer Use this property to define thelength of retry interval (inseconds) for reconnecting to theSpectroSERVER after beingdisconnected.

The default is 30.

SpectroServerPollInterval integer

-spectroserverpollinterval integer

Use this property to specify theinterval (in seconds) at which theprobe polls the CORBA services tocheck their availability.

The default is 20 seconds.


ElementsThe probe breaks event data down into tokens and parses them into elements.Elements are used to assign values to ObjectServer fields; the field values containthe event details in a form that the ObjectServer understands.

The following table describes the elements that the probe generates. Not all theelements described are generated for each event. The elements that the probegenerates depend on the event type.

Table 10. Elements

Element name Element description

$Acknowledged This element indicates if the alarm has beenacknowledged by a CA Spectrum operator.

$AlarmID This element contains the identifier of the alarm.The probe sends this element to the rules file as azero-padded 8-character hexadecimal string.

Note: The alarm ID changes when an event failsover 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 aprevious run of the SpectroSERVER.

$ClearMe This element indicates whether the event is aresolution event.

A value of true sets the ObjectServer field @Typeto 2 in the rules file. This indicates that it is aresolution event.

$CauseNum This element shows the probable cause numberof the event. The probe sends this element to therules file as a zero-padded 8-characterhexadecimal string.

$ClearedBy This element contains the user name associatedwith the user who cleared the alarm through theCA Spectrum API. This element is not presentwhen an alarm is created but it is added prior toremoval.

$CreationDate This element contains the date when the alarmwas generated.

$DomainID This element contains the domain ID of theSpectroSERVER.

$EventIDList This element contains the list of SpectroSERVERevent identifiers that triggered the alarm.

$IPAddress This element contains the IP address of thereporting node.

$ModelHandle This element contains a model handle. A modelhandle is a 32-bit number in which thehigh-order 12 bits make up the landscape and theremaining 20 bits make up the model identifier.


Table 10. Elements (continued)

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 thatraised the alarm.

$Occurrences This element shows the number of times that theevent has occurred.

$PrimaryAlarm This element indicates the priority of the alarm inthe SpectroSERVER. A value of true identifies thealarm as a primary alarm. Primary alarms havethe highest priority.

$Pre-existing This element indicates whether the received eventis already present in the SpectroServer.

$Primary This element indicates whether the probe isconnected to a primary SpectroSERVER or to asecondary SpectroSERVER. A value of falseindicates that the probe is connected to asecondary server.

$Priority This element indicates the priority in theSpectroSERVER.

$Severity This element indicates the severity of the alarm inthe SpectroSERVER.

$TroubleShooter This element displays the name of the specifiedtroubleshooter. This element maps to theTroubleShooter SpectroSERVER field, which canbe updated using the updateTroubleShooterNameCLI command.

$TroubleShooterModel This element displays the model type of thespecified troubleshooter. This element maps tothe TroubleShooterModel SpectroSERVER field,which can be updated using theupdateTroubleShooterModel CLI command.

$TroubleTicketID This element displays the identifier of the troubleticket associated with an alarm. This elementmaps to the TroubleTicketID SpectroSERVERfield, which can be updated using theupdateTroubleTicket CLI command.

$UserClearable This element indicates whether or not a client canclear the alarm. This element is provided so thatclient applications can indicate to users that thealarm is not clearable. A client cannot controlwhether an alarm is clearable.


Error messagesError messages provide information about problems that occur while running theprobe. You can use the information that they contain to resolve such problems.

The following table describes the error messages specific to this probe. Forinformation about generic Netcool/OMNIbus error messages, see the IBM TivoliNetcool/OMNIbus Probe and Gateway Guide.

Table 11. Error messages

Error Description Action

Exception when attemptingto run status monitorProbe shutting downbecause CORBA Statusmonitor not pollingsuccessfully.

Exception thrown whenattempting to start CORBAserviceProbe shutting down asunable to access CORBAservice, please ensurethat server configurationis complete and try againProbe shutting downbecause Probe unable toaccess CORBA service

Exception when attemptingto establish a filter foralarmsProbe shutting down asunable to receivealarms,please ensure thatthe timestamp filepointed to does notcontain corrupted dataProbe shutting downbecause unable toestablish Alarm Watchfilter

Exception when attemptingto establish an AlarmWatchProbe shutting down asunable to receivealarms,please ensure thatserver configuration iscomplete and try againProbe shutting downbecause unable toestablish Alarm Watch

The probe could not initializethe connection with theCORBA interface and isshutting down.

Check the SpectroSERVERconfiguration.

Verify that the values set forthe Domain, Name, and IPattributes of theSpectroServer property arecorrect in the hostconfiguration file.

Check the firewall settings inyour environment.

Check that the appropriateadditions were made to theSpectroSERVER server list.

Verify that a Spectrum UserModel exists for the user IDthat runs the probe.


Table 11. Error messages (continued)


Error occurred attemptingto pass on details ofcleared alarms to theObject Server.Probe shutting downbecause Problemprocessing clearedalarms.

Error occurred attemptingto pass updates to theObject ServerProbe shutting downbecause Problemprocessing updatedalarms.

Error occurred attemptingto pass details of newalarms to the ObjectServerProbe shutting downbecause Problemprocessing new alarms

Error in connecting toCORBA interfaceError external to CORBAframeworkProbe shutting downbecause External error inconnection to CORBAinterface

Exception thrown whenquerying whether we areaccessing PrimarySpectroSERVERProbe shutting downbecause Problem queryingSpectroSERVER.

Connection to CORBAinterface has been lost.Error internal to CORBAinterfaceProbe shutting downbecause Internal error inCORBA interface,connection lost

Error shutting downconnection to CORBAinterface

The probe connection withthe CORBA interface hasfailed.

Restart the probe.

Check whether theSpectroSERVERconfigurations have changed.

Verify that theSpectroSERVER is running.




Failed to pick up probeproperty TimeStampFileNot using timestamp file,proceeding to collect allactive alarms.

Timestamp of alarms notstored for re-sync

Unable to createtimestamp file

Unable to find time stampfile

Unable to write totimestamp file

Error closing timestampfile

Error opening timestampfile for reading

The probe failed to use thetimestamp file. These errorsare not fatal error messages.

Check the specific messageand verify that the timestampfile is accessible.




Alarm + alarmID + Errorclearing alarmError clearing alarm

Alarm + alarmID + Errorin Event ID List updateError updating the eventID List

Alarm + alarmID + Errorin Trouble Shooter ModelupdateError updating thetrouble shooter model

Alarm + alarmID + Errorin Trouble Ticket updateError updating thetrouble ticket

Alarm + alarmID + Errorin Troubleshooter NameupdateError updating thetrouble shooter name

Alarm + alarmID + Errorin status updateError updating the alarmstatus

Alarm + alarmID +Error inunacknowledgeError un-acknowledgingalarm

Alarm + alarmID + Errorin acknowledgeError acknowledging alarm

The probe failed to update anevent.

Verify that the alarm you aretrying to update exists in theSpectroSERVER.

Note: If the alarm is notfound, the SpectroSERVERshows an error message.

Invalid spectrum alarmseverity:MaxSpectrumSeverity isgreater than 6. Validspectrum alarm severityvalue is from 0 to 6.

The value set for theMaxSpectrumSeverity propertyis greater than the maximumvalid value. The valid valuesfor this property are between0 to 6.

Set the MaxSpectrumSeverityproperty to a value between 0to 6.

Invalid spectrum alarmseverity: the values ofMinSpectrumSeverity andMaxSpectrumSeverity arenot in order. Validspectrum alarm severityvalue is from 0 to 6.

The value set for theMinSpectrumSeverity propertyis greater than that set for theMaxSpectrumSeverity property.

Set the MinSpectrumSeverityproperty to a value between 0to 6, and less than that set forthe MaxSpectrumSeverityproperty.




Invalid spectrum alarmseverity:MinSpectrumSeverity isless than 0. Validspectrum alarm severityvalue is from 0 to 6.

The value set for theMinSpectrumSeverity propertyis less than 0, which is notvalid.

Set the MinSpectrumSeverityproperty to a value between 0to 6.

[Command Port] Failed toopen listening socket:java.lang.IllegalArgumentException: Portvalue out of range:<invalid value>

The value set for theCommandPort property is notvalid.

Set the CommandPort propertyto a positive integer.

[Command Port] Failed toopen listening socket:java.net.BindException:Address already in use

The probe failed to listen tocommand port socket becausethe CommandPort property isset to a value that is alreadyin use.

Set the CommandPort propertyto a value that is not alreadyin use.

Host parser exception :file:///<hostconfiguration file path>LineNumber=62ColumnNumber=21Msg=cvc-complex-type.2.4.b: The contentof element'ProbeHeadProperty' isnot complete. One of'{SpectroServer}' isexpected. Error inparsing hostconfiguration file. Probewill shutdown

No SpectroServer is specifiedin host configuration file.

Specify at least oneSpectroServer in the hostconfiguration file.

Host parser exception :file:///<hostconfiguration file path>LineNumber=51ColumnNumber=37Msg=cvc-complex-type.2.4.a: Invalidcontent was foundstarting with element'<property name in hostconfig file>'. One of'{AlarmAttributes,TimeStampFile,FetchEventFormatFields,FetchEventString,EventFormatFile,ProbCauseLookupFile,ResyncInterval,ResyncSQLCmd}' isexpected. Error inparsing hostconfiguration file. Probewill shutdown

Duplicate entries were foundin the host configuration filefor at least one of thefollowing properties:AlarmAttributes,TimeStampFile,FetchEventFormatFields,FetchEventString,EventFormatFile,ProbCauseLookupFile,ResyncInterval,ResyncSQLCmd.

Specify only one entry in thehost configuration file for anyof the properties listed.




Retry value must be 0 or1.

Error in Retry propertyvalue. Probe willshutdown

Retry is set to invalid value. Change the value of Retry inthe properties file.

[servername] failed toretrieve related events:

[servername] no eventscould be fetchedsuccessfully for thisalarm

The Archive Manager serviceis down and the probe couldnot retrieve events for thealarm from the ArchiveManager.

Restart the Archive Managerservice.

Unknown hostconfiguration file,<invalid host path>

Error in parsing hostconfiguration file. Probewill shutdown

The probe could not detectthe host configuration filebecause the path is invalid.

Set the a valid path to thehost configuration file for theHost property.

ProbeWatch messagesDuring normal operations, the probe generates ProbeWatch messages and sendsthem to the ObjectServer. These messages tell the ObjectServer how the probe isrunning.

The following table describes the ProbeWatch messages that the probe generates.For information about generic Netcool/OMNIbus ProbeWatch messages, see theIBM Tivoli Netcool/OMNIbus Probe and Gateway Guide.

Table 12. ProbeWatch messages

ProbeWatch message Description Triggers/causes

Error in Retry propertyvalue. Probe willshutdown

The Retry property is set toinvalid value and so theprobe is shutting down.

An invalid value was set forthe Retry property.

Probe has lost connectionto CORBA interface, errorexternal to CORBAinterface

The probe has lost theconnection to the CORBAinterface.

The connection between theSpectroSERVER and the CASpectrum EMS is down.

Probe has lost connectionto CORBA interface. Errorinternal to CORBAinterface

The probe has lost theconnection to the CORBAinterface.

The connection between theprobe and the server is downdue to incorrect probe settingsor an inactiveSpectroSERVER.

New successful connectionto the CORBA interface,connected to the PrimarySpectroSERVER

The probe connected to theprimary SpectroSERVER.

The connection to the primarySpectroSERVER wassuccessful.

New successful connectionto the CORBA interface,connected to theSecondary SpectroSERVER

The probe connected to thesecondary SpectroSERVER.

The primary SpectroSERVERhas failed, and the probe hasconnected to the secondarySpectroSERVER.


Table 12. ProbeWatch messages (continued)


Start resync forspectroServerName

The probe started theresynchronization processwith the Spectrum serverindicated.

Either a resynchronizationwas requested by a CLIcommand, or one wasinitiated automaticallyfollowing the elapsing of aresynchronization interval, orthe failover of the Spectrumserver.

Complete resync forspectroServerName

The probe's resynchronizationwith the Spectrum serverindicated has completed.

The resynchronization withthe Spectrum server indicatedcompleted successfully.

Probe successfullyconnected to <targethost>

The probe started and isrunning successfully.

The probe process was startedby the operator.

Running ... The probe started and isrunning successfully.

The probe process was startedby the operator.

Probe is shutting downGoing Down ...

The probe is shutting down. The system has beenrequested to shut down theprobe because the probeprocess was terminatedmanually by the operator.

<target host> head isshutting down, removefrom active host list

CA Spectrum EMS is shuttingdown after the probeconnected to SpectroSERVER.This ProbeWatch will beshown when the retry valuefor the probe is set to 0.

CA Spectrum EMS that isconnecting to the probe isshutting down. This is eitherbecause the Spectrum servicehas been stopped manuallyby operator or has aborted.

Error in spectrum alarmseverity values. Probewill shutdown.

Invalid values have been setfor either theMaxSpectrumSeverity propertyor the MinSpectrumSeverityproperty .

Either the value set for theMinSpectrumSeverity propertyis higher than that set for theMaxSpectrumSeverity, or thevalue set for eitherMinSpectrumSeverity orMaxSpectrumSeverity is notbetween 0 and 6.

Received connection from127.0.0.1

The probe connected tocommand port session and isready to receive CLIcommands.

The operator managed tosuccessfully telnet to thecommand port.

Failed to open listeningsocket: java.lang.IllegalArgumentException: Portvalue out of range:<invalid value>

The probe failed to listen tothe command port socket.

The CommandPort property isset to an invalid value. Eitherthe value is not an integer, orit is set to a negative value.

Failed to open listeningsocket:java.net.BindException:Address already in use

The probe failed to listen tothe command port socket.

The CommandPort property isset to a value that is notalready in use.


Table 12. ProbeWatch messages (continued)


Error in parsing hostconfiguration file. Probewill shutdown

The probe failed to parse thehost configuration file.

Either there are missingvalues in the hostconfiguration file (for examplea missing SpectroServer host),duplicate entries were foundin the host configuration filefor at least one of thefollowing properties:AlarmAttributes,TimeStampFile,FetchEventFormatFields,FetchEventString,EventFormatFile,ProbCauseLookupFile,ResyncInterval,ResyncSQLCmd, or the path tothe host configuration filespecified for the Hostproperty is an invalid path.

Running the probeThe probe is run from the command line.

To start the probe, use the following command:

$OMNIHOME/probes/nco_p_spectrum_corba_v9

TroubleshootingVarious issues arise as users work with the probe. Troubleshooting information isprovided to help you diagnose and resolve such issues.

Fails to Connect

The Probe for CA Spectrum V9 (CORBA) fails to connect to the SpectroSERVERwhen configured with a host file. You may receive the following message whenconfiguring a host file:07/01/10 10:36:39: Debug: [1 server1] Connecting to SpectroServer07/01/10 10:36:39: Debug: CommandPort-> 777807/01/10 10:36:39: Debug: CommandPortLimit-> 1007/01/10 10:36:39: Debug: [Command Port] Waiting for connections07/01/10 10:36:42: Debug: [1 server1] Exception =org.omg.CORBA.OBJECT_NOT_EXIST: vmcid: 0x0 minor code: 0 completed: No07/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 theSpectroSERVER. A possible reason is that the probe cannot find the location of theSpectroSERVER specified in the spectrum_corba_v9_host.xml host file.

To resolve this problem, set the domain property in host file to the SpectroServerhost FQDN which is reachable from probe host.


For the information about the required format of the connection information in thehost file, see “Using the host configuration file” on page 5.

Known issuesAt the time of release, several known issues were reported that you should beaware of when running the probe.

Using timestamp files

The TimeStampFile property in the host configuration file enables you to specify afile in which the probe can log the timestamp of the last alarm it processed. Whenthe AllAlarmsOnRestart property is disabled, and a timestamp file is specified, thealarms received by the probe are filtered according to this timestamp.

The timestamp filter works in the following way. Assume that the probe shutsdown and logs timestamp T to the timestamp file. Then the probe starts up againand sets up two timestamp filters, TS1 and TS2. The value of the TS1 filter is equalto the value of the last logged timestamp minus 48 hours (TS1 = T - 48 hours). Thevalue 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 werecleared or updated while the SpectroSERVER was connected to the probe, to beforwarded 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 frombeing resynchronized.

The issue arises because, although the probe will accept updates to alarms that werecreated after TS1, it cannot logically accept updates made in the SpectroSERVER toolder alarms that it has already filtered out. To avoid this issue, do not use theTimeStampFile property in the host configuration file.

Error using the UpdateEventList command

The UpdateEventList alarmID eventIDList spectrumName CLI command enablesyou to update the event list of an alarm by specifying the alarm identifier, theevent list identifier and the SpectroSERVER host name.

This command feature is currently unavailable because when issued to theSpectroSERVER, the command produces an exception with an error ofTYPE_RESTRICTION at the Spectrum API level.

SpectroSERVER automatically disconnecting the probe

When the total time taken by archive manager to retrieve events exceeds the timeset in the MAX_EVENT_ID_REQUEST_TIMEOUT field on SpectroSERVER, SpectroSERVERwill disconnect the probe, but will not inform the probe that it has beendisconnected. The probe will fail to retrieve any further events fromSpectroSERVER 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 probeis running on libraries from an older version, for example Spectrum version 9.2.



Appendix. Notices and Trademarks

This appendix contains the following sections:v Noticesv Trademarks

NoticesThis 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 inother countries. Consult your local IBM representative for information on theproducts and services currently available in your area. Any reference to an IBMproduct, program, or service is not intended to state or imply that only that IBMproduct, program, or service may be used. Any functionally equivalent product,program, or service that does not infringe any IBM intellectual property right maybe used instead. However, it is the user's responsibility to evaluate and verify theoperation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matterdescribed in this document. The furnishing of this document does not grant youany license to these patents. You can send license inquiries, in writing, to:

IBM Director of LicensingIBM CorporationNorth Castle DriveArmonk, NY 10504-1785U.S.A.

For license inquiries regarding double-byte (DBCS) information, contact the IBMIntellectual Property Department in your country or send inquiries, in writing, to:

IBM World Trade Asia CorporationLicensing 2-31 Roppongi 3-chome, Minato-kuTokyo 106-0032, Japan

The following paragraph does not apply to the United Kingdom or any othercountry where such provisions are inconsistent with local law:INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THISPUBLICATION “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHEREXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIEDWARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESSFOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express orimplied warranties in certain transactions, therefore, this statement may not applyto you.

This information could include technical inaccuracies or typographical errors.Changes are periodically made to the information herein; these changes will beincorporated in new editions of the publication. IBM may make improvementsand/or changes in the product(s) and/or the program(s) described in thispublication at any time without notice.

© Copyright IBM Corp. 2010, 2015 37

Any references in this information to non-IBM Web sites are provided forconvenience only and do not in any manner serve as an endorsement of those Websites. The materials at those Web sites are not part of the materials for this IBMproduct 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 itbelieves appropriate without incurring any obligation to you.

Licensees of this program who want to have information about it for the purposeof enabling: (i) the exchange of information between independently createdprograms and other programs (including this one) and (ii) the mutual use of theinformation which has been exchanged, should contact:

IBM CorporationSoftware Interoperability Coordinator, Department 49XA3605 Highway 52 NRochester, MN 55901U.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 materialavailable for it are provided by IBM under terms of the IBM Customer Agreement,IBM International Program License Agreement, or any equivalent agreementbetween us.

Any performance data contained herein was determined in a controlledenvironment. Therefore, the results obtained in other operating environments mayvary significantly. Some measurements may have been made on development-levelsystems and there is no guarantee that these measurements will be the same ongenerally available systems. Furthermore, some measurements may have beenestimated through extrapolation. Actual results may vary. Users of this documentshould verify the applicable data for their specific environment.

Information concerning non-IBM products was obtained from the suppliers ofthose products, their published announcements or other publicly available sources.IBM has not tested those products and cannot confirm the accuracy ofperformance, compatibility or any other claims related to non-IBM products.Questions on the capabilities of non-IBM products should be addressed to thesuppliers of those products.

All statements regarding IBM's future direction or intent are subject to change orwithdrawal without notice, and represent goals and objectives only.

All IBM prices shown are IBM's suggested retail prices, are current and are subjectto change without notice. Dealer prices may vary.

This information is for planning purposes only. The information herein is subject tochange before the products described become available.

This information contains examples of data and reports used in daily businessoperations. To illustrate them as completely as possible, the examples include thenames of individuals, companies, brands, and products. All of these names arefictitious and any similarity to the names and addresses used by an actual businessenterprise is entirely coincidental.


COPYRIGHT LICENSE:

This information contains sample application programs in source language, whichillustrate programming techniques on various operating platforms. You may copy,modify, and distribute these sample programs in any form without payment toIBM, for the purposes of developing, using, marketing or distributing applicationprograms conforming to the application programming interface for the operatingplatform for which the sample programs are written. These examples have notbeen thoroughly tested under all conditions. IBM, therefore, cannot guarantee orimply reliability, serviceability, or function of these programs.

Each copy or any portion of these sample programs or any derivative work, mustinclude 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 rightsreserved.

If you are viewing this information softcopy, the photographs and colorillustrations may not appear.

TrademarksIBM, the IBM logo, ibm.com, AIX, Tivoli, zSeries, and Netcool are trademarks ofInternational Business Machines Corporation in the United States, other countries,or both.

Adobe, Acrobat, Portable Document Format (PDF), PostScript, and all Adobe-basedtrademarks are either registered trademarks or trademarks of Adobe SystemsIncorporated in the United States, other countries, or both.

Intel, Intel Inside (logos), MMX, and Pentium are trademarks of Intel Corporationin the United States, other countries, or both.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks ofMicrosoft Corporation in the United States, other countries, or both.

Java™ and all Java-based trademarks are trademarks of Sun Microsystems, Inc. inthe United States, other countries, or both.

Linux is a trademark of Linus Torvalds in the United States, other countries, orboth.

UNIX is a registered trademark of The Open Group in the United States and othercountries.

Appendix. Notices and Trademarks 39


��

Printed in USA

SC27-2722-08

Documents

IBM Tivoli Netcool/OMNIbus Probe for CA Spectrum V9 … … · Installing Spectrum utilities .....3 ... Where Tivoli Netcool/OMNIbus files are identified as located within an arch