It’s not that the mainframe is hard to learn. In fact, the environment is pretty easy to understand once you get past the archaic naming (but let’s not kid ourselves: on the POSIX side we’re still running t[ape]ar[chive] and other archaic tools too).
In a way, the ease IS the problem: the runtime environment for COBOL (and other stuff on the mainframe) assumes that the underlying platform and OS deal with the really hard stuff like HA and concurrent data access and resource cost management. Which, on the mainframe, they do.
Now, contrast that with doing the same thing in, say, a Linux container on AWS. From the stock OS, can you request a write that guarantees lockstep execution across multiple cores and cross-checks the result? No. Can you request multisite replication of the action and verified synchronous on-processor execution (not just disk replication) at both sites such that your active-active multisite instance is always in sync? No. Can you assume that anything written will also stream to tape / cold storage for an indelible audit record? No. Can you request additional resources from the hypervisor that cost more money from the application layer and signal the operator for expense approval? No. (Did I intentionally choose features that DHT technology could replace one day? Yes, I did, and thanks for noticing.)
On the mainframe, these aren’t just OS built-ins. They’re hardware built-ins. Competent operators know how to both set them up and maintain them such that application developers and users never even have to ask for them (ideally). Good shops even have all the runtime instrumentation out there too—no need for things like New Relic or ServiceNow. Does it cost omg so much money? Absolutely. Omg you could hire an army for what it costs. But it’s there and has already been working for decades.
God knows it’s not a panacea—if I never open another session of the 3270 emulator, it’ll be too soon. And a little piece of me died inside every time I got dropped to the CICS command line. And don’t even get me started on the EBCDIC codepage.
Folks are like, “But wait, I can do all of that in a POSIX environment with these modern tools. And UTF-8 too dude. Stop crying.” Yup, you sure can. I’ve done it too. But when we’re talking about AI lifting and shifting code from the mainframe to a POSIX environment, the 10% it can’t do for you is… all of that. It can’t make fundamental architectural decisions for you. Because AI doesn’t (yet) have a way to say, “This is good and that is bad.” It has no qualitative reasoning, nor anticipatory scenario analysis, nor decision making framework based on an existing environment. It’s still a ways away from even being able to say, “If I choose this architecture, it’ll blow the project budget.” And that’s a relatively easy, computable guardrail.
If you want to see a great example of someone who built a whole-body architectural replacement for a big piece of the mainframe, check out Fiserv’s Finxact platform. In this case, they replaced the functionality (but not the language) of the MUMPS runtime environment rather than COBOL, but the theory is the same. It took them 3 companies to get it right. More than $100mm in investment. But now it has all the fire-and-forget features that banks expect on the mainframe. Throw it a transaction entry, and It Just Works(tm).
And Finxact screams on AWS which is the real miracle because, if you’ve only ever worked on general-purpose commodity hardware like x86-based Linux machines, you have no clue how much faster purpose-built transaction processors can be.
You know that GPGPU thing you kids have been doing lately? Imagine you’d been working on that since the 1960s and the competing technology had access to all the advances you had but had zero obligation to service workloads other than the ones it was meant for. That’s the mainframe. You’re trying to compete with multiple generations of very carefully tuned muscle memory PLUS every other tech advancement that wasn’t mainframe-specific PLUS it can present modern OSes as a slice of itself to make the whole thing more approachable (like zLinux) PLUS just in case you get close to beating it, it has the financial resources of half the banks, brokerages, transportation companies, militaries, and governments in the world to finance it. Oh, and there’s a nearly-two century old company with a moral compass about 1% more wholesome than the Devil whose entire existence rests on keeping a mortal lock on this segment of systems and has received either first- or second-most patents every year of any company in the world for decades.
It’s possible to beat but harder than people make it out to be. It makes so many of the really hard architectural problems “easy” (for certain definitions of the word easy that do not disallow for “and after I spin up a new instance of my app, I want to drink poison on the front lawn of IBM HQ while blasting ‘This Will End in Tears’ because the operator console is telling me to buy more MIPs but my CIO is asking when we can migrate this 40-year old pile of COBOL and HLASM to the cloud”).
Mainframes aren’t that hard. Nearly everyone who reads HN would be more than smart enough to master the environment, including the ancient languages and all the whackado OS norms like simulating punchcard outputs. But they’re also smart enough to not want to. THAT is the problem that makes elimination of the mainframe intractable. The world needs this level of built-in capability, but you have to be a bit nuts to want to touch the problem.
I have been to this hill. I can tell you I am not signing up to die on it, no matter how valuable it would be if we took the hill.