Why does COBOL have both `SECTION` and `PARAGRAPH`?

Question

Why does COBOL have both SECTION and PARAGRAPH?

Can anybody explain why the designers of COBOL created both SECTIONs and PARAGRAPHs? These have been around since the initial release of COBOL so I suspect the real reason for their existence has long since gone away (similar to things like NEXT SENTENCE which are still in the language specification for backward compatibility but no longer required since the introduction of explicit scope terminators).

My guess is that SECTION may have been introduced to support program overlays. SECTION has an optional PRIORITY number associated with it to identify the program overlay it is part of. However, most modern implementations of COBOL ignore or have dropped PRIORITY numbers (and overlays).

Currently, I see that SECTIONs are still required in the DECLARATIVE part of the PROCEDURE DIVISION, but can find no justification for this. I see no semantic difference between SECTION and PARAGRAPH other than PARAGRAPH is subordinate to SECTION.

Some COBOL shops ban the use of SECTION in favour of PARAGRAPH (seems common in North America). Others ban PARAGRAPH in favour of SECTION (seems common in Europe). Still others have guidelines as to when each is appropriate. All of this seems highly arbitrary to me - which begs the question: Why were they put into the language specification in the first place? And, do they have any relevance today?

If you answer this question, it would be great if you could also point to a reference to support your answer.

Thanks

Solution 1

No references on this, since I heard it passed on to me from one of the old timers in my shop but...

In the old COBOL compilers, at least for IBM and Unisys, sections were able to be loaded into memory one at a time. Back in the good old days when memory was scarce, a program that was too large to be loaded into memory all at once was able to be modularized for memory usage using sections. Having both sections and paragraphs allowed the programmer to decide which code parts were loaded into memory together if they couldn't all be loaded at once - you'd want two parts of the same perform loop loaded together for efficiency's sake. Nowadays it's more or less moot.

My shop uses paragraphs only, prohibits GOTO and requires exit paragraphs, so all our PERFORMS are PERFORM 100-PARAGRAPH THRU 100-EXIT or something similar - which seems to make the paragraphs more like sections to me. But I don't think that there's really much of a difference now.

Solution 2

I learned COBOL around 1978, on an ICL 2903. I have a vague memory that the SECTION headers could be assigned a number range, which meant that those SECTION headers could be swapped in and out of memory, when the program was too large for memory.

Solution 3

I know this is an old question, but the OP requested about documentation on the original justification of the use of SECTION as well as PARAGRAPH in COBOL.

You can't get much more "original" than the CODASYL Journal documentation.

in section 8 of the Journal's specification for the language,

"COBOL segmentation is a facility that provides a means by which the user may communicate with the compiler to specify object program overlay requirements"

( page 331, section 8.1 "Segmentation - General Description")

"Although it is not mandatory, the Procedure Division for a source program is usually written as a consecutive group of sections, each of which is composed of a series of closely related operations that are designed to collectively perform a particular function. However s when segmentation is used, the entire Procedure Division must be in sections. In addition, each section must be classified as belonging either to the fixed portion or to one of the independent segments of the object program. Segmentation in no way affects the need for qualification of procedure-names to insure uniqueness."

(p 331, section 8.1.2.1 "Program Segments")

In her book on comparative programming languages ("Programming Languages: History and Fundamentals", 1969) Jean Sammet (who sat on the CODASYL committee, representing Sylvania Electric) states:

".. The storage allocation is handled automatically by the compiler. The prime unit for allocating executable code is a group of sections called a segment. The programmer combines sections be specifying a priority number with each section's name. ... The compiler is required to see that the proper control transfers are provided so that control among segments which are not stored simultaneously can take place. ..."

(p 369 - 371 V.3 COBOL)

Solution 4

Cobol was developed in the mid-50's. As the full name alludes, it was developed for business programming, as being a language more relevant for business purposes than the existing "scientific" or "technical" languages (there were very few "languages" anyway, and "machine code" (specific, of course, to a particular architechture (I nearly said "specific chip", before thinking of vacuum tubes)) which may have to be set through physical switches/dials on some machines) and if lucky with an "Assembler". Cobol was very advanced for its day, for its purpose.

