IBM Tivoli NetView V7.1.3 Fix Pack 4 Readme

Date: September 30, 2005

Name: 7.1.3-TIV-NVD-FP0004

Component: IBM Tivoli NetView Version 7.1.3

PTF Number: U804578 (UNIX) or XR23264 (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 1.1.0.3-TIV-NVD-WEP-FP0003.readme file associated with this Fix Pack. 1.1.0.3-TIV-NVD-WEP-FP0003.exe is the executable for installing these changes.

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)
• Solaris:
  • V2.7 (with all Sun-required patches)
  • 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)
• 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)
• Windows:
  • Windows NT Server Version 4 with Service Pack 5 or higher
  • Windows 2000 Server
  • Windows 2000 Advanced Server
  • Windows 2003 Server
  • Windows XP Professional

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

• Windows 2000 Professional
• Windows XP Home Edition

New in Fix Pack 04

The following items are new in IBM Tivoli NetView Fix Pack 04.

New options added to the xnmsnmpconf command

The three new options listed below have been added to xnmsnmpconf command. Note: The characters in [] are optional.

1. xnmsnmpconf -clearn[odedb]

   Removes all entries from the SNMP configuration nodedb directory.

2. xnmsnmpconf -clearw[ilddb]

   Removes all entries from the SNMP configuration wilddb directory.

3. xnmsnmpconf -clearco[lldb]

   Removes all entries from the SNMP configuration colldb directory.

For AIX and Solaris, with the three new options and the previously existing "xnmsnmpconf -clearCache", this now means the SNMP configuration database can be entirely cleared out by entering the following four commands:

1. xnmsnmpconf -clearnodedb
2. xnmsnmpconf -clearwilddb
3. xnmsnmpconf -clearcolldb
4. xnmsnmpconf -clearCache

For Linux, do NOT use the new commands to clear xnmsnmpconf's databases. On Linux, using the new options causes xnmsnmpconf to fail later with a memory fault. Unfortunately, after this failure, there is no way to fix the xnmsnmpconf database other than to reinstall IBM Tivoli NetView.

For Linux, xnmsnmpconf's databases can only be cleared by using xnmsnmpconf and deleting each node one at a time.

New options added to the nvmaputil.sh command

Two new options have been added to the nvmaputil.sh script that permit managing and unmanageing networks from the command line. The format of the new options are:

nvmaputil.sh --manage-network <IP Address 1> ... <IP Address N>

nvmaputil.sh --unmanage-network <IP Address 1> ... <IP Address N>

A new netnmrc file

For UNIX, a new netnmrc file is shipped with this fix pack. Changes to netnmrc fix problems related to APAR IY71793 with correctly starting up the X Virutal Frame Buffer software.

In order to place this fix in your NetView for UNIX 7.1.3 server implementation, copy the new file from /usr/OV/newconfig/OVMIN/netnmrc to /etc/netnmrc (for AIX) or /etc/init.d/netnmrc (for other UNIX Platforms).

A new trapd.conf file

For UNIX, a new trapd.conf file is shipped with this fix pack. Changes to trapd.conf fix problems related to APAR IY57432 with sending interface lists to the Tivoli Enterprise Console on events, as well problems related to APAR IY52871 with launching the MIB browser or Sort events from Options -> Additional Actions in the Events Window in the Control Desk.

If trapd.conf in /usr/OV/conf/C (not the obsolete trapd.conf file in /usr/OV/conf) has not been customized, simply replace it with the new trapd.conf from /usr/OV/newconfig/OVSNMP-RUN. If, however, the original trapd.conf has been modified, manually merge the changes into the original file.

Note: See the New in Fix Pack 03 section for information on the Windows trapd.conf file.

Changes to trapd.conf for launching the MIB browser on Linux

As mentioned in the A new trapd.conf file section above, the new trapd.conf shipped with this fix pack fixes the problem described by APAR IY52871 with launching the MIB browser from the Events Window on Linux.

If the original trapd.conf has been modified, manually add the changes in the new trapd.conf into the original trapd.conf file. Otherwise, simply use the new trapd.conf.

The suggested method is to use xnmtrap to edit the trapd.conf file because doing so causes trapd to automatically reload it when you are finished. You must make the edit as root.

1. Start xnmtrap from a command line: /usr/OV/bin/xnmtrap
2. Click Configure Additional Actions.
3. Select Browse MIB, which fills in the Configure Additional Actions for Operator panel.
4. Change the command shown in the command box by adding a space and a quotation mark at the end. In other words, change it from this:

   /usr/OV/bin/xnmbrowser -node "`awk '{if (NR==1)print $10}'`

   to this:

   /usr/OV/bin/xnmbrowser -node "`awk '{if (NR==1)print $10}'` "

5. Click OK at the bottom of the Configure Additional Actions for Operator panel.
6. Click OK to exit xnmtrap.

