Going Mobile With Bob Angell

Going Mobile: Part Deux

By Robert L. Angell

When I first pursued my "going mobile" project (see part one of "Going Mobile" in Personal Systems' July/August 1996 issue), I thought it was going to be an easy, "slam-dunk" process. However, implementing the appropriate solutions has provided me with quite an education when it comes to transmission control protocol/internet protocol (TCP/IP), network file system (NFS), point-to-point protocol (PPP), network printing, and other related obstacles.

Let me recap my office setup. I eliminated a single desktop workstation and purchased a RISC System/6000 (to be an interactive development platform/server running AIX) and a ThinkPad 755CE/Dock Station II combination. I put the docking station's 4.3 GB small computer system interface (SCSI) drive into the RS/6000, put a 1 GB SCSI drive on the docking station for local storage (to get around an annoying problem with extended attributes that I will discuss later), then networked the RS/6000 and the docking station together. I also set up this configuration so that all print jobs are routed to the printer connected to the RS/6000. Therefore, all these services (except the docking station storage and data) are available when I telephone the office while on the road (without the ThinkPad, there is no CPU to facilitate this).

TCP/IP is a networking strategy for connecting computers running like or different operating systems (DOS, OS/2, UNIX, MacOS, etc.) to each other. It was developed many years ago to connect different computers and operating systems on the Internet. (Please note that this is just a brief discussion on TCP/IP--there are many books written on this subject at your local library or bookstore, as well as numerous articles on the World-Wide Web. In addition, Personal Systems' March/April 1995 issue includes an in-depth article by Phil Lieberman: "TCP/IP: How it Works.")

Computers using TCP/IP networks are known as hosts (or nodes in other networking lexicons) and all take on specific names as well as special internet protocol (IP) addresses. IP addresses consist of four groups of numbers separated by periods and are used to route messages, work, and other necessary information from machine to machine. For example, in my case, the RS/6000's name is Denali, the ThinkPad's name is Everest, and another server is called Hood. Denali's IP address might be 192.178.16.1.

TCP/IP is the "software glue" that connects these machines so that I have access to my data while I'm in the office or when I'm on the road. I use the built-in PPP and TCP/IP that comes bundled with OS/2 Warp Connect to dial into the office. This would be sufficient for the in-office network except that I need the NFS piece that is found only in the full TCP/IP 2.0+ package. (NFS is now included with OS/2 Warp Server--a less expensive alternative.) Once connected via modem, I can use my data loaded on the ThinkPad and RS/6000 simultaneously.

With TCP/IP connecting everything, I can be working at a customer site, use a word processing application installed on my ThinkPad, load my word processing file from the RS/6000, make changes, then print locally at the customer site and/or remotely back at the office--it doesn't matter whether I am in the office or across the world. This capability makes TCP/IP and its related tools (PPP, NFS, etc.) my "friends."

As I make the RS/6000 a full-time member of the Internet community in the next few months, I will have even more ways to access, use, and disseminate my data. Part of AIMS' expertise is designing, developing, and implementing database systems for clients, potential customers, and internal use. With my "going mobile" project thus far, AIMS can access basic data (word processing, spreadsheet, utility files, etc.); however, we don't yet have the ability to retrieve information from our databases. The next part of this project will focus on remotely accessing the RS/6000 database.

As I mentioned earlier, although OS/2 Warp Connect on my laptop allows me to remotely access most of what I need, extended attributes (EAs) do create some limitations. When a file is written to the hard disk, OS/2 creates an EA, a special index OS/2 uses to quickly find a file on the hard disk. DOS, UNIX, and other operating systems do not use EAs; thus sharing data from one operating system to another becomes a problem. The NFS I am currently using to store data on the RS/6000 does not support EAs. If I were using OS/2 Warp Server or another network solution, the EA problem would not exist. Because some of the software I use daily depends heavily upon OS/2's EAs, it is a bit tricky to use this information remotely (or in the office when connected to the network).

To get around this EA problem, I am going to implement local storage in the docking station. Having local storage in the docking station provides the flexibility for the office, but I am still limited remotely. In the future, I will use OS/2 Warp Server on a new machine (probably a small, compact-sized server) and place all the necessary OS/2 storage there, thus eliminating the EA problem.

Another possible way around the NFS/EA limitations is a DCE/DFS (Distributed Computing Environment/Distributed File System) solution. This is an advantage OS/2 Warp Server's file system has over AIX/NFS. I will talk about this in my next article.

My phone system was also an obstacle to going mobile. I had to devise a way for the telephone (data line) to determine whether my ThinkPad had dialed into the office or a fax was arriving. After some research, I found a $60 device at Radio Shack that works on analog telephone lines to intercept calls placed to the fax machine or to the modem. This device is about the size of a small modem. It plugs into the outgoing phone line, then the modems and fax devices are plugged into it. The device "listens" for the sounds that fax machines and modems make on incoming calls and routes them to the proper machine.

In my next "Going Mobile" article, I will continue to discuss the advantages and pitfalls of accessing data from the road, talking about DCE/DFS, DB2/6000, DB2/2, and other successes and failures this setup has created.