Search This Blog

Thursday, September 3, 2009

COBOL: It's Everywhere

The plethora of anti-COBOL articles on the web has prompted me to write this article. I have heard for years that ‘COBOL is dying’ or ‘COBOL will be dead soon’ and yet here it is 20 years later and guess what, COBOL is still going strong! I’ve been coding COBOL since roughly 1991 and have met quite a few COBOL developers over the years. I am now working for Micro Focus, the leading Enterprise Application Management and Modernization Company with over 1500 employees worldwide. While our mission has expanded significantly since our birth in 1976, our roots are firmly in the COBOL environment.

I know that’s not what some of you may want to hear but it’s true. COBOL is still doing the heavy lifting of the business world and will continue to do so for many, many more years to come. (I’m betting well into my non-existent grandchildren’s careers!)I’d like to discuss in this article why COBOL has continually received a less than equal opportunity in the market-place: Lack of knowledge as to what COBOL is, has become and can do. I’d like to address these issues one at a time.

What COBOL is
COBOL was originally developed in 1959 by Admiral Grace Hopper for the Department of Defense. It was the first language developed that enabled a person to utilize a ‘normal’ language style to create applications to run on a computer. Prior to that assembly language was the prevalent language utilized. COBOL, as you may know is an acronym for COmmon Business Oriented Language, the emphasis being on business. It is utilized in every industry around the globe from telecommunications, banking, finance, manufacturing, government, aerospace, security, and many more too numerous to mention. Micro Focus asked one reporter to live for one day without using COBOL and it couldn’t be done. It is everywhere. So why then does it receive such a bad reputation if it’s so widely used? One would think the prevalence of COBOL would make it quite popular. One of the main reasons is the environment in which a COBOL developer has to operate in. The majority of COBOL is found on mainframe based systems (IBM, Fujitsu, Hitachi, and DEC) that have a simple character based user interface (UI). Costs to maintain these systems are usually quite high and priority is given to the applications running the company, not the developers creating or maintaining them. So to add to a less than robust UI we have low priority which translates into long times to edit, compile, and test programming changes. All this means developers get frustrated and start looking for something other than mainframe (COBOL) based development, but they take their frustrations with them when they leave thus spreading the word that COBOL is a dead-end or brain-dead world. Nothing however can be further from the truth.

What COBOL has become
COBOL has grown significantly. Do you know it is the only computer language that has evolved through multiple standards? Over the year the ANSI Committee has continued to expand and refine the language through several different standards and continues to improve the language to keep up with the growing technology.

Does C, C++ or Java have a standard that compiler vendors have to adhere to? I seem to recall a recent analyst's review of languages which listed COBOL as "stable and mature" while Java and a few others were actually considered to be in a declining state. That is a trend that continues to occur with many of the "popular" languages out there, but not COBOL. COBOL has grown to match the needs of the business and is one of the most portable languages around. A program compiled on a mainframe can be, if no machine specific instructions are included in the code, moved to a Windows, Unix or Linux platform, recompiled and utilized for what it was intended to.

COBOL has evolved into a multifaceted tool that could be utilized for a number of solutions from web to web-services to client-server applications. However COBOL was intended to process large amounts of data in an efficient manner (efficient in CPU, memory and storage usage). COBOL was not designed to manage a UI. While it has evolved into a graphically capable interface there are other languages such as C# or VB.NET that were designed specifically to create the users interface. Why not leave COBOL to do the heavy lifting of the transaction and provide the answers to the questions the application is meant to answer? After all, it is the original COBOL that was developed by a business analyst to answer a specific business problem. Let COBOL continue to perform the job it’s been doing along, helping companies be profitable.

What COBOL can do
Web Services, web sites, code-behind, XML data read and write, client-server applications, data transformation, .NET integration, Java integration, Visual Studio.NET, Eclipse, recursive calls, pointers, arrays, bit level data manipulation, write once run anywhere, WPF, WCF, ASP.NET, 32-bit and 64-bit, ActiveX, ADO.NET, Assemblies, Call the Windows API, CGI, COM, CORBA, DBCS, dynamic linking, file conversion, floating point, HTML, ISAPI, memory management, mouse manipulation, multi-threading, National Locale Support, Object Oriented, ODBC, OLE, parsing, spawn processes, SQL – DB2, Informix, ODBC, Oracle, SQL Server, Sybase, UDB, stored procedures, Unicode support, XML formatting and parsing to name a few.

Is there something not mentioned above? Let us know and we’ll probably be able to provide an example.

A recent blog post I’ve seen claims COBOL is “…so very, very dead.” I think that is still 30 years away at least from being true. As long as smart decision makers look at the options and take the lowest risk, highest return approach by letting COBOL do the job for which is was intended (high volume processing of data to pay the bills and keep the world running), COBOL will be around a long time. Don’t bash it, don’t underestimate it. Embrace it and use it for what it was intended to do, getting high volume business processing done!

