Traditionally, PC desktops have been directly connected to IBM host systems, using SNA-only hardware adapters and SNA protocols across a dedicated SNA-only network. Initially, this meant installing a coax or twinax adapter in each PC, which was connected via coaxial or twinaxial cabling to a local IBM control unit, such as an IBM 3174 or IBM 5294. Later, this meant using a token-ring LAN adapter to connect PCs to controllers via the SNA Data Link Control (DLC) protocol. Control units in remote locations were connected to central host systems across leased-line Synchronous Data Link Control (SDLC) connections.
However, at the same time as organizations moved from coax and twinax to token-ring LANs, there emerged a greater need for access to non-SNA LAN file servers to meet the daily needs of PC users. For the most part, the SNA networks remained separate from the non-SNA networks. Each network had its own PC adapters, cabling, and protocols. The non-SNA LANs tended to be built across Ethernet using popular IPX/SPX or TCP/IP protocols. Non-SNA LANs were connected together over WANs composed of routers and bridges that supported non-SNA protocols only. Remote SNA controllers remained isolated on dedicated SNA-only SDLC leased lines.
Over time, organizations began merging SNA-only networks with non-SNA networks because maintaining separate SNA and TCP/IP networks was economically undesirable.
The first step towards integration was to use the same PC adapters and network cabling. Various industry standards and vendor-specific implementations have emerged to let SNA and non-SNA protocols share the same network. However, organizations learned through experience that mixing SNA and IPX/SPX or TCP/IP is like mixing oil and water. This is especially true in the case of WAN connections, where common reliability problems include DLC time-outs, poor and inconsistent host response times, and complex network management.
One remedy proposed by vendors has been to install a TCP/IP stack directly on the host system. However, this approach has its own disadvantages. Again, experience has shown that host performance often is degraded. In addition, some applications (such as host printing and host database access) will not work or require an investment in new TCP/IP-aware software. Also, IP address administration can present a far bigger network management challenge than supporting dual SNA and non-SNA networks. For more detail on these points, see "Integrating IBM Mainframes with TCP/IP Networks," a white paper produced by the SNA Server product unit, and "TCP/IP Connectivity in an AS/400 Environment," a white paper produced by Duke Communications and published
by NEWS/400 magazine. See "Integrating IBM Mainframes with TCP/IP Networks" on Microsoft's World Wide Web site at http://www.microsoft.com/sna. See also "TCP/IP Connectivity in an AS/400 Environment" on Duke Communications World Wide Web site at http://www.news400.com/Education/WhitePapers/tcpip/tcpip.htm.
Another remedy proposed by networking vendors is the concept of a LAN-to-SNA gateway. The gateway computer allows the PC desktops to access host applications and data using non-SNA protocols. The connection between the desktop and the gateway is via a common LAN protocol, while the connection between the SNA gateway and the host computer is via SNA. Microsoft SNA Server has the capability to provide LAN-to-SNA gateway services while providing a choice of network protocols, including TCP/IP, IPX/SPX, Banyan® VINES®, Microsoft Networking, and AppleTalk®.
LAN-to-SNA gateway solutions have become the de facto standard in providing access to host-based SNA applications for LAN-based PCs. One of the strongest motivations for using SNA gateways is to configure a single non-SNA protocol on every desktop, which improves stability of popular Windows® desktops and reduces PC memory usage. Other common features of SNA gateways include logical unit (LU) pooling, load balancing, and fault tolerance. These features provide greater availability of host logical units (LUs) and higher reliability of host connections.
Figure 2.1 SNA Server offers LAN-to-SNA gateway services supporting a broad range of LAN-based PC operating systems across popular LAN and WAN protocols.
Recent trends indicate that organizations are deploying large numbers of branch-based PCs that access multiple host systems through centralized SNA gateways. Centralized SNA gateway solutions offer high-speed channel and LAN-to-host connections. They also restrict the use ofSNA to the data center. However, this practice has revealed that most WANs cannot support heavy client-to-server (SNA gateway) traffic. The greater the number of clients, the slower the response time and the greater overhead on the wide-area network. This has prompted organizations to increase WAN backbone speeds, resulting in significant additional operating costs.
The typical network manager is now faced with the trade-off between (a) administrative savings offered by SNA gateway solutions and (b) the cost of additional network bandwidth required to achieve acceptable response times. In many cases, these trade-offs can be resolved by deploying SNA gateways to maximize available WAN resources. SOGA includes a number of flexible SNA gateway deployments that allow network managers to achieve the benefits of SNA gateway services without incurring prohibitive WAN operating costs.