Note that you may make this change using another editor also. Locate the line that reads:

ACTION 0 "Browse MIB" /usr/OV/bin/xnmbrowser -node "`awk '{if (NR==1)print $10}'`

ACTION 0 "Browse MIB" /usr/OV/bin/xnmbrowser -node "`awk '{if (NR==1)print $10}'` "

Then save the file. Then you must either restart trapd or issue the command "/usr/OV/bin/event -e FMTCHG" to cause it to re-read the file.

Sending interface lists to the Tivoli Enterprise Console on events

APAR PJ29821 (Windows) and IY57432 (UNIX) deal with certain events failing to parse correctly when sent to the Tivoli Enterprise Console(R). The reason for this is that, in certain environments, some nodes and routers have so many interfaces (in excess of 30) that the interface list, sent as varbind 8, is too large for the Tivoli Enterprise Console to parse correctly. This problem is addressed by no longer sending the interface list to the Tivoli Enterprise Console as part of those events.

• UNIX

  In IBM Tivoli NetView for UNIX, this is controlled by the slot map entries in trapd.conf. The fix for UNIX will ship a new trapd.conf (in /usr/OV/newconfig/OVSNMP-RUN) but this will not automatically replace the customized one that the user currently has installed in /usr/OV/conf/C/trapd.conf. Therefore, users should make this modification manually on their current systems (or if trapd.conf has not been customized, simply replace the current one with the new one).

  Using xnmtrap, modify each of the following entries in trapd.conf, first clicking the T/EC Slot Map. Then in the window that pops up, select the "iflist" entry and click Delete. Then click OK for each, and "OK" again to complete the edit for that trap. Continue until you are finished. Then press "OK" to finally exit xnmtrap.

  • IBM_NVNM_EV   	50790400  (Node Marginal)

  • IBM_NVNUP_EV 	58916864  (Node Up)

  • IBM_NVNDWN_EV 	58916865  (Node Down)

  • ROUTDOWN_EV	58916971  (Router Down)

  • ROUTUNREACH_EV	58916972  (Router Unreachable)

  • ROUTERUP_EV	58916973  (Router Up)

  • ROUTMARG_EV	58916974  (Router Marginal)

• Windows

  In IBM Tivoli NetView for Windows, this is controlled by the entries in the file \usr\ov\conf\tecad_nv6k.cds. The fix for Windows will ship a new tecad_nv6k.cds, but in \usr\ov\newconfig\tecad. This new file will not replace the customized file that the user has in \usr\ov\conf\tecad_nv6k.cds. Therefore, in order to avoid the problem, users should make this modification manually on their current systems.

  In the \usr\ov\conf\tecad_nv6k.cds file, locate the entries for each of the following traps:

  • 50790400 (Node Marginal)

  • 58916864 (Node Up)

  • 58916865 (Node Down)

  • 58916971 (Router Down)

  • 58916972 (Router Unreachable)

  • 58916973 (Router Up)

  • 58916974 (Router Marginal)

  Under the SELECT statement, remove the line that reads:

  6: ATTR(=, "VB_8") ;
  

  Under the MAP statement, remove the line that reads

  iflist = $V6 ;
  

  For example, the Node Up entry as shipped looks like this:

  CLASS TEC_ITS_NODE_STATUS
    SELECT
      1: ATTR(=,$ENTERPRISE) , VALUE(PREFIX, "1.3.6.1.4.1.2.6.3" ) ;
      2: $SPECIFIC = 58916864 ;
      3: ATTR(=, "nvObject" ) ;
      4: ATTR(=, "nvEventDescr" ) ;
      5: ATTR(=, "nvApplNbr" ) ;
      6: ATTR(=, "VB_8") ;
    FETCH
      1: IPADDR($V3);
    MAP
      origin = $F1 ;
      hostname = $V3 ;
      msg = $V4 ;
      category = $V5 ;
      nodestatus = 1 ; # UP
      iflist = $V6 ;
      nvhostname = $ADAPTER_IP ; # Required for ALL TEC_ITS events
  END
  

  The user will want to make it look like this:

  CLASS TEC_ITS_NODE_STATUS
    SELECT
      1: ATTR(=,$ENTERPRISE) , VALUE(PREFIX, "1.3.6.1.4.1.2.6.3" ) ;
      2: $SPECIFIC = 58916864 ;
      3: ATTR(=, "nvObject" ) ;
      4: ATTR(=, "nvEventDescr" ) ;
      5: ATTR(=, "nvApplNbr" ) ;
    FETCH
      1: IPADDR($V3);
    MAP
      origin = $F1 ;
      hostname = $V3 ;
      msg = $V4 ;
      category = $V5 ;
      nodestatus = 1 ; # UP
      nvhostname = $ADAPTER_IP ; # Required for ALL TEC_ITS events
  END
  

