Unknown Pundit: "When you're up to your butt in alligators, it's hard to remember that the original objective was to drain the swamp."

In the Trenches with LAROKE

Konsultant's Log, Cyberdate 09.27.1997 (Getting P2 ready for his new user)

SITREP: 1:02 PM 9/11/97 Christine, the front office lady at my day job, wears many hats: "Receptionist", "Clerical Administrator", "Keeper of the Payroll", "Screen for telephone calls", and "Portal Guard to the Inner Sanctum" are just a few. Back in April I outlined my plan to replace her workstation, "Christine", a Windows 3.x 486/25 SLC, with "P2", my old Pentium P5/100 workstation, since I was now using "HAL" my IBM Aptiva Stealth (see In the Trenches Cyberdate 04.19.1997 "Moving the HAL 9000").

Being a PC "Power-user" junkie, I've become used to using both machines at the same time in the intervening months. I compose Web pages on HAL, save them, then refresh the browser screen on P2 to view them, for example.

Yesterday, at quitting time, Christine impressed cold reality on my "merry existance" by informing me that summer was over, and she was going to begin computer night classes, and she needed a PC with the Windows 95 environment. Her machine "Christine" could not make this techological leap in operating systems.

You remember, I said one of Christine's many jobs is "Keeper of the Payroll"? It is this particular role of hers that causes me to pay her special attention. So, now the time is overdue for transferring the rest of my applications from P2 to HAL and then making P2 ready for Chris. First task is to transport the remaining applications I still use from P2 to HAL. I will try to move the applications I can with QuarterDeck CleanSweep's "Transport" feature. I will have to find the installation disks for the applications that don't work with Transport.

TACAMO: While preparing to attempt transport of AutoCAD LT, I found there were two versions of CleanSweep installed on P2: "CleanSweep 95 v2.0" and "CleanSweep v3.0", so I decided to stop and remove the older version from P2 before proceeding with AutoCAD. CleanSweep v2.0 was removed from the Windows 95 "Add/Remove Programs" dialog and P2 was warm-booted.

AutoCAD LT v1.0:

1:15 PM 9/13/97 I Transported AutoCAD LT to HAL using CleanSweep and it didn't work. On P2's Desktop, the "shortcut" icon for AutoCAD LT was a T-square, carpenter's square and paper icon, but on HAL it was transformed some kind of three-dimensional "T" icon. When double-clicked, this icon would bring up an AutoCAD LT tutorial that would not, in turn, bring up the AutoCAD LT program.

I did not want to spend a lot of time finding out why the CleanSweep Transport feature did not work this time, so I uninstalled the failed AutoCAD LT installation on HAL and started tearing up my cluttered office in search of the AutoCAD LT installation disks. After about 15 minutes of grunting and muttering under my breath, I located the AutoCAD LT installation disks and manual in a dusty file box covered with parrot feathers and seeds, which served to remind me I hadn't cleaned my office since my co-workers took care of "Wingnut" while I was on vacation.

3:20 PM 9/15/97 I rebooted HAL without his startup programs, by holding down the shift key during the Windows 95 startup to give me an environment free of running programs for the AutoCAD installation. After starting CleanSweep Smartsweep, I proceeded with the AutoCAD LT installation from the original 3-1/2" installation diskettes.

At the end of the process after the SmartSweep agent informed me of a successful installation, and I clicked on the new "AutoCAD LT" Program Group window's "X" button to close it, I got an "Illegal" action error and was encouraged to "save data and restart Windows". There was no data to save, and after the restart, I expected to find the AutoCAD LT programs missing from the Windows 95 "Start" menu structure, so I was pleasantly surprised to find them there, and in working order. Now I could remove AutoCAD LT from P2, which, I proceeded to do with the help of CleanSweep.

Time-out for more dBase problems:

Now that the dBase and Foxpro programs have been working on HAL for awhile I can remove them from P2 . . . OOPs . . . not so fast.

Back in In the Trenches Cyberdate 08.23.1997 "When we last left our hero, HAL . . .", I explained making dBase 5 tables and indexes to the same specs as the original dBase IV tables and importing the dBase IV records into them to get past a "WRONG LANGUAGE" error. I stated this process was a "no-brainer", but tedious and would lead to problems later on.

The time has come to sheepishly relate the suffering I caused myself with this quick "band-aid" solution. As they say, "Hindsight is 20-20". First of all, the "WRONG LANGUAGE" error only disappeared for a day or so. I now believe that the error was not being caused by dBase IV, but FoxPro.

FoxPro routines use the same tables, and everytime they manipulate the tables, I think they are saved with FoxPro "headers". They are not dBase IV or dBase 5 tables anymore, and therefore, the "WRONG LANGUAGE" error occurs. I may be all wet with my current theory also, but for the time being, "that's my story and, I'm stickin' to it!"

