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

Filepro spaghetti

© December 2007 Anthony Lawrence

Yesterday I wrote a review of a programming style book ("Implementation Patterns" by Kent Beck). Right now I'm reading a book about Xen and another on Web site performance optimization, and will have reviews soon, so we'll be moving away from programming for a bit.

But before we leave, I wanted to mention a bit of Filepro work I did yesterday. If you have no idea what Filepro is (no, it's not Filemaker), the Wikipedia entry will give you the basics, but what that doesn't tell you is how darn popular it was on Xenix systems. There was a lot of Filepro written in the 80's; I did a lot myself. As Wikipedia tells us, it was a "RAD" (Rapid Application Development) system, and I don't think the word "rapid" was ever more justified than it was there. You really could hack out useful apps in literally minutes.

However: the downside of Filepro was its weak programming language. When I first used it (1983, beta version on Tandy Xenix) it didn't even have gosub and it had severe problems with floating point numbers..and although it did get better and more powerful, its "if:then" base and extremely limited namespace for variables made for a lot of difficult and confused code. Some folks would even have worse to say, and I would not disagree. "Filepro programming" barely deserves the name.

But just the same, a lot of useful apps were developed (actually, I think "cobbled up" might be a better choice) in Filepro. Some of them still run today, and every now and then I get called to change something. That was the case yesterday. I've mentioned this before; usually these people don't want much.. the app has been working for years and changes aren't frequent. But the change they wanted yesterday looked a bit more difficult..

Remember, I didn't write this code. I'm not even going to complain about the person who did write it, because I have no idea what version of Filepro he or she started with - they may have done the best possible with what they had to work with at that time. Just the same, the code is a mess. Envision 900 lines of code like this:

If field 142 ="Y" then goto abc
If field 153 ="" and field 6="M" then field 144= field 147 * field 17; 
if field 153="Y" and field 144 > "17" then field 153="N";aa="0";dg="15"
if field 153="N" and field 144 <= 17 then af="13"; goto def

That's not actual Filepro code; believe it or not I made it easier to read! Want to know what field 142 actually is? Look it up. There are 348 fields in this database, six related databases each with field counts from a few to hundreds.. any time one of those is referenced, it's by number. Variables? Those are the "aa" and "dg" - two character names, not exactly descriptive. In later versions you could use longer names, but they were mapped to those two character names, so you were still limited and also had to be very careful not to overwrite your namespace.. bad, bad stuff.

So anyway, the change they wanted affected a total field. Under some conditions, they wanted it to include a field that was otherwise stated separately. But oh, my, the conditions. This field was set and reset in dozens of places in the code, and sometimes it would jump around sets based on some other field.. I couldn't follow it and wasn't about to rewrite 900 lines of code.

So, I took the cheap way out. At the end of the processing, I put in a "gosub" to a block of new code that tested for their conditions, reset things when appropriate, and then returned. It means that there are wasted tests and sets earlier in the code, but on the other hand if they come across conditions where this should not happen, I can quickly fix it in that subroutine. If I started messing with the earlier code, I could break all kinds of things.

I was thinking that our brains work the same way. We have "old code" (our so-called "reptilian brain") that new code (our conscious brain) overrules. Rewriting the old stuff probably would have broken it, so evolution just added on a new gosub.

I don't think my solution is "good code". It isn't. The "right" way to do this is to take the time to understand the whole process and rewrite (and probably not in Filepro!). But that way would involve weeks of work, maybe even months. It would be very expensive, and neither I nor the customer have any interest in doing that. The current system works, and we can keep hacking at it as needed.

Long live Filepro..

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

Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> Filepro spaghetti


Inexpensive and informative Apple related e-books:

iOS 10: A Take Control Crash Course

Take Control of the Mac Command Line with Terminal, Second Edition

Take Control of IOS 11

Photos for Mac: A Take Control Crash Course

Take Control of Numbers

More Articles by © Anthony Lawrence

Mon Jan 14 17:05:35 2008: 3478   anonymous

I work for a company that still uses Filepro and nothing else. You are very kind in your remarks about Filepro code. It is worse then you can imagine. We have processing tables that are over 3,000 lines, talk about hard to follow. What gets me is people still think this program can do anything/everything yet we can't seem to do anything and keep adding programs on top of it to make it print properly etc. It's horrible! I don't know why people keep saying it's fast. My experience shows it to be much slower than say MySql. I am also amazed that so many people build such large tables 348 fields. Why? I thought we were the only one's who did that. I guess it's because it's so hard to display information from other tables/databases in Filepro. Also hard to due lookups correctly. It just amazes me anyone still uses this broken down program. It hasn't changed much since the Tandy days.

Mon Jan 14 22:06:44 2008: 3480   TonyLawrence

No, you are not unusual.. I've seen a LOT of Filepro code and most all of it is really, really bad.

It is fast though.. in spite of all that..

Wed Jan 16 16:17:14 2008: 3488   BigDumbDInosaur

I haven't looked at FilePro in at least 15 years. Frankly, I never liked it for a variety of reasons and sure wouldn't relish having to work with it now. In the late 1980s, I switched all my RAD work to Thoroughbred, which had (still has) far more functionaility and power. I can't imagine any reason at this point in time intentionally using FilePro as a development tool. It is still pretty crude, in my opinion.

Wed Jan 16 22:07:49 2008: 3490   TonyLawrence

You won't get any argument from me!

Tue Feb 5 15:39:04 2008: 3588   anonymous

It's nice to know I'm not alone here. I think the reason people still use this program is because they're afraid to change. Pretty crude is a nice way to put it. I use it every day and I still believe that it has severe problems with floating point numbers or any number for that matter. If you want your computer system to be the way computers were 30 years ago then FilePro is for you. My company wants this so bad they are willing to spend hundreds of thousands of dollars for new equipment just to run FilePro. And yet they can't figure out why their reports never match and they can't do this or they can't do that. Just amazing. Thanks guys for making me not feel alone in a world where people think FilePro is the best program ever written.

Fri Feb 8 15:32:01 2008: 3608   BigDumbDInosaur

My company wants this so bad they are willing to spend hundreds of thousands of dollars for new equipment just to run FilePro.

Switch 'em to Thoroughbred Dictionary-IV. Far more powerful, math works right, much better support for modern page printers, more structured environment, good screen-driver support, etc. Since going with Thoroughbred in the late 1980s I've never looked back at File Pro.


Printer Friendly Version

Have you tried Searching this site?

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

Printer Friendly Version

Much to the surprise of the builders of the first digital computers, programs written for them usually did not work. (Rodney Brooks)

Linux posts

Troubleshooting posts

This post tagged:



Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode