## MS BackOffice Unleashed

- IBM Network Architecture (Mainframe and AS/400)
  - Linking SNA Networks
  - SDLC
  - X.25
  - DLC/802.2
  - DFT/Twinax
  - Sessions
  - Subarea SNA
  - Peer-To-Peer/APPN SNA Model
- Services Provided by the SNA Server
  - Detailed Features of the SNA Server
    - Standard Windows Interface
    - Centralized Monitoring and Control
    - Administration Tools
    - Integration With Windows NT
    - Security, Reliability, and Capacity
    - Host-Connectivity Options
    - Complete SNA LU and PU Support
    - Host Data-Access Tools
    - Client-Server Application-Development APIs
    - Remote Access Service
- Integration with other BackOffice Components
  - Windows NT Server
  - Integration with Windows NT Server is provided through the following services:
  - SQL Server
  - Systems-Management Server
  - Mail and Exchange
- Service Pack for the SNA Server Version 2.11
- The SNA Server Version 3.0 Features
- Summary

#
— 38 —

##
SNA Server Overview

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.

###
IBM Network Architecture (Mainframe and AS/400)

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:

- Type 2 nodes are generally endpoints, such as PCs running terminal emulation software, terminals, and printers.
- Type 4 nodes are communication controllers. Communication controllers link remote terminals to host systems. They service terminals connected to them by transmitting and receiving host data, detect and correct errors, and serve as concentrators for groups of terminals.
- Type 5 nodes control and manage the network.

####
Linking SNA Networks

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).

####
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

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.

####
DLC/802.2

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.

####
DFT/Twinax

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.

####
Sessions

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:

- Type 1 provides interactive batch transfers.
- Type 2, the IBM 3270 display terminal.
- Type 3, the IBM 3270 printer.
- Type 6.2, program-to-program communication.
- Type 7, IBM midrange computer sessions.

Physical Units (PUs) remain in the node that communicates with the host. They manage and control the communication link. There are three types:

- Type 2 resides in cluster controllers.
- Type 4 resides in front-end processors.
- Type 5 resides in host communication software.

Here are the two main software modules in an SNA network:

- Systems Services Control Point (SSCP) runs in the host and controls all the resources within the hosts domain. The host system runs the Virtual Telecommunications Access Method (VTAM), which contains the SSCP.
- Network Control Program (NCP) runs in the communication controller. It manages the communications with the host, including routing, session management, buffering, and error detection and correction.

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.

####
Subarea SNA

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.

####
Peer-To-Peer/APPN SNA Model

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.

###
Services Provided by the SNA Server

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.

####
Detailed Features of the SNA Server

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.

#####
Standard Windows Interface

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.

#####
Centralized Monitoring and Control

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:

- LU and User Management. The Admin utility permits management of users, user groups, and assignment of sessions for users given access to SNA Server resources. Admin also permits LU and LU poll assignment to users and user groups. C2-level security to SNA Server resources is provided through Windows NT Server user-management features.
- Configuration Management. The Admin utility enables multiple system configurations to be defined, saved, and edited. In a multiple SNA Server environment, the primary SNA Server keeps the master configuration files, which are automatically migrated to backup servers. This promotes the SNA Server's resource reliability; in the event that the primary SNA Server goes down, sessions are automatically rerouted to backup servers, even during the middle of an active session. Because SNA Servers in a single domain are aware of each other, they can distribute new sessions to servers with more available resources to help balance the load.
- Troubleshooting. The SNA Server provides extensive troubleshooting capabilities. The SNA Server provides the SNA Trace tool; support for 3270 terminal emulator Response Time Monitor; support for NetView, NVRunCmd, and NVAlert utilities; and integration with Window NT Server's Event Viewer and Performance Monitor.
- Connection Management. The Admin utility shows the status of the SNA Server and connection status (active, inactive, stopping, or pending). Connections can be created, removed, or stopped. Connections can be started manually, at server startup, or on demand. On-demand activation can be useful for activating backup SNA Server connections.
- Link Management. Utilizing SNA Server setup, new SNA link services can be installed, configured, or removed. Mappings between NT device-driver names and their associated Windows NT device drivers can be viewed. Individual device drivers can be activated and deactivated in the Devices applet of the Control Panel.
- Batch Mode Configuration. The SNA Server provides a command-line utility SNACFG to automate the configuration of the SNA Server. The command-line interface can also print a text version of the current SNA Server configuration.
- Remote Access Administration. The SNA Server Admin utility can be utilized over a Remote Access Service (RAS) link to facilitate centralized management of distributed SNA Servers. Only one domain can be administered at a time; the Select Domain command can be used to connect to different remote domains.

