Is COBOL really understandable after 14 years.

Hello,

This article uses an old piece of COBOL code to see if it really is understandable after 14 years.

Do you agree?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Problems fixed over 30 years ago

The most recent advance in COBOL appear to be an object orientated standard‚ which offers some considerable improvements while maintaining backwards compatibility. Unfortunately the uptake on this seems to be slow. COBOL does have a bad press‚ and after looking at modern COBOL‚ most of the complaints refer to problems that have been fixed over 30 years ago.
What changes were done to address the complaints, I am curious to know?

Re: Problems fixed over 30 years ago

I don't know much about COBOL, but one of the biggest complaints is that it doesn't support structured programming because you have to use GO TO to create loops. This just isn't true and hasn't been since COBOL 74 or maybe COBOL 85. From what I can see, there is also better support for local variables from at least COBOL 85.

Mostly COBOL-85

Most of the structured control-flow stuff was added in COBOL-85. No more need for GOTO or PERFORM THROUGH. You could write the Procedure Division for that example like this:

       PROCEDURE DIVISION.
       MAIN SECTION.
       MAIN-PARA.
           OPEN INPUT TAG2-FILE
           OPEN OUTPUT REP-FILE

      * Get the Date
           ACCEPT WS1-DATE FROM DATE
           MOVE WS1-YR TO WS1-YER
           MOVE WS1-MT TO WS1-MTH
           MOVE WS1-DY TO WS1-DAY

           SET NOT-TAG2-EOF TO TRUE

           PERFORM UNTIL TAG2-EOF
             READ TAG2-FILE AT END
                SET TAG2-EOF TO TRUE
             NOT AT END
                PERFORM A01-OP-LINE
             END-READ
           END-PERFORM

      * Print Control Report
           MOVE WS1-BLU-ADD TO WS1-BLU-TOTAL
           MOVE WS1-RED-ADD TO WS1-RED-TOTAL
           MOVE WS1-BLA-ADD TO WS1-BLA-TOTAL
           MOVE WS1-BLU-TOT TO WS1-BLU-COST
           MOVE WS1-RED-TOT TO WS1-RED-COST
           MOVE WS1-BLA-TOT TO WS1-BLA-COST
           WRITE REP-RCD FROM WS1-CONTROL-HDR AFTER ADVANCING 4 LINES
           WRITE REP-RCD FROM WS1-RESULT1 AFTER ADVANCING 1 LINE
           WRITE REP-RCD FROM WS1-RESULT2 AFTER ADVANCING 1 LINE
           WRITE REP-RCD FROM WS1-RESULT3 AFTER ADVANCING 1 LINE
           CLOSE TAG2-FILE REP-FILE
           STOP RUN.


       A01-OP-LINE.
      * Put Correct Colour Name in Sub Heading
          MOVE SPACES TO SUB-COLOUR
           EVALUATE TAG2-COLOUR
             WHEN "BLU"
                MOVE 'BLUE' TO SUB-COLOUR
             WHEN "RED"
                MOVE 'RED' TO SUB-COLOUR
             WHEN OTHER
                MOVE 'BLACK' TO SUB-COLOUR
           END-EVALUATE

      * If the number of lines printed > 57 then put up the page heading
           IF WS1-LCNT > 57
                ADD 1 TO WS1-PAGE-EDIT
                MOVE WS1-PAGE-EDIT TO WS1-PAGE-NBR
                WRITE REP-RCD FROM WS1-HDR-AREA AFTER ADVANCING PAGE
                MOVE ZERO TO WS1-LCNT
      * Output Colour Sub Heading
                MOVE SPACES TO WS1-COLOR-CHECK
                MOVE TAG2-COLOUR TO WS1-COLOR-CHECK
                WRITE REP-RCD FROM WS1-SUB-HDR AFTER ADVANCING 3 LINES
                WRITE REP-RCD FROM WS1-SUB-HDR2 AFTER ADVANCING 1 LINE
                ADD 4 TO WS1-LCNT
                MOVE SPACES TO REP-RCD
            END-IF

           IF WS1-COLOR-CHECK NOT = TAG2-COLOUR
                MOVE SPACES TO WS1-COLOR-CHECK
                MOVE TAG2-COLOUR TO WS1-COLOR-CHECK
                WRITE REP-RCD FROM WS1-SUB-HDR AFTER ADVANCING 3 LINES
                WRITE REP-RCD FROM WS1-SUB-HDR2 AFTER ADVANCING 1 LINE
                ADD 4 TO WS1-LCNT
                MOVE SPACES TO REP-RCD
            END-IF

           MOVE TAG2-ACC-NBR TO REP-ACC-NBR
           MOVE TAG2-TAG TO REP-TAG
           MOVE TAG2-PRN TO REP-PRN
           MOVE TAG2-QTY TO REP-QTY
           WRITE REP-RCD AFTER ADVANCING 1 LINE

      * Add up Tag Quantity for each Colour
           EVALUATE TAG2-COLOUR
             WHEN "BLU"
               ADD TAG2-QTY TO WS1-BLU-ADD
             WHEN "RED"
               ADD TAG2-QTY TO WS1-RED-ADD
             WHEN OTHER
               ADD TAG2-QTY TO WS1-BLA-ADD
            END-EVALUATE

      * Add up Tag Cost for each Colour
            EVALUATE TAG2-COLOUR ALSO TAG2-QTY
              WHEN "BLU" ALSO 24
                ADD 2.25 TO WS1-BLU-TOT
              WHEN "BLU" ALSO 36
                ADD 3.00 TO WS1-BLU-TOT
              WHEN "BLA" ALSO 24
                ADD 2.25 TO WS1-BLA-TOT
              WHEN "BLA" ALSO 36
                ADD 3.00 TO WS1-BLA-TOT
              WHEN "RED" ALSO 24
                ADD 2.25 TO WS1-RED-TOT
              WHEN "RED" ALSO 36
                ADD 3.00 TO WS1-RED-TOT
           END-EVALUATE

           ADD 1 TO WS1-LCNT.

