Should we still use COBOL?
Tom.Ross 12000087AJ Comments (6) Visits (10549)
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
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. 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, 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.
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 an official 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:
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 prog