Telecommuting:   Even if I did not telecommute, we would still have to be connected to far-flung entities. IRS requires that some of our forms be filed electronically, and our CPA is in another town. At the time we automated, I lived in Tennessee but needed to visit Florida often. I discovered I could hook up a modem in my hotel room and perform most of the functions I was accustomed to doing in my office. No additional software was needed. This was a normal function of our basic system. When I actually moved to Florida (I had reasons other than whim), long distance charges would have been too extreme for our little office. A leased line would also have been a serious financial problem. But the bills were made modest by using a second computer only periodically connected to copy the data.

Unix:   We began updating our stodgy office in 1986 using Hewlett-Packard computers originally intended as laboratory controllers. At the time, the logical choice would have been a business system with banking software, but that was a costly option, and much of the cost was software. Networked PCs were possible even then, but did not seem reliable. We opted to write our own software. We began small with a Hewlett-Packard desktop with the language BASIC. When we got that working, we began to think of Unix. The original thought was to re-write the BASIC code in PASCAL. The Unix operating system changed our minds. It was written in the language "C". Pascal worked, but was just not well adapted to its environment. It was easier to cave in and go with C. Several local terminals were connected to this computer along with a centrally located printer and a modem. We then had a powerful data processing arrangement for bargain basement prices. The trade-off (besides a lot of sweat equity) was that we were responsible for maintaining the system. That in turn created a key personnel problem.

PCs and the web:    The Unix systems are in their second incarnation and still working well. At some point, we will have to move on, and, as it is with computers, we'll move not to bigger and better, but to smaller and simpler. Right now, almost everyone in the office has a terminal and a PC on their desk. (Yes we could and do use a terminal emulator on the PCs but have not found them truly convenient.) PCs are more reliable now, and the connectivity provided by the World Wide Web and the ease of doing forms in HTML are excellent resources to exploit. Java really isn't ready for prime time, but it promises a language that will be less complex and more transportable than C, and one that fits into the web like C does in Unix. We still need to start little and do our R&D on the cheap.

It turned out that setting up a model on a single PC was stunningly difficult. A long time ago, any data processing system was expected to have five basic functions: inputing data, manipulating data, storing data, retrieving data, and displaying data. Now we routinely expect a sixth: communicating data. The web emphasizes communication, but security concerns dictate barriers to storing and retrieving data. Obviously, you don't want some web site you visit amusing itself with your personal affairs. I was advised we'd have to set up a server just for experimentation. That advice was correct but incomplete. An adequate server ("Personal Web Server") comes with Windows 98. When installed, a single PC can run Java programs and access its own data, provided certain other conditions are met. Actually, when tied on to an internet service provider, it is at least conceivable that anyone else in the world could access the same data unless passwords and barriers are in place. Good reason not to get too upset that the security measures make development tricky.

Here follows the procedure we used. We installed Windows 98 and installed the Personal Web Server that comes with it. The two volume set CoreJava, (Horstmann and Cornell, Sunsoft Press), was bought at the bookstore. The Java development kit (JDK) comes with it. A trial application was written in Java, but there are examples provided in volume II that demonstrate data file access. This application was modified per instructions in volume I to be a Java applet. A sample ASP (Active Server Page) wizard was downloaded from Microsoft and run to create a web. To do this, go to Microsoft select search and on that page select search for a particular article. The ones needed were Q174015, Q175770, Q175771, and Q180405. The last tells you how to download. Move the applet to the sample web and compile it. Set your browser's permissions to allow full permissions on Java (but, um, maybe you'd better set these back before going on line). Right click the sample web directory and set sharing. In the Default.htm, add a line to call an ASP file that calls the applet. When you double click on the Default.htm, the browser will show a file address. It needs the URL instead. This is name of your computer/ name of the web. These are names you had to select during installations. Finally, JavaScript in the ASP file can access any public method or variable in the applet.

This is complex, but not impossible, and cheap. We did shell out bucks along the way for books and software packs that proved useless. FrontPage is not useless, but it is not necessary. The Java books we bought are convenient, but we could have downloaded what we needed from Sun. In fact, I suspect beyond buying Windows 98, the rest can be had for free.

  E-Mail 
([email protected])

In Florida (information only), contact George Harrison
Obed River
228 South Courtenay Pkwy., Suite 7
Merritt Island FL     32952
(407) 452-5565