IBM Tivoli NetView V7.1.4 Fix Pack 1 Readme

Date: April 16, 2004

Name: 7.1.4-NVD-FP001

Component: IBM Tivoli NetView Version 7.1.4

PTF Number: U497654 (UNIX) or XR23260 (Windows)

Note: Before using this information and the product it supports, read the information in the "Notices" section at the end of this document.

About this fix pack

This section provides general information about this fix pack. It is strongly recommended that you read this entire document before you install this fix pack.

Fix pack contents

This fix pack consists of five packages, one each for RS6000 AIX®, SUN SPARC Solaris, Linux Intel™, Linux 390, and Microsoft® Windows®. You need to use the appropriate package on each platform on which an IBM® Tivoli® NetView® native server or client has been installed.

This fix pack also contains a set of corrections for the NetView ETL code used by and contained within the Tivoli Data Warehouse. In order to apply the corrections to the NetView ETL code within the Tivoli Data Warehouse, see the nvTDW_FP1.txt file associated with this fix pack.

Patches superseded by this fix pack

None. There are no patches superseded by this fix pack.

Supported operating systems

• AIX:
  • V4.3.3 (Maintenance Level 09)
  • V5.1 (Maintenance Level 01)
  • V5.2
• Solaris:
  • V2.8 (with all Sun-required patches)
  • V2.9 (with all Sun-required patches)
• Linux Intel:
  • Red Hat Version 7.2 (2.4.7-10 kernel)
  • Red Hat Advanced Server Version 2.1
  • SuSE Version 7.2 (2.4.4-4GB kernel)
  • SuSE Version 8.0 (2.4.4-4GB kernel)
  • United Linux Version 1.0
• Linux for zSeries® (32 bit systems only):
  • Red Hat Version 7.2
  • SuSE Linux Enterprise Server 7.2 For S/390® and zSeries (SLES 7)
  • SuSE Linux Enterprise Server 8.0 For S/390 and zSeries (SLES 8)
  • United Linux Version 1.0
• Windows:
  • Windows 2000 Server
  • Windows 2000 Advanced Server
  • Windows 2003 Server
  • Windows XP Professional

Please note that the following operating systems are not supported in this release:

• Windows NT®
• Windows 2000 Workstation
• Windows XP Home Edition

New in this fix pack

The following items are new to this fix pack.

A modified tdwdaemon.lrf

APAR IY48379 described a problem where the ovstop command does not always stop the tdwdaemon. A modified tdwdaemon.lrf was created and included in this fix pack that corrects the problem. To install this correction on a UNIX platform, the tdwdaemon.lrf file in the customer installation must be replaced using the following steps:

1. Stop the tdwdaemon (ovstop tdwdaemon).
2. Delete the tdwdaemon entry from the ovsuf file (ovdelobj tdwdaemon.lrf).
3. Rename the current tdwdaemon.lrf file (cp /usr/OV/lrf/tdwdaemon.lrf /usr/OV/lrf/tdwdaemon.save).
4. Copy the new tdwdaemon.lrf on top the original lrf file (cp /usr/OV/newconfig/IBMVA-RUN/tdwdaemon.lrf /usr/OV/lrf/tdwdaemon.lrf).
5. Add the tdwdaemon to the ovsuf file (ovaddobj tdwdaemon.lrf).
6. Restart the tdwdaemon (ovstart tdwdaemon).

To back this correction out, follow the above directions, replacing the two copy steps with a single copy of the saved lrf file back to its original location.

Enhanced Location Sensitive Topology functionality

The Location Sensitive Topology functionality (location.conf) has been enhanced to allow IP address ranges and wild cards in gateway entries. Ranges or wild cards may be used in any part of the gateway IP address. Wild cards may not be used in a gateway name.

The following change (which should be applied to the comment section of the location.conf file manually) describes the changes to the gateway name or address field:

The format of a gateway entry is:

<location name> <gateway name or address>

where location name is the name of the location under which this gateway should be placed, and gateway name or address is the name of the gateway or the IP address of one of its interfaces in dot-notated format. Wild cards and ranges are allowed in gateway IP addresses (meaning, 5.25-30.2.8 or 3.5.*.*). Wild cards are not allowed in gateway names (myrouter.company.com).

Example gateway entries:

