Table of Contents

Introduction

Installation

Defects Fixed in this Release

Documentation Changes

Product Notes

Introduction

This document describes how to install IBM Tivoli NetView Version 7.1.3 Fix Pack 2 and the code, documentation, and functional changes that result. This fix pack is only for IBM Tivoli NetView for UNIX/Windows Version 7.1.3, and will not install or work on any other version of IBM Tivoli NetView.

This fix pack supercedes IBM Tivoli NetView 7.1.3 Fix Pack 1. It contains all of the modifications and corrections contained in that fix pack as well as changes and corrections to IBM Tivoli NetView 7.1.3 since Fix Pack 1 was released.

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

Once this fix pack has been installed on a platform, this readme file can be found at /usr/OV/service/V713/FixPack2/readme.html on a UNIX platform, or \usr\ov\service\V713\FixPack2\readme.html on a Windows platform.

IBM Tivoli NetView V7.1.3 Fix Pack 2 can be ordered on CDROM media through standard IBM channels by requesting either PTF U496817 (UNIX) or PTF XR23259 (Windows).

Installation

Installation Requirements

In order to install IBM Tivoli NetView Fix Pack 2 on a system, the following requirements must be met:

1. The customer must download the appropriate package for that platform, and make it available to the system on which it is to be installed.

2. The customer must be logged into the system with the same user account that performed the original NetView V7.1.3 installation (the root account on UNIX).

3. The system must already contain an IBM Tivoli NetView Version 7.1.3 installation.

4. The system on which the Fix Pack is to be installed must have enough free space to (1) install the fix pack, and (2) 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 for update NetView installation remains in use until either the fix pack is backed out or a new version of NetView is installed.

   Customer installations that contain a previous IBM Tivoli NetView fix pack may recover most of the space used by that fix pack by deleting the /usr/OV/service/V713/FixPackX directory on UNIX, or the \usr\ov\service\v713\fixpackX directory on Windows prior to installing this fix pack. Please note, however, that doing so removes the ability to back out the previous fix pack, as well as the ability to install code fixes that require the previous fix pack in order to install.

   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	385 Mb	240 Mb
   SunOS Solaris	330 Mb	215 Mb
   Linux Intel	345 Mb	220 Mb
   Linux 390	395 Mb	240 Mb
   Windows	97 Mb	54 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/V713/FixPack2 (on UNIX) or \usr\ov\service\V713\FixPack2 (on Windows) directory. However, doing so removes the ability to back out the fix pack. Do not delete the FixPack2 subdirectory itself, since 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. Customers using the Secure Socket Layer (SSL) protocol either need to (1) turn off SSL via the NetView serversetup application, or (2) copy the file /usr/OV/www/webapps/netview/WEB-INF/web.xml (on UNIX) or \usr\ov\www\webapps\netview\WEB-INF\web.xml (on Windows) to a temporary location.

2. If installing the fix pack on a NetView client, insure that the client is disconnected from the NetView server by running the Client Setup application, selecting Configure -> Remove Server, entering the NetView server name in the "Server Hostname:" field and applying.

3. Place the package into a local subdirectory on the platform on which the fix pack is to be installed and change directory to that subdirectory.

4. Extract the installation script:

   • on a UNIX platform, type zcat FixPack2.{Platform}.V713.tar.Z | tar -xvf - install
   • on a Windows platform, type FixPack2.Win32.V713.exe

5. Execute the installation script:

   • on a UNIX platform, type ./install
   • on a Windows platform, to install the NetView native Server, type install
   • on a Windows platform, to install the NetView native Client, type install noversioncheck
   In the event the installation is unable to complete, the install script will report the problem with enough information to correct it and allow the user to rerun the installation.

6. Restart the NetView daemons by either rebooting the machine, 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 prior to restarting the NetView daemons.

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

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

9. Customers wishing to resume the use of the Secure Socket Layer (SSL) protocol either need to (1) turn on SSL via the NetView serversetup application, or (2) replace the saved copy of web.xml to the /usr/OV/www/webapps/netview/WEB-INF directory (on UNIX) or \usr\ov\www\webapps\netview\WEB-INF (on Windows).

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/V713/FixPack2 (on UNIX) or the \usr\ov\service\V713\FixPack2 (on Windows) subdirectory. If a customer wishes to, he may uninstall the fix pack by running the backout script contained in that directory in place of steps 3-5 of the installation instructions above, and the system will return to the state that it was in prior to the fix pack installation.

On Solaris 2.9, the backout process occasionally stalls for no apparent reason. The backout script can be aborted, a new terminal window opened, and the backout script rerun with no adverse impact on the NetView installation. In order to help diagnose this type of situation, a log can be created for the backout script by adding set -x as the first line of the Backout subroutine within the script, and then running the command with standard error directed to a file, e.g. ./backout 2>backout.log.

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

Defects Fixed in this Release

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

The following customer-reported problems were fixed in IBM Tivoli NetView V7.1.3 FixPack 1:

Documentation Changes

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

   The Scope feature of the NetView Web Console requires not only the default map open - with the name "default" - but this map must 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 a user using such an account would really be viewing a read-write map, he/she would not be able to modify the map in any way and therefore it would effectively be read-only.

2. The IBM Tivoli NetView Release Notes for NetView V7.1.3 and V7.1.4 reference, in the Linux Software Prerequisites section, a pdksh RPM on the NetView for Linux 390 CD, but refer to the package as pdksh-5.2.14-248.s390.rpm. In fact, the RPM shipped on the CD is pdksh-5.2.14-197.s390.rpm, and the release notes should reflect this.

