© October 1994 by NetSoft and Microsoft Corporation
In May of 1994, IBM announced a new series of AS/400 systems that are upgradeable to the RISC-based PowerPC processor. The announcement also included a new version of the AS/400 operating system, OS/400 Version 3 Release 1 (V3R1). Among other things, V3R1 will feature internetwork connectivity based on IBM’s Multi-Protocol Transport Network (MPTN) architecture. This announcement underlines customer interest in efforts at making the AS/400 a more open and interoperable system.
The traditional advantage of the AS/400 as an integrated, single-vendor solution to business computing problems is under increasing pressure. Rapid growth in desktop and network computing is pushing the profile of AS/400 connectivity from single-vendor to multi-vendor. The AS/400 environment must keep up with the rapidly changing desktop and network environment to retain unique value in the era of heterogeneous computing.
Microsoft and NetSoft have formed a partnership to integrate the AS/400 with Microsoft® Windows™ clients on multi-vendor local-area networks (LANs). Such cooperation is essential to customers seeking to integrate the AS/400 with new desktop and network computing systems. This white paper presents the strengths and benefits of this Microsoft/NetSoft partnership.
Two approaches have emerged for connecting the LAN to the AS/400. One is known as direct connect and the other may be conveniently referred to as gateway or front end processor (FEP). Historically, IBM has used the gateway or FEP approach to offload network processing from the mainframe. Microsoft SNA Server, which runs on the Windows NT™ Server platform, offers a similar approach to offloading network processing from the AS/400. The Microsoft solution has the added benefit of delivering strong support for heterogeneous LAN installations with connected Windows clients (Figure 1).
Figure 1.
The major benefit of the gateway approach is flexible support for rapidly expanding desktop and network systems. Gateways allow end users, network administrators, and host administrators to integrate growing PC LANs with the AS/400 without sacrificing any of the services of each environment. More significantly, they eliminate major reliability, performance, and resource problems that occur with the direct connect approach.
With the direct connect approach, the 802.2 (DLC) protocol and a LAN protocol, such as TCP/IP or IPX/SPX (to connect to existing file/print/database/mail servers), is needed on each Windows client. In many cases, it is simply not possible to get the DLC protocol to work or coexist with certain types of third-party adapters and/or protocols. Microsoft SNA Server enables the use of one protocol for both AS/400 and LAN server access. Using only one protocol retains user access to both computing environments, reduces network traffic complexity, increases network stability, and saves desktop memory.
By using a single desktop protocol, customers can rid themselves of remaining terminate-and-stay-resident programs (TSRs) and DOS device drivers. With Windows for Workgroups 3.11 and the upcoming Windows 95, customers can even get fully-protected-mode NDIS or ODI drivers and protocol stacks. This is not the case when using direct connect; the DLC protocol is a TSR and thus requires a real mode NDIS or ODI driver. In addition, IBM's DLC protocol (LAN Support program) only works with certain adapters and protocol stacks. Removing real-mode TSRs and drivers obviously saves memory, but can also bring a dramatic improvement to the stability of the desktop because most hangs on Windows occur during real/protected mode interaction.
A gateway approach is easier to manage on the LAN. With direct connect, each desktop must be configured individually with the host's network address, LU name, and so on. When a change happens on the host side (for example, the host's network address changes), all desktops must be reconfigured. With the Microsoft SNA Server, there is nothing to configure at the client level and all host changes can be tracked centrally by the LAN administrator.
The gateway approach also provides integrated security. The LAN administrator can control who gets access to the host by using Windows NT’s C2 level security features. With direct connect, each desktop accesses the host by simply knowing the applicable host parameters.
The gateway approach also provides better performance and troubleshooting tools. When all host-bound traffic is concentrated through Microsoft SNA Server, the LAN administrator can use the performance monitoring, event logging, and tracing capabilities of the Windows NT Server platform. An individual desktop problem is easier to work around by simply assigning a new LU, and tracing/debugging can be done at the server without disturbing the desktop users’ work.
The gateway approach means dramatically less (re)definition work and resource usage for the host. With Microsoft SNA Server, a single controller can handle hundreds of users, rather than defining one controller per user. With an AS/400, change control can be done infrequently, perhaps once a month, to minimize down time. Less definition work with gateways results in fewer errors, and definition errors can be very costly. In addition, some of the largest IBM customers have been forced to start using gateways because they have run out of physical address space for definitions.
Of even greater significance is the potential savings the gateway approach provides in host CPU usage. With direct connections to the host, each connection must be managed individually by the host's control software, consuming large amounts of CPU time. Some studies have shown that it is possible to free up as much as 30 percent of the host's CPU simply by switching from direct connections to a gateway approach. This is why IBM invented the front-end processor (FEP) in the mainframe world. The host was being brought to its knees just servicing connections. An FEP is a gateway approach, albeit with hardware and software that is more costly than a PC running Microsoft SNA Server.
Network bandwidth is another significant resource savings realized from the gateway approach. Instead of having to poll all desktops (to maintain connections during inactive periods) with direct connections, the host has to poll only a few PU connections when using gateways. This can dramatically reduce the network utilization (or noise), allow for better network performance, and reduce session time-out problems.
PC Support/400 (PCS/400) client software was designed in the late 1980s by IBM to meet the AS/400 connectivity needs of MS-DOS–based PC clients. At the core of PC Support client software was the APPC "router". By consuming large amounts of real-mode memory, the "router" (and the other PCS/400 programs) created performance and reliability problems in the Windows environment. The router lacked support for internetworking protocols such as IPX/SPX and TCP/IP, offering only the direct-connect approach. In addition, the router did not exploit the ease-of-use characteristics in the Windows user interface.
Productivity applications such as word processors and spreadsheets have traditionally benefited most from the Windows graphical user interface (GUI). AS/400 connectivity is a more complex problem for Windows clients due to the inherent limitations in MS-DOS–based networking technology. Effective Windows-to-AS/400 integration must therefore include the removal of MS-DOS–based networking components and the addition of GUI services for accessing and using AS/400 servers. Figure 2 illustrates the Microsoft/NetSoft Windows-to-AS/400 client. MS-DOS networking components have been eliminated and native Windows client services deliver access to AS/400 servers through heterogeneous LANs and Microsoft SNA Server.
Figure 2.
NetSoft responded to these problems by creating an LU 6.2/APPC facility for PC-to- AS/400 connectivity with a native Windows architecture and GUI metaphor. This facility is the NS/Router. NS/Router performs all AS/400 connectivity tasks within Windows. This allows the user to take advantage of the natural work flow of the GUI. AS/400 connections are started and stopped using drag and drop techniques. AS/400 security is dynamically enforced within Windows since the host can drop links upon inactivity. Casual, user-initiated AS/400 connections become the norm.
To solve the problems experienced by PC Support users migrating from MS-DOS to Windows, NetSoft built a complete family of native Windows client replacements for corresponding PC Support TSR programs. This family is known as NS/Midrange Client Services, and includes Elite/400, NS/Router, NS/Transfer, NS/Commander CL, NS/Folders, NS/Queues, and NS/Virtual Print. Each NS/Midrange Client Service uses the NS/Router as its foundation. Each NS/Midrange Client Service is designed and built as a Windows solution that exploits Windows GUI features such as drag and drop. And each NS/Midrange Client Service can import existing PC Support configuration files and data.
NS/Midrange Client Services allow Windows to perform more reliably because they eliminate the use of conventional memory. The majority of Windows crashes occur during software component interactions that switch a CPU between real mode and protected mode. NS/Midrange Clients use native Windows code services such as virtual device driver (VXD) and dynamic-link library (DLL) modules. In Microsoft SNA Server installations, this eliminates real mode access for network IO, increasing overall Windows client reliability. In addition, all Windows-to-AS/400 applications run faster; they do not need to make DOS protected-mode interface (DPMI) calls to switch the PC into real mode to communicate with TSRs.
Beginning with version 2.2, PC Support included a set of Windows DLL interfaces for the various DOS TSR services. The Windows APPC interface for the DOS router was known as EHNAPPC.DLL. NS/Router delivers a binary compatible version of this interface. Liberated from the constraints of a DOS router, the EHNAPPC.DLL API became much more attractive to independent Windows-to-AS/400 software vendors. These vendors experienced immediate speed and reliability improvements by using NS/Router. They also reduced the amount of time spent on development and support of the DOS router. NetSoft continues to deliver binary-compatible versions of applicable PC Support’s APIs in NS/Midrange Clients. Today the NS/Router is supported by more than 50 independent software vendors (ISVs).
Microsoft SNA Server and NetSoft NS/Midrange Client Services preserve the best aspects of both the PC LAN and AS/400 computing environments. Many customers need to run AS/400 and LAN environments together as highly integrated systems, with each optimized for specific applications and services.
The Microsoft/NetSoft partnership provides the most effective Windows connectivity for mixed AS/400 and LAN environments. It offers AS/400 users with significant LAN and Windows investments all of the following:
The Microsoft/NetSoft AS/400 connectivity partnership offers immediate and effective integration of the AS/400 with multi-vendor LANs running Windows clients. All of the products and services described above are available today. For more information on Microsoft SNA Server, contact Microsoft Corporation at (800) 426-9400. For more information on NetSoft NS/Midrange Client Services, contact NetSoft at (800) 352-3270.
________________________
NetSoft and NS/Router are registered trademarks and NS/, NS/Midrange Client Services, NS/Transfer, NS/Commander CL, NS/Folders, NS/Queues and NS/Virtual Print are trademarks of NetSoft.
Microsoft and MS-DOS are registered trademarks and Windows and Windows NT are trademarks of Microsoft Corporation.
IBM and AS/400 are registered trademarks and Client Access/400 and PC Support/400 are trademarks of International Business Machines, Inc.
All other product names are the trademarks of their respective companies.