Banks Should Let Ancient Programming Language COBOL Die

Megalith

24-bit/48kHz
Staff member
Joined
Aug 20, 2006
Messages
13,000
I thought that if something ain’t broke, you shouldn’t fix it, but some think that the programming language that powers banking systems should be replaced with something a bit more modern. The argument is that only old geezers know COBOL, and we may be in for a little upkeep problem since they aren’t going to live forever. So what, exactly, is preventing younger folk from putting that language on their resume?

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. Döderlein 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.
 
So what are the advantages of COBOL over something like C or C++?

EDIT: wow, the syntax of COBOL seems really English-like.

http://jeffsutherland.org/papers/oocobol.html

That site claims COBOL doesn't have to deal with memory leaks, which was a big part of my previous job, chasing down memory leaks in C code.
 
I know COBOL was still part of all the programming, network, and computer science degrees at our local state university 8yrs ago, not sure about now. And it was exactly for this reason, there's still significant demand, and several large financial services institutions had operations in local area.
 
There is nothing wrong with COBOL. The only disadvantage to COBOL is it is very wordy. It lacks libraries for doing scientific type calculations, but other than that everything you can do in C or C++ is possible in COBOL. Furthermore, people who say COBOL should be replaced have no idea of the scope of the situation. It would be far easier to go to educational institutions and pay for them to offer classes in COBOL and offer graduates guaranteed jobs than to even begin replacing COBOL programs. You will see no performance improvement by moving from COBOL, the only thing you will get is a larger programmer base. For any decent software engineer learning a language is simple, it's the coding part that is hard... not the syntax.
 
You don't replace bulletproof mainframe code "just because", you draw the line in the sand where you won't modify it any more and future development has to take a different path, which is what is happening and has been happening for the past decade or more. Cobol is alive and well in big-business so long as the mainframes run. The only thing replacing mainframe/cobol code gets you today is a pandoras box of brand-new problems for you to solve. Now, if the mainframe is dead or you need to replace hardware, THAT is when you seriously talk about developing a parallel system and then, when it's bulletproof, you flip the kill-switch on Cobol.
 
As far as memory leaks, morgwon is right that was 1995. In 2002, they introduced pointers, heaps and garbage collection... just like you find in any C-style language.
 
You don't replace bulletproof mainframe code "just because", you draw the line in the sand where you won't modify it any more and future development has to take a different path, which is what is happening and has been happening for the past decade or more. Cobol is alive and well in big-business so long as the mainframes run. The only thing replacing mainframe/cobol code gets you today is a pandoras box of brand-new problems for you to solve. Now, if the mainframe is dead or you need to replace hardware, THAT is when you seriously talk about developing a parallel system and then, when it's bulletproof, you flip the kill-switch on Cobol.

So much this.

They'll train people before the attempting to replace all the backbone systems their operations rely on. The sheer scale of doing so would require trillions in investment across the financial system, and no one wants that hurting quarterly results. I know the company I work for has been looking for about a decade for a company that could replace most of our stuff, but haven't been able to find anyone up to the task, it's proven too complicated a web of disparate systems feeding one another for any of the big names to handle, or want to handle. Now that they've consolidated so much and spent a ton of time and money on getting some consistent interfaces and systems for some tasks they've dramatically cut down on the number of ways information would need to be passed around different operational areas so I'm sure they'll find someone in the next decade or 2.

Just updating our billing system, which interacts with all the background data coming out of COBOL systems has taken 5yrs thus far, that's using 90% of an off the shelf product. It will take another 3 years(I'm being optimistic) before it takes over all the billing company wide, vs. the 8(at least) different ones used across different product lines currently. Even still we lose a ton of customer centric capabilities/flexibilty we had with our previous systems, but that's what simplicity and consistency get you, and then far less human input is needed because hey "we can't do that" when the customer asks.
 
COBOL is REALLY easy to learn. It took me a day as a college student, though I had previous programming experience, but that's what they'll do today. Banking needs simple because simple is fast. COBOL was built to be simple and fast because transactions needed to happen fast. The goal in the 1950s/60s was for electronic transactions to never take more than one second. Yes one second! Perhaps modern banking needs something more advanced but I doubt COBOL can't handle whatever they need.
 
What's worse is the dependency on FORTRAN that a lot of the government uses, which I think I'm one of like 3 people under the age of 35 know how to write code for.
 
