If you think of COBOL as a script language rather than a real one its inadequacy is less painful. (My first node and I'm lying like Satan already.) It actually serves okay for its main purpose, mass processing of input and output files where the data is in fixed columns. Admittedly, it helps to see it this way if you've never used any other language.

The part I find most painful is that there are no local variables and no parameters to routines. Everything is global, and spaghetti code abounds.

That and the fact that most Cobol systems are legacy systems that began long before Edsger Dijkstra descended from Mt Sinai (sorry for all the religious imagery, by the way) and proclaimed GO TO an abomination. So Cobol programs use GO TO and when you start working on them they're so complicated by generations of fiddling and accretion that you couldn't take the GO TOs out even if you wanted to and were brave enough to try.

The text of a Cobol program is structured in columns, to some extent:

  • columns 1-6 is the line number (your choice of numbers, but conventionally in increments of 100 for ease of later insertion)
  • column 7 is a special marker:
  • columns 8-12 (Area A) are where major divisions of the code start, and ordinary program text isn't allowed here
  • columns 13-72 (Area B) is the main text area
  • columns 73-80 are ignored by the compiler, so you typically use them for version information.
A program consists of four divisions. All four of these must be in every program, in this order:
The Identification Division contains the name and things that are effectively comments.

The Environment Division contains file declarations and a ragbag of minor stuff.

The Data Division contains all file formats and all variables. Internal variables, i.e. those not describing positions in a file, are called working storage and live in the subdivision called the Working-Storage Section.

The Procedure Division contains the procedures. It is divided into paragraphs. All statements must be in a paragraph. You can either GO TO or PERFORM (= call) a paragraph. Most programs do both freely, with the attendant hilarity of the next person who tries to work on it. Optionally a program can have its paragraphs grouped into sections: you can also GO TO and/or PERFORM sections, at the same time as weaving in and out of their component paragraphs. 90% of Cobol-related murders are of people who did all of these at the same time.

I intend to node this wonderful language in detail, but might be returning to expand this main node in future.

coaster toaster = C = COBOL fingers

COBOL /koh'bol/ n.

[COmmon Business-Oriented Language] (Synonymous with evil.) A weak, verbose, flabby language used by card wallopers to do boring, mindless things on dinosaur mainframes. Hackers believe that all COBOL programmers are suits or code grinders, and no self-respecting hacker will ever admit to having learned the language. Its very name is seldom uttered without ritual expressions of disgust or horror. One popular one is Edsger W. Dijkstra's famous observation that "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." (from "Selected Writings on Computing: A Personal Perspective") See also fear and loathing, software rot.

--The Jargon File version 4.3.1, ed. ESR, autonoded by rescdsk.

(Disclaimer: I stopped doing COBOL some years ago. It fed me well for a number of years. The writeup below is far less than complete, though, but I will try to illustrate a number of points.)

Cobol has its uses in commercial data processing. Of course, commercial applications aren't exactly sexy - the same applies to COBOL.

Still, COBOL comes with features that are very handy in commercial applications, but mostly useless in something like a compiler:

BCD data types.
An accounting package just cannot use float for obvious reasons. Generally, COBOL allows for a lot of control over your data, includign the encoding and position of the sign, justification and other nifty things.

Arithmetic statements that allow for rounding (ROUNDED)
Greater control over what you do with your numbers.

powerful list formatting
Depending on dialect, you get everything including a report generator built into the language.

powerful, in-language, file access methods
Less important in the age of the data base, but anybody trying to do ISAM access or even key sequential reads in other programming languages of similar age would have ended up with nightmarish code by comparison.

portability of the above to a number of platforms
Platform in this context does not mean different Microsoft operating systems or different Unix dialects. COBOL is portable between architectures as different from each other as MVS mainframes and outdated 16 bit minicomputers.
FORTRAN is as portable, maybe even more so. Ada, however cannot be beaten for portability but kicked for it's anal-retentiveness in loads of other areas.

Of course, COBOL also has disadvantages, many of them stemming from the fact that the language is older than most of today's computer users.

Strict source code formatting
Know your columns - OldCobbler's writeup tells you all about it.

Long, long, source code
There is no one-liner in COBOL. Something you'd write in a couple of lines in a modern language will fill pages and pages of COBOL code. Of course, this sometimes also works the other way around, in areas where COBOL is strong - processing well-formatted data.

Dangerous features
ALTER will change the target of a GOTO during run time - most later compilers did not even support it.
CORRESPONDING when added to statements like ADD or MOVE, will add or move parts of one structure to another structure. Convenient if it works as advertized, but subject to arcane rules.
PERFORM procedure-name-1 THRU procedure-name-2
will allow you to execute more or less arbitrary parts of your program. If you also know that PERFORM is the preferred, goto-less loop concept (by default when it comes to classical COBOL), you might end up with constructs like:

No recursion, pointers, dynamic memory handling, high-level math finctions, or even functions.

"The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense."
- Edsger W. Dijkstra

A little geneology/historical background for COBOL:

1943 -- ENIAC First general purpose electronic computer
1948 -- UNIVAC First commercial computer
1952 -- A-O First compiler (of sorts)
1954 -- FLOWMATIC First English-like programming language
1957 -- FORTRAN, a language based on algebraic formulas
1959 -- First COBOL specifications introduced by CODASYL
1960 -- First COBOL implementation
1968 -- ANSI develops ANS COBOL Standard

According to LegacyJ Corp., one of several companies trying to revive COBOL by transforming it into a web scripting language (*shudder*) and trying to support Web based interfaces to legacy COBOL code:

"There are over 180 billion lines of COBOL in use today, with an estimated 5 million new lines added each year. There are as many as 2.5 million programmers who have primary skills in COBOL, far exceeding any other programming language. Investments in COBOL technologies, staff, hardware is estimated to be over 5 trillion dollars."

(Throughout this node, Cobol referrs to the modern language, standardized in the 1990s, and COBOL referrs to the unstandardized language that goes back to the 1950s.)

Every language has a domain of competence: That group of problems that language can solve more concisely and with less work than any other language currently in existence. Cobol's domain of competence is business problems, especially business problems that deal with large numbers of records and large amounts of money:

  1. Its mathematical model allows a level of control over the precise format of the number unheard-of in modern programming languages. This is required because people get quite irate if their paychecks or bank accounts are miscomputed due to a floating-point rounding error. Fixed-point and strict control over rounding rules is essential, and no language provides those features like Cobol.
  2. Its I/O model is completely record-oriented. This is utterly unworkable when you want to write a general-purpose text editor, but it's a godsend when you need to plow through millions of payroll records to compute FICA withholdings. This record-orientation dates back to the punch card era, but it maps well to how banks and other large corporations actually work.
  3. It works on the machines banks already have. No one was ever fired for buying IBM, and IBM mainframes (the big things running MVS, VM/CMS, and OS/400 in the back room) provide very good native Cobol support. OS/400 even provides a native database for your Cobol programs to get records out of. (Besides, if you aren't programming in Cobol you're liable to be programming in RPG, and that's nobody's idea of a good time.)

The downsides to Cobol are that it was once called COBOL and it really doesn't have any other domain of competence. I'll take these in turn:

  1. COBOL is one of the earliest high-level languages. Its immediate ancestry consists of autocoders, programs that are barely a step above macro assemblers, and very little was known about writing readable programs in those days. Couple that ignornace with the severe limitations of mainframes in those days and you end up with abominations like the ALTER verb and a complete lack of data encapsulation: Like the BASIC dialects that haunted microcomputers in the 1970s/1980s, every variable in a COBOL program is a global.

    This wouldn't be so bad if it wasn't for the prevalence of legacy code. There is a huge amount of really old COBOL software that strongly resembles Cthulhu: Leave it sleeping in the deep and all will be well, but wake it up and you will pray only to be eaten first. Suffice to say, future modification wasn't the foremost concern on the original authors' minds.

  2. Cobol is horrifically bad at anything that doesn't involve performing simple arithmetic on large numbers of fixed-format records. Its ability to finely control data types (not just numbers) means that the programmer must finely control data types, leading to either wasted space or unavoidable truncation. Its record-orientation makes it impossible to read unstructured files, like HTML documents or plain text files. Its atrociously ugly syntax makes it painful to read and impossible to write with real concision: There are no one-liners in Cobol. (Ironically, its syntax is horrible because it was meant to be easy to read. The designers thought an English-like syntax would enable non-programmers to write software, ignoring that fact that the difficulty of programming has nothing to do with syntax.)

    Cobol is not the language for most kinds of new software projects. It is a good language to keep using if the program has been running just fine since the Johnson administration. It is a good language to use if you need to write a new financial package and can't buy one from a software company. Beyond that, however, stay away.

Cobol and COBOL will be with us for a very, very long time to come. COBOL has outlived the structured programming, object-oriented programming, and aspect-oriented programming crazes, and it will outlive the extreme programming craze in due course. It has seen the rise of the Internet and the Web and the fall of IBM as a hardware company. (IBM still makes hardware, but it's primarily a consulting firm these days.) It will haunt our dreams until we die.

Log in or register to write something here or to contact authors.