Much of the world's financial systems run on it, replacing it is infeasible, but the expert's in this area are aging out (and many have retired more than once). But the tech still needs maintaining, and is difficult to work with.
Fewer and fewer grad students seem interested in learning it, and the expectation that you'll stay and work on this stack for 20+ years is something that drives others away.
Nothing is infeasible to replace, it might be costly, but not infeasible
And of course IBM is happy to get paid millions to keep backward compatibility on the systems they sell
Nobody wants to invest their time learning a dying platform that is good for nothing but a dead end job at a bank and won't teach anything usable in any form of modern system (hope you like wearing a tie for your job as well)
(Fortran is still used, z/OS might be dying down as well but it runs some modern software)
Hahaha, nope. It's easier and cheaper to train a copule of COBOL programmers than replace the systems that run COBOL.
At a previous company I worked for, it was estimated that the cost to replace just a single COBOL based system was upwards of $50 million.
Not only that, banks are notoriously risk averse, especially with their software. They are very reluctant to change things that already work.
If the cost of training peons to make it last and run is less than the cost of rebuilding it, be it from scratch or piece by piece, it will matter longer (that's the point of view of insurances, banks and big corps today, and what's still happening in the IT industry).
> Nothing is infeasible to replace, it might be costly, but not infeasible
Too costly. Which does make it infeasible.
Five minutes of downtime can result in multi-million dollar profit losses. (At least that's the quote I was given by the CTO when he was explaining the scope of my role when I was consulting at a major Australian bank).
When you have literally millions of transactions a second you need to handle, building a new system to handle the same:
* Regulations * Specifications (Some thousands of pages) * Edge cases * Load
Turns into a multi-year, multi-million dollar operation that will likely be outclassed by the old system by the time it is ready.
No manager in their right mind would approve such a project, no matter how forward-thinking it may be.
Not impossible, but entirely infeasible.
Probably because it's not really fun languages to work in compared to newer things. I'd rather get paid a bit less and work with C# for example than get paid a lot more and being miserable. :)
And since it is a language that will probably die off sooner or later, it is not really a good investment since it will limit your job prospects if the bank you work for would ever change their financial system.
I work on z/OS utilities, mostly assembler. It can be fun, you have to be resourceful. z/OS is actually quite pleasant environment compared to many newer platforms (such as Windows), because you get a very high visibility into what's going on in the system.
I guess it depends on type of person. If you love to understand things across the stack (what's going on under), you might like it. If you would rather focus on an application (or framework) layer only, you probably won't.
But yeah, totally depends on the type of person and while I could potentially see myself doing these things I much rather develop in newer languages that makes my life easier. It isn't like it's bad pay for modern languages anyway.
The compensation would have to be a lot in order for me to even consider it :)
However, for the most part those systems have been running for decades and aren't modified that much any more. While probably not completely bug-free they tend to have a low error rate, in terms of functional requirements at least. They also mostly deal with low-level mathematical and accounting functions that don't change frequently.
For better or worse a lot of COBOL code also gets replaced when new compliance measures like Basel II and III are implemented. Additionally, there are even transpiler-like tools that convert COBOL to Java code. The resulting code of course is horrible but at least it then is available in a language with a long-term maintenance outlook.
In addition to a very conservative work environment all of this contributes to COBOL not having the prospects it might seem to have at face value.
That's really not my experience.
I was brought in to maintain, and manage a series of changes to a major bank in Australia, where I trained a full-time replacement before leaving.
We replaced COBOL code... With more COBOL.
> Additionally, there are even transpiler-like tools that convert COBOL to Java code. The resulting code of course is horrible but at least it then is available in a language with a long-term maintenance outlook.
Not just horrible to look at. Slow. Performance that is hundreds to thousands of times slower than the pre-existing code. That's just not acceptable.
---
Now, we were writing "new" stuff in a different language - C++, because IBM has a wonderful linker framework between Fortran and C++ on their mainframes. But the COBOL is staying put, because nothing can really replace it without unacceptable downtime or performance regressions.
My first job was writing COBOL on an IBM 390. I hated it at the time, but I realise now how many important lessons I learned from it. It wasn't trendy, but it was worth doing and I'm glad I had the opportunity.