Special Edition, Using Microsoft BackOffice, Ch. 21

21 - SNA Server Preparation and Installation

by Jim Marshbank

  • Learn the basic concepts behind SNA Server - Enhance your understanding of SNA Server by learning what SNA really is, seeing some different SNA models, and becoming familiar with key SNA Server features.

  • How to prepare for your SNA Server installation - Acquaint yourself with the recommended installation preparation actions, planning decisions that need to be made early on, and helpful forms to document planned installation and configuration parameters.

  • How to install SNA Server with the SNA Server Setup program - Obtain the details on selecting client-server protocols, installing link services, and configuring the different types of link services.

  • How to perform some common SNA Server administrator tasks after installing SNA Server - Find out how the SNA Server Setup program can be used to accomplish post-installation actions. Step-by-step procedures are provided for some common SNA Server administrator tasks.


Microsoft's Systems Network Architecture (SNA) Server is a key component of the Microsoft BackOffice suite of server-based applications. It provides a way of accessing existing IBM mainframe-resident and AS/400-resident data from your desktop PC. Although the major focus of this chapter is on the SNA Server installation process, it is important that you understand some of the broad concepts behind IBM's SNA and Microsoft's SNA Server and the various network models in which they function. Therefore, before launching into a detailed discussion of the actions required to install SNA Server, a significant portion of this chapter overviews IBM's SNA and Microsoft's SNA Server to include a brief survey of some of SNA Server's more important features.

Understanding SNA Server

With the growing popularity of client-server computing in local area network (LAN) and wide area network (WAN) environments, businesses are demanding robust PC-based client-server solutions that provide accessibility to and control of corporate data across the enterprise. Although a large percentage of these businesses could benefit by moving from a traditional legacy (mainframe) system to a LAN-based PC environment, industry analysts agree that many of them will continue to run mission-critical applications on mainframe systems, not LAN-based PCs. This, coupled with the generally accepted position that traditional mainframe-style computer environments will continue to play a key role in major business enterprises for the foreseeable future, indicates that a significant number of businesses will establish and maintain computing environments that consist of multiple systems of various types in use simultaneously. Even if they eventually decide to migrate away from a mainframe environment to a pure LAN-based PC, client-server environment, that migration will probably be a long, arduous process during which data and applications residing on diverse types of platforms will need to be accessible across a variety of environments.

The challenge, therefore, is to build transitional strategies that leverage existing computing environments without jeopardizing reliable, fast, and secure access to corporate data via the desktop PC. These strategies must identify cost-effective solutions that make legacy data and applications accessible to heterogeneous collections of PCs and networks. At the same time, the capabilities of host systems or PCs cannot be sacrificed during the migration to a pure LAN-based PC, client-server environment. Any candidate solution must convincingly deal with a few critical management concerns if businesses are to implement new technologies in ways meaningful to their business operation. One concern is how to maintain control of sensitive information and manage access to that information in a secure and highly centralized manner while distributing client-server applications as close as possible to the end users. The other management concern is how to ensure that LAN administrators have total management control of all the PC desktops across the entire enterprise environment.

Some of the most prevalent enterprise computing environments today involve IBM mainframe-stored corporate data available only through IBM's Systems Network Architecture (SNA) network. Therefore, candidate solutions need to be cleanly integrated and closely coupled with these SNA networks to provide rapid, secure, and reliable data accessibility in a way that also convincingly satisfies the management control concerns of the enterprise. The Microsoft SNA Server, designed and developed for compatibility with IBM's proprietary SNA network, is just such a solution.

What Is SNA?

IBM's SNA, originally defined in the 1970s, is a set of communications protocols and message format specifications that provide for the integration of IBM hardware and software into a networked environment called an SNA network. While this architecture is indeed proprietary, the specifications embodied within it are well documented and available for third-party vendors to use in developing SNA-compatible hardware and software products, which can then be integrated into SNA networks. As a matter of fact, the popularity of SNA environments and their wide use around the world have created a de facto standard recognized throughout the industry.

Hierarchical SNA Model

