About the author
Tom Ross has been a developer working on IBM COBOL compilers for over 40 years. One of his coworkers in IBM gave him the nickname “Captain COBOL” since he seemed to be able to answer ANY question about COBOL. He spends his time writing code, presenting COBOL topics to user groups such as SHARE, and helping customers with any questions or concerns about COBOL including migrating to newer versions of COBOL compilers.
Table of contents
Should we continue to use COBOL?
Isn't it old and outdated? Many people are saying that COBOL's time has passed, that we should convert applications to Java/Groovy/Swift/Node.js/'your name here', so are we making a mistake by staying with COBOL?
These are common questions, and have been asked in different ways for over 30 years! In this blog I will approach the topic of "Why COBOL" from several different angles. First, some history...
I believe that COBOL was first declared DEAD in 1969, when IBM came out with the ultimate programming language, Programming Language One, or PL/I. In the late 1970s and early 80s, many Universities taught only PASCAL. By 1990 it was clear that C would take over, COBOL was once again declared dead. In 1995 the buzz was all about C++, but by 1998 all code would be rewritten in Java! Then Microsoft came out with C# to compete with Java, but it only runs on Windows/Intel. Then came Ruby on Rails and Groovy as replacements for Java, and Java was declared dead. By this time, of course, COBOL was long since buried, no one was using it....or were they?
Of all of the programming languages at our disposal, only COBOL was designed from the ground up as a language for business use. Fortran was designed for scientific purposes, PL/I was designed to do everything, C and C++ were mostly used for system programming, Java is used in a lot of Web and Mobile apps but its strength has never been number crunching or record processing. For number crunching and customer data processing in banks, insurance companies, large-scale manufacturing and government, COBOL was (and is) the language of choice. Why is this?
For many businesses, the key elements of data are customer information, account information, and currency processing (either dollars and cents or Euros and euro cents or many other currencies). COBOL is ideal for defining such data structures and data types. In fact, you can have data items (variables) defined with dollars and cents in COBOL using data types external decimal (zoned decimal or character type numeric), packed decimal, binary, or even non-numeric types such as numeric-edited! COBOL is expert at handling character strings, fixed and variable-length records, conversion from character to numeric data, etc., all commonly needed to process business data and business processes.
When you go to the bank or ATM and withdraw cash, you are most likely running a COBOL transaction! I can't resist a shameless plug for z/OS and CICS here...let's compare the number one transaction monitor on z/OS to something else that you have heard of...Google! There are at least 1.1 million CICS transactions run every second of every day! Surely Google searches can beat that? Nope...there are only about 59,421 Google searches every second globally. By the way, a large majority of CICS transactions are written in...you guessed it: COBOL.
Think about it...more than one million COBOL programs run every second of every day on mainframes, while Google searches on all those phones, tablets and PCs can only come up with 60,000 or so. Amazing!
OK, let's get back to technical comparisons of programming languages. It is true that you can do business processing in other (non-COBOL) languages, though not as easily. In fact, you can do system programming with COBOL, though it is not the strong suit of COBOL. The point is, you can make anything get the job done if you're willing to spend a pile of time and money, but which tool makes sense for which work? If the work is business processing with customers and accounting, COBOL is still the best choice.
Many IBM customers who run their businesses on COBOL (and that is MOST Fortune 1000 businesses) encounter the question of "Why COBOL?". New, up and coming executives come in from college and have never heard of COBOL or mainframes, and try to push to change everything to something that they know. They start out by questioning the choice of COBOL, even z/OS! Sometimes, entire IT organizations start wondering about the company direction. This can really detract from actually running the business.
When compared with Java (Groovy, Node.js, Go, etc.), COBOL is better in that it is self-documenting, is a natural string-processing language and can do fixed-point arithmetic. Those are all requirements for business processing. Having said that, a shop that is writing most of its code in Java should not switch to COBOL, and a shop that is writing most of its code in COBOL should not switch to Java! If there is a COBOL base (where most applications being written in COBOL), then the customer should stay with COBOL. This includes writing new applications in COBOL, since all of the developers would have to know COBOL anyway. Staying with COBOL might mean training new hires in COBOL, but COBOL is easy to learn. I learned it without any classes at all, so I assume others can too! Finally, changing horses mid-stream is usually not a good idea, and COBOL is strong, keeping up with the times (Vector packed decimal instructions, JSON processing, UTF-8, etc) and is a great horse to stay on!
A large bank in the Netherlands called Rabobank had this exact situation. Lots of time was wasted discussing and arguing technical direction, but no decisions were made. Finally the company launched anofficial inquiry and study: What hardware/software platform should we be using, and what programming language for our payments system? They looked into all of the solutions in use today, debated pros and cons and finally settled the question once and for all in about 2010: the best possible way to run a bank is with COBOL applications running on z/OS. They stopped wasting time arguing and got down to the business of running their business, on COBOL. A quote from them "Massive volumes + High availability + high security: z/OS + IDAA + Datapower+ COBOL is unbeatable".
How about some other ways to look at programming languages?
There are many aspects to a successful and useful software application. Some of them are:
- efficiency (CPU and storage resources)
- adaptability (ability to handle problems)
- maintainability (ease of updating and fixing the code)
Since COBOL was designed for business processing, it is very efficient. In fact, many IBM customers have tried replicating their COBOL processes in other languages, with COBOL always the clear winner.
Adaptability is a matter of how the code was written, and I do not think that there is one language better than another here, though COBOL has some unique capabilities. Most languages have some sort of overall error checking, such as PL/I ON-units, errno for function calls in C, try/throw/catch in C++, or user written error handlers with COBOL. A programmer can write error-tolerating code in any language! However, in addition to overall error handling, COBOL has per statement error handling features, such as ON SIZE ERROR, ON EXCEPTION, and ON OVERFLOW. COBOL also has abilities to validate numeric data (NUMERIC class test), alphanumeric data (user written class test with CLASS clause), UTF-8 data, XML documents, and JSON texts!
Finally, maintainability. At some point in their careers, most programmers have been given the task of updating or fixing a bug in code that someone else wrote. If the originator (or earlier owners) of the code did not document the code, it can be very difficult figuring out what the code is doing, or even more difficult, WHY the code is doing it the way that it is! One of the features of COBOL is that it is difficult to write mysterious code in COBOL. It is more wordy than other languages, but that is actually an advantage! Just writing COBOL is writing the documentation at the same time! I can write a C program that can hide its intentions and obfuscate the algorithm, but I cannot do that in COBOL. (I know some programmers like writing tricky, hard to understand and challenging code, but businesses rarely want their company running on code like that!) COBOL was designed to be able to be understood by non-engineers, so that engineers find it very easy to read and understand. This makes maintaining or extending old COBOL programs very easy and safe. No wonder COBOL is still the King of the programming languages for business programming!