New in Fix Pack 03

The following items were new in IBM Tivoli NetView Fix Pack 03.

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 of 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 dotted-decimal notation 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.

A new JRE

APAR IY45265 included in this Fix Pack provides a JRE upgrade. This gets rid of the problem on earlier NetView V7.1.3 Fix Packs where, depending on your system configuration and level of operating system, the NetView Web Console sometimes caused a core dump after the Fix Pack was installed.

New ruleset, overridestatus_user1.rs, replaces setstatusseverity.rs

IBM Tivoli NetView for Windows users can implement the new ruleset, overridestatus_user1.rs, which replaces the broken ruleset, setstatusseverity.rs. A new document, \usr\ov\doc\Rulesets_on_Windows.readme, documents the ruleset samples for use with the correlation daemon, nvcord. setstatusseverity.rs should be deleted by the user. It will not be shipped in future releases.

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

• For UNIX, 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.

• 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, 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.3 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 initially exist on Solaris. The client setup creates the file after failing to access it, so the error message does not indicate failure.

• The Security Audit Configuration dialog box has two panes.

  The upper pane contains the Select Audit Categories field. Use the on and off buttons in this field to select the categories of audit records that should be stored. Refer to the IBM Tivoli NetView for UNIX Administrator's Guide for information about the events recorded under each category.

  The lower pane contains the following fields, which can be used to control the size and location of audit log files:

  • Audit Log File Name: to specify the full path and name of the audit log file.
  • Number of Audit Files: to specify how many audit files will be stored. When the current audit file reaches the maximum size, it is rolled over into a backup file. When the maximum number of files is reached, the oldest file is moved into the specified temporary directory.
  • Maximum Audit File Size: to specify the maximum size, in MB, of each audit file. When the current file reaches this size, it is rolled into a backup file, and a new file is started.
  • Temporary Directory: to specify a directory for the storage of old audit files. When the maximum number of audit files is exceeded, the oldest file will be moved into this directory. The default value is /tmp. Old audit files are not deleted automatically; be sure to monitor the size of this directory to avoid it filling up your file system.

• On UNIX, /usr/OV/bin/netview.pre is a script a user can create to set environment variables pertaining to the NetView Console. /usr/OV/bin/netview.pre gets run when the user brings up the NetView Console. Like /usr/OV/bin/netnmrc.pre which is used for daemon startup environment variables, /usr/OV/bin/netview.pre is automatically backed up and migrated during an update installation or when users select the /usr/OV/bin.USER category during migration.

  netview.pre can be used to set the environment variable, NVMAPGLOBALACK. Setting NVMAPGLOBALACK equal to one activates the global-based mode for map aknowledgments.

• ON AIX V5 platforms, the default SNMP agent for the operating system is the SNMP V3 agent, which NetView 7.1.3 is not enabled to work with. The default SNMP agent for the system should be set to the SNMP V1 agent. This can be done by stopping the NetView daemons, executing the operating system command

  snmpv3_ssw -1

  and then restarting the NetView daemons.

APARS corrected in this Fix Pack

The following customer-reported problems are 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 by Fix Pack 3:

The following customer-reported problems were fixed in IBM Tivoli NetView V7.1.3 by Fix Pack 2:

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

Installation and configuration

Prerequisites

In order to install IBM Tivoli NetView V7.1.3 Fix Pack 4 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.3 installation (the root account on UNIX).

• The system must already contain an IBM Tivoli NetView Version 7.1.3 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.

  Customer installations that contain a previous IBM Tivoli NetView V7.1.3 Fix Pack may recover most of the space used by that Fix Pack by deleting the /usr/OV/service/V713/Fix PackX directory on UNIX, or the \usr\ov\service\v713\Fix PackX 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	380 Mb	235 Mb
  SunOS Solaris	330 Mb	215 Mb
  Linux Intel	345 Mb	220 Mb
  Linux 390	400 Mb	240 Mb
  Windows	95 Mb	55 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/FixPack4 (on UNIX) or \usr\ov\service\V713\FixPack4 (on Windows) directory. However, doing so removes the ability to back out the Fix Pack. Do not delete the FixPack4 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. Based upon whether the Web Console has been customized, users of the Secure Socket Layer (SSL) protocol either need to:

   • Turn off SSL via the NetView serversetup application.

     Note: This applies to users who have not customized the Web Console.

   • Copy the following files to a temporary location:
     • /usr/OV/www/webapps/netview/WEB-INF/web.xml and /usr/OV/www/conf/jetty.xml (on UNIX)
     • \usr\ov\www\webapps\netview\WEB-INF\web.xml and \usr\ov\www\conf\jetty.xml (on Windows).

     Note: This applies to users who have customized the Web Console.

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

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

   Prior to copying the package, ensure that the space available in this subdirectory is larger than the space required for installation of the IBM Tivoli NetView 7.1.3 Fix Pack 04 on this operating system.

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

   • On UNIX: type zcat 7.1.3-NVD-{Platform}-FP0004.tar.Z | tar -xvf - install
   • On Windows: type 7.1.3-NVD-Win32-FP0004.exe

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

   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.

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

