Differences in Monitoring Network, Local, and LU Topologies

It is important to understand how your decision to monitor network, local, or LU topology can affect what you see in the views. Each topology displays different information.

As an example, with Advanced Peer-to-Peer Networking®, it makes a difference whether you collect local topology on ENs or on NNs, both in terms of the objects that are present in the views and in how you interpret status. In addition, because the ACTIVATE, INACTIVATE, and RECYCLE commands are issued against various real resources, you must have already obtained the appropriate topology to use these commands from the NetView® management console menus.

Your choices also affect performance. Monitoring local topology or LU topology increases the volume of data sent to the topology manager and RODM because of the additional objects involved. Your choice can also cause frequent view changes.

This section describes the differences between monitoring network, local, and LU topologies so that you know when to use these options. Examples of some options are demonstrated and described in SNA Topology Manager User Scenarios in the sample Advanced Peer-to-Peer Networking network views.

Monitoring Advanced Peer-to-Peer Networking Network Topology on NNs (No Advanced Peer-to-Peer Networking Local Topology)

Each NN maintains a copy of the network topology of its subnetwork. This topology database is duplicated in every NN in the subnetwork. The topology manager obtains this data from the nodes and displays the following information:

• All NNs, virtual routing nodes, and interchange nodes (a type of NN) in the subnetwork
• All TG circuits and TGs between these nodes in the Advanced Peer-to-Peer Networking subnetwork

Because the topology data is duplicated in every network node, you only need to request network topology from a single network node to obtain the network topology of the subnetwork. Network topology, therefore, can include nodes that do not have the topology agent installed. You can obtain network topology only from NNs that have an agent installed. Network topology is not available from ENs.

Why Use Network Topology without Local Topology

Network topology displays the nodes and connections used for network routing in the Advanced Peer-to-Peer Networking subnetwork. If you want to monitor just those nodes and connections that are important for Advanced Peer-to-Peer Networking network routing, use network topology without local topology. Local topology displays additional nodes and connections that are not part of Advanced Peer-to-Peer Networking network routing.

What Do You Give Up by Not Monitoring Local Topology

Without local topology, you cannot view, navigate to, or issue NetView management console menu commands against underlying ports and links in the network. The view navigation ends at NNs and their interconnecting TGs. You cannot view or navigate to ENs and LEN nodes in the NN domains. This also means that the status of TGs to ENs is not part of the aggregation calculation. Although underlying resources might actually exist in the Advanced Peer-to-Peer Networking network, the data for these resources is not in RODM until you collect it by monitoring local topology.

Lack of local topology data also has implications for TGs and TG circuits that use demand-activated links:

• The status of TGs and TG circuits that use demand-activated links is displayed as satisfactory. Because no local topology is collected, the topology manager is unaware of the link status. As a consequence, even if the demand-activated link is inactive, the TG and TG circuit are still shown as satisfactory.
• TGs and TG circuits from NNs to ENs and LEN nodes are not shown in the views. Only TGs and TG circuits between NNs, and between NNs and virtual routing nodes, are displayed.

Monitoring Advanced Peer-to-Peer Networking Network and Local Topologies on NNs (No Advanced Peer-to-Peer Networking Local Topology on ENs)

The local topology of a node is specific to that node. Monitoring local topology of NNs adds information about their TGs, links, ports, and adjacent ENs and LEN nodes that is unavailable from network topology.

With this type of monitoring, you can display views of the following resources:

• The NN domain, which includes the network node, and all TG circuits to served ENs. This view also shows TG circuits to adjacent NNs and to virtual routing nodes.
• Local topology of an NN, which includes everything in the NN domain view, plus TG circuits to all adjacent nodes and the adjacent nodes themselves.
• The TGs, logical links, and ports associated with the NN.

Why Monitor Network and Local Topology on NNs But Not on ENs

This type of topology monitoring displays status and configuration information for the entire network node domain. This information is useful for understanding and navigating to the underlying links and ports and also connections to the adjacent ENs and LEN nodes. Monitoring local topology of a network node is useful for determining which resources lose Advanced Peer-to-Peer Networking services if the network node has a problem or loses access to the network. The aggregation calculations are more comprehensive when you are monitoring the local topology because it includes the connections to served ENs.

Including local topology of network nodes might be the best way for you to monitor most resources in your network without the added performance hits of monitoring EN local topology. The added performance costs occur because monitoring of EN local topology adds many more resources and topology flows to the RODM processing.

