Independent Evaluations of Networking Products and Tools

Early Unix Networking — The AIX Alternative

IBM's other network operating system environment gets a vote of confidence from Wausau Insurance

 

 

Some time ago, Wausau Insurance Company asked my company to port an insurance rating application to a networked, distributed Unix environment. Wausau wanted to use IBM RS/6000 machines running AIX as file servers, with PC workstations running DOS or possibly a version of Unix. The RS/6000s had to act as a host computer as well as a file server; we'd have to restructure the application into a client/server architecture. All background tasks would run under AIX (IBM's version of Unix) on the RS/6000.

 

The application, written in a mix of compiled Basic, assembly language, and C, was already LAN aware. We had designed it to perform file-sharing and record-locking on top of such network operating systems such as NetWare, IBM's PC LAN Program, and LAN Manager. Background tasks ran on dedicated, unattended workstations. Our starting point wasn't too far away from Wausau's DOS-and-Unix-combined client/server goal, so we felt confident we could do the job. Our first step was to use the RS/6000 successfully as a file server, then port the background tasks to run under AIX on that same RS/6000.

 

Why AIX?

Wausau decided to buy into Unix (AIX on the RS/6000, AIX or other Unix on PCs) rather than the more traditional, SAA-compliant OS/2-MVS combination. It cited several reasons, the biggest of which was scalability. OS/2 only runs on microcomputers (although the rumor at press time has it that IBM is developing a version of OS/2 for the RS/6000). Unix, on the other hand, runs on PCs, RS/6000s, and even mainframes. AIX on an RS/6000 has many connectivity features, including Token Ring, Ethernet, X.25, asynchronous, and synchronous communications. AIX also supports IBM 3270, DEC VT-100, IBM 3151, X-Windows, and many other communications modes. On a PC, you can run DOS as a task under Unix. These are all important considerations when you want to keep your options open.

 

Wausau's plan also saves the company money by reducing the load on its mainframes, while distributing significant processing power to its 40 regional offices and over 100 service offices. By sticking with common Unix facilities and system calls, we would provide Wausau with an application it wouldn't have to rewrite  every three to five years--a typical problem under DOS, OS/2, and to some extent MVS.

 

Wausau briefly considered Novell's NetWare as a development platform and file server network operating system, but decided that the resulting server code, in the form of Netware Loadable Modules (NLMs), would be NetWare-specific and thus not as portable as code designed to run under Unix. Another scalability factor was that, with Unix, a PC can be a file server, a DOS workstation, or a terminal for RS/6000 applications without rebooting the machine. With only ordinary Unix-style coding techniques, tightly-integrated client/server applications become possible between the Unix host and DOS workstations. The programmer doesn't have to think in terms of programming a file server. The server becomes just another Unix box.

 

Wausau could have its cake and eat it too. The company could strike out in a new technological direction, yet maintain its considerable investment in IBM computer architectures.

 

NFS vs AADU

Not everything was honey and roses with Wausau's decision to use Unix as their base operating system. First off, we ran into the thorny design issue of choosing network support software. IBM offers several environments for file-sharing under AIX. We distilled the choices down to two: IBM's version of SUN's Network File System (NFS) and IBM's version of Locus Computing's PC Interface, which IBM calls AIX Access For DOS Users (AADU). Both AADU and NFS run on top of TCP/IP; we had to decide which would be the best tool for the job.

 

IBM licenses NFS 3.2 from SUN. The AIX Communications Handbook calls NFS ``...a de facto standard system for sharing directories across TCP/IP networks.'' IBM implementations of NFS are available for DOS, AIX, and for the mainframe MVS and VM operating systems. That these implementations were interoperable impressed us; NFS became an early favorite.

 

NFS gives you the means to mount remote directories over empty local directories (directory ``stubs''). Local programs access files on the remote computer as though they resided in a local directory. A ``client host'' mounts directories from remote computers; a ``server host'' lets other hosts mount its directories. The server host exports a file system with an entry in  /etc/exports.

 

When a client host accesses a file in the mounted directory, NFS redirects the file request over the network to the remote server host. It only supports the exporting  of entire file systems, and does not support inherited mounts.

 

NFS has no mechanism to map user names and permissions across the network. For security, administrators and programmers must configure networks that use NFS by conservatively restricting exports to file systems that everyone may access, or by setting up separate, segregated file systems for shared access. You can set up various levels of what's called Single System Images via a companion product named Yellow Pages. Yellow Pages provides a distributed network lookup service and maintains a database of network maps that clients can query.

 

I found NFS and Yellow Pages extremely difficult to administer, however. For example, the superuser (root) on one system cannot remotely exercise his powers on a host system. NFS maps the client root to the host  ID nobody, who by default has no privileges on the host. If a Yellow Pages server dies, then applications, utilities, and their users hang endlessly waiting for the server to respond. And you must take great care when setting up the parameters for the NFS and Yellow Pages mount commands.

 