Welcome to batch processing. Every night 10's of millions of events must be processed, data files created and handed off. There is a relatively small window in which to accomplish this. Mainframe COBOL gets this done day in and day out with almost no downtime and no errors. When maintenance exceeds replacement cost a migration might happen. We have not hit that inflection point yet. When I worked at [REDACTED] we studied this. Everyone shuddered when we estimated a floor of 500 million in project and hardware cost to replace the books and records that resided on the mainframe. That was 15 years ago and only a single core system.
 
It's a good thing computer science majors do not also control written language....or else we would all have to learn a new language every 5 years just because. Want to make a webpage? Use perl. No use ruby. No use ASP.net. No use python. No use PHP. And if you disagree, you are a complete idiot!
 
My organization is still based around AS/400 with RPG programming, our programming department are all like 50+ year old
 
Don't go bonkers over syntax. I was schooled in one language, but I've had to learn a good dozen to do my job. People will figure out the language if the need arises. What matters is knowing what you want the program to do, and the rest is just figuring out the syntax to do it.
 
So due to the fact that COBOL was pretty much a mainframe based programming language, would it be safe to assume that most major banks still use mainframe type setups? I assume they're a lot smaller these days?
 
Sort of related to this, I have been teaching two family members who expressed "I wish I learned to program in College rather than x" how to program in JavaScript. I chose JavaScript mostly because there are online playgrounds where I can have them create things that they will see instantaneous results, plus in terms of syntactic structure is similar the majority of languages. I have been using them as a bit of an experiment, one has a degree in anthropology, speaks 7 languages and is very artistic... the other has a nursing degree. Neither have self-confidence in anything tech related.

My focus has been to first nab their attention, teaching them basic elements of writing code that will give them immediate output... i.e. drawing functions. Then introducing them to logic and conditions, each time with the focus of creating something visual. The end goal is for them to create a web based game ala flappy birds then migrate the game over to Swift and recreate the same thing in another language. As they have been learning, I have been swapping out and in different APIs, so they are getting very familiar with subtle changes in the code. At this point I would say they are probably about as good as half the front-end developers I've worked with over the years. I have been teaching them data structures, without telling them it is data structures because they both freaked out when I started with a mathematical description. In some ways, I am learning more about programming because I have to think about it in a different way. It's also entertaining to teach someone about math, without them realizing they are doing math.

In about another 3 months I pretty sure they will be on par with 90% of developers. As we have been working on these projects, they have been learning GIT, Agile development (because it's how I have them tackle each project), Jira, Node.js etcetera without them realizing these are "marketable skills". I only encourage them to code 1 hour a day and for the last few months, I check in every day and discuss what they did. The artistic one, my Sister, will say stuff like "the boys were sick, so I barely had time to get an hour in" and I will look at what at she created and I will sit in awe of both what she is able to churn out and how fast she picks things up. I have no doubt both will able to bounce around from language to language without a problem. I only wonder how far I want to take this. Frontend and Database design is easy enough to teach, but backend code may be pushing this experiment too far.
 
When I entered college in 1988, and was part of the CiS program, COBOL was the main thing we were taught.

Needless to say.... I never found a practical use for it in my life, but I bet if I could remember it all now, I could get a pretty nifty paying job.

Oh well.... ;)
 
What's worse is the dependency on FORTRAN that a lot of the government uses, which I think I'm one of like 3 people under the age of 35 know how to write code for.

Heh. You wish. I'm in my 20's and regularly work in Fortran, and occasionally write COBOL. I avoid COBOL if at all possible, but at this point I don't mind using Fortran vs. C for mission-critical tasks. C has marginally more creature comforts, but I write better Fortran :D

I also question the notion that these legacy languages are hard to learn. If someone has some background in JS or C++, it shouldn't take more than a week's training to bring him/her up to speed in Fortran or COBOL. If there is enough demand, people will learning anything.
 
When I was in college, my class was the last that they were teaching COBOL to.

Not the newer version of COBOL that has OOP built in, but the old COBOL which was an actual super pain to program and get the results you wanted without having your teacher be able to break it with his specially crafted data sets designed to break your code.
 
My Army job had me learn COBOL in 1991. Got my first duty station, didn't use it. Second (last) one, same thing. LOL
 
it doesn't matter if anyone can learn COBOL, it is do they already know it inside and out to fix an issue if said person takes over. If the entire banking system was to go on its ass do you want to wait for somebody to learn COBOL then start trying to fix the issue or do you want a person that can jump in and already knows the system.

