Connecting an APPN node to VTAM

This topic includes information about:

Connections through boundary function-based transmission groups
Multiple Connections with Parallel Transmission Groups
Channel connections between APPN nodes
Leased connections between APPN nodes
IBM® 3172 Nways interconnect controller connections between APPN nodes
APPN multiple network connectivity
Virtual-Route-Based transmission groups
Selecting the network node server for end nodes

For a node to communicate with other nodes as a peer, rather than as a participant in a hierarchical relationship, the node must be aware of other APPN nodes. VTAM® nodes use a combination of the following available definitions and information to learn about adjacent nodes:

Definition of the physical line or port
Definition of the adjacent link station, either defined dynamically or predefined with PU definition statements
Transmission group number
Adjacent control point name

Before and during link activation between adjacent link stations, nodes also obtain information about the capability of an adjacent node through a message unit called an exchange identification (XID), which is used to convey node and link characteristics. XIDs are exchanged by adjacent nodes to establish and negotiate link and node characteristics. After link activation, XIDs are used to communicate changes in these characteristics and to negotiate the TG number used to represent the connection.

APPN nodes are connected using type 2.1 connections. APPN connections provide the same benefits as LEN connections. With APPN connections, you do not need to define CDRMs, PATH definitions, or ADJSSCP tables. You can dynamically define switched connections and independent logical units, and the connectivity of applications and dependent LUs is not limited.

Notes:

If you use VR-based transmission groups, CDRMs, PATH definitions, and ADJSSCP tables must be considered.
When changing the node roles of nodes in the network, a node should be taken down using normal takedown procedures. Forcing a node down and then bringing it up with a different node role can cause errors in the topology database, because error recovery might still be in progress when the node is brought back up.