Using advanced client-server architecture, Microsoft SNA Server offloads the communications processing from host computers and desktop PCs. Each PC uses standard networking protocols, such as TCP/IP, IPX/SPX, NetBEUI, Banyan VINES, or AppleTalk to connect to one or more SNA Servers. The SNA Servers connect to IBM mainframes and AS/400s using the SNA networking protocol. The SNA Server version 2.11 supports up to 2000 clients and 10,000 host sessions (version 3.0 supports 5,00 users and 15,000 host sessions, see The SNA Server 3.0 Features section later in this chapter) and offers advanced tools for easy system setup and centralized administration. It supports all standard PCs and network operating systems, LAN protocols, SNA host connections, and host types. Client computers and administrator workstations can connect to SNA Servers across LAN (local area network) and WAN (wide area network) bridges, routers, and over dial-up lines. The SNA Server, an integral component of Microsoft BackOffice, takes full advantage of the Windows NT Server operating system to deliver power, scalability, and security. Combined with the industry-standard SNA APIs, this foundation makes the SNA Server the most flexible platform for integrating PC and host environments.
FIGURE 38.1. The SNA Server environment overview.
The SNA Server also includes ODBC (Open Database Connectivity) drivers for access to DRDA (Distributed Relational Database Architecture) databases. The ODBC drivers support connectivity to the following IBM host databases: DB2 for MVS, SQL/DS for VM,
and DBS/400 for OS/400. With AFTP (Advanced File Transfer Protocol) services, files can also be downloaded from the host using FTP (File Transfer Protocol) commands. AFTP enables large file transfers between host and Windows NT-based systems to be
performed quickly using native SNA protocols, eliminating the need to install the CPU-intensive TCP/IP stack for the host. Also, the SNA Server acts as a proxy, which enables users on the Internet to access host information.
Microsoft SNA Server includes a full SDK with library and header files, and sample applications. It provides extensive support for industry-standard client and server protocols as well as APIs, making it an ideal tool for integrating diverse enterprise
systems. All SNA Server APIs (APPC, CPI-C, LUA, and CSV) are fully compatible with the WOSA (Windows Open System Architecture) SNA API standard.
The SNA Server enables enterprises to utilize legacy mission-critical applications and data available on IBM mainframes and AS/400s, by distributing these over the local area network to hosts PCs, while still providing reliable, fast, and secure access.
Although many organizations are moving to LAN-based PC client-server models, the generally accepted practice of running these mission-critical applications on IBM hosts is not likely to change soon. The ability of the Microsoft SNA Server to integrate
these mainframe applications and data into the corporate LAN in a fast, secure, reliable way, along with its centralized enterprise-wide management capabilities, make it an integral component of corporate computing environments.
In the early seventies, IBM discovered that enterprise customers required highly reliable and redundant communications networks to distribute mission-critical applications. In response, IBM developed Systems Network Architecture (SNA). SNA may be unique
in trying to identify literally everything that could possibly go wrong in order to specify the proper response. Certain types of expected errors, such as a phone line or modem failure, are handled automatically. Other errors—software problems,
configuration tables, and so on—are isolated, logged, and reported for analysis and response. This SNA design worked well as long as communications equipment was properly installed and managed by a competent staff. It was less useful in LAN
environments, in which any PC easily connects and joins the LAN.
An SNA network is comprised of host systems (mainframes or AS/400s), terminals (or PCs clients running terminal emulation software), printers, communication controllers, and cluster controllers. Terminals and printers connect to cluster controllers.
Cluster controllers connect directly to the host or communications controller. The terminals, printers, communication controllers, and cluster controllers are generally referred to as nodes. Nodes are endpoints or linkages in the network. There are
different types of nodes:
SNA requires a reliable network. When a packet of data moves between nodes, it must be checked for errors and either accepted or retransmitted. Only after it has been accepted will it be sent on to the next node. To achieve this reliability, SNA depends
on the connection-oriented protocols of High Level Datalink Control (HDLC). HDLC is an international standard developed in the seventies to provide simple, reliable modem communications. Because it is an international standard, it has a very broad
definition.
The HDLC definition leaves open many facets of the communications process. Communication can be full or half duplex. If a sequence of data packets is transmitted and one is found to be in error, the receiving node can request that the individual packet
or the entire packet sequence be resent.
IBM refined this ambiguous international HDLC standard. Instead of allowing multiple choices to resolve a problem, IBM modified the standard for their own devices, which required a specific response to be generated in a situation where the international
standard would allow multiple responses. Even though IBM-specific devices generate specific responses, they will permit devices created by other vendors to generate responses valid in the international standard. IBM took the HDLC standard and resolved the
uncertainties within it. It called this new protocol subset Synchronous Data Link Control (SDLC).
In the early seventies, most large U.S. corporate networks were developed using modems, leased phone lines, SDLC, and SNA. SDLC is based on the Normal Response Mode subset of HDLC. When the host system sends a sequence of packets to a 3270 control unit,
it pauses and waits for confirmation. The 3270 acknowledges that the data packets were received correctly, or it requests retransmission of the data packets starting with the packet discovered to be in error. The host node and the control unit
"talk" to each other in short packet bursts. The host node sending data packets to the control unit, and the control unit acknowledging packets or requesting retransmission. SDLC is a very linear protocol, with events happening in sequence and
producing immediate results. Figure 38.2 shows a typical use of an SDLC connection with the SNA Server.
FIGURE 38.2. View of the SNA Server utilizing an SDLC link.
X.25 is similar to the SDLC protocol. X.25 is a service provided by the phone company to accept and route individual data packets. In an X.25 packet-switching network, the network determines the most efficient means of transmitting packets from the
transmitter to receiver. The phone company charges by the packet for use. As with SDLC, X.25 is based on HDLC, but X.25 is based on a more complex subset called LAP-B (Link Access Protocol—Balanced). The Balanced mode is in contrast to the SDLC Normal
Response Mode. Both ends of an X.25 connection can send data simultaneously. Error correction and detection is still supported, although it is a more complex process. Figure 38.3 shows a typical use of an X.25 connection with the SNA Server.
FIGURE 38.3. A view of the SNA Server utilizing an X.25 link.
SDLC reflected the technology of the early seventies, before the invention of the microprocessor. The IEEE began work to standardize LAN communications utilizing the microprocessor. Because of the processing power available, the IEEE adopted the most
complex subset of the HDLC standard, called Asynchronous Balance Mode. IBM introduced its Token Ring technology after the IEEE 802 standards were released and integrated these standards into Token Ring communications.
In an HDLC or IEEE 802 connection, data is transferred as numbered units called I-frames. When a connection is established, both ends negotiate on the number of I-frames (called the window) that they can transfer between each other before requiring data
acknowledgment. In each I-frame that is sent, and in a separate control packet (Receiver Ready or RR) which is sent if there is no pending data, each end transmits which packet it expects to receive next. By doing so, it implicitly acknowledges that all
packets before that number have been received correctly. Each end should be able to receive the number of I-frames negotiated upon when the session was established, but if problems occur that stem the flow of packets (for example, a buffer overflow) a
Receiver Not Ready (RNR) message is sent from the receiver to the packet transmitter. Using just I-frames and the RR and RNR packets, it is possible to detect and correct communications errors. Other control packets can be used to increase efficiency, but
they are not required in the 802.2 standard. Figure 38.4 shows a typical use of a DLC/802.2 connection with the SNA Server.
FIGURE 38.4. A view of the SNA Server utilizing a DLC/802.2 link.
The DFT (Distributed Function Terminal)/Twinax networking protocol provides a connection between the communications controller and the host system over more modern coaxial or twisted-pair cables. The host system and communications controller are
directly connected to each other using a high-speed data link. The DFT protocol can support multiple user sessions. Figure 38.5 shows a typical use of an DFT/Twinax connection with the SNA Server.
FIGURE 38.5. A view of the SNA Server utilizing a DFT/Twinax connection.
When running an application, a user creates a session. A session is a channel to a network-addressable unit. An SNA network is comprised of logical and physical units. The resources associated with logical and physical units are discussed below.
Logical Units (LUs) are sessions. The following types of SNA network resources can be accessed through these sessions:
Physical Units (PUs) remain in the node that communicates with the host. They manage and control the communication link. There are three types:
Here are the two main software modules in an SNA network:
Two forms of SNA were developed: subareas, managed by mainframes, and APPN (Advanced Peer-To-Peer Networking), based on networks of minicomputers. In the original design of SNA, a network is built out of expensive, dedicated-switching minicomputers
managed by a central mainframe. The dedicated minicomputers run a special system called NCP. No user programs run on these machines. Each NCP manages communications on behalf of all the terminals, workstations, and PCs connected to it. Traffic is routed
between the NCP machines and eventually into the central mainframe. The mainframe runs an IBM product called VTAM, which controls the network.
The rapid growth in minicomputers, workstations, and personal computers forced IBM to develop a second kind of SNA. Customers were building networks using AS/400 minicomputers that had no mainframe or VTAM to provide control. The new SNA is called APPN
(Advanced Peer-to-Peer Networking). APPN and subarea SNA have entirely different strategies for routing and network management. Their only common characteristic is support for applications or devices using the APPC (LU 6.2) protocol. SNA is generally
viewed as a single networking architecture, although it would more accurately described as two complimentary architectures that can exchange data.
The more traditional SNA networking model is based upon a hierarchical approach, organized into subareas. The host system (a PU 5) is at the top of the hierarchy. The host system runs the VTAM, which manages the networking the sessions connected to the
host. There is only one PU 5-type device in the hierarchy or domain. Connected to the host system is the front-end processor (a PU 4). The front-end processor is an intelligent device that manages connections between the hosts system, devices, users, and
applications connected to it. The cluster controller (a PU 2) connects to the front-end processor, and manages the users and devices connected to it, in a specific area. Different types of LUs connect to the cluster controller—for example, LU 2 3270
terminals and LU 3 3270 printers. A typical subarea SNA configuration is shown in Figure 38.6.
FIGURE 38.6. Typical subarea SNA network configuration.
The SNA Server functions as an interconnecting network gateway in the subarea SNA model. The SNA gateway connects to the LU 1, 2, and 3 terminal and printer emulators running on the LAN PCs using standard LAN protocols (NetBEUI, IPX/SPX, TCP/IP, Banyan
VINES, or AppleTalk). Also, the SNA Server connects to the SNA network by emulating a cluster controller (a PU 2). The SNA Server is generally connected to the front-end processor utilizing the SDLC, X.25, or DLC/802.2 protocols. The SNA Server connects to
the front-end processor and manages all the LU device emulators running on the LAN. A typical subarea SNA model utilizing the SNA Server is shown in Figure 38.7.
FIGURE 38.7. A view of the SNA Server in the Subarea SNA configuration.
The rapid growth of personal computers and workstations created an evolution in SNA networking. The peer-to-peer SNA model was created to support the AS/400 minicomputer environment. The AS/400 environment had no mainframe or VTAM to rely upon to
provide control. Whereas the traditional SNA networking model can be viewed as an organized hierarchy, where increasingly intelligent devices connect to the host, in the APPN model each computer (PU 2.1) provides its own functionality to communicate on the
network. The APPN model is more similar to traditional LAN-based networking models. The hosts systems in the APPN model are usually AS/400s (PU 2.1). The AS/400s provide their own functionality to manage the LU connections to them. Normally, PCs (LU 6.2)
emulating terminals and printers are connected to the AS/400s over the LAN. APPN also allows two applications to appear as LU 6.2 devices on the network, and communicate with each other using the Advanced Program-to-Program Communication (APPC) protocols.
A typical APPN SNA model is shown in Figure 38.8.
FIGURE 38.8. A typical peer-to-peer/APPN SNA network configuration.
As in the subarea SNA networking model, the SNA Server functions as an interconnecting network gateway. The SNA Server emulates a PU2.1 type device on the SNA Network which manages the LU 6.2 sessions running on the PCs connected to the LAN. The SNA
Server emulates a APPN Low-Entry Network node. The SNA Server is generally connected to the AS/400 utilizing the DFT/Twinax protocol. A typical APPN SNA model that utilizes an SNA Server is shown in Figure 38.9.
FIGURE 38.9. An SNA Server in the peer-to-peer/APPN SNA configuration.
The SNA Server manages connectivity to the host systems and provides mechanisms to ensure their reliability. Two or more SNA Servers can be configured to handle multiple-user connections to a host. These SNA Servers can work together to balance the load
between the PC terminals and the host. Also, multiple servers can provide redundancy to eliminate a single point of failure.
SNA Server offers a standard windows interface, centralized monitoring and control, administrative tools, integration with Windows NT, security, reliability, capacity, enterprise configuration flexibility, a variety of host connectivity options,
complete SNA LU and PU support, host data access tools, client-server APIs, and remote access services. In the following sections, these features are described in detail.
The SNA Server utilizes the standardized Windows interface to facilitate installation, configuration, and management. The SNA Server Setup enables the user to configure SNA link services for installed adapters, specify the server role, and select LAN
client-server protocols. The SNA Server Setup also provides an option to completely remove the SNA Server from the system.
The Admin utility provides an easy-to-use interface to manage Servers and Connections, LU Pools, and Users and Groups. The Admin utility enables a user to filter and adjust displayed information to suit his or her needs. The Admin utility supports
standard drag-and-drop functionality to facilitate LU pool setup and user and group assignment. All information displayed by the Admin utility is dynamically updated.
Close integration with Windows NT Server permits monitoring and control of the SNA Server from a centralized location. The SNA Server provides a complete set of utilities to assist in the management of the SNA Server. The Admin utility can be run on NT
Server or Workstation, and it provides the capabilities for day-to-day management of the SNA Server. Integration with the IBM mainframe, host-based NetView application also permits communication with the SNA Server from the host system. Linking SNA Servers
with the Windows NT Server performance monitor creates a graphical interface for monitoring and troubleshooting SNA Server performance. The SNA Server can facilitate the centralized monitoring and control of the following SNA Server functions:
The SNA Server provides a number of tools to simplify administration. These utilities are closely integrated with Windows NT and can provide information regarding the events that occurred leading up to a difficulty. These tools and utilities are as
follows:
The SNA Server is tightly integrated with Windows NT Server. Windows NT Server provides consistent and user-friendly tools for the administration and management of the SNA Server, in a secure and reliable environment. The utilities and applets available
from Windows NT for the SNA Server are as follows:
The SNA Server provides a highly secure environment for SNA access. Through the use of hot backup and load balancing, the SNA Server also provides a highly reliable environment necessary for mission-critical SNA access in the largest of enterprises.
Enterprise Configuration Flexibility
The SNA Server can be located in two distinct enterprise locations. They can be located in branch offices (closer to the users) or in a centralized location (closer to the host system).
FIGURE 38.10. SNA Server Branch Configuration.
FIGURE 38.11. SNA Server Centralized Configuration.
FIGURE 38.12. SNA Server Distributed Deployment Configuration.
Many organizations utilizing IBM mainframes or AS/400s are in the process of moving from a hierarchical SNA network to an interconnected, TCP/IP-based LAN. Continued access to applications and data from these legacy host systems is a necessary
requirement during this migration process. The maintenance of separate SNA and TCP/IP networks can be cost prohibitive and problematic. Installing a TCP/IP protocol stack on the host system can be viewed as another alternative, but this can also be cost
prohibitive, difficult to manage, and it can degrade system performance.
The SNA Server is a split-stack SNA gateway, enabling access to host SNA data and applications for PCs on the LAN. WAN bandwidth capacities have become a factor, due to the overhead generated by the client-server traffic of the SNA gateway. The SNA
Server is the first gateway solution that can deploy split-stack gateway clients (where multiple protocol drivers need to be loaded into memory) in remote branch offices while maintaining the advantages of a Centralized Configuration.
The SNA Server provides a number of host-connectivity options and support drivers (called link services). Each single link can support only a single adapter; each link can support multiple sessions. The following connections types are supported by the
SNA Server:
The SNA Server supports the following Logical Units: LU 0, LU 1, LU 2, LU 3, and LU 6.2. The SNA Server supports the following Physical Units: PU 2.0, PU 2.1, APPN LEN Node, and Downstream PU (DSPU).
The SNA Server includes ODBC/DRDA (Open Database Connectivity/Distributed Relational Database Architecture) drivers for Windows and Windows NT clients. The ODBC driver enables database connectivity for applications such as Microsoft Excel and Microsoft
Access to IBM-host databases, without the need for an expensive host-based database gateway. The ODBC drivers support DB2 for MVS, SQL/DS for VM, and DBS/400 for AS/400. The ODBC/DRDA drivers provide an efficient and cost-effective means for accessing
host-based databases. Any Windows-application development tools that support ODBC connectivity (such as Microsoft Visual Basic) can access host-based databases from custom-created applications.
The SNA Server comes with a full SDK for building client-server solutions. The SNA Server supports the WOSA (Windows Open Systems Architecture)-compliant standard APIs for Windows and OS/2-based standards for OS/2. The SNA Server also supports IBM's
standard API for AS/400 systems, as well as the new EHNAPPC API. This provides a mechanism to write Windows-based applications that integrate with the AS/400 data and applications.
Remote Access Service (RAS) enables clients in remote locations to access SNA Server and Windows NT services.
RAS servers can be accessed from the SNA Server or any Windows NT Server in the domain, providing a remote connection to the SNA Network or LAN. All SNA Server functions are supported over RAS connections. Windows NT logon and domain security, data
encryption, and callback options are supported for RAS connections, ensuring secured remote access.
SNA Remote Access Service is a feature that allows administrators to create virtual LAN connections between Windows NT systems across an existing SNA network. This is accomplished by using SNA's LU6.2 transport mechanism with the RAS architecture,
enabling enterprises to leverage existing equipment to facilitate the SNA Server and host management. SNA Remote Access Services supports IPX, TCP/IP (PPP) and NetBEUI from Windows NT and Windows NT Workstation clients.
The SNA Server provides integration with other BackOffice components to deliver enterprise-wide connectivity solutions.
Integration with SQL Server is provided through the following services:
Integration with Systems-Management Server is provided through the following services:
Integration with MS-Mail and Exchange Server is provided through the following services:
In January 1996, Microsoft released a service upgrade to the SNA Server. Service Pack 1 for the SNA Server 2.11 included the following features:
Service Pack 1 for the SNA Server is available to download at ftp://ftp.microsoft.com/bussys/winnt/sna-public/fixes/sna211/ or on disk from Microsoft. The Intel version of the service pack is in the directory USSP1/WINNT/I386/, the filename is
211SP1IS.EXE.
To extract the Service Pack, copy the file to an empty directory on your hard drive and issue the command:
211SP1IS.EXE -d PATH
Where PATH is the destination directory for the service pack. If you wish to extract the service pack to the current directory, leave PATH blank.
After the service pack has been decompressed, stop all SNA Server services running on the machine (including SnaBase, TN3270, APPC transaction programs, and so forth) and run the UPDATE.EXE program to install the updated SNA Server 2.11 server files.
With the release of Windows NT Server Version 4.0, the SNA Server 3.0 will be available soon afterwards. The new version will feature the following:
It is estimated that more than 80 percent of all information on enterprise computer systems is available only through an IBM SNA network. Enterprise efficiency and competitiveness require that people using desktop PCs be able to access enterprise data
application effectively and efficiently. The SNA Server gives PC users reliable, fast, and inexpensive access to host data and applications, preserves the security and control of host systems, and frees up host and PC resources for what each does best.
The SNA Server reduces the need for client workstations to run dual protocol stacks to participate in the enterprise LAN and SNA Network. This increases client workstation support and stability. Hot backup and LU pooling help assure consistently
reliable access to host systems and data.
The SNA Server provides a number of tools to ease the administration of the SNA Network resources. All host changes can be tracked centrally at the SNA Server. The SNA Server provides integrated security for access to SNA Network resources, through the
use of the combined Windows NT Server and SNA Server security mechanisms. Performance and event-monitoring utilities are provided, easing the ability to diagnose SNA Network problems and the events that lead up to them.
The SNA Server can reduce the amount of network-definition work on host systems. Large numbers of users can be supported through a single PU controller. This can greatly minimize the number of times VTAM regenerations need to be run, which reduces host system downtime, frees up staff time, and reduces potential errors. The SNA Server also decreases host memory requirements and frees up host processing power for running applications. The SNA Server can also decrease network traffic. The host system no longer needs to poll each client terminal emulator connected to it. The host system just needs to maintain connectivity to the SNA Server, increasing network performance and reducing session time-outs. Through the use of hot backups, LU pooling, and load balancing, the SNA Server assures reliable access to enterprise host systems and data.
