Sections

Declaratives require you to use sections, but these cases should be rare. In older dialects of Cobol, the SORT and MERGE verbs require sections for input and output procedures. COBOL II and later releases have removed this requirement.

Apart from these exceptions, sections are completely unnecessary in the PROCEDURE DIVISION.

If a section contains only a single paragraph, you might as well use a paragraph (except as noted above). If it has more than one paragraph, then you need a GO TO or fall-through logic to exit the section.

On older, smaller machines, partitioning a program into sections could supposedly improve performance through the use of overlays. On today's monster mainframes this consideration is not likely to be important. Conceivably, the use of sections could even reduce performance, depending on how the compiler implements the call-and-return mechanism.

The only remaining reason to use sections is to chop up spaghetti code into smaller, more manageable platefuls. It's better not to write spaghetti code in the first place.

Duplicate Paragraph Names

In the absence of sections, no two paragraphs can have the same name in the same program. The rules change when you use sections: paragraph names need be unique only within each section.

Duplicated paragraph names invite confusion, especially if you duplicate them without realizing it. If two paragraphs have the same name, they probably do similar things, and contain similar code. It would be easy to apply a change to the wrong one, or change only one when both need to be changed.

All Sections, No Paragraphs

I once maintained a package which followed an interesting convention: there were no paragraphs. Whatever I would have coded as a paragraph was a section instead.

This custom allows you to reap the performance benefits of sections (if there are any) without sacrificing sound structure. However, it entails a subtle but serious danger.

Suppose I code two successive sections: 2900-OPEN-FILE and 2910-CLOSE-FILE. Or at least, I intend to, but I absent-mindedly leave the SECTION keyword off of 2910-CLOSE-FILE.

When I PERFORM 2900-OPEN-FILE, execution falls into 2910-CLOSE-FILE, due to the missing SECTION keyword. It doesn't return until it reaches the next section header at, say, 2920-VERIFY-SORT-SEQUENCE.

Sooner or later I just know I'm going to forget to type SECTION. The resulting bug will probably be perplexing, because I don't pay much attention to humdrum stuff like section headers.

A Dissenting Opinion

David Rennie writes:
As a long time COBOL programmer I disagree with your argument against using sections. I strongly prefer a system which uses an alphanumeric numbering system like this: 
A000-MainProgram Section.
A000-P1.
    PERFORM B000-INITIALISATION
    do  some stuff here.
    PERFORM B900-FINALISATION 
    STOP RUN.
A000-END.
This system provides a strong structure for the program with higher level code calling lower levels.The use of the standard paragraph names -P1 and -END to bracket the section are extremely useful devices when using the primitive debuggers on large systems. It is much easier to SET BREAK A000-END than try to remember the name of the next paragraph when you wish to avoid stepping through a routine. Using this section and paragraph numbering system it is also easy to see when a section name has been missed as only sections have long names. If I want to find the beginning or end of a section it is simple compared to the difficulty in finding the end of a 600-900 line paragraph.
I've never tried an interactive debugger with COBOL, mostly because the debugger in our shop has a reputation for being a real pain to set up. It always seemed easier just to stick in a few DISPLAY statements at critical places.

As a result, I'm not sensitive to the ways that coding style may affect the use of a debugger. However, if the debugger forces you to adopt bad coding practices, that's a good reason not to rely on the debugger.

It may indeed be difficult to find the end of a 600-900 line paragraph. The solution is not to add superfluous labels, but to write shorter paragraphs. A long paragraph will be hard to maintain in any case, no matter how easy it is to find the end of it. (Exception: when it is stereotyped and repetitious, such as a long series of MOVE statements.)

Mr. Rennie continues:

The use of an alphanumeric numbering system also makes it extremely easy to make global changes if the structure of the program changes. Altering a straight numeric system is much more difficult.

We use a system which reserves levels A to L for unique program logic, M-R for functions which are repeatedly called within a single programs, S level for file IO, T for software system-specific subroutines, U-Y for generic subroutines, Z for Hardware Specific routines.

Working storage is grouped to match the subroutines below S; e.g. working storage area W101- matches Subroutine T101-. The files storing these subroutines and working storage areas are named using the prefix; e.g. W101-dates.def contains the storage for the dates subroutines in T101-Dates.sub. When working with the system it becomes extremely simply to locate a variable or subroutine as the alphanumeric prefix immediately identifies the file which contains it.

Some systems will not allow the creation of filenames commencing with a number, preventing this facility if one uses a numeric naming system.

At least with the SPF editor I use, global changes are not an issue. If I want to rename 3279-EDIT-NAME to 3260-EDIT-NAME, I merely do a global change to "3279-". I may have problems if one of my data names contains "3279-", but data names like that are rare. In any case, similar problems can pop up with any numbering scheme.

Apparently Mr. Rennie uses copybooks in the PROCEDURE DIVISION, especially for accessing files, with corresponding copybooks in WORKING-STORAGE. In that case the argument for alphanumeric procedure names makes sense, at least for the procedures in copybooks.

I prefer not to use copybooks in the PROCEDURE DIVISION. If I want to reuse some logic in multiple programs, I'll put it into a separately compiled subprogram. This approach makes less work for the compiler, and reduces the chances of name collisions. However, in some systems, heavy use of separately compiled subprograms may create other problems. I've been told that in Unisys, each subprogram clutters up the operator's console as a separate process.

[home]COBOL Home [style forum]COBOL Style Forum