The intention was for programs written in Cobol to be much more like English-language than just a set of "codes" which mean something to the initiated.

If you look at some of the nomenclature relating to the language - paragraph, sentence, verb, clause - it is deliberately following the patterns ascribed to the English language.

SECTION doesn't quite fit into this, until you relate things to a formal business document.

Both SECTIONs and paragraphs also appear outside the PROCEDURE DIVISION. As in written English, paragraphs can exist on their own, or can be a part of a SECTION.

SECTIONs may have a priority-number which relates to the "segmentation feature". This used to include "overlaying" of SECTIONs to afford a primitive level of memory management. This is a "computing featuer" rather than an English-language one :-) The "segmentation feature" does have something of a remaining affect, but I've never seen it actually used.

Without DECLARATIVES (which I don't use, and have just noticed the manual to be unclear upon) then it is "choice" as to whether SECTIONs or paragraphs are used for PERFORM.

If GO TO is used, rationally, "equivalence" can be achieved with PERFORM ... TRHU .... If not, and there is not gratuitous use of PERFORM ... THRU ..., then there is equivalence already.

Comparisons to "structured" code and modern languages are "reading history backwards" or just outlining a particular "practice". From the reputation attained by "spaghetti code" and ALTER ... TO PROCEED TO ... it may well be that for 20 years it was "common" to not do much with PERFORM unless you needed the "memory management", but I have no references or knowledge to back this up.

SECTIONs allow duplicate paragraph-names, otherwise paragraph-names must be unique.

I can't put a specific finger on one over the other all the time.

If using GO TO, I'd use SECTIONs. If not, paragraphs. With DECLARATIVES I'd use SECTIONs. If using SECTIONs I'd start PROCEDURE DIVISION with a SECTION to avoid a diagnostic message.

Local standards may dictate, but not necessarily on a "modern" (or even "rational") basis. Much is "known" but actually misunderstood about SECTIONs and paragraphs, in my experience.

For performance (where masses of data is being processed, and I mean masses) then a PERFORM of one SECTION rather than multiple individual paragraphs would see improvements. The effect would be the same with PERFORM ... THRU ..., but I prefer not to recommend it. GO TO outside the range of a PERFORM is 1) bad 2) can lose out on "optimization". Shouldn't be a problem *except" when GO TO abend/exception and not expecting any logical return. If the use of this is felt to be necessarily "immediately", then it is better done with a PERFORM despite the "counter-intuitive" aspect (so document it).

Solution 5

Well, the simplest of the reasons is that SECTION s provide you the "modularity" -- just as functions in C -- a necessity in the "structured" programs. You would notice that code written using SECTIONs appears far more readable than the code written just in paragraphs, for every section has to have an "EXIT" -- a sole and very explicit exit point from a SECTION (exit point of a paragrpah is far more vague and implicit, i.e. until a new paragraph declaration is found). Consider this example and you may be tempted to use sections in your code:

*==================
 MAINLINE SECTION.
*==================
     PERFORM SEC-A
     PERFORM SEC-B
     PERFORM SEC-C
     GOBACK.
*==================
 MAINLINE-EXIT.
*==================
    EXIT.

*==================
 SEC-A SECTION.
*==================

.....
.....
.....
.....

    IF <cond>
       go to A-EXIT
    end-if

..... 
.....
.....
.....

.

*==================
 A-EXIT.
*==================
    EXIT.

Don't think you would have this sort of a privlege when writing your codes in paragraphs. You may have had to write a huge ELSE statement to cover up the statements you didn't want to execute when a certain condition is reached (consider that set of statements to be running across 2-3 pages... a further set of IF / ELSE would cramp you up for indentation). Of course, you'll have to use "GO TO" to achieve this, but you can always direct your professionals not to use GO TOs except while Exiting, which is a fair deal, I think.

So, whilst I also agree that anything that can be written using SECTIONs can also be written using paragraphs (with little or no tweaks), my personal choice would be to go for an implementation that can make the job of my developers a little easier in future!

View more solutions

Comments

[NealB]