If a gateway matches more than one gateway entry, one entry is arbitrarily chosen. To help in resolving overlapping gateway entries, warning messages about gateway interfaces that match more than one entry are displayed in the location.log file. These are only warning messages; they do not indicate any problem with the gateway/router placement.

A modified netmon.seed file

A modified netmon.seed file for APAR IY47145 is shipped with this fix pack. This file documents that in order to explicitly discover a node and make it SNMP-managed there must be two entries in the netmon.seed file: one to discover the node and the second for SNMP management. This fix pack places the modified netmon.seed file in the /usr/OV/newconfig/IBMVA-RUN/ subdirectory on UNIX, and the \usr\ov\newconfig\netmon subdirectory on Windows.

Maximum alternate community names

By default, up to seven alternate community names can be specified in communityNames.conf file. You can modify the maximum number of alternative community names allowed by setting the environment variable MaximumCommunityNames in the netmon.conf file to a value between 0 and 100.

A new trapd.conf file

A new trapd.conf file is shipped with this fix pack. This trapd.conf file no longer accidentally truncates several values in the HPCIFxxx traps in the trapd.conf file for NetView for Windows. This file can be found in \usr\ov\newconfig\ovsnmp-run\trapd.conf. If you want to use this file and you have not customized \usr\ov\conf\trapd.conf, you can use it to replace the one found in \usr\ov\conf\trapd.conf. If, however, the original file has been modified, you must merge the two files.

Enabling secondary IP address retrieval

If you are having trouble finding services when using servmon to do ITM queries, you may need to enable secondary IP address retrieval for servmon initialization.

Enable secondary IP address retrieval for servmon during servmon initialization by adding a line in servmon.conf consisting of just SECONDARY_IPADDRS. By default, secondary IP addresses are not retrieved during servmon initialization.

However, enabling this function is very performance intensive. It would be best to allow NetView to stabilize before making the change. Then, once NetView is running, complete the following:

1. Stop servmon, using ovstop servmon.
2. Modify the servmon.conf file.
3. restart servmon using ovstart servmon.

Fix pack notes

• Since NetView for UNIX Version 5.1, the Action node ruleset has added three additional variables to the end of every trap passing through it (in order):

  • The trap severity
  • The trap source character
  • The trap category
  These are obtained from trapd.conf, in order to make these items available to the user's scripts.

  In NetView 6.0.3, a new variable, NVATTR_COUNT was added to tell the user how many variables the trap now contains, and it permitted easier reference of these last three:

  • the NVATTR_n variable, where n = NVATTR_COUNT-1 was the trap category
  • the NVATTR_n variable, where n = NVATTR_COUNT-2 was the trap source
  • the NVATTR_n variable, where n = NVATTR_COUNT-3 was the trap severity

  In NetView 7.1.3, these additional varbinds are now exported into three, easy to reference variables:

  • NVSEV
  • NVSRC
  • NVCAT

• The syntax of the mib2trap command has changed. This can be seen by issuing the command mib2trap -? from the command line. The mib2trap command produces the optional baroc file with TEC_ITS_BASE as the base event class by default. The general syntax is given by:

  mib2trap mib_file addtrap_output_file [baroc_file] [base_event_class_name]

  If you want to continue using the old base class, Nvserverd_Event, you can do so by specifying it as the fourth (optional) parameter, in the following way because the command now supports any user-defined base event class.:

  mib2trap mib_file addtrap_output_file baroc_file Nvserverd_Event

• The origin field of an event sent to Tivoli Enterprise Console® by the internal Tivoli Enterprise Console adapter in nvserverd always contains the IP address of the NetView server. The adapter_host field contains either the fully qualified domain name of the NetView server or the same IP Address as the origin field. Short names can no longer be used for the adapter host field in order to facilitate event responses and forwarding at the Tivoli Enterprise Console server.

• The Java™ MIB Loader no longer puts MIBs that failed to load into the list of loaded MIBs. It also now warns you if loading a MIB is skipped and reminds you that, for the Java MIB loader, the only valid extensions for MIB files are .mib, .my, and .def.