#####
Administration Tools

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 Admin utility can provide information regarding Server status (inactive, pending, active, or stopping), Connection status (inactive, pending, active, or stopping), and LU status (active or inactive, associated user, computer name).
- The SNA Trace utility can dynamically collect information on the activity of the SNA Server. The Trace utility can be started and stopped independently of the SNA Server. The information gathered by the trace utility can be effective in improving performance and diagnosing configuration problems.
- The SNA Server provides the ability for remote diagnosis. Microsoft support can log into the server and utilize the available diagnostic tools (such as the Event Viewer or Trace Tool). The remote diagnostic facilities can help resolve problems faster, without personnel having to be on site.
- The Response Time Monitor (RTM) is an IBM NetView tool that can monitor how long it takes the host to respond to a 3270 session request. The Admin utility can configure how often the RTM data should be updated. RTM is available only on supported emulators. The 3270 applet that is part of the SNA Server supports RTM data collection. RTM data can be utilized with Windows NT Server Performance Monitor.
- The SNA Server integrates with IBM's NetView network-management system, which runs on an IBM host system. NetView can help an administrator manage operations, diagnose network problems, and enhance system performance. With the NVAlert utility, alerts generated by the SNA Server can be passed along to the host systems. Alerts such as a full disk or inability to open a file can be processed.
- SNA Server integration with Netview’s NVRunCmd enables an administrator seated at a NetView monitoring console to enter Windows NT commands, to be carried out at a remote Windows NT SNA Server. In conjunction with the NVAlert utility, NVRunCmd is very useful in monitoring and quickly responding to reported problems. For example, if a disk-full alert is sent to a NetView operator, he or she could take the appropriate measures to free up disk space on the remote SNA Server.

#####
Integration With Windows NT

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:

- Control Panel. The Windows NT Server Control Panel provides SNA Server integration through a number of applets. The Services applet provides the ability to start, stop, and pause various SNA Server services. The Network applet provides the ability to install and configure network cards. Windows NT Server enables you to have one card running multiple protocol stacks or individual protocol stacks running on multiple cards. The Devices applet provides the ability to start, stop, and report the status of system drivers, network protocols, and adapter drivers. The Server applet provides the ability to monitor who is connected to the server and which shared resources they are utilizing.
- Performance Monitor. The Windows NT Performance Monitor provides the ability to monitor the real-time performance of the SNA Server in a graphical representation. Charts, triggers, tables of values, and logs can be generated. The Performance Monitor can track throughput and transmission volume for connections, LUs, and adapters—and, if supported by the terminal emulator client, response times measured by NetView RTM.
- Event Viewer. The Event Viewer can log and track significant events that occur on the Windows NT Server and the SNA Server. The Event Viewer can notify administrators of important events with pop-up messages and/or send information to a log file. The severity of errors that are recorded can be adjusted. The size of the log file can also be controlled. The Event View can filter recorded events by event types, date and time, source, category, user, computer, or event ID. Event logs can also be exported as comma-delimited files for analysis in a spreadsheet.
- User Manager. The User Manager creates and manages Windows NT Server user accounts and group accounts within a domain. The SNA Server utilizes these user accounts to manage access to SNA services. Any account created by the SNA Server or Windows NT Server is available for use by the other. This creates a single user-information repository that is efficient and secure.
- Server Management. Windows NT Server user accounts can be grouped into domains. The primary domain server keeps the user-account database. Users can log into other systems in the domain that have copies of the primary server user database. A single account provides access to all services within the domain (including files, directories, servers, and printers), providing an effective way to manage enterprise wide access.

#####
Security, Reliability, and Capacity

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.

