APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Filepro conversion

In years past, I did a lot of Filepro programming 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.

If you have an old app and need a Filepro programmer, I can help.

Got something to add? Send me email.

1 comment

Increase ad revenue 50-250% with Ezoic

More Articles by

Find me on Google+

© Anthony Lawrence

Fri Jul 28 05:01:42 2006: 2292   BigDumbDinosaur

This story reminds me of a similar experience I had with a client in the mid-1990's (they're still a client, BTW). This client was running on an MAI Basic Four minicomputer system they had purchased back when Alan Shugart was sketching out plans for a 5-1/4 inch floppy disk drive (see (link) The B4 system had been reliable over the years but it had its limitations, such as each task being allowed to have a maximum of eight open files, including one opened to the user's terminal. Performance wasn't anything about which to get excited, either. As time went on, it became increasingly clear to the client that the B4 system had to get replaced, especially since Year 2000 issues could not be resolved in this system. The question was: replaced by what?

For those readers who may not be familiar with some of this ancient computing machinery, MAI (Management Assistance Corporation) was a builder of minicomputers that included a resident BASIC interpreter. The original BASIC dialect (called BB4) was essentially the 1964 Dartmouth version, with extensions to handle indexed file I/O, as well as detailed terminal control (e.g., clear screen, address cursor, etc.). The product was a fully integrated system of minicomputer, terminals, printers and a diagnostic modem. Tens of thousands of these systems were sold and a few are still in active service (I personally know of at least one). Vertical applications for almost every type of business known to mankind were written to run in MAI's BB4 language.

However, the system had many limitations beyond the number of files that could be opened. Due to very tight integration between BB4, the underlying operating system (which was nothing like anything we'd use today) and the hardware, upgrades were a complicated and expensive process. In particular, the use of bit-sliced processors in the earlier Basic Four boxes made upgrading all but impossible -- you had to replace the machine to upgrade it. Also, only the final versions built in the early 1990's could be made Y2K compliant -- these were SCO UNIX 3.2v4.x powered, running on AMD or Intel hardware.

Anyhow, when my client decided it was time to retire the B4 system, we recommended that they switch to SCO OpenServer. So as to avoid having to rewrite all of their custom-developed software scratch, we also recommended that the Thoroughbred Dictionary IV package be loaded on the new machine. Thoroughbred is a widely used integrated language/database development package that is essentially a superset of the BASIC language and file handling implementation of the Basic Four system, and is available for all UNIX and Linux flavors, Windows and Novell Netware. It's similar to Filepro, except code and data are completely portable to any hardware/OS combination that Thoroughbred supports.

In this case, the UNIX/Thoroughbred combination was the logical route to take, and in 1996 my colleague and I made a presentation to the client to that effect. Incredibly, the business owner's son, whose knowledge of computers was limited to what he had read in PC Magazine, objected to the use of UNIX -- it was "obsolete," according to him -- and somehow convinced his dad to go with Windows (95 OSR2.1 at the time).

Over the next 18 months, we regularly got calls about Error 7, which was the error code in Thoroughbred for a corrupted file. This would occur because the record locking semantics used in Windows didn't work worth a damn (they still don't work right to this day). In some cases, one user would be modifiying a record that supposedly had been locked and meanwhile another user would somehow get control of the same record and step on the changes made by the first user. All too often, bi-directional links in the keyblock area of the affected file (this part was structured as a B-tree index for the purposes of retrieving a record by key) would get mixed up and we would have to read out the file contents a record at a time, construct a new key and then write a new record into a different file. Needless to say, this was a tedious process.

None of this nonsense ever happened in the old Basic Four environment, and of course, wouldn't have been an issue at all in UNIX. However, with Windows it was a weekly occurrence. Finally, after countless phone calls for help and lots of modem time, the owner ordered us to replace Windows with UNIX and, where possible, install dumb terminals (Wyse 160s) in place of the PC's running Windows. We did and that was the end of file corruption problems.

Kerio Samepage

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

Don't get suckered in by the comments … they can be terribly misleading. (Dave Storer)

Java is the most distressing thing to hit computing since MS-DOS. (Alan Kay)

This post tagged: