Upload
api-3743621
View
486
Download
3
Embed Size (px)
Citation preview
TCP/IP Connectivity in an AS/400 EnvironmentTCP/IP has become today's standard for "open" networking. Virtually all the major computer and
network vendors now support the TCP/IP protocol and service suite as an integral part of their
products. In particular, IBM has made great strides toward fully integrating TCP/IP into the OS/400
operating system; and Microsoft now allows you to select TCP/IP as the underlying protocol for
Windows for Workgroups, Windows 95, and Windows NT networks. As a result of these and other
developments, yesterday's proprietary network-level transport protocols have been shoved aside by
TCP/IP.
Despite the ubiquitous nature of TCP/IP, implementing TCP/IP for client/server connections in the
AS/400 environment is not a clear-cut matter. You can construct a TCP/IP-based client/server
solution for the AS/400 three different ways:
• You can use native TCP/IP protocols (TN5250, FTP, LPR/LPD) and services on the desktop and on
the AS/400.
• You can run standard SNA client/server traffic over TCP/IP using IBM's AnyNet architecture.
• You can deploy a TCP/IP-SNA gateway, such as Microsoft's SNA Server, to route client/server
traffic between the desktop network and the AS/400.
The intent of this white paper is to help you understand the underlying technology of TCP/IP and how
it relates to these three connectivity strategies. To accomplish this objective, the white paper will
explore the following topics:
• How TCP/IP became the standard for open networking.
• The distinction between using TCP/IP as an interoperability solution and using TCP/IP as an
underlying network protocol.
• The key differences between the Microsoft client-side TCP/IP implementation and the AS/400
server-side TCP/IP implementation.
• The architecture and pros/cons of each of the three TCP/IP client/server connectivity strategies.
Based on the information presented here, you should be able to evaluate the TCP/IP client/server
needs of your organization and determine which of these three strategies best addresses those
needs.
On This Page
The Transmission Control Protocol/Internet Protocol
The Transmission Control Protocol/Internet ProtocolTCP/IP was originally developed to enable interoperability among diverse system types. The
development of TCP/IP was primarily funded by the United States Department of Defense (DOD)
under the direction of the Advanced Research Project Agency (ARPA). The United States
government's participation in the development of TCP/IP created two significant, long-term benefits:
• All the core TCP/IP services and protocols are public domain possessions. Anyone can obtain
TCP/IP specifications and implement their own services and protocols.
• In the early 1980s, the DOD dictated that computer manufacturers must support TCP/IP if they
wanted to sell equipment to the DOD. As a result, TCP/IP was implemented - at least on a limited
basis - on virtually every commercial computer system.
Outside the confines of the DOD, TCP/IP served as the network architecture for the Internet and for
most Unix systems. Unfortunately, during the late 1970s and into the 1980s, the Internet was not
widely known to the general computing population and Unix was not well regarded as a viable
commercial operating system. Consequently, TCP/IP remained a niche network architecture for
years.
Over time, however, TCP/IP has become the standard for "open" networking. How did TCP/IP get
from the dark back room to the brightly lit front office? This transition did not happen overnight - it
was the result of a series of developments.
First, in the mid-1980s, the Unix operating system came to be regarded as a viable commercial
operating system. As Unix became more popular, the TCP/IP services and protocols that allow Unix
systems to operate in a distributed, client/server computing environment came to light. The
commercial community found what the technical and educational community had known all along -
TCP/IP had matured into a broad, well-rounded network architecture that included a full complement
of interoperability services.
Corporations then found that they could implement basic interoperability services using core TCP/IP
services: telnet for terminal access, the File Transfer Protocol (FTP) for data movement; and the
Simple Mail Transfer Protocol (SMTP) for electronic mail. Gradually, additional TCP/IP services were
brought into play - for example, TN3270 for mainframe terminal access, Simple Network
Management Protocol (SNMP) for network management, Line Print Remote (LPR) for print sharing,
and Network File System (NFS) for file and directory sharing.
As TCP/IP continued to be successful, the number of TCP/IP services ported to non-Unix systems
continued to grow. The computer industry's fascination with TCP/IP peaked when the focus shifted
from the interoperability services (e.g., telnet, FTP, and SNMP) to the underlying TCP/IP protocols
(e.g., TCP, IP, and the User Datagram Protocol (UDP)). At this junction, networking professionals
realized that they could construct enterprise-wide networks using only TCP/IP - non-TCP/IP services
could be carried as encapsulated traffic.
The benefits of deploying TCP/IP as the single, underlying network protocol are very attractive:
• TCP/IP is a tried-and-true networking solution. One of the largest and most successful networks in
the world, the Internet, is a TCP/IP network.
• TCP/IP can operate over a wide range of network types, including Ethernet/802.3,
Token-Ring/802.5, FDDI, ATM, Frame Relay, X.25, as well as conventional dialed and leased
telephone lines.
• TCP/IP networks are economical to construct, expand, and maintain. The market for TCP/IP
software and hardware products is very competitive, which results in affordable prices.
• TCP/IP is easy to understand and is backed up by a wealth of written material and professional
consulting. TCP/IP has been around for more than 20 years and there are plenty of people who are
intimately familiar with it.
By the time the Internet became the industry's hottest topic, TCP/IP had become the de facto
standard for interoperability solutions. The fact that the Internet was a TCP/IP network further
emphasized the desirability of TCP/IP and generated demand for TCP/IP even in organizations
clinging to strict IBM SNA networking.
From the consumer's perspective, TCP/IP is the promised land of interoperability. From the computer
manufacturer's perspective, however, TCP/IP is a nightmare because it challenges the positioning of
proprietary equipment and proprietary network architectures. At first, many vendors tried to provide
a limited TCP/IP implementation - an implementation that includes enough features to be called
TCP/IP, but is limited in its usefulness as a true interoperability solution. For example, the AS/400
implementation of TCP/IP before OS/400 V2R3 was limited in several respects: It had a ceiling on
how many concurrent TCP/IP connections could be established, it had a ceiling on the size of files
that could be transferred, and it did not support network printing via TCP/IP.
Despite resistance from many computer manufacturers, the demand for full-scale TCP/IP
implementations - implementations that provide key TCP/IP interoperability services and support
TCP/IP as the sole underlying network protocol - continued to increase. This message was not lost on
either Microsoft or IBM; both companies responded by integrating TCP/IP into their network designs.
However, in their separate quests to provide TCP/IP support, the two companies came up with
different answers to one key question: Which TCP/IP services should be implemented? As you will
see, this question is the defining issue for comparing the Microsoft and IBM TCP/IP implementations.
TCP/IP Without UnixDeciding which TCP/IP services should be implemented is challenging because there are literally
hundreds of TCP/IP-related services available in most Unix environments. Porting all of them to a
non-Unix environment is impractical for a number of reasons (including the time to do it and the lack
of compatible languages), so the trick becomes picking the right services to port. These services fall
into two categories: (1) services that support end-user functions (e.g., telnet for terminal access, FTP
for file transfer, and SMTP for mail exchange), and (2) services that assist in the configuration and
management of a TCP/IP network (e.g., dynamic IP address assignment and IP name-to-address
translation).
Although the end-user services are important, they are oriented toward achieving interoperability in
a multivendor network. For example, you can invoke telnet to sign on to a foreign computer and use
FTP to transfer files to and from a different type of computer. The configuration and management
services, on the other hand, are important in all TCP/IP networks, because they provide services that
can greatly enhance the overall operation and maintenance of the network. Look at it this way: If
you are using TCP/IP in a Windows for Workgroups (WFW) network, you don't necessarily need FTP
to transfer information between systems (you just use shared directories) - but you do need some
mechanism for translating WFW system names into IP addresses.
The issue of configuration and management services is further complicated by the fact that a single
functional service may be implemented in several different ways. For example, IP names can be
translated into IP addresses via either a Domain Name Server (DNS) or a Network Information
Service (NIS) server. Similarly, the assignment of IP addresses to individual systems can be handled
via manual configuration or through dynamic assignment protocols such as bootp, the Reverse
Address Resolution Protocol (RARP), or the Dynamic Host Configuration Protocol (DHCP). The
duplication of services means that companies like Microsoft and IBM not only have to choose which
services to implement, but they also have to choose which style of service to support.
As noted, this area is where the Microsoft approach to TCP/IP networking and the IBM AS/400
approach to TCP/IP networking differ from one another. Specifically:
• The IBM AS/400 supports IP name-to-address resolution through a DNS. However, an AS/400
cannot act as a DNS system - it can only be a client.
• The Microsoft TCP/IP implementation also only supports IP name-to-address resolution as a DNS
client; however, third-party DNS server software is available for the Windows, Windows for
Workgroups, Windows 95, and Windows NT environments. For example, NetManage's Chameleon
suite of TCP/IP services for Windows, Windows 95, and Windows NT includes a DNS server
module.
• Microsoft also supports the Windows Internet Naming Service (WINS), which implements IP name-
to-address resolution for native Microsoft networking services (e.g., directory/file sharing, printer
sharing, and application access). Microsoft provides both client-side and server-side software for
WINS.
• The IBM AS/400 does not support any dynamic IP address protocol - IP addresses must be
manually configured in each AS/400. Using static IP addressing on both the AS/400 and the client
workstations increases the likelihood of configuration errors and related connection failures, plus
it makes change more costly.
• Microsoft supports the Dynamic Host Configuration Protocol (DHCP) as a means of dynamically
assigning IP addresses to systems in the network. Microsoft provides both client-side and server-
side software for DHCP.
All things considered, it is difficult to construct a reasonably sized TCP/IP network around the AS/400,
because the AS/400 lacks support for dynamic address assignment and cannot function as a name
server. Because the AS/400 does not provide these features, the responsibility for them must be
shifted to the desktop TCP/IP implementation, or other computers (for example, Windows NT
systems or Unix computers) must be deployed in the network to provide these functions.
The Microsoft TCP/IP implementation does not suffer from the same limitations the AS/400 TCP/IP
implementation does. Dynamic addressing is supported through DHCP, name serving is handled
through WINS or through third-party DNS software. You can, in fact, construct and support a large
TCP/IP network using the Microsoft architecture - no other systems are required.
The View From the ClientWhen you look at the connection between the desktop computer and the AS/400 in a TCP/IP
network, the focus shifts from low-level protocols and services to the emulation and client/server
services needed to connect your desktop computers to your AS/400. As mentioned in the
introduction, you can choose from three TCP/IP-based strategies for desktop-to-AS/400 connectivity:
• Run TCP/IP on the desktop and on the AS/400, and use native TCP/IP services such as TN5250,
FTP, and LPR to integrate the desktop with the AS/400.
• Run TCP/IP on the desktop and on the AS/400, and use IBM's AnyNet to tunnel SNA client/server
traffic through the TCP/IP network.
• Run TCP/IP on the desktop and native SNA on the AS/400, and use Microsoft's SNA Server to
provide end-to-end connectivity between the desktop and the AS/400.
As you will see, these three strategies are very different from one another.
Integration Using Native TCP/IP Services
With TCP/IP on both the desktop and on the AS/400, you can use native TCP/IP services to integrate
the two environments. The one issue you must grapple with under this approach is how to
implement workstation emulation via telnet. You can choose from three variations of telnet:
• Standard telnet - The telnet software packaged with most TCP/IP products emulates character-
mode terminals such as the Digital Equipment VT100. When character-mode telnet traffic reaches
the AS/400, the AS/400 must (1) receive and echo each character as it is typed on the client
keyboard, (2) convert the data stream into block-mode 5250 format, and (3) provide keyboard
mapping so the user can generate critical 5250 keys (e.g., Field Exit, CF01 through CF24). The
AS/400 is not particularly well-suited for this task and the result is an emulation environment that,
although technically functional, consumes CPU resources on the AS/400 and is extremely
awkward to use.
• TN3270 - Telnet 3270 (TN3270) was developed as an alternate telnet service for mainframes.
TN3270 provides keyboard emulation and block-mode service at the client level, freeing the
mainframe from those tedious translation functions. TN3270 can also be used to connect to the
AS/400, and it offers a better look-and-feel than standard telnet. However, the AS/400 must
translate the 3270 data stream into 5250 format and provide keyboard mapping between the
3270 and 5250 key sequences. As in the case of standard telnet, the conversion process
consumes additional CPU resources in the AS/400. Overall, TN3270 provides a functional interface
but the numeric field handling and keyboard interface are clumsy at best.
• TN5250 - Telnet 5250 (TN5250) is to the AS/400 what TN3270 is to the mainframe. TN5250
provides 5250 workstation emulation that supports virtually all the field attributes and keyboard
sequences of a "real" 5250 (the one significant feature missing in TN5250 is text assist). As a
result, the look-and-feel of TN5250 is natural and intuitive, and no conversion is required inside
the AS/400. TN5250 has advanced to the point where in most cases it is impossible for an end-
user to tell the difference between a TN5250 session and an SNA 5250 session.
Virtually all TCP/IP packages include a standard telnet client and many of them include TN3270 as
well. You can also find freeware and shareware versions of telnet and TN3270 on bulletin boards, on
FTP sites, and on a variety of CD software collections. TN5250, on the other hand, remains a
commercial product that is, for the most part, offered by companies providing client/server solutions
for the AS/400 (e.g., Attachmate, Wall Data, and WRQ).
Telnet, TN3270, and TN5250 provide workstation emulation only - they do not include file transfer or
printer emulation. Additional functionality is accommodated through the use of FTP and LPR/LPD
(Figure 1). FTP provides an interactive facility to transfer files between the AS/400 and the desktop.
Unfortunately, FTP is strictly a bulk-file transfer facility - it does not accommodate any record
selection criteria or perform any field-level conversions (although FTP can provide simple translation
between the ASCII and EBCDIC character codes). Because of these two limitations, you often end up
developing a program that extracts the data to be transferred into a separate file and converts it all
to printable characters before the FTP transfer can occur.
LPR/LPD are partner programs for printing. LPR is the initiating partner that routes output to the
receiving partner, LPD. The AS/400 supports both partner programs, and most PC-based TCP/IP
implementations include both programs. Under this architecture, you define an output queue on the
AS/400 as an LPR queue and associate that queue with a specific PC-based printer. The PC
sponsoring the printer must run LPD as a terminate-and-stay-resident program or as a Windows
background task to receive the print job and spool it out to the local printer. For desktop-to-AS/400
printing, the PC LPR function allows an AS/400 LPD queue to appear as a network printer. Output
from the PC is sent over the network to the AS/400 where it is routed to the correct printer by an
LPD job. Note that most LPR/LPD implementations (including the AS/400 implementation) do not
include any printer emulation - the print output generated by the originating application must be in
the appropriate format for the printer it will be delivered to.
All things considered, a desktop system running TN5250, FTP, and LPD/LPR provides a satisfactory
operating environment for basic workstation users. This environment does not, however, provide the
same range of client/server features offered by CA/400. For example, the native TCP/IP environment
does not support shared folder access, printer emulation, flexible data transfers, data queue access,
text assist, ODBC/DRDA, or any of the programming APIs associated with CA/400.
An all-TCP/IP environment also comes up short in the area of configuration and management. In
particular, TCP/IP client connections do not enjoy the same ease of configuration that SNA clients do.
Devices and controller descriptions are not generated for each individual client system; instead, all
clients share a common TCP/IP controller definition. If an AS/400 needs to establish contact with a
specific client system, it must rely on a local IP address table or on a DNS server.
One final consideration that must go into the decision to deploy native TCP/IP for desktop-to-AS/400
integration is the release level of OS/400. Although TCP/IP has been available for OS/400 since V1R2,
its features and performance are not consistent across all versions and releases.
• For releases earlier than V3R1, TCP/IP is a separately priced, licensed program product. TCP/IP is
included in V3R1.
• Before V3R1, TCP/IP ran at the application program level and suffered from performance
limitations. TCP/IP was integrated into OS/400 with release V3R1 and has no artificial performance
limitations.
• LPR/LPD was not introduced until V2R3.
The bottom line is that implementing the full set of desktop-to-AS/400 TCP/IP features requires V2R3
or better, and getting the best performance requires V3R1 or better.
IBM's AnyNet
Using IBM's AnyNet strategy for desktop-to-AS/400 integration bypasses some of the limitations
imposed by the native TCP/IP strategy because AnyNet allows you to run standard client/server
software over the TCP/IP network. For example, you can run CA/400 over TCP/IP and retain all the
CA/400 features, including workstation emulation, printer emulation, shared folders, data transfers,
data queue access, APIs, and so forth. In theory, every desktop-to-AS/400 operation that can be
performed over an SNA network can be performed over a TCP/IP network using AnyNet.
The translation of SNA traffic into TCP/IP format occurs below the level of the end-user application or
server (Figure 2). In the case of CA/400, this translation is provided by the router program before it
releases the traffic into the network. In the AS/400, the translation between TCP/IP and SNA formats
occurs before the information is handed off to the appropriate service routines (e.g., shared folders
handling, data queue access). Because the translation between TCP/IP and SNA occurs at the
network level, the applications or services on each end of the link are shielded from the fact that the
information was routed through a TCP/IP network - they see the traffic as standard SNA traffic.
The translation and encapsulation process used in AnyNet was derived from Data Link Switching
(DLSw), a technique used by routers to move SNA traffic through a TCP/IP network. Unlike DLSw,
AnyNet does not require external routers or connectivity equipment - all the translation between
SNA and TCP/IP occurs within the AS/400 or within the client systems. Also unlike DLSw, AnyNet
does not require that clients use the Data Link Control (DLC) protocol for LAN-level access; instead,
clients simply use TCP/IP.
The encapsulation process used by AnyNet is relatively efficient. Fields are, in fact, moved out of the
APPC headers and into the TCP/IP headers to reduce the payload. Unfortunately, the payoff for this
reduction is virtually negligible because the TCP/IP headers are much larger than APPC headers in
the first place.
The significant advantage of AnyNet over direct TCP/IP is that it allows normal, APPC-based
client/server traffic to flow over a TCP/IP network. This advantage does not, however, come without
constraints. In particular, the following limitations are currently associated with AnyNet:
• AnyNet is only available in OS/400 V3R1 or better.
• Client/server products must explicitly support AnyNet; you can't just use any garden-variety
client/server software. For example, in IBM's Client Access family of products, AnyNet is only
supported by CA/400 for Windows.
• The AnyNet clients available today only run on Windows 16-bit client platforms, not the more
powerful Windows 95 or Windows NT Workstation platforms.
• Client/server connections using AnyNet are not automatically configured as they are in an SNA
network. Individual client system addresses must be manually configured in the AS/400 or a
TCP/IP DNS server must be deployed. This is the same limitation you encounter in an all-TCP/IP
network.
• The translation between TCP/IP and SNA formats consumes extra processing resources in both
client systems and in the AS/400. Informal field tests have shown that a client/server AnyNet
connection operates more slowly than an SNA client/server connection.
As it stands today, AnyNet is well suited for sites with AS/400 CPU capacity to spare, OS/400 V3R1, a
TCP/IP network with DNS services, and the budget to upgrade to CA/400 for Windows (or an AnyNet-
compliant third-party product). Sites that do not meet these qualifications may find the entry
barriers to AnyNet too high.
TCP/IP-SNA Gateway
See full-sized image.
The third strategy for desktop-to-AS/400 integration in a TCP/IP network is to deploy a gateway, such
as the Microsoft SNA Server (Figure 3). SNA Server allows the client side of the network to function
in a TCP/IP environment while allowing the AS/400 to function in a native SNA environment. As in the
case of AnyNet, the client-side applications and services are isolated from the network - they
function as if they were operating over an SNA network.
Microsoft's SNA Server is a software product that runs on a Windows NT Server system. SNA Server
can operate on Intel, Alpha, MIPS, and PowerPC platforms, thus providing a wide range of
price/performance options. A dedicated system is not required; the same Windows NT Server system
can also be used for file sharing, for printer sharing, mail, database, Internet web, as a DHCP server,
as a WINS server, and even as a DNS server (via third-party software). Multiple SNA Servers can be
deployed for load balancing and redundancy.
SNA Server provides a gateway between the client TCP/IP network and the AS/400 APPN/APPC
network. The client network is usually serviced by the SNA Server through a Token-Ring or Ethernet
LAN connection. The connection to the AS/400 network can be over the same LAN connection or
through separate attachments. A variety of AS/400 attachment methods are supported, including
LAN (Ethernet/Token-Ring), SDLC, X.25, and twinaxial.
Client/server traffic is routed from the client to the SNA Server by a software module running on the
client. This module is normally installed as a replacement for the CA/400 (or equivalent) router
program. The SNA Server includes client modules for a variety of client environments, including MS-
DOS, Windows, Windows for Workgroups, Windows 95, OS/2, Macintosh, and Windows NT
workstation. No changes are required to the client/server applications or services because the
Microsoft router provides the end-to-end connection with the AS/400 in a manner that is transparent
to the client applications.
The Microsoft router is also responsible for translating the SNA traffic into TCP/IP format. Once the
traffic reaches the SNA Server, it is translated back into SNA format and passed to the AS/400
network as normal routed traffic. No additional processing is required on the AS/400 to handle the
traffic.
The SNA Server strategy is a comprehensive, enterprise-oriented solution that offers many
advantages. In particular, SNA Server
• Works with any version of OS/400, providing consistent support for all AS/400s in your
environment. This feature allows you to upgrade to V3R1 as you see fit.
• Is supported by all major AS/400 client vendors, including Andrew, Attachmate, Eicon, IBM
NetSoft, Wall Data, and WRQ. In contrast, only a subset of these vendors provide support for
TN5250 or AnyNet.
• Supports concurrent connections to AS/400, System/38, System/36, and mainframe systems by
functioning as a PU 2.1 APPN LEN node.
• Works with MS-DOS, Windows, Windows for Workgroups, Windows 95, OS/2, Macintosh, and
Windows NT client platforms, supporting up to 2,000 concurrent clients and 10,000 concurrent
sessions.
• Accommodates other types of client networks. The SNA Server can concurrently support client
connections to the AS/400 using TCP/IP, IPX/SPX, Banyan VINES IP, NetBEUI, and AppleTalk
protocols.
• Accommodates dial-up PCs via the Windows NT Server's Remote Access Service (RAS) feature,
which supports remote Windows, Windows for Workgroups, Windows 95, Macintosh, and Windows
NT clients.
• Isolates the AS/400 from the TCP/IP network. If you don't run TCP/IP on the AS/400, you are not
exposed to the security considerations that accompany TCP/IP. Even better, the SNA Server
provides an additional layer of C2 certified security that prevents unauthorized host access from
your client environment.
• Supports both local and remote AS/400 attachments. One or more SNA Servers can provide links
to local, LAN-based AS/400s; to remote AS/400s; or to both. Support for local and remote
connections give you flexibility in how and where you deploy SNA Servers. Supported AS/400
connections include twinaxial, Ethernet/802.3, Token-Ring/802.5, SDLC, and X.25.
• Can be interlinked with other SNA Servers. You can place SNA Servers at remote branches and
feed the remote traffic into one or more centralized SNA Servers. The link between the remote
and central SNA Servers can use TCP/IP, thus simplifying the construction of a wide area network.
• Can cooperate with other SNA Servers in the network. Up to 15 SNA Servers can work together to
provide extra capacity, load balancing, and hot backup.
• Provides a graphical interface to monitor and manage client/server connections. The monitor
function can be run locally or from any Windows NT Workstation or Windows NT Server system on
the network or connected via a RAS link.
• Leverages the management tools available in the Windows NT Server environment, including the
Performance Monitor, the Event Viewer, and the User Manager.
• Gives you access to the Windows NT Server DHCP and WINS capabilities for dynamic IP address
allocation and name resolution. This feature obviates the need to manually manage IP address
tables, as in the case of the all-TCP/IP and AnyNet environments.
• Coexists with other Windows NT Server software. You can use the same server for file serving,
print serving, DHCP, WINS, and DNS (with third-party software), mail, database, and systems
management.
• Provides open APIs. A number of connectivity vendors have utilized these APIs to create custom,
SNA Server-based LAN-to-host applications for file transfer, printing, and database access.
• Reduces the AS/400 communications overhead associated with client connections. An AS/400
must continually poll each client controller in a direct SNA or AnyNet environment. This activity
consumes AS/400 memory and processor resources. In contrast, the SNA Server reduces the
number of controller definitions required and the AS/400 only needs to poll each SNA Server.
• Is designed to be scalable for large and small organizations. An SNA Server can take advantage of
the newest hardware platforms for best possible performance, including the Intel Pentium, MIPS,
Alpha AXP, and PowerPC platforms. The SNA Server is also designed to take advantage of multiple
processor configurations, which can dramatically improve performance in cases of high load or
heavy traffic.
As you can see, an SNA Server is powerful, flexible, and scalable, but it is not self-contained. To
deploy an SNA Server, you must first purchase, configure, and install a Windows NT Server. Given all
the capabilities that a Windows NT Server brings to the table, you can often justify the installation of
an SNA Server on the basis of bringing leading-edge technology into your enterprise network.
The Choice Is YoursIn the long run, the strategy (or strategies) you choose must make sense in the context of your
network and organization. If you have a limited number of desktop PCs that need to be integrated
into a TCP/IP network and you are running OS/400 V3R1, then both the all-TCP/IP and AnyNet
solutions are viable options. In this environment, an all-TCP/IP solution can provide a fundamental
level of connectivity (TN5250, FTP, and LPR/LPD) without a great deal of complexity. In contrast, an
AnyNet solution in this environment brings a broader range of features to the desktop, but it also is
more complex and it consumes more resources on your AS/400 and more bandwidth on your LAN.
Neither the all-TCP/IP nor the AnyNet solutions are particularly well-suited for large or complex
TCP/IP networks. In particular, the AS/400's inability to participate in dynamic address assignment or
act as a name server dramatically limits the role it can serve in any reasonably sophisticated
network. Additionally, client software is not widely available - either for TN5250 or AnyNet. Another
critical limitation of both the all-TCP/IP and AnyNet solutions is support for OS/400 versions before
V3R1 - AnyNet simply doesn't support previous versions of OS/400, and an all-TCP/IP solution does
not perform well on earlier versions.
In contrast, the SNA Server solution works well in all-TCP/IP networks, regardless of size or
complexity, it works with a variety of OS/400 versions, and it supports a broad range of client
environments. By leveraging the features of the Windows NT Server product alongside the features
of SNA Server, you can create a TCP/IP environment that provides fast and efficient
desktop-to-AS/400 access, and also simplifies the configuration and management of desktop
systems through services such as DHCP, WINS, and DNS. The combined strengths of Windows NT
Server and SNA Server in a TCP/IP network clearly outweigh the AS/400's capabilities to function in a
TCP/IP network.
See full-sized image.
The SNA Server can also address problems outside the realm of TCP/IP. By using the Windows NT
Server RAS function, you can accommodate remote access from a variety of clients without
requiring complicated "remote control" software or dedicated gateways. Furthermore, SNA Server
can provide concurrent support for clients locked into using the IPX/SPX or NetBIOS/NetBEUI protocol
suites. In short, the SNA Server is a multipurpose tool that can be used to solve a broad array of
connectivity, configuration, and management problems (Figure 4).
Ultimately, the choice is yours to make - there is no one "right way" to implement a TCP/IP
client/server network. The good news is that you have three viable options to choose from - you are
not locked into any single vendor's vision of your network. In the world of interoperability, having
choices represents real progress.