- Security. Through the security measures designed to meet U.S. government C2-level compliance, via Windows NT Server domain logins, the SNA Server guards the most critical corporate data, by effectively preventing unauthorized access to the Windows NT Server and SNA Server. The sharing of the user database between the Windows NT Server and the SNA Server provides an effective, centrally managed mechanism to control access to SNA resources. The Admin utility can allow read-only, read-write, full-control, and no access. Full auditing measures are also supported through the use of the Windows NT event log.
- Reliability. The high reliability of the SNA Server is provided through the hot-backup and load-balancing capabilities. The hot-backup utility assures users continual access to their sessions if the SNA Server goes down. This is assured through multiple servers in a domain, or through multiple connections to an SNA Server. Through LU pooling, LUs (from one or more servers) are grouped together. If a data link fails, the SNA Server can reroute sessions to other functioning LUs in the pool. If an entire server fails in a multiserver domain, session can automatically be redirected to other functioning servers in the LU pool. In a multiserver domain, load balancing routes new LU sessions to the server in the domain that is the least busy, ensuring maximum response time.
- Capacity. The SNA Server can support up to 250 simultaneous PU connections, up to 2,000 clients per server, up to 10,000 LU sessions per server, and up to 50 SNA Servers in a domain for load balancing and hot backup. Making the SNA Server the highest capacity SNA gateway available on a PC platform.

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).

- Branch Configuration. In the Branch Configuration (see Figure 38.10), the SNA Server is located in a branch office, close to the actual end users. The Branch Configuration is a better choice when utilized over low-bandwidth WAN links. The Branch Configuration minimizes the WAN traffic and also increases user responsiveness through local-connection management. The SNA Server's remote-administration capabilities provide an effective means of managing the remotely located SNA Servers.

FIGURE 38.10. SNA Server Branch Configuration.

- Centralized Configuration. In the Centralized Configuration (see Figure 38.11), the SNA Server is placed in a centralized location close to the host system, maximizing security and reliability. The Centralized Configuration simplifies the load-balancing and hot-backup setup. Centralized Configurations are a better choices when a high-bandwidth WAN is available, or if enterprise operations are confined to a single location. A single, routable protocol (such as IPX or TCP/IP) can be utilized over the WAN to provide SNA Server access.

FIGURE 38.11. SNA Server Centralized Configuration.

- Distributed Deployment Configuration. The Distributed Deployment Configuration (see Figure 38.12) combines the strengths of the Branch and Centralized Configurations. In this configuration, branch-based SNA gateways connect to the host through centralized SNA gateways. The connection between the branch-based and centralized SNA gateway is via native LAN protocols such as TCP/IP. The SNA Server introduced the first architecture designed to meet TCP/IP and SNA Inter-networking requirements. SOGA (SNA Open Gateway Architecture) is a scalable framework for SNA enterprise gateways that offers multiple options to integrate branch offices via routed LAN internetworks with host computers.

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.

#####
Host-Connectivity Options

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:

- 802.2
- SDLC (Synchronous Data Link Control)
- X.25
- DFT (Distributed Function Terminal)
- Channel
- Twinax

#####
Complete SNA LU and PU Support

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).

#####
Host Data-Access Tools

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.

#####
Client-Server Application-Development APIs

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

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.

###
Integration with other BackOffice Components

The SNA Server provides integration with other BackOffice components to deliver enterprise-wide connectivity solutions.

####
Windows NT Server

####
Integration with Windows NT Server is provided through the following services:

- SNA Remote Access Service creates a virtual WAN over SNA networks to link two or more Windows NT Server LANs.
- The SNA Server's NetView Services enable host administrators to execute any NT command line from an IBM NetView console, make it possible to forward any Windows NT event-log message to NetView, and permit LAN administrators to view NetView performance data on any Windows NT Performance Monitor.

####
SQL Server

Integration with SQL Server is provided through the following services:

- ODBC/DRDA driver integrates host data from DB2, SQL/DS, and DB2/400 with Microsoft SQL Server.
- You no longer need expensive, single-purpose SQL-to-host database gateways to access host databases.

####
Systems-Management Server

Integration with Systems-Management Server is provided through the following services:

- SNA Remote Access Service supports all functions of SMS, including remote control of remote workstations over SNA networks.
- The systems administrator can utilize SMS software distribution, remote control, and other management capabilities even if the network is a host-based SNA network.

####
Mail and Exchange

Integration with MS-Mail and Exchange Server is provided through the following services:

- SNA Remote Access Service enables postoffice-to-postoffice connectivity over SNA networks.
- PROFS and SNADS gateways (third-party products) link host e-mail and scheduling to the Microsoft Mail and Exchange Servers.

###
Service Pack for the SNA Server Version 2.11

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:

- Distributed Gateway Service. Distributed deployment improves host response times and saves WAN bandwidth compared to the centralized model, while making host access more reliable and simplifying network management compared to the branch-based model.
- Support for TN3270E clients.
- FTP-AFTP gateway. The Service Pack includes a new server-based function to convert FTP file-transfer requests into AFTP.
- AFTP API support. The Service Pack adds a new API to automate AFTP file transfers programmatically.
- Support for ESCON channel attachment.
- Windows 95 client for the SNA Server.
- Support for SQL/DS and stored procedures in the ODBC/DRDA driver.
- Drivers for several new SDLC and X.25 adapters.

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.