• Prior to NetView 7.1.3, unreachable symbols in a submap were ignored for the purpose of calculating the compound status of the parent symbol. In NetView 7.1.3, the default compound propagation treats symbols with unreachable status as marginal. If one or more but not all symbols in a submap are unreachable, those symbols are treated as marginal to indicate that at least one symbol in that submap has a problem. The NetView GUI can be configured to ignore unreachable symbols for compound propagation by setting the environment variable OVW_NO_UNREACHABLE_PROPAGATION=1 before starting the NetView GUI. If all symbols in a submap are unreachable, then unreachable status is propagated regardless of the variable setting.

• The file installed on Solaris as /etc/snmp/conf/mgragentd.rsrc has been changed so that the command field reads just 'command = "" ' (a null command entry) from its former value, 'command = /usr/bin/echo mgragentd registered with snmpdx'. The purpose of this change is to avoid any possibility of a defunct process being created when snmpdx is restarted. However, the file is only installed once, on the initial installation of NetView, and the current copy on your system is not updated by this fix pack. Therefore, if you wish to have this change before the next release, you must manually insert this change into the /etc/snmp/conf/mgragentd.rsrc file.

• As of NetView V7.1.2, the Tivoli Enterprise Console class definitions used by NetView were upgraded. The previous Tivoli Enterprise Console Event class definitions used by NetView are no longer supported, and you are expected to use the new class definitions because future migration will not support the old class definitions.

• Depending on your system configuration and level of operating system, you may need to upgrade to a newer version of the JRE once a NetView V7.1.4 Fix Pack is installed. If the NetView Web Console causes a core dump after a fix pack has been installed, you can request the JRE upgrade from IBM Tivoli Customer Support by asking for fix IY45265 for the appropriate platforms and installing it on your systems.

• If the snmpCollect daemon is deferring more collections than seem appropriate, the problem may be because the default wait time of 3 seconds may not be enough time for the snmpCollect daemon to receive the reply.

  To allow more time for collections, do the following:

  1. Select the Options entry on the tool bar and click the SNMP menu item to bring up the SNMP selection window.
  2. Click the node in the list having the deferred collections, and click the Properties button.
  3. Either increase the values in or replace the blanks with initial values in the "Retry SNMP Requests Every" and "Seconds for a Maximum of __ Tries" fields.

• When NetView security is enabled, the Tivoli NetView server's fully qualified host name must appear as the first host name for the server's entry in the server's /etc/hosts file. Otherwise, the NetView client's credentials cannot be verified, and when a message is sent from the server in the Security Administration dialogue, Error(35) is reported.

• When using a Tivoli NetView native server/client configuration on UNIX, the native NetView client must be stopped and restarted if the platform on which the NetView server resides is rebooted. The reboot and subsequent restart of the NetView server causes the loss of session information regarding the native client, and the client must be stopped and restarted to restore that information.

• The wildcard range in the seed file limits the discovery to be in the range for all managed networks. It does not force netmon to discover any new node in that range, and it does not force netmon to create a new network. However, for the seeded entry (single IP or hostname), netmon always attempts to discover the entry and to create a network if it is needed.

• To enforce the discovery of an "island-network" (that is, a network with no router connection to NetView server), you must add one explicit (seeded) node entry in that network into the seed file to force the node discovery and network creation. In addition, to expand discovery on other devices in that network, you must ensure the seeded entry is snmp enabled.

• In the SNMP Configuration Panel of the xnmsnmpconf application, the field Retry Count indicates the total attempts on a ping or snmp request. The count includes the initial poll, so a value of "1" indicates one attempt should be made, a value of "2" indicates an initial attempt and one retry if it fails, etc.

