http://www.microsoft.com/technet/boes/bo/sna/technote/polaris.htm (PC Press Internet CD, 03/1996)
| Posted Date: March 14,1996 |  Go To TechNet Home Page |
Overview
Consolidating SNA and TCP/IP
TCP/IP-to-SNA Communications
Channel Connected Solutions
Polaris System 2000 Gateway
Microsoft SNA Server
Summary
The once independent roles of the IBM® mainframe network manager and the local-area network manager are now as enmeshed as the networks they must manage. Where previously they occupied completely separate links, it is now common to see both SNA and LAN traffic traversing the same LAN and WAN connections. Similarly, network managers now find themselves increasingly responsible for the integrity of all types of network traffic, where before they had been able to concentrate on a single protocol.
This white paper covers topics that will be of interest to network managers who have worked mainly with SNA, but it will be of equal interest to those whose background is primarily in the LAN world. Its focus is on the connections between the two, on the types of solutions the computer/communications industry has offered in order to bring these worlds together in the past, and on the latest interconnection methods available today.
Presenting this white paper are Microsoft and Polaris Communications. Polaris has assumed its position over the past eight years as a technology leader in providing high-speed programmable channel interfaces for direct attachment of all kinds of systems and peripherals to IBM mainframe channels. Polaris' programmable channel adapters provide the enabling technology used by a large number of computer and peripheral manufacturers to help them gain high-speed direct access to IBM mainframes.
This white paper has been produced to coincide with the formal release of the Polaris Communications System 2000 Gateway, which runs the powerful and richly featured Microsoft® SNA Server, operating on the Windows NT™ Server operating system platform. This white paper will cover issues of interest to virtually all network managers who have IBM mainframes as part of their network domains. And so, we encourage you to read on...
As SNA networks increasingly become targeted for replacement by routed multi-protocol TCP/IP based networks, data center managers have been run through one ringer after another, as one by one, each element of the tried and true SNA architecture has been dismantled--forced to fall in line with rules mandated by the new networking paradigm.
Gone are the days when the mainframe hosted all applications and all data worth accessing. Now it is common for users to need access to many types of systems--LAN based file servers, minicomputers, and mainframes even concurrently. Recently, SNA, the architecture of choice for more than a decade, turns out to be the biggest barrier to the implementation of the network of the nineties.
TCP/IP has emerged as the networking protocol of choice. It runs now as the mandated default protocol on most multi-protocol WANs, and as a real contender to IPX as the underlying protocol of choice on most LANs. All major computer operating systems run well with TCP/IP governing PC conversations with the networked world. Some, like UNIX and Windows NT have been structured to work with native TCP/IP. Others, like NetWare®, MS-DOS®, and OS/2® have been modified to work with it.
But the mainframe operating systems, MVS™, VM, and DOS/VSE, are different. Software products built to run on these operating systems were built to talk only to IBM's VTAM® (Virtual Terminal Access Method), which uses SNA as its underlying networking protocol. Everything was well defined, rigorously enforced, securely administered, expensive as all get-out, and tens of thousands of users could work on these systems at once. That was, and that remains, VTAM's appeal.
Traditional SNA LANs consisted of coax-connected terminals and printers. These devices were cabled to hardware controllers, which were either LLC or SDLC connected to Front End Processors over SNA-only networks.
We begin with a brief description of the SNA methodology by which users entered into conversation with VTAM in the past. They had no PCs. They used terminals, dumb terminals, 3270 terminals. To VTAM, these terminals were represented by Logical Unit (LU) Type 2 conversations. Mainframe printers used LU Type 1 or 3 data stream. These devices talked to the host mainframe via control units called 3174 cluster controllers or Physical Unit (PU) Type 2. Controllers were used to cluster, or group together, large numbers of terminals and printers that shared the SNA links to the host, primarily LLC (local Token Ring LAN connection) and SDLC (remote dial-up or leased line connection). SNA was devised as a means to share the relatively expensive CPU, or intelligence, of the mainframe with the relatively cheap, unintelligent devices on the network-terminals and printers. SNA was originally a very hierarchical system, with the host designated as Physical Unit Type 5, the front end processor as a PU 4 device, and controllers and other devices designated as PU Type 2 nodes.
For the most part these 3174 cluster controllers, and their coax-attached terminals and printers have gone by the wayside, at least as strategic network components. Most data centers will report that these older technologies are slated for replacement, although much more legacy equipment remains in place today than is normally admitted on industry surveys.
Emulation sessions replaced dedicated terminal and printer hardware, but still relied on an SNA LAN and WAN. Remote offices were connected to the mainframe via SDLC-attached remote controllers.
The terminal devices have been, and continue to be, replaced in significant numbers by PCs running 3270 emulation products. Dedicated mainframe controller-attached printers are being replaced by LAN attached printers, which also print PC reports and documents. The 3174 cluster controllers themselves are being replaced by gateways such as SNA Server.
SNA originally provided terminal access to host applications. Later, it evolved to allow PC-based emulation, offering users greater productivity and flexibility to integrate host data with PC applications. This productivity and flexibility fueled the move from terminals to terminal emulation, which in turn resulted in the advent of SNA-based client/server networks using IBM's APPC protocol. Applications on PCs could talk to applications on the mainframe by using APPC and a new protocol, LU6.2. Mainframe application software vendors built hooks into their programs to allow APPC access, and often these same companies built their own PC and PC-LAN based products to facilitate the use of the protocol. PC 3270 emulation vendors built APPC-enabling technology into their emulators. Some mainframe data centers undertook projects to develop their own APPC applications. APPC allows for advanced server-based solutions, such as those based on an SNA Server platform, like Proginet's™ FUSION FTMS™.
As more and more users were moved from terminal access to terminal emulation, and as more mission-critical computing was performed at the LAN and PC levels as opposed to on the mainframe, there was a push by LAN Administrators to rid their networks of SNA protocols in favor of more open protocols, such as TCP/IP. Replacing SNA with TCP/IP first occurred on the WAN. This is due to a number of factors, including the aversion to the high cost of supporting multiple protocols (TCP/IP and SNA) in a WAN environment, plus the relative speed advantage and reduced complexity of routing TCP/IP versus bridging SNA.
Typically, an SNA WAN consists of remote controllers connected over source route bridges or SDLC leased lines. The SNA WAN is generally not integrated with the routed TCP/IP WAN.
In the branch office, remote SNA consisted of SDLC-attached 3174 cluster controllers that communicated to the host via leased, multidrop and dial-up lines. These remote controllers are being replaced by PCs running remote 3174 emulation, still running on the same 9600 bps or 56k bps lines previously attached to the real 3174s. The 3174 emulation, or SNA gateway software, as it is commonly called, was varied and ran on many different platforms, including MS-DOS and OS/2. This methodology has had its day, but now it too is destined to become a memory.
Router-based networks carrying TCP/IP and IPX traffic have been installed to handle non-SNA traffic. Initially, this non-SNA traffic came in on its own communication lines. However, typically from the start the plan was to ultimately carry the mainframe-based traffic as well. Many different methods have been put in place to carry the SNA traffic alongside the TCP/IP traffic: tunneling technologies, remote source-route bridging, encapsulation, datalink switching (DLSw). These are techniques designed to carry all traffic, TCP and SNA-based, over a single line or set of communication links.
These technologies took some time to fine-tune to the point where they actually worked, and the growing pains caused by many of these approaches have been well documented during the first half of this decade. The relative merits of these approaches is necessarily the subject of another white paper. But by now, most organizations have come up with one satisfactory method or another for eliminating the use of the SNA/SDLC WAN protocol, typically by replacing it with LLC, the SNA LAN protocol, and using DLSw, or some sort of encapsulation, to carry it across a TCP/IP WAN architecture. SNA SDLC links are getting about as scarce as hen's teeth; soon, only the farmers will have them.
Still, SNA exists today at most corporate headquarters. LLC, the SNA LAN protocol, is all over the place; its signals are generated by both the downstream node (DSN) LAN-attached PC Gateways that support the headquarters staff, and, of course, by the home-office routers that must decapsulate the remote SNA traffic that their sister routers in the remote branches wrapped up and shipped over.
For LAN users, both local and remote, these LLC packets contain LU2 screen sessions, LU1 and LU3 printer sessions, and LU6.2 APPC sessions, all carried across the LAN and up to VTAM through some sort of channel-attached device, either via older style 3174 controller products, via more robust 3745 and similar front end processors, or via newfangled 3172 XCA gateways (for VTAM releases 4.1 and later).
But once again, the cry has gone up. SNA is cramping the style of an otherwise uniform TCP/IP environment. Because, over LAN or WAN, SNA is deterministic; it must travel over a predetermined path, (it cannot be routed in its native format), and it must know in advance where it's going, how it's going to get there, and how long it's going to take. TCP/IP doesn't work that way. It likes to make its own decisions on which direction it wants to send packets, and it cannot really guarantee that it will meet any sort of deadline, only that it will do its best to get its packets to the proper destination in the shortest time possible. And just as native SNA got booted off the WAN, its time on the LAN is getting pretty short. SNA is in the way, and LAN managers want it gone.
One seemingly promising method for eliminating SNA on the LAN is the installation of the native TCP/IP protocol stack on the mainframe and the use of the 3172 in TCP/IP pass-through mode to perform the physical packet transfer between LAN and mainframe channel. The suite of software delivered with the TCP/IP protocol stack (available from IBM for MVS and VM systems, or from Interlink for MVS systems only), includes an interface to VTAM for delivering 3270 terminal users to its applications. Newer releases from both IBM and Interlink also include methods for delivering mainframe print, previously destined for VTAM print LUs, to TCP/IP-based printers via an lpr/lpd mechanism.
The mainframe TCP/IP stack allows for the creation of a TCP/IP-only LAN and WAN.
As stated above, this is interesting as an alternative. Its beauty lies in the fact that from the standpoint of the LAN, SNA traffic is completely eliminated. Its downfall lies in both its limitations and its costs.
The key limitation, and probably the downfall of this alternative, is that mainframe TCP/IP does not talk to SNA clients; it talks to TCP/IP clients. SNA clients provide 3270 emulation for LU2 screen sessions, LU1 and LU3 emulation for printer sessions, and LU6.2 emulation for APPC sessions.
TCP/IP clients provide TN3270 emulation for screen sessions, and that's about it. TN3270 is NOT the same as 3270. TN3270, contrary to popular belief, is not the well-considered result of much arguing and negotiation, as would be an Internet RFC. TN3270 is a de facto standard based on the way the IBM TCP/IP stack handles inbound terminal requests. If you look underneath any TN3270 emulator, do you know what you'll find? TELNET, plus a nice way of blocking together groups of characters for transmission so it doesn't have to put each character in its own packet the way ordinary TELNET does.
The TN3270 emulator has no standard way of representing the ATTN key or the SYS REQ key as on a real 3270 keyboard, the way all "real" 3270 emulators do. The TN3270 emulator has no mechanism for handling LU1 or LU3 print sessions, the way "real" 3270 emulators do. The TN3270 emulator has no inherent way of handling mapped LUs, aiming client sessions at specific VTAM definitions, the way "real" 3270 emulators do. The TN3270 emulator has no way of handling LU6.2 APPC traffic, the way most "real" 3270 emulator products do. These are limitations and they are significant.
Of course, there is another aspect of TN3270 that now makes it virtually a requirement for most data centers to accommodate. TN3270 is available to a much broader base of users than the traditional 3270 clients. Real 3270 emulation software runs on PCs, and though not as common, it can be found on UNIX® machines. But TN3270 also now exists on network terminal servers, allowing really dumb devices, like VT100 terminals, to pick up a 3270 emulation at a very low cost. And TN3270 is an excellent way to allow external public users to traverse the Internet and access the data center's mainframe without requiring these external users to buy a lot of fancy, expensive gear for a simple look at some service the data center has been asked to provide. For these types of users, TN3270 is a good deal. But for corporate PC users who have been using "real" 3270 emulators, it probably is not.
We stated above that there were two reasons TCP/IP on the mainframe was probably not the answer to eliminating the SNA protocol from the LAN. Remember, that's where we were going with this discussion. One was the limitations of the TN3270 client protocol, and the other was the cost.
The cost factor is significant, and it is easy to understand. When an SNA user comes into a mainframe using an SNA protocol, he goes straight to VTAM and tells it which PU/LU combination he is using. VTAM then takes the user where he is supposed to go. When a TN3270 user enters the mainframe, he comes in as a bunch of TCP/IP packets, which must be converted by the mainframe running the protocol stack into a PU/LU combination and handed off to VTAM for processing. The mainframe does the conversion. Mainframe cycles are expensive. MIPS on a mainframe are sold at a premium. Most savvy host administrators refuse to relegate their host to performing the function of a protocol converter. This is where the phrase "water-cooled protocol converter" comes from.
In response to both the costs and the limitations of the mainframe TCP/IP protocol stack, many products have come to market, first from Mitek (now OpenConnect Systems), then from McDATA (now gone from this marketplace), then Apertus Technologies (formed from the ashes of Lee Data), and other smaller and newer players, all of whose products are designed to convert TN3270 clients coming across TCP/IP LANs into VTAM without the use of mainframe TCP/IP.
They all point to the obvious lower cost of running the required protocol conversion on these gateway processors rather than on the mainframe, and each deals in its own way with the limitations imposed by the TN3270 protocol. Each product, for example, has a way for dealing with the problem of mapping users to specific PU/LU combinations. Each has provided the ATTN and SYS REQ keys in one way or another, and each has come up with a method of getting printer sessions out to TCP/IP attached printers. Most of these vendors are now working to support the new TN3270E specification (RFC 1647), which handles most of these issues in a standard way. But ALL of these products have one thing in common: They ONLY handle TN3270 clients.
Nevertheless, if a data center is willing to forsake LU6.2 applications, and equip all its PC users with a TN3270 emulator, it can move to this type of gateway and achieve the elimination of SNA from the LAN environment. Compared to the all-or-nothing approach of the proponents of mainframe TCP/IP, these gateway vendors offer an alluring concept: Don't get rid of SNA entirely; simply confine it to the mainframe channel, to the machine room.
But to embrace this solution, the data center must still pay a price, and a steep one at that.
We have already agreed that most data centers will have a need for SOME TN3270 clients. It can also be said, though, that most data centers will have a need for SOME "REAL" 3270 clients, whether due to an LU6.2 application or some other 3270 function that is either unavailable or inconvenient in the TN3270 environment. It can be said with equal certainty that compared to its population of TN3270 emulators, most data centers today have installed a much larger population of "real" 3270 clients: EXTRA!® and IRMA™ from Attachmate, RUMBA® from Wall Data, and others. True, all of these products now include a TN3270 emulator. But make no mistake, these TN3270 emulators are never the same, and do not have the same features as the "real" 3270 emulators in the same package.
There is, of course, some good news here. There always is in a white paper. It comes to you from Microsoft and Polaris Communications. Microsoft's Windows NT operating system is what lays the foundation for the solution. It allows all LAN network traffic to exist in pure, routeable TCP/IP. The good news is Microsoft SNA Server, which runs on the Windows NT Server platform and supports native Windows Sockets TCP/IP. It lets you have it all. You can run LU6.2 clients and server-based applications. You can run real 3270 clients like EXTRA! and RUMBA. You can run TN3270 clients-any of them.
The Microsoft SNA Server provides the network administrator with the network environment he is looking for: straight TCP/IP, straight IPX, NetBEUI, Banyan® VINES® IP, AppleTalk®, or mixed. Yet NO LLC, NO SNA anywhere on the LAN or WAN. Those users who want or need a TN3270 solution can have one; SNA Server will support them natively. Those who are currently using or want to use a "real" 3270 Client can use it.
And SNA; it didn't go away. As with the TN3270-only gateway vendors, it's still there, confined to the channel, courtesy of Polaris Communications and its System 2000 Channel-Attached Gateway. Although with the Polaris system, "confined to the channel" no longer means "confined to the machine room," because of advances in channel technology, and because of the new ESCON® (Enterprise System CONnection) fiber channel.
To fully appreciate what this means, it is necessary to have a good high-level understanding of basic IBM channel technology and its history. Understand that there is only one way to communicate with a mainframe, and that is through its channel. The mainframe has no LAN ports, no serial ports, no SCSI ports, no ports of any kind, just one or more channels. The traditional, older-style channel is called Bus & Tag, named for the two sets of signals that race over its copper wiring. Newer mainframes still support Bus & Tag, but also support ESCON fiber channels, which feature many enhancements over Bus & Tag.
All devices that want to converse with the mainframe must do so via some sort of channel-attached control unit. Control units attach to the channel and provide buffering and preprocessing for tape drives, disk drives, terminals, virtually any devices that either are directly cabled or somehow remotely attached to the control unit.
The Bus & Tag channel uses heavily shielded copper-based cables, supporting the daisy chaining of up to 8 or 16 control units in series. The Bus & Tag channel was introduced in 1964 with the announcement of the IBM 360 class of mainframes. Since the 1960s, there has been continuous improvement to the speed and physical span of the Bus & Tag channels. In 1970, the Block Mux channel was introduced with the S/370™ class of mainframes, allowing sharing of the channel by multiple high-speed control units.
In 1980, IBM introduced the Data Streaming mode of transfer over the Block Mux channel. Unlike its predecessors, the DC Interlock mode and the "High-Speed" mode, the Data Streaming transfer mode serviced all control units with the same transfer rate, with virtually no degradation in data throughput regardless of the position of the control unit within the 400-foot span of the channel.
Today, the Block Mux channels offered on the ES/9000™ series of mainframes can support transfer rates of 4.5 megabytes (MB) per second over a span of 400 feet. Up to sixteen control units can be daisy chained on a single channel.
The ESCON channel was introduced in 1990 with the S/390® architecture. ESCON provides a vast improvement in performance, flexibility in wiring, and dynamic connectivity. ESCON uses light-weight fiber optic cabling for distances of up to 9 kilometers and transfer rates of 200 megabits per second (17 megabytes per second). Through the use of ESCON Directors (switches), ESCON channels offer a switched point-to-point topology for dynamic connectivity and flexible channel interconnections.
IBM, as well as many third party manufacturers, provides both Bus & Tag and ESCON channel-attached control units. Each control unit attaches a certain class of peripherals or devices to the IBM mainframe. There are disk control units for attachment of disks, and tape control units for attachment of tapes, and so on. A front end processor (FEP) is a channel-attached control unit for connecting SNA-based communication networks to the IBM mainframe. 3174 describes the class of control unit previously described as a cluster control unit for "clusters" of 3270 terminals and printers. 3172 describes the class of control unit previously described as having been designed for pass-through communications, either in TCP/IP mode, or in SNA (XCA) mode, passing either TCP/IP packets or SNA packets between the channel and one or more LAN segments.
The Polaris System 2000 running the Microsoft SNA Server looks to the mainframe like one or more 3174 cluster controllers, bringing thousands of concurrent users into VTAM. Like the 3172, it is available with one or more channel connections, and these can be either Bus & Tag, or ESCON, or a combination of both. But the similarity ends there. As we discussed earlier, the System 2000 actually performs protocol conversion. It is not a simple pass-through device like the 3172, and therefore requires, understandably, faster processors, and a faster bus than the 3172.
Just as IBM mainframe channel technology has been updated and enhanced over the years, so too has the underlying transport vehicle, "the bus," used in IBM PC technology. Beginning with what is now termed the ISA (Industry Standard Architecture) bus in the early 1980s, which maxes out at about 2.2 MB per second throughput, through two interim technologies EISA and MicroChannel (both 40 MB per second), we have now arrived at PCI, today's fastest industry standard bus available, delivering throughput at speeds up to 133 MB per second.
Unlike any of its predecessors, however, PCI has gained unprecedented acceptance outside the PC arena, and this should serve to lengthen its lifespan considerably. DEC™, with its Alpha series, and IBM, with its new models of RS6000, were among the first UNIX vendors to announce PCI-based systems. Now, just about all minicomputer vendors are making plans to replace, or at least augment their proprietary buses with PCI-based architectures.
Today, the Polaris System 2000 ships standard with four PCI slots, which are reserved for Polaris's PCI-based Bus & Tag and ESCON boards, and a "best of breed" selection of PCI-based LAN interface boards. These are the critical elements that demand speed in the Microsoft SNA Server environment. The System 2000 also includes three ISA slots that are used for system elements for which high speed is not essential, like the video and disk controllers.
Currently, the System 2000 ships with a single Pentium® microprocessor running at 120 megahertz (MHz). Future plans include dual and quad-Pentium designs. Pentium Pro-based systems will follow. The System 2000 also ships standard with 32 MB of RAM, and is field upgradeable to 128 MB of RAM to support larger numbers of users.
The System 2000 is built from the ground up with the particular needs of the data center in mind. In fact, "from the ground up" is a good description, because that's where the Bus & Tag Channel cables come from, and the System 2000 is built to accept these cables through a large opening in the bottom of the enclosure. The heavy-duty power supply and twin-fan cooling system have also been designed with the special needs of the Bus & Tag connections in mind.
24 hour/7 day software support and both 9 hour/5 day and 24 hour/7 day hardware maintenance contracts are available, and are administered through Polaris's 1-800 hotline. On-site whole-unit-spares are also available for mission-critical accounts that cannot afford even two hours of downtime while waiting for an engineer to arrive.
Network managers can leverage SNA Server and the Polaris Communication channel attachment capabilities when implementing an "SNA gateway" approach to host connectivity. In this section, we will explore SNA Server's capabilities, focusing on features that allow network administrators to integrate SNA with TCP/IP networks.
SNA Server provides the network manager with more flexibility, including full SNA API support, increased LAN protocol choice, a platform on which to plan for future growth, an extra layer of configurable security, and local and remote administration.
SNA Server is a flexible 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, Windows NT Server. SNA Server can be configured as an IBM PU 2.0, PU 2.1, APPN® LEN node, and can support multiple DSPU devices. LU services provided are LU 0, 1, 2, 3, and LU 6.2. SNA API support is comprehensive, including APPC, CPI-C, CSV, LUA/RUI, LUA/SLI, and EHNAPPC. SNA Server supports direct TN3270 access to host applications through a Windows NT Server-based TN3270 service. Advanced features offer high-speed file transfer through support of APPC File Transfer Protocol (AFTP), as well as interactive host data access with the StarSQL ODBC/DRDA client.
SNA Server's client/server architecture provides a broad range of capabilities.
SNA Server is designed to provide LAN protocol choice, configuration flexibility, scalable growth, greater security, easier administration, and multiple licensing options. These strengths can aid the migration from an SNA-only or multiprotocol network to a pure TCP/IP environment.
The focus of this paper is integration of TCP/IP as a strategic LAN/WAN protocol with SNA connectivity. However, not many environments have reached the nirvana of a pure TCP/IP-only network. The majority of organizations require a migration plan from a multiprotocol to a single TCP/IP protocol environment. SNA Server provides this necessary first step, as well as a final solution for integrating TCP/IP with SNA.
SNA Server offers flexibility and greater choice.
A network administrator can select the LAN protocol that best suites the needs in a given network deployment, whether TCP/IP or another popular LAN protocol. SNA Server supports five common LAN protocols: TCP/IP, IPX/SPX™, NetBEUI, Banyan VINES IP, and AppleTalk. Additionally, remote access to host resources is provided through Windows NT Server's Remote Access Service. Compatible emulation products are written to the SNA Server client/server API and take full advantage of the protocol independence designed into the SNA Server client and server software.
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.
The LAN administrator can control access to the host by using the integrated security features of Windows NT Server and SNA Server. In contrast, direct connection allows each end-user to access the host simply by knowing the applicable host parameters. A gateway adds an extra layer of flexible security.
This extra layer of security is an important capability when deploying a TCP/IP-to-SNA gateway. With most TN3270 solutions, if one knows the IP address of the host, then one can connect. Only the host security prevents unauthorized access. With SNA Server, only those client emulators and server-based applications that are authorized to access the SNA Server host gain connectivity to the host.
SNA Server's graphical Admin running over a RAS connection.
In the last section, we looked at SNA Server's flexibility from a network management perspective. In this section, we will expand this view to a discussion of how SNA Server can be deployed to take advantage of its versatility. There are three basic deployment options for SNA Server. Additionally, SNA Server performs a number of roles, from full-featured SNA communications server for traditional full-stack and split-stack SNA client emulators, to acting as a TN3270 server off-loading the TCP/IP-to-SNA protocol conversion from the host. Further, SNA Server supports the multiple paths available in a modern WAN to connect from client PC to host mainframe by supporting all required host connectivity methods.
SNA Server allows LAN administrators to configure and implement a variety of host connectivity options by utilizing a branch-based, centralized, or distributed deployment model.
Branch-based deployment model. Remote SNA Servers connect to the host via SDLC or LLC.
Centralized deployment model. Channel-attached SNA Servers provide support for TCP/IP clients.
Distributed deployment. Remote SNA Servers connect via TCP/IP to central site SNA Servers, sharing the channel-attached host links.
In any organization, 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. Multiple 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 for both mainframe and AS/400 connections and for both dependent and independent LUs.
Polaris channel attachment options fit right into SNA Server's open SNADIS architecture.
SNA Server provides support for all popular host connections. Its object architecture and open SNA Device Interface Specification (SNADIS) allow SNA Server to incorporate new host connection methods as they become available. The open API allowed key independent hardware vendors, such as Polaris Communications, to develop complete host connectivity solutions, including Polaris Bus & Tag and ESCON attachments. Support for the Polaris System 2000 Gateway was added to SNA Server 2.11 without compromising the stability of the SNA Server product, because SNADIS isolates the host adapter drivers from the core SNA Server components.
SNA Server allows network managers to maximize existing SNA resources by saving SNA network bandwidth, reducing host memory usage, and consolidating host definitions while focusing the host CPU on running applications.
When using a gateway, the host system can support a large number of sessions over a single connection. This is in sharp contrast to other connection schemes where the host may be required to poll each desktop individually to maintain connections (even when there's no activity) such as with direct TCP/IP or TN3270 connectivity. The ability of SNA Server to provide a single gateway-to-host connection can dramatically reduce network traffic and allow better network performance. SNA Server supports not only the popular TN3270 clients but also more advanced server-based solutions providing high-speed file transfer, advanced function printing and database access.
With other host access models, hundreds of end-user definitions are typically stored in resident memory on the host system and FEP, consuming expensive host resources. By assigning individual user accounts to host resources on the SNA Server machine, SNA Server allows memory savings to be realized on the host system, which can result in hardware savings and in improved host performance. Many large enterprises reach a point at which they are forced to start using SNA gateways because they run out of physical address space for definitions in VTAM or NCP.
SNA Server is designed to minimize (re)definition work on the host. With SNA Server, hundreds of users can be supported by defining a single PU or controller. On mainframe systems, VTAM gens must be scheduled in advance with little margin for error due to the high costs and inevitable downtime. Host administrators can rely on the end-user definitions on the SNA Servers to allow for more flexible changes at the gateway as demanded.
If there are direct connections to the host, each of these connections must be managed individually by the host's control software, consuming expensive CPU cycles. IBM invented the FEP because host performance was substantially degraded by maintaining a large number of network connections. In fact, a FEP can be considered a gateway and a channel-attached SNA Server can augment FEP hardware.
The System 2000 Gateway running the powerful and richly featured Microsoft SNA Server provides a gateway that is unique in power, performance, and flexibility. It uses the industry's fastest available processors, system bus, network interfaces, and channel interfaces, including both 4.5 MB per second Data Streaming Bus & Tag, and ESCON, IBM's new fiber offering.
The System 2000, and Microsoft SNA Server provide the TCP/IP-connected TN3270 user with the same high-speed mainframe connectivity it offers to traditional 3270 SNA-connected users and provides LU6.2 APPC applications with the fastest possible mechanism through which they can carry on their peer-to-peer conversations.
The alliance between Polaris and Microsoft brings together the recognition and experience of Polaris as a mainframe connectivity vendor with the commitment and expertise of Microsoft in supporting both SNA and the multivendor LAN protocols. This alliance brings to market a solution that provides the customer with the desired flexibility and the required growth path in all areas: in mainframe connectivity, in network topology, and in support of every standard LAN protocol.
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.
Contact Polaris Communications at (800) 353-1533 in the United States, or outside the United States call us at (503) 643-1533. We can also be reached by fax or email, and our web site is accessible 24 hours a day:
The information contained in this document represents the current view of Microsoft Corporation on the Microsoft issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
Microsoft's support services are subject to Microsoft's then-current prices, terms, and conditions, and are subject to change without notice.
© 1996 Microsoft Corporation and Polaris Communications. All rights reserved. This document is for informational purposes only.
MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.
Microsoft, MS-DOS and Windows are registered trademarks and BackOffice and Windows NT are trademarks of Microsoft Corporation.
AppleTalk is a registered trademark of Apple Computer, Inc.
Attachmate and EXTRA! are registered trademarks and IRMA is a trademark of Attachmate Corporation.
Banyan and VINES are registered trademarks of Banyan Systems, Inc.
Alpha AXP and DEC are trademarks of Digital Equipment Corporation.
APPN, AS/400, IBM, NetView, OS/2 and VTAM are registered trademarks and ES/9000 and MVS are trademarks of International Business Machines Corporation.
Intel and Pentium are registered trademarks of Intel Corporation.
MIPS is a registered trademark of MIPS Computer Systems, Inc.
IPX/SPX is a trademark of Novell, Inc.
PowerPC is a trademark of Motorola, Inc.
Fusion FTMS and Proginet are trademarks of Proginet Corporation.
UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company, Ltd.
Wall Data and RUMBA are registered trademarks of Wall Data Incorporated.
All other trademarks or registered trademarks are the properties of their respective owners.
0196 Part No. 098-62920
 |
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 |