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

Found the LUDDITE!

[Anonymous Coward]

Only LUDDITES use LUDDITE COBOL! Modern app appers use AppScript and AppApp to app apps!

Apps!

Re:What is needed..

[msauve]

What's obviously needed is a COBOL -> APL translator to convert all those programs into a newer language.

Re:COBOL isn't hard to learn

[Z00L00K]

SAP is more likely to go the way of the dinosaurs than Cobol.

Which reminds me of this joke:

In 1998, a programmer who had been working on Y2K fixes started to get anxious because he couldn't believe how pervasive the problem was. He switched from company to company trying to get away from it, but everywhere he went he became regarded as the Y2K expert and immediately became the team lead for that company's Y2K contingencies. He finally had a nervous breakdown, quit his job, and decided he wanted to be knocked unconscious when the Y2K actually came about.

A month before Y2K he was put into an artificial coma and cooled down to a near cryogenic easily sustained long term life support.

Unfortunately the life support notification system had a Y2K bug, and no one revived him for 8000 years.

Finally he was found and revived. He woke up, and saw himself surrounded by lots of glass, light, stainless steel, and tall beautiful people in white robes. He asked if he was in Heaven.

They replied, "No, this is Chicago. Actually but it's a lot like Heaven to someone like you."

"Someone like me?"

"You are from the 20th century. Many of the problems that existed in your lifetime have been solved for thousands of years. There is no hunger and no disease. There is no scarcity, or strife between races and creeds."

"What year is it now?"

"Yeah, about that - it's the year 9,998. You see, the year 10,000 is coming up, and we understand you know something called COBOL?"