• If the daily Web Server log files are taking up too much space on your system, in addition to lowering the number of days that these request logs are retained (as described in detail in the IBM Tivoli NetView 7.1.4 for UNIX Release Notes), there are several additional actions you can take:

  1. Customize the EventChannel Servlet's Query Interval:

     The Query Interval determines how often Web Consoles send a request to check whether the Web Server is still alive.

     Normally, there is no need to customize this parameter. However, if the daily servlet request logs (yyyy_mm_dd.request.log in /usr/OV/www/logs for UNIX or in \usr\ov\www\logs for Windows) are routinely much too large, you can increase the Query Interval so that fewer EventChannel query log entries are created. However, this change also increases the lag time before Web Consoles realize that the Web Server has gone down.

     This can be configured in the queryIntervalSec parameter for the EventChannel Servlet in the /usr/OV/www/webapps/netview/WEB-INF/web.xml file for UNIX or in the \usr\ov\www\webapps\netview\WEB-INF\web.xml file for Windows.

  2. Customize the EventBrowser Servlet's Client Refresh Rate:

     The Client Refresh rate determines how often Web Consoles ask the Web Server to refresh the events for the Web Consoles' event browsers.

     Normally, there is no need to customize this parameter. However, if the daily servlet request logs (yyyy_mm_dd.request.log in /usr/OV/www/logs for UNIX or in \usr\ov\www\logs for Windows) are routinely much too large, you can increase the Client Refresh rate so that fewer EventBrowser event request log entries will be created. However, this change also decreases the frequency with which the EventBrowser data is updated in the Web Consoles.

     This can be configured in the clientRefreshRate parameter for the EventBrowser Servlet in the /usr/OV/www/webapps/netview/WEB-INF/web.xml file for UNIX or in the \usr\ov\www\webapps\netview\WEB-INF\web.xml file for Windows.

  Both of these actions, as well as lowering the number of days the logs are retained, can be performed on a NetView Web Server running on either a UNIX platform or a Windows platform.

• IBM Tivoli NetView 7.1.4 requires the latest Tivoli Enterprise Console releases (3.7.1 + Fix Pack 05, 3.8 + Fix Pack 01, 3.9) if TEC-forwarding is enabled. This is due to changes in the trap parameters sent from NetView to Tivoli Enterprise Console, which is only known to the latest Tivoli Enterprise Console releases.

• When configuring a client/server system for the first time on the Solaris operating system, you might see an error message during the "Add Client Access" stage that says:

  !-> error message "Can't open /etc/dfs/sharetab" (3 times)

  -> Operation completed

  This is because the file /etc/dfs/sharetab does not exist on Solaris until created. The client setup creates the file after failing to access it, so the error message does not indicate failure.

• Neither the NetView UNIX or Windows Administrator's Guides nor the comments in itm_attributes.conf and servmon.conf correctly and clearly explain how and when servmon creates Service SmartSets.

  The servmon daemon does not automatically create Service SmartSets for service attribute entries (see both itm_attributes.conf and servmon.conf). If you would like to have a Service SmartSet, you should add an entry to servmon.conf for that service (or uncomment the commented-out line, if there is already one for that service, making any necessary changes). See servmon.conf for details. Then stop and restart the servmon daemon to pick up the changes.

  Alternatively, you can manually create the SmartSet on your own. For Windows, the status for nodes under the SmartSet submap depends only upon the service status. However, for User SmartSets, the status for nodes depends upon both the IP status and the service status. For UNIX, while Service SmartSets are supported, service icons are not created and the service status does not contribute to the overall status of a node.

  Additional Notes on servmon

  The servmon daemon does not create a Service SmartSet unless Service SmartSet, Service Label Name, and a Status Interval greater than zero are all specified on the entry in servmon.conf for the service. The servmon daemon creates the SmartSets up front. It does not wait to discover a node containing the service.

  Unlike for normal servmon services, the status of services discovered using ITM queries does NOT reflect the actual status of the service. For these services, the status only indicates whether the service was present on the node or not. It does not indicate whether the service is up or down.

APARS corrected in this fix pack

The following customer-reported problems are fixed in IBM Tivoli NetView V7.1.4 by this fix pack:

Installation and configuration

Prerequisites

In order to install IBM Tivoli NetView V7.1.4 Fix Pack 1 on a system, you must meet the following prerequisites:

• You must download the appropriate package for that platform and make it available to the system on which it is to be installed.

• You must be logged into the system with the same user account that performed the original NetView V7.1.4 installation (the root account on UNIX).

• The system must already contain an IBM Tivoli NetView Version 7.1.4 installation.