The traditional SNA specification represents a hierarchical model (a vertical architecture) in which each device communicates with a more intelligent device above and a less intelligent device below. The IBM mainframe is at the top of the hierarchy. It is referred to as a Physical Unit Type 5 (PU 5) in standard SNA terminology. There can only be one PU 5 in an SNA domain, and it handles the actual computing. The typical applications that run on the PU 5 are Time Sharing Option (TSO), NetView (IBM's network management package), databases, the SNA network software called VTAM (Virtual Telecommunications Access Method), and other user-developed applications.

Below the PU 5 in the hierarchy is the PU 4, an IBM front-end processor that is directly connected to the PU 5 via a high-speed connection. The PU 4 is a highly intelligent device that handles the communications between the PU 5 and the users, devices, and applications throughout the network. The IBM cluster controller, PU 2, is the next device down in the hierarchy, as reflected in figure 21.1.

Fig. 21.1 - A simple diagram of the hierarchical SNA model.

The PU 2 communicates with the PU 4 via telephone line, token ring connection, local cable, or other physical connection. It directly controls the unintelligent devices at the bottom of the hierarchy on the SNA network. These unintelligent peripheral hardware devices consist of equipment such as CRT terminals, tape drives, and printers. The SNA network software knows these actual hardware devices only as logical addresses, and therefore, they are generically referred to as logical units, or LUs. LUs are of different types, and each unique type communicates with the PU 2 via a uniquely defined set of protocols in the SNA. Two of the more common LU types are CRT terminals (LU 2) and IBM 3287 printers (LU 1 and LU 3). Any user-defined device, which is by default non-standard, is an LU 0.

Peer-Oriented SNA Model

While IBM's SNA was originally developed for their hierarchical S/370 mainframe-oriented hierarchical network, it has evolved to accommodate the IBM AS/400 intelligent peer-oriented networks as well. In the peer-oriented SNA model, a horizontal model in which computers communicate directly with each other, each computer depends mostly on its own intelligence and does not rely heavily on help from a higher level device. Communication can be initiated anywhere, not just from a top-down host. The peer-oriented model is the general direction in which all computer networks are evolving, and IBM's stated direction for the future evolution of its SNA networks is to employ Advanced Peer-to-Peer Networking (APPN).

The peer-oriented SNA model of an APPN network (see fig. 21.2) is not completely horizontal, however. The larger computers in the IBM SNA APPN network are usually AS/400s, which handle all network routing functions and normal computing functions as well. These network peers, referred to as PU 2.1 devices, may offer various levels of service and network intelligence.

Fig. 21.2 - A simple diagram of the Advanced Peer-to-Peer Networking (APPN) SNA model.

The smaller computers, which are associated with the PU 2.1s, are typically PCs that provide terminal and printer emulation. These PCs appear as LU device type 6.2, and therefore are called LU 6.2 devices. These devices, as well as programs in an SNA APPN network, appear as LU 6.2 entities that communicate via LU 6.2 sessions by using Advanced Program-to-Program Communication (APPC) protocols. Two separate and totally independent programs running in an SNA APPN network, each one appearing as an LU 6.2 session, may also communicate directly by using APPC.

What Is SNA Server?

SNA Server provides a sophisticated, user-friendly business solution for accessing existing IBM mainframe-resident and AS/400-resident data from your desktop PC. It is essentially a high-speed internetworking gateway between the PC and IBM SNA network, connecting LAN-based PCs with IBM host systems running SNA protocols. As a server process running under the Microsoft Windows NT Server operating system, it is composed of both hardware and software components and is capable of concurrently running communications protocols from both the Windows NT network environment and the IBM SNA network environment. Additionally, the SNA Server provides extensions to other networking protocols such as TCP/IP and IPX. The SNA Server thus provides a high-speed window between the SNA network and the Windows NT network environments through which bi-directional communications can occur.

SNA Server emulates IBM S/370 and S/390 mainframe terminals, IBM AS/400 terminals, and IBM 3287 printers through its high-speed, bi-directional communications capability. It actually functions as a server node to the IBM SNA network and provides LAN-based PCs with direct access to data and applications residing on IBM mainframes and IBM AS/400 hosts. Because the PC can emulate an IBM terminal, applications running on the IBM host can display application screen faces and data directly on the PC. These data screens can then be manipulated, and application processes communicated back to the IBM host system.

One obvious additional benefit of having this data available at the PC is the capability to use standard desktop productivity software with the IBM host data. You can easily use word processors, spreadsheets, and presentation packages to manipulate and utilize the data in routine office productivity functions such as the following:

  • Drafting letters

  • Generating reports

  • Calculating statistical summaries

  • Developing professional presentations

Additionally, the printer emulation software allows you to gain access to and capture IBM print data at your network printer. You can even transfer files between the IBM host system and your LAN-based PC by using SNA Server.

SNA Server in the Hierarchical SNA Model

As an internetworking gateway, SNA Server concurrently runs two separate and different networking protocols. This capability allows the SNA Server to essentially belong to two separate networks at the same time, as shown in figure 21.3. The SNA Server fits into the SNA network by emulating the IBM PU 2 (cluster controller) and multiple LUs of type 1, 2, or 3. Thus the SNA network sees the SNA Server as a PU 2 with associated LUs. Client software applications within the Windows NT network that emulate LU 0 through LU 3 devices can then communicate with the PU 5 (IBM host) through the PU 4 (IBM front-end processor).

Fig. 21.3 - A view of how the Microsoft SNA Server fits into the hierarchical SNA network model.

SNA Server in the Peer-Oriented SNA APPN Network

As in the hierarchical SNA model, the SNA Server belongs to both the SNA network and the Windows NT network simultaneously. In the case of the peer-oriented SNA network model, the SNA Server fits into the SNA APPN network by emulating the IBM PU 2.1 network node with its associated LU 6.2 sessions (see fig. 21.4). It appears to the SNA APPN network as a PU 2.1 peer device and also as an APPN Low Entry Network (LEN) node. It allows software applications in the Windows NT network that emulate LU 6.2 devices to communicate with PU 2.1 devices or LU 6.2 applications within the SNA network.

Fig. 21.4 - A view of how the Microsoft SNA Server fits into the peer-oriented SNA APPN network model.

Surveying Features in Microsoft SNA Server

Numerous features have been designed into the SNA Server to make it one of the most powerful, reliable, and user-friendly internetworking products available today. Many of these features also greatly simplify the LAN administrator's difficult job of managing and controlling the enterprise network. Some of the more significant features are presented in the following list and then described in the rest of the chapter.

  • Enhanced, but still familiar, graphical user interface

  • Tight integration with Windows NT-type operating systems (Windows NT Version 3.1, Windows NT Advanced Server Version 3.1, Windows NT Workstation Version 3.5, and Windows NT Server Version 3.5)

  • Centralized monitoring and control

  • Enterprise configuration flexibility

  • Highly secure, reliable, and efficient

  • Numerous host connectivity options

  • Comprehensive client-server support

  • Robust administrative and diagnostic tools

  • LU pooling

  • Support for remote access service

Graphical User Interface (GUI)

SNA Server was designed to have the same look and feel as other Windows-based systems, thus potentially reducing your training and support costs. State-of-the-art GUI functionality, icon-based visual feedback, easy to understand dialog boxes with drag and drop features, and dynamic data updating help to make SNA Server intuitive to use and administer. Intelligent integration and design of dialog boxes has also minimized the number of windows necessary for installation and simplified setup and configuration tasks.

The SNA Server Setup program uses these GUI features to facilitate the rapid installation and configuration of SNA link services, adapters, and client-server protocols. It also allows the SNA Server roles to be quickly defined or modified and simplifies the thorough removal of SNA Server software from both server and client platforms if it is no longer needed.

The SNA Server Admin program eases the burden of SNA Server network administration by employing standard File Manager-type windows to define and configure the server, host, and client connections; LU pools; users; and groups. You even have the flexibility of tailoring these Admin windows to fit your individual viewing needs through column resizing and data filtering. Unique icons allow you to readily identify connection types and LU types as well as specific servers, connections, users, and LU pools.

Tight Integration with Windows NT-Type Operating Systems

The installation of SNA Server on top of the Windows NT Server operating system provides a tight integration with the Windows NT Server graphical tool set. This not only simplifies management of the host/PC interconnection for LAN administrators, but also ensures the viability of other SNA Server features such as security and centralized monitoring and control. Windows NT Server tools such as the User Manager, Server Manager, Performance Monitor, Event Viewer, and Control Panel applets actually appear as seamless extensions of the SNA Server:

See "A Survey of Windows NT Server's Administrative Tools," (Ch. 6)

  • User Manager. This tool allows you to create and manage all user and group accounts on the domain. SNA Server shares the accounts established by User Manager, and therefore, any account created on the Windows NT Server or the SNA Server is automatically registered for use on the other server as well. This single account database design allows you to specify which users and groups defined in the Windows NT Server domain will also be users and groups on the SNA Server.

  • Server Manager. A logical grouping of servers is called a domain. Server Manager allows you to manage various accounts on one or more domains. You can switch between domains, view all the servers on the selected domain, attach to servers on the domain, and manage servers on the domain. You can also alter the properties for each of the servers on the domain.

  • Performance Monitor. This tool is used to measure the performance of any server, including installed SNA servers, accessible over the network. Things such as connections, LUs, and adapter throughput and transmission volume can be measured on SNA servers. Monitored results are dynamically updated and can be viewed as charts, tables, and logs. In some cases, client response times can be monitored, but the client emulator needs to support the NetView Response Time Monitor (RTM) for this to be possible.

  • Event Viewer. You can use this tool to record and view predefined events that occur on the Windows NT Server or SNA Server systems. Event Viewer is very flexible and can easily be tailored to suit a variety of conditions and monitoring needs. For example, you can set the type and severity of events you want to be recorded, and you can put limits on the size of the log file. You can even provide disposition instructions that will automatically be carried out when the log file becomes full so that remaining events can still be recorded.

  • Control Panel. This is a collection of tools for Windows NT Server and SNA Server. It allows you to start and stop services; install, configure or remove network cards; install, configure, start, and stop system drivers; and monitor who is connected to your computer as well as identify the shared resources in use.

Centralized Monitoring and Control

The SNA Server's seamless integration with the Windows NT Server allows you to manage all the SNA servers from a single computer. The SNA Server Admin program, which can be run from any Windows NT platform, provides all the tools the SNA or LAN administrator needs to manage the daily operation of network interactions. From the IBM mainframe side, the NetView program, resident on the IBM host computer, provides the capability for the host operators to communicate with the SNA Server. The following list briefly describes some of the more important functions that can be performed through centralized management of the SNA Server environment.

  • Troubleshooting. The SNA Server either directly or indirectly provides a wide array of helpful troubleshooting tools such as the SNA Trace tool, support for the RTM, support for the NetView utilities NVAlert and NVRunCmd, Windows NT Performance Monitor, and Windows NT Event Viewer.

  • User and LU management. The SNA Server Admin program allows monitoring and management of users, groups, and sessions for users assigned SNA Server access. It also allows you to create LUs for specific connections and group them into pools, and then to assign specific users or groups to the various LU pools as a way of controlling access to SNA Server resources.

  • Configuration Management. The SNA Server Admin program allows you to manipulate multiple configuration files between and among primary and backup SNA servers. This facilitates hot backup in the event the primary server is lost. Additionally, because every SNA Server in the domain knows what the other servers are doing, new sessions can be distributed to less busy servers automatically to better balance the workload on each SNA Server.

  • Link services management. SNA Server Setup allows you to install, configure, and remove link services, and it also displays the mapping between the Windows NT device driver names and the SNA connections.

  • Connection management. SNA Server Admin allows you to monitor the status of SNA servers and connections as being active, inactive, pending, or stopping. It also allows you to create, remove, start, and stop connections; and it facilitates connection activation by providing options for manually starting the connection, having the connection start automatically upon SNA Server startup, or starting the connection on demand as clients have a need for it.

  • Remote administration. The SNA Server Admin program can be used across routers, bridges, and Remote Access Service (RAS) links to allow central management of distributed SNA servers. However, because the SNA Server can only be connected to one remote domain at a time, you can only perform administration operations on one remote domain at a time.

Enterprise Configuration Flexibility

SNA Server can be physically located in two distinct enterprise configurations: centrally at the main corporate office or data center, or in a distributed fashion where they are installed in branch offices. In the centralized configuration, one or more SNA servers are located in a single place, usually a controlled access data center, to maximize reliability (hot backups and load balancing are simplified) and security. Also with the centralized configuration, a single routable protocol (such as TCP/IP or IPX) can be used on all WAN links to connect clients on the WAN to SNA servers at the central site.

In the distributed configuration, SNA servers can be located at each branch office, possibly even utilizing existing Windows NT Server platforms that are already performing control functions for printing, database management, e-mail distribution, and fax operations. This configuration usually reduces heavy traffic on the WAN and improves management responsiveness to user needs and configuration changes since LUs, connections, security, and users can be managed locally at the branch office. Because remote administration of the local branch SNA Server can also be performed from another site (the data center or home office, for example) using RAS or NetView, there is not necessarily a need to have trained troubleshooting personnel at the branch office.

Highly Secure, Reliable, and Efficient

Controlled logon to the Windows NT Server domain provides enhanced security meeting the U.S. government's C2 level. Additionally, administrators can exercise tight local and remote access control from the LAN, the IBM host, or both through the use of a single user account database in the Windows NT Server domain. For more information, see the section "Implementing Security" later in this chapter.

Reliability is achieved through the hot backup capability, a unique benefit of the SNA Server's LU pooling feature. Hot backup is the term applied to the capability of immediately switching to the backup SNA Server when the primary SNA Server fails or becomes unavailable. This switching occurs without session interruption and without losing any session functionality or data. If you want to maximize the hot backup potential of your SNA Server, you should assign LUs from more than one SNA Server in each LU pool. Thus, if an SNA Server stops working, pool users can still get LU access through another SNA Server. In fact, the pool users will probably not even be aware that a server has malfunctioned. See the section "LU Pooling" later in this chapter for more information.

Efficiency is achieved through load balancing, another direct benefit of SNA Server's advanced LU pooling feature. In multiple SNA Server configurations, load balancing is the capability of each SNA Server to automatically route new LU sessions to the least-busy SNA Server. This dynamic routing of traffic across multiple servers minimizes response time and improves user productivity. You can prevent automatic load balancing by specifying which SNA Server should run a particular transaction program (TP). You accomplish this by using unique TP names or by associating each TP with a unique local LU alias. If you do not require specific control over SNA Server choices, however, you can certainly gain efficiency by allowing the SNA servers to distribute new workloads automatically based on existing TP availability.

Numerous Host Connectivity Options

SNA Server connects to the SNA network through a data link that is a combination of both hardware and software. The hardware is composed of a circuit board (communications adapter) that is installed in the SNA Server platform and provides a physical connection to the SNA network. These physical connections can be made using one of the following six possible connection types:

  • 802.2 connection type for Ethernet or token ring network configurations using the 802.2 communications protocol

  • Synchronous Data Link Control (SDLC) using leased telephone lines dedicated to the connection at all times or switched telephone lines connected as needed

  • X.25 for public or private packet-switching networks using the X.25 Qualified Logical Link Control (QLLC) protocol

  • Distributed Function Terminal (DFT) using local coaxial cable or twisted pair for the direct physical connection to an IBM cluster controller

  • Channel, which provides a direct channel attachment to an IBM mainframe

  • Twinax, which provides a direct twinaxial connection to an IBM AS/400

The software part of the data link is imbedded in an SNA Server component called Link Services. It provides communications between the SNA Server and the hardware communications adapters. Although a single link can only support a single adapter, each link can support multiple sessions.

Comprehensive Client-Server Support

SNA Server supports all the SNA application programming interfaces (APIs), LU protocols, PU protocols, and data link protocols. SNA APIs also support both synchronous and asynchronous calls. Synchronous calls support the native SNA communications schemes, but asynchronous calls can be more efficient in client-server environments. This is because asynchronous calls improve client-server I/O handling through the pipelining of I/O operations and independent processing of I/O requests while the application is performing other tasks.

The APIs supported by SNA Server include:

  • APPC for developing 5250 emulators, as well as applications that communicate peer-to-peer with other APPC applications using the LU 6.2 protocol

  • CPI-C for developing applications that communicate peer-to-peer with other applications using the LU 6.2 protocol

  • CSV for developing applications that include tracing of API calls, communication with NetView, and EBCDIC to ASCII conversion

  • LUA for developing applications that need direct access to the LU 0, LU 1, LU 2, and LU 3 data streams


The EHLLAPI for developing applications that interface with existing 3270 or 5250 applications is available from independent software vendors, but is not supplied by Microsoft. It is not currently included in the SNA Server applets.

The LU protocols supported by SNA Server include:

  • LU 0

  • LU 1

  • LU 2

  • LU 3

  • LU 6.2

The PU protocols supported by SNA Server include:

  • PU 2.0

  • PU 2.1

  • APPN LEN Node

  • Downstream PUs (DSPUs)

The data link protocols supported by SNA Server include:

  • 802.2/LLC

  • SDLC

  • X.25/QLLC

  • DFT

  • Twinax

  • Channel attachment

SNA Server also provides native support for many client-server protocols, including the following:

  • TCP/IP

  • Named Pipes

  • Remote Access Service

  • IPX/SPX

  • Banyan VINES IP

  • AppleTalk

SNA Server's flexibility in the area of client-server support allows you to mix clients using these protocols together, in any fashion, on the same SNA Server. For example, you can mix NetWare clients running the IPX protocol with TCP/IP clients on the same SNA Server.

The number of client systems supported by SNA Server is large, so connecting to practically any client desktop system with SNA Server is relatively easy. The client systems currently supported by SNA Server are as follows:

  • Windows 3.x

  • Windows for Workgroups

  • Windows NT Version 3.1

  • Windows NT Workstation Version 3.5

  • Windows 95

  • MS-DOS

  • Macintosh

  • UNIX

  • OS/2

Robust Administrative and Diagnostic Tools

As mentioned earlier, the tight integration of SNA Server with the Windows NT-type operating systems has provided a number of graphical tools that can be used to not only manage the network, but also perform diagnostic appraisals of the network functions and components. The diagnostic tools allow you to monitor and trace events and collect event information leading up to a specific problem occurrence. Thus, with effective event monitoring, you can tell the exact state of the system at the time of the difficulty.

The SNA Server Admin program can dynamically provide data on the server status (inactive, pending, active, stopping); connection status (inactive, pending, active, stopping); and the LU status (active or inactive, associated user, computer name). The SNA Server Trace program, which can be executed without stopping the SNA Server, collects information on the activity between and within the SNA Server components. This information can be extremely valuable in diagnosing configuration problems and improving performance.

The RTM, an IBM NetView function that measures response time between a host and a 3270 session, is another valuable diagnostic tool, but for you to use it, your 3270 emulator must be capable of supporting it. SNA Server Admin allows you to tailor the RTM by specifying such things as when the collected data should be sent and what triggers will cause the RTM to register responses from the host computer.

IBM's NetView is a network management system that runs on the IBM host. It is helpful to the network administrator because it receives alerts from the Windows NT system, or NT-based applications, and forwards these alerts to the host computer and the network administrator. It is also helpful in diagnosing problems and improving performance on the network. The NetView service that provides this functionality is called NVAlert. A companion service of NetView, NVRunCMD, runs as a background process on the SNA Server and is a command line interface to the Windows NT Server. It is extremely useful in responding to NVAlert messages for diagnostic querying or for providing simple fixes to problems. For example, if a NetView operator receives an alert indicating an application could not find a particular file, the NetView operator could intervene by executing a command (via NVRunCMD) on the Windows NT Server to copy the file to an area where it could be found by the application needing it.

LU Pooling

LU pools are groupings of 3270, LUA, or downstream LUs organized by the administrator in such a way as to maximize access to the LUs in the pool. A pool user, LUA application, or downstream system can get LU access as long as only one of the pooled LUs is available and functioning. One or more LUs in the pool can cease to function without affecting pool access by other users, applications, or downstream systems, just as long as a single pool LU continues to work. The primary benefits of LU pooling are hot backup, load balancing, session efficiency, and administrative efficiency. For a brief discussion of hot backup and load balancing, see "Highly Secure, Reliable, and Efficient" earlier in this chapter.

Session efficiency applies to cases where intermittent users need to use a limited number of resources. These intermittent users could be pooled together to represent a smaller number of users and find their access needs sufficiently met. For example, if nine 3270 users need infrequent access to a particular resource, they may find that access is sufficiently provided by a pool of only four 3270 LUs.

Administrative efficiency is achieved through the administrator's use of the SNA Server Admin program to assign LU pools to users or groups of users. This eliminates the need to assign LUs to users individually. Additionally, with SNA Server's drag and drop functionality, creating pools and assigning users or groups to them is extremely fast and easy.

Remote Access Service (RAS) Support

RAS allows network clients in remote locations to participate in the full functionality and features of the network. RAS servers can be configured on any Windows NT-based platform (including SNA Server) as long as SNA clients have access to SNA gateway resources from remote workstations. Connectivity for RAS can be achieved through the use of asynchronous dial-up modems, X.25 adapters, or ISDN connections. All SNA Server functions, application-to-application communications, administration, and emulation are possible with a RAS connection. Additionally, because RAS supports Windows NT logon and domain security disciplines, callback, and data encryption, secure network access by remote clients is ensured.

SNA Server version 2.1 put a new twist on this RAS feature. It is called the SNA RAS. It is similar in most respects to the RAS feature just described, but it has additional significant benefits in that it can use the SNA network itself as the physical connection between the RAS server and the SNA Server. Administrators can create virtual LAN connections between Windows NT systems across an existing SNA network by essentially integrating SNA Server's LU 6.2 transport with the standard RAS architecture. Because SNA RAS uses SNA remote transports such as synchronous X.25 and SDLC, there is no longer a need for corporate customers with large SNA WAN backbones to have to create LAN-to-LAN networks or install dial-up modems in each remote branch office. Thus, network administrators who need to manage remote offices connected to corporate mainframes or AS/400s through existing SDLC lines can now do so easily.

Preparing for SNA Server

Before you install any network server, it is always wise to do some detailed preliminary planning. But preliminary planning becomes an absolute necessity when you are preparing for an SNA Server network environment. SNA Server environments are extremely varied in how they are put together and what they do. For example, SNA servers may access IBM mainframes, AS/400s, remote peer systems, or a combination of all three. Their communication lines and adapters also vary from slow speed to high speed and are capable of supporting a range of traffic loads from light to very heavy. Because SNA Server environments are so varied, the configuration parameters for any particular environment must also be varied. Fortunately, SNA Server was designed to supply many standard default values. Invariably, however, unique parameters for one thing or another seem to always be required to make your system work. It is, therefore, imperative that parameters be defined in advance, system constraints identified before installation, and configuration options intelligently selected to best fit the needs of the enterprise.

Selecting a Management Model

One of the first decisions you must make when planning the installation of SNA Server environments is how to organize the SNA Server domains. Two management models for organizing domain distributions are possible, with each one possessing certain advantages and disadvantages. You must have an understanding of the business enterprise requirements, the existing environment, applicable resource constraints, and enterprise growth projections to select a management model that is right for your particular enterprise, both today and in the future.

Distributed Management of SNA Server Domains

In the distributed model, SNA servers in the enterprise are geographically separated and spread out across multiple local area networks (LANs), with each network domain containing one or more servers and the clients supported by those servers. An enterprise consisting of a corporate or home office and one or more branch offices is depicted in figure 21.5. In this typical example, a different SNA Server is physically located at each branch office and is part of the LAN supporting that branch office. The branch SNA Server is also connected to the IBM front-end processor (PU 4) or AS/400 located at the home office or data center. This connection is a Synchronous Data Link Control (SDLC) connection using leased telephone lines (dedicated to the connection at all times) or switched telephone lines (connected only when needed).

Fig. 21.5 - The view of a typical distributed SNA Server configuration with geographically separated SNA servers supporting independent LANs.

Because each SNA Server has its own communications link with the home office PU 4 or AS/400, transmission contention such as what would occur over a common wide area network (WAN) backbone is avoided. The SNA Server can also be installed on an existing branch office server platform already being used for printing, e-mail, fax, and local database support. This would reduce traffic on the WAN between the branch office and the home office and increase responsiveness to branch users through local management control of connections, LUs, and security. Additionally, because branch office domains would typically be smaller, server platforms could be smaller and SNA Server components would probably be easier to configure and manage. Because SNA Server's graphical tools and remote administration features would be available via remote access service (RAS) or NetView, there probably would not be a requirement for having trained SNA support personnel on site at the branch office to administer or troubleshoot the local SNA network. Another important consideration is that the distributed SNA Server configuration could easily take advantage of existing distributed networks and decrease the number and type of physical changes required to implement a new SNA Server network.

Centralized Management of SNA Server Domains

The alternative to the distributed management of SNA servers is the centralized approach. With the centralized configuration, SNA servers are all located in one place (a data center, for example) and are all on the same WAN with all the clients, regardless of location. These servers and clients all use the same networking protocol (TCP/IP, for example) to connect and communicate throughout the network. Using the example of the typical branch office enterprise environment once again, all the SNA servers would be located at the home office or central data center, as portrayed in figure 21.6. Each branch office has its own LAN domain that is also a part of the enterprise WAN. Access to the SNA Server(s) supporting the branch LAN is obtained via a combination of SDLC connections and WAN bridges or routers. Each SNA Server in the data center is connected to the IBM front-end processor (PU 4) or AS/400 via a token ring LAN or directly attached to the host mainframe channel.

Fig. 21.6 - The view of a typical centralized SNA Server configuration with SNA servers located in the same facility.

This centralized approach provides several benefits:

  • Having the SNA servers located in one place maximizes reliability and security, facilitates the arrangement of hot backups and load balancing, simplifies server management, and reduces the potential need for SNA Server expertise at remote sites.

  • The same WAN environment can be used for other purposes as well, such as SQL Server, e-mail, and printer and file sharing support.

  • Configuration is simplified because only one communications protocol is used throughout the WAN.

Filling Out the Planning Forms

Planning forms serve a useful function in identifying and organizing all the information required during SNA Server installation and configuration. Work with the system administrator of the remote host, peer, and/or downstream system to obtain the required information for the various forms. The following forms are included in the Microsoft SNA Server Version 2.1 Administration Guide and are reprinted in Appendix A of this book:

  • Server Resources Planning Form

  • Server Information Form

  • Initial Connection Settings Form

  • 802.2 Settings Form

  • SDLC Settings Form

  • X.25 Settings Form

  • Channel Settings Form

  • 3270 LUs Form (for Individual LUs)

  • 3270 LUs Form (for Ranges of LUs)

  • 3270 LU Pools Form

  • Users and Groups Form

  • Local APPC LUs Form

  • Remote APPC LUs Form

  • Mode Properties for LU-LU Pairs Form

  • CPI-C Properties Form

  • 3270 RTM Settings Form

Defining Connectivity Options

As discussed earlier, communications between the SNA Server and the SNA network can occur over various types of connections, which are determined by the type of physical wire or cable across which the data is passed; the communications adapter installed in the SNA Server platform; and the communications protocol used to control the communications process. Two of these connection types use special coaxial or other cables and adapters to connect directly to the IBM mainframe or AS/400 host. These are referred to as the Channel connection, which provides direct channel attachment to the mainframe, and the Twinax connection, which provides a twinaxial connection to an AS/400. Four other connection types are possible, with each type having an associated link service that is configured during the installation of SNA Server by the SNA Server setup program.

Link services allow the SNA Server to communicate with host, peer, or downstream computers over specific data links composed of communications adapters, physical wires or cables, and protocols. The following sections examine each of these four connection types and their associated link services in more detail.

Data Link Control (DLC) 802.2 Link Service

This link service facilitates communications between the SNA Server and host, peer, or downstream computers over token ring and Ethernet LANs using the standard 802.2 communications protocol. For example, if your environment has client devices communicating with each other over a token ring or Ethernet network, and these client devices need to communicate with IBM mainframes, AS/400s, or other downstream SNA devices, the SNA Server should be configured with the DLC 802.2 link service, as illustrated in figure 21.7.

Fig. 21.7 - The view of a typical environment suitable for the use of the DLC 802.2 link service.

SDLC Link Service

The SDLC link service controls communications between the SNA Server and the host, peer, or downstream computers over telephone lines that are either switched or leased (see fig. 21.8). Switched lines are basically dial-up lines that are activated when you dial the telephone number of the computer to which you want to connect. Leased lines, on the other hand, are dedicated lines that are constantly active between the SNA Server and the host, peer, or downstream computer. Leased lines are essentially point-to-point type circuits that physically connect two geographically separated computers to each other.

Fig. 21.8 - The view of a typical environment suitable for the use of the SDLC link service.

Another characteristic of the SDLC link service is the requirement for a full-duplex or half-duplex synchronous modem at each end of the telephone line. Data to be transmitted must pass from the computer, through the synchronous modem, and to the communications line for transmission to the distant end. Then at the other end, the data being received must pass from the communications line, through another synchronous modem, and then into the receiving computer. The advantage of using a full-duplex modem is that the modem can accommodate two-way communications simultaneously. In other words, the modem can send and receive data at the same time. The half-duplex modem can also send and receive data, but not simultaneously. It must complete one operation (for example, sending data) before it can receive incoming data.

X.25 Link Service

This link service supports the communications between the SNA Server and the host, peer, or downstream computers through the use of packet-switching networks, as reflected in figure 21.9. These packet-switching networks are classified as either public or private, depending on the accessibility of the network to the general public. Public packet-switched networks transmit data over public telephone circuits; whereas private packet-switched networks transmit data over private circuits installed and maintained for the exclusive use of the network owner.

Fig. 21.9 - The view of a typical environment suitable for the use of the X.25 link service.

Public networks can reduce a corporation's line costs by using the existing communications lines of a communications service provider (AT&T, for example), but there are several reasons why a corporation may still need to pay the high installation and maintenance fees to have their own private network. For example, the corporation may have sufficiently high traffic loads to make a private network more cost effective, or they may need a packet-switched network in an area where public packet-switched services are not available. The increased security afforded through centralized management and control of the private network may also be sufficient justification for the high cost of owning and operating the private network. In many cases, however, the most cost effective solution is to utilize a mix of private and public packet-switching networks to handle nationwide communications needs.


The X.25 link service must use the X.25 Qualified Logical Link Control (QLLC) protocol when communicating in an SNA network environment.

Distributed Function Terminal (DFT) Link Service

The DFT link service controls the communications between the SNA Server and the host systems over coaxial cable or twisted pair wire. The cable (or wire) directly connects the SNA Server to the IBM cluster controller, as shown in figure 21.10. It is also possible to connect SNA Servers to peer systems via the mainframe host using this link service. Multiple sessions are supported by the DFT link service.

Fig. 21.10 - The view of a typical environment suitable for the use of the DFT link service.

Understanding Client-to-SNA Server Protocols

SNA network client devices usually exist on a separate LAN connected to the SNA Server platform via an 802.2, SDLC, or X.25 connection. The network software and protocols for the client devices are dependent upon the network operating system controlling the client devices, as well as the physical adapter, contained within each client device, which allows that client device to communicate with the client LAN. SNA Server can be configured to support the following types of network software and protocols:

  • Microsoft Networking (Named Pipes)

  • Novell NetWare (IPX/SPX)

  • Banyan VINES

  • TCP/IP

  • AppleTalk (for Macintosh networks)

Client platforms can be controlled by any one of several different operating systems as long as the proper networking software and protocols are used. In figure 21.11, notice that for each operating system identified, at least one of the required combinations of networking software and/or protocols must be installed in the client device in order for the SNA Server to communicate with that client.

Fig. 21.11 - Relationship of various client operating systems to required networking software and protocols.

Implementing Security

SNA Server security is provided and enforced through three different design factors, which when implemented properly, provide a stable, highly controllable security environment meeting the government's stringent C-2 security level standard. These design factors are as follows:

  • The SNA Server architecture itself

  • The use of the Windows NT-based server operating systems

  • The client logon process

Security Through the SNA Server Architecture

The SNA Server architecture has been designed to make it impossible to bypass SNA Server security features. Regardless of which SNA Server components are communicating, and regardless of which transport components are being used for that communication, everything must pass through a single SNA Server component - the DMOD Service Layer. The DMOD enforces SNA security features by applying defined security constraints and conditions to all communications that pass through it.

Security Through Windows NT-Based Server Operating Systems

Because SNA Server must operate under the control of a Windows NT-based server operating system (either Windows NT Advanced Server Version 3.1 or Windows NT Server Version 3.5), the Windows NT security features provide the bulk of the security for SNA Server. This security involves controlling access at two different levels:

  • Access to mainframe and/or AS/400 resources

  • Access to the tools and files used to create or change accounts and LUs

Access to Mainframe and/or AS/400 Resources
Remember that SNA Server uses the same user accounts database as the Windows NT-based servers, so you can specify which Windows NT domain users and groups will also be SNA Server users and groups. They only have to be created once for use by both Windows NT and SNA Server.

Mainframe access, however, is defined through use of the 3270 LU. So for users and/or groups to gain access to mainframes through 3270 emulation, they must be associated with 3270 LUs. You accomplish this by assigning specific 3270 LUs or LU pools (defined for mainframe access) to them. In this way, you can control access to the mainframe by controlling which 3270 LUs or LU pools are assigned to which users or groups of users.

Access to the Tools and Files Used to Create and Change Accounts and LUs
In a similar way as for the mainframe, access to the AS/400 is defined and controlled by the LU. But unlike the 3270 LU used by the mainframe, the design of LU 6.2 (the specific type of LU used with the AS/400) is not nearly as restrictive. As long as a user has an account in the Windows NT domain and has specific information about the 6.2 type LUs configured in SNA Server, that user can possibly gain access to the AS/400 with which those LUs communicate. To prevent this, you must exercise tight control over accounts and LU information available to the users. Because this information is contained in the SNA Server configuration file, it is essential to control access to this file through the use of file access restrictions and security permissions.

The capability to assign security permissions on a file-by-file basis is available in Windows NT-based servers, but only if the file to be protected is stored on an NT file system (NTFS) partition on the internal hard disk. If the file is stored on a file allocation table (FAT) or high-performance file system (HPFS) partition instead, file-level security features cannot be implemented. Therefore, always install SNA Server software on an NTFS partition. This is especially critical for SNA servers used in the primary and backup roles because they contain the main configuration files for all the other SNA servers in the domain.

Security Through the Client Logon Process

The logon process is the first level of security for the SNA Server because the user is identified to the Windows NT domain and to the SNA servers through this process. If the user cannot be identified by the Windows NT server during logon, the user will not be given access to any domain resources, SNA Server resources included.

SNA Server handles the logon process differently depending on the networking software being used by the client system. If Microsoft networking (used for Windows for Workgroups, Windows NT-based systems, and Windows or DOS systems running LAN Manager) is being used, a valid logon causes the user to be logged on across the network automatically through encryption and secure protocols. Thus a single correct logon gains a user access to both the Windows NT domain and all the SNA servers in the domain. Non-Microsoft networking (such as Novell NetWare, TCP/IP, and Banyan VINES) requires two logons - one for access to the Windows NT domain and one for access to the SNA servers in the domain. The same password for both logons can be used, if desired, but no information is sent from the SNA Server to the client system until both logons have been completed successfully.

Implementing Auditing

Auditing is a feature provided through the Windows NT Server operating system. Auditing is performed by the system when specific events are recorded in an event log as they occur. When you set up the auditing feature, you can specify which events to audit. When the specified event occurs, such as a member of the Administrator Group changing the configuration file, for example, the system automatically records information concerning that event.

Auditing is also an important method of collecting security-related information. When auditing is used, however, system resources must be used for tracking and recording audited events. This means you pay a small price in performance overhead for each event audited. Additionally, if numerous events are audited, the size of the event log can quickly get very large. Therefore, you would be wise to carefully select which events should be audited so that useless event log entries are avoided and system performance is not unnecessarily impacted.

Choosing a Server Role

When planning for the SNA Server environment, one of the planning decisions that must be made is how many SNA servers should be present in the network and what each of their roles should be. SNA server can be installed to function in any one of three different roles: primary server, backup server, or member server.

When the SNA Server is installed as a primary server, it will contain the main configuration file for the entire domain. This configuration file contains information about the SNA Server resources available in the domain such as link services, LUs, domain users, and so on. There can be only one primary SNA Server in a domain, and typically it is the first one installed.


As used in this section, the term "domain" actually refers to a subdomain under the Windows NT domain. Numerous SNA Server subdomains can exist under a single Windows NT domain, but each subdomain can have only one primary SNA Server (and up to 49 backup SNA servers). Thus, a Windows NT domain can support several primary SNA servers as long as each primary SNA Server is in a separate subdomain under the Windows NT domain.

Up to 49 backup SNA servers can be installed on the domain. Any of these backup servers can automatically take over as the primary server if the primary server ever fails or if domain connection to the primary server is ever lost. The primary SNA Server ensures that a current read-only copy of the domain's main configuration file is replicated and stored on the backup SNA server(s) each time the configuration is changed and saved on the primary server. Then if the primary SNA Server is ever lost, any of the backup SNA servers will have all the necessary files and information about the domain to immediately take over the primary SNA Server functions. Because the configuration file is a read-only copy of the main configuration file, it cannot be changed or saved while the backup server is functioning as the primary server. You can actively manage the current configuration, however, without altering the configuration file.

If the SNA Server is not a primary or backup server, it has to be a member server. Member SNA servers do not contain configuration files, but they do perform normal SNA Server functions by applying configuration file information as necessary through communications with the primary SNA Server.

Installing SNA Server with the SNA Server Setup Program

Because the SNA Server Setup program requires the capability to access the Windows NT Registry, you must be logged on the Windows NT Server as an administrator when you start the SNA Server Setup program. When you start the SNA Server setup program, one of the first dialog boxes you see is the Software Licensing dialog box. This dialog box is used to enter identifying information about you, your company, and your SNA Server product identification number. If you have installed other Microsoft products, you have undoubtedly seen similar dialog boxes for entering identification information. The buttons at the bottom of the dialog box allow you to continue with the setup program after entering the information, go back to edit the information you have just entered, obtain help on the setup program, and exit from the setup program.

After completing the Software Licensing dialog box, and its accompanying Confirm Licensing dialog box, the Installation Path dialog box appears. The default installation path displayed is C:\SNA. You can accept this default path or change the installation path to one of your own choosing. Be sure to type in the full installation path if you choose your own, and be careful to use an empty directory so that SNA Server setup will not inadvertently overwrite files needed by other programs on your system.

Selecting Client-Server Protocols

The setup program next checks for installed client-server protocols. If more than one client-server protocol is detected, the Select Client-Server Protocols dialog box depicted in figure 21.12 appears.

Fig. 21.12 - A Select Client-Server Protocols dialog box showing that several client-server protocols have been automatically detected by the SNA Server Setup program.

The detected protocols will be available for selection and, by default, will already be marked for use. Other protocols may be listed, but will be grayed out and unavailable for selection if they were not detected on your system. You can deselect the protocol(s) you do not want SNA Server to use by clicking the marked check box.

If the Microsoft Networking (Named Pipes) client-server protocol was not selected, SNA Server setup will ask you to specify the network domain name in which you want to operate with the other network transports. The Network Domain Name dialog box appears for you to use in specifying a domain name, as portrayed in figure 21.13.

Fig. 21.13 - This is how the Network Domain Name dialog box appears after the domain name "INTERNAL" has been entered.

If you selected the TCP/IP protocol instead of the Microsoft Networking (Named Pipes) protocol, you can specify the domain name in one of three forms:

  • The Domain Name used in the Windows NT domain

  • The host name and the TCP domain name (for example, gasullivan.iceman.com).

  • The IP address (for example, 55.255.23.11).

If you select the Banyan VINES protocol instead of the Microsoft Networking (Named Pipes) protocol, setup displays the StreetTalk Group Name dialog box so that you can supply the StreetTalk group name. If you leave the Group Name box blank, setup uses the group name of the user currently logged onto the Banyan VINES network as a default.

Selecting the Server Role

When the client-server protocol setup actions have been completed or the Microsoft Networking (Named Pipes) protocol has been detected as the only installed protocol, setup directs you to designate a role for this SNA Server by displaying the Change SNA Server Role dialog box shown in figure 21.14. For a description of the different SNA Server roles, see "Choosing a Server Role" earlier in this chapter.

Fig. 21.14 - The Change SNA Server Role dialog box first appears with the default option selected.

The Primary Server option is automatically selected as the default. If this is the role you want the SNA Server to have, simply click the Continue button. Otherwise, click one of the other desired options. Because the SNA Server can only be designated for a single role, clicking one of the options clears the highlighting from any other option.


When an SNA Server is going to function as a primary server, the SNA Server software needs to be installed on an NTFS hard disk partition so that file-level security permissions can be used to control access to critical configuration files. If necessary, Exit SNA Server setup, establish an NTFS partition on the SNA Server installation platform, and then rerun SNA Server setup to install the SNA Server software on the NTFS partition.

The Review Settings dialog box appears next. If you need to go back and review (and/or change) the installation directory and server role settings, click the Review button. Otherwise, click Continue. After clicking Continue, SNA Server Setup copies the appropriate files to the selected location and then displays the Link Service Installation dialog box.

Installing Link Services

A link service defines the protocol used between the SNA Server software and the installed communications adapter and enables communication with that adapter's device driver. SNA Server setup uses the Link Service Installation dialog box displayed in figure 21.15 to install link services.


When the Link Service Installation dialog box appears, you can click Continue without making a selection to complete SNA Server installation without installing and configuring link services. In this case, you will have to run the SNA Server setup program to install link services later, because link services must be installed and configured before the SNA Server connections can be configured with the SNA Server Admin program.

Fig. 21.15 - The Link Service Installation dialog box displays a list of link services available for installation.

To install a link service listed in the Available Link Services list box, select the desired link service and click the Install button. This causes the setup dialog box for the selected link service to appear. The dialog box displays default information and details concerning the configuration settings active on the communications adapter for which this link service is being installed. Either accept the defaults or enter the desired configuration settings appropriate for your installed adapter. When you click Continue, the link service is installed.

Depending on the link service being installed, additional dialog boxes may appear to solicit your input of required configuration constraints. For example, if you select the Barr SDLC link service (for the Barr T1-SYNC adapter card), an additional dialog box appears asking for you to accept the defaults or enter new Barr SDLC device driver settings for base address, IRQ level, DMA level, and data rate.

If you select the DLC 802.2 link service for installation, the SNA Server Setup program checks for the presence of DLC software installed from the Windows NT (or Windows NT Server) Setup programs. If none is detected, a message box appears informing you that you must install DLC software before continuing. The SNA Server Setup program then provides you with two alternatives:

  • Exit from the SNA Server Setup program and run the Windows NT Setup program to install the required DLC software. Then rerun the SNA Server Setup program to install SNA Server and link services.

  • Insert the Windows NT Setup program installation disks or CD, and SNA Server installs the DLC software automatically as a part of the link service installation.

If you want to install a link service not listed in the Available Link Services list box, you can install it from a floppy disk, the hard drive on the SNA Server installation platform, or a network drive. Simply click Other in the Link Service Installation dialog box to display the Link Service Import dialog box. When the Link Service Import dialog box appears, delete the default drive in the Path box, if necessary, and enter the new drive and/or full path for the location of the desired link service file. When you click Continue, the setup program looks in the specified location for other link services. The Link Service Installation dialog box then reappears listing any additional link services found.

Configuring Link Services

The various link service setup dialog boxes that appear during the SNA Server installation all contain a Configure button so that you can configure the link service as it is being installed. But you can also complete the installation of the link service with default configuration settings and then go back and run SNA Server Setup again to configure the link services. Either way, however, the link services have to be properly configured before the process of building your SNA Server (discussed in Chapter 22, "Building Your SNA Server") can be completed. The following paragraphs discuss how to configure the four primary types of link services, which are as follows:

  • DLC 802.2 link service

  • IBM SDLC link service

  • IBM X.25 link service

  • IBM DFT link service

DLC 802.2 Link Service

Follow these steps to configure the DLC 802.2 link service:

  1. Access the DLC 802.2 Link Service Setup dialog box by selecting the DLC 802.2 link service from the Available Link Services list box in the Link Service Installation dialog box. Then click Install. A DLC 802.2 Link Service Setup dialog box similar to the one in figure 21.16 appears.

    Fig. 21.16 - The DLC 802.2 Link Service Setup dialog box for a computer using the 3Com Etherlink III communications adapter.

  2. In the Title box of the DLC 802.2 Link Service Setup dialog box, either accept the default title or delete the default title and enter a new title name for this link service. Title names can be up to 40 characters long.

  3. In the Adapter box, click the drop-down list box to display the list of communications adapter cards. Then select the communications adapter card you are using.

  4. In the Local Service Access Point (SAP) box, enter the local SAP number, which is used for access to certain services on an 802.2 connection within an SNA network. This number, which is usually 4 for an SNA Server, must be evenly divisible by 4 and be in the range from 4 to 252.

  5. Click Continue. Setup copies the required files and displays the Link Service Configuration dialog box listing the link service just configured (see fig. 21.17).

    Fig. 21.17 - The Link Service Configuration dialog box after the DLC 802.2 link service has been installed.

    This dialog box can also be used to add new link services, reconfigure existing link services, and to remove existing link services:

    • To add a new link service from the Link Service Configuration dialog box, click Add. Setup displays the Link Service Installation dialog box (refer to fig. 21.15) so that you can select the link service to be installed.

    • To reconfigure an existing link service, select the desired existing link service in the Link Service Configuration dialog box and then click Configure.

    • To remove an existing link service, select the desired existing link service in the Link Service Configuration dialog box and then click Remove. When the Confirm Link Service Removal dialog box appears, click Continue.

  6. Click Continue to complete SNA Server installation normally, or click Exit to exit the setup program at this point.


If your SNA environment includes an SNA Server on an Ethernet LAN and communications between the SNA Server and remote hosts, peers, or downstream systems is accomplished via routers, you may have to make adjustments to the Windows NT Registry. The FrameType registry entry indicates the type of frames the 802.2 link service needs to send over the Ethernet LAN. You need to ensure that the frame type used by SNA Server matches the frame type used by the routers. Check with the local network support staff to determine what type of frames the routers pass. The FrameType can only be set on an SNA Server and is in the following Registry section:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
    DLCLinkServiceName\Parameters\ExtraParameters

SDLC Link Service

Follow these steps to configure the SDLC link service:

  1. Access the SDLC Link Service Setup dialog box by selecting the SDLC link service you want from the Available Link Services list box in the Link Service Installation dialog box. Then click Install.

  2. One or more dialog boxes may appear asking you to enter information or make selections for IRQ, DMA, and other settings applicable to your communications adapter. If these preliminary dialog boxes appear, supply the necessary information and make the required choices; then click Continue. An SDLC Link Service Setup dialog box appears with options specific for the SDLC link service specified. If the IBM SDLC link service is selected, for example, the IBM SDLC Link Service Setup dialog box in figure 21.18 appears.

    Fig. 21.18 - The IBM SDLC Link Service Setup dialog box for a computer using an IBM SDLC communications adapter on dedicated communications lines.

  3. In the Service Title box of the IBM SDLC Link Service Setup dialog box, either accept the default title or delete the default title and enter a new service title name for this link service. Service Title names can be up to 40 characters long.

  4. The Card Type box may or may not be present depending on the SDLC Link Service Setup dialog box being used. If it is present, you must select the communications adapter card you will be using. In the Card Type box, click the drop-down list box to display the list of communications adapter cards. Then select the communications adapter card you are using.


    The IBM SDLC and IBM MCPA adapters lack coprocessors. Therefore, they cannot handle full-duplex transmission at high transmission speeds. If you are using one of these adapters and want to use a transmission speed greater than 9600 baud, you must use the SNA Server Admin program to set the half-duplex mode (vice the full-duplex mode) for the adapter.

  5. If the Details or Adapter Details button is included in the SDLC Link Service Setup dialog box, clicking this button displays the settings for the SDLC communications adapter card configured in the SNA Server platform. Depending on the specific card you have configured, you may have the option of reconfiguring certain displayed settings. Consult your specific adapter's documentation for information about how to change your card's configuration settings.

  6. The Line Type box contains four options, one of which must be selected by clicking the radio button adjacent to the option. The options are identified and explained as follows:

    • Leased. Choose this option if you will be using a dedicated telecommunications line.

    • Switched: Server-Stored Number. Choose this option if the adapter card to which your synchronous modem is attached has a serial port built into it.

    • Switched: Modem-Stored Number. Choose this option if your modem is capable of storing a phone number and is configured to dial the number when the Data Terminal Ready status is detected. See "Using Server-Stored Numbers" later in this chapter.

    • Switched: Manual Dial. Choose this option if you will be manually dialing the phone number when prompted by the SNA Server.

  7. Click the Constant RTS (Request To Send) check box if you want the SDLC adapter to be in constant readiness to send data. In this mode, the adapter keeps a high priority on maintaining its own RTS state and signals the remote end to set a high priority on maintaining its CTS (Clear To Receive) state as well. In contrast, if Constant RTS is turned off (by clicking the marked Constant RTS check box to clear the mark), the SDLC adapter must establish its RTS state and then wait for the remote end to establish its CTS state before the adapter can send data. Therefore, transmission delays are minimized when RTS is on. For higher throughput, turn on RTS whenever you can.


    Constant
    RTS must be turned on if the link service is configured for use by a full duplex connection, and it must be turned off if the link service is configured for use by a multidrop connection.

  8. If other options are displayed in the SLDC Link Service dialog box, select the appropriate option or supply the additional information as required.

  9. If the Dialer Settings button is available in the SDLC Link Service Setup dialog box, select it and configure the following setting as indicated here:

    • COM Port. Select the number of the COM port. For example, for COM2, select 2.

    • Baud Rate. Select the desired transmission rate. The default is 9600.

    • Incoming String. Type the command string to be sent to the modem when an incoming call is detected. If your modem accepts the standard AT command set, the default command string (AT&F&C1&S1&D3&Q1Q1S0=1) will be appropriate in most cases. See "Modem Command Strings" later in this chapter.

    • Outgoing String. Type the command string to be sent to the modem when an outgoing call is detected. If your modem accepts the standard AT command set, the default command string (AT&F&C1&S1&D3&Q1Q1S0=0DT) will be appropriate in most cases. See "Modem Command Strings" later in this chapter.

  10. Click Continue. Setup copies the required files and displays the Link Service Configuration dialog box listing the link service just configured (see fig. 21.19).

    Fig. 21.19 - The Link Service Configuration dialog box after the IBM SDLC link service has been installed as a second link service.

    This dialog box can also be used to add new link services, reconfigure existing link services, and to remove existing link services:

    • To add a new link service from the Link Service Configuration dialog box, click Add. Setup displays the Link Service Installation dialog box (refer to fig. 21.15) so that you can select the link service to be installed.

    • To reconfigure an existing link service, select the desired existing link service in the Link Service Configuration dialog box and then click Configure.

    • To remove an existing link service, select the desired existing link service in the Link Service Configuration dialog box and then click Remove. Then when the Confirm Link Service Removal dialog box appears, click Continue.

  11. Click Continue to complete SNA Server installation normally, or click Exit to exit the setup program at this point.

X.25 Link Service

To Configure the X.25 link service, follow these steps:

  1. Access the X.25 Link Service Setup dialog box by selecting the X.25 link service you want from the Available Link Services list box in the Link Service Installation dialog box. Then click Install. An X.25 Link Service Setup dialog box appears with options for the X.25 link service specified. If the IBM X.25 link service is selected, for example, the IBM X.25 Link Service Setup dialog box in figure 21.20 appears.

    Fig. 21.20 - The IBM X.25 Link Service Setup dialog box for a computer using an IBM SDLC communications adapter on dedicated communications lines.

  2. In the Service Title box of the IBM X.25 Link Service Setup dialog box, either accept the default title or delete the default title and enter a new service title for this link service. Service titles can be up to 40 characters long.

  3. The Card Type box may or may not be present depending on the X.25 Link Service Setup dialog box being used. If it is present, you must select the communications adapter card you will be using. In the Card Type box, click the drop-down list box to display the list of communications adapter cards. Then select the communications adapter card you are using.

  4. If the Details or Adapter Details button is included in the X.25 Link Service Setup dialog box, clicking this button displays the settings for the X.25 communications adapter card configured in the SNA Server platform. Depending on the specific card you have configured, you may have the option of reconfiguring certain displayed settings. Consult your specific adapter's documentation for information about how to change your card's configuration settings.

  5. In the Local NUA Address box, enter the local X.25 address. The address must be 15 decimal digits in length with no embedded spaces. The last three digits are used to route information between stations having the same 12-digit address. No defaults are available for this box.

  6. The default L3 window size parameter only applies to switched virtual circuit (SVC) connections and specifies the maximum number of packets that can be transmitted before an acknowledgment from the receiver is required. In the Default L3 Window Size box, either accept the default value of 2 or click the drop-down list box to display the full list of possible values. Then click the desired value to be used as the default L3 window size.

  7. The default L3 Packet Size setting defines the maximum length of the data each packet can contain when transmitted over SVC connections. In the Default L3 Packet Size box, either accept the 128 standard default setting or click the drop-down list box to expand the list box and display all the allowable values. Then click the desired value to be used as the default L3 packet size.

  8. The L2 Window Size parameter specifies the number of frames that can be sent to the network by the SNA Server before an acknowledgment from the receiver is required. In the L2 Window Size box, either accept the standard default of 7 or click the drop-down list box to expand the list box and display all the allowable settings. Then click the desired setting to be used as the default L2 window size.

  9. The T1 Timeout parameter defines the length of time a local station (system) should wait for a receiving station to respond to a transmission before it tries the transmission again. This parameter is specified in tenths of a second, with the allowable range being from 1 to 100, and the default value being 30. In the T1 Timeout (0.1s) box, either accept the default or enter another number in the allowable range, being careful to use a number greater than the normal frame relay time needed between the local and remote systems.

  10. The N2 Retry Limit box specifies the maximum number of times a particular transmission should be attempted. The allowable range is from 1 to 100, with the default being 10. Either accept the default or enter another valid number.

  11. The Accept Reverse Charge check box indicates whether the SNA Server should accept incoming calls that are flagged to have the long distance charges reversed or charged to the receiving SNA Server. Reverse charge calls are indicated by the data contained in the call packet. Click the empty check box to mark the box, indicating that the option is on and that the incoming reverse charge calls will be accepted by the SNA Server. Clicking the marked check box clears the "X" and turns off the option, which is the default setting.

  12. The Select Standby check box indicates whether a standby line can be used. A standby line is essentially a backup line included on some modems that can handle the transmission in the event the primary modem line fails. Click the empty check box to mark the box, indicating that the option is on, and the standby (backup) line can be selected to handle the transmission. Clicking the marked check box clears the "X" and turns off the option, which is the default setting.

  13. The Startup Restart check box indicates whether a restart should be performed each time the link is activated. Click the marked check box to clear the "X" and turn off the option so that a restart will not be performed each time the link is activated. Clicking the empty check box marks the box, indicating that the option is on, and the restart will be performed each time. This is the default setting.

  14. The Incoming Filter check box indicates whether calls to X.25 addresses other than the local one are filtered out. Click the marked check box to clear the "X" and turn off the option so that calls to X.25 addresses other than the local one will not be filtered out. Clicking the empty check box marks the box, indicating that the option is on, and the calls will be filtered out. This is the default setting.

  15. Channel range specifications for your X.25 link must agree with the configuration used by your X.25 carrier. Therefore, you must specify a channel range for at least one of the channel types using the X.25 link service in accordance with the following guidelines. The only default available is for the Two-Way SVC channel. That default is 0001-0004.

    • Channel numbers may range from 1 to 4096.

    • When entering channel numbers, you must use the format A-B where A represents the beginning channel number, and B represents the ending channel number.

    • Although there is no requirement for the number of channels used by switched or permanent virtual circuit types, the total number of channels among all types must be from 1 to 16.

    • Channel number ranges must be unique and cannot overlap.

    • At least one SVC incoming or SVC two-way channel must have a range specified if incoming calls are to be received.

    • A PVC channel range must be specified if a PVC connection uses the link service.

    • When configuring more than one channel type, assign channel numbers to the selected channel types in ascending order, adhering to the following channel type ordering sequence from the lowest channel numbers to the highest channel numbers: PVCs (use lowest channel numbers), incoming SVCs, two-way SVCs, and outgoing SVCs (use highest channel numbers).

  16. In the Data Rate box, either leave the data rate default set to High or click the Low radio button to set the data rate to a slower speed if your line quality is poor and errors occur at the high rate setting.

  17. Because encoding specifies the encoding pattern for the data, it must be set the same for both the sending and receiving computers. In the Encoding box, either leave the default set to NRZ (nonreturn to zero) or click the NRZI (nonreturn to zero inverted) radio button to switch to the NRZI encoding scheme.

  18. In the Line Type box, select the line type that matches your line type and modem capability. The Line Type options are explained as follows:

    • Leased. Select this option if you are using dedicated lines.

    • Switched: Modem-Stored. Select this option if your modem can store a phone number. Make sure that you configure your modem to dial the stored number when it senses a Data Terminal Ready (DTR) status.

    • Switched: Manual Dial. Select this option if you will be dialing the number manually when prompted by the SNA Server.

  19. If other options are displayed in the X.25 Link Service Setup dialog box, select the appropriate option or supply the additional information as required.

  20. If the Dialer Settings button is available in the X.25 Link Service Setup dialog box, select it and configure the following settings as indicated in the following list:

    • COM Port. Select the number of the COM port. For example, for COM2, select 2.

    • Baud Rate. Select the desired transmission rate. The default is 9600.

    • Incoming String. Type the command string to be sent to the modem when an incoming call is detected. If your modem accepts the standard AT command set, the default command string (AT&F&C1&S1&D3&Q1Q1S0=1) will be appropriate in most cases. See "Modem Command Strings" later in this chapter.

    • Outgoing String. Type the command string to be sent to the modem when an outgoing call is detected. If your modem accepts the standard AT command set, the default command string (AT&F&C1&S1&D3&Q1Q1S0=0DT) will be appropriate in most cases. See "Modem Command Strings" later in this chapter.

  21. Click Continue. Setup copies the required files and displays the Link Service Configuration dialog box listing the link service just configured (see fig. 21.21).

    Fig. 21.21 - The Link Service Configuration dialog box after the IBM X.25 link service has been installed as a third link service.

    This dialog box can also be used to add new link services, reconfigure existing link services, and remove existing link services:

    • To add a new link service from the Link Service Configuration dialog box, click Add. Setup displays the Link Service Installation dialog box (refer to fig. 21.15) so that you can select the link service to be installed.

    • To reconfigure an existing link service, select the desired existing link service in the Link Service Configuration dialog box and then click Configure.

    • To remove an existing link service, select the desired existing link service in the Link Service Configuration dialog box and then click Remove. Then when the Confirm Link Service Removal dialog box appears, click Continue.

  22. Click Continue to complete SNA Server installation normally, or click Exit to exit the setup program at this point.

DFT Link Service

To configure the DFT link service, perform the following steps:

  1. Access the DFT Link Service Configuration dialog box by selecting the DFT link service you want from the Available Link Services list box in the Link Service Installation dialog box. Then click Install. A DFT Link Service Configuration dialog box appears with options for the DFT link service specified. If the IBM DFT link service is selected, for example, the IBM DFT Link Service Configuration dialog box in figure 21.22 appears.

    Fig. 21.22 - This dialog box appears when the IBM DFT link service is selected in the Link Service Installation dialog box.

  2. Examine the current title of the link service and leave it as is if it is acceptable. Otherwise, click Change to display the Link Service Title dialog box. Then in the Title box, delete the default title and enter a new title for the link service. Title names can be up to 40 characters long. Then click Continue.

  3. The DFT Adapters Available box contains a Base Address for the installed DFT adapter. Either accept this default address or click Configure to display the Adapter Base Address dialog box in figure 21.23.

    Fig. 21.23 - This dialog box is used for specifying a new base address for the installed DFT adapter.

  4. In the Base Address box, delete the default address and enter a new address for the adapter. Then click Continue to redisplay the IBM DFT Link Service Configuration dialog box.

  5. If additional DFT adapters need to be configured, click Add to display the Adapter Base Address dialog box. Enter a base address for the new adapter, using a multiple of hexadecimal 1000 in the range of hexadecimal A0000 through FF000. Then click Continue to redisplay the IBM DFT Link Service Configuration dialog box. Note that the Base Address of the newly configured DFT adapter now also appears in the DFT Adapters Available box.

  6. If you need to remove a DFT adapter whose base address is listed in the DFT adapters available box, simply highlight the desired adapter's base address and click Remove.

  7. Click Continue. Setup copies the required files and displays the Link Service Configuration dialog box listing the link service just configured (see fig. 21.24).

    Fig. 21.24 - The Link Service Configuration dialog box after the IBM DFT link service has been installed as a fourth link service.

    This dialog box can also be used to add new link services, reconfigure existing link services, and remove existing link services:

    • To add a new link service from the Link Service Configuration dialog box, click Add. Setup displays the Link Service Installation dialog box (refer to fig. 21.15) so that you can select the link service to be installed.

    • To reconfigure an existing link service, select the desired existing link service in the Link Service Configuration dialog box and then click Configure.

    • To remove an existing link service, select the desired existing link service in the Link Service Configuration dialog box and then click Remove. When the Confirm Link Service Removal dialog box appears, click Continue.

  8. Click Continue to complete SNA Server installation normally, or click Exit to exit the setup program at this point.

Using Server-Stored Numbers

If you choose Switch: Server-Stored Number for a line type when configuring your SDLC link service, the following modem setup requirements must be fulfilled in order for a phone number to be accepted from the SNA Server:

  • Accept dial commands in ASCII format consisting of eight data bits, no parity bit, and one stop bit.

  • Do not dial when the DTR signal is sensed.

  • When ready to accept dial commands, set Clear To Send (CTS) and Data Set Ready (DSR) to on.

  • After accepting the dial command, set DSR to off.

  • Set DSR back on only when the dialed connection is made.

  • Change to the synchronous mode after the completing dial-up.

  • Change back to the dial-up mode if DTR status is lost and then reacquired.

Modem Command Strings

When the SNA Server creates a dial string to send to the modem, it actually appends the phone number specified through SNA Server Admin to the outgoing command string supplied through the installation and configuration of the SDLC link service by the SNA Server Setup program. For modems that accept the standard AT command set, the outgoing default command string of AT&F&C1&S1&D3&Q1Q1S0=0DT will probably be appropriate. Using this command string as a reference, the effect each element has on the modem is described in the following list:

  • AT. This is the standard prefix for modem command strings.

  • &F. Instructs the modem to reset itself to its initial factory-installed defaults.

  • &C1. Instructs the modem to track the status of the Carrier Detect (CD) line.

  • &S1. Instructs the modem to raise the Data Set Ready (DSR) line after it has dialed.

  • &D3. Instructs the modem to reset when the Data Transmit Ready (DTR) line is lost.

  • &Q1. Instructs the modem to go into command mode and switch to the synchronous mode after dialing.

  • Q1. This element turns off the modem result codes.

  • S0=0. This element sets the modem for outgoing calls by turning off the auto-answer mode.

  • DT. Instructs the modem to dial the number following it (the one appended by the SNA Server) using tone dialing. If this element were DP, the modem's actions would be the same except that pulse dialing would be used instead of tone dialing.

The incoming default command string (AT&F&C1&S1&D3&Q1Q1S0=1) will also probably work well for modems that accept the standard AT command set. The elements do the same thing as in the outgoing command string just described, except that the S0=1 element instructs the modem to answer the phone after one ring.

Completing Installation of SNA Server

The SNA Server setup program displays the SNA Server Setup Finished dialog box when the SNA Server software files have been successfully installed. At this point, there will still be a significant amount of SNA Server setup and configuration tasks that need to be accomplished by running the SNA Server Admin program. You can run the Admin program at this point by clicking the Admin button, or you can click Exit to exit the SNA Server installation and start the SNA Server Admin program later. These tasks are explained in detailed in Chapter 22, "Building Your SNA Server."

The Windows NT Server Program Manager screen contains the Microsoft SNA Server group icon, which when restored, contains the following program-item icons:

  • SNA Server 3270 Applet

  • SNA Server 5250 Applet

  • SNA Server Setup

  • SNA Server Admin

  • SNA Server Trace

  • SNA Server Read Me

  • SNA Server Modem Monitor

  • ODBC Administrator

  • SNA Server Documentation (if Online Documentation option selected during installation)

  • SNA Server KnowledgeBase (if Online Documentation option selected during installation)

Using the SNA Server Setup Program After Initial Installation

When you run the SNA Server Setup program, one of the first things it does is check for the presence of installed SNA Server files and configuration data. If it detects your completed installation and finds the configuration file, it will display the Setup Options dialog box. From this dialog box, you can perform the following tasks:

  • Change an SNA Server role in the domain

  • Add and remove a link service

  • Change the configuration of a currently installed link service

  • Change the client-server protocol selections

  • Remove an SNA Server


Do not use the Windows NT Server Control Panel Network option to remove SNA Server device drivers (adapters, link services, and so on) because severe system problems could result. Instead, use the SNA Server Setup program to remove SNA Server device drivers so that initial driver installation actions can be properly reversed under program control.


You used the Windows NT Server Control Panel Network option to remove SNA Server device drivers (adapters, link services, and so on) and system problems have resulted.
Use the SNA Server Setup program to remove and reinstall SNA Server.

Changing the Server Role

Follow these steps to redefine the role of the server:

  1. In the Windows NT Server Program Manager, open the SNA Server program group.

  2. Click the SNA Server Setup icon to display the Welcome to the SNA Server Setup dialog box.

  3. Click Continue to display the Setup Options dialog box.

  4. Click Role in the Setup Options dialog box.

  5. When the Change SNA Server Role dialog box appears, click the radio button for the new SNA Server role. See "Selecting the Server Role" earlier in this chapter.

Adding a Link Service

To add a link service, follow these steps:

  1. In the Windows NT Server Program Manager, open the SNA Server program group.

  2. Click the SNA Server Setup icon to display the Welcome to the SNA Server Setup dialog box.

  3. Click Continue to display the Setup Options dialog box.

  4. Click Links in the Setup Options dialog box.

  5. When the Link Service Configuration dialog box appears, click Add. Setup displays the Link Service Installation dialog box so that you can select the link service to be installed. See "Installing Link Services" earlier in this chapter.

Removing a Link Service

The procedure for removing a link service is as follows:

  1. In the Windows NT Server Program Manager, open the SNA Server program group.

  2. Click the SNA Server Setup icon to display the Welcome to the SNA Server Setup dialog box.

  3. Click Continue to display the Setup Options dialog box.

  4. Click Links in the Setup Options dialog box.

  5. When the Link Service Configuration dialog box appears, highlight the link service to be removed and click Remove. Then when the Confirm Link Service Removal dialog box appears, click Continue.

Reconfiguring a Link Service

To reconfigure a link server, perform the following steps:

  1. In the Windows NT Server Program Manager, open the SNA Server program group.

  2. Click the SNA Server Setup icon to display the Welcome to the SNA Server Setup dialog box.

  3. Click Continue to display the Setup Options dialog box.

  4. Click Links in the Setup Options dialog box.

  5. When the Link Service Configuration dialog box appears, highlight the link service to be reconfigured and click Configure. A configuration dialog box specific to the link service selected is displayed. Use this dialog box to reconfigure the link service as necessary. See "Configuring Link Services" earlier in this chapter.

Changing Client-Server Protocol Selections

To change client-server protocol selections, follow these steps:

  1. In the Windows NT Server Program Manager, open the SNA Server program group.

  2. Click the SNA Server Setup icon to display the Welcome to the SNA Server Setup dialog box.

  3. Click Continue to display the Setup Options dialog box.

  4. Click Protocols in the Setup Options dialog box to display the Select Client-Server Protocols dialog box. See "Selecting Client-Server Protocols" earlier in this chapter.

  5. Use this dialog box to make the new protocol selections.

Removing an SNA Server

To remove an SNA server, follow these steps:

  1. In the Windows NT Server Program Manager, open the SNA Server program group.

  2. Click the SNA Server Setup icon to display the Welcome to the SNA Server Setup dialog box.

  3. Click Continue to display the Setup Options dialog box.

  4. Click Remove in the Setup Options dialog box.

  5. When the Confirm Removal dialog box appears, click Continue.

From Here...

This chapter briefly introduced the basic concepts of IBM's SNA and how the Microsoft SNA Server fits into a typical SNA network environment. Required SNA Server installation actions were also covered in detail, including some of the recommended preinstallation planning activities and post-installation uses of SNA Server Setup.

  • For information on building the SNA Server and establishing the connections between the SNA Server and the host mainframe or AS/400 system, see Chapter 22, "Building SNA Server."

  • For information on configuring the logical units and downstream connections so that clients can access network resources, see Chapter 23, "Implementing SNA Server."

  • For information on managing the SNA Server on a daily basis as the SNA Server administrator, see Chapter 24, "The Role of the SNA Server Administrator."

  • For information on using the Windows NT Server administrative tools as the SNA Server administrator, see Chapter 6, "The Role of the Network Administrator."


Table of Contents

20 - SQL Server Advanced Topics

22 - Building SNA Server