with the addition in the WORKING-STORAGE SECTION of:

       01 TAG2-FLAG PIC S9(9) COMP.
             88 TAG2-EOF      VALUE 1.
             88 NOT-TAG2-EOF  VALUE 0.

With COBOL-2001 (and most compilers before that), you can say:

       01 TAG2-FLAG PIC S9(9) COMP.
             88 TAG2-EOF      VALUE 1 FALSE 0.

and SET TAG2-EOF TO FALSE

Of course, if I were really going to maintain this program, I'd translate the color name to an integer and use arrays and loops.

Nothing like the verbosity

Nothing like the verbosity of COBOL, is there? :-)

Only the sparsity of Perl

As an aside--and this is an entirely syntactic issue, so I'm almost tempted to apologize for bringing it up?

but who finds the ALL CAPS SYNTAX OF COBOL and other languages of the era to be annoying? There is, of course, a reason for that--many terminals of that era didn't support lowercase letters--something that would chew up valuable bits on punchcards; I still remember my days on the Atari 8-bit machines, which didn't support lowercase letters in the color text modes (6 bits used to encode the character, in an ASCII-derivative called ATASCII; and 2 bits used to encode the color).

Of course, we still have SQL. :)

UPPER CASE

In my experience, COBOL compilers are case-insensitive, but coworkers are not.

Well...

So are SQL engines -- at least, all the ones I'm familiar with.

It really is quite nice to look at

I know that people say that COBOL is verbose, but if it was meant to be easier to read than to write. Then it does what it was designed to do well.

I really quite like the look of the improved code above and think that I might look further into COBOL. I can certainly see how it must be easier to debug.

Density

but if it was meant to be easier to read than to write

It's always seemed to me that languages like COBOL create easy readability of trees at the expense of making the forest incomprehensible.

EVALUATE

Well, I like the EVALUATE statement in COBOL. This example shows some features not in many languages switch statements:

evaluate some-string also some-number
  when "FOO" also 1
  when "FOO" also 2
  when "BAR" also 1
    perform something-for-these-three-cases
  when "BAR" also ANY
    perform something-for-other-bars
  when "FOO" also 3
    continue
  when other
    perform default-processing
end-evaluate

Note how you can have multiple WHENs with a common statement. If you want to have a WHEN with no action, you can put in the no-op CONTINUE.
There's an ANY expression that will match anything. There's a default WHEN OTHER clause.

You can also use it like a LISP cond:

evaluate true
   when A < B
   when A > B
     perform paragraph-1
   when A = B AND A = C
     perform paragraph-2
   when A = B AND A > C
     perform paragraph-3
   when other
     perform paragraph-4
end-evaluate