• The system on which the Fix Pack is to be installed must have enough free space to do the following

  • Install the fix pack
  • Contain the updated NetView installation
  The free space required for the first is temporary and will be returned to the system once the fix pack has been successfully installed. The space required to update NetView installation remains in use until either the fix pack is backed out or a new version of NetView is installed.

  The table below describes the amount of space required on each platform for each of the space requirements described above.

  Operating System	Space Required for Installation1	Space Required for Upgraded Product2
  RS6000 AIX	445 Mb	300 Mb
  SunOS Solaris	390 Mb	265 Mb
  Linux Intel	380 Mb	250 Mb
  Linux 390	325 Mb	205 Mb
  Windows	95 Mb	52 Mb
  1This space is required in whatever location the user will be placing the Fix Pack installation package. 2This space is required in /usr/OV on UNIX or in \usr\ov on Windows.

  Most of the space required to contain the fix pack contents in /usr/OV or \usr\ov (the space described in the second column) can be returned to the system by deleting the contents of the /usr/OV/service/V714/FixPack1 (on UNIX) or \usr\ov\service\V714\FixPack1 (on Windows) directory. However, doing so removes the ability to back out the fix pack. Do not delete the FixPack1 subdirectory itself; this subdirectory must exist in order to install fixes that have this fix pack as a prerequisite.

Installation instructions

To perform the actual installation of the package, perform the following steps:

1. If you are installing the fix pack on a NetView for UNIX client, ensure that the client is disconnected from the NetView Server by completing the following:

   1. Run the Client Setup application.
   2. Click Configure -> Remove Server.
   3. Enter the NetView server name in the Server Hostname field.
   4. Click Apply.

2. Open a new window, copy the package into a local subdirectory on the operating system on which the fix pack is to be installed, and change directory to that subdirectory.

3. Extract the installation script by doing one of the following:

   • On UNIX: type zcat Fix Pack1.{Platform}.V714.tar.Z | tar -xvf - install
   • On Windows: type Fix Pack1.Win32.V714.exe

4. Execute the installation script:

   • On UNIX type ./install
   • On Windows, to install the NetView native Server, type install
   • On Windows, to install the NetView native Client, type install noversioncheck

   When installing the fix pack on a native NetView client installation, it will report a set of errors that the files nvexportd.jar, nvexportd.lrf, and notfoundhandler.class could not be copied. These files are not necessary for a client installation, and the errors should be ignored.

   In the event that you encounter any other errors during the installation (regardless if the installation process itself reports success), complete the following:

   1. Run the backout script (ignoring any errors).
   2. Correct any problems reported during the installation.
   3. Reboot the computer (on Windows).
   4. Restart the installation from the beginning.

5. Restart the NetView daemons by either rebooting the computer, using the netview command, executing the netnmrc script on UNIX, or clicking on the NetView icon on Windows.

   If the NetView installation is using a SQL database on Windows, restart the SQL server before you restart the NetView daemons.

6. Reinstall any NetView Web Console installations from the upgraded native NetView Server installation.

   Please note that when upgrading a NetView Web Console from a NetView 7.1.4 Fix Pack 1 UNIX server, the thin version of the NetView Web Console package should be used. The full version of the NetView Web Console does not contain the fix pack updates. After the fixpack has been installed on a NetView server, the thin package must be applied on top of the full package whenever the full package is installed.

7. If you applied this fix pack to a NetView client installation, use the Client Setup application to reconnect the client to the appropriate NetView server.

Backout instructions

As a part of the fix pack installation, a copy of each file that is replaced during the installation is saved in the /usr/OV/service/V714/FixPack1 on UNIX or the \usr\ov\service\V714\FixPack1 on Windows subdirectory. If you want, you may uninstall the fix pack by running the backout script contained in that directory in place of steps 2-4 of the installation instructions above, and the system will return to the state that it was in prior to the fix pack installation.

Any NetView fixes installed on the system after the fix pack is installed must be backed out prior to backing out the fix pack.

Known defects and limitations

• Manipulation of the Korn shell history file from a .kshrc file is not recommended. Several of the installation mechanisms used by NetView expect the standard history file to be set; if it is not, the prerequisite checking and the actual NetView installation will fail.

• Some customers have encountered difficulties when using the stand-alone NetView V7 installation on a system that has the Tivoli Framework installed in a customized location. To avoid these difficulties, it is recommended that if you want to retain the Framework in their environment, you should install NetView V7.0 via the standard Tivoli Framework installation. If the Framework was installed only to support NetView and is no longer desired, then you should complete the following:

  1. Back up the NetView installation via the backup function in serversetup.
  2. Remove both the Tivoli Framework and NetView from your system.
  3. Install NetView from the command line using the update option.