Biggest issue I see is that COBOL being such an obscure language few are going to learn it since it doesn't get you a job anywhere. Those that know it have had their jobs for 40+ years so you aren't going to have 22 year olds being able to jump into that job after college like they could anywhere that does web, a visual studio language, or java. If anything they need to bring in a few younger programs and start teaching them and getting them familiar with the programs. Although one has to wonder after this much time does much really change or it is more of just support now.
 
COBOL and FORTRAN are still around because they do what they were designed to do very well. Given the size of the installed code base, by the time you pick a modern solution, analyze the existing code, implement 'just a few changes while you are at it', test, validate and deploy, what ever language you picked would likely be considered outdated when you deployed your 'new' system. Might as well keep the outdated languge you have now. Unlike your average game that can be patched many times after deployment, for some strange reasons, folks expect their bank software to work perfect the first time and every time.
 
We had to write an outline for, then program, a text-based game in COBOL when I was in high school during the early 90s. We only spent a week on the COBOL portion of class, and it was rather easy.

That's why COBOL is still in widespread use.
 
Last edited:
Last time I heard a company use Fortran was in the early nineties when I was just a child. Cobol I don't even remember ever hearing about or seeing it used in action.
 
So what are the advantages of COBOL over something like C or C++?

EDIT: wow, the syntax of COBOL seems really English-like.

http://jeffsutherland.org/papers/oocobol.html

That site claims COBOL doesn't have to deal with memory leaks, which was a big part of my previous job, chasing down memory leaks in C code.

This is what I was told in COBOL class. COBOL was made so that non programmer managers could write in it. Hence the English-like syntax.
 
it doesn't matter if anyone can learn COBOL, it is do they already know it inside and out to fix an issue if said person takes over. If the entire banking system was to go on its ass do you want to wait for somebody to learn COBOL then start trying to fix the issue or do you want a person that can jump in and already knows the system.

Biggest issue I see is that COBOL being such an obscure language few are going to learn it since it doesn't get you a job anywhere. Those that know it have had their jobs for 40+ years so you aren't going to have 22 year olds being able to jump into that job after college like they could anywhere that does web, a visual studio language, or java. If anything they need to bring in a few younger programs and start teaching them and getting them familiar with the programs. Although one has to wonder after this much time does much really change or it is more of just support now.

I've actually had a number of job opportunities that were pretty much "write Fortran for us" requests. If you can actually do the work, i.e. build and validate real programs in Fortran, you can probably just call up a place like Bloomberg and ask for a job offer. The demand gap is massive. On the other hand, you might get better job offers if you put a similar amount of energy into Python or JS...

I started out only because my graduate adviser refused to read anything other than Fortran (in his defense, he writes wonderfully bug-free code using a plain text editor), but I've come to appreciate the simplicity and consistency. Frankly, I wonder why people don't give it a shot.
 
So due to the fact that COBOL was pretty much a mainframe based programming language, would it be safe to assume that most major banks still use mainframe type setups? I assume they're a lot smaller these days?

Many that I have worked at or have knowledge of still use mainframes for middle-office and back-office processing. Distributed systems rule the trading floors and investment bankers desks. Over the years many ancillary functions have been moved around but the foundational record keeping is done on the MF. Click TRADE on your browser or your .NET or your JAVA or whatever and it is going to be sent to the MF for order matching, clearance, trade processing, general ledger . . you get the general idea. We used to jump through hoops at times to make cross platform information exchange work then IBM MQ came out for UNIX and MF and we just treat the MF as another server listening to what we publish and vice-versa.

When you say "smaller" are you referring to the physical size of the MF? If so yes, they are much smaller these day but their CPU's remain much bigger than an x86.
 
Many that I have worked at or have knowledge of still use mainframes for middle-office and back-office processing. Distributed systems rule the trading floors and investment bankers desks. Over the years many ancillary functions have been moved around but the foundational record keeping is done on the MF. Click TRADE on your browser or your .NET or your JAVA or whatever and it is going to be sent to the MF for order matching, clearance, trade processing, general ledger . . you get the general idea. We used to jump through hoops at times to make cross platform information exchange work then IBM MQ came out for UNIX and MF and we just treat the MF as another server listening to what we publish and vice-versa.

When you say "smaller" are you referring to the physical size of the MF? If so yes, they are much smaller these day but their CPU's remain much bigger than an x86.