This is equivalent to

   if A < B
   or A > B
     perform paragraph-1
   else if A = B AND A = C
     perform paragraph-2
   else if A = B AND A > C
     perform paragraph-3
   else
     perform paragraph-4
   end-if end-if end-if

but more aesthetically pleasing. There's no ELSEIF in COBOL so you either need and equal number of end-if's or a period--but the period also ends any enclosing statements.

Other than the EVALUATE, I can't think of much to like in COBOL.

COBOL itself is not hard to

COBOL itself is not hard to understand, few syntax to learn about data types and IO(1), but real COBOL code is most of the time a monstruosity.

I've read mainframe programs in production that were 10 pages long, with at least 100 variables with "gensym" like names and as much GOTO statements.

COBOL doesn't really help to structure/abstract your program but I think most of the problem are the programmers (and the historical context) ..

(1): and .Net evangelists make a lot of jokes on that part because they have a COBOL 2 CIL compiler and thus interoperability; so they show you what kind of advantages you have to use C# to add new features on top of existing COBOL programs.

Any reason to prefer COBOL over Java...

...for non-legacy business software? (I.e. no need to be compatible with an existing COBOL codebase).

One thing that comes to mind is a suitable decimal math packages. IEEE754 floating point (what you get with "float" and "double") is inappropriate in financial applications, due to its inability to represent decimal fractions precisely. One can write precise math packages in Java (many exist), but the lack of operator overloading makes these cumbersome to use.

Obviously, Java has a far healthier ecosystem today than COBOL enjoys.

Re: operator overloading

might be worth considering sticking with the jvm, but going with a language which supports something like that e.g. Scala or whatever. it used to be that "java" == both the jvm and the language (unless you were some crazy bytecode hacker :-) but now there's i think enough choice on top of the jvm to be able to find a sweeter spot than the painfully unhelpful normal java syntax.

Volume

There are companies whose software handles record keeping for a significant portion of the US economy that process millions of transactions in nightly batch cycles (batch due to the time of market close and security pricing based on stock prices). I saw one application that ran on mainframes that generated 50 terabytes of data a day. Moores law hasn't negated the mainframe advantage yet in this regard.

There are a couple of Cobol to Java conversion products around. I've read that performance of generated code is not so good because Cobol numeric types require a BigDecimal type of array manipulation and Java bounds checking is a major performance penalty in that regard.

Do you mean..

that the array indices are stored as BigDecimals, requiring a more expensive (than a simple ALU operation) boundscheck?

About the only language I can think of that permits fractional array indices is Cg, a graphics-oriented C derivative proposed by one of the GPU vendors (3Dfx?) a while back--if you passed a fractional index into an array, it would interpolate the data for you.

Moore's Law hasn't done all that much for I/O speeds; other than make it more of a bottleneck.

Nice!

> if you passed a fractional index into an array, it would interpolate the data for you.

That is utterly brilliant. Stan Kelly-Bootle is finally vindicated! =)

But really

Cg doesn't really have arrays. It has texture maps, which are sampled two-dimensional signals, and operators for evaluating the underlying signal at arbitrary floating-point positions, by reconstructing the continuous signal from its samples (by linear interpolation.) A large fraction of the hardware in the graphics cards that Cg runs on is devoted to exactly this operation, so it's unsurprising that the feature appears in the language. Since texture maps are the only data storage available on the hardware (other than a small register file) it's also unsurprising that programmers use textures to store arrays and just about anything else you can think of.

Ahhh Cobol....