• When you attempt to run nvColToSQL you may get the following error message:

  Database Server is not present or not enough disk space for log files, temp files and rollback segment or table does not exists in the database

  This message can occur if there are too many snmpCollect files to process (usually more than 500). If you get this message, you can use the following script to process the files. This script processes each file one at a time and saves the output to the log file.

  #!/bin/sh
  LOG=/usr/OV/log/nvColToSQL.log
  date > $LOG   # CREATE NEW LOG EACH TIME
  # Loop all files that do not have ! or archive in name
  for file in `ls /usr/OV/databases/snmpCollect | grep -v "\!" | grep -v "archive"`
  do
  
     nvColToSQL -f $file -m 64 >> $LOG 2>> $LOG
     RC=$?
     echo "* FILE <$file> Return Code <$RC>" >> $LOG
  
  done

• The help for SNMPV2 command on NetView for Windows V7.1, found by opening the Help menu item, selecting Help Topics, selecting the Find tab, entering

  snmp

  selecting SNMPV2 from the list and selecting Tools -> MIB -> SNMPV2 -> Load Command is no longer valid and should be ignored.

• At this time, NetView for Windows does not support SNMP V2 traps.

• Due to a quirk in the Linux operating system and the formatting of the NetView for UNIX man pages, the man pages do not display properly on Linux systems unless the Linux terminal window is greater than 80 characters long. To correct the formatting, enlarge the terminal window by using your mouse to drag the right border of the window farther to the right. Any man commands executed after this is done will be correctly displayed.

• In NetView for Windows, admin down interfaces (status USER1) can incorrectly change to a critical status when the interface is unmanaged and then managed again due to netmon's use of the ICMP ping. The admin down status of the interface won't be picked up again until next Config Check or demand poll. To prevent the admin down interfaces from being reported as critical in this situation, configure the router with the admin down interfaces to use SnmpStatus poll instead of ICMP poll in the netmon seed file.

• On Tivoli NetView for Windows on Windows 2003, attempting to send a message to a client or server (Server Setup -> Client/Server -> Send Message tab) may result in a popup with a "NO MESSAGE" error. This may be due to the Windows Messenger service not being enabled; the default is to leave the service disabled after installation on Windows 2003. To enable the Messenger Service, complete the following:

  1. Click My Computer -> Manage -> Services and Applications -> Services
  2. Right-click Messenger
  3. Click Properties.
  4. Click the Startup type's down arrow and select Automatic.
  5. Click OK.
  6. Right-click Messenger.
  7. Click Start.

• When a SmartSet submap is opened in Tivoli NetView for UNIX, collmap overrides any user-customized labels for generic symbols with the selection name for the object. A workaround is to configure and use a nongeneric symbol for the object.

• On some Linux platforms, the operating system may not properly shut down some of the threads of the Tivoli NetView for UNIX Java daemons, occasionally resulting in problems restarting the NetView daemons. A "force" option has been added to the nvKill command to shut down all rogue NetView daemons and threads and clear out the sockets, allowing the daemons to be restarted properly if this situation arises. If the NetView daemons appear to be hung (the restart has lasted longer than 10 minutes), type this command

  /usr/OV/service/nvKill -f

  at a command prompt, and then use the netnmrc or the netview command to restart the daemons in the normal manner.

• If a NetView for Windows installation was migrated from a previous version, then the NetView.exe executable will lock up when using "Find by Other Properties" under the simple tab of the find dialog due to the file /usr/ov/conf/c/finddialog.conf having a <CR><LF> changed to just a <CR>.

  To fix the problem, load the finddialog.conf file into the Windows Wordpad program and then save the file. Wordpad will change a <CR> to <CR><LF>. Note: The Windows Notepad program does not work.

• When installing and backing out the NetView for 7.1.4 Fix Pack 1 on an installation of NetView with the Japanese language pack on a Solaris system, the NetView GUI has failed to start with an error message of "Error retrieving mapdb field info: Null field value". To recover from this error when it occurs, perform the following steps:

  1. Run ovobjprint -s mapdb to get the object ID of the mapdb object.
  2. Run ovwdbdmap -d objid where objid is the object ID from step 1.
  3. Run ovstart ovwdb to restart the ovwdb daemon.
  4. Run mapadmin -i to recreate the mapdb object.

• The Windows and AIX Web Consoles do not connect to a Solaris NetView Server when double-byte characters are used in the user ID. However, a Solaris 8 web console can connect to a Solaris NetView server when double-byte characters are used in the user ID.