My gravest sin, however, was getting one of the table structures wrong, back in May, when I made the dBase 5 tables. A dBase IV table for recording reimbursable items had an "Amount" field for the price of a reimbursable item in dollars and cents. When I created the dBase 5 table the amount field was inadvertently truncated to whole dollars. When the existing data was imported from the dBase IV tables, the "cents" portion of the amount field was "stripped".

An amount of $15.42 would become $15 for instance, or $105.95 would be $105 in the new table. About two months went by before I realized this error and corrected the table structure to account for the cents in all "future" transactions. The company did not lose any money due to this mistake of mine. The invoices went out with the correct amounts including the "cents", but the permanent database was now corrupt up to the point where I made the correction to the table structure. The data is not even important to the company except for certain "ballpark" analysis reports, but it really bugs the database "purist" in me.

It would be too much effort to get back the "cents" for the two months the error went undetected, but I could program a little routine to get the correct record amounts from the old dBase IV table of P2 before I removed the dBase programs and records from P2. This would leave me with only two months of truncated reimbursables records instead of several years worth.

7:21 AM 9/16/97 Browsing the reimbursables table on P2 revealed that there were 9,531 records. Browsing the new reimbursables table on HAL indicated that the table had grown to 9,655 records and that I had corrected my mistake at record 9,584. After creating and running my little "faux-pas" fix-it program, there would remain only 53 corrupted records without "cents" of 9,655 total records. The little utility program source code is below:

* Temp faux pas correction utility
(a title note to myself)
USE h:\dbase\vpadb\pa_main ALIAS p2 EXCLUSIVE IN 1
(open reimbursables table on P2 for exclusive use in workarea 1 and call it p2)
USE e:\dbase\vpadb\pa_main ALIAS hal EXCLUSIVE IN 2
(open reimbursables table on HAL for exclusive use in workarea 2 and call it hal)
SELECT 1
(goto workarea 1)
DO WHILE NOT EOF()
(repeat the task for each record until last record in reimbursables table on P2 is processed)
REPLACE hal.paamt WITH p2.paamt
(replace the price amount in the record on HAL with the price amount for the same record on P2)
SKIP
(move to the next record in the reimbursables table on P2)
SKIP IN hal
(move to the next record in the reimbursables table on HAL)
(...and process the next record)
ENDDO
(after all records are processed, break out of the loop and end program)

After checking the reimbursables table on HAL for the updates, all the dbase IV applications and data were removed from P2 using CleanSweep and the Windows Explorer file manager.

FormTool Gold v3.0:

2:29 PM 9/16/97 Transported FormTool Gold v3.0 for Windows form P2's drive C: to HAL's drive D: with CleanSweep's "Transport" feature. FormTool would not start initially, after the transport installation, but after a Windows 95 warm reboot, it opened with an "illegal FTGW.INI file" error message.

Upon viewing the FTGW.INI, I found it was not a normal Windows "ASCII text" file, but a binary file of some type proprietary to FormTool, so CleanSweep had not tried to modify it for new filepaths. When Formtool started the first time on HAL, and found incorrect filepaths, it created a new default FTGW.INI.

Now all I had to do was change the FTGW.INI for HAL's environment by using the "Settings" dialog from within the FormTool application. That done, FormTool Gold was removed from P2.

Microsoft FoxPro v2.6:

Using CleanSweep, Microsoft FoxPro v2.6 for Windows was removed from P2 since the application had been working well on HAL for a few months.

METZ Phones v5.02:

4:21 PM 9/16/97 Using CleanSweep Transport, The METZ Phones address book database application was moved from drive C: on P2 to drive D: on HAL, but the same difficulty arose that afflicted the AutoCAD LT transport. When tested, the METZ Phone help system started instead of the phone book, and there seemed no way to open the application, but I'm getting ahead of myself here.

I noticed after the transport was complete that the METZ Phones icon on HAL's Desktop was different than the one on P2's Desktop. It had a blue question-mark superimposed on it that P2's icon did not have.

CM: I was not ready to try METZ phones yet, because some more setup work had to be completed that I knew CleanSweep could not have taken care of.

First, I checked the "METZPHO.INI" in HAL's "C:\WINDOWS" subdirectory. How did I know METZPHO.INI was there? CleanSweep Transport keeps a detailed list of the files it's transporting, so you can see what is going on. You can also tell CleanSweep not to move certain files, etc. The METZPHO.INI is an ASCII text file (not like FormTool Gold) so CleanSweep Transport actually changed some of the drive designations in it from "C:" to "D:".

The METZ Phones application is actually a front-end interface used to manipulate a Borland Paradox database. In the case of our company system, the main phone database is located on "Old Blue", the file server. On P2, and other workstations on the network, this database is accessed by an Invisible LAN "shortname" mapped to drive "Y:". HAL is not on the Invisible LAN network. He is on a Microsoft Network. The sad reasons for this "Byzantine" arrangement are painfully detailed in In the Trenches Cyberdate 04.19.1997 "Moving the HAL 9000".