###
The SNA Server Version 3.0 Features

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:

- SNA Print Service. This feature provides server-based 3270 and 5250 print emulation, allowing mainframe and AS/400 applications to print to any LAN printer supported by Windows NT Server or Novell NetWare. Host printing supports both LU1 and LU3 devices. AS/400 printing supports SCS line printing and pass-through support for host-based 3812 graphics-printing emulation. Printer-emulation sessions no longer need to be configured separately. Centralized control and greater sharing of printer resources is achieved.
- Increased Capacity. The SNA Server 3.0 now supports up to 5,000 users and up to 15,000 host sessions. Fewer centralized SNA Servers are required to support the entire enterprise. This higher capacity has become possible due to the channel-attachment solutions recently made available for the SNA Server, which offer throughput several times that of a Token Ring connection to the host.
- Single Sign-On To AS/400s And Mainframes. Integrated password synchronization and single sign-on covers the primary IBM mainframe operating system, OS/390 (previously MVS), the AS/400 operating system OS/400, and all desktop operating systems that are integrated with Windows NT Server security: Windows NT Workstation, Windows 95, Windows for Workgroups, Windows 3.x, MS-DOS, Macintosh, and OS/2. The unified sign-on feature of Windows NT Server permits clients users to log in once to gain access to all files, printers, databases, messaging systems, and other applications running on the Windows NT Server-based network. Password synchronization with AS/400 and other mainstream mainframe security systems make it possible to utilize one password for host and LAN access. User passwords are kept synchronized regardless of which environment—the host or the Windows NT Server-based computer—initiates the change.
- Data Encryption. Encryption of all data passed between the SNA Server and the client using the RSA RC4 data-encryption standard is now provided. Due to the SNA Server's client-server architecture, existing 3270/5250 emulators and applications written to the SNA Server's APIs will automatically provide encrypted sessions. This feature may be disabled on a user-by-user basis. Data encryption is also supported in the Distributed Configuration of SNA Open Gateway Architecture (SOGA), providing secure SNA Server-to-SNA Server communications across the Internet, Intranet and WANs. The centralized SNA Server can be placed next to the host in a secure room, providing host-to-client encryption of all client sessions without effecting host performance.
- Shared Folders Service. Similar to the Gateway Service for NetWare in Windows NT Server, Shared Folders Service permits PCs with no SNA client software installed to access "shared folders" files on an AS/400. The Shared Folders Service makes AS/400 files available to users as just an additional drive on the Windows NT Server. Windows NT Server security systems can be used to set permissions on the shared folders.
- TN5250 Service. The TN5250 Service enables any TN5250 emulator to connect to an AS/400 through the SNA Server without requiring a TCP/IP protocol stack on the AS/400. This frees up significant host processing power. The TN5250 Service also provides support for UNIX and Macintosh clients that were previously unable to connect to an AS/400 through the SNA Server.
- Support For TN3287 Clients In TN3270E Service. Adds support for the TN3287 print-emulation capability implemented in some TN3270 emulators.
- Syncpoint Support For APPC. The SNA Server 3.0's Software Development Kit (SDK) includes the addition of Syncpoint level 2 support in the WinAPPC API. The APPC Syncpoint API provides the coordination necessary to implement robust, cross-platform distributed-transaction processing in conjunction with host-based databases (for example, DB2) and transaction-resource managers (for example, CICS).
- SNA Explorer. SNA Explorer is a new, integrated administration tool. SNA Explorer is consistent with the look and feel of the Windows 95 Explorer, and it functions as the single point of control for configuring and managing all SNA Servers, host connections, sessions, users, security, auditing, and other functions in the same domain. SNA Explorer combines the administration of the SNA Server, TN3270 Service, TN5250 Service, SNA Print Service, Shared Folders Service, and Host Security into a single application.
- Improved Setup Programs. The SNA Server's client and server setup programs have been redesigned to be consistent with other Microsoft BackOffice and Office applications. The setup program supports the automatic upgrade of the SNA Server 2.1 and 2.11 to the the SNA Server 3.0. Microsoft Systems Management Server can be utilized to complete unattended and remote installations of the SNA Server and clients.

###
Summary

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.