That is, the only driving requirement left for IBM mainframes is your own software that depends on system software that only exists on IBM mainframes.
Same reason some people still use other old environments like HP MPE, IBM AS/400, and Tandem Nonstop, and so on. They have found, thus far, that the cost of doing that is less than the cost of rewriting it. Or they have been unable to do that for reasons other than cost.
Edit: Separately, there are still some technical advantages. z/OS mainframes have a level of "within the rack" redundancy that you won't find in commodity servers. Or, with TPF, it's difficult to engineer a solution that scales as well and remains reliable...it's a very battle tested distributed K/V store that deals with heavy write contention.
Of course part of the reason it faded away (indeed, was gradually fading away even when I worked for Tandem) is that almost nobody does need that sort of reslience.
Bank calls the Tandem support line: "Our computer is down. It crashed! How do we get it back up?"
It wasn't offline. It had fallen over, punching through some of the sections of the raised floor.
--- 1. Well, I guess second-and-a-half. I played a little with Z-80 on my Spectravideo computer, but mostly that was writing a disassembler in MSX basic to reverse-engineer how the system worked after it was abandoned by its manufacturer. The disassembler was never finished because I didn't properly manage the multibyte opcodes.
In a high availability environment (like banking or airline reservations, as mentioned), mainframes never go off, even during upgrades. When physical machines need replacement, the entire system is run in parallel on a second machine.
These boxes have both incredible I/O hardware (there's never been anything like IBM channel I/O) and the software to keep everything humming. On a typical day when I worked there, we'd have a 1,000 devs using the same box (and that was a small installation) with multiple operating systems, virtualizations, etc. with zero hiccups.
IBM also has amazing software for getting stuff done. Documentation, for example, is universal and available worldwide from any terminal. When you want a printed manual, the system figures out which big, fast printer is near you and offers to print it down the hall. Every IBM employee has access to all the company's resources from every terminal, and it all just works.
Yes, PCs have caught up to emulating many of these features, but they definitely don't have the robustness or ease of use that System/370 (z/OS) did.
That's an aside though. The reason people keep buying them is software lock in, yes. There's a reason Amazon likes to push their proprietary services...they are the new mainframe.
These days if you can parallelise those calculations the price benefits of servers are worth the software complexity.
A Z15 core runs at 5.2 GHz (IIRC) and has shared access to 960 MB of L4 cache for every group of 4 sockets of 10 cores each (Linux workloads can do SMT2 on each core). They emphasize single-thread speed because they measured diminishing returns when adding more cores to an LPAR and figured out it was pointless to play a numbers game.
> These days if you can parallelise those calculations
Yes, but it's not all workloads that are amenable to that - some will want to keep a consistent in-memory representation of the working data with all cores working on the same data. If you can scale out, great. If you can't, this is the very top of the line. It you need to scale up from a z15, I suggest you wait for the z16 availability ;-)