SNA Topology Manager Implementation Guide

NetView for z/OS, Version 5.4

Monitoring Network, Local, and LU Topologies

The topology manager creates SNA objects in RODM from the information it receives from nodes being monitored. You can issue commands to monitor topology from the NetView® command line as described in one of the following sections. These sections also describe how to monitor critical resources, how to resume monitoring if the topology manager fails, and how to automatically monitor resources.

The monitoring of SNA topology data is broken into several stages. These stages are defined in Table 17.

Table 17. Stages of a Monitor Operation
Stage Description	When entered	When exited
Initiation of the operation with the agent node.	When the TOPOSNA MONITOR command is issued or the topology manager sends the request to the agent node.	When the topology manager receives the first response to the request it sent to the agent node.
Receiving the initial contents of the topology. Whenever a new monitor operation is started, the topology agent first transfers the current contents of the requested topology.	When the first topology update is received from the agent node.	When the transfer of the initial contents of the topology is complete.
Receiving topology updates.	When the transfer of the initial contents of the topology is complete.	When the monitor operation is stopped. The monitor operation is stopped when the operator issues a TOPOSNA STOP command, when the monitor time specified on the TOPOSNA MONITOR command expires, or when an error occurs.
Retrying the initiation of the operation with the agent node.	When the monitor operation fails because of an error that can be retried. This error can occur while trying to initiate the operation, or while receiving topology information from the agent node.	When the monitor operation is successfully started or the retry count is exceeded.

TOPOSNA Requests for Monitoring Topologies

The TOPOSNA requests used for topology monitoring along with their parameters are listed to help you understand these TOPOSNA requests. For complete syntax of the TOPOSNA command, see the NetView online help.

The following TOPOSNA command request keywords are used for topology monitoring:

LISTREQS

With TOPOSNA LISTREQS, you can determine:

All nodes being monitored for network topology
All nodes being monitored for local topology
All nodes being monitored for LU topology

MONITOR

Specifies that the topology manager is to begin monitoring the topology of an agent node. Monitoring continues until a STOP request is issued, unless you have specified the MONTIME= keyword parameter.

STOP

Requests no further monitoring. Data already received is processed by the topology manager.

Issuing a Monitor Request from the NetView Command Line

When you initialize the topology manager for the first time, RODM might not contain any SNA objects (because you have not yet started monitoring). To start monitoring topology, issue the TOPOSNA MONITOR command. The topology manager uses the topology updates from the agent nodes to dynamically monitor the SNA network.

For example, to start network topology monitoring at a specified node, enter the following command on the command line:

TOPOSNA MONITOR,NETWORK,NODE=A.NN2

If the command is issued against an Advanced Peer-to-Peer Networking®network node or an interchange node, a node object and Advanced Peer-to-Peer Networking TG objects are created in RODM. Higher level Advanced Peer-to-Peer Networking aggregate objects are also created. If the command is issued against an interchange node, migration data host, or type 5 node, CDRM objects are created in RODM.

Note:

For the interchange or migration data host nodes, only one object is created, but it is displayed in both Advanced Peer-to-Peer Networking and subarea views: a dual-image object.

You can use the TOPOSNA MONITOR command at any time after startup, for network, local or LU topology monitoring. If nodes from which you want to start monitoring topology are displayed in the views, you might find it more convenient to issue the command from the menus. If you need help with command syntax, type HELP TOPOSNA MONITOR for online help at the command line.

In some cases, nodes from which you want to start monitoring topology are in the network but are not shown in the views. If you know the name of the node, issue the TOPOSNA MONITOR command from the NetView command line.

TOPOSNA MONITOR requests can also be issued by:

The NetView operator
NetView command lists
Customized command sets at the NetView management console

Automation Considerations

Issue the TOPOSNA MONITOR command as an automated part of the topology manager startup. Specific considerations include the following items:

