Installing Internet Support in OS/2 Warp

By Howard Gilbert

Connection to the Internet is one of the most important features of IBM's OS/2 3.0 Warp operating system. IBM has been refining its OS/2 Internet support for five years, and the current generation of programs show the sophistication and polish that comes from iterative refinement.

Warp will be a family of operating systems. The first version (lets call it Personal Warp) provides Internet support for dial-up modem connections using the SLIP or PPP protocols. Sometime in early 1995, IBM is expected to provide the LAN Client version of Warp with Ethernet and Token Ring drivers for connection to the Internet, to IBM LAN Servers and NT Servers, and to Novell Netware. For those who cannot wait, it is possible to install the OS/2 LAN Requestor diskettes from the current IBM LAN Server 4.0 product to get immediate LAN access. However, the Internet support provided with Warp is slightly advanced over the version supplied with the LAN Server package, so there is a small amount of effort involved to integrate the two.

Personal Warp includes all the subroutines and protocol support needed to run any TCP/IP application written for Windows or for a previous version of OS/2 over a phone line. Once the LAN drivers are added, Warp will provide full support to client or server applications. It ships with updated versions of the most important modern client programs. Additional applications and server programs are available in the full TCP/IP for OS/2 product group, but they will not be required by most users. OS/2 Warp Article Contents:

Realistic Prerequisites
The claim that either Warp or Chicago will run on a machine with only 4 megabytes of RAM is questionable. In both cases it is possible to load the basic operating system and run simple applications. However, additional memory is needed if Warp is to run Windows applications, multimedia, HPFS, or the Internet Connection package.

To get the full benefit from Warp, a machine should have 8 megabytes of memory. If you intend to simultaneously download files from the network, play music, and edit a large document with Word 6, then a 12 megabyte machine might be recommended. The same is true of Windows 95 (Chicago), so this is a statement about the direction of technology and not about any particular system.

First Clean Your Windows
A common problem that users have after installing Warp is some confusion trying to run WINSOCK applications. WINSOCK is a DLL routine, and the standard Windows processing, which Warp doesn't change, is to search for any DLL first in the \WINDOWS directory, then in the \WINDOWS\SYSTEM subdirectory, and then in the DOS path.

Now we encounter a fundamental difference between Microsoft and IBM. Microsoft, following the lead of Steve Jobs and the Macintosh, assumes that a PC must be a simple system that takes care of all the configuration details automatically. In concrete terms, Microsoft installs all its system support code into the WINDOWS and WINDOWS\SYSTEM directory and encourages all other vendors to do much the same. This works wonderfully well as long as there is only one copy of anything, or at least that two modules with the same name do the same thing and you only need the one with the latest date.

IBM, on the other hand, realizes that as the PC grows toward 16 megabytes of RAM and a Gigabyte of disk, real systems will never be all that simple. The OS/2 practice is to install each component it its own directory. Multimedia support goes in MMOS2, basic LAN support in IBMCOM, the file server client goes in IBMLAN, and Internet support goes in TCPIP. As each new component is added to the system, its directory is added to the PATH (to find EXE modules) and to the LIBPATH (to find DLL modules). This approach increases the complexity of simple systems, but it provides the control needed for more sophisticated configurations.

When Warp is installed, a vanilla installation will produce an OS/2 PATH (from CONFIG.SYS) that looks like:

D:\OS2;D:\OS2\SYSTEM;D:\OS2\INSTALL;D:\;D:\OS2\MDOS;D:\OS2\APPS;C:\WINDOWS ;D:\MMOS2;D:\VIEWER\BIN;D:\TCPIP\BIN;D:\TCPIP\UMAIL;

and a DOS PATH (from AUTOEXEC.BAT) that looks like:

PATH=D:\OS2;D:\OS2\MDOS;D:\;C:\WINDOWS;D:\TCPIP\DOS\BIN;

Of course, the disk letters may vary, but the important matter here is that C:\WINDOWS occurs first in both the OS/2 and DOS paths, and in any event, WINDOWS will always search its own directory first. Since the WINSOCK.DLL that OS/2 supplies, which is needed for Windows programs to run under OS/2, is installed in the \TCPIP\DOS\BIN directory, it will not be found if a Microsoft or other WINSOCK.DLL is installed in \WINDOWS. Worse, any commonly used TCP/IP utility installed in the Windows directory will be found before the corresponding OS/2 utility in \TCPIP\BIN.

Although this can be cleaned up later on, it may be a good practice to address the problem before installing Warp. Check the \WINDOWS directory for the following files:

WINSOCK.DLL, PING.EXE, ROUTE.EXE, IFCONFIG.EXE

If they are found, move them to a separate directory and add them to the Plain Old DOS PATH in AUTOEXEC.BAT. Reboot and verify that the old WINDOWS Internet programs still function correctly.

Installing Warp
This is not the place for a full discussion of the Warp installation process. IBM has done a lot of work so that Warp will install automatically on most mainstream computers. However, there are many obscure hardware vendors who sold equipment that just barely works on Plain Old DOS, and there are a number of new cards that appear initially with only Plain Old Windows drivers. The manual that comes with OS/2 is fairly comprehensive here and does not need to be restated.

The "Easy Install" process will install Warp on the C: drive and establish a Dual Boot configuration. DOS system files are moved to the C:\OS2\SYSTEM directory. The BOOT.COM program switches the DOS and OS/2 system files and selects which operating system boots. Before starting, make sure that there is enough space (~50 megs, plus 10 more for multimedia) on the C: drive to hold all the files.

The "Advanced Install" will install OS/2 on any disk letter, provided that it is possible to install the Boot Manager in its own one megabyte partition on the first hard disk. If there is no room for Boot Manager, it will probably be easier to move some files around and install on the C drive.

Warp will detect the presence of most Sound Blaster or Media Vision sound cards. During the installation of the Warp operating system, it will also install the multimedia drivers in the MMOS2 directory.

If Warp is installed on a typical DOS/Windows system, all of the disks will be formatted with the "FAT" file system. OS/2 has another file system, called "HPFS" that provides long file names and better performance on larger systems. However, HPFS requires a large amount of memory and is not a good choice on typical desktop configurations. A user with 8 megabytes of RAM who intends to run Warp with Internet or Multimedia support should use only FAT volumes and should remove or comment out the first line of CONFIG.SYS:

REM IFS=D:\OS2\HPFS.IFS /CACHE:64 /CRECL:4

This will free up memory and can make a big difference in performance.

Some clever options can also take up large amounts of memory. Although it may look nice to have a picture as the background of the display, an image has to be loaded into memory. At high resolution (1024x768) the image will occupy 768K of memory. Someone in a memory constrained environment should avoid "cute" options.

