Should Banks Let Ancient Programming Language COBOL Die? (thenextweb.com)

COBOL is a programming language invented by Hopper from 1959 to 1961, and while it is several decades old, it's still largely used by the financial sector, major corporations and part of the federal government. Mar Masson Maack from The Next Web interviews Daniel Doderlein, CEO of Auka, who explains why banks don't have to actively kill COBOL and how they can modernize and "minimize the new platforms' connections to the old systems so that COBOL can be switched out in a safe and cheap manner." From the report: According to [Doderlein], COBOL-based systems still function properly but they're faced with a more human problem: "This extremely critical part of the economic infrastructure of the planet is run on a very old piece of technology -- which in itself is fine -- if it weren't for the fact that the people servicing that technology are a dying race." And Doderlein literally means dying. Despite the fact that three trillion dollars run through COBOL systems every single day they are mostly maintained by retired programming veterans. There are almost no new COBOL programmers available so as retirees start passing away, then so does the maintenance for software written in the ancient programming language. Doderlein says that banks have three options when it comes to deciding how to deal with this emerging crisis. First off, they can simply ignore the problem and hope for the best. Software written in COBOL is still good for some functions, but ignoring the problem won't fix how impractical it is for making new consumer-centric products. Option number two is replacing everything, creating completely new core banking platforms written in more recent programming languages. The downside is that it can cost hundreds of millions and it's highly risky changing the entire system all at once. The third option, however, is the cheapest and probably easiest. Instead of trying to completely revamp the entire system, Doderlein suggests that banks take a closer look at the current consumer problems. Basically, Doderlein suggests making light-weight add-ons in more current programming languages that only rely on COBOL for the core feature of the old systems.

Comments

BUGS

[AK Marc]

COBOL is simple. It is also relatively limited. This makes it easier to track, troubleshoot, and maintain. With Banks, accountability is more important than functionality.

Hopper? No. She's the grandmother of COBOL

[quarrel]

Grace Hopper did not invent COBOL. Follow your own links - there is a whole list of who designed it, and none of them are Grace Hopper. She did lay lots of the foundations they worked upon of course.

To the question of should they replace it? About the same time as any other language should be replaced - it is a very silly question...

Re: What is needed..

[techno-vampire]

Cobal is a crazy nuanced language that is hardware specific.

Absolutely wrong. One of the language's biggest selling point when it was first created is the source code is completely hardware agnostic. To demonstrate this, the developers compiled the same program (from the same deck of punched cards) on three different brands of computer, ran the program with the same deck of input data and got the exact same results. The only change they had to make was one card in the Environment Section, and all that card did was specify the target machine.

Re:What is needed..

[CaseCrash]

I couple of years ago I worked at a place that has an automatic converter from COBOL to C#/VB.Net (followed by an insane amount of testing and fixes to the converter/custom fixes for their code) and we handled all kinds of businesses including banks (I got to spend three weeks in Belgium helping out on the ING project). So people are already doing this.

(FYI, the company is Asysco)

Re: COBOL isn't hard to learn

[TheRaven64]

That's the second post I've seen saying that COBOL has no unicode support, yet COBOL 2002 added unicode support and is widely supported (COBOL 2014, less so). If you're running on an IBM system, a bunch of the COBOL unicode operations are accelerated in hardware.

Re:COBOL isn't hard to learn

[TheRaven64]

Given that most of this code was originally targeting systems from the 1960's and 70's, I can't imagine there being an insurmountable number of lines of code

According to Wikipedia, Gartner estimated about 200 billion lines of COBOL code in 1997. To put that in perspective, that's more than the total amount of open source C code tracked by OpenHub.net. Can you imagine persuading someone to rewrite all of that C code in a newer language?