LinkExchange Network
You are here: HOME > TRENCHES INDEX > CYBERDATE 09.27.1997
Site Map

Log Index
Previous Log Entry
Next Log Entry
Christophers Napkin Sketch by Al Gleichman

In the Trenches with LAROKE

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

    Situation Report
    Take Charge And Move Out
    United States of America
  • CM
    Configuration Management
    Mission Report
Previous P2 Articles:

Cyberdate 09.20.1997 A typical week of headbangers

Cyberdate 06.28.1997 Restoring a Flash BIOS Meltdown

Cyberdate 05.03.1997 Feeding Softwarez to HAL 9000

Cyberdate 04.12.1997 Case of the Phantom Printer

Cyberdate 02.24.1997 Where's my !@#$% FONT MENU??

Later P2 Articles:

Cyberdate 10.11.1997 P2's transformation slips into high gear

Cyberdate 10.25.1997 More fun with P2, HAL and 4-Bits

Cyberdate 11.08.1997 P2 and 4-Bits - Light at the end of the tunnel

Cyberdate 12.06.1997 P2's configuration suffers a relapse

Cyberdate 12.23.1997 Re-glazing P2

Cyberdate 02.04.1998 P2's lobotomy recovery

Cyberdate 02.23.1998 Moving P2 is as much fun as pulling teeth

Cyberdate 01.28.1999 Countdown to midnight Part I - Y2K Preparations

Cyberdate 04.14.1999 Countdown to midnight Part II - Y2K Preparations

Previous HAL Articles:

Cyberdate 09.06.1997 Kurrent Konundrums debut

Cyberdate 08.23.1997 When we last left our hero, HAL..

Cyberdate 06.14.1997 When it rains, it pours

Cyberdate 05.17.1997 HAL's softwarez feeding frenzy continues

Cyberdate 05.10.1997 HAL gets more software

Cyberdate 05.03.1997 Feeding Softwarez to HAL 9000

Cyberdate 04.19.1997 Moving the HAL 9000

Later HAL Articles:

Cyberdate 10.04.1997 Putting out brushfires

Cyberdate 10.11.1997 P2's transformation slips into high gear

Cyberdate 10.25.1997 More fun with P2, HAL and 4-Bits

Cyberdate 10.28.1998 HAL proves that even IBM can make a lemon

Cyberdate 01.28.1999 Countdown to midnight Part I - Y2K Preparations

Cyberdate 04.14.1999 Countdown to midnight Part II - Y2K Preparations


Autodesk, Inc. AutoCAD LT cad software

IBM Corporation IBM Aptiva Stealth PC

IMSI FormTool

Inprise Corporation (formerly Borland Corporation) dBASE 5 for DOS

METZ Software, Inc. Metz Phones v5.02, v6.01

Microsoft Corporation Windows 3.x, Windows 95 operating systems, Microsoft FoxPro v2.6, Visual FoxPro DBMS

Proximity Technology, Inc. Friendly Finder dBase file query utility.

SPSS, Inc. allCLEAR flowcharter software (formerly published by Clear Software, Inc.)

Symantec Corporation CleanSweep (formerly from Quarterdeck before Quarterdeck ceased to exist under the Symantec Corporate Banner)


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.

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.

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)
(goto workarea 1)
(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)
(move to the next record in the reimbursables table on P2)
(move to the next record in the reimbursables table on HAL)
(...and process the next record)
(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.

== UPDATE ==

Cyberdate 05.17.1999
Database Update
Since this article was first written, I've discovered an even bigger database faux pas than the example above with the reimbursables database tables. This time the company timesheet database tables were involved.
I've been carefully maintaining employee timesheet data since 1986. The first records were originally entered in an Apple II database program called AppleWorks with the data stored on 5.25" floppy disks. I painfully translated that data to an IBM/MS-DOS environment in the late eighties using a "Transporter" adapter card (basically an Apple II processor on a card) installed in a IBM AT computer. The new DBMS I translated the data to was DacEASY Base (a dBase II language clone). This database was eventually imported into our current dBase/FoxPro system.
You see, I've been at this a long time. We keep timesheet records accurate to one-tenth hour (six minutes), or at least we used to. I made the same mistake with the timesheet dBase V table structure that I did with the reimbursables by truncating the field to whole hours. I caught the timesheet problem early on before any damage was done (I thought).
Around the same time I was doing this quick-n-durty programing, the main timesheet database was corrupted by a power outage or other outside influence I can't remember. I do remember I had to restore from backup tape. What I didn't know at the time is that the database restored from tape had the truncated hours field.
By the time I realized my error many months had passed and the backup tapes overwritten. The result is that we no longer have timesheet data to the "right of the decimal point" for many years of past data. That's the bad news. The good news is that after running a few reports, I discovered that the decimal data had been rounded when forced to whole hours, not truncated. Not much of a consolation but better than nothing.

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.

== UPDATE ==

Cyberdate 05.18.1999
FormTool Update
This version of FormTool has never worked very well in HAL's Windows 95 environment and until recently I've only been using it to update one document each week.
8:55 AM 3/29/99 Due to the network mapping breakdown between Old Blue and Johnny Mnemonic during Saturday's backup ops and the subsequent renaming of Old Blue to "Old_Blue", HAL's printer mapping to the TI Microlaser no longer works. The printer was removed from the Printers Folder and HAL rebooted. A new HP Laserjet II printer was installed and tested with the microlaser. OK!
Formtool Gold lost its mapping to the Microlaser as a result of the above and now insists on printing to the IBM RingCentral FAX applet. I attempted several times to change the printer using FormTool's "Printer Control" but got a fatal error every time for my efforts. This is a nominal Windows 3.x application that I continue to use for only one document which can be easily duplicated in a spreadsheet program, so I have decided to retire it rather than spend a lot of time trying to fix it. Uninstalled FormTool Gold using CleanSweep Deluxe.

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.

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.

== UPDATE ==

Cyberdate 05.18.1999
METZ Phones Update
Our office has upgraded to METZ Phones v6.01 since this log entry was written (current version is METZ Phones Pro v8.01) and we are well satisfied with the application.
We upgraded for Web browser and E-mail client support. The older version already supported interaction with our WordPerfect word processing applications. METZ Phones places a macro icon on the WodPerfect Toolbar during installation. When you are composing a document in WordPerfect, you can click the METZ icon which will bring up a list of records in the METZ phone database. Selecting a record and then the "Paste" button will paste the record's recipient and address information into your WordPerfect document at the cursor location (a great timesaver for starting a letter to someone who is in the METZ Phones database). I also use METZ to print envelopes to the same recipients.
Version 6 added Web URL address and E-mail address fields to the METZ Phones database structure as well as provisions for several user-configurable fields. When viewing a METZ Phones record, if you click an E-mail address in the record, your e-mail client will be started (MAPI compliant clients only) and a new message dialog will start with the selected e-mail address already inserted in the "To:" field.
Likewise, if you click a URL address link in the record, your Web browser will be started and you will be taken to that site.
METZ Phones gives us a common network address book database capability without the expense/complexity of a Microsoft Exchange Server installation.

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.

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.


Site Map

Log Index
Previous Log Entry
Next Log Entry

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

HotBot Search for