MultiSystem Manager Netfinity Agent Readme for OS/2 and Windows NT This file contains information related to the download and installation process for the NetView for OS/390 V1R3 MultiSystem Manager Netfinity agent for OS/2 and Windows NT. This agent allows for display and control of your Netfinity networks from Tivoli NetView for OS/390. If you are not controlling your Netfinity workstations from Tivoli NetView for OS/390, you do not need to install this agent. ******************************************************************************* * The term Netfinity is used throughout this readme file, this may refer to * * Netfinity Manager or NetFinity, depending on the version you are running. * ******************************************************************************* Note that the MultiSystem Manager Netfinity agent is NOT shipped with the NetView for OS/390 CD. The MultiSystem Manager Netfinity agent is available from the Netfinity product CD and is also available from the Netfinity web site at www.pc.ibm.com/qtechinfo/SCOD-44BT66.html?lang=en_US&page=brand&brand=IBM+PC+Server%7CSystems+Management - Overview - Supported platforms - Prior to Installation - Installation - Service Point only installation - Complete Installation - Installation notes for OS/2 users - Installation Notes for Windows NT users - Modifying Your Netfinity Environment - Security - Hints - Tracing - Remote Console - Getting Help - Late-Breaking News - Trademarks Overview -------- The MultiSystem Manager Netfinity Agent allows for management of Netfinity controlled workstations from NetView for OS/390. There are 2 parts to the MultiSystem Manager Netfinity agent. There is an piece that collects status on the Netfinity workstation. This part must reside on each Netfinity workstation where accurate status is required. The second piece resides on one or more NetFinity workstations and communicates between NetView for OS/390 and the Netfinity Network. This service point agent collects status from the individual status agents throughout the network. Supported platforms ------------------- The MultiSystem Manager status agent is currently supported on: - Netfinity Manager Version 5.00 and later And the following operating systems as supported by Netfinity Manager: - Microsoft Windows NT - OS/2 Prior to Installation --------------------- If the MultiSystem Manager NetFinity agent was previously installed, you must verify that the MultiSystem Manager NetFinity Agent is not currently active prior to installing the new copy of the agent. On OS/2, you can verify that the agent is not active by checking its status in the Process manager of Netfinity. Start the Netfinity Process Manager and verify that FLCHAGNT.EXE is not in the active process list. If it is, select it and using the right mouse button, stop it. On Windows NT, You can verify that the agent is not active by checking its status in the Services facility of Windows/NT: 1. Select My Computer from the desktop. 2. Select the Control Panel. 3. Select the Services window from within the Control Panel. 4. If the MultiSystem Manager NetFinity Agent is in the Services list and the status of the MultiSystem Manager NetFinity Agent is Started, select the MultiSystem Manager NetFinity Agent from the list and click on the Stop button. Installation ------------ There are 2 approaches that can be used to install the new MultiSystem Manager Netfinity agents. Service Point only installation ------------------------------- This approach allows for a less intrusive approach to management while still providing a certain level of accuracy in the initial status of objects. Since this methods depends on Netfinity alerts flowing from the endpoint Netfinity workstations to the service point, the service point machine must be started prior to endpoint machines. If the Service Point machine is started after an endpoint machine, the MultiSystem Manager agent will assume all resources on the endpoint are active until an alert arrives indicating differently. To install on the service point: 1) If you are installing from the Netfinity CD, the MultiSystem Manager Netfinity agent install file (NETFINST) resides in a subdirectory below the MSM directory. Depending on the version and release of the Netfinity CD, NETFINST might be found in the /OS2 or /WINNT subdirectory or possibly even lower in the directory structure if the Netfinity CD contains multi-language (ENU, JPN, etc.) subdirectories. Start the appropriate version of NETFINST for the platform and language you are installing. 2) Choose the source and target directory and select OK. It is recommended that you install the MultiSystem Manager Netfinity agent in the same directory as Netfinity. 3) On the install panel, select Netfinity MultiSystem Manager Agent Installation 4) After the installation is complete, the workstation should be rebooted. 5) In the Netfinity alert manager, create an action to forward all alerts Complete Installation --------------------- This method involves updating the MultiSystem Manager Agent on the service point machine and installing a MultiSystem Manager status agent on each Netfinity endpoint in which initial status is critical. First, follow the steps outlined above to install on the service point. On each of the Netfinity workstation endpoints: 1) It is recommended that you modify the NMVT.INI file on the installation media prior to distributing the status agent. See the section below named 'Process Manager Alerts and Resolutions' for details on modifying NMVT.INI. 2) If you are installing from the Netfinity CD, the MultiSystem Manager Netfinity agent install file (NETFINST) resides in a subdirectory below the MSM directory. Depending on the version and release of the Netfinity CD, NETFINST might be found in the /OS2 or /WINNT subdirectory or possibly even lower in the directory structure if the Netfinity CD contains multi-language (ENU, JPN, etc.) subdirectories. Start the appropriate version of NETFINST for the platform and language you are installing. 3) Choose the source and target directory and select OK. 4) On the install panel, select Netfinity MultiSystem Manager Status Agent Installation 5) After the installation is complete, the workstation should be rebooted. 6) In the Netfinity alert manager, create an action to forward all alerts to the "MSM Status Tracker". See below for details. 7) In the Netfinity Security Manager, provide access to the "MSM Status Tracker" for your service point machine. 8) In the Netfinity alert manager, create an action to forward all alerts through the network to the service point machine. See below for details. Installation notes for OS/2 users --------------------------------- Ensure that the directory where the agent is installed is included in the PATH, DPATH, and LIBPATH statements of your CONFIG.SYS file. NETFINST will automatically update CONFIG.SYS if you want it to. If CONFIG.SYS is not updated by NETFINST, it must be manually updated with the PATH, DPATH, and LIBPATH changes or the agent may not function properly. You can have the MultiSystem Manager Netfinity agent automatically started by choosing the autostart option during the installation process. If you automatically start the agent you might find that the MultiSystem Manager topology database may not be complete when you first check it. Even though the MultiSystem Manager Netfinity agent waits a period of time before querying topology, Netfinity may not have completely discovered the network before the agent begins its queries. If you receive incomplete topology, you can issue a GETTOPO NFRES with NFRESET=YES to synchronize the MultiSystem Manager agent database. You can also increase the amount of time that the MultiSystem Manager Netfinity agent waits before querying Netfinity for topology information. The command to start the MultiSystem Manager Netfinity agent, along with the wait time, are included in CONFIG.SYS. For an OS/2 Netfinity agent, that command would look like this: RUN=path\FLCHAGNT.EXE 5 The value of 5 in the example above indicates that the MultiSystem Manager Netfinity agent will wait five minutes before querying Netfinity for topology information. The number of minutes can be changed to meet the needs of your installation. Configuring alerts to route through APPC on OS/2 ------------------------------------------------ Status for objects on your NetView graphical display is kept current by alerts sent from Netfinity to NetView for OS/390. To ensure that status is updated, Netfinity must be modified to forward alerts to NetView for OS/390. Follow these steps to forward alerts to host NetView: 1) Select Alert Manager from the Netfinity panel. 2) Select Actions pushbutton on the Alert Manager panel. 3) Select New pushbutton on Alert Actions panel indicating that a new action is to be created. The Action Editor panel has numerous filters that can be defined for alerts. One method is to forward all alerts. 4) To forward all alerts, select the Any box for Alert Type, Application ID, Application Alert Type and Sender ID. 5) To route alerts through APPC, Select the action Send Alert to host via APPC (TRANSFER_MS_DATA) for the Action Definition. Since status is kept up to date using these alerts, filtering alerts may impact the status of objects on your NetView graphical display. An alternative way to perform this configuration is through the Netfinity Command line facility. Issue the following command from the OS/2, DOS or MS/DOS command line: NFALRTCL /ADDACT:"HOSTACT/0" Configuring Communications for an OS/2 Agent ---------------------------------------------- In order to correctly represent the status of real objects on your NetView graphical display, alerts and resolutions must flow between the Netfinity service point machine and NetView for OS/390. This requires that the Communications Manager or Communications Server on the service point machine be properly configured to route alerts. The most common way to accomplish this would be to define a link in Communications Manager to the host NetView. For more information on defining links, see the Communications Manager or Communications Server documentation. Ensure that the host focal point support denotes the link name going to host NetView. Another way to configure your service point machine to route alerts is to use the DEFINE_REMOTE_FOCAL_POINT entry in the networks definition file (NDF) for your configuration file. This entry denotes how alerts should get routed. For Example, you could code the following to route alerts to the host USIBMNT.NTVB3. DEFINE_REMOTE_FOCAL_POINT SNA_DEFINED_MS_CATEGORY(X'23',031) DESCRIPTION(ALERT_CATEGORY) FQ_PRIMARY_FP_NAME(USIBMNT.NTVB3 ); DEFINE_REMOTE_FOCAL_POINT SNA_DEFINED_MS_CATEGORY(X'23',015) DESCRIPTION(MESSAGE_TO_OPERATOR) FQ_PRIMARY_FP_NAME(USIBMNT.NTVB3 ); The FQ_PRIMARY_FP_NAME name must be the fully qualified netid.name. Configuring Remote Operations Service(ROPS) ------------------------------------------- This section applies to users running Communications Manager/2(CM/2) or Communications Server. The commands sent from NetView for OS/390 are received by the ROPS service and passed to the MultiSystem Manager Netfinity for OS/2 agent for processing. It is imperative that the default timeout values for ROPS be set to values sufficiently large to allow all MultiSystem Manager commands to complete. To change the values select Options from the Remote Operations Service main screen. Then select Program Options. Change the fields 'Time before setting status to long-running' and 'Time before canceling commands' to values appropriate for your environment. Considering all the variables that may affect command completion time, CPU, number of machines being monitored, memory, etc., It is recommended that your initial setting for these variables be their maximum allowable, 65535 seconds. These should be reduced later to minimal values which allow your longest running commands to complete. If these time-out values are reached before the MultiSystem Manager Netfinity for OS/2 agent completes it's processing, GETTOPO commands sent from NetView for OS/390 will result in message FLC077E at the NetView console. Installation Notes for Windows NT users --------------------------------------- The MultiSystem Manager NetFinity agent will run as a Windows/NT service. By default, the agent will be configured to automatically start when the system starts. If the agent should not be started automatically, you can use the Windows/NT Service facility to change the default startup to Manual. If the default startup is set to Manual, the operator is responsible for starting the agent. Once the NetFinity agent is installed, you should update the MSMNFNT.INI file for your environment before starting the agent. The MSMNFNT.INI file contains parameters that the agent uses when it initializes. Specifically, there are four values in the file that can be changed: MAX_BUFFER_SIZE Defines the maximum amount of information that the agent will send to NetView for OS/390 in one buffer. INITIALIZATION_DELAY Specifies the number of MINUTES that the MultiSystem Manager NetFinity Agent will wait during initialization before querying NetFinity for topology and status information. ALERT_DESTINATION Identifies the NetView host that will receive alert notifications. This can be specified as either a host name or an IP address. ALERT_DESTINATION_PORT Specifies the port to be used to communicate with the NetView for OS/390 TCP/IP Alert Receiver (DSIRTTR). For additional information on the use of these definitions, please refer to the comments in the MSMNFNT.INI file. Configuring Alerts to Route IP ------------------------------ Status for objects on your NetView graphical display are kept current by alerts sent from NetFinity to NetView for OS/390. NetFinity must be modified to forward alerts to NetView for OS/390 for the status to be updated. Follow these steps to forward alerts to NetView for OS/390: 1. Select ALERT MANAGER from the NetFinity panel. 2. Select ACTIONS pushbutton on the Alert Manager panel. 3. Select NEW pushbutton on Alert Actions panel indicating that a new action is to be created. The Action Editor panel has numerous filters that can be defined for alerts. One method is to forward all alerts. 4. To forward all alerts, select the ANY box for Alert Type, Application ID, Application Alert Type and Sender ID. 5. To route alerts through IP, select the action SEND ALERT TO HOST for the Action Definition. NOTE: Since status is kept up to date using these alerts, filtering alerts may impact the status of objects on the NetView graphical display. An alternative way to perform this configuration is through the NetFinity Command line facility. Issue the following command from the MS/DOS command line: NFALRTCL /ADDACT:"HOSTACT/0" Specifying TCPIP Ports ---------------------- The MultiSystem Manager NetFinity agent for Windows/NT uses the following port definitions: msmnft_Agent 6752/TCP msmnfnt 6751/TCP msmnfnt_commands 6753/TCP msmnfnt_query 6754/TCP If these entries result in conflicts in your environment, the SERVICES file in the \ETC directory must be modified to include the appropriate port statement, as shown above. For example, if you have a conflict with port 6751 (which is defined to msmnfnt in the port statement above), add the following statement to the SERVICES file in the \ETC directory: msmnfnt xxxx/TCP Where xxxx is a valid unused port number. NOTE: The port number defined to the msmnfnt service must match the port number specified on the PORT keyword on the GETTOPO command to this service point. Modifying Your Netfinity Environment ------------------------------------ System Naming Convention ------------------------ Although Netfinity does not impose hard restrictions on workstation names, MultiSystem Manager will not be able to issue GETTOPO commands to workstations that have a name containing all blanks. Service Point ------------- MultiSystem Manager will use the grouping as defined in Netfinity on the service point machine for the view layouts on your NetView graphical display. Workstations will be displayed by group the same as they are displayed on the Netfinity service point. Therefore each workstation that you want to display on the NetView graphical display must be in a group on the Netfinity service point. Process Manager Alerts and Resolutions -------------------------------------- For RODM to correctly represent the status of Process Manger objects, the nmvt.ini file on your service point workstation must be modified. The nmvt.ini file dictates how Netfinity alerts will be translated into NetView (NMVT) alerts. All process manager alerts are, by default, sent to NetView for OS/390 as alerts. You might want an alert to be sent when a process stops. For example, if you create a process monitor for a process named server.exe, NetView for OS/390 receives an alert when the process is started and when the process stops. Because you would probably want the server code running continuously, an alert should be sent when the server.exe stops. RODM status would be updated when the alert is sent. A resolve should also be sent when the server.exe starts so that the alert is resolved in RODM. Conversely, you might want an alert to be sent when a process is loaded and a resolve sent when it has stopped. For example, your company policy might prohibit game.exe to be loaded. If you want to monitor the loading of game.exe, you could set your system up so that an alert is sent when the file is loaded and a resolve is sent when it is stopped. In either case, you will need to edit your nmvt.ini file in the Netfinity directory. Under the process manager section, you will see the following three lines, one for each Netfinity alert type: 901 This is generated when a process is started. 900 This is generated when a process is stopped. 902 This is generated when a process fails to start. Each of these Netfinity alert types, ATYPE, is converted to a NetView GTYPE, by default, in the nmvt.ini file. To make one or more of these alerts a resolve, change the keyword GTYPE to RTYPE. For more information on NMVT alerts, see the System Network Architecture Formats book. End Point --------- Defining alert conditions ------------------------- MultiSystem Manager tracks workstation status through the use of alerts. The user is allowed to customize each Netfinity workstation to determine what conditions warrant an alert and thus a change in status on the NMC views. For example on LAN servers, you may want to define alert conditions when the servers hard drives exceeds a certain percentage full. On build machines, CPU utilization may be more critical. Please see the Netfinity Users Guide for more information on configuring alert conditions. Forwarding Alerts ----------------- Netfinity workstations that are not the service point must be configured to send alerts to the service point. This will allow the service point to route those alerts to NetView for OS/390. This configuration can be done for the service point through a remote session or directly from the Netfinity end point. This assumes the end point is not a passive Netfinity services workstation. To forward alerts from workstations to the service point, do the following: 1) Select Alert Manager from the main Netfinity panel. 2) Select Actions pushbutton from Alert Manager panel. 3) Select New pushbutton on Alert Actions panel indicating that a new action is to be created. 4) To forward all alerts, select the Any box for Alert Type, Application ID, Application Alert Type and Sender ID. In the Action Definition, select action Forward alerts through network P1 to system P2 for the Action Definition. In the P1 field enter the network type that the workstation will use to communicate with the Netfinity service point (i.e. NETBIOS, TCPIP...). In the P2 field enter the name of the workstation as it is known on the network (i.e. Netfinity.raleigh.ibm.com for TCPIP). If you also installed the MSM Status Tracker agent, you must also create an action to forward all alerts to the MSM Status Tracker. Follow the steps above to create an alert action, substituting MSM Status Tracker for Forwarding alerts through the network. The Action Editor panel has numerous filters that can be defined for alerts. One method, as described above, is to forward all alerts. Status is kept up to date using these alerts, filtering alerts may impact the status on NMC. This configuration can either be done through the Netfinity user interface or the Netfinity command line facilities. If there are numerous machines to modify, it would be expedient to use the command line facility. From the OS/2 command line, the Netfinity command to do this same configuration is: NFALTCL /ADDACT:"ALERTFORWARD" /PARM0:TCPIP /PARM1:ServicePoint.raleigh.ibm.com To configure a large number of workstations use the /n: option on the command line. The command to a remote workstation is as follows: NFALRTCL /ADDACT:"ALERTFORWARD" /PARM0:TCPIP /PARM1:ServicePoint.raleigh.ibm.com It is important to have a methodology for forwarding alerts. When a workstation is configured to forward alerts, by default, it will forward all alerts including those forwarded to it from another workstation. As an example, if workstation A is configured to send alerts to workstation B and workstation B is configured to send alerts to workstation A, each alert will get sent around in a loop for an extended period of time. Netfinity will eventually stop forwarding the alert but it is something that should be avoided. One method to avoid this is to have each workstation only forward alerts to the service point, and the service point forward alerts to NetView for OS/390. Another method to avoid this problem is to configure each workstation to only forward alerts generated by that workstation. This can be accomplished through the Netfinity Alert Manager user interface by selecting box labeled Any Sender on the panel and typing the network name of the local workstation. Security -------- The Netfinity service point will query the Netfinity workstations in the network for management information. Because of this, each end point must have security configured to allow access by the service point Netfinity. You may receive incomplete topology if the security is not configured correctly. Remote Console -------------- There are 2 ways to run remote console from your NetView graphical display machines to directly connect to NetFinity on the selected machine. These can be setup and configured via the NetView for OS/390 Build Views (BLDVIEWS) utility. 1) TCPIP - If your shop is configured to run TCPIP, the WEB Enhancement is installed on your NetFinity managers and your NetView graphical display workstations are TCPIP enabled and have a WEB Browser that supports command line addressing, you can have the remote console start your browser and connect to a remote manager. An example might be Netscape http://%ipaddress%:411/MAIN/ This command would start the Netscape browser and automatically connect to a NetFinity Manager. You could use the rodm object field IPAddress to get the TCPIP address for the system object and the monitor object. 2) Native NetFinity - If your NetView graphical display workstations have NetFinity Manager installed on them and have access to the same networks as your service points you can use NetFinity directly. An example of this might be: NETFIN /n:%CommandRountingAddress% /L:%RANDOM% /R:%RANDOM% This command would start a NetFinity session on the NetView graphical display machine and automatically connect it to the remote NetFinity services. The CommandRoutingAddress would be the CommandRoutingAddress field on the real NetFinity objects in RODM. Hints ----- If you have specified ALL for keywords NFSYSMON and NFPROC but still do NOT see the system monitor and application icons in your NetView graphical display views, you might have a Netfinity security problem. You can verify this by going to the remote system and verifying that security is configured to allow access by the service point Netfinity machine. Tracing ------- The MultiSystem Manager Netfinity agent is designed to log potential error problems to an error file. Error logging is always active such that in the unlikely event of a problem, IBM service will have access to a file containing trace information. It may become necessary in the course of debugging a problem for IBM that you would be asked to start the agent with tracing turned on. This is done by adding a trace flag to your config.sys and rebooting your workstation, or alternatively starting the agent manually in an OS/2 session where the trace environment variable has been set. A typical line for the config.sys or to enter on a command line is: SET MSMNF_TRACE=-EXIT_TRACE -ENTRY_TRACE -API_TRACE -TRACE_LEVEL_3 -LOG_TO_DISK Y This will turn on EXIT, ENTRY, and API tracing at level 3 and log it to disk. Should you need to provide IBM service with a trace file, your IBM representative will give you further instructions on which flags to set. Getting Help ------------ For Technical Information ------------------------- We are ready to help you with your questions. You can contact us through standard problem reporting procedures. Defect Reporting ---------------- For support for this or any Tivoli product, you can contact Tivoli Customer Support in one of the following ways: o Submit a problem management record (PMR) electronically from IBMSERV/IBMLINK o Submit a problem management record (PMR) electronically from our Web site at http://www.tivoli.com/support o Send e-mail to support@tivoli.com Customers in the United States can also call 1-800-TIVOLI8 (1-800-848-6548). International customers should consult the Web site for customer support telephone numbers. You can also review the Customer Support Handbook, which is available on our Web site at http://www.tivoli.com/support/handbook/. When you contact Tivoli Customer Support, be prepared to provide identification information for your company so that support personnel can assist you more readily. Company identification information may also be needed to access various online services available on the Web site. Additional support is also available on the NETVIEW CFORUM (Customer Forum) on IBMLINK. This forum is monitored by NetView development who answer questions and provide guidance. When it appears that a problem with the code is found, you will be asked to open an official PMR to get resolution. For information about IBMLINK registration and access, look on IBM Web page: http://www1.ibmlink.ibm.com The Web site offers extensive information, including a guide to support services (the Customer Support Handbook); frequently asked questions (FAQs); and documentation for all Tivoli products, including Release Notes, Redbooks, and Whitepapers. The documentation sets for some product releases are available in both PDF and HTML formats. Translated documents are also available for some product releases. You can order documentation by e-mail at swdist@tivoli.com. Please provide the publication number, part number or order number of the desired document; alternatively, you can provide the document’s title, version number, and date of publication. We are very interested in hearing about your experience with Tivoli products and documentation. We also welcome your suggestions for improvements. If you have comments or suggestions about our documentation, please contact us in one of the following ways: o Send e-mail to pubs@tivoli.com o Fill out our customer feedback survey at http://www.tivoli.com/support/feedback. Determining Your Service Level ------------------------------ When reporting defects it will be necessary to provide Tivoli with your service level. You will receive instructions on how to do this when you contact Tivoli. Late-Breaking News ------------------ Known defects ------------- o None Service History --------------- * Unless denoted otherwise, fixes were made to both the OS/2 and NT agents. o October, 1997 Modified this file to add a section on configuring ROPS runcmd timeout. If the timeout is not configured properly for the OS/2 agent, a FLC077E error message may be returned on the GETTOPO. o February 1999 MSM Netfinity agent does not run with CS/2. GETTOPO returns the error message FLC108E Command Received by the Agent was Not Valid. Changed protocol to better handle non-English character sets. In order for this fix to work, users must apply the PTFs from the appropriate TME 10 NetView for OS/390 APAR. For V1R1 - OW36122 For V1R2 - OW37441 For later versions of NetView, no APAR is required. o February, 1999 Agent enhanced to allow for more accurate initial status of objects in the network. This involved the creation of a status agent for each NetFinity workstation to be monitored. o July, 1999 Abnormal termination of FLCHAGNT.exe with access violation if a heartbeat request preceded the first GETTOPO request. o September, 1999 Abnormal termination of FLCHAGNT.exe with access violation 0xC0000005 during agent resource discovery. This occurred on resources where the IP address could not be resolved to an IP hostname. o September, 2000 NetFinity environments with monitor names over 32 chars could present random problems in the MSM NetFinity Agent. The agent was modified to truncate all monitor names at 32 characters. Therefore, the first 32 characters of Monitor/Threshold names for a given workstation must be unique. In order for this fix to work, users must apply the PTFs from the appropriate TME 10 NetView for OS/390 APAR. For V1R1 - OW45218 For V1R2 and V1R3 - OW46031 For later versions of NetView, no APAR is required. The MSM Agent was incorrectly reporting an agent status of active when the NetFinity base (NETFBASE) was not active. The agent was modified to report as inactive when it discovers it can no longer communicate with NetFinity. When the Agent discovers that NetFinity is active after being inactive, it will send an Agent-Up alert and topology will automatically be rediscovered. In order for this fix to work, users must apply the PTFs from the appropriate TME 10 NetView for OS/390 APAR. For V1R1 - OW45218 For V1R2 and V1R3 - OW46031 For later versions of NetView, no APAR is required. Documentation Changes --------------------- o No documentation changes at present. Trademarks ---------- The following terms are trademarks of the respective companies in the United States or other countries or both: - AIX and OS/2 are trademarks of the IBM Corporation. - Tivoli Systems is a trademark of Tivoli Systems Inc. - Java and Solaris are trademarks of Sun Microsystems, Incorporated. - TME and TME 10 are trademarks of Tivoli Systems Inc. - Windows 95 and Windows NT are trademarks of Microsoft Corporation. Licensed Materials - Property of Tivoli Systems Product Number 5697-B82 (C) Copyright Tivoli Systems 1997, 2000. All rights reserved. US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Last Updated: September 7, 2000 3:07 pm EDT.