http://www.microsoft.com/TechNet/boes/bo/sna/ypages/barr.htm (PC Press Internet CD, 03/1996)
| Updated: March 15,1996 |  Go To TechNet Home Page |
Overview
Microsoft SNA Server
Barr and Microsoft Provide Configuration Flexibility
Summary
Recent trade articles have focused on apparent trends in the computer industry that indicate a move away from mainframes towards new client-server architectures. However, there is no definitive data showing a concrete trend where large enterprises are completely eliminating their IBM host systems. In fact, many large enterprises are investigating how they can include their IBM host systems into client-server architectures. Implementing client-server with an IBM host system as a server, definitely changes the role of the host system. The change in roles requires increases in the level of connectivity needed to support the new client-server infrastructure.
Remote mainframe access, once used mainly for connecting remote transaction terminals to centralized hosts, is now critical for a variety of distributed computing and client-server implementations. The product combination of Microsoft SNA Server and Barr Systems channel connectivity and SDLC products, allow enterprises to increase the speed and throughput for client-server implementations that involve integrating multi-protocol LANs with IBM host systems.
Microsoft SNA Server is a LAN-to-SNA gateway that provides SNA communications for LAN-based services and multiple platform PC workstations running a variety of network protocols. SNA Server employs a client-server architecture that is tightly integrated with, and leverages the strengths of, Microsoft Windows NT Server. SNA Server can be configured as an IBM PU 2.0, PU 2.1, APPN LEN node or support a DSPU. LU services provided are LU 0, 1,2,3 and LU 6.2. SNA API support is comprehensive with the inclusion of APPC, EHNAPPC, CPI-C, CSV, LUA/SLI, and ODBC/DRDA. SNA Server also supports TN3270 clients via the inclusion of a TN3270 server and provides for high speed file transfer through support of APPC File Transfer Protocol ( AFTP).
Most enterprise environments include desktops running Windows, Windows for Workgroups, Windows NT Workstation, Windows 95, MS-DOS, Apple Macintosh, OS/2 and UNIX, with a networking mix that contains IPX/SPX, TCP/IP, NetBEUI, Banyan VINES IP, and AppleTalk in addition to SNA protocols. IS directors wish they had a single solution to provide IBM mainframe and AS/400 data to every desktop. Corporate data on the host systems must be made available to users in the simplest and most efficient manner. The days of hard copy reports and hand keying of information back into disparate systems are long over. On-line access and the sophisticated integration of enterprise data offered by client-server technologies are demanded by end users.
Microsoft SNA Server provides the solution for this heterogeneous reality, while offering the extensibility demanded by the ever-changing computing environment. Large enterprises and small to medium organizations no longer have to worry about how users will access host data across the network today or tomorrow.
Microsoft SNA Server provides a single access method for all IBM host systems by solving the problem of mixing disparate LAN and SNA protocols on a single network. Due to SNA Server's extensive support for SNA and LAN protocols, in most cases LAN administrators do not have to make any changes to their current network structure. It fits right in. Whether organizations are using protocols such as TCP/IP or IPX or need to support Banyan VINES IP, AppleTalk, NetBEUI or remote dial-up clients, SNA Server can meet the challenge. SNA Server extends access to all SNA functions to all network clients through its protocol-independent client-server architecture. The result is desktop users can use their favorite host access product no matter which client operating system or networking architecture is currently in place or planned for the future.
Since SNA Server is an application integrated with Windows NT Server, it can grow with organizations as they increase the number of users connecting through the gateway, the number of host connections, or the types of applications that use gateway services.
SNA Server is also architected to take advantage of multi-processor versions of each of these systems. Running SNA Server on a multiprocessor system can dramatically improve performance in cases of high load or heavy traffic.
In any large IS environment, an individual gateway can be viewed as a single point of failure. For mission-critical use, Microsoft recommends a minimum of two SNA Servers to provide fault tolerance. Up to 50 SNA Servers can be grouped together to provide load balancing and hot backup, allowing sessions to be automatically rerouted to a backup gateway should the primary gateway or host link fail. The load balancing and hot backup features work both for mainframe connections and AS/400 connections-and both for dependent and independent LUs. For highest speed mainframe connectivity, SNA Server works with direct channel attached technology such as Barr Systems' Channel Adapter. This device can provide host access at speeds many times greater than the fastest direct LAN attachments.
A single Windows NT Workstation or Windows NT Server, located anywhere in the corporate network, can configure and manage all of the SNA Servers in the network using graphical tools that are included with the product. If the servers reside at a central location, the IS staff can be responsible for the administration and monitoring of all host access. This can also be accomplished from the IBM host console because of the integration of SNA Server with NetView facilities.
In addition, SNA Server provides numerous benefits to LAN and Host administrators through unique implementation features and configuration flexibility.
SNA Server is designed to provide easier administration, greater security, and configuration flexibility.
SNA Server reduces the frequency of VTAM® gen re-definitions, lessens host memory requirements, frees-up expensive host CPU cycles, saves network bandwidth, and provides high reliability for client access to host applications.
A large number of SNA Server installations use SDLC (Synchronous Data Link Control) to provide remote access into IBM mainframes. Most of those could benefit from implementing the SDLC technology provided by Barr Systems' T1-SYNC adapter. It is very probable that non-Barr SDLC implementations are using only about one-half of the bandwidth available. The original SDLC protocol requires that acknowledgments to frames be received before more frames can be sent. In practice, this means that data cannot be sent and received at the same time. A later enhancement to this original protocol was made to eliminate this problem. However, by the time of the enhancement there was a substantial amount of equipment already installed which had implemented the original version.
Communications standards can have a lot of inertia. In fact, today's IBM 3174 and 3274 controllers, as well as most SNA gateways, still do not support the full-duplex version of the SDLC protocol. When selected via the VTAM parameter DATMODE=FULL, this modified version of the basic SDLC protocol allows each station to send additional frames before receiving acknowledgments for earlier frames. All current-model Front-End Processors (FEPs) support DATMODE=FULL, and the protocol is widely used with mainframe-to-mainframe SDLC links.
A common VTAM parameter definition associated with an SDLC link is DUPLEX=FULL. This is not the same as DATMODE=FULL. Actually, DUPLEX=FULL does two things to improve throughput. First, it eliminates the modem line-turnaround time between raising the Request To Send (RTS) line and getting the Clear To Send (CTS) response. This can save up to 30 milliseconds each time the sending end changes. Second, for multi-drop lines, DUPLEX=FULL allows the FEP to send data to one device on the line while simultaneously receiving data from another device on the same line. While this does increase the utilization of multi-drop links, each device on the line still cannot send and receive at the same time.
Independent laboratory testing by The Tolly Group (formerly InterLab) has shown that simply by changing to DATMODE=FULL, SDLC links can achieve up to double the data throughput at any given connection speed. Thus, the same link could be supporting twice as many users, and transferring files in half the time. Even if all of the traffic is traveling in one direction, as it is during a solitary file transfer, throughput improvements of up to 30 percent can be accomplished. This is because not having to wait for acknowledgments eliminates dead time on the line. Barr Systems (Gainesville, FL) is the only provider to offer an SDLC adapter and drivers that support the DATMODE=FULL protocol on the SNA Server. The increase in throughput allows solution providers to configure SNA Server implementations that provide higher capacity and better response times over SDLC links.
Implementing an SNA Server environment for large numbers of users requires moving very large amounts of data through the gateway. The overall flexibility of SNA Server allows downloads of large databases from the mainframe, or the ability to run thousands of terminal and print sessions. The throughput requirements created by these application demands are unlikely to be satisfied by SDLC connections, even at rates up to T1 (1.536 megabits per second). Large requirements may exceed the throughput obtained via a 16 Mbps Token Ring connection-but there is a faster option.
Direct attachment to the S/370 channel achieves higher throughput to the mainframe than Token Ring links, with the side benefit of completely off-loading the FEP. The S/370 channel is the same interface that the FEP uses to connect to the mainframe. It's also the way disk drives and tape drives are usually attached to a mainframe. Direct connection to the mainframe reduces the effects of high data rates on other users of the FEP and improves end-to-end response times.
If all of the downstream devices currently attached to a given FEP can instead be connected through SNA gateways, enterprises may discover that they can retire a FEP. Support for Downstream Physical Units (DSPU) in the SNA gateway makes this much more likely. With DSPU support, the gateway can provide an interface that looks exactly the same as a FEP to PU type 2.0 and 2.1 devices such as 3174 and 3274 controllers. DSPU support is a core feature of SNA Server.
Figure 1.
Figure 1 depicts a channel-attached gateway linking to a TCP/IP network for distribution of sessions to remote workstations. This solution provides extensive wide-area capability without the expense of adding TCP/IP support on the mainframe. The same TCP/IP connections can also easily be used for routing LAN traffic, thus eliminating the duplication of wide area networks for SNA and inter-LAN traffic.
Barr Systems developed a product called BARR/CHANNEL to attach the SNA Server platform to a S/370 channel. BARR/CHANNEL includes
The S/370 channel is a daisy-chained byte parallel interface, so the channel attachment unit provides connectors for channel "in" and channel "out". The box can be located under the raised floor in the mainframe data center.
The reasons for the separate channel attachment box are two-fold. First, it eliminates the physical problems of connecting the unwieldy BUS and TAG cables directly to the PC running SNA Server. This allows the large BUS and TAG cables to be kept under the raised flooring. Second, it electrically isolates the S/370 channel from the PC. If the cable to the PC is severed or accidentally disconnected, or if the PC is rebooted or shut down, the box automatically connects the BUS and TAG cables straight through, with no effect on the mainframe or other peripherals that may be connected downstream. This allows insertion of the channel attachment unit along the BUS and TAG lines whenever the channel is shut down for maintenance. Through this feature, the SNA gateway can be attached to the live channel any time later. BARR/CHANNEL provides a low-cost, fail-safe method for putting an SNA Server directly on the mainframe channel.
Almost every 3270 emulation product supports 3287 print streams. These print jobs are usually oriented toward the transaction processing world. A terminal operator generally fills in a screen or two of data, then prints out a form, receipt, order, etc. This style of printing is satisfactory for large numbers of small jobs that need to be printed at many different locations.
High-volume production printing is another matter entirely. Large print jobs often range into the millions of pages per month. Insurance, investment, health care, utility, government and other industries frequently require such large printing volumes. These print jobs cannot be handled by low-speed printers. Even if enough ten to twenty page-per-minute printers were distributed to handle the total page count, these printers are not designed for the continuous duty cycles supported by high-speed laser printers in production environments. The pre- and post-processing equipment needed to feed paper, separate jobs, and stuff envelopes is also not available for low-end printers. Further, large print jobs must be stopped and restarted, for example, if the printer must be given more paper or toner. For these reasons, large print jobs are usually handled via high-speed printers and Job Entry Subsystem (JES) queues on the mainframe. The Remote Job Entry (RJE) protocol was developed to submit batch data and accept print jobs from JES queues for processing at distant locations.
By using the RJE protocol, high-speed printers can be connected to mainframes in numerous ways. Since RJE communicates through JES, it requires no changes to the host applications. The RJE protocol also supports electronic forms, printer information headers, and data compression. These necessary features are not available with 3287 data streams. Various minicomputer solutions were used as RJE terminals for many years. Today, standalone PC-based RJE systems are usually used, along with their own Token Ring connections or via dial-up or dedicated SDLC links. But, if a mainframe link exists to a remote location with an SNA Server, the mainframe link can be shared by putting RJE workstations on the LAN with SNA Server. This configuration is shown in Figure 2.
Figure 2.
The BARR/RJE product is a PC-based RJE workstation that used in conjunction with SNA Server. Logical Units for simultaneous print sessions are assigned to the BARR/RJE workstation by SNA Server just as they are for any 3270 workstation. The BARR/RJE workstation includes a built-in JES console, so providing control over the mainframe side of the printing process. It includes a full-function print spooler, giving local control over restart, reprint, printer selection, multiple copies, etc. BARR/RJE allows serial and parallel printers to be connected directly to the PC.
In addition, there is an option called PRINT370 that provides connection of S/370 channel-attached printers to the PC. This allows, for example, a 400 page-per-minute printer to be placed anywhere on the LAN with the SNA gateway, without requiring a separate data link. Production printing jobs then can be sent directly from JES to any PRINT370 location, with no changes to the host applications.
Today's SNA gateways and file servers have benefited dramatically from the inexorable march of progress in silicon because they are based on standard PC architectures. If support for large numbers of users, or addition of server applications such as SQL Server, is required, enterprises are going to need as much processor power as possible.
Microsoft's SNA Server employs the scaleable architecture of Windows NT, allowing organizations to use Pentium, multi-processor PC compatibles, DEC Alpha machines, or MIPS processors, to build a super-server to handle the processing requirements of large LAN-to-mainframe environments.
In the foreseeable future, the move toward distributed processing is going to increase, rather than decrease, the amount of data moving to and from mainframe systems. Advances in legacy communications technologies such as SDLC, S/370 channel, and RJE can make an important difference in the effectiveness of the implementation of distributed computing environments.
For more information:
Contact your local Microsoft office or a Microsoft Solution Provider near you. In the United States, call (800) 426-9400 for product information or to locate a Microsoft Solution Provider. In Canada, call (800) 563-9048. Outside the United States and Canada, call your local Microsoft subsidiary or (206) 936-8661. Via the Internet, use: http://www.microsoft.com.
Contact Barr Systems at: (800) BARR-SYS or (904) 371-3050.
 |
Click Here to Search TechNet Web Contents | TechNet CD Overview | |
Microsoft TechNet Credit Card Order Form At this time we can only support electronic orders in the US and Canada. International ordering information. |
| Go To TechNet Home Page |
©1996 Microsoft Corporation |  Go To Microsoft Home Page |