Are 70% of programs/business applications/something based in COBOL?

Question

I heard this number and a quick google search reveals a whole lot of touting this number and absolutely zero data (honestly most articles promoting COBOL read like 95% propoganda). Perhaps it's true in an extremely limited context of banking software or something, but with millions of applications coded in dozens of languages and near-zero new COBOL projects I don't see how this is possible.

Is this a myth from the 70s (when it would have seemed entirely plausible) or is there some limited definition where this is actually true? I know there is a great deal still being maintained and I'm sure a large % of businesses have at least one COBOL program around, but this invisible 70% seems absurd.

Answer 1

The COBOL wiki page cites the Gartner quote, but there isn't a source from Gartner provided. It is all over the Net. 80% of businesses, 200 billion lines of code, 5 billion new lines of code each year. Some places, the numbers vary a bit. However, one number is almost always missing from that Gartner quote on the COBOL wiki page, and missing number is the year. 1997. Let's assume the quote was true, in 1997.

I have worked in COBOL for 20 years, and for the last 13 years I have witnessed COBOL development disappear.

ERP solutions? The last one I know of that had at least some COBOL in the product was PeopleSoft, when I talked to PeopleSoft reps at an IT conference in 2004. I was working for the UW at that time, and I talked to literally dozens of people, maybe upwards of 100, from universities all over the country. A very common story was repeated. "We replaced our homegrown ERP solution, written in COBOL, with " PeopleSoft, Oracle, SAP, SunGard. Delve into the careers links of those companies, and look at IT positions. See if there is any mention of COBOL, DB2, CICS, etc.

Healthcare? Well, I worked for GE Healthcare for 3 years, and they were among the last hospital clinical software vendors writing in COBOL. 3 big layoffs in 3+ years, an office that dwindled from 600 employees to under 300 employees, clients converting to Epic or Cerner. Not a very bright future for COBOL there. Neither Epic nor Cerner writes in COBOL. Check out their career pages. McKesson appears to still be written in COBOL, but I see a number of hospitals converting away from them as well.

State and federal government might end up the last bastion of COBOL, but some of those projects have gone away. Completely replaced with .NET or Java.

At 44, I'm one of the youngest COBOLers I know. Oh, there are 5 or 6 I know who are younger than me, but the 100 or more others I know are probably on average 10-15 years my senior.

IBM 390 and zSeries, HP NonStop, Unisys 2200, and Unisys MCP are the big iron boxes out there running COBOL. Every one of them supports Java development. From what I have read and know Java on big iron, which is mostly limited to the HP NonStop, if it is done right then Java can replace COBOL over time.

There have been efforts, that I know of or worked on, since 1994 to replace clunky mainframe green screens with GUI front ends written in VB, .NET or Java.

A lot of COBOLers I talk to who are certain of COBOL's future are out of work, like me, and aren't finding work. Best shot I have is a state gig where there are likely more than a couple of people within a few years of retirement. Assuming I get in, I expect over the next couple of years my role will evolve into how to clean, efficiently, and without interrupting the business administer a lethal injection, figuratively speaking, to COBOL through step by step replacement.

Finally, back to Gartner. They charge for everything they publish, and it ain't cheap. But venture over to Gartner.com, set up a free account, go to the Research tab, and search on the keyword COBOL. You won't get the whole article, but you will get a summary and a snippet. Reading and analyzing Gartner's work, I think it's very clear they are signalling the death of COBOL.

Answer 2

Depending on how you define the 100%, that number might be correct. For example, it might very well be that 70% of the programs written for banks and financial institutions until 2010 is based in COBOL. Wouldn't be surprised.

But I don't think that it is a fair statement to say that out of all the software in the world, 70% would be written in COBOL. Frankly, I don't know if you can even measure it.

Answer 3

the Gartner Group reported that 80% of the world's business ran on COBOL with over 200 billion lines of code in existence and with an estimated 5 billion lines of new code annually. Source is: COBOL-1.

I have no idea how do they count these numbers. I worked in several companies where no one actually tried to count all lines of code in one shop accurately, even when it was used as a measure of complexity. So how did they come up with these numbers?

COBOL is alive and well. It is not true to say that there are zero projects starting using COBOL. Remember that lots of the enterprise projects are interdependent. Unless there is a reason to extend a project in a different language you use the original architecture and software. Remember that most of such systems are large and re-writing them in a different language is risky, expensive and usually adds little or no value to the business.

There are many resources on the net that tells us that COBOL is alive and well.

Answer 4

I think these figures date to about around 1997 when the Y2K "problem" was the hot topic in IT (especially sales people out to make a quick buck!). At the time there were some serious attempts to find out how much COBOL/C/C++/Java/VB etc. code was actually running to get a grip on how much work was required. It came as a shock to people how much of the worlds code base was COBOL.

I would expect this figure to be a lot less now, partly because of the long slow decline of the COBOL but mostly because there is a lot of code been written in other languages since then. Just think, php, barely existed in 1997.

Answer 5

First of all, these estimates are dubious. Secondly even if you'd assume that the numbers are correct, the estimates are based on lines of code (LoC) metric. COBOL is extremely verbose, so you need an order of magnitude more code to achieve same thing. Consider "hello world" in 3 programming languages:

Python:

print "Hello world!"

C:

#include <stdio.h>

int main() {
    printf("Hello world!\n");
}

COBOL:

000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. HELLOWORLD.
000300
000400*
000500 ENVIRONMENT DIVISION.
000600 CONFIGURATION SECTION.
000700 SOURCE-COMPUTER. RM-COBOL.
000800 OBJECT-COMPUTER. RM-COBOL.
000900
001000 DATA DIVISION.
001100 FILE SECTION.
001200
100000 PROCEDURE DIVISION.
100100
100200 MAIN-LOGIC SECTION.
100300 BEGIN.
100400     DISPLAY " " LINE 1 POSITION 1 ERASE EOS.
100500     DISPLAY "Hello world!" LINE 15 POSITION 10.
100600     STOP RUN.
100700 MAIN-LOGIC-EXIT.
100800     EXIT.

Answer 6

I have previously worked at a (largish) bank, and there COBOL was used for all core banking logic, with anything outside of that being done in either Java or C#. Although it's impossible for me to be sure about exact lines of code, I believe the 70% claim to be extremely dubious, in my experience. It is possible COBOL is more verbose as vartec points out above, but in terms of functionality implemented, the Java and C# "auxiliary" software was handling far more.

As a a typical example, the COBOL code was in charge of actually creating accounts, calculating interest, generating basic statements, as well as business rules around managing of the state of an account (access / valid actions). To be fair, that's not an insignificant amount of code - but compared to this, the "auxiliary" software was in charge of everything from receiving faxes, document splitting indexing, document storage / management, routing work to individuals, several thousand (sadly, yes) screens for data capture and managing the lengthy lifecycle of various processes that end in account creation, electronic interfaces to other companies and legal services, integration with the telephony platform, and many, many more functions.

Looking at it from this angle, I am fairly sure that the number would have been in favour of the Java / C# code, but again, I don't have any hard numbers to back up this claim.