Installing the Bonus Pak
The Bonus Pak is distributed as either a directory on CDROM or a whole bunch of diskettes. There are many programs in the Pak, but the four that will be discussed here are the Multimedia Viewer, the Internet Connection for OS/2, Person to Person, and Works.

The Multimedia Viewer provides additional programs and file formats to extend the base multimedia support installed with Warp. The component of the operating system that provides the ability to play multimedia files is called MMPM and it is installed in the \MMOS2 directory. In OS/2 2.0 it was a separate program item. In OS/2 2.1 it was distributed with the OS/2 system but was installed separately. In Warp, MMPM is installed automatically when the system detects a sound card during the installation of the basic operating system.

The Multimedia Viewer include components of a previous product called Ultimedia Workplace. It was originally targeted to the developers of multimedia projects. However, the ability to more easily handle images and sound files now extends to the ordinary user community. In particular, Gopher and the Web Browser make it easy to transfer a photograph from the Smithsonian or an image of artwork at the Louvre. Multimedia Viewer is supposed to provide an easy way to organize these images.

The Bonus Pak program calls a utility named MINSTALL to install the Viewer software. MINSTALL is part of the MMPM support and is responsible for installing and updating all software related to multimedia support. For example, Multimedia Viewer includes support for the .AU sound file format commonly used on the Internet to store sound files. Although this support is packaged with Viewer, it actually goes into the MMOS2 directory and extends the capability of all the existing multimedia utilities and program interfaces. Other files are installed in the \VIEWER directory.

Multimedia files are too large to be comfortably fetched using a SLIP connection through an ordinary modem. It may be better to wait until the LAN Client version of Warp is distributed. The Multimedia Viewer is also appallingly buggy and may not be very useful until IBM releases the first set of fixes.

The Internet Connection for OS/2 is the package of Warp support for client access to Internet resources. It contains five general types of components:


 * 1) Client programs for commonly used Internet protocols: Gopher, Web Explorer, FTP, Telnet (terminal logon to mainframe and minicomputer hosts), and E-Mail.
 * 2) The DLL libraries to provide access to the TCP/IP protocol by application programs written for OS/2 or Windows.
 * 3) The low level drivers loaded by CONFIG.SYS to provide TCP/IP protocol support as an extension of the OS/2 operating system.
 * 4) SLIP support and the utilities to configure phone numbers and manage logon scripts.
 * 5) Higher level tools to establish an account with the IBM network service and update software through the network.

The Internet Connection package is obviously the most important part of the Bonus Pak, but its installation has no important options. The user is asked to select a target disk letter, then the files are copied into the \TCPIP directory and its subdirectories. The hard part will be the configuration that comes later.

Person to Person (P2P) isn't part of the standard set of Internet programs. It is an rather nice IBM package for workgroup communication that happens to work over the Internet. A group of users in different locations establish a network connection. P2P supplies a shared "whiteboard" on which they can exchange text, graphics, or other files. P2P does not provide voice communication, since this is easily arranged through a telephone conference call. It does allow the exchange of other forms of information.

Works is a grab-bag of simple applications: a word processor, spreadsheet, address book, and date book. These applications are integrated with the Workplace Shell, and WPS is always running. Several people have reported that performance on memory challenged machines was greatly improved by removing Works. Some have suggested that the system was more stable without these applications. At this point, the best advice appears to be to avoid installing Works if its functions are not needed.

Understanding Warp Configuration
OS/2 Internet software is installed under the \TCPIP directory. Programs and CMD files go in the \TCPIP\BIN directory, and configuration files go in the \TCPIP\ETC directory.

The name "etc" and the format of most of the files stored in this directory is a convention carried over from Unix. The information has to be stored somewhere, and Unix has established the standard for Internet software. During the early stages of development, Unix systems provided the router and gateway components from which the Internet was constructed. The legacy of those days are configuration files that are much more complicated than necessary. Today, most systems provide a simple front-end that allows the workstation user to enter a few important values that are used to populate all the configuration files.

Before Warp, all Internet software assumed a LAN connection. If a system used a modem instead, it was assumed that the modem connected to a device that provided a gateway to a corporate or campus LAN. The system was therefore configured with the machines, addresses, and services of the "home" network. Warp is the first Internet package specifically designed to be used by an ordinary consumer who has established a personal account with one or more network service providers. This presents an entirely new configuration problem.

Each network has its own set of addresses. Each has its own name server, news server, mail server, and so on. If a consumer has more than one account in more than one network provider, then the configuration of all these items has to change when the user dials a different phone number.

The applications are effected as well. Network News ties together the news servers of all organizations. When an item is posed to a news group, it eventually propagates to all news servers. However, each server maintains its own database and assigns each incoming item a local identifier. A program that displays news items keeps a record of the items that have already been seen, so that they will not be redisplayed the next time the program is run. However, the list of subscribed groups and viewed items uses identifiers that apply only to a specific news server. Switch to a different news server in a different network and the items have all been renumbered, so the list of previously viewed items becomes meaningless.

The News Reader V1.07 update (available through the Retrieve Software Updates panel previously discussed) now maintains a separate set of configuration and history files for every network to which the user may connect. This can be very useful in today's two income households. He can dial into his network to read his news, and she can dial her network to read her news.

Most of the time, configuration can be accomplished using the public front end. Occasionally it is useful to understand the lower level configuration files to debug problems or handle special cases. Four topics need to be considered


 * 1) A general understanding of SLIP/PPP and the ways in which it can be configured
 * 2) An examination of the SLIPPM utilities and connection scripts supplied with Warp
 * 3) A discussion of the layers of TCP/IP support in OS/2
 * 4) The structure of LAN support and its connection to higher level TCP/IP layers.

SLIP and PPP
The Internet developed from research sponsored by the Department of Defense. To allow computers from many different vendors running many different operating systems, the Internet provides clear standards when individual machines connect to Ethernet or another LAN. Each corporate or campus LAN is then connected to the larger network over high-speed long distance phone lines. What may be surprising is that the phone connections have not been standardized.

Instead, if a company decides to connect to the Internet, it has traditionally contracted with a Regional network to provide the connection. The Regional network establishes a phone line to the company, and places a router box at the company location. The router connects to the company LAN, as do all the local computers. Since the Regional network buys all its router boxes from the same company, it really doesn't care how the routers communicate over the phone line. When two Regional networks need to connect, they each put a router box in the same room and run a LAN between them.

Internet routing has been dominated by devices produced by the Cisco company. Most companies, universities, and networks use Cisco devices as routers. Thus much of the long distance Internet communication uses whatever protocol Cisco decided to build into their hardware. This is not really a bad thing. The process of drafting any official standard takes years, while technology is constantly changing. Too often, by the time a standard is officially published it has already become obsolete. A private company is more agile and adapts more quickly.

