Misinformation continues to surround the most-used 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 article¹ 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 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. While that claim was made 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 common financial functions, nor does the language stucture 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:

• The notorious period

  In their zeal to produce an English like syntax COBOL's designers preferred the term "sentence" to "statement". And of course in English sentences are ended by periods. But the period in COBOL imposes multiple closure on all open conditional statements. Programmers would stare at nicely indented "structured" logic and wonder why it didn't do what appeared obvious. A premature period was usually the culprit.

• Dozens of arbitrary rules

  Critics used to complain that PL/I was too large a language, and indeed PL/I provided vastly greater functionality than any of its predecessors. But surprisingly a COBOL manual contained about the same number of pages as a PL/I manual. How could that be?

  Instead of presenting facilities a programmer could use, the COBOL manual had to present dozens and dozens of special rules and restrictions. For example:

  • An array dimension (OCCURS) had to be specified as a literal constant, thus forcing you to repeat a "hard coded" value. Furthermore, you couldn't specify values for a table in the same declaration but had to use a REDEFINES structure.

  • The DISPLAY <value> statement will produce garbage if the value parameter is an internal numeric (COMPUTATIONAL) data item.

  • A MOVE of a group item will produce garbage if the source and the target fields don't have the same internal form (DISPLAY or COMPUTATIONAL), but moving a single item or CORRESPONDING items will effect the expected conversion.

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.

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.

²—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 September 20, 2008

Return to IDI home page
Technical articles