Happy Coding!


  1. Nice article; however, I think that you dance around one point. COBOL is a verbose human centric language. This is not actually a disadvantage because this syntactic structure has allowed it to evolve. Other languages like C, C# and Java etc. have ended up digging them selves into holes because they start out terse but then have no room to evolve. An example which I find illustrative is lambda syntax in C# which is just a pile of symbols grafted onto the syntax tree of the language.

    Natural languages are verbose and flexible in structure. My son is studying Chaucer. The language there is 700 years old but still readable with some effort by a native English speaker. English just evolved, it was not replaced.

    I suspect COBOL can continue its life indefinitely if people continue to evolve it. I am not sure that any of the other major programming languages around at the moment have that opportunity open to them. Who knows?

    - AJ

  2. Hi Rick, it is good to see your blog post. I will of course subscribe -- Perhaps I can be the pesky .NET guy that harasses you for loving COBOL so much :).

    So about your post... I agree with you that COBOL is not dying. It will be around for many many years. Even though more and more companies will migrate their legacy systems, it still is not practical to port the COBOL source to a different language. Why would you, it simply does't make sense.

    That said, I do think that we are going to see less and less NEW code written in COBOL. So I guess it all depends on what people consider a "dead" language. It isn't going anywhere anytime soon - there is simply too much of out there - and there are still many COBOL developers out there actively coding in COBOL.


    - Bob Lair

  3. Not to detract from COBOL, but to set the record straight: There are standards for C, C++ (ISO 14882:200

  4. Sorry about my previous incomplete post...

    Not to detract from COBOL, but there actually are standards for C (ISO 9899:1999), C++ (ISO 14882:2003) and Fortran (ISO 1539:2004). I don't know about Java; a quick search turned up an article about Sun giving up on a Java standard (and that was before Oracle bought Sun).

    The comment about COBOL being easier to extend than, say, C++ is right on. Remember the '&' in a reference declaration? Are you ready for the next C++ standard's "rvalue reference" syntax, '&&'?

  5. Louis, Thank you for the information. I will be sure to make a note of it and not make that mistake again.

  6. As a career COBOL programmer, I have to say, I WISH COBOL would die out. Honestly. There are a great deal of shortcomings in the language, IMO.

    And to address my point, I think I have to look at the lowest common denominator of the language: MVS mainframe COBOL.

    Local variables? Recursion? Not possible. Robust string or date manipulation or calculation. Nowhere to be found. It's just not a do-everything language. I have heard tell of OOP in MVS COBOL, but I read half a page of the specs and passed out.

    Now, I don't disagree with you that COBOL isn't going anywhere. But that's more a factor of inertia than anything else. Companies simply don't want to foot the bill for re-engineering their bread-n-butter.

    However, COBOL is being taught less and less in schools. So as the current crop of COBOL programmers in the world die off or retire, there will be more and more programmers coming into the workforce that cry out for a different language. I don't know what that language would be, but eventually keeping a COBOL shop staffed will become more expensive than getting a passle of Java (or C or whatever) programmers and rewriting the works. I think it's inevitable, but I have to agree... give it a few more decades at least.

    I have to ask about your statement "A program compiled on a mainframe can be, if no machine specific instructions are included in the code, moved to a Windows, Unix or Linux platform, recompiled and utilized for what it was intended to." Aside from your employer, Microfocus, how can this be done? And what are you considering to be "machine specific instructions?" I ask because my holy grail would be a PC COBOL compiler (and, hopefully, an API/UI for debugging) that would indeed use mainframe COBOL code without a rewrite, and vice-versa. But alas, I think that you are including "reading or writing a file, particularly a VSAM file" as machine-specific... but then file operations are pretty basic stuff to ANY programming language, no? So this cuts COBOL off at the knees as far as a migratable language.

    Oh, and before you go down this road, there's no way in God's green earth that I would be able to convince my "handlers" to purchase Microfocus. I would love to have it, but it just ain't in the cards, sadly.


  7. Hey Mike,

    Your comment of "...a few more decades at least..." seems like a pretty good reason to continue working with the COBOL language. I really can't see Java or C++ having any dominant presence in "a few more decades". Especially when Java itself is already on the decline. And new developers would probably work in C# before they would jump into C++ nowadays.

    When was the last time you heard of someone doing Powerbuilder on a new project? Or Delphi?

    I think all languages tend to reach a level of declining viability due to the companies or individuals who support it. Good news it that with companies such as Clerity, Micro Focus, Fujitsu, CA, and IBM all supporting the language, I'd say it has a decent amount of life left in it.

    You pick MVS as the lowest common denominator. I would probably agree the total lines of code on that platform are significant. However, it would probably surprise you to find out how much non-mainframe COBOL there is in the world...

    Personally I feel knowing COBOL for the foreseeable future will keep me employed. Paycheck Good, Unemployment Bad. *grin*

  8. I'm sure you are correct that I would be surprised to know how much non-mainframe COBOL is out there. But I don't think I'd be TOTALLY surprised. :-)

    Like you, I don't see myself throwing away my COBOL paycheck. But I also believe that there are different tools for different jobs and I try to have as many tools in my bag as I can. You never know. There may be some huge issue with COBOL in the near future and everyone will be clamoring to convert. Probably not going to happen, but stranger things have. And it is nice to have a broader knowledge of programming as a whole, not limited to one or a few languages.

    So, as I write my own suite of tools to dissect JCL and allow me to make grand manipulations of it, I am not going to write it in COBOL, which would take hundreds of lines just to get the syntax parsed, when a few dozen lines of Perl do nicely.

    As well, I doubt you'd find any graphics-intensive programs (games, etc.) written in COBOL.

    As I said, I think the Holy Grail here is a language that is truly cross-platform. Or maybe I'm barking up the wrong tree there. Perhaps we really need an OS that's truly cross-platform. I mean, after all, we do have Linux on our mainframe where I work (we lowly application programmers just don't have access to it).

    But I do see your point... there is probably a far greater installed base of COBOL code than there is for any other language. C might come close... but I'm not sure.


  9. I just found an interesting article which provides some real numbers to the number of COBOL developers, etc. out there in the world.

    An interesting read...