Since Old Blue also had Microsoft Networking installed, as well as Invisible LAN, this was not a problem, only a few minutes extra work as I set up Microsoft Network "sharing" for the directory where the METZ Phone database was located on Old Blue and made a drive Y: "persistent" mapping for it on HAL. The METZ Phones program didn't know or care what network it was running on, only that it wanted it's data to come from drive "Y:".

Once I had the Y: drive mapping setup, I was ready to reboot HAL and try METZ Phones. That's when I found out that it wouldn't work. I wasn't ready to give up as easily as I had with AutoCAD LT though.

I started the Windows Explorer file manager on P2 and compared P2's METZ Phones program directory (C:\METZPHO) with HAL's (D:\METZPHO). Oddly enough, some file dates were different as well as icons. I decided on a direct copy of the files on P2 to HAL (replacing the changed transported files). After the copy operation, HAL was warm-booted.

This time the METZ Phones icon on HAL's Desktop matched the one on P2, and, when opened, started the METZ Phones interface in the normal manner. Ah! Little successes . . . that's what I live for.

Proximity Technology, Inc.'s Friendly Finder v4.1c:

4:46 PM 9/17/97 Friendly Finder, originally published by Proximity Technology, Inc., is based on their "fuzzy" database search technology. Using CleanSweep Transport, the Friendly Finder vBase application was transferred to HAL. This is very similar to the METZ Phones application in operation.

Friendly Finder is an old " legacy" MS-DOS program. It is a query front-end for dBase "DBF" files. The architectural firm I work for uses it mainly for a quick way to look up project information for the 1200 plus jobs we've started here in the last fourteen years. The entire application is located on Old Blue, including the database table file. This is a nice, simple little program that anyone in the office can use. It works on all the machines: DOS, Windows 3.x and Windows 95/98/NT. In Window 3.x and Windows 95/98/NT it opens up in a MS-DOS window on the Desktop.

The only file that CleanSweep Transport brought over was a "PIF" configuration file. Like METZ Phones, "sharing" for the Friendly Finder subdirectory on Old Blue and a "persistent" drive mapping to drive U: had to be setup for HAL. For those of you who are starting to wonder what a "persistent" drive mapping is, it is simply a drive mapping that is established automatically every time Windows starts . . . it is persistent. Once this was done, HAL was warm-booted, but the vBase icon did not show up on the desktop.

I opened the Windows Explorer file manager and searched HAL's drive C: for "VBASE.PIF". It was found and I right-clicked on it to copy it to the "Clipboard". Then I right-clicked on HAL's Desktop and created a shortcut from the Clipboard's contents. I double-clicked the new vBase icon and Friendly Finder on Old Blue tried to open, but produced the error message "Can't open file FFIND.HLP". Right-clicking the vBase shortcut icon and choosing properties, then the "Program" tab in the Properties dialog revealed that the "Working" directory field was wrong. Typing "U:\FF" in this field and clicking the "OK" button fixed the shortcut so it would work properly. The directory U:\FF is where all the Friendly Finder files are as far as HAL is concerned.

Clear Software, Inc.'s allCLEAR for Windows 3.01:

7:13 AM 9/18/97 allCLEAR was transported to HAL using CleanSweep. Again, and it was not a clean process. After the transport had been installed on HAL, and he was warm-booted, allCLEAR was initiated from the Windows 95 Start Menu. The following error message appeared: "System has been damaged. Check A3W.INI and allCLEAR subdirectory."

I found the A3W.INI file using Windows Explorer file manager and opened it up for viewing. Once again, CleanSweep had correctly changed drive designations from "C:" to "D:" and everything else seemed to be in order. Like I did with METZ Phones, I decided to perform a direct file copy of the allCLEAR directory and it's subdirectories and files from P2 to HAL, replacing the transported files. After the copy operation, allCLEAR worked just fine on HAL.

MISREP: I believe CleanSweep Transport is doing just fine in the tasks of moving required files to the Windows directory and making proper changes to configuration files and the Windows 95 Registry. It seems to "screw-up" what seems to me the easiest part of the job, transporting the program files and subdirectories.

CleanSweep v3.0 has an Internet update feature. I think I'll visit the QuarterDeck site before I use it again to find out if this anomaly exists in the latest version.

There's still a lot of work to be done to P2 and that will be reported on later. In the meantime, next week, I'll have to make time to put out some brushfires smoldering elsewhere.

LAROKE Microcomputer Consultants
155 East Boca Raton Road
Boca Raton, Florida 33432
(561)368-0659 (Tel & Fax)

Issued Saturday September 27, 1997

Updated Wednesday May 19, 1999

copyright © 1997-1999 LAROKE Microcomputer Consultants all rights reserved

Search www.laroke.com the Web for