CONSIDERATIONS FOR CHOOSING A PLATFORM
Cisco’s SNASw provides EE on a router, which is a great choice for many situations. Many distributed SNA solutions are implemented using an SNA product that does not support EE. Connecting these users through an SNASw router in a branch office allows the users to benefit from the availability and performance capabilities of EE.
IBM’s Communications Server and PCOMM products provide native EE support. SNA solutions implemented using one of these products will benefit from end-to-end EE support, resulting in significantly improved availability and a greatly simplified network. The new Communications Server for Linux on zSeries allows you to consolidate SNA branch office solutions onto a single mainframe.
SNA support for distributed users can be handled via EE on SNASw or IBM’s Communications Server, removing the need for FEPs to handle the distributed workload. This often results in only needing the FEP to handle SNA network interconnect (SNI), which provides SNA connectivity between enterprises. VTAM and NCP work together to establish SNI network boundaries, which allow enterprises to connect, but also provide network isolation. APPN has a function called Extended Border Node, which is an excellent replacement for SNI, and is being widely used.
WHAT ABOUT APPN?
APPN has been available for many years now; why would someone not use it? Most of the time the answer falls into one of two categories.
The first answer is “if it’s not broken, don’t fix it.” A traditional subarea net work has worked fine for many enterprises. However, even though the subarea network is not “broken,” there are a number of compelling reasons why it is no longer suitable for many enterprises. These reasons include the expense of maintaining separate IP and SNA networks, the need to improve availability, and the increasing bandwidth required as a result of consolidations and changing workloads.
The second answer is “fear of the unknown.” People who have supported mainframe networks for many years are comfortable with the definitions for SNI connections. The thought of throwing these away and having to deal with new, unfamiliar definitions makes them uncomfortable. Perhaps they have heard bad things from other people who tried to implement APPN and encountered many problems. We can tell you from experience that these fears are real. Migrating from subarea-based SNA to APPN is a significant change. The good news is many people have made this migration and are very happy they did. There is now a large base of experience on which to draw to help make your migration successful.
You can put SNA in the data center, regional centers, or even the branch office. What are some of the things to consider when making this decision? How do you plan to replace those OS/2 servers that have worked so well for all these years?