7. Reinstall any NetView Web Console installations from the upgraded native NetView Server installation. This can be downloaded from the following URL after the NetView server has been upgraded:

   	http//<NetViewServer>:8080/download
   	

   For the Web Console on Windows, the following files contain the Fix Pack 04 updates. Either one can be used.

   	nvwc_thin.zip    (thin Web Console for Windows)
   	nvwcinstall.exe  (self extracting installation)
      

   For the Web Console on UNIX, the following file contains the Fix Pack 04 updates:

      nvwc_thin.tar    (thin Web Console for Unix)
      

   Please note that when upgrading a NetView Web Console from a NetView 7.1.3 Fix Pack 04 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 Fix Pack 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.

8. After Fix Pack installation, users must run the Web Console Security Console before using the Web Console, itself, since some of the XML properties values are changed during Fix Pack installation

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

10. 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/FixPack4 on UNIX or the \usr\ov\service\V713\FixPack4 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 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.

Note: The backout script must be run from the \usr\ov\service\V713\FixPack4 Windows subdirectory.

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

• IBM Tivoli NetView 7.1.3 is not compatible with Microsoft Remote Terminal Services. If Remote Terminal Services is used to install or execute NetView, NetView will not function correctly, and the NetView database will become corrupted.

• When a new object (for example an interface, network, segment, or node) belonging to a SmartSet is discovered while the SmartSet is open on the NetView console, the new object is displayed with a generic computer symbol. Closing the SmartSet and reopening it displays the proper symbol.

• UNIX customers who use the Web Console with a large NetView database, should:

  • Change NETVIEW_LARGE_DB=FALSE to NETVIEW_LARGE_DB=TRUE in the /usr/OV/conf/NetViewLargeDb.conf file.
  • Save the file.
  • Bring down any NetView Consoles and the netviewd daemon.
  • Restart the netviewd daemon and any NetView Consoles.

• 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.3 Fix Pack 3 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 implement the new ruleset, overridestatus_user1.rs, instead of the broken ruleset, setstatusseverity.rs. The broken setstatusseverity.rs ruleset 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, but it cannot be removed in a maintenance release.

  Note: Once the Fix Pack has been installed, a user can refer to the new \usr\ov\doc\Rulesets_on_Windows.readme for more information on rulesets.

• IBM Tivoli NetView for users implementing complex SmartSets sometimes end up having the wrong objects in the Smartset (particularly when using !(IN_COLLECTION collectionName) on the right side of && in the right side of an ||). However, if the user rearranges the logic for the SmartSet, they can create a SmartSet with the correct results.

  Example:
  
  nvUtil e "(isMLM=TRUE || ((isNode=TRUE) && \
  (isIP=TRUE) && ('IP Status'!=Unmanaged) && \
  (!(IN_COLLECTION Routers)) && \
  (!(IN_COLLECTION CiscoDevices)) && \
  (!(IN_COLLECTION NetViews))))"
  
  

  Rearrangement of the rule as follows seems to fix the problem:
  
  nvUtil e "(isMLM=TRUE ||
  ( (!(IN_COLLECTION Routers)) && \
  (!(IN_COLLECTION CiscoDevices)) && \
  (!(IN_COLLECTION NetViews)) && \
  (isNode=TRUE) && \
  (isIP=TRUE) && \
  ('IP Status'!=Unmanaged) ) )"
  
  

• The fix to PJ29416 replaces the binaries, \usr\ov\bin\tecad_nv6k_non_tme.exe and \usr\ov\bin\tecad_nv6k_tme.exe, but it does not alter the Windows TEC adapter daemon that the user is running, \usr\ov\bin\tecad_nv6k.exe. This binary is a copy of one of the two which are shipped. Users who wish to pick up this fix must either re-run the tecconfig.bat configurator to copy the appropriate shipped binary to tecad_nv6k.exe, or do this themselves manually.

• When connecting to the NetView Server share from a native NetView Client on Windows, the drive must be mapped to the hostname rather than the IP address, i.e.

  \\hostname.tivoli.com\NetView

  rather than

  \\192.168.1.1.\NetView

  This limitation is due to netbios requirements in Windows.

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 UNIX User's Guide for Beginners, a note should be added to Chapter 1, "Getting Acquainted with Tivoli NetView", under "Starting the Tivoli NetView Program":

  In order to start the IBM Tivoli NetView GUI over a remote connection using Secure Socket Shell (SSH), you must set the SSH option, X11UseLocalhost to no.

• In the IBM Tivoli NetView for Windows User'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:

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 IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement 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.