When it became possible to run Unix on personal workstations, a need developed to connect remote systems to a central LAN over ordinary low cost modems and standard phone lines. A simple protocol was proposed called Serial Line/IP (SLIP). SLIP was never intended to be a "standard", just a temporary quick and dirty solution that was easy to code and would suffice until something better came along.

Unfortunately, when the Internet community decided to do something better, they defined the problem very broadly. First, they wanted a standard that would work on high speed long distance leased phone lines to replace the vendor proprietary protocols supplied by Cisco. A version of the same standard would then be used on inexpensive asynchronous serial modems used by Personal Computers. They also wanted a protocol that would support not only the TCP/IP protocol used by the Internet, but also Appletalk, DECNet, Novell IPX, and everything else.

The Point-to-Point Protocol (PPP) has been developing over a period of many years. Standards are drafted and discussed by a committee of the group that manages the Internet, but there is broad participation by computer, software, and network vendors. While SLIP only provides a method of exchanging data, PPP allows the two ends of the connection to negotiate or adjust buffer sizes, data compression options, addresses, and other housekeeping. PPP even provides for the automatic exchange of Userid and Password information.

To the Warp user, PPP may provide a slightly simpler method of connection. More of the configuration information is provided automatically. Less has to be configured or extracted during a logon script. If the central site supports all the options, the user may only have to configure the phone number and everything else can be handled automatically. This is the way that Microsoft uses PPP in Windows 95 (Chicago) and Windows NT.

However, IBM currently supports PPP only as an alternative to SLIP for Internet access. IBM doesn't have a PPP server, and it doesn't support the use of PPP with other LAN protocols (Communications Manager, LAN Server, or Novell Requestor). This eliminates most of the advantages that PPP would normally have. In Warp, the difference between SLIP and PPP is more a matter of taste than technology.

The TCP/IP protocol manages the Internet. As the name suggests, the Internet is a network of networks. If you configure SLIP or PPP "honestly", then each phone line is supposed to look like a link between your "network" at home and the network at the other end of the phone. Of course, most PC users don't want to configure and administer a "network" consisting of one machine.

So most implementations of SLIP or PPP are configured somewhat dishonestly. Each remote machine is given a set of parameters that make sense, but the central network "cheats" to make the overall configuration simpler.



Remote users dial into modems connected to a Communications Controller. The Controller is then connected to a LAN by an adapter card (represented by a red circle). Elsewhere on the LAN a Gateway Router connects this LAN to the rest of the corporation or campus and eventually to the Internet and the rest of the world.

Assume there are 32 dial in modems connected to the Controller. If you configure SLIP honestly, every SLIP line is a connection to a remote network. The Gateway would then have to be programmed to regard the Controller as a device that provides an interface to the 32 different remote networks. Each remote user has to configure one of these networks. The result is a mess.

There are two reasonable lies that the Controller can tell. The most outrageous lie is that it can claim all 32 remote users are actually connected directly to the LAN. The Gateway tries to send messages directly on the LAN to each of the 32 separate workstations, but the Controller catches all these messages and sends them out the phone line. In this situation, the Controller makes itself invisible to the Gateway.

In a more modest lie, the Controller can act as if all 32 remote users are on a single separate LAN and that it provides a path between this imaginary LAN and the real LAN. In this case the Controller is visible and must have an IP address. The Gateway sends messages for any of the 32 remote users to the Controller's one address for forwarding, and the remote users send messages to the Gateway over their individual phone connection. At first, this seems to be very close to reality. The underhanded part is that the Controller is probably using the same IP address on all the connections. An "honest" TCP/IP implementation would require the Controller to have a different IP address for the LAN and for each phone line. However, since nobody is really looking, the Controller can cheat and get away with it.

Suppose that the Gateway has address 130.132.57.1. Suppose that the first dial in modem line is associated with address 130.132.57.32, and the second with .33, and so on. For the rest of this example, "*" will replace the "130.132.57" part of the address.

If the controller is invisible, then the first SLIP line will be declared to be a connection between remote address *.33 and the Gateway at *.1. The SLIP user will send all messages to the Gateway. The Gateway will believe that these machines are on the LAN. The Controller will forward messages between the remote user and the Gateway transparently.

If the Controller chooses to be visible, then it will probably have the address *.31. The first SLIP/PPP line will be treated as a connection between *.31 and *.32. The second line will be a connection between *.31 and *.33. The LAN connects the Gateway at *.1 to the Controller at *.31. In this view, the Gateway sends all traffic for any of the remote users to the Controller at *.31 so that it can be forwarded. The remote users send all traffic for everyone to the Gateway at *.31 so it can be forwarded. The same *.31 address gets used over and over again, but since the Gateway and remote users have need for a global view of network architecture, the trick is never discovered.

If the user selects the PPP protocol, the Controller configures the remote user directly. SLIP, however, has no low level housekeeping messages. The remote computer initially connects to the Controller box as a terminal. The Controller writes the configuration information in messages send to the "terminal screen." The user supplies a script to provide Userid and Password and to extract address information.

If the Controller chooses to be visible, then during the initial connection it will send out a message of the form:

Your IP address is 130.132.57.34. My IP address is 130.132.57.31.

The script anticipates this message and captures both address values. It plugs the *.34 address in as the value assigned to the remote PC, and the *.31 address is treated as a "gateway" value. If the controller chooses to be invisible, it will simply send out

Your IP address is 130.132.57.34.

The user will not be told about the *.1 gateway. The user has to know this address already. Generally, it will have been supplied by the central network administrator.

An invisible gateway would pose a minor routing problem if two remote SLIP users want to talk to each other. Since each believes that the Gateway is the route to all other machines, they would initially send it the message. However, from the Gateway point of view two machine on the same Ethernet should be able to talk directly to each other and do not need assistance. The Gateway then sends back a mild rebuke to each system to address traffic directly to each other. This is a minor issue, and in any event, remote SLIP users are not servers and are therefore unlikely to talk to each other directly.

Defining a "Provider"
For the PC to access the Internet over SLIP or PPP, it must first


 * 1) Initialize the COM port to the correct speed and settings (no parity, eight bits per character, hardware pacing).
 * 2) Initialize the modem to the correct settings
 * 3) Dial the phone number and wait for a connection

In a small number of cases, the communications controller will be configured to use only PPP protocol and to exchange Userid, Password, and configuration information automatically. In this case, nothing further is required. Otherwise, there are several possible sequences:


 * The communications controller may prompt for a Userid and Password, then present a command prompt to which the correct reply is "SLIP" or "PPP".
 * The communications controller may present a command prompt, and if the user enters "SLIP" or "PPP" then the controller may prompt for Userid and Password.

The PC may then have to scan the remaining messages from the controller to extract IP addresses.

In addition, the user may have to supply information provided by the network administrator, including a subnet mask and gateway address. It is also important to define a name server, news server, mail server, and other important service machines.

