As many said before ; it’s not learning Cobol (or Fortran), it’s the weird IBM mainframe/OS ecosystem that is the problem. I am good at both languages, but I know very little about the ecosystem it runs in.
I'd also say it's the compensation. I love Python, I love being a software architect helping smart engineers build good software, but I also love mainframes and, if the money is good, why not?
Which is sad, because programs written in the arguably dullest programming language ever conceived run on the sexiest computers ever made.
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.
As a Millennial, I haven't ever seen/touched/used a mainframe. And I work in a modern Data Center.
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.
Not that I have any experience of it in practice, but shouldn't those whole machines be possible to emulate gracefully by now? If not in software alone, at least combined with e.g. a decent FPGA.
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
Maybe not an ancient IBM mainframe, but I've used older HPPA systems, AS/400 systems, and DEC Alpha systems as well - in a hospital setting... thankfully they were all phased out in the 2005-2010 range.
Agreed. Mainframes made sense prior to distributed computing being a well used “thing”. Back in an era where a single consumer grade computer wouldn’t handle a sizeable chunk of workload, and there needing to be a single log of account balances, inventory etc.
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.
While having mainframe hardware at home is rather impractical not to mention costly there is an alternative which can be run on limited hardware:
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.
Mainframes are great for large batch like tasks. They have very good security and the VM isolation is excellent. The hardware is very robust and uptimes can be very high.
With the large increases in computing power and storage available via AMD/Intel/Apple, the case is less compelling now.
I'm about as old as you can be and still be considered a millennial and I've only run into mainframes twice in the wild, at my 1st and 3rd jobs. The 1st was that way because they were leasing the software written in FORTRAN by 1 guy in the 70s and doing a couple very small things on top. All the core edits had to go through that one guy (this was ca. 2009 or so), it was basically a black box with a 6+ week turnaround for even minor changes. 3rd was for a warehouse management system and logistics shop that was so old they had multiple full-time employees whose job title was "Computer Operator" and basically just babysat the mainframe - zero programming, sysadmin, or networking skills, I still have no idea what they actually did but whatever it was it was enough for 3 or 4 full-time people.
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.
My simplified understanding is that mainframes take vertical OLTP scaling AND system redundancy to the absolute extreme.
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.
Depending on your starting level they are designed in a way which is ahead of time for many small software houses environments even now.
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,...
High reliability/availability, data integrity, and the insane IO are the main pros I can think of.
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.
The idea that COBOL is at the heart of bank systems is a persistent myth that gets published every now and again alongside some story about how essential these systems are, how they can never be replaced and how the people maintaining these systems are a dieing breed.
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.
A friend of mine worked for a bank, or rather part of a bank that did the payroll I think. And they where working on converting all the COBOL to java a few years back.
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.
Maybe not COBOL, but I know someone who works for a payment processor / print shop in the New England area, they use a language called PL/B which is pretty close. Most of the senior crew are all retired now, and the place is practically falling apart.
> 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.
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]
Same here, in Australia I did a contract with QBE insurance, COBOL was what was running the show and I know of several people in banking where it's the same
Like many Oracle products, they didn't write it from scratch, they acquired it – from Citibank. In the early 1990s, Citibank set up a subsidiary in Mumbai to maintain their banking software, and sell it to other banks. Citibank ended up selling that subsidiary to Oracle, although Oracle is only the majority shareholder, and a minority of the stock is listed on the Bombay Stock Exchange.
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.
As the other comments say, this is not a myth. Of course banks use other languages and try and put as many work processes as possible outside the core system, but core COBOL systems is very common. Have worked at a couple.
It also appears in ways that you don’t expect. PeopleSoft is COBOL and they have like 25k+ customers. As we write, Oracle is trying to sell more COBOL into the enterprise in 2023 :)
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.
Right. Front is people code. Batch and heavy processing may be application engine or sqr, or COBOL. PeopleSoft HCM is their biggest product I think, and a lot of core (or old, if you prefer :) processes are in COBOL. Still getting updated, still actively used to pay many many millions of people in North America.
I've never worked in a bank. But I've been a sysadmin for a number of payroll and finances systems and some have run on COBOL. In particular a lot of PeopleSoft has key processes in COBOL. This is absolutely not obvious to anybody who is not actively working on that COBOL. Front end is a nice web Gui served by WebSphere or Weblogic. Rest of the system is enterprise Java. There's Python and RPA and all sort of fun stuff on the periphery, and obscure proprietary languages such as PeopleCode and ApplicationEngine (no not that one :) and God help me sqr. But core business logic that nobody touches directly except when they must is COBOL. Oracle still spits out PeopleSoft stuff in COBOL, used by thousands of companies (they're not actively selling PeopleSoft anymore, focusing on HCM cloud etc, but that too still happens)
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:)
You will be happy to know that in India at least, the big CBS (finacle) is in poorly written Java instead.
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.
I dont know cobol/mainframes but have worked for several banks that uses it heavily and that would love to train developers in the tech. They have never been able to convince me or any of my colleagues go that 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.
I've worked in the bowels of both banking (business, retail, securities, wealth) and healthcare (PBM) for the last 10ish years.
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
There is a network of local state owned savings banks in Germany called Sparkasse.
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.
When I've seen this in other banks it's been difficult to keep the junior devs interested in staying with COBOL. In general they wanted to move to other teams.
I don't blame them, some places would rather maintain their 1960s status quo than port to modern languages. It makes no sense but management is rather resistant to change.
Oh that's not the case here, management would love to get off these systems. They see the risks with the age profile of developers, staffing issues, and general ageing tech problems.
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.
Ripping the bandaid could potentially cause fatal bleeding. Keep in mind these stacks are calcified on a lower layer of stack and other higher ones depend on.
Sure, but the situation isn't getting any better. At some point you will have to start paying exorbitant salaries to people that still know Cobol and are familiar with mainframe. Then they'll need probably years to understand and untangle the systems. The sooner you start, the easier it's going to be.
> “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.”
I would do it for them for the right price; about 5x what I currently make writing Java/Js/C on Linux.
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.
> 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.
Wait, really? I briefly looked at Cobol job ads in Sweden (just for fun to see what's out there -- not actually looking for a Cobol job right now) recently and they were all looking for people with multiple years of production Cobol maintenance. I must have missed something obvious.
Ignoring English seems a little silly. Doesn't modern standard Arabic function as a lingua franca between people who natively speak something else (even if mutually unintelligible local Arabics)? That would explain it's popularity, but on those grounds English would be even more popular.
Large parts of financial industry IT are just in a hopeless, terminal state.
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'm 31 and my first job was in COBOL for a big mortgage company.
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.
COBOL at least for me, is quite readable. I've worked with code (not in a bank) that processes binary records in a quite readable way allowed porting the functionality to C++. Comments from the people who wrote it that it wasn't that hard when you put your mind to it. JCL is another matter though.
Maybe the headline should be shortage of developers who can work with poorly documented legacy code for low wages.
To me, it's readable because it usually only does very basic operations, in batch, like arithmetics, simple SQL requests and some if statements. It forces you to declare all variables once, at the beginning of the file, nothing dynamic going on, so it will never surprise you, but you won't be able to do advanced problem solving, no Google apps, no Uber, Netflix (no video processing), etc. (not saying these companies are great, just that they need stuff you can't do in COBOL85).
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.
70 comments
[ 5.0 ms ] story [ 55.9 ms ] threadLast 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).
http://www.hercules-390.org/
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.
[1] https://www.anandtech.com/show/343/5
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,...
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.
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.
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.
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
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.
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...>
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.
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.
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.