Sometimes, these systems are unable to be run in what you'd think about as a traditional distributed systems model. You don't just run that one COBOL program 100 times and kill one process everytime it jams up.
The software inside of some of these systems was written in a time when it could be optimized to the absolute bit. At that level of optimization and skill in development, you're not really going to do better or get more throughput with a rewrite. Instead, you just keep wrapping that thing in outer layers and message queues.
So, if you need a computer that can absolutely 99.99999% never stop working, including redundant everything (Power, ram, cpu, network) and you're running something that's super old but super efficient and has worked basically perfectly for 30 years, you just buy another one to replace the original, and add some containers into the mix for the queues, or storage adapters or whatever, rather than spend a billion dollars re-engineering the whole thing from scratch as microservices that may or may not work.
That, or it's a giant fucking database server. That's usually the case: one big floppy database that runs everything in the company and it's SAP system.
Another interesting feature is that they are designed to be monitored, because a traditional business model was to lease a mainframe and rent out capacity to smaller companies that'd pay for things like CPU seconds or bytes read/written.
They might also know others who do it too. I must admit I've never heard of such a thing from non-IBM sources.
[https://medium.com/selency-tech-product/your-balance-is-0-30... - all those problems are addressed.
Also, per [this thread](https://softwareengineering.stackexchange.com/questions/1129...):
> In the environments where COBOL thrives, multi-threading is usually left to application containers like CICS or IMS which are good at it, rather, than programmers who tend to be bad at it.
I'm legitimately curious. I already know how stupid reliable they are in terms of correctness guarantees and staying up when hardware failure and replacement occurs, but what truly sets them apart, considering their cost?
At least for we 20-something engineers, I'd wager that nearly all of us have never had an opportunity to be exposed to mainframes.