Reasons for Subprograms

There are several reasons to create subprograms. More than one may apply in a given case.

Make Programs Smaller

Traditionally, COBOL programs tend to be large and monolithic. Such big programs are hard to read and harder to maintain. For unusually large load modules, it is useful to break out the major functions into subprograms of a more manageable size.

For example, one part of JOCKEY is a huge load module, but the topmost level of code is only a few hundred lines long. It calls one subprogram to fetch an input message. Depending on the type of message, it calls another subprogram to process a completed order, or still another to cancel a previously completed order. With a little more code it starts itself up, shuts itself down, and handles error conditions. Most of the work is done by the subprograms, which are relatively isolated from each other and from the topmost module.

In order to make this strategy work, you must find a good way to carve up the application. Each subprogram should be able to do a well-defined job without interacting much with its parent program.

Make Code Reusable

If you find yourself writing the same code more than once, consider burying it in a subprogram, especially if: Some subprograms are highly specialized, reusable only within a narrow sphere. For example, the JK496 program provides an interface from JOCKEY to another application (on another box) through an LU6.2 connection. It is used in only two places.

Other subprograms are highly generic, and can be reused repeatedly, not only in JOCKEY but also in other applications. For example, JOCKEY contains some generic routines for managing dynamically allocated memory. Almost any application could use them (though so far I haven't had any success in attracting converts).

When you write good reusable code, you need only write it once. From then on you can invoke it from any program which can use it. You save time coding in the future and you reduce the total amount of code.

Build Firewalls Around Change

In any application, some parts are are more volatile than others. Consider isolating the most volatile parts in subprograms. Then changes will be easier: first because you only need to change one program, and second because that one program is small and simple. You still need to identify and relink all of the relevant load modules (unless the subprogram is called dynamically), but you would have to do that much anyway.

(This strategy can backfire. If a change requires that the subprogram know something that it doesn't currently know, then you have to change its interface, and make corresponding changes to all the programs that call it.)

Encapsulate Data

Many programs use lookup tables in WORKING-STORAGE. They load each table from a file and then perform searches against them. Even when the logic is routine, it is tedious to code. Often it has to be peculiar or complex.

Lookup tables are good candidates for subprograms, for all the reasons discussed above. In addition, a subprogram can make the data available to other subprograms, as well as to the main program.

For example, one utility module in JOCKEY loads so-called environmental variables into its own WORKING-STORAGE. Any module in the load module can query the values of these environmental variables. In effect they become global variables. Though global variables can be abused, they can also be useful.

Subprograms may encapsulate data structures other than arrays, such as linked lists or trees.

When subprograms encapsulate data, the calling program needn't know anything about the physical format of the data. It needs only a few well-defined operations for accessing the data.

homeCOBOL Home [style forum]COBOL Style Forum