How To Create A Data Filing System

Part 4: The Main Program

Jim Fowler

In the final installment of this series, the author looks at ways to approach the overall logic of a final system. Safeguards and auxiliary programs are also discussed.

Now you have most of the detail work on your data file system finished. You know what kind of files you want and how they are formatted. The nature of the output functions (and searches) has determined the coding and index files needed, and this has pretty much dictated the input part of the program. Now we're ready to put it all together.

Make It Modular

You probably already know the advantages of writing programs with lots of subroutines, each doing a single task. In data filing systems this advantage is particularly obvious. A subroutine to input a string from a particular device is much more useful than one to input a string from the keyboard and another to read a string from the disk. That subroutine can be used in other subroutines, to input an author's name, and again to input the title of a work, the date of publication, and so on. The subroutine to input an author's name and encode a part for the index file can also be used to input a key used to search for a particular author. This can go on and on. Whenever possible, make subroutines so all-purpose that they can be called throughout the program.

In the accompanying flowchart, I have illustrated the design for my author-subject file of books and articles. How you want your data displayed, what you want printed, and what you want on the screen will depend on your individual situation. Some people want a printout of their input as well. It is also easier for some people to proofread text on paper than on a screen, so customize it for your needs. Your requirements will differ from mine, so your flowchart will be different, too. However, you probably should use subroutines in a modular fashion.

Preventing Disaster

You should include fail-safe methods to prevent disastrous errors. For instance, suppose you have just finished entering a hundred records and you turn off the system without saving the index files. This disaster breaks down into two problems: reminding the user to save the file before quitting, and reconstructing the lost files from the data on disk in the main records. Both are easy to solve, but you must solve them - preferably in advance. Even if your method of reconstructing files is crude or your warning to the user lacks elegance, the important thing is to have these provisions in the program.

You cannot prevent certain disasters, although you can reduce the seriousness of the damage. These include a power interruption, hardware failure, or a bad spot on a disk. To minimize the damage from these troubles, you need good operating procedure. For data files, this means making backup copies frequently. You could, for example, make backup copies after every twentieth entry into the file, then put a counter in the program. When it "goes off," have the program tell you to insert a disk into drive X and "press return" - and there is your backup.

Satellite Programs

You may find, as I did, that you will need one or more other programs to augment your data file system. For example, you probably will have to write a program to prepare the disk for the records to be written. It should allocate (and fill with nulls) perhaps one thousand relative records. These nulls (zeros) are then replaced as real data is written into the system. A program that does this is a satellite program. It is not part of the main system program, but has no function except in that system. You can simply include this program on the same disk as the main program where it is handy.

I had to create a satellite program when my main data file forced me to make a second data system. Many of the records I entered were titles of magazine or journal articles. There is no point in spelling out The Journal of Embryology and Experimental Morphology when everybody in the business knows it as "JEEM." Every periodical has an official abbreviation, but how to remember them all? I had to make a dictionary of journal names and their abbreviations. Of course, that meant another data file. If I had had the foresight, I could have incorporated the dictionary into the main system. Fortunately, my half-megabyte disks have lots of room, but I really do not need a second system with its files and program when it could be ancillary to the main one. Maybe you will think far enough ahead and avoid the rather clumsy solution I had to adopt.

As we've stressed throughout this series, ingenuity, careful planning, and foresight are the key ingredients to a good system. Although it may be frustrating at times, writing the system is almost as worthwhile as using it.