In general, designate at least one network node from each Advanced Peer-to-Peer Networking subnetwork to be monitored initially by the topology manager. The topology manager discovers all other nodes in the subnetwork from the information received from the agent nodes.
If you want to monitor CDRMs, monitor network topology from all interchange nodes, type 5 nodes, and migration data host VTAM® nodes.
To monitor a complete VTAM domain, except for LU and CDRSC objects, monitor network and local topology from each VTAM node. Balance this need with performance considerations.
To monitor the collection of LUs at a VTAM node or a logicalLink owned by a VTAM topology agent, monitor the LU topology. When collecting LU topology from a VTAM node, balance this need with performance considerations. For more information, see the IBM Tivoli NetView for z/OS Tuning Guide and see Monitoring LU Collections from the NetView Management Console.

Timed Topology Monitoring

If you want to monitor the local topology only for a defined period of time, specify a duration value (in minutes) when the window for specifying the control point name and duration is displayed. This is also available for monitoring network topology and LU topology.

When the time expires, monitoring stops and the status of the applicable resources in the view can become unknown (LUs and CDRSCs are deleted). If objects in the view are currently being monitored under a different request, their status remains current. For example, the network node in the view is likely still being monitored with network topology and remains at its current status.

Specifying a duration (in minutes) on a MONITOR request is useful when you want to monitor portions of your network for brief periods of time. However, it is more efficient to monitor continuously than to request frequent timed monitoring. This is especially important for:

Local topology in large VTAM domains
LU topology on a VTAM node

How to Monitor Critical Resources

For a logicalUnit (LU) or crossDomainResource (CDRSC) object that you want to monitor continuously, the TOPOSNA CRITICAL command provides a means to start monitoring (STARTMON keyword) and continue monitoring regardless of the presence of the logicalUnit or crossDomainResource object in any views. These resources are created in RODM and are available for display in relevant views, but are not deleted from the RODM data cache until monitoring is requested to be stopped using the TOPOSNA CRITICAL command (STOPMON keyword).

The TOPOSNA CRITICAL command also provides a means to request a list (LIST keyword) of all the logical units and cross domain resources that SNA topology manager is currently monitoring continuously. An entry in the list, resulting from a TOPOSNA CRITICAL LIST command, includes the resource name, the resource type (LU or CDRSC), and the monitor status (monitoring, requested, failed, or initialized) of a critical LU. Refer to the NetView online help for an example, complete description, and correct syntax for the TOPOSNA CRITICAL LIST command.

Critical LUs are monitored using event forwarding discriminators (EFDs). EFDs report status changes, but cannot detect when a path between the agent and the manager no longer exists.

If a NETWORK, LOCAL, OR LUCOL monitor request to the owning node of the LU is interrupted, the SNA topology manager attempts to collect new status information from the critical LU. If this request fails, the status of the LU is changed to unknown, and the critical LU monitor status is changed to failed.

If a subsequent NETWORK, LOCAL, or LUCOL monitor request is successful, the SNA topology manager attempts to refresh the status of the critical LUs under that node. If this is successful, the status of the LU is updated and its critical LU monitor status is changed to monitoring.

Notes:

To ensure that the status of an LU is accurate and the operator is aware of connectivity problems, have at least one NETWORK, LOCAL, or LUCOL monitor request active to the node where the LU is defined.
If a switched major node becomes inactive, then any TOPOSNA CRITICAL continuous monitors that existed for LUs under the switched major node are stopped. If the switched major node is later activated, then you must again issue the TOPOSNA CRITICAL command to restart continuous monitoring for critical LUs.

See Automating and Customizing Topology Manager Views and Creating RODM Objects for additional information about TOPOSNA CRITICAL command usage. For a complete description and correct syntax of the TOPOSNA CRITICAL command request parameters, see the NetView online help.

Using Warm Start to Resume Monitoring

When the topology manager is stopped with the TOPOSNA STOPMGR command, it saves an indication in RODM designating which resources were being monitored before the topology manager task ended. If you have specified warm start in the topology manager initialization file (FLBSYSD), the topology manager uses these indicators to restart monitoring of all resources automatically, except:

Resources older than the specified number of days on the PURGDAYS parameter in the topology manager initialization file (FLBSYSD)
Timed monitors that were in effect when the topology manager task was stopped

By using the topology manager warm start, you can start and stop the topology manager without taking any action to save objects in RODM; the topology manager tracks the objects.