NFS is a stateless protocol. It avoids complexity by deliberately forgetting about recent file requests from workstations and forcing each workstation to completely specify each file request. This approach goes hand in hand with the connectionless User Datagram Protocol that current implementations of NFS use for transport services. Though it's fine for reducing the chances of data loss when a server crashes, this technique gave me pause--it meant that NFS had to pass lots of extra information inside every file service request packet. The resulting extra LAN traffic might not be worthwhile.

 

One of NFS' strong points is that it lets programs on different machines exchange data using the External Data Representation (XDR) standard. This is a big consideration when you want Intel-based PS/2s to talk to the RISC-based RS/6000. Even something as simple as a two-byte integer needs to be transformed between the two machines because the Intel architecture puts the high-order byte last in memory, while the RS/600 puts it first. If we didn't use NFS, we'd have to worry about the numeric representation of nearly every field in the application.

 

The lockd daemon is an optional NFS 3.2 feature. Without it, record and file locking aren't possible. Unfortunately, IBM chose not to incorporate lockd into its NFS products, except as a component of AIX/370. To use NFS as a network operating system, I'd have to code the locking routines myself (I do most of the low-level coding within the application). Tentatively, I designed a daemon that would use the Unix lock() system call on the AIX machine to implement locking, and I prepared to make the DOS workstations coordinate with the daemon via TCP/IP. I figured I could make it work well enough for the application, but I knew the approach was awkward and a kludge.

 

On any LAN, the device drivers and TSRs that accomplish file redirection take up memory. NFS, we found, uses about 90K. The application isn't small, and we found precious little room left after loading TCP/IP and NFS on the DOS workstation. Solving this problem (which is not unique to NFS) was tougher than creating a new locking mechanism. Because we couldn't find a way to configure NFS to take up less memory, the answer was to use a 386 memory manager such as QEMM 386 or 386MAX. I used one to load the device drivers and TSRs into the high memory area between the 640 KB and 1 MB.

 

Another drawback to NFS was that it's slow. You need a little more CPU power than you otherwise might if you want to get good performance. I suspect the slowness is a result of NFS' statelessness; it obviously must spend time refreshing its memory about what it last did for a client.

 

The choice came down to two products, IBM's version of NFS (Network File System, licensed from SUN Microsystems) and IBM's AADU (AIX Access for DOS Users, IBM's version of Locus Computing's PC Interface product). NFS took an early lead in the competition, but I discovered several problems with NFS. Next, I'll tell you more about AADU and let you know which one got the nod--and why. I'll also talk about a rather special Oracle interface we constructed that saves both memory and money.

 

 

How AADU Works

Like NFS, AADU runs on top of TCP/IP. On a Token Ring LAN, AADU consists of two DOS device drivers that implement TCP/IP and that establish a new DOS disk drive letter, pretty much the same way that NetWare does. You don't assign (or map) the drive letter, though; DOS and AADU simply give you the next available drive letter. This network drive encompasses the top level directory structure of the Unix host, including all its file systems. As an example, suppose your PC already has a C: and a D: drive--AADU gives you a drive E: on which you see typical Unix directories such as \USR, \TMP, and \LOST'UND. This last directory name is AADU's way of representing the ubiquitous Unix "lost+found" directory in terms of the more restrictive DOS rules for file names. AADU provides the utility udir to let you see both the full AIX name and the "mapped" DOS name.

 

