COBOL variable table size

0
votes

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?

2
cobol
Why would you need to load a large file into memory ??? - Bruce Martin
Valdis, sorry, but although interesting,this is off-topic for Stack Overflow. You've come up with three yourself, there's really already several more in the two answers, and I have some agreement with the existing answers and some disagreement. Try to find somewhere which is for the specific COBOL you have, and ask there. - Bill Woodger
As @BruceMartin points out in a comment on his answer, if you have a specific situation, you should be able to formulate an on-topic question on the basis of that. If it is just a general question, it is just not for here. - Bill Woodger
This was a general question. Although "off-topic" for StackOverflow, the answers were very instructive. Thank you. - Valdis Grinbergs
Well, I disagree with the answer you accepted, and there are lots of other things. I was hoping you were going to say GNU COBOL, as they have a discussion area. - Bill Woodger

2 Answers

1
votes

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.

1
votes

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.