In years past, I did a lot of Filepro work. This goes way, way back: I worked on the first Tandy Xenix version when it was still beta – so beta that it couldn’t even do floating point math reliably!
I liked the product: it was fast (still is), partially relational, and had enough features to create decent applications. In the 80’s and 90’s I had quite a few Unix Filepro customers. Some were apps I developed, but most were things I inherited from other consultants. Over the years these slowly dwindled away.. better commercial software made home grown apps less necessary and less desirable.
I picked up a Windows Filepro customer a few years back and still have them. That they are running it under Windows put me off a little, but what the heck. Once in the FP code itself, there’s not a lot of difference.
As is so unfortunately typical of FP code, it’s pretty bad stuff. That’s not FP’s fault, maybe it’s not any body’s fault. The language doesn’t encourage bad programming, but it doesn’t discourage it either. However, the stuff basically worked. They wanted a few changes, so for the past few years I’ve added little stuff here and there. The last time I made any changes was about six months back, and that was just a new report to produce CSV files.
And then..
Sudden problems. Lots of lock file errors. Lots of indexes needing rebuilding regularly, big mess. Obviously couldn’t be from a recent code change because that was six months back. I looked at it all and felt it had to be a network or OS level problem. I and their Windows tech pored through a lot of logs and did a lot of debugging type tests but could not isolate anything suspicious.
Next, we contacted FP and hired them to look at the code – I really didn’t think this was the issue, but two sets of eyes are better than one, and the code is messy. The FP programmer agreed with the messy part, but still agreed with me that the nature of the errors indicated a network or OS problem. Nevertheless, he agreed to do some code changes to try to further isolate the problem.
He did clean up and streamline quite a bit, but the errors didn’t change. This was all extremely frustrating for everyone: the users, the tech folk, even the FP programmer; we were all unhappy. The management came back to me again and asked for another thorough sweep to see if we missed anything.
I made a different suggestion. Let’s move it to Linux.
I had several reasons for that. First, I felt it might just plain fix the problem. Linux and Unix are inherently multi-user, Windows had that functionality bolted on as an after thought. Changing the OS might just avoid the problem, but even if it didn’t, I felt I could deploy more and better debugging and analysis tools on a Linux platform.
So we commandeered a unused Windows desktop and I installed Suse 10.1 on it. We got a demo license from FP, and I installed the Linux version. I had some difficulty, but FP was very helpful: Ray, the programmer who had been cleaning up old code, was taking a day off when I sent email explaining my installation difficulty, but called me right back and helped me get everything in place manually. Now all I had to do was convert the Windows data.
This is a place where Filepro is a little weak. You’d think that they could easily have had complete independence, that Windows and Linux or any other platform would only need appropriate binaries and you could just copy over the data files. That’s not the case, though. They do provide (at cost) a FpTransfer program that you have to use. Originally designed for serial communication, it understands nothing of networks but fortunately can output to and read from a file. That’s the way I used it, transferring the files with scp and then restoring them with FpTransfer on the Linux side. That took most of a Sunday, and I set up a few users for testing on Monday. I did rebuild all indexes and there were a few minor menu problems to straighten out, but basically the system was ready for testing.
And the testing went very well. The users were able to “crash” the Windows system at will: all it took was a few of them simultaneously entering and looking up orders and the problems would pop up within minutes. On the Linux box, however, they could not break it: no errors manifested.
So, things were looking good. Until.. well, this is long enough for today. I’ll finish the story tomorrow.
*Originally published at APLawrence.com
A.P. Lawrence provides SCO Unix and Linux consulting services http://www.pcunix.com
