What is the benefit of using paragraphs and sections for executing pieces of code, instead of using a subprogram instead? As far as I can see paragraphs and sections are dangerous because they have an non intuitive control flow, its easy to fall through and execute stuff you never meant to execute, and there is no variable (item) scoping, therefore it encourages a style of programming where everything is visible to everything else. Its a slippery soup.
I read a lot, but I could not find anything related to the comparative benefit of paragraphs/sections vs a subprogram. I also asked online some people in some COBOL forum, but their answers were along the lines of "is this a joke" or "go learn programming"(!!!).
I do not wish to engage in a discussion of stylistic preferences, everyone writes the way that their brain works, I only want to know, is there any benefit to using paragraphs/sections for flow control? As in, are there any COBOL operations that can be done only by using paragraphs/sections? Or is it just a remnant of an early way of thinking about code?
Because no other language I know of has mimicked that, so it either has some mechanical concrete essential reason to exist in COBOL, or it is a stylistic preference of the COBOL people. Can someone illuminate me on what is happening?
These are multiple questions... the two most important ones:
Yes. A likely not complete list:
USE
statements in DECLARATIVES
can only apply to a paragraph or a section. These are used for handling file errors and exceptions. Not all compilers support this COBOL standard feature in full.switch
statement (COBOL's EVALUATE
, which is not the same as a common switch
but can be used similar has an explicit break
and no fall-through)GO TO DEPENDING ON
(could be recoded to achieve something similar with EVALUATE
and then either PERFORM
, if the paragraphs are expected to fall-through, which is not uncommon, then that creates a lot of extra code)GO TO
in general and especially nice - the old obsolete ALTER
statementPERFORM
statement, format 1 "out-of-line"EXTERNAL
, and you often want to have a file state being limited to a single programEXIT
statement (plain without anything else, actually doing nothing else then a CONTINUE
would)static
data or otherwise (module)global data that is shared between functions/methods and also different source code files)CALL
isCALL USING
means that you also have to adjust the called program - and all programs that call this, even when you place the complete definition in a copybook, which is very reasonable, this means you have to recompile all programs that use thisCALL
ed program may not be available or lead to an exception, for example because it cannot be loaded as its parameters have changedNote: While not all compilers support this you can work around nearly all of the runtime overhead and consistency issue when you use one source files with multiple program definitions in (possibly nested) and using a static call-convention. This likely gives you the "modern" view you aim for with scope-limitation of variables, within the programs either persistent (like local-static) when defined in WORKING-STORAGE
or always passed when in LINKAGE
or "local-temporary" when in LOCAL-STORAGE
.
[I've added this one to not lead to bad assumptions] Of course not!
Using sub-programs and also user-defined functions (possibly even nested providing the option for "scoped" and "shared" data) is a good thing where you have a "feature boundary" (for example: access to data, user-interface, ...) or with "modern" COBOL where you have a "language boundary" (for example: direct CALL
s of C/Java/whatever), but it isn't "jut for limiting a counter to a section" - in this case: either define a variable which state is not guaranteed to be available after any PERFORM
or define one for the section/paragraph; in both cases it would be reasonable to use a prefix telling you this.
Using that "separate by boundary" approach also takes care of the "bad habit of everything being seen by everyone" issue (which is in any case only true for "all sections/paragraphs in the same program).
Personal side note: I would only use paragraphs where it is a "shop/team rule" (it is better to stay consistent then to do things different "just because they are better" [still providing an option to possibly change the common rule]) or for GO TO
, which I normally not use.
SECTION
s and EXIT SECTION
+ EXIT PERFORM [CYCLE]
(and very rarely GOBACK
/EXIT PROGRAM
) make paragraphs nearly unnecessary.