• When using the Japanese language pack, the default value of a map snapshot name (for example "Snapshot 1"), when used, is not displayed in the snapshot menu of the Server Setup Window. The created snapshot is displayed when you select File -> Map Snapshot -> Open. It can also be viewed when the ovmapsnap CLI command is used.

• IBM Tivoli NetView for Windows users should not implement the ruleset called setstatusandseverity.rs with the correlation daemon, nvcord. This ruleset, \usr\ov\conf\rulesets\setstatusandseverity.rs, does not work, and will put the correlation daemon into a loop, continually sending bogus status change events to the trapd daemon, until both it and the TEC adapter daemon are overwhelmed. This ruleset will be removed from the product in a future release to avoid this unfortunate situation, but it cannot be removed in a maintenance release. Users who wish to generate their own status change events are advised to do so from a bat file containing an nvsnmptrap command, as described in the NetView for Windows Programmer's Reference under the information for trapd.conf, and not to use a ruleset to do so.

Documentation updates

• Note to be added to future versions of the IBM Tivoli NetView Release Notes:

  In addition to requiring the default map open (with the name "default"), the Scope feature of the NetView Web Console requires that this map be open in read/write mode. Customers can configure web accounts to effectively view "read-only" maps by just removing the manage/unmanage and acknowledge/unacknowledge actions from the role their account is configured for. Although users using such an account would really be viewing a read-write map, they would not be able to modify the map in any way and therefore it would effectively be read-only.

• In the IBM Tivoli NetView for UNIX Release Notes, Version 7.1.4, "Supported Operating Systems," page 24, there should be a note under AIX 5.2 operating system that states that the 64-bit operating system is not currently supported because it has not been tested.

• In the IBM Tivoli NetView for UNIX Release Notes, Version 7.1.4, "Product Notes," page 49, the paragraph beginning with "The Tivoli NetView for UNIX product running on the AIX Version 5.2 operating system" is incorrect. It should read as follows:

  The Tivoli NetView for UNIX product running on the AIX Version 5.2 operating system only supports the snmpdv1 version of the snmp daemon. If the 64-bit operating system is being used, then the following procedure changes to snmpd64v1 and not snmpdv1, which is what is supported. snmpdv1 and snmpd64v1 are both SNMPv1 agents. It is impossible for snmpdv1 to run on the 64-bit kernel instead of snmpd64v1. Use the following procedure to determine which version of the daemon is running on your system and change the snmp daemon version.

• The IBM Tivoli NetView Release Notes for NetView V7.1.3 and V7.1.4, Linux Software Prerequisites section, mistakenly refers to pdksh-5.2.14-248.s390.rpm as the package to use from the NetView for Linux 390 CD.

  However, the RPM shipped on the CD is really pdksh-5.2.14-197.s390.rpm, and the release notes should reflect this.

• In the IBM Tivoli NetView for UNIX Release Notes Version 7.1.4, the command given on page 8 to confirm that the Tivoli NetView AutoTrace function is stopped is incorrect:

  /usr/OV/bin/atctl v info

  The command should be:

  /usr/OV/bin/atctl -v info

• In the IBM Tivoli NetView for Windows Beginner's Guide, a note should be added in the Shift-In/Shift-Out section (page 6):

  In order to use the Shift-In/Shift-Out mechanism, you need to run nvauth first.

• Note on specifying time values to be added to the IBM Tivoli NetView for UNIX Administrator's Guide, Chapter 5, "Correlating, Filtering, and Configuring Events", under "Types of Ruleset Nodes":

  When an event is first pulled from the event stream, it is given a time stamp to be used in determining its eligibility for processing in time-critical operations within a ruleset, such as Pass-on-Match, Reset-on-Match, or Threshold operations. This time stamp on the event remains unchanged during all subsequent processing. Determinations as to whether an event should be held or discarded are made, therefore, based upon the time that the event was received. This makes all subsequent time comparisons after the first one cumulative. Should you wish to add two time-critical operations back-to-back, you must allow for this cumulative time. Thus, for example, should you wish to code two Reset-on-Match nodes, back-to-back, within the same ruleset, and have the first one hold the event for two minutes and the second one hold it for an additional minute, then you must specify a two-minute time value in the first Reset node, but a three-minute time value in the second one, to allow for the two minutes which have already expired before the event passes to the second Reset-on-Match node. Failure to allow for this will result in unintended results, typically with events not being held as long as you intended.

