|| Home |||Site Map |||Trenches |||Links ||
|| Konundrums |||Downloads |||Forum ||
|| Tech |||Toolbox |||Personnel ||
|You are here:||HOME >||TRENCHES INDEX >||CYBERDATE 09.27.1997|
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 "
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
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
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
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:
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
Upon viewing the
Now all I had to do was change the
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 "
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 (
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 "
The only file that CleanSweep Transport brought over was a "
I opened the Windows Explorer file manager and searched HAL's drive C: for
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: "
I found the
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
Issued Saturday September 27, 1997
Updated Wednesday May 19, 1999
copyright © 1997-1999 LAROKE Microcomputer Consultants all rights reserved