Monitoring local topology data on NNs but not on ENs has implications for TGs and TG circuits with demand-activated links. The status of the TGs or TG circuits from NNs to ENs or from NNs to NNs is displayed as intermediate when the underlying demand-activated link is inactive. Because the local topology is monitored, the topology manager has the link status data. (TG circuit status is calculated according to the rules in Table 21).

When the underlying demand-activated links are activated, TGs and TG circuits are displayed with satisfactory status.

What Do You Give Up by Not Monitoring EN and BrNN Local Topology

If you have never monitored EN local topology, those objects are not in RODM and cannot be displayed in views. Note that you do not need to be actively monitoring local topology for the objects to be in RODM, just that you have previously obtained local topology (and the resources have not been purged).

Without local topology of ENs and BrNNs:

• You do not see every resource in the network because the local information about ENs and BrNNs is not displayed (ports, links, and any connections between ENs and branch network nodes and from ENs and BrNNs to LEN nodes). For example, if an EN is connected to a LEN node, the only way to display the LEN node in a view is to monitor the local topology of the EN.
• TGs and TG circuits between ENs are not shown in the views when local topology for ENs or branch network nodes has never been obtained.
• TGs and TG circuits between BrNNs are not shown in the views when local topology for BrNNs has never been obtained.
• Because you cannot see the logical links and ports of ENs and BrNNs, you cannot issue the ACTIVATE, INACTIVATE, and RECYCLE commands against these resources using the NetView management console menus.

Monitoring Advanced Peer-to-Peer Networking Network and Local Topologies on NNs and Advanced Peer-to-Peer Networking Local Topology on ENs and BrNNs

Monitoring Advanced Peer-to-Peer Networking network and local topology on NNs and Advanced Peer-to-Peer Networking local topology on ENs and branch network nodes displays information about every resource in the network that has an agent. Monitoring local topology of ENs and BrNNs adds information about their TGs, links, ports, adjacent ENs, and adjacent LEN nodes to the views. TGs and TG circuits between all types of nodes (NN to NN, NN to EN, NN to BrNN, NN to virtual routing node, EN to EN, EN to virtual routing node, NN to LEN node, and EN to LEN node) are displayed in the views. When demand-activated links are inactive, TGs and TG circuits show intermediate status. Once the underlying links are activated, the TGs and TG circuits that use these links show satisfactory status.

This way of monitoring provides more comprehensive views; however, it can mean performance trade-offs if you have a large number of nodes and connections in the network. In addition, the complexity of the views displayed increases because of the number of objects in the views.

Monitoring Subarea Network, Local, and LU Topologies

For subarea networks, network topology includes the CDRMs that are part of active CDRM definitionGroups at the VTAM® (t5Node, interchangeNode, or migrationDataHost) to which the network topology request was sent using the command:

TOPOSNA MONITOR NETWORK NODE=netid.cp

For a subarea local topology monitor request, all resources that are known at the VTAM (t5Node, interchangeNode, or migrationDataHost) to which the request was sent are reported using the command:

TOPOSNA MONITOR LOCAL NODE=netid.cp

These resources include the following resources:

• The port objects that reside at the VTAM node and any owned t4Nodes
• The logicalLink objects that reside at the VTAM node and any owned t4Nodes
• Owned t4Nodes
• The subareaTransmissionGroup objects
• The t4Node or t5Node on the other side of the subareaTransmissionGroup
• CDRMs that are part of active CDRM definitionGroup objects

The exceptions are the following resources:

• logicalUnits
• luGroups
• crossDomainResources (CDRSCs)

Use a TOPOSNA MONITOR LUCOL NODE=netid.cp command to monitor the logicalUnit, luGroup, and crossDomainResource objects that reside at the VTAM node. Use the LCLNAME parameter to monitor the LU and CDRSC objects that reside at a logicalLink.

For VTAMs that are functioning as both a subarea node and an Advanced Peer-to-Peer Networking node, the network and local topology contains a combination of Advanced Peer-to-Peer Networking and subarea resources.

Monitoring Topology on a Remote Subarea VTAM

When you want to specifically monitor network topology from VTAMs that are functioning as subarea nodes, start the collection of network topology for a known, single t5Node, interchangeNode, or migrationDataHost. The VTAM responds with all crossDomainResourceManagers that are known to it. If the VTAM is an interchangeNode, the Advanced Peer-to-Peer Networking network topology is also sent.

You can then bring up the view of crossDomainResourceManagers and select one of the crossDomainResourceManagers. Run the previously built command profile containing the TOPOSNA MONITOR, (NETWORK, LOCAL or LUCOL) commands. See Adding Topology Manager Commands to the Menus for information about building a command profile.