To supply this information in a way that allows several different people to dial the same network from the same machine, or to allow one person to dial any of several different networks, Warp supplies the "Dial Other Internet Providers" program (actually a module named SLIPPM.EXE).



The main panel of SLIPPM provides lots of useful information. In the middle there is provision for a list of "phonebook entries" for different networks. Two are listed here, Yale and Another. A new line is added by clicking the Add Entry icon and filling in information. Select and entry and click the phone icon to dial the phone. Messages during the initial connection appear in the scrollable box at the bottom. While connected, the window shows the elapsed time of the current connection, and the total time online since the counter was last reset. This allows a user to control cost when the network provider charges by connect time. There is even a nice little box to click when dialing out requires a "9" prefix from the current phone. Clicking the Add or Modify icons brings up a notebook of configuration settings for one of the providers.



The first page of the notebook provides the essential information for this provider. It is given a name "Yale", a phone number, and a Userid and Password is supplied. The user selects either the SLIP or PPP protocol. There is an inactivity timer that will hang up the phone if no data has been transferred for a number of minutes. This eliminates the threat of racking up connect time charges with a commercial Internet vendor if you are unexpectedly called away from your computer.

The Login Sequence in the middle is the most important and most complicated field in the configuration. Note that there is Help for the configuration, so if you have trouble filling out this field, hit F1 or the Help button for more details.

In a few cases, someone will dial a phone number which is dedicated to PPP access. Since most of the configuration can be handled automatically, it may not be necessary to use a Login Sequence.

In other cases, a user will dial a phone that is often busy. The user will want the system to wait a few minutes, then retry the number until it answers. To provide this level of support, one must supply a REXX program to control the line.

Most users will confront a Communications Controller that will prompt in some order for Userid, Password, and the SLIP or PPP command. It will then supply address information. The exact sequence varies from vendor to vendor. For example, some controllers ask for "Username", some for "Userid", and some use other words for the same thing.

The Login Sequence shown above provides an example of the most common sequence. The user supplies a set of lines that alternate between output expected from the Communications Control and input that should be supplied by the PC. Special variables are defined in as "[VARIABLE]". IBM provides one example for the ANNEX (visible) communications controller.

\r sername: [LOGINID] ssword: [PASSWORD] annex: slip address\sis\s[$IPDEST]\sYour\saddress\sis\[$IPADDR]

The first line is sent from the PC to the Communications Controller after the modem has connected. The special value "\r" asks for the PC to send a Carriage Return. The Controller prompts for "Username" or "username". The script leaves off the first letter and therefore doesn't care if it is capitalized or not. The script now responds with the string configured in the "LOGIN ID" field in the configuration panel. The Controller then prompts for password and the PC supplies the value typed into the password field. The Controller then generates a command prompt ending in "annex:". The PC responds with the command "slip". The Controller types out a line of the form:

Annex address is 130.132.57.20. Your address is 130.132.57.27.

The last line of the script matches this output. The special sequence "\s" matches one or more blanks. The first address "130.132.57.20" is stored as variable $IPDEST which becomes the address that the PC will use for the Gateway. The second address "130.132.57.27" is stored as $IPADDR and becomes the IP address that the PC will assign itself.

Now consider another script used to connect to a Cisco Controller:

[LOGINID] word: [PASSWORD] &gt SLIP IP\saddress\sis\s[$IPADDR]

This particular system doesn't require a starting Carriage return from the remote user, but the IBM script requires the PC to speak first. The Cisco allows the user to typeahead, and will take whatever is sent in as the answer to the first question, so this script sends the userid initially in response to a question that has not yet been asked and then waits for the second prompt for "Password:". Note also that the Cisco controller is one of the "invisible" type and only sends out the address that the PC should adopt. The user needs to obtain information about the Gateway address from the network administrator and enter it in the supplied field of the next panel.

In either of these examples, the "SLIP" command can be replaced by "PPP" and the Connection Type button on the configuration panel can be switched to PPP. Once PPP is selected, the last line of the script is not needed, because PPP will obtain the address information at the protocol level. However, the line can be left in if the user expects to switch between SLIP and PPP frequently.



The second page of the configuration notebook allows the user to enter basic network information. These values would be supplied by the network administrator of the network into which you are dialing.

The field Your IP Address can be filled in when a user dials a dedicated phone number and is always assigned the same address each time a connection is made. The Destination IP Address is filled in with the address of the Gateway ("invisible" controller) or of the Communications Controller ("visible" controller). The Netmask indicates the part of the IP address that defines individual workstations and the part that defines the remote network. The MTU is the maximum size of data packets that can be exchanged over the link.

VJ Compression triggers a special algorithm that reduces the size of TCPIP packet headers dramatically. Most Communications Controllers support VJ compression, but they are often configured to remain passive. When they seen the PC sending a compressed header, then they respond by sending compressed headers back. If you know that VJ compression is possible, then it is best to force the issue by checking the box.

Domain Name Servers are used in most large organizations. They are configured with the name and IP address assigned to all of the local machines. They also provide access by local machines to the other name servers on the network. When a Web browser wants to connect to "pclt.cis.yale.edu" it will first send a message to the machine configured as the local name server. That machine uses the "yale.edu" part to contact the name server at yale to locate information on the PCLT server. It passes back an IP address that can be used to send a request to the PCLT server.

Fill in the field named "Your Host Name" with anything. Machines on the LAN have a name when they act as servers. Each dial-in line often is assigned an arbitrary name by the name server, which the dial-in user normally doesn't need to know. The field "Your Domain Name" provides a default suffix that is added to any Internet name that doesn't have any periods. As configured here, the OS/2 command "ftp fred" will be treated as a reference to "fred.cis.yale.edu".



The News Server name identifies a Network News Transfer Protocol (NNTP) server that will be used by the News Reader utility to fetch news. The name configured here works within the Yale environment but will not support requests from outside. Find your own news server.

The Gopher Server identifies a "Home" machine to which the Gopher client program will send its first query when it starts up. YALEINFO is the campus information and bulletin board system.

The WWW server field is not very helpful. To start a Web browser, one needs a URL. Configure the "home page" in Web Explorer after it starts up.

The Mail Server information is supposed to provide a starting configuration for the Ultimail Lite package. It identifies a Post Office Protocol (POP) server that receives mail on your behalf. When requested, Ultimail contacts this server to fetch any new mail. Mail sent by Ultimail or by the News Reader goes out through this server.

The mail configuration is rather complicated. In Ultimail itself there are six panels of parameters to establish a signature field at the end of each mail item, to annotate mail quoted during a reply, and handle other special features. Information provided here many not be successfully transferred. It is best to start Ultimail and check all the settings there directly.

In this example, the mail client contacts a machine named "minerva.cis.yale.edu". It supplies the userid "gilbert" and a password not shown. This would be the same userid and password that I would use to logon to that particular Unix host. Instead of logging on, the POP server uses the userid and password to retrieve any mail received by that host and to send it to my PC.

