How could this be an open-ended table? This is the structure that’s named in the CEEGTST and CEECZST service invocations so it must be a table, right? It is. Here’s where a revision to traditional COBOL-think is required.
The program maintains a running count of the number of overflow entries. As soon as it detects the first overflow, it invokes CEEGTST to acquire a single 80-byte piece of storage. If there was only a single overflow, then everything would match the logical perceptions of traditional COBOL. That would be a non-repeating, single-value field with a length of 80 bytes storing a single extra overflow record.
If a second (and third, fourth and so on) overflow is encountered, the program logic shifts to using the CEECZST service to enlarge the previously acquired storage area. The previously acquired storage will be of a size that will always be evenly divisible by 80; i.e., 80, 160, 240 and so on.
After every invocation of CEECZST, the two statements shown in Figure 3 will always return with the address of Overflow-Input—the single 80-byte field in the Linkage Section—pointing to the most recent 80 bytes of CEECZST-acquired storage.
Note that the Set Address of COBOL syntax allows only an Oh-One-Level’s address to be set. In fact, the fields named Overflow-Input and Overflow-Table will always have the same address.
After the input file reaches end of file, the program determines how many fixed entries appear in the standard COBOL table—there’s a maximum of five entries—and then displays them.
If there are overflow entries, they’re also displayed. The inline Perform that displays the overflow entries isn’t as COBOL-centric as the one that displays the fixed entries. Here’s what the logic to display the overflow entries does:
• Before the loop is entered, the currently saved starting address of Overflow-Input is set. This will point to the first overflow entry. The work pointer Storage-Adr is also set to the currently saved starting address.
• Within the loop, after the Display, the redefined pointer item Storage-Adr-Fullword is incremented by the Length of Overflow-Table (80 bytes).
• After incrementing the pointer, the address of Overflow-Table is set to the incremented pointer.
In other words, the address of the item named Overflow-Table is continually being changed so it points to the current entry. While this looks odd in COBOL, the program is meant to demonstrate one use of COBOL pointers. Becoming accustomed to manipulating the addresses of memory structures is required to become proficient with pointers.
Figure 4 contains sample JCL to run the TABLETST program.
So, why not use this method for all tables? That’s a fair question, but we don’t recommend doing so.
COBOL has excellent table handling built right into the language. In fact, when an index is declared on an Occurs structure—Indexed By—the index is actually a pointer data item. Indexes declared on tables are internally translated to run-time addresses based on length and displacement into a given table. This is why an index declared on one table is only valid for the table for which it was declared.
There are many more uses for COBOL pointer items—some involve interfacing with LE service calls, some don’t.
By combining LE’s robust set of callable services with the best new syntax features of modern enterprise COBOL, the venerable old language proves that it’s a full-fledged LE power player.