How and Why Node Types Can Change

When creating node objects dynamically, the SNA topology manager specifies node types to RODM based on the information received from topology agents. In topology reporting, a node can be reported by several different nodes. These nodes might not have the same point of view or information about the reported node.

For example, two nodes might report the same node as an end node and a border node. In addition, if a link to a node is not active, Advanced Peer-to-Peer Networking might later report the node differently when the link becomes active (because more information is learned about the node).

The topology manager reconciles all duplicate and differing information about a node. You do not need to do anything to ensure the accuracy of the data. However, you do need to be aware that node types can change and that the views reflect these changes when refreshed.

Typical Reasons Node Types Change

The following descriptions contain examples of why node transformations typically occur.

More Detailed Information Is Learned about a Node

The following list includes examples.

• You have used the locate resource function for an LU that resides at a node that is not already being monitored (local topology or network topology). The node type is unknown; it is represented as an snaNode. You monitor the local topology of the node and the SNA topology manager learns that the node is an Advanced Peer-to-Peer Networking network node. The SNA topology manager changes its representation of the node from snaNode to appnNN.
• An Advanced Peer-to-Peer Networking agent node has an inactive link to an adjacent node. If the link definition does not include the adjacent node type, the agent reports the adjacent node as type 2.1. Once the link is activated, the true node type is reported (such as EN or NN).
  Note:
  The type 2.1 node is used when the link definition does not specify the adjacent node type.
• Advanced Peer-to-Peer Networking Subnetwork A has an NN connected to a border node in Advanced Peer-to-Peer Networking subnetwork B. Until Advanced Peer-to-Peer Networking subnetwork B reports on the border node, the NN in Advanced Peer-to-Peer Networking subnetwork A reports subnetwork B's border node as an EN. Once network topology is monitored from subnetwork B, its border node is upgraded to an NN with border node capability.

  With the new information from subnetwork B, the Advanced Peer-to-Peer Networking TG connection between the two NNs is now reported as a Advanced Peer-to-Peer Networking TG circuit with intersubnetwork TG capability. Previously, Advanced Peer-to-Peer Networking subnetwork A reported this connection as an Advanced Peer-to-Peer Networking TG circuit with CP-CP sessions but was not aware of the intersubnetwork TG capability. (The sample network provided with the topology manager demonstrates this example.)

• The SNA topology manager discovers a t5Node, but is currently not collecting topology directly from this t5Node. The topology manager collects topology (network or local) from an Advanced Peer-to-Peer Networking node that reports the existence of a node with the same name as the t5Node. If this node is reported as:
  • An appnNN, it transforms the t5Node into an interchangeNode (the node is reported as an appnNN when collecting local topology).
  • An interchangeNode, it transforms the t5Node into an interchangeNode (the node is reported as an interchangeNode when collecting network topology).
  • An appnEN, it transforms the t5Node into a migrationDataHost.
  • A migrationDataHost, it transforms the t5Node into a migrationDataHost (the node is reported as a migrationDataHost when collecting local topology directly from the node).
  • A t2-1Node or lenNode, it does not transform the t5Node; this VTAM® remains as a t5Node.
  Note:
  The NetView® program fully supports interchangeNode and migrationDataHost object classes, and actually transforms an object of the appnNN or appnEN object class to an object of the interchangeNode or migrationDataHost object class, respectively.

Node Type Was Inferred When Originally Reported

An EN (node 1) might report an adjacent EN (node 2) as a LEN node if node 2 does not support CP-CP sessions on the logical link to node 1. Node 2 might also have a link to a serving network node, which might later report node 2 as an end node. This transforms the original LEN node to an EN.

User Reconfigures the Node to a Different Type

Node transformations occur when a LEN node is reconfigured as an EN or when an EN is reconfigured as an NN.

User Defines a Node Incorrectly to RODM

When conflicting information is received in a topology report, the node is deleted (with possible loss of user data) and is then defined correctly in RODM. This is the only condition under which the topology manager overrides a user definition in RODM.

Transformation Implications

Transformation has implications for the object definition in RODM and can affect any user-defined objects you might have placed in RODM. For more detailed information, see the IBM Tivoli NetView for z/OS Data Model Reference.

Transformation Exception

In one scenario, transformation might not occur accurately because the SNA topology manager cannot detect a node type change. A timing condition can occur because VTAM cannot guarantee the order in which NetView receives information concerning a VTAM node type when that VTAM is recycled using the Z NET,CANCEL command.

The following list describes the scenario:

1. You are collecting local topology from one or more agents, and these agents report a connection to a VTAM node, but the SNA topology manager is not collecting topology directly from the VTAM node.
2. The SNA topology manager creates an interchangeNode or migrationDataHost that represents this VTAM node because one or more of the agents are reporting both subarea and Advanced Peer-to-Peer Networking connections to this VTAM node.
3. This VTAM node is recycled and reconfigured as either an appnNN, appnEN, or t5Node. The timing is such that the Advanced Peer-to-Peer Networking (for appnNN and appnEN) or subarea (for t5Node) connections are re-established before the other connections are reported as inactive:
   • Advanced Peer-to-Peer Networking: When the VTAM node becomes a t5Node
   • Subarea: When the VTAM node becomes an appnNN or appnEN

The VTAM node remains as the original node type (interchangeNode or migrationDataHost) until one of the following conditions occurs:

• You collect local topology directly from the VTAM node.
• You collect network topology directly from the VTAM node, if the VTAM node is reconfigured as an appnNN.
• All connections (both Advanced Peer-to-Peer Networking and subarea) from the agent nodes to the VTAM node are stopped. When the connections are re-established, only the subarea or Advanced Peer-to-Peer Networking connections are reported, and the VTAM node is transformed to the correct type.
• You stop the monitors to all agents that are reporting this adjacent VTAM node. Then restart the monitors.

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