Very interesting, and yes, when I said smaller I meant physical size.

Cheers ragnarz.
 
This is what I was told in COBOL class. COBOL was made so that non programmer managers could write in it. Hence the English-like syntax.

Actually .. . .

In the late 1950s, computer users and manufacturers were becoming concerned about the rising cost of programming. A 1959 survey had found that in any data processing installation, the programming cost US$800,000 on average and that translating programs to run on new hardware would cost $600,000. At a time when new programming languages were proliferating at an ever-increasing rate, the same survey suggested that if a common business-oriented language were used, conversion would be far cheaper and faster.[14]
 
how many of you have actually programmed cobol? I have, way back when. Much of the actual work (UI, IO, etc, in the implementation) was done through system calls.
So I am unsure as to the claimed benefits of cobol.
 
how many of you have actually programmed cobol? I have, way back when. Much of the actual work (UI, IO, etc, in the implementation) was done through system calls.
So I am unsure as to the claimed benefits of cobol.

The claimed benefits of COBOL don't matter. What matters is banking systems are some of the most stable systems on the planet with an incredibly low machine error rate.

COBOL is not rocket surgery, it is not a difficult task for someone who is already brainy enough to learn. There is literally no danger in sticking with application designs in COBOL.

These people are whining because the market for this coding skill is shallow and they don't have enough people to try and exploit. I say this because I have been there and that's the only reason *I* whined about COBOL. I always had people, I just had to pay them outrageously large sums.
 
I'm ready, CICS, COBOL, JCL, but I'm 51, I can carry the torch for a few more years. :)
 
how many of you have actually programmed cobol?

*waves*

COBOL is one of they dozen or so languages where I've had to code in over the past few years.

To me, language doesn't matter; if you know what you want to do, all you need to figure out is the syntax to do it. Having to work in as many languages as I do (ranging from low-level assembly for pre-x86 based CPUs all the way up to scripting languages, and everything in between) I more or less could care less about syntax at this point. If you know how to code, you'll figure the syntax out.
 
It doesn't make sense to replace COBOL.

First of all, the systems that are in place to run those COBOL programs are not targeted by fancy new languages, they're older mainframes on which the best maintained software environments are.. COBOL!
COBOL itself also undergoes changes, it's not a static language. Modern approaches do find their way into it, but of course not all software gets ported to it. Still, it does evolve.

COBOL is so ingrained on those old machines that the operators all have a fully working environment into which they can patch source code changes if need be. They are intimately familiar with their systems.

My workplace has a good number of COBOL customers and they are, for the most part, not going anywhere. Their systems work very well for them, and the software is a good bit cheaper than our more recent Java versions.
 
I've worked as a mainframe coder for a bank for the last 12 years. While the concern for upkeep is justified, the issue is basically supply and demand. Wages for Cobol haven't gone up in 20 years.

The short-term solution has been to off-shore resources with the obvious goal to save money, but the cultural differences prevent any acquisition of people who will stick around to gain the depth of the systems they will be working on. Most of the IT folks off-shore are striving to be managers within 5 years.. not life long coders to one discipline.

This is actually the problem that the management across my industry is choosing to ignore. While we do get new-blood into the industry from time to time via in house training programs, it typically takes about 5 years to even be fluent with the banking systems tied to the mainframe and 10-15 years to be knowledge enough about all the other parts and inter-related systems to actually architect anything that's not a stand-alone module.

Until the wages come up, the problem will exist. When the industry makes billions in profits per quarter.. I don't really feel sorry about the problem being created... it's self-inflicted (and the source for gloom/doom articles like this.)
 
This is what I hate about our current economy.

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.

Fine, it's dying. THEN TRAIN PEOPLE! When my sister graduated back when the economy was doing great, she got her degree in sociology, which is a wonderful useless degree that will get you nowhere in life. But she got a job as a programmer and her company paid for her to learn COBOL. Even when I graduated, companies were still willing to hire people who didn't meet the entire 22 things on their must haves, and were willing to train you on where you were lacking.

Today, companies are whining about how there just aren't enough people for those jobs, yet there are plenty of unemployed people out there looking for jobs, who are mostly qualified, but just not that perfect candidate. Why aren't companies willing to invest in their employees anymore? We're not talking about rocket science or brain surgery here. As others have mentioned above, for a person with a CS degree, learning a new language isn't exactly hard.
 
Back
Top