• In the IBM Tivoli NetView for UNIX Administrator's Guide, Chapter 5, under "Environment Variables for Trap Data", the information given in the first product note below regarding the exported varbinds "NVSEV", "NVSRC", and "NVCAT" should be included.

• In the IBM Tivoli NetView for UNIX Version 7 Administrator's Guide, the following line near the bottom of page 164 is no longer true and needs to be removed:

  When the node name does not resolve to an IP address, the community name public is used to send the SNMP request.

• The IBM Tivoli NetView Web Console User's Guide needs to include the system requirements for Microsoft Internet Explorer for those customers who wish to run the NetView Web Console on a system using that browser. Minimum requirements are a 450 MHz machine with 256 MB of RAM. For a production system, the recommendation is 800 MHz with at least 256 MB.

• The Tivoli Enterprise Data Warehouse Integration Pack for NetView V1.1.0 Guide needs to be updated to include requirements for a distributed Tivoli Enterprise Data Warehouse environment. On page 33 of the document, item # 8 should read as follows:

  8. To be able to successfully install the NetView ETLs in a Tivoli Enterprise Data Warehouse environment which is distributed across more than one machine, the machines where the TWH_CDW and TWH_MART databases exist must also have the corresponding TEDW components installed:
     • "Central Data Warehouse" component must be installed on the server containing the TWH_CDW database.
     • "Data mart" component must be installed on the server containing the TWH_MART database.

  The rest of the note on page 34 is correct.

• The description of the Thresh command "-T" option in the NetView for Windows Programmer's Reference Manual is not entirely correct. For the "-T" option it states:

  Specifies the NetView enterprise-specific trap to be sent when the threshold is exceeded. This threshold must be an odd value in the range of 1001 to 1999, or the default value of 58720263.

  The statement should be changed to:

  Specifies the NetView enterprise-specific trap to be sent when the threshold is met. This trap number must be an odd value in the range of 1001 to 1999, or the default value of 58720263.

• The current online help for the "Send Trap Number" field when defining a MIB from which to collect data in NetView for Windows is incomplete and needs to be expanded upon. The following line should be added to the help information:

  Specifies the trap number that is to be sent when the collected data meets the value in the Threshold field. This trap number must be an odd value between 1001 to 1999, or the default value of 58720263.

  This help can be invoked by completing the following:
  1. Click Tools -> MIB -> Collect Data.
  2. Click New.
  3. Select a MIB to collect on.
  4. Click Next. This panel has the field "then send Trap Number."
  5. Select Help on that field.

• The help panel for "Agent Policy Manager Filter Panel" Throttle Settings should be updated to include the 256 byte length limitation in the Armed and Disarmed commands:

  8. Click Throttle Settings to specify the number of matching traps that are sent to the top-level manager. These values are used only if the Action field is set to throttle Traps. The Armed Command and Disarmed Command fields have a length limitation of 256 bytes.

Contacting software support

If you have a problem with any Tivoli product, refer to the following IBM Software Support Web site: http://www.ibm.com/software/sysmgmt/products/support

If you want to contact software support, see the IBM Software Support Guide at the following Web site: http://techsupport.services.ibm.com/guides/handbook.html

The guide provides information about how to contact IBM Software Support, depending on the severity of your problem, and the following information:

• Registration and eligibility
• Telephone numbers and e-mail addresses, depending on the country in which you are located
• Information you must have before contacting IBM Software Support

Notices

This information was developed for products and services offered in the U.S.A. IBM might 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 might 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 users 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 give 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:I

IBM World Trade Asia Corporation
Licensing2-31 Roppongi 3-chome, Minato-ku
Tokyo 106, 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 IMPLIEDWARRANTIES 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 might 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 products and/or the programs described in this publication at any time without notice.

Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you.

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

IBM Corporation
2Z4A/10111400 Burnet Road
Austin, TX 78758 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 document and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or any equivalent agreement between us.

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.

Trademarks

IBM, AIX, S/390, NetView, zSeries, Tivoli, and Tivoli Enterprise Console are trademarks of International Business Machines 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 and logos are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

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

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

Other company, product, and service names may be trademarks or service marks of others.