COBOL-aware middleware

Two phenomenons with opposing effects have affected COBOL structures over time.

The first one is a tendency to construct complex data structures with many fields. This would allow to store a maximum amount of information in a VSAM record or database segment for instance. This was an important factor in reducing physical I/O and getting the best performances possible. When data structures were passed from program to program, they also tended to be large structures because developers would typically try to reduce the number of programs and hence, would rather write big programs that handle many cases than many smaller programs.

When the mainframe opened up to program to program communication over networks though, these large structures became a problem because networks were slow. So the next tendency was to try to find ways to reduce the size of the data sent over the network even if the structures stayed complex and large.

The most widely used mechanism to reduce the size of the data is the variable size array (an array with the DEPENDING ON clause). This is a awkward type of array for people used to java and C. It is an array which actual size is given by a variable, appearing somewhere in the structure (before the array itself).

The second mechanism is not related to COBOL per-se but more with the middleware used. Because structures contain many fields, it often happens that these fields contain default values. For instance, alphanumeric fields might contain binary zeros, which is usually interpreted as "no content". If the middleware is smart enough, it can avoid sending these non initialized fields over the network thus saving a lot of bandwidth.

Variable size arrays also need to be handled correctly by middleware. For instance sending the maximum number of items would be wasteful. A more tricky situation arises when the middelware invokes a mainframe program that returns a variable size array. Often, the memory needed by the target program to operate must be allocated beforehand by the middleware. But how can the middleware anticipate the number of rows that the program will return?

As you can see there are good reasons why middleware used to communicate with mainframe programs need to be COBOL-aware.