I had forgotten about the "namespacing" feature that SECTIONs provide over PARAGRAPHs, but was that the justification the language designers used when coming up with these constructs? J.Sammet wrote an interesting article on the Early History of COBOL some time ago where some insight was given into why certain language features are the way they are but provided no insight as to why both SECTION and PARAGRAPH were incorporated. I just don't get it - but these people were not dummies so I imagine there must have been good reasons for having them. Thanks, Neal

[NealB]

Yup, those were PRIORITY numbers, and I bet you could give me a bunch of horror stories on having to use them too. I believe a program could get into real trouble if you ever let one independent segment (priority number >= 50) referenced another independent segment. Fortunately, those days are pretty much behind us now...

[NealB]

Hence the EXIT statement as a target for GO TOs. Today, EXIT is just a place to "hang" a paragraph name. I think some early compilers required EXIT to be the only statement in the last paragraph of a performed range of SECTIONs/PARAGRAPHs. It was required to generate code implementing the return from a PERFORMed range. Since PARAGRAPH is subordinate to SECTION, one can expect that PERFORMing a SECTION will execute all contained paragraphs. A range of paragraphs may be executed using PERFORM para-1 THROUGH para-n so the same functionality may be achieved using paragraphs only.

[NealB]

Interesting... Have you done benchmark testing to demonstrate these performance differences? I was under the impression that the control mechanism used in IBM compilers was exactly the same when PERFORMing SECTIONS and PARAGRAPHS. The control mechanism used in IBM COBOL compilers to implement the return from a PERFORM is described in this paper I would not expect any difference in performing a SECTION or a PARAGRAPH.

[NealB]

+1 for the interesting feedback. You describe a particular coding style using SECTION/PARAGRAPH rather than identify the language design criteria that led to inclusion of both SECTION and PARAGRAPH into the COBOL language specification. Note in your example if SECTION headers are dropped, making them into PARAGRAPHs, and PERFORM SEC-A is replaced by PERFORM SEC-A THRU A-EXIT etc. you have a functionally equivalent program using only PARAGRAPH. BTW Place MAINLINE-EXIT before GOBACK otherwise GO TO MAINLINE-EXIT will most certainly lead to trouble!

[Marcus_33]

Bah, I see that colemanj had the same answer as me. I just scrolled down past the first answer entry. I can't comment on others' answers yet so I'll leave this as a slightly expanded explanation of what colemanj said.

[NealB]

I think you and colemanj have the correct answer, but your answer is more articulate. Program segmentation was the "state or the art" mechanism for managing "large" programs in a small address space. Fortunately virtual memory made this function obsolete (I have been around long enough to have experienced the "joy" of writing segmented programs). All I see remaining is a possible "name spacing" use and an unexplained requirement that Declaratives reference Sections as opposed to Paragraphs (as pointed out by Tim Sylvester).

[Bill Woodger]

I know this is "old", but... There are many contradictions and misconceptions here. They may be born of poor wording, but they are there. "Coder beware". The "Warning" in particular does not make sense - the first part is not true, the second part need not be true. There is only one sense in which PERFORMing a SECTION with multiple paragraphs will be "faster" than PERFORMing the individual paragraphs (outside of a SECTION, it would be absurd to do it if they are inside a SECTION): PERFORM A-SECTION (containing B-PARA and C-PARA) PERFORM B-PARA PERFORM C-PARA The first is less code.

[Bill Woodger]

Those who resort to "GO TO" as a "first response" to a program design flaw :-) tend to imagine that those who don't must code deeply-nested IF/EVALUATE instead. This need not be true, although it does happen.

[user207421]

Speaking as a COBOL compiler writer, this is a load of nonsense. Using a SECTION isn't intrinsically different from using paragraphs. There is no reason to expect it to be faster or slower, whichever you are claiming. I don't know why you use the non-COBOL term 'Tag-Line' when PARAGRAPH already exists. The coding technique you describe has nothing whatsoever to do with 'high performance batch assembler'. Using GOTO to bypass conditional logic is not preferable to using ELSE. EXIT is not an assembler NOP: it is a conditional return. There are no GOTOs in PERFORM xxx THRU yyy. @BillWoodger++