This is not, however, what appears to be happening in the Reply fields. The two reply fields suggest that return mail should be sent to "Howard.Gilbert@yale.edu". This is a convention adopted by the University to save reprinting business cards every time machines change. No matter how the network is configured, there will be a machine acting as "yale.edu". It will have no users or accounts. Its only function is to receive mail and forward it to another machine. In this particular case, mail arriving for "Howard.Gilbert@yale.edu" gets forwarded to "gilbert@minerva.cis.yale.edu".



The last panel selects a type of modem, a COM port, and modem speed. When the brand of modem is selected, the Initialization Strings in the last two fields are filled in. A speed of 38400 is probably a good choice on a computer with a decent (16550A) serial port. If the computer has an older inadequate chip, then 19200 is the highest recommended modem speed. SLIP or PPP will always run with 8 data bits and no parity.

There is also a section to disable the "call waiting" feature where the line generates a "beep" when someone dials into your phone when another call is active. The "beep" may or may not disconnect the data session. If you do not want to be disturbed, then this option may be used.

Adapting a REXX Login Script
Prior to the "PPP Update" it was necessary to use a REXX login script to handle most connections. With the simple scripts listed previously, REXX is now only needed to redial from a busy signal or to handle special cases. Most of the people who initially complained that they couldn't get Warp connected mentioned that they didn't know anything about REXX and didn't use it. Running OS/2 and not knowing REXX is something like living in Key West and not knowing how to swim. This is not the place to teach an entire language, but fortunately you don't need to know much about REXX to accomplish this task.

Click here for a quick introduction to the REXX language.

The ANNEX.CMD Script
IBM supplies a sample ANNEX.CMD script in the \TCPIP\BIN directory during installation of the Internet Connection. This section examines key lines from that script. The examples provided here will not provide any more function than can be accomplished with the standard login sequence scripting language.

/*--*/

Anything in a REXX program between "/*" and "*/" is a comment. All REXX programs must begin with a comment. Its a rule.

After some standard modem initialization comes the key logic. It is reproduced below, with some comments removed:

call waitfor 'CyberGate&gt ' ; call flush_receive 'echo'

On the whole, this is lousy REXX and is not the example I would choose if the purpose of this exercise was to learn the language instead of connecting to the provider. However, this is what you get to start with and so we have to live with it as a starting point.

The particular communications controller that IBM chose to support starts by sending out a block of greeting junk followed by a command prompt of the form "CyberGate&gt ". It is fairly standard practice for the command prompt to end in "&gt ", but the "CyberGate" part is terribly specialized. The script responds with the command "SLIP" and a Carriage Return character (that the script has conveniently stored in the CR variable in an earlier section not reproduced here).

