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.