SNA Server Challenges NetWare for SAA

Eliminate the Single Point of Failure from Your PC-to-Host Connection

To connect PCs on a LAN to an IBM mainframe or an AS/400, you have two options: Either you can connect each PC directly to the IBM host, or you can use an SNA (Systems Network Architecture) gateway. In the not-so-distant past, this choice was like being stuck between a rock and hard place. No matter which way you turned, there were problems. Direct connection meant that you had to run the SNA protocol on all of your systems as well as the LAN protocol that was already there. It also meant that you had to individually set up and administer every PC connected to the host. If you opted for an SNA gateway, it almost certainly meant using Novell's NetWare for SAA (Systems Application Architecture). While NetWare for SAA addressed the problems of direct connections, it brought its own set of challenges.

The introduction of Microsoft's SNA Server 2.1 in September, 1994, raised the stakes for LAN-to-IBM-host integration. SNA Server is a server application that takes advantage of Windows NT Server's user interface (UI) and robust architecture. Unlike NetWare for SAA, you can set up and configure SNA Server with easy to use point-and-click operations. In addition, NT Server, with its preemptive multitasking operating system, provides a stable and scalable platform. The advanced features coupled with Microsoft's aggressive pricing and BackOffice bundle make SNA Server a threat to NetWare for SAA's market dominance (see Figure 1 ). Since its release, SNA Server has made significant inroads in the LAN gateway market.

The SNA Server Connection
SNA Server is a software gateway that lets PCs on a LAN connect to IBM mainframes, such as the ES/9000, and IBM midrange systems, such as the AS/400. IBM mainframes and AS/400s both use IBM's SNA protocol as their primary method of communications. Since PC networks do not use SNA, gateways such as SNA Server provide the necessary SNA communications link required for PC-to-IBM-host connectivity. SNA Server is built on a flexible architecture that enables it to work with NT Server networks as well as with TCP/IP (Transmission Control Protocol/Internet Protocol), IBM LAN Server, and Novell NetWare networks.

SNA Server 2.1 provides some significant improvements over 2.0, such as greater compatibility with PC Support/400 (PCS/400) and Client Access/ 400 (CA/400), making it more attractive for IBM midrange and mainframe users. Other new features include increasing the number of clients allowed per server (from 250 to 2000 users) and the number of sessions (from 500 to 10,000). This gives SNA Server 2.1 the highest capacity of any SNA gateway available.

SNA Server was designed for protocol independence, which means it provides SNA connectivity for PC clients using a variety of LAN protocols. Release 2.0 supported clients using Internet Packet eXchange (IPX) and Named Pipes over NetBIOS Extended User Interface (NetBEUI), Remote Access Service (RAS), or TCP/IP. (Named Pipes is an interprocess communications (IPC) mechanism that runs on various network transports.) Release 2.1 has added AppleTalk, Banyan VINES IP, and native TCP/IP (which is implemented using Winsock-compliant TCP/IP sockets instead of Named Pipes).

Gateway to the Host
Like NetWare for SAA, SNA Server is a software gateway to IBM host computers. SNA Server requires NT Server 3.5 (or higher), and it supports DOS, Windows 3.1, Windows NT Workstation, OS/2, Mac, and UNIX clients. A Windows 95 client is also planned to follow the general availability of Windows 95.

SNA Server offers the same benefits as other LAN gateways. The LAN clients benefit by having lower resource requirements: They must support only the LAN protocol and don't need to run the more resource-intensive SNA protocol normally required to connect directly to IBM hosts. Running only one communications protocol is more stable than trying to make different protocols coexist, and it uses fewer client resources, so more memory is available to the PC nodes. Using a gateway also facilitates central administration. Instead of manually configuring each individual network node, a gateway gives you a single point for PC-to-host management.

This approach can greatly simplify the maintenance and administration of large networks. The host requires fewer resources because it communicates with only one control unit (i.e., SNA Server) instead of managing communications with each LAN node individually. Network traffic is reduced because the host needs to poll only one device. However, gateways often deliver a lower level of performance than direct connections because they introduce a single point of failure. SNA Server shares some of these problems while it solves others.

The software for SNA Server can run on the same system as NT Server (see Figure 2) or on a dedicated communications server. The LAN nodes communicate with it using a LAN protocol such as NetBEUI or IPX/SPX; communication with the host is via SNA connection.

SNA Server supports various SNA protocols, including LU 0, LU 1, LU 2, LU 3, and LU 6.2. Host connections via 3270 terminal emulation typically use LU 2 and LU 3 while AS/400 connections use LU 6.2 (Advanced Program-to-Program Communications, or APPC). SNA Server connects to the host at a peer level.

Making the Connection
For many AS/400 users, the most important facet of PC-AS/400 connectivity is PCS/400 and CA/400 compatibility. SNA Server provides it through the APPC LU 6.2 protocol. The current release of SNA Server supports PCS/400 and CA/400 functions such as 5250 emulation and file transfer. Shared folders are not fully supported (release 2.1 supports them only in a IPX environment).

For IBM mainframe users, SNA Server provides 3270 display and printer emulation through its support of LU 2 and LU 3. SNA Server is also compatible with NetView, IBM's mainframe-based network management product. You can use NetView's RunCmd function to execute SNA Server commands remotely. To connect PC clients to an IBM host, SNA Server encapsulates SNA requests from the clients within the network transport protocol being used (see Figure 3).