The script now waits for a prompt "Username:" and responds with the USERNAME variable (remember, this was extracted in the first PARSE statement shown above and was the second word in the argument list that you configured in the Login Script field of the first configuration panel.

The controller prompts for "Password:" and the script responds with the contents of the PASSWORD variable.

The controller now wants to respond with a line that includes something like:

Annex address is 130.132.57.20. Your address is 130.132.57.27.

The script wants to capture the two addresses in this string. It waits for the "Your address is" part of the reply.

call waitfor 'Your address is'

When that string has been received, then the first address is in the WAITFOR_BUFFER and the second address has not yet been processed. The first PARSE statement discards leading trash (the first period), the string "Annex address is" in the source gets matched, and the address is deposited into A ("130"), B ("132"), C ("57"), and D ("20"). The next line then recombines these numbers into a IP address string assigned to variable ANNEX_ADDRESS.

call waitfor crlf

Remeber, the previous WAITFOR trigger in the middle of a line of output being sent by the Controller. This second WAITFOR reads the rest of the line (up to Carriage Return and Line Feed). This puts the second address into the WAITFOR_BUFFER. This second PARSE statement decodes it, and uses it to construct a variable OS2_ADDRESS.

Building Your Own Script
The first step to build a script is to use any terminal emulator, even the Terminal accessory in WINOS2, to connect to the communications controller and to run through the initial logon sequence. Capture this for further study. Consider the following example captured from the Cisco communications controller at Yale:

CONNECT 14400/ECLC Welcome to the Yale University Network -Authorized access only- -Connections may be logged- Type: ? for help &lt command&gt ? for help with a particular command logout to logout User Access Verification Username: gilbert Password: Yale-Remote-01&gt SLIP Entering SLIP mode. Async interface address is unnumbered (Ethernet0) Your IP address is 130.132.57.30. MTU is 1006 bytes Header compression will match your system. 

This sequence has the same elements as the ANNEX script, but with some important differences. For one, the Userid and Password must be entered first, before the SLIP command can be typed. The Cisco controller uses the "invisible" approach where it advertises no IP address for itself. The convention at Yale, however, is that the Gateway router will always have the last number in its IP address set to 1. Thus although the Cisco hasn't sent any explicit information about the gateway, if this remote PC has been assigned address 130.132.57.30, then the Gateway must have the first three numbers and end in 1 (130.132.57.1). With these changes, now we can rearrange the ANNEX script as follows:

call waitfor 'name:' ; call flush_receive 'echo' annex_address = a||'.'||b||'.'||c||'.1'

A few of these changes are stylistic. For example, after examining a number of different communications controllers, one discovers that some end the prompt "Username:" and some end it "username:". Although REXX ignores case in variable names and keywords, it honors it inside a quoted text string. So after a while one learns that the best general approach is to trigger on the end of the word and match both the capitalized and uncapitalized prompt. The same idea drops the "Pass" in "Password:". Clearly we want to dump whatever gets put in front of the "&gt " in the command prompt.

The "MTU" phrase appears immediately after the IP address gets printed out, so we use it as a trigger to stop the WAITFOR. Then the address gets parsed out of the buffer. In this case, the IP address presented belongs to this remote machine (it is the OS2_ADDRESS) and in this case the Gateway IP address can be deduced by taking the same first three numbers as a prefix and ending with a "1".

Obviously calling this ANNEX.CMD and leaving the ANNEX_ADDRESS variable name is a bit confusing, since this script now has nothing at all to do with an ANNEX brand controller. However, cleaning things up involves more work that is necessary, so this script makes the fewest possible changes and just gets things working.

It is now possible to fall through to the rest of the IBM ANNEX.CMD script and it will do the right thing. It is, however, informative to examine what the "right thing" really is:

call flush_receive 'echo'

The FLUSH_RECEIVE lets the user see the output from the communications controller that is still in the buffer. The two SAY statements also show up on the screen and are useful diagnostic statements in the event that the processing gets completely fouled up. The last two statements execute two OS/2 commands that configure the TCP/IP protocol. In this example, they will expand to

ifconfig sl0 130.132.57.30 130.132.57.1 netmask 255.255.255.0 route add default 130.132.57.1 1

The IFCONFIG statement tells the TCP/IP support that the SLIP connection ("SL0") is a route to send messages to a machine with IP address 130.132.57.1 and that in this connection the address assigned to my PC is 130.132.57.30. The ROUTE statement says to send all messages for all other machines to the gateway at 130.132.57.1 (and therefore to send them all on the SLIP line). IFCONFIG.EXE and ROUTE.EXE were installed with the rest of the Internet Connection programs in \TCPIP\BIN. However, as was noted previously, many DOS/Windows packages also have programs with this name. Since \WINDOWS is often configured in the OS/2 PATH before the \TCPIP\BIN directory, it was important at the start (as explained in First Clean Your Windows) to remove programs with this name from the WINDOWS directory or these statements will try to execute the DOS versions of the utilities and will therefore fail.

Note that the original ANNEX script generated a ROUTE command for a visible controller that presented its own IP address. This script changes it to support an invisible controller. Therefore the ANNEX_ADDRESS variable is set to the address of the LAN gateway and the generated ROUTE statement reflects the result.

Handling "Unknown Host" Problems
Once the phone actually dials and the Warp system connects to a network, the most common complaint of users is that the application programs (FTP, Gopher, Web Explorer) report that they cannot find any of the named server machines. This means that the user failed to configure the address of a Name Server or that the application cannot find the configuration files.

Each server has a domain name. The PCLT server is called "pclt.cis.yale.edu." There is a network of interconnected name servers that will translate this or any other machine name into the IP address needed to route messages to the server through the network. Each client machine is configured with the IP address of the name server in the network to which he is directly connected. That server handles requests for local servers, and forwards requests for information about servers in other organizations.

IBM supplies a routine that simple programs can call to lookup a name. Unfortunately, there is no way to predict how long it will take to get back a response. A query about a machine in Australia will have to go to Australia for resolution. In Unix or in traditional character mode applications, this isn't a problem. However, if a Windows or OS/2 graphic application executes a name query directly, then the mouse pointer can turn into an annoying hourglass or watch and user input gets locked out until an answer is returned. Since the Name Server protocol is extremely simple, many programs will send the query to the server and then wait for a reply with user input unlocked.

This means that the information about the Name Server has to be available not only to the Internet Connection, but also to all the OS/2, Windows, and DOS programs that run under Warp. For reasons not entirely clear, IBM has chosen to separate the DOS/Windows configuration files from the OS/2 files. When the Internet Connection is installed, nearly identical files are constructed in the \TCPIP\ETC and the TCPIP\DOS\ETC directory. Although these directories should not, in theory, be very hard to find, the Internet Connection routines require that there be an environment variable set to point to them:

SET ETC=E:\TCPIP\ETC is put in the CONFIG.SYS for the OS/2 programs SET ETC=E:\TCPIP\DOS\ETC is put in AUTOEXEC.BAT for the DOS/Windows programs

Unfortunately, the AUTOEXEC.BAT file is reinitialized every time that DOS or WINOS2 support in reinstalled by the Selective Install process. The symptom is either that OS/2 programs can find a host, but a DOS or Windows program cannot find it, or else DOS/Windows programs report something cryptic about being unable to find a "service". The missing SET statement need to be edited back into the AUTOEXEC file.

Assuming that the two environment variables are now in place, a failure to resolve host names would then mean that either the RESOLV or HOSTS file is missing. The "\TCPIP\ETC\RESOLV" file (yes, it has no dot or extension, 'resolv' is the entire name) defines the name server address and the suffix added to all machines in the local network:

domain cis.yale.edu nameserver 130.132.1.9

If this machines is configured to have the name "fred", then the first line says that its full name is "fred.cis.yale.edu". The second line says that the Name Server in the local network is at 130.132.1.9 so all requests for name resolution should be sent to that address. There should be an identical \TCPIP\DOS\ETC\RESOLV file to handle name resolution for DOS/Windows programs.

Most Unix systems can act as Name Servers. There is also an optional package for the full TCP/IP for OS/2 product that can turn an OS/2 machine into a Name Server for a network. Even so, a small network with a few machines may not want to go to all the trouble of maintaining a server. For this purpose, the \TCPIP\ETC\HOSTS and \TCPIP\DOS\ETC\HOSTS files provide a list of IP addresses and machine names.

130.132.21.58 PCLT 128.123.35.151 HOBBES

The hosts file can include long names or nicknames. Generally, the TCP/IP code will check the HOSTS file first for a name, and if it is not found there then the code will send a query to the nameserver.

OS/2 TCP/IP Components
The Internet Connection for Warp, as the TCP/IP for OS/2 product before it, is organized into a number of layered or functional components. To diagnose problems or to do anything out of the ordinary, it is useful to understand these groups of programs and their relationship with each other.

The Application Program Interface
In OS/2, applications call the operating system, database managers, or communications support through groups of subroutines packaged in Dynamic Link Libraries (DLL's). The Internet Connection API routines are provided by four modules in the \TCPIP\DLL directory:
 * SO32DLL.DLL provides the 32-bit version of the core "socket" communications services. Routines here allow the user to establish a session, and to send and receive data.
 * TCP32DLL.DLL provides the 32-bit version of routines that do name lookup, address conversion, and provide other support for the socket interface.
 * FTPAPI.DLL provides a special subroutine library to use the FTP protocol.
 * TCPIPDLL.DLL supplies 16-bit versions of the SO32 and TCP32 routines. This allows older OS/2 programs to run on the current release of the system.

The TCP/IP Protocol Support
The control blocks and buffers that represent the active connections are maintained by the TCP/IP protocol support in the kernel or in a background program. This part of the system is loaded and started by three statements in CONFIG.SYS:

DEVICE=e:\tcpip\bin\inet.sys DEVICE=e:\tcpip\bin\ifndisnl.sys RUN=e:\tcpip\bin\cntrl.exe

If the workstation is connected to a LAN, then the middle statement will change from IFNDISNL to IFNDIS.



INET runs as a device driver at Level 0, with full system privileges. It uses the services of IFNDIS to communicate to the LAN services of OS/2 (the part of the system based on the NDIS conventions used by IBM and Microsoft in their LAN architecture). In this example, LAN access is provided through a driver for the 3COM Etherlink III family of cards.

TCP/IP was designed to be easy to use and robust. Sometimes, however, a seemingly straightforward request runs into a problem that requires a higher level of processing than is appropriate down in device drivers. For this purpose, TCP/IP spins off a background program named CNTRL.EXE. It doesn't have a window, so the user typically doesn't see it. However, running as a regular program it can call all the system services, open datasets, and allocate memory for larger tables.

When there is no LAN connection, and only SLIP is used, then the IFNDISL stub driver is loaded. The blue boxes (Protman and ELNK3) disappear. SLIP traffic is routed through SLIP.EXE or SLIPPM.EXE which runs as an application program up. In this case, all the data goes from INET up to the SLIP programs and then out the COM port.

Other Dialects of IBM TCP/IP
The primary use of the TCP/IP protocol is to connect to Internet Services. However, in PC systems it has two other uses.

TCP/IP can be used by the Redirector to communicate with file or print servers on the network. Traditionally, IBM and Microsoft Redirectors have used a smaller, simpler protocol named NETBEUI (or in other contexts, NETBIOS). NETBEUI had the advantage in Plain Old DOS of taking up the least memory, a distinct disadvantage when trying to squeeze everything into a 640K area of memory. However, NETBEUI was not designed to be routed across a large network. As the focus of PC use changed from small departmental workgroups to Enterprise-wide applications, it has become important to replace NETBEUI with a better albeit larger protocol like TCP/IP.

Release 4.0 of the IBM LAN server includes all the modules for the lower levels of the TCP/IP protocol. They are intended for use as a transport protocol for messages between the Redirector and the Server. However, they can also provide the missing components needed to connect Warp to a LAN.

At a higher level, IBM proposed several years ago a new Communications Blueprint. Its purpose was to update the earlier IBM strategy that depended entirely on SNA. As it happens, the current Microsoft strategy duplicates the IBM Blueprint except for minor differences in some of the component names.

The Blueprint reduces most of the communications issues to four layers. The lowest layer provides the physical connection used to transmit data. Some examples of the options at this level include Ethernet, Token Ring, Frame Relay, modem, ISDN, X.25, and Fiber Optic ATM. In theory, these options are all interchangeable except for speed, cost, and reliability.

The next layer up is the type of network organization. Options here include SNA, TCP/IP, and OSI. SNA provides a good choice for an internal network with high reliability but higher cost. TCP/IP is a good choice for a public or multivendor network with more informal management.

The third layer reflects the type of communication. Options include traditional sessions based on sockets, Remote Procedure Calls, or transactions based on APPC.

The Anynet/2 product for OS/2 reflects a partial implementation of the Blueprint. It also is based on the same LAN support modules incorporated into LAN Server 4.0. Assuming that some version of this code is incorporated in the forthcoming Warp LAN Client, then the LAN software will come together nicely.

However, the remote dial-up connections are not being handled very well. SLIP only provides support for TCP/IP. The LAN Client package is supposed to include the client version of IBM's LAN Distance package, which provides an alternate version of the remote LAN client. IBM has a bunch of other products (something called DIALS for the 8235, Route eXpander, the WaveRunner ISDN support). All provide some sort of dial-in alternative to the LAN, all support TCP/IP, and none interoperate with each other. To this mess, the SLIP support packaged with Warp adds an additional and now highly visible incompatible alternative. It is not clear whether and how this mess will sort itself out.

Microsoft, in contrast, has a very clear communications structure in place for Windows NT 3.5. Most of the same elements are part of the Windows 95 (Chicago) current Beta test release. The user can connect to the network with a LAN adapter, modem, or ISDN link. All protocols run over all forms of network attachment. The modem connection uses the PPP standard protocol that interoperates with standard third party communications controllers.

Adding LAN Support
The Internet Connection supplied with the Bonus Pak for Personal Warp contains only support for dial-in access using SLIP (and PPP with the "PPP Update"). Compatible LAN support will be provided in a future LAN Client version of the Warp family. LAN Client will simply repackage and slightly upgrade some code that is already available. If you are unable to wait, you can install LAN support using disks from IBM LAN Server 4.0.

It doesn't make sense to buy a Server just to get the client piece. However, LS 4.0 is a very nice, very fast file server and many people will already have a copy. There are also a number of more exotic products (Anynet/2, DCE) that have the same code. Everyone else may find it a lot cheaper to wait for the LAN Server to be offered.

You don't really need LS itself, but rather a component named MPTS that is distributed with it. MPTS (Multi-Protocol Transport Services) is the latest version of a sequence of OS/2 LAN support components with names like LAPS and NTS/2. The terms "MPTS" and "MPTN" are often used interchangeably to refer to the component. Where it matters, MPTS.EXE is a utility program and \MPTN is the directory into which it installs some files.

If PCLT ever becomes more formalized, the next section will be on the Drake Test. There are a handful of interrelated Three and Four Letter Acronyms (TFLAs) that always confuse people. It is not safe to try to bypass these issues.


 * OS/2 LAN support is based on NDIS 2.x (the second generation of the MS-3Com Network Driver Interface Specification). DOS drivers are 16-bit NDIS 1.x, and Chicago/NT drivers are 32-bit NDIS 3.x. OS/2 Device Drivers still support a 16-bit interface, even though the whole system supports 32-bit code, so it is reasonable that the 2.x release number fits right between DOS and NT.
 * Novell has its own ODI stuff. ODI does the same thing as NDIS, but its different. The only thing going for ODI is the large market share that Novell enjoys. TCP/IP and all the other IBM stuff (SNA, DCE, ...) works through NDIS. Novell has been unable to deliver working code for OS/2, NT, Chicago, or any system more complicated than DOS. ODI may be a bit faster, but since it doesn't work this is not necessarily an advantage.
 * In previous years, IBM tried to nickel and dime customers by packaging only the subset of LAN support needed to run any given product. LAN Server had no TCP/IP, and the TCP/IP product had no NETBIOS support. To run NETBIOS over TCP/IP required a third optional product. This was the problem with LAPS and NTS/2.
 * Microsoft is now bundling all its support in with WFWG, Chicago, and NT. NETBEUI has problems in large networks, and IBM needs a standard NETBIOS over TCP/IP to overcome them. To keep LAN Server 4.0 competitive, IBM had to add minimal TCP/IP protocol support into that product.
 * There is also the larger IBM Communications Blueprint. This larger strategy breaks networking down into three independent interfaces. The user can choose any type of connection (Ethernet, Token Ring, ISDN, or modem). Separately, the user can choose any type of Network based on how much management and complexity is required (NETBEUI is simple but local, TCP/IP is harder, SNA is hardest but best controlled). At the top, the programmer chooses any programming interface (the "Sockets" subroutines from Unix, the CPIC subroutines from SNA). The Blueprint says that all combinations of subroutines, networks, and adapters should work.
 * MPTS reflects the OS/2 LAN support for the Communications Blueprint. It provides support for NETBIOS, TCP/IP, and SNA. It includes the NETBIOS over TCP/IP support previously sold as a separate product. It also include the Sockets subroutine libraries previously sold as part of the TCP/IP Programmer's Kit.
 * To get CPIC and other SNA support over MPTS, it is still necessary to purchase the Communications Manager. To run SNA over TCP/IP, one needs the Anynet/2 product. To get programming interfaces other than Sockets, one needs other products (DCE Client, TCP/IP Programmers for Sun RPC, X-Windows Client). However, MPTS by itself is enough to support LAN access from the Warp Internet Connection programs and to provide the most popular Internet programming interface.

For MPTS to work well with the Internet Connection, it should be at level WR08000 or later. The files will be dated Sept. 94 or later. The version of MPTS distributed on DEVCON (files dated Aug 94 or earlier) are unable to coexist smoothly with the support provided with the Warp Bonus Pak.

Before and After
The Warp Internet Connection was installed into a directory named \TCPIP on your hard disk. MPTS will create two additional directories. \IBMCOM will contain the NDIS 2.x code. \MPTN will contain the additional multiprotocol support.

After installing Warp and the Bonus Pak and before installing MPTS, the CONFIG.SYS file should include statements like:

DEVICE=g:\tcpip\bin\inet.sys DEVICE=g:\tcpip\bin\ifndisnl.sys DEVICE=g:\tcpip\bin\vdostcp.vdd DEVICE=g:\tcpip\bin\vdostcp.sys RUN=g:\tcpip\bin\cntrl.exe RUN=g:\tcpip\bin\vdosctl.exe

INET, IFNDISNL, and CNTRL are the core of the TCP/IP protocol. The other three drivers provide TCP/IP access for DOS and Windows programs. MPTS also contains its own copies of the three core drivers. INET and CNTRL are pretty much the same programs in the Bonus Pak and in MPTS. IFNDISNL was a dummy placeholder that has to be upgraded to the real MPTS code.

MPTS is distributed on three diskettes or on CDROM. It is installed and configured with the MPTS.EXE utility. After it has been installed, CONFIG.SYS will have been changed.

Lines added near the front: DEVICE=G:\ibmcom\LANMSGDD.OS2 /I:G:\ibmcom DEVICE=G:\ibmcom\PROTMAN.OS2 /I:G:\ibmcom

What is left of the Bonus Pak drivers: DEVICE=g:\tcpip\bin\vdostcp.vdd DEVICE=g:\tcpip\bin\vdostcp.sys RUN=g:\tcpip\bin\vdosctl.exe

Lines added at the end: CALL=G:\ibmcom\PROTOCOL\NETBIND.EXE RUN=G:\ibmcom\LANMSGEX.EXE DEVICE=G:\MPTN\PROTOCOL\MPTN.SYS DEVICE=G:\MPTN\PROTOCOL\LIPC.SYS DEVICE=G:\MPTN\PROTOCOL\INET.SYS DEVICE=G:\MPTN\PROTOCOL\IFNDIS.SYS RUN=G:\MPTN\BIN\CNTRL.EXE /P mptn_os$ mptn_in$ CALL=G:\OS2\CMD.EXE /Q /C G:\MPTN\BIN\MPTSTART.CMD DEVICE=G:\IBMCOM\MACS\ELNK3.OS2

Disk letters will vary. Additional lines might be added if NETBIOS is installed to support the LAN Server 4.0 Redirector. The last line for ELNK3 supports a 3Com Etherlink III adapter card and will be different for other types of LAN cards.

As before INET, IFNDIS, and CNTL are the core of the TCP/IP part. MPTS replaces the Internet Connection drivers with its own code. MPTS doesn't itself provide support for DOS/Windows programs, but the three drivers from Internet Connection that are not replaced (two VDOSTCP modules and VDOSCTL) provide that support. The combination of Internet Connection (installed first) and MPTS (installed on top of it) provide fairly complete coverage.

PROTMAN manages the NDIS stuff. ELNK3 is an example of a LAN hardware driver. LIPC provides a high performance connect between programs on the same machine (Local Inter-Process Communications) that can be easily extended through the LAN to other machine.

Information needed to configure NDIS components (hardware parameters for the Ethernet Card, NETBIOS limits, etc) are stored in \IBMCOM\PROTOCOL.INI. Generally, this file contains nothing related to the Internet.

TCP/IP configuration, however, is a bit more confusing. MPTS is designed to provide TCP/IP support to connect LAN Server 4.0 clients and servers together even without Internet access. The Warp Internet Connection from the Bonus Pak provides Internet access through the modem without a LAN. When you throw the two together, there is some overlap.

One user installs Warp on a laptop computer in the office. There is an Ethernet "credit card" PCMCIA adapter in the machine, so MPTS is also installed. Both the Bonus Pak and the MPTS panels are configured with information about the office environment. The laptop will now work both from home (over the modem) and at the office (over the LAN) because both Internet Connection and MPTS were configured with the same parameters.

Another user has a desktop machine with a modem and a LAN configuration. Most of the time the user connects to the office network over the LAN. Occasionally, the user wants to access a remote network over the modem. In this case, MPTS will be configured with the local office parameters, while the Internet Connection will be configured with information about the remote network. Getting this mess to work requires careful handling.

SET ETC=G:\TCPIP\ETC

The ETC environment variable, normally set in CONFIG.SYS, points to the directory from which Internet client application programs expect to get their information. To find a server machine from its name, the Internet support subroutines will look in this directory for the RESOLV file that designates a domain name server or for a HOSTS table that lists names and IP addresses. The mail, news, and other utilities save their information in this directory.

The IP number of the LAN adapter and routing information to the outside world are established by commands. MPTS configuration creates a set of commands to be executed during initialization and stores them in \MPTN\BIN\SETUP.CMD:

route -f arp -f ifconfig lan0 130.132.57.244 netmask 255.255.255.0 metric 0 mtu 1500 broadcast 130.132.57.255 route add default 130.132.57.1 1

A sharp eyed reader may remember that the same statements were generated for SLIP/PPP connections explicitly in a REXX login script or implicitly with the "Dial Other Internet Providers" utility. The IFCONFIG statement tells TCP/IP that the Ethernet adapter (LAN0) has IP address 130.132.57.244. It is connected to the network of all machines with addresses 130.132.57.*. The ROUTE statement says that the machine 130.132.57.1 is a Gateway to the rest of the world.

This arrangement is based on the original Unix design for Internet support. Unix machines are sometimes connected to more than one network, and a Unix box can act as a gateway between two networks. The information about an individual LAN adapter was regarded as more changeable that the information about the network as a whole. Thus ETC configures information (like the Name Server address) that is regarded as global, while IFCONFIG and ROUTE change dynamic routing tables.

The MPTSTART statement in CONFIG.SYS configures the address and routing gateway for the LAN adapter. To change later on to use SLIP, one should use "ifconfig lan0 down" to disable the LAN adapter, then run the standard login script or "Dial Other Internet Providers" utility. Once the remote connection is established, another IFCONFIG will be issued for the "sl0" SLIP/PPP line and another ROUTE command will establish a new Gateway.