Also, mainframes are the most expensive way to run modern code so the fact that it's possible is not interesting.
I've been thinking about this a lot. I don't think many businesses have the margin to pay for the vast cost of a rewrite off of legacy. So maybe it's simply an evolution of business. Old businesses die and young businesses take their place with more efficient technology.
Unfortunately, it does not happen in industries that are heavily regulated, and probably where we need it most.
In a business context, the outcomes that your software enable are the things that matter. If your legacy platform still works and your business can still accomplish the things it wants to accomplish, why add a huge expensive distraction?
IBM still makes mainframes. You can still buy OpenVMS systems. There is no reason to believe that you will wake up one day and your technology will no longer exist. Don't hire people from Stanford or MIT. Recruit at 2nd tier schools and get them a year or two before you need them. They can learn all they need on the job, and they cost less, too.
> payments taking over a day to go through
That's due to the protocol. https://en.wikipedia.org/wiki/ACH_Network "when a real-time transfer is required, a wire transfer using a system such as the Federal Reserve's Fedwire is employed instead".
> people not being able to receive unemployment
That's probably not due to the mainframes. https://slate.com/technology/2020/04/new-jersey-unemployment... That's probably an administration issue. https://www.citylab.com/equity/2020/04/unemployment-benefits...
and
http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr011.pdf
Should pretty much cover it :)
Edit: missed http
Consider that when you swipe your credit card and get payment approved in a store, that’s a round trip to the mainframe back at Visa HQ. Or when you withdraw cash from an ATM. Mainframes are perfectly capable of near-real-time operations at massive scale. The problems you mention are not technological.
The worst part is that a clean, entire rewrite isn't necessary: while everyone's familiar with a gradual refactor (module-by-module), fewer people seem to be aware of how better a proxied gradual rewrite is: where a single module/area in the old system is rewritten in the new system, but the old system's exposed interfaces remain the same and simply proxy or pass-through to the new system (to support existing clients and use-cases) while new clients can access the new system directly.
It's an approach I used for a rewrite of an old ASP.NET WebForms application to ASP.NET Core (famously the two are very incompatible: old WebForms *.aspx markup and stateful Page classes (don't forget `__VIEWSTATE`!) simply cannot even be refactored to work in ASP.NET Core: the only way forward is a total rewrite: but when an old .aspx is replaced, there's an `IHttpHandler` that takes its place and proxies the request to the new ASP.NET Core system and end-users are none-the-wiser (and by "proxy" I don't necessarily mean like a HTTP reverse-proxy - 90% of the time the new .NET Core code was running in-proc and invoked as a normal library reference because it targeted .NET Standard and so ran on .NET Framework 4.x instead of only the .NET Core runtime).
Now I know I can't compare a line-of-business web-application to a billion-dollar IBM-powered banking/insurance/public-sector - but I believe the same principles apply. Provided the original application _can_ be decoupled internally (thus to allow that proxying in the first place), then a gradual in-situ rewrite should be doable.