3. 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

   /usr/OV/bin/atctl v info

   is incorrect. The command should be

   /usr/OV/bin/atctl -v info

4. In the IBM Tivoli NetView for Window 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.

5. Note 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".

   A note on specifying time values:

   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.

6. 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.

7. 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.

8. 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 256MB of RAM. For a production system, the recommendation is 800 MHz with at least 256 MB.

9. The Tivoli Enterprise Data Warehouse Integration Pack for NetView V1.1.0 guide needs to be updated to include requirements for a distributed TEDW 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 (TEDW) 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.

10. 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.

11. 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 selecting Tools->MIB->Collect Data, selecting New, choosing a MIB to collect on and clicking on NEXT. This panel has the field "then send Trap Number"; choose Help on that field.

12. 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.

Product Notes

1. Ever 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. These are, in order, the trap severity, the trap source character, and the trap category, 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, and so on), but even this was cumbersome for the user. In 7.1.3, an additional enhancement to this feature was made. These additional varbinds are now exported into variables called "NVSEV", "NVSRC", and "NVCAT" to make using them easier to reference.

2. 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, we recommend that customers who wish to retain the Framework in their environment 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 customers should backup the NetView installation via the backup function in serversetup, remove both the Tivoli Framework and NetView from their system, and install NetView from the command line using the update option.

3. The syntax of the mib2trap command has changed. This can be seen by issuing the command "mib2trap -?" from the command line. The mib2trap command will now produce 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]

   Users who wish to continue using the old base class, Nvserverd_Event, may do so by specifying it as the fourth (optional) parameter, in this way:

   mib2trap mib_file addtrap_output_file baroc_file Nvserverd_Event

   since the command will now support any user-defined base event class.

4. 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.

5. The origin field of an event sent to TEC by the internal TEC adapter in nvserverd will always contain the IP address of the NetView machine. The adapter_host field will contain either the fully-qualified domain name of the NetView machine or that same IP Address as the origin field. Shortnames will no longer be used for the adapter host field in order to facilitate event responses and forwarding at the TEC server.

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

7. 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 was changed to treat symbols with unreachable status as marginal. If one or more, but not all, symbols in a submap are unreachable then those symbols will be treated as marginal to indicate that at least one symbol in that submap has a problem. The NetView GUI can be instructed 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.

8. Currently, the NetView Web Console does not support the connections popup menu option or the meta-connection drill down.

9. 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 install of NetView, and the current copy on the user's system is not updated by this fix pack. Therefore, users who wish to have this change before the next release will have to manually insert this change into the /etc/snmp/conf/mgragentd.rsrc file.

10. As of NetView V7.1.2, the TEC (Tivoli Event Console) class definitions used by NetView were upgraded. The previous TEC Event class definitions used by NetView are no longer supported, and users are expected to use the new class definitions since future migration will not support the old class definitions.

11. Depending on the system configuration and level of operating system, some customers may need to upgrade to a newer version of the JRE once a NetView V7.1.3 Fix Pack is installed. If the NetView Web Console cores after a fix pack has been installed, customers can request the JRE upgrade from IBM Tivoli Customer Support by asking for fix IY45265 for the appropriate platforms and installing it on their systems.

12. When attempting 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 the message, you can use the following script to process the files. It 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

13. 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.

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

15. APAR IY48379 described a problem where the ovstop command does not always stop the tdw daemon. A modified tdwdaemon.lrf was created and included in this fix pack that corrects the problem. To install the correction, the tdwdaemon.lrf file in the customer installation must be replaced using the following steps:
    1. Stop the tdw daemon (ovstop tdwdaemon).
    2. Delete the tdw daemon entry from the ovsuf file (ovdelobj tdwdaemon.lrf).
    3. Rename the current tdwdaemon.lrf file
       (On UNIX, cp /usr/OV/lrf/tdwdaemon.lrf /usr/OV/lrf/tdwdaemon.save)
       (On Windows, copy \usr\ov\lrf\tdwdaemon.lrf \usr\ov\lrf\tdwdaemon.save).
    4. Copy the new tdwdaemon.lrf on top the original lrf file
       (On UNIX, cp /usr/OV/newconfig/IBMVA-RUN/tdwdaemon.lrf /usr/OV/lrf/tdwdaemon.lrf)
       (On Windows, copy \usr\ov\newconfig\ibmva-run\tdwdaemon.lrf \usr\ov\lrf\tdwdaemon.lrf).
    5. Add the tdw daemon to the ovsuf file (ovaddobj tdwdaemon.lrf).
    6. Restart the tdw daemon (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.

16. 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 on the SNMP menu item to bring up the SNMP selection window.
    2. Click on 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.

17. 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 (i.e. 5.25-30.2.8 or 3.5.*.*). Wild cards are not allowed in gateway names (myrouter.company.com).

    Example gateway entries:

    SalesOffices gateway1
    SalesOffices 22.84.5.2
    SalesOffices 55.21.*.4
    SalesOffices 22.*.*.*
    SalesOffices 22.*.5-10.20-33

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

18. A modified netmon.seed file for APAR IY47145 has been shipped with this fix pack which 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.

19. 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, simply click on the right side of the terminal window, hold it, move the cursor further to the right, and let go. Any man commands executed after this is done will be correctly displayed.

20. 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, the router with the admin down interfaces should be specified to use SnmpStatus poll instead of ICMP poll in the netmon seed file.

21. 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, click on My Computer -> Manage -> Services and Applications -> Services, right-click on Messenger, then click on Properties. Click on the Startup type's down arrow and select Automatic. Click OK, and then right click on Messenger and select Start.

22. 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) will be reported.

23. 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.

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

25. 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), simply type the 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.