The SNA topology manager resolves the OBJECTID of the remote VTAM and sends the requests to the remote VTAM. See Figure 26 for a pictorial example.

Figure 26. Monitoring a Remote VTAM

If the network ID is not known (unknown to the t5Node that reported the crossDomainResourceManager), an error message is displayed that states that the TOPOSNA command has failed.

Monitoring LU Topology on VTAM Nodes

Assume you are a help desk operator and have already started monitoring local topology on the two VTAM nodes (SSCP1 and SSCP2) in NETA. A user calls and reports the inability to log on to an application, and the user knows the LU name. To determine the status of the LU, perform a Locate Resource command with the Extended Search option selected.

If you perform the locate LU function and specify an LU resource name that is not fully qualified, such as NETA.LU1, two Configuration Parents views might be displayed on your screen, as shown in Figure 27 and Figure 28. Whether you get one or two views depends on your environment (Advanced Peer-to-Peer Networking, subarea, or mixed). See Locating LUs in the Network for additional information about environment considerations when locating a logicalUnit object.

Figure 27. Configuration Parents View of LU1 from SSCP1 Perspective

If you know the fully qualified name to be NETA.SSCP2.NETA.LU1 (our example value) and specify it when you perform the locate LU, the SNA topology manager displays a Configuration Parents view such as that shown in Figure 28.

Figure 28. Configuration Parents View of LU1 from SSCP2 Perspective

To monitor the LU collection, which in this example is a collection of one, perform one of the following tasks:

• Specify a TOPOSNA MONITOR,LUCOL command on the command line, providing the VTAM name (snaNetID.SSCP_name) for the NODE= parameter and the logicalLink object name for the LCLNAME= parameter. For example:

  TOPOSNA MONITOR,LUCOL,NODE=NETA.SSCP2,LCLNAME=PU1

• Navigate to the logicalLink object and select More Detail to have the SNA topology manager issue the command automatically.

When the LUCOL is run for the logicalLink named PU1 at agent SSCP2, Figure 28 evolves to Figure 29.

Figure 29. Configuration Parents View after TOPOSNA MONITOR,LUCOL Command

Independent LUs are put in context of the logicalLink only by a TOPOSNA MONITOR,LUCOL command, where the LCLNAME parameter equals the logicalLink_name of the used logicalLink. If NETA.LU1 was a dependent LU residing at PU1, the LU is immediately placed in context of the logicalLink and Figure 29 is displayed instead of Figure 28.

Note these several points relative to LU topology:

• For each LU of the same name in the same network ID, one or more LU images exist, and each LU image is treated independently by the SNA topology manager. For example, in Figure 29, the logicalUnit object (LU1) is one object from an SSCP2 perspective, another image is NETA.SSCP1.NETA.LU1 (see Figure 27).
• Only one logicalLink object exists; its name is the PU_name (PU1), and it is multiply owned by the SSCP1 and SSCP2 nodes.
• Application LUs can have a different geometric shape depending on the setting of the UNIQUE_LU_APPL_DRT parameter in the FLBSYSD initialization file (see Parameters to Control View Information Processing).
• For noncritical LUs, the LU is deleted from the RODM data cache when the LU is not being monitored for one of the following reasons:
  • An LU Collection is stopped.
  • All views are closed that contain LUs that were presented because the NetView management console Locate Resource with the Extended Search option selected was performed.
  To prevent the deletion of the LU from the RODM data cache, either start a continuous monitor by using the TOPOSNA CRITICAL command (see How to Monitor Critical Resources) or change the value of the FLB_Creator field in RODM (see the IBM Tivoli NetView for z/OS Data Model Reference for more information).

Determining the Agent When Monitoring LU Topology of a Multiply-Owned logicalLink

When a logicalLink is owned by more than one VTAM, monitoring the collection of logicalUnits residing at the logicalLink can be accomplished by selecting the logicalLink on a view and running the More Detail command.

The SNA topology manager performs the following steps to select the VTAM topology agent for the monitoring of the collection of logicalUnits:

1. Query the status history entries in the SNA topology manager data cache.
2. Determine which VTAM agent has reported the selected logicalLink as active (operationalState equals enabled and unknownStatus equals false) and has the most recent time stamp. If all status history entries are inactive (operationalState not equal to enabled), the entry with the most recent time stamp is used.
3. Monitor the collection of logicalUnits that reside at the selected logicalLink from that VTAM agent perspective by issuing the following command:

   TOPOSNA MONITOR,LUCOL,NODE=netid.cp,LCLNAME=localname

   Where localname is the local name of the logicalLink, and netid.cp is the network qualified name of the control point of the agent node.

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