SNA Server consists of the server, which provides SNA connectivity to the host, and the client, which intercepts SNA requests from client applications and relays them to the server. SNA Server has different modules for DOS, Mac, OS/2, Windows 3.1, NT Workstation, and UNIX clients. These client modules are written for their native target platforms. For example, the DOS client module (figure 3) is an executable program that runs as a terminate-and-stay-resident (TSR) program, while the Windows 3.1 client module is a native Windows dynamic link library (DLL). Using SNA Server can eliminate the need for any memory-hogging TSRs as well as the need to support both SNA and LAN protocol stacks on all of the client systems.

While maintaining an SNA-based connection to the host, SNA Server conducts a networking connection with each connected node. The SNA Server client module takes the client request and packages it in the LAN's network transport protocol. For instance, if the LAN uses NetBEUI, the SNA requests are contained inside NetBEUI packets. If the LAN uses NetWare (SNA Server can coexist with a NetWare file server on a single LAN and use IPX as the network transport), the requests are wrapped in the IPX/SPX protocol. The client module sends the network packets (containing the requests) directly to SNA Server which pulls the packets off the LAN and routes the requests to the host.

As SNA sessions start on the host, SNA Server builds a dynamic session table that maps the host connections to the LAN client addresses. When the host responds to a request, it sends a response to SNA Server which looks in the dynamic session table to find the client PC's LAN address. SNA Server then wraps the response in the appropriate network transport protocol and sends it to the PC at that address. The PC client module separates the response from the protocol and feeds it to the client function.

SNA Server comes bundled with two applets for client system connectivity: a 5250 connectivity applet supplied by Wall Data and a 3270 connectivity applet supplied by NetSoft. These emulation applets don't provide the full range of features and capabilities found in the current crop of commercial Windows emulation products; they provide only the most basic 5250 and 3270 terminal emulation. They're limited to a single session, and they don't support advanced functions like multiple sessions, hot-spots, or floating command pads. You can use the applets to verify the connection to the host, but that's about all.

A Window on Administration
SNA Server supports several features designed to make multiple-system enterprise connectivity more robust and easier to manage. Most important is the hot-backup feature, which takes advantage of the ability to simultaneously connect multiple SNA Server gateways. If one gateway fails, client systems can be rerouted through another SNA Server. Naturally, any sessions that were active on the failed system will end abnormally, but client systems on the LAN can immediately establish new sessions with the host through the alternate gateway. This ability to support hot backups eliminates the single point of failure that is a weakness for most gateways.

Another closely related feature is dynamic load balancing. When multiple SNA Servers are available, they can split the load. Load balancing helps to optimize performance by moving new sessions to the SNA Server with the most available capacity. This helps to ensure that the LAN-host connection functions optimally without user intervention.

Another feature that makes SNA Server easy to administer is its ability to perform LU pooling. With it, you can set up a group of shared LUs eliminating the need to preconfigure dedicated SNA sessions for every node that wants to connect to the host. When an application requests a new session, SNA Server assigns an available LU from the shared pool. You don't need to configure the specific session before trying to start it. In addition, LU pools can be split among multiple SNA Servers.

Although SNA Server's real usefulness is behind the scenes in supporting LAN connections to an IBM host, all of its administrative and diagnostic functions are native Windows applications. You use SNA Server's Admin function to configure SNA Server, set up security, and configure LU pools. You can also use it to manage multiple SNA Servers.

Another diagnostic utility that comes with this product is the Trace tool. Trace records the communications activity between SNA Server and both the host and the client systems on the network.

Also, NT has several tools to gauge the status of SNA Server. The Performance Monitor has a graphical view into current system activity, providing information about CPU and disk utilization. NT comes with an Event Viewer that logs the system's history and lets you view the system, error, and security events recorded in the system event log.

Running SNA Server
The minimum requirement for SNA Server is a 486 system with 12MB of memory and 20MB of hard disk storage. Although exact requirements vary depending on usage, in general, a 16MB 486 should be able to handle 50 to 100 network connections. If you have a lot of activity or you don't want to tune your system, you should use a server platform with 32MB of memory. That's enough to handle about 300 SNA sessions. Although a single SNA Server will support up to 2000 clients, if you have more than 300 connections you should consider running a second copy of the software to get hot backup. SNA Server uses NT's flat memory model and can take advantage of all the real memory in the system. If application requirements exceed the amount of physical memory, NT uses virtual memory, paging the least-used sections to the hard disk.

If you must run with less memory, you can use NT's Performance Monitor to determine your actual requirements. The hard-disk light is a quick performance check. If you see a lot of disk activity, you're probably short of memory.

Because it runs on NT, SNA Server is portable to platforms other than Intel-based systems. If the gateway needs more processing power, it can run on an Alpha, PowerPC, or MIPS processor. SNA Server's scalability and load-balancing capabilities help to eliminate the traditional gateway-as-bottleneck problem.

SNA Server has an open driver interface and can use most of the popular network interface card adapters. It supports 90 different ones overall and can connect to the host using 802.2 Ethernet or Token-Ring LAN adapters. In addition, it can use a Fiber Distributed Data Interface (FDDI) or Synchronous Data Link Control (SDLC) adapter to make its connection to the AS/400. SNA Server supports a channel attachment to the mainframe only. Support for adapters for Integrated Services Digital Network (ISDN) adapters are planned.

No Single Point of Failure
SNA Server is a compelling choice if most of your LAN nodes are running Windows 3.1 or Windows for Workgroups. It lets you maintain a homogeneous, Windows-based environment between the server and client platforms. SNA Server is also a good choice to simplify LAN management. It centralizes administration and configuration for your IBM host connections. And it can stabilize client systems. In addition, SNA Server eliminates the critical single point of failure that plagues other gateways.

Using SNA Server, Windows NT--with its preemptive multitasking, flat memory model, and virtual memory management--provides a stable, robust platform for LAN-to-host connectivity.