Misinformation continues to surround the once dominant programming language

Reminiscences and Myths about COBOL

©Conrad Weisert
September 20, 2008

NOTE: This article may be reproduced and circulated freely, as long as the copyright credit is included.


Last year, upon the death of John Backus, we looked back at Fortran, a half-century-old programming language that's still in general use. The October issue of Dr. Dobb's Journal resurrects interest in another language that's still widely used: COBOL. The article1 reminds us that

"Billions of lines of new Cobol code are being written every year."

and speculates that COBOL may still be an appropriate language for new Web 2.0 development.

From COBOL's birth that language has been the source of endless misinformation, and the latest article is no exception. Here are a few memorable myths:

Myth #1—COBOL programs are self-documenting!

We disposed of that one several years ago. Although that claim was widely accepted when COBOL was presented to the world, it became a joke as monster COBOL programs were seen as impenetrable nightmares.

Myth #2—COBOL is business-oriented!

Because its very name is an acronym that includes the term, it was natural to accept that claim without careful scrutiny. But we can search the language and its run-time support thoroughly and never find a tiny fraction of the support for business that's common in a modern spreadsheet processor. There's no built-in support either for frequently occurring data types or for common financial functions, nor does the language structure facilitate transaction processing. The sole innovation I can think of was the floating dollar sign in number formatting.

Myth #3—COBOL is a terrible language mainly because of its verbose syntax

Actually the syntax, tedious as it is to code, is the least of the obstacles COBOL puts in the path of a good programmer. You get used to the syntax, or you can use a macro generator to expand it from a compact form.

It would take dozens of pages to cite all the real serious shortcomings of COBOL, but I'll mention a couple here:

Myth #4—COBOL programs have a hierarchical organization!

This is the new one from Dr. Dobb.

"Developed in 1959 . . . COBOL is characterized by a verbose English-like syntax and a strict hierarchical program structure." (p. 16)

The above is not only wrong, it asserts the exact opposite of a notorious COBOL deficiency. If there was ever a language that discouraged hierarchical structure it was early COBOL. The only thing remotely hierarchical in the language is the ability to specify group levels in a fixed record structure.

The original COBOL offered no way to build a program out of parameterized subroutines. Every data element used in the whole program was jammed into one common monolithic DATA DIVISION, and every statement in the PROCEDURE DIVISION potentially knew about and could modify every data item in the entire program.

Not until the COBOL 742 standard did the language support the CALL . . USING statement and the LINKAGE SECTION, thereby allowing conventional subroutines, and even then we weren't allowed to pass a file name as a parameter.

Furthermore, by that time the monolithic style of programming had become so firmly entrenched among COBOL programmers that hierarchical program structure was practiced by only a minority of programmers. Popular textbooks on COBOL programming, including many with the word structured in the title, ignored modular hierarchical program structure.

The costly
filename parameter restriction

A common pattern in early (batch processing) business applications was to update a sequential master file from a sorted file of transactions. Every COBOL programmer wrote that logic dozens of times, and some were even proud of their mastery of it.

Nevertheless, a lot of those sequential file update programs contained bugs, often subtle ones that didn't arise for months after the application was deployed. Multiple transactions for the same master record was often a problem. Inserting a new record before the first record or after the last one might not work. And even if the logic was flawless, the cost of all that redundant development was a severe burden.

Wasn't sequential file update an obvious candidate for a reusable library module? Of course! Then why did so few organizations develop and use one? Given the restriction on passing filename parameters, was it even possible to write a general-purpose one? Yes, but not in the obvious way.

So, is COBOL still alive and well?

The Dr. Dobb's article urges us to keep an open mind. The latest version, featuring object-oriented extensions, may well be appropriate for some applications.

Programming in a limited language with lots of restrictions can be a satisfying challenge for a good programmer, but there is a huge difference between bad COBOL and good COBOL. Several years ago we looked at some organizations' COBOL coding standards and, with feedback from readers, concluded that many of them were misguided and even harmful.

A good programmer uses whatever tools contribute to solving the problem. If you find yourself using COBOL, use it well and produce well organized, well structured, maintainable programs.


1—Michael Swaine: "Is Your Next Language COBOL?", pp. 16-18.

2—IBM and others had earlier supported a non-standard ENTER LINKAGE feature, but it was used mostly for calling small utility programs coded in assembly language.

Last modified April, 2013

Return to IDI home page
Technical articles