COBOL variable table size

Question

When I need to load a variable number of records into a table, I generally use one of three approaches:

1. Guess a maximum size for the table ("MAX-TABLE-SIZE"). Make the table OCCUR 1 TO MAX-TABLE-SIZE TIMES DEPENDING ON INPUT-FILE-RECORD-COUNT. Count the number of input records while loading them to the table. If the number of records in the input file is greater than MAX-TABLE-SIZE, display the table size needed and STOP RUN. Then manually recompile the program with a higher value for MAX-TABLE-SIZE and rerun the program.

2. Use two programs. The first one counts the number of records in the input file, writes a second source code file with the necessary MAX-TABLE-SIZE, compiles the second program, and executes the second program. This approach avoids manually rerunning the program, but takes longer because a compilation is always needed.

3. Write data to a file, rather than to a table. Then the data can have as many records as available disk space allows. If no longer needed, delete the file at the end of the program. This approach avoids needing to recompile the program for larger data, but reading from and writing to disk is slower than using an in-memory table.

Are there other techniques in COBOL for handling a variable number of records? What are their advantages/disadvantages?

Answer 1

Unless performance is known to be an issue, you cannot improve on (3). The first two have too much overhead & manual handling for use in production software. Today's hard drives do an excellent job of caching data and performance should not be a problem in most circumstances.

If you absolutely MUST read the records into memory, your best shot (and what used to be done routinely) is to estimate the number of records you'll need and increase it a lot so that most of the time it will require only one run and no recompilation. If you error out, then you'll have to increase the table allocation. It would take a LOT of performance consideration to make this method preferable to (3) just on the basis of lousy programming/design technique.

These are essentially your options. If you want to provide more info on what you're trying to accomplish there could be further suggestions... GLTY.

Answer 2

As @RegularExpression said, options 1 and 2 should be avoided if at all possible. I do not general solution apart from 3 (note: as well as an index file a temporary (local ??) DB Table could be used). In most cases this option will be fast enough.

There are several solutions that will work in specific cases

1. One or more sort merges (i.e sort input files on a common key and merge the files) is often the most efficient and can be used in most batch programs. It will involve rewriting the existing code, having a series of small programs and uses more disk spaces. DB's can be unloaded if necessary (or for SQL DBs you can use the order by).

2. Use a option 3 but have a small table in memory. The design of the in memory table is case specific.

   • I once worked on a personel system, while the system held thousands of rosters, 99% of people at the company worked rhe standard 40 hours per week roster. In this case a 2 element last used table worked wonders.