To accomplish the file/disk redirection, AADU uses the Internet Protocol (the IP part of ARPA's TCP/IP) and User Datagram Protocol (UDP) for LAN communications. IP routes the packets, and UDP provides simple process-to-process datagram service on top of IP. When an application (even COMMAND.COM) issues a DOS request for file or disk services, AADU snatches the request away from DOS and shunts it across the LAN to the Unix host. A background process on the host (a daemon) fills the request by issuing the corresponding Unix system call and sending the response back to the workstation. These AADU packets, like other Token Ring frames, have specific source and destination network addresses. NetWare, LAN Server, and NFS/AADU are possible on the same LAN, but a workstation can see only one type of server at a time.

 

Actually, two Unix daemons (PCIMAPSVR.IP and PCICONSVR.IP) run on the host, and a third (PCIDOSSVR.IP) is spawned for each workstation that performs the AADU login sequence. PCIMAPSVR.IP maintains site maps that identify all the AADU servers on the LAN; the AADU login program uses the information to list these servers so you can pick one. The servers are identified by host name and by Internet Address in the file  /etc/hosts. The PCICONSVR.IP daemon periodically broadcasts “<host name> HERE” messages to let all PCIMAPSVR.IP daemons know to include it in their site maps. And PCIDOSSVR.IP is the daemon spawned for each AADU workstation--it maintains a dialog with the workstation and executes Unix system calls on behalf of that workstation. Results from these system calls are transmitted back to the AADU workstation and made to look as if DOS had performed the request. As you'd expect, print redirection is supported along with file redirection.

 

This structure of Unix daemons and DOS device drivers works pretty well until a DOS user forgets to use the AADU logout program to end a session. If the DOS machine reboots during a session (or even if it suffers a power failure or lockup), the PCIDOSSVR.IP daemon remains running as a  "zombie" Unix process. It takes a supervisor-level (root) Unix login to kill the zombie.

 

You probably know that each Unix filesystem, like each DOS drive letter, has its own space-available and space-used statistics. Since AADU maps the entire Unix host as a single DOS drive, you can get confusing and conflicting reports from even a simple DOS DIR command. In the E:\TMP subdirectory, for example, you might see 8000000 bytes free. But in the E:\USR subdirectory, you'll see a different report of free disk space. This is disconcerting, but if IBM/Locus were to map each Unix file system as a separate network drive, the result might be even more confusing and difficult to follow.

 

 

Record Locking and File Sharing

AADU supports DOS record locking and file sharing, unlike IBM's NFS. You'll recall this was a sore point for me with NFS. I was prepared to add my own record locking scheme on top of NFS by writing a custom Unix daemon. With AADU, I wouldn't have to. However, even with AADU, there are administrative headaches associated with record locking. The PCIDOSSVR.IP daemon uses Unix shared memory to keep track of record locks, and a DOS workstation that reboots or crashes with outstanding locks leaves those shared memory entries intact. To free the locks, all AADU users have to log off and a supervisor has to use the AADU sharectl utility to clean up shared memory. (Frankly, this same situation was a design issue I faced if I were to write a record locking daemon under NFS.)

 

 

My PC Forgot its Name

To my surprise, I found AADU doesn't support Machine Name, a fairly common feature of most networks. Machine Name is supposed to be available through a standard DOS call, function 5E00h. Because the application uses the first two characters of Machine Name to uniquely identify each user/workstation, I had to write a small (800-byte) TSR to add this support to AADU. This was annoying, but certainly not fatal. I hope IBM/Locus correct this oversight in future versions.

 

 

Performance, Memory and Security

Performance and memory usage are always big concerns on a network, and AADU measured up favorably in both categories. The AADU device drivers use up about 60K of RAM, compared to about 90K for NFS. The application runs as quickly using AADU on an RS/6000 model 320 PowerServer as it does using NetWare on a 33Mhz 80386 server.

 

This certainly tipped the scales between NFS and AADU, and if you hadn't guessed by now--we chose AADU over NFS.

 

For security, AADU relies on standard Unix protections. You use the AADU login program, which prompts you for a Unix account ID and password, to gain access to the network drive. (The supervisor must add each AADU user to the Unix system.) You can be denied read or write access to files and directories on the Unix host through the use of standard Unix permission masks. And, speaking of security--be aware that each AADU DOS device driver contains a serial number and is therefore copy-protected. Don't take the first diskette and make copies for all the users (like I did). You'll have to recall all the diskettes and make new ones, one at a time, from each individual distribution diskette.

 

 

Icing on the Cake

AADU provides a set of utilities for starting and monitoring Unix software from the DOS environment. It even comes with a C programming interface that allows you to imbed host-control functions in your software. You can manipulate AADU, execute Unix programs, and perform DOS/Unix interprocess communications involving message queues and semaphores.

 

What if you want users to be able to run Unix software and DOS software? No problem; AADU provides two terminal emulators (VT100 and VT220) that work across the LAN through a "virtual serial link". You can easily hop back and forth between a DOS prompt and a  Unix prompt. However, you can't hot-key between the two.

 

 

A Homegrown Oracle Interface

We're using Oracle 6.0 on the RS/6000 to store much of the data in relational form. The front-end of the application issues SQL statements to retrieve the data, which is then processed by a series of programs. At the tail of the processing, the application issues SQL statements to store the result. One way to get the SQL statements and data across the LAN to Oracle on the RS/6000 would be to use Oracle's SQL*Net product. SQL*Net makes it look as if Oracle is running on the workstation by redirecting data to/from the host.

 

Unfortunately, SQL*Net takes up extra memory underneath the application, and it's a fairly expensive product if you have a large number of workstations. The solution: we developed a homegrown link (a queue) between the DOS machine and the Unix host. Through this link we pass the data records, in both directions. We issue the actual SQL statements directly to Oracle with a C program on the RS/6000. The C program responds to entries we place in the network-based queue. This approach leaves us with enough memory to run the application, and it saves the cost of about a hundred copies of SQL*Net.

 

 

 

                                                                                                                                                         Back