Note that this is different from stopping and restarting RODM with a checkpoint file. If RODM is loaded with a checkpoint file between the time the topology manager is stopped and restarted, the topology manager restarts all monitor operations that were active when the RODM file was checkpointed. Be aware that resources in the checkpointed file contain time stamps that have also been checkpointed. These time stamps are used for the PURGDAYS calculation. That is, if you checkpoint a configuration and load it one month later, and then start the topology manager with PURGDAYS=15, all resources are purged (equivalent to a cold start).

Additional information about the topology manager warm start, especially as it relates to planning considerations and performance, is in Using Warm Starts and Cold Starts.

Automatic Monitor of Newly Discovered Nodes

As updates occur in the SNA network, nodes send dynamic updates to the topology manager. As the topology manager discovers these nodes, it creates them in RODM. However, the network topology of these newly discovered nodes is not monitored unless you explicitly request it.

The topology manager is supplied with a set of default values for monitoring topology. These default values are saved to RODM and are retained across restarts of the topology manager and of NetView. The values are lost if RODM is cold started.

The TOPOSNA SETDEFS command is used to modify the defaults for the retry policy of topology monitor operations and to modify the defaults for the automatic monitoring of local topology at newly discovered nodes. Specifically:

Retry (NETRETRY=, LCLRETRY=, and LURETRY=) sets the limits and intervals the topology manager uses to retry failed network, local, and LU topology monitoring operations.
Automatic monitoring (AUTOMON=) indicates how the topology manager handles newly discovered nodes in the network. A YES or NO value determines whether the topology manager automatically starts local topology monitoring and network topology monitoring for the newly discovered nodes in the network. Newly discovered nodes are nodes created in RODM as the result of a topology update.

AUTOMON Parameter Options

The AUTOMON parameter on the TOPOSNA SETDEFS command specifies whether to automatically monitor local or network topology of newly discovered nodes. You can set the parameter to apply to network nodes, end nodes, interchange nodes, migration data hosts, type 5 nodes, and cross domain resource managers (CDRMs). The following AUTOMON options of the TOPOSNA SETDEFS command are applicable to local and network topology automatic monitoring:

ALL: Specifies local and network topology monitoring for newly discovered nodes (subarea or Advanced Peer-to-Peer Networking).
Note:

This can cause more than one Advanced Peer-to-Peer Networking network monitor within the same subnetwork when VTAM is an interchange node.
ENLOCAL: Specifies local topology monitoring for newly discovered appnENs and migrationDataHosts.
NNLOCAL: Specifies local topology monitoring for newly discovered appnNNs and interchangeNodes.
SALOCAL: Specifies local topology monitoring for newly discovered t5Nodes, interchangeNodes, migrationDataHosts, and crossDomainResourceManagers.
SANET: Specifies network topology monitoring for newly discovered t5Nodes, interchangeNodes, migrationDataHosts, and crossDomainResourceManagers.

For a complete description and correct syntax of the TOPOSNA SETDEFS command, see the NetView online help.

Initialization File Parameters for Automatic Monitoring

Topology that is gathered automatically is limited to the network identifiers you specify in the NETID_LIST in the FLBSYSD initialization file. If you are migrating from the NetView V2R4 APPNTAM feature, specify your network identifiers (snaNetIDs) to achieve the same function that you had previously.

In addition, you can set a parameter under the AUTOMATIC_TOPOLOGY category in the FLBSYSD initialization file to automatically collect topology from the VTAM that is local to the topology manager. See Modifying the FLBSYSD Initialization File for more information about FLBSYSD initialization file options and parameters.

Automatic Monitoring of VTAM Nodes Represented by CDRMs

Automatic topology monitoring of the VTAM nodes represented by CDRMs is started only when the CDRM has an OSI status of UEA (administrativeState=unlocked, operationalState=enabled, and usageState=active). If it does not initially have an OSI status of UEA, automatic local topology monitoring starts when the CDRM OSI status changes to UEA. With this support for network topology, you can automatically discover VTAMs that are functioning as subarea nodes.

Feedback

[ Top of Page | Previous Page | Next Page | Contents ]