There are many reasons to migrate from subarea to APPN. Obviously, where SNA routing is required, migrating to APPN allows you to replace aging FEPs with newer, more flexible and less costly technologies. In addition, APPN is required to take full advantage of the Parallel Sysplex environments. HPR can improve network availability. Another key benefit of APPN is the simplification of SNA network configuration. Maintaining an SNA network can be resource intensive. By taking advantage of the capabilities of APPN, you can free system programmers from having to do repetitive tasks. Skilled resources can then be redeployed to support next-generation network and application rollouts.
The good news is that it is relatively simple to enable APPN in the data center and in VTAM.
VTAM can be configured as one of several types of APPN node, each of which provides a different level of subarea and APPN function and interoperability. The implementation depends upon whether the node or nodes to be converted need to communicate with other subarea nodes, other APPN nodes, or both. A description of the APPN node types follows.
The most common migration step for a multidomain network is to migrate the CMC VTAM subarea host to an ICN. An ICN combines the function of a subarea node and a network node. It implements APPN NN functionality, SSCP functionality, and CDRM functionality. The location of an ICN is on the border of an APPN network and a subarea network. Here it provides conversion between subarea and APPN protocols and enables the establishment of sessions between applications residing on an APPN VTAM host to LUs residing in the subarea network by converting session requests from one protocol to the other. It can also provide intermediate session routing.
An ICN can own and activate NCPs; it communicates network control data by using SSCP-to-SSCP sessions with other subarea nodes and CP-to-CP sessions with other APPN nodes. To enable it to participate in the subarea network, it is defined with a unique subarea number and requires subarea path definition statements. An ICN can be connected to other APPN nodes, LEN nodes, and subarea nodes.
A migration data host (MDH) is a VTAM data host that communicates to APPN resources as an APPN end node and communicates to directly attached VTAMs and NCPs using subarea flows. Unlike an ICN, it doesn't translate between the two (APPN and subarea), and it cannot own NCPs or provide ISR routing. An MDH is often implemented during migration because it allows the data host to be accessed either from an APPN node (for example, a Cisco router) or from a FEP at the same time, thereby providing the safest migration alternative.
When VTAM is configured as an APPN EN or NN, it does not use SSCP-to-SSCP sessions. Instead, a it uses CP-to-CP sessions for network control data. Consequently, it does not require subarea network routing definitions. It requires static definitions only for those resources located within the APPN node and for local connections.
One other useful term to understand is a Virtual Route (VR) Transmission Group (TG). Virtual routes are end-to-end paths through a subarea network used to carry SNA traffic. A VR TG is a collection of virtual routes connecting two VTAM nodes that are acting as either ICNs or MDHs VR TGs allow CP-to-CP sessions between VTAMs to communicate using FID4 transmission headers and to take advantage of the multilink transmission group feature of subarea SNA. They can be used if the path between the APPN ICNs or MDHs contains subarea FEPs, but they can also be used for channel-to-channel (CTC) connections between hosts.
Was this article helpful?