Cobol 101

Felt i must introduce you to my new best friend, at least, the programming equivalent of it.

Why do i love to code Groovy ? It’s easy to express a quick solution in a few lines of code, and for me, after almost fifty years of writing COBOL code, my brain has nearly turned to rice pudding from writing huge lumps of english-like code just to express a logical solution to some problem or other that i can do in a few lines of Groovy. A COBOL overview follows, so kindly click on Groovy 101 to avoid falling asleep.

COBOL, you may or may not rememeber, was invented as a tool that programmers could use to develop and express solutions to common business oriented problems in a platform-independent way, and before you can say Grace Hopper, we had a high level language that was human-readable and portable between machines. We dumped the work of expressing our solutions onto the machine. Instead of writing thousands of lines of code in machine language, or it’s later cousin, assembler, which was extremely machine-friendly and man-hostile, we started to write in english and then use translators and compilers to interpret what the english would mean in computer-speak.

This, of course, forced the hardware providers to write compilers to do just that. Each vendor had their own flavor of COBOL. Burroughs had theirs, Honeywell, Univac and DEC had different flavors, RCA 301 and 501 systems had started earlier on their COBOL compilers, so they were a little less buggy. IBM had forms of COBOL on their 1401, 1620, 7040, 7090, S360, and later S/34-S/36-S/38-AS400-System i  systems, and since they sold more machines, their version of COBOL became more acceptable. (Hitachi pitched in too).

Still, there were far too many versions of COBOL and each version had it’s own vendor-specific features making it a lot less portable than Grace first envisioned. Enter CODASYL. See http://en.wikipedia.org/wiki/CODASYL for an overview of what was needed. I made a fairly good living migrating different versions of COBOL between platforms.  To read more about the various incarnations of the COBOL specification, please google ‘american national standards institute 1960 cobol‘ .

My memories of Burroughs systems are quite nostalgic. Burroughs COBOL in the ’70s looked like this

http://bitsavers.org/pdf/burroughs/B1700/B1700_brochures/1058542_COBOL/1058542_COBOL_front_feb73.jpg

In COBOL, i had to code four divisions of statements. The IDENTIFICATION DIVISION spells out the program name. The ENVIRONMENT DIVISION declares the model of computer the program can run on, and associates the files to be used in this program with the type of external devices used by this program, i.e. punch cards, magnetic tape, etc. The DATA DIVISION has two sections, the first section describes file usage in more detail with variables for file-related purposes and the second section is for non-file related variables, or fields. The intended use of a field is declared in PICTURE statements. The final division is the PROCEDURE DIVISION where we code the actual logic to solve our problem using english-like statements.

Our typical ‘Hello World’ COBOL program requires a minimum set of statements like this:

IDENTIFICATION DIVISION.
PROGRAM-ID. HELLOWORLD.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
     SOURCE-COMPUTER. IBM-360.
     OBJECT-COMPUTER. BURROUGHS-B1700.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
DATA DIVISION.
FILE SECTION.
WORKING-STORAGE SECTION.
01 HELLO-MESSAGE PIC X(20) VALUE "HELLO WORLD".
PROCEDURE DIVISION.
LOGIC-1.
     DISPLAY HELLO-MESSAGE.
     STOP RUN.

A program to print out each line of an input text file plus a count of lines might look like this :


/ slash char. caused compiler to advance printout paper to next page/sheet of paper
* star char. used to have remarks and notes in your source code - invisible to the compiler
 IDENTIFICATION DIVISION.
 PROGRAM-ID. HELLOWORLD.

 ENVIRONMENT DIVISION.
 CONFIGURATION SECTION.
      SOURCE-COMPUTER. IBM-360.
      OBJECT-COMPUTER. BURROUGHS-B1700.
 INPUT-OUTPUT SECTION.
 FILE-CONTROL.
      SELECT README-FILE ASSIGN TO DISK
      ACCESS MODE IS SEQUENTIAL.
 DATA DIVISION.
 FILE SECTION.
 FD README-FILE
      RECORD CONTAINS 1 TO 80 CHARACTERS
      VALUE OF ID IS "README.TXT"
      DATA RECORD IS RECORD-1.
 01 RECORD-1.
     05 FIELD-NAME PIC X(80).

 WORKING-STORAGE SECTION.
 01 LINE-COUNT PIC S9(5) VALUE ZERO.

 PROCEDURE DIVISION.
 A-SECTION-OF-KODE SECTION 50.
 SOME-LOGIC-STATEMENTS.
      OPEN INPUT README-FILE.
 PARAGRAPH-2.
      READ README-FILE AT END GO TO PARAGRAPH-123.
      DISPLAY FIELD-NAME.
      ADD 1 TO LINE-COUNT.
      GO TO PARAGRAPH-2.
 PARAGRAPH-123.
      CLOSE README-FILE.
      DISPLAY LINE-COUNT " LINES".
      STOP RUN.
/

Forgot to note that we only had 80 column punch cards, each card holding a single ‘line’ of code. Cobol source code decks of cards could easily contain several thousand cards, even for the most simple of tasks. Each column of a single punch card might hold one element of syntax, or use several columns for a single piece of logical ‘information’, like a seqeunce number. For many of the compilers i worked on, card column’s one thru seven were used to hold a sequence number like 000100, quite essential if one dropped the card deck ! Then you needed a card sorter machine to reorder all the cards back into ascending order. What! – forgot to punch a sequence number into each and every card ?

Column seven was for continuation characters ( – ) or remarks ( * ), an early approach to offer metadata to the compile. Column eight was for group-level declarations like ‘DIVISION‘, ‘SECTION‘ grouping names.

Sub-sections logically within a group would begin in column 12 and up thru column 72, while column 73-80 could be used for remarks, notes, etc. – also invisible to the cobol compiler.

So you can see from these examples, the amount of supporting syntax to get the job done is similar to Java. Groovy gets the job done in fewer lines. Please see Groovy 101 for the Groovy equivalent code.