My understanding is that Z mainframes have a number of unique features to support those use cases. Stuff like hot swapping CPUs, and hundreds of IO coprocessors to avoid the main cores from getting blocked. Don't think they're just rebranded x86 machines, but not an expert.

True. I find it interesting how difficult that they find it to put the benefits into words that don't sound like a brochure.

Surely there should be some specifications behind this? Benchmarks?

I worked on them a bit while at IBM.

You can open a terminal and come back in a month and it will still be there. Unlikely kunernetes where containers regularly go down.

You can obviously achieve high reliability with Kunernetes, but you'll need queues and retry logic, that you don't need with SystemZ.

> You can open a terminal and come back in a month and it will still be there. Unlikely kunernetes where containers regularly go down.

You mixing apples and oranges there, by comparing kubernetes workloads to mainframes. Kubernetes isn't really designed to serve long-persistent workloads of that fashion. Although tbf I've had VM's that last for years and real hardware (albeit Sun) that's had over a decade of uptime, so I'm not sure what all the fluff is about.

Both have a goal of high reliability. They are both solving the problem of running you application on a single server.

Kubernetes runs across multiple nodes to achieve that, that don't need to be in the same datacentre, though.

Is this where we are right now as a society: a terminal which doesn't die in a month is presented as an achievement?

I assume the achievement part is that any CPU can be replaced transparently to the terminal running?

I've not worked with a mainframe, but I've worked with an IBM storage system that worked on similar principles: We could connect our systems via dual controllers, to separate bays of controllers on the storage array. You could pull whole bays of controller cards and the system would stay up. You could pull whole bays of hard drives, and the system would stay up. You could pull power supplies and it'd remain up. You could swap RAM and CPUs in the servers managing it without shutting them down, but you could also pull one of those servers, and it'd remain up. If stuff started failing, and IBM engineer would show up because the system would call home. This was around 25 years ago.

It wasn't cheap, but it made a typical "modern" high availability setup look like a crude homemade toy.

But as impressive as it was, there are just very few places where that impressiveness provides enough value to justify the cost. And having to deal with IBM.

Yes, Hard drives can die, power supply can die, another user can write an infinite loop and it will not kill your terminal.

Not a big deal today, but in the 80s hard drives died more frequently and a bank losing just 5 seconds of transactions could cost them millions.

Anandtech ran a story when the z16's CPU was announced:

https://www.anandtech.com/show/16924/did-ibm-just-preview-th...

ECC memory is widely available, you can buy it on amazon, and if you have a contract with a server manufacturer they'll be happy to sell it to you.

It's just not compatible with consumer CPUs (well, ddr5 is, but ddr4 and lower wasn't) because Intel was voluntarily segmenting the market to upcharge for server CPUs.

Sounds like a working solution is not as “widely available” as you suggest. Apple/Amd play similar games.