Shortage of COBOL developers in insurance and banks
lemonde.fr
lemonde.fr
Almost all of this seems untrue (except maybe the last one). I’ve worked at a variety of banks from front to back office across securities and private wealth. I’ve seen plenty of company-specific languages, plenty of C++, Java, perl, python but have literally never encountered a COBOL system. There’s one system at one of the banks that I was a contractor at which may have been COBOL I’m not sure. I didn’t work directly on it and it ran on a Tandem.
I’ve never worked for a pure retail bank so it’s possible that some pure retail banks use COBOL, but I have worked on settlement systems, payment systems, reconciliation systems etc including for banks that have a retail arm as part of a larger bank and haven’t seen hide nor hair of COBOL anywhere. Some cynical part of me wonders whether IBM PR or some niche trade body or recruitment agency seeds these stories into the press every now and again to get people to fixate on COBOL and these clunky mainframes being somehow essential to the financial system.
From personal experience when I got a loan approved I noticed the bank dude had to log into a terminal based system via remote login to a VM. But I can't say for certain that it was written in COBOL. But certainly written around or before the 90s.
Two of Australia's four biggest banks – ANZ and Westpac – have historically run CSC Hogan. I don't know what they are doing as of today, but according to media reports ANZ was still using it in 2016 [0] and Westpac in 2019 [1]. Hogan is based on z/OS, CICS, COBOL. Not only is the vendor-supplied product code in COBOL, any customer ends up having to write lots of their own COBOL code to add customisations necessary for their environment. CSC – now DXC – has a replacement platform, Celiriti, which runs on a more mainstream tech stack (Java/Linux/etc), and I believe both were looking at migrating to that eventually. Australia's 6th largest bank, Suncorp, uses Hogan too, having in 2020 abandoned an attempt to replace it with Oracle Banking Platform. [3]
[0] https://www.itnews.com.au/news/core-banking-overhaul-still-o...
[1] https://www.itnews.com.au/news/westpacs-100m-core-network-re...
[2] https://www.itnews.com.au/news/suncorp-to-modernise-its-hoga...
[3] https://www.itnews.com.au/news/suncorps-oracle-core-finally-...
When I worked at Oracle, I was involved on the periphery of it, in the middleware products that it used, but I never actually saw the product itself.
(Not so) fun fact, Westpacs account password policy requires the following:
6 characters. Not minimum. 6 exactly. (!!!)
Includes at least 1 number and one letter
No special characters, spaces or repeating characters
And it’s case insensitive! Very convenient indeed if your caps lock is broken or something
Edit: I stand corrected, that's 8 characters.
The majority of PeopleSoft isn't COBOL – it is written in PeopleCode, a language PeopleSoft invented themselves (like SAP's ABAP), and I believe some newer components use Java too.
The COBOL is mainly used for batch processing and offline reporting in some of the older modules, such as Payroll. Many of the newer modules don't use any COBOL at all.
Note, fwiw, while I personally happen to work for ibm, little to none of the COBOL I've encountered was running on ibm mainframes or even on ibm COBOL compiler. Most of it was third party software running on microfocus COBOL compiler... On windows and *nix.
Obviously just an anecdote like yours, but COBOL is definitely out there and not just on ibm mainframes:)
Many legacy banking cores are still in use and the legacy ones are all written in COBOL.
Made on least cost basis, protected by a moat a central bank wide, and maintained by 10k /year engineers, it is truly a marvel that our country's banks even run.
The company i intern at has built its entire business off moving as much functionality outside finacle. A small modification of changing a label's font, can cost a full 100-150 usd.
Never mind adding in custom features and the like, which costs a pretty penny if you use infy.
To me, it's impossible that people lack COBOL skills, I was ready to push code to production in less than a week, so I started with a one-week self-teach COBOL which included the specifics of working with this particular mortgage company with its way of naming files, separating DB2 SQL requests in files, never using GOTOs, etc.
So when I see this kind of news, once or twice a year, I know it's probably more about sysadmins willing to run mainframes, setting up compilers and stuff, JCLs scripts, relational and hierarchical databases, than just developing in COBOL. Of course there's also the problem that nobody wants to learn and write COBOL when there's "good" and "pleasant" modern languages around. But that can be solved with a 20%-30% increase in salary (and I don't think they are actually paid more than other devs at least nowadays in my area (France), so it's probably fine for now).
PS: It gets better, I'm a web developer now, only did 1 yr of COBOL. Good to know it exists, and some people are miserable, makes you enjoy simple things, don't take anything for granted.
Last time I checked, the money wasn't good.
It's a small enough niche that buyers of services can conspire.
One piece of advice: avoid working at a cost centre. Always prefer the profit ones. Working on something that’s considered a cost for doing business will lead to much less freedom (and budget) to innovate than working on something that’s seen to be the cause of your revenue.
What are the pros/cons of mainframe? What makes them better than a rack housed with necessary hardware? Well, I can see cons - not so accessible as regular hardware. Impractical/impossible to have at house.
So the learning curve for hobbyists/tinkerers/curious are missing first steps.
Of course that's of limited benefit if the jobs also include service of the actual hardware, but it seems like it should be good enough to get experience with the machines as an environment for programming. (And certainly compact enough to have at your house)
- Most new stuff is built on regular servers with Linux running
- Mainframe kind of stuff would be HPC (high performing computing), this is where huge calculation are done at scale, this would be scientific/university/engineering use cases
https://en.wikipedia.org/wiki/TOP500
> most powerful non-distributed computer systems in the world.
Today a single computer is so powerful it can easily take on the needs of a logical division of work. Hence distributed computing taking over the world.
Your modern smartphone is more powerful than mainframes of generation prior.
Hercules is an open source software implementation of the mainframe System/370 and ESA/390 architectures, in addition to the new 64-bit z/Architecture. Hercules runs under Linux, Windows (98, NT, 2000, and XP), Solaris, FreeBSD, and Mac OS X (10.3 and later).
I tinkered with this a bit some 25 years ago, running it on Linux on an Abit BP-6 (dual 400 MHz Celerons overclocked to 466 MHz, just imagine the power...) [1], just for fun really. It booted and I managed to run some simple tools on it so it should do more on up to date hardware.
With the large increases in computing power and storage available via AMD/Intel/Apple, the case is less compelling now.
Despite the Computer Operators, the advertised pros of the mainframe are often very little maintenance and being able to write code and let it run for months or years without interruption. I've heard the performance is also very very good.
In any other computer your small number of general purpose CPUs have to handle all the business / application logic plus disk IO, network IO, cryptography, system housekeeping, etc. On a mainframe all those other things are offloaded to specialized coprocessors and the actual business logic gets nearly 100% of the cycles on hundreds of special purpose high frequency water cooled business logic CPUs running at 5+GHz.
Also any component can fail and be replaced without downtime or lost transactions. CPUs, RAM chips, entire motherboards, anything at all. You can rebuild it online while your transactions continue. Transactions can be run in duplicate across multiple hardware paths to ensure they are never lost and also verify output correctness.
If you set out to build a database server that handles 100 million transactions per hour and never ever goes down, you would end up with a mainframe.
I went through couple of mainframe z/OS basics certifications about 10y ago, never did anything commercial, just for educational purposes. All info comes from lectures and people who visited the cert-learning group with job offers.
A bit of history, mainframes are done by IBM which historically had some interesting things to do like count votes which led them into data processing market, mainframes were built for high data loads. You don't buy mainframe, you only rent it, physically. The level of duplication possible with these machines is incredible. You might receive a call, or maybe mail nowadays that something has broke in the mainframe you are using and you might be not aware it ever happened. I don't know if any "regular" vendor can tell you that e.g. half of 24 CPU board is broken down and they are going to replace it for you as this is their responsibility and would like to be sure someone can open the building with mainframe. Pro tip: you might be scared because you know you need 40 CPUs and that means you should have 2 such CPU boards and now you think you are missing 4 CPUs, but in reality you will learn that it's all ok and you will not face downtime because they can change it without switching it off and anyway you already had 3 boards just in case some failure happens and IBM does not want to send technicians back and forth multiple times a year for something as simple as this thing so they just have put more parts into your chassis and since telemetry is working all the time the know when they have to replace parts. On the software side you can run pretty much anything fancy there, the can emulate whatever you need if only enough clients have enough $$$ and this is how they can offer you CPUs with native java support, you don't run assembly there, you run JVM bytecode directly on CPU. And the more accurate software side, sometimes you have to deal with strange limitations, are they wrong? I don't know for sure, but I rather think not wrong. Mainframes can operate in backward compatible way and you are hostage to thinking of times when computers very in early evolving stage and world looked different. If you are writing web apps - which is pretty much kind of majority of work for devs in my experience - have you ever considered things like limits of the app you are writing? Can you estimate a number of users who can use app concurrently without measuring? Do you know upfront how much space for logs do you need? Maybe yes, but if you have to tell your operating system that you need space for 5 billions of log records and you have to provide record format with constant length strings and you have to do it upfront you might be surprised. You might be also surprised your operating system understands that your data is structured and has tools supporting you with processing such data. Log retention? This is operating system feature, you can specify that log is important for 3 such files and they should rotate, opearting system will notice when you cross boundary of 5 billion records and will create next dataset (not file, there are no files, different words for many of things). If datasets (000), (001) and (002) are full, then the oldest is removed and (004) starts its own life. Oh, did I mention you can specify these rotation only once when you create dataset :)? But only if you work in backward compatible mode which is compatible with tape drives.
There are lots of topics which I haven't covered and can relate looking at other comments, I'm not sure how much of the hardware things is really true because I couldn't verify it from software side, but on the other hand I have no reason to doubt the stories other than it being so uncommon in regular computing. I hope I did not make up things as I write old memories.
One thing which is not really mainframe related is the work culture around them. It is just different, to me it seems like it is build for STEM enthusiasts, people who prefer to plan then execute. From business side there is a need to do something and see money coming, this is where is key difference, I don't know if Agile would work in world of mainframes but I doubt. Of course there are deadlines too, but overall approach is different. And because a lot of things get planned or are considered before deploying the app, the apps come with books of procedures. If error QWE123 happens then please follow these 15 steps. This is where mainframe operators come (mentioned in other comments), I don't know why this work should be done by people, terminal which accesses mainframe can be programmed around and used just like rest API (or pretty close), but there must be something extra in having some analog processing unit in the loop. Playing with emulators is not enough, you will invent your own ways of doing some things which is undesired feature when you work with mainframes, they are supposed to be low maintenance, so there is sometimes probaly a little space in mature environments to come with own custom solutions. But on the other hand they are source of many already existing concepts, e.g. blue green deployments but with option to continue started operations with old versions. Completely invisible rollout of new app version.
Mainframes are fascinating for many reasons and while I know some of the features can be done in regular environments I have bad luck in choosing jobs. Companies hiring for mainframes usually offer all required trainings, what I don't understand is why they don't offer well above the market salary for work which is far more cumbersome than other things. I received offer to work in capital city of neighbouring country of similar economic situation and the offer while was about 30-40% than my actual first job did not please me at all, and I could do regular dev job in my own capital city for a little less than that if I wanted to. I worked for one proxy dev contracting job for company with thousands of people around the world and somehow my local managers took care about opportunity to work with mainframe so it never happens, somehow it was seen as bad opportunity, I guess it was problematic for local office to deal with probable security measurements.
While there is a lot to talk about there, I think all of those points are dwarfed by the main draw: legacy support. Companies running mainframes typically have decades worth of code that is running on the mainframes and the cost/risk of migrating is enormous for questionable gains.
I definitely agree accessibility is an issue. I am pretty young myself and found COBOL to be pretty easy to learn and start developing production applications with, in many ways easier than modern systems due to lower complexity for the dev. However, the systems side of things felt very alien to me and has been a challenge to learn. I don't know how one could learn it without training at a company that has a mainframe or by taking courses with IBM.
Only formal requirement to apply is some professional development experience or a degree in something programming related.
In completely unrelated news, Arabic is now the second most spoken language in Sweden. <https://digitaledition.chicagotribune.com/tribune/article_po...>
They have an in-house IT company called Finanz Informatik. I was surprised to learn that they actually had IT/Software Dev apprenticeships that taught COBOL and mainframes as their main subject. Apparently the program was somewhat successful for them.
Re-writing these systems in another language is almost not an option. They have been written over decades with countless undocumented projects. They are core systems that work the way the business wants (or is built around, for better or worse), and doing a port would take years 100s of millions budgets and have a very high risk of failure.
I've seem smaller/non-core mainframe systems ported and they have been years delayed and plagued with issues, where it is very difficult to specify what is wanted other than something that is the same as the systems that is currently there with all it's weird corner cases.
> “As an example, we knew that the General Ledger capability would most likely not be modernized for a very long time as changes are slow and the module is very stable,” explains Uli Homann, Corporate Vice President in the Cloud + AI Group at Microsoft. “If you were to transpose this situation to modernizing a mainframe application landscape, for applications or functionality that’s unlikely to change, it might mean that you would opt to rehost your existing COBOL, PL/I, or mainframe assembler code using capabilities from partners such as Raincode—and then eventually rewrite those applications piecemeal as COBOL or PL/I programming skills continue to get more scarce and expensive. In the meantime, though, rehosting existing code buys you time and frees-up cashflow to focus on more pressing or important modernization projects.”
https://customers.microsoft.com/en-us/story/1636062794805219...
These sense like an extreme amount, but the problem is I’m pigeon holing myself into a single tech and my pathway to career advancement is finding other big banks that are hurting… which again I’m willing to do, but the risk/reward has to be there.
Given what some of these mangers make at these banks, coughing up that salary isn’t unreasonable.
From the bank's perspective, it is unreasonable.
Legacy banks still don't understand/accept that IT is the foundation of their business. Maybe a century ago it was possible to run a bank on paper records, typewriters and abacuses (abacii?) but those days are long gone. Yet, the banks still consider IT as a nuisance and overhead to be outsourced to the lowest bidder (and many consultancies have third-world sweatshops full of incompetent monkeys to fill this niche). It is also a positive feedback loop because outsourcing IT to idiots means the user experience is terrible and the people within the bank now have a good reason that reinforces that mindset.
Your typical software engineer/IT person in the bank has about the same clout and political power as the janitor, absolutely not enough to commend the high salaries given out to managers and various paper-pushers. Keep in mind it's still a very nepotistic environment (relative to most tech companies) and in a lot of cases those managers don't get those high salaries upfront but grew them over time by playing office politics correctly and doing the right favors to the right people.
This is less endemic on the securities and wealth side. Business and retail banking back-end transactions and processing have extremely large COBOL/mainframe dependencies. The systems have been built over decades. Some of these banks have tried to transition to newer tech and progress is very slow + bumpy. I'm not a cobol dev but from what I understand it is spaghetti'd to hell and back.
There is def a labor shortage but more of the younger gen is being exposed to this tech via the transition/transformation projects. But def. a dying breed from what I've experienced.
note: except for the healthcare side, all this experience is OUTSIDE the US
Maybe the headline should be shortage of developers who can work with poorly documented legacy code for low wages.
So it's ok at doing the most basic things. But all the other languages can do it too, and you could require compile-time restrictions to enforce constraints, you could write Rust without heap storage, allocating all memory once, etc. The compiler might get bored.
There are a few exceptions of organizations that have serious in-house knowledge (mostly select parts of investment banks) but, by-and-large, this sector has never really thought of information technology as being core to its mission. So everything related to information processing has been outsourced, from Microsoft's excel, to IBM's mainframes and COBOL. In this world Java is the epitome of sophistication and modernity.
It is a monumental error in vision and leadership given that finance is nothing but information processing. In any other sector this level of incompetence would have brought swift and merciful disruption and obsolescence. But this is not any other sector.
This is the highly-regulated inner sanctum where society keeps its precious Monetary State. As the experience with crypto amply demonstrates, leave that door ajar to fast-talking, white-paper writing financial "innovators" and a madhouse ensues in dt.
It is entirely unclear how things will develop as the last COBOL developers retire to blissfully sail around the Balearics. Maybe banks will move from COBOL to blockchain, asking chatGPT for instructions every step of the way.
I have never seen a good reason that I as a developer should shift to a proprietary technology with very small sector usage, very little long term future and no personal interest.