21 - SNA Server Preparation and Installation

• 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

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?

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

• 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