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.
I see a lot of “good” answers where good translates to reasonable business or social goals. But I can think of quite a few bad reasons.
The top reason is, management wants workers back in the office because managers never learned how to manage people, so they practice management-by-walking-around, aka interrupt-driven behavior. Many companies have a culture of MBWA, and it’s a hard curse to break.
Another bad reason is, distanced work has led to a substantial reduction in workplace unfairness behaviors such as sexual harassment and race-based favoritism. And this, logically, has made female and minority employees more valuable and better performers. But in many workplaces, favoritism is the order of the day, and women and minorities were not the favorites. The favorites are now performing worse than the people they stepped on to be unfairly promoted, and it makes incompetent executives look, well… incompetent.
Another reason is that many people, particularly executives, have more authority, respect, or control in the workplace than they do at home. For quite a few people, their office has become their primary social outlet. And taking that away has proven unlivable for them.
The other reason that immediately came to mind is that executives are, by and large, older than the rank and file, and they (we) come from a time when building, maintaining, and overseeing an office space was both a critical part of the job and a source of pride / ego. For older management, offices are still a real-world manifestation of the success of the company that signals to other people how effective the leadership of the company is. People are less able to derive the same sense of awe from abstractions like sales numbers. If people don’t return to the office, it will not continue to make economic sense to have flashy offices, and this ego outlet will disappear.
Are these good reasons? They are not. But these reasons, honestly, ring truer to me than “hallway collisions.” In the real world, all motivating reasons are self-centered reasons, and executives simply don’t benefit from hallway and breakroom magic or mentoring of the young. They do perversely benefit from showy offices, discrimination, avoiding overt displays of their lack of skill, and forced social conduct, though.
Branches exist to handle and process A) cash demands, B) check and other non-specie instruments, and C) paper for commercial clients. If they’re a community or specialty bank, branches also exist to serve the particular, unusual needs of their community,—usually business needs. These special needs often include unusual skills such as assessing the quality of a crop or meeting with specialized experts.
That branches happen to also offer convenience to consumers is a happy accident, mostly, and it’s happier in that businesspeople are themselves consumers and often select their business bank based on where they personally bank. Branches are JUSTIFIED regulatorily by their public benefit which centers, in most cases, around consumer and SMB (which is to say, prosumer) access. But like many things, the regulatory rationale and the real purpose do not fully correspond. I’m sure you’re as shocked as I.
If branches were about sourcing consumer deposits, they would be uninsurable properties, because banks would burn their branches to the ground. Rest assured.
Well… I read it. And I’ve gotta say, that sounds like a blatant violation of Regulation Y, the requirement that bank holding companies engage only in, “The business of banking.” There are lots and lots of activities that fall under that umbrella, but enterprise B2B software sales isn’t one of them.
CapOne may be too big to fail, but it’s not too big to receive a C
Oh wow, that made me feel old. I actually read that article just before making the switch from the Radio Shack TRS-80 ecosystem to Commodore. See the Tussey ad for a 64C with an FSD-2 floppy? I bought that package from them with a repackaged c.Itoh thermal printer. It actually had the mail-in redemption offer the Commodore guy referred to in the article.
It felt like I had that C64 forever. I learned CBM BASIC, 6502 assembler, and even K
Goodness, Rexx. I’m pretty sure I got the job at IBM when I was a kid because I already knew Rexx on the 390, ARexx on the Amiga, and the OS/2 version. I also knew HLASM and ia32 assembler, so I was instantly useful with no further training.