Cobol (minus goto's) really isn't that bad. Especially if you consider that there are plenty of 1000+ file ASP (JSP, PHP whatever) applications in the world now. A lot of them are a spaghetti nightmare of included files, javascript, vbscript, html, and css. It's really quiet frightening.

With Cobol green screen programs, IBM's CICS environment at the very least keeps a concrete separation between presentation and logic. There are tons of web applications that don't even manage to do this. And with inline sql, Cobol can even look kind of 'linq-ish'.

I've become convinced that application development has taken a major step backward with the predominant web paradigm and still hasn't solved the fundamental problem of implementing stateful applications over a stateless medium (www or 3270 take your pick).

Note: everything I just said applies to Cobol 85. The oop extensions in newer versions are simply absurd, imho

problems of stateless medium

I agree about the web being an awful development environment. I have developed a reasonably large web app and I pull my hair out at the inefficient way of doing things to keep track of state. As far as I am concerned the only reason that web applications are still so popular is that so many of them rely on advertising and they also rely on being found by google.

the only reason that web

the only reason that web applications are still so popular is that so many of them rely on advertising and they also rely on being found by google.

The only reason they are so popular is because they are a well-understood medium for delivering portable applications one can access from anywhere with a network connection, with virtually any device, even low-powered ones, and allows companies to keep their precious IP on their own servers where it can't be disassembled. I think you'd be hard-pressed to find a language or framework that can provide those same advantages.

What about telnet? (Sorry about going off-topic)

Telnet was used previously and worked really well. What I think we really need now is a graphical version of telnet so that we can have proper stateful control over our applications in a pleasing windowing GUI.

For anyone who has written anything but the most basic of web apps vs proper distributed applications, they will know that really web apps are just bodges and hacks cobbled together. This is fundamentally true no matter how well designed they are.

Given my mainframe

Given my mainframe experience I was somewhat amused when CICS was mentioned, and it is true that many MF applications are written in COBOL, but even there the connection is weak. Applications can be written in many other languages as well (indeed, nothing beats BAL and IMS... CICS and COBOL is for wimps...) But really, this angle is not going to bring us any closer to PLT issues. As regards staeful programming models, I think the connection is going to be yet another discussion of continuation based systems, a subject discussed here many many times. The archives are your friend.

proper stateful GUI applications

What I think we really need now is a graphical version of telnet so that we can have proper stateful control over our applications in a pleasing windowing GUI

I agree very much about this, and I am extremely surprised that no such interface did appear.

More specifically (at least from a Linux or SunOS perspective) I am still wishing a more friendly user interface than the command line. (On unix, the underlining tty interface is a huge mess; nobody cares about a VT220 interface anymore!). I would like some sophisticated terminal like interface.

For example, it would be wonderful if a markup language similar to HTML would exist, but without any navigation abilities. One could dream of a terminal handling a sequence of "pages" with input boxes, buttons, etc...

More related to programming languages, I also find pitiful that our programming languages are still textual (and that our code is edited under Emacs, which I do like). We still have no way to add (without an extra syntax) bold and italics in comments, greek letters in identifiers, hypertextual links in code.

Regards.

Non-textual programming languages

At the risk of flying off at a tangent

> I also find pitiful that our programming languages are still textual

Some are not, but there is a long way to go.

So far we have (off the top of my head):

  • SynthEdit is a way of programming synths and audio effects visually; why is that considered an "application" and not a "domain-specific visual programming language"?
  • Conal Elliott's Tangible Values is a bold step towards real visual programming; I wait for "real" applications of this with baited breath, but feel that the mental gap most of us programmers will have to leap is perhaps too wide.
  • Python has doctest, the ability to plonk test code into comments. That's still textual, but (when married with a folding editor) gets away from one serious annoyance with linear, textual languages which is that multiple views of the code cannot coexist without clutter. In this case a (kind of) use-case view together with an implementation view.
  • UI builders have been with us for some time, but the integration with "real" code is weak. When will the visual aspects be given equal footing?
  • Useless UML round-trippery.

And we have not (as far as I know -- please correct me if I've missed something exciting):

  • Visual state machine programming where the diagram is first-class.
  • Visual dataflow programming (Haskell's Arrows are programmed in a cute flattened-diagram way; don't you wish you could represent the dataflow in two dimensions?). Domain-specific applications of this such as SynthEdit exist, but not AFAIK general-purpose.
  • GUI Mock-ups existing as first-class objects that "run" whenever that portion of "real code" is missing, and validate the code against use-cases where code is present.

Given the amount of effort so far poured into UML, this seems a bit pathetic, no?

But what about...

"What I think we really need now is a graphical version of telnet so that we can have proper stateful control over our applications in a pleasing windowing GUI"

I agree very much about this, and I am extremely surprised that no such interface did appear.

XWindows...?

For example, it would be wonderful if a markup language similar to HTML would exist, but without any navigation abilities. One could dream of a terminal handling a sequence of "pages" with input boxes, buttons, etc...

This sounds a bit like WAP.

For anyone who has written

For anyone who has written anything but the most basic of web apps vs proper distributed applications, they will know that really web apps are just bodges and hacks cobbled together. This is fundamentally true no matter how well designed they are.

I disagree. Also, stateful systems don't scale as well as stateless systems, as they are more vulnerable to DoS.