Search This Blog

Thursday, July 1, 2010

The COBOL Version: Going The Way of Jello?

Once upon a time, every customer RFI had a question about the version of COBOL the compiler supported.  That was years ago.  I can't tell you the last time I got that question.  Not only that, I can't recall when the last time anyone cared really.

Why is this?  Have COBOL versions gone the way of gelatin?  Have they blended so much or become so generic that eveyone calls it by the same name, regardless of what version it is?  Name another brand of gelatin.  (Bet ya can't)

Well, one reason I personally never get the RFI question is probably due to the fact that the Micro Focus dialect has become the defacto standard if you are working off the mainframe.  And that just happens to be the toolset I work with.  Yes, it is nice to be with the market leader *grin*.  It does make life easier sometimes.  The only version related question recently was "Do you support Enterprise COBOL?".   Again, this was probably due to this being the version on the mainframe they used.

With these two exceptions in mind, I still don't see why companies have lost interest in the latest version of the COBOL standard.  Ask a shop working with Java and you'll find out quickly if they are on 1.3 or a 1.6, etc.  Same thing with the .Net framework.  I guarantee you'll find out quickly if a company targets  the 2.0 or 3.0 version of the .Net framework.

But the COBOL version?  Maybe my imagination, but it doesn't seem to be that important anymore.

Could it be that everyone lumps every version into the same bucket?  Its all just COBOL right?

As many may or may not know, the last published COBOL standard was released in 2002.  There were a number of items in the 2002 edition related to Object Orientation which truely brought the language into the modern era.  From the notes on the COBOL Standards website, there are references to a supposed release targeted for 2008 which were supposed to move it even further forward.  I wonder what ever happened to that version.  Anyone know?  Why did it die on the vine?  I know for a fact the group still meets and is working on advancing the language.  But why has it remained unpublished?  Isn't it about time a new version was announced?

Oh well, I digress.

What I'm most curious about is your company's conformance to a particular COBOL version or published standard.  What version do you use?  Are there any elements of the 2002 standard that your company uses or conforms to?  Or are they tied to a vendor specific version of COBOL like Micro Focus or Acucorp?

A more basic question...Do you know what is in the 2002 edition of the COBOL standard?  You can find it at the ISO website just in case you were curious...

And one other question before I finish up on the topic.

If a new version of the standard were to be released on the world, what would it mean to you?  To your company?  From what I can see, it would be a safe bet that very little discussion would occur around the subject until somone needed to upgrade their compiler. 

Kinda like the "if a tree fell in the woods, would it make a sound" question. *smile*

With my limited knowledge of what is being discussed by the group, this may ultimately be a bit of short-sightedness if your company uses COBOL but isn't up on the subject.  There may be elements within the standard which would allow your company to save money or do more with the language.

All things considered, how would you propose the guys over at the COBOL Standards Group go about getting your attention?

What needs to happen to bring this to the forefront in your shop?

Just curious.


  1. The ANSI standard will only be relevant if they come up with improvements to the COBOL language. There is little in 2002 which is really a big benefit to an everyday COBOL developer over the ANSI89 adjunct. The OO implementation is poorly thought through and the exception handling is dire. PIC 1 is nice - but that is hard to implement with any degree of performance - which is exactly what COBOL is supposed to be about.

    When ANSI start to ask Business (as is Business Oriented) what COBOL should do ANSI will become relevant. They have it the wrong way around IMHO. It is ANSI's job to make its self relevant.

  2. Cobol 201x will have:
    - standard-binary and standard-decimal arithmetic according to IEEE Std 754-2008
    - Lots of bug-fixes to the 2002 standard.
    Just to name a few.
    The latter one cost time.Lots of ti.

    @Alex: ISO/ANSI have a problem: they want it all platform independent. And they lack resources in committees SC22/WG4 & PL22.4 (that's were it happens).

    @Robert: Hot standards, where people do know the version number, are driven by vendor (Java=Sun, C#/.NET=Microsoft). Older languages are like wheels: nobody knows the version, they're there and function.

  3. COBOL is the perfect implementation of the KISS (Keep It Stupid Simple) principle. COBOL is stable, does the job and backward compatible.
    Many years ago I tried taking MF's OO Cobol courses and they were all were canceled due to lack of interest. Few youngsters learn COBOL since it's not sexy. For myself, I developed windowing tools on mainframe before Windows came out, Application generators etc. all in Cobol, but most people just move fields from one place to another. Cobol is here to stay, but very few will enjoy new innovations implemented within.