Nope

Hmm IO is not near native speed and since this is a mainframe we are talking about its pretty darn important... Which is also where a lot of the R&D goes - making sure the IO paths are all blazingly fast.

For that matter how fast would all the mainframe specific CISC instructions run emulated on a RISC CPU... Not very would be my guess.

Maybe leave the solutions to the pointy haired IBMers in futture.

I/O, Emulation

Indeed I/O performance is one of the major strong aspects of the mainframe. CPU throughput has never been impressive; the "Seymour Cray One Man Show" beat the hoardes of IBM engineers on a regular basis in terms of CPU performance.

But I/O is actually the easiest to virtualize/ translate. A POWER system can have exactly the same I/O facilites (I/O Processors/Channels, DASD, Fibrechannel, Infiniband, 10G ethernet, DMA etc) as a current mainframe. What I am suggesting is to just remove the S/390 CPU but not necessarily all other mainframe hardware components.

My point was that it does not make sense to develop a POWER and an S/390 CPU at the same time. As POWER is the fastest CPU architecture around, even translated CISC programs would have excellent performance. Various projects at HP, DEC, Apple, Transmeta and now QEMU proved this. Some even argue that Translation can optimze code "on demand" and based on a real workload and achieve higher throughput than a statically optimized program. It is well-known that profile-driven optimizers achieve best results.

DEC achieved competitive performance with their Alphas emulating (actually dynamically translating) x86 CPUs using FX!32 technology.

Hmmm

That would imply they can perform some sort of translation inside the CPU. Transmeta did this, but they could apparently not compete with "real" x86 processors. Also, their technology included some very sophisticated software performing the translation and I have never heard of that with Power or S/390 CPUs which are part of production systems.

My guess is that IBM reuses ALUs, caches, branch predicition logic etc from Power CPUs in S/390 CPUs and the other way around. Microcode can only be used for infrequently used instructions, as that makes them *really* slow.

What I suggest is very similar to Apple's CPU transition strategies. The successfully supported 68K code on Power and the Power code on x86 with acceptable performance penalties.

Rock Solid Windows!

Mainframe reliability -> "...you can get pretty close to it on a well-configured Unix/Linux or even Windows box, if you understand what you're doing"

lol! What the f* do you do to a Windows box to make it as reliable, or 'pretty close', as a mainframe! Unix maybe more reliable but MTBF for the components in any of those servers is not in the league of a Mainframe by miles. If you come up with the Chris Miller method of making cheap Windows and Unix machines that reliable you will be a billionaire in no time. Getting anywhere near mainframe levels of availability for an app on Windows or UNIX requires a distributed design - not one box - which is where the Mainframe usually sits, its a workload that cannot be distributed (Or easily anyway).

Your statement about third party drivers shows you have little understanding how reliability is designed into zOS. There are plenty of shitty bits of code running on zOS - unlike Windows and a lesser extent UNIX they could *never* take the system down.

@oolon

"What the f* do you do to a Windows box to make it as reliable, or 'pretty close', as a mainframe!"

You configure and manage it correctly. Just because you don't know how to do it doesn't mean it can't be done. I expect my Windows servers to deliver at least 99.999% availability and that's just the sweet spot - higher levels are achievable, but it starts to cost serious money and most applications can't justify it.

Of course, if you're a bank or a stock exchange or a telco five-nines isn't good enough. But they usually go for high-availability solutions such as HP Integrity (Tandem to us old timers). IBM mainframes, good though they are, are really just for running legacy code.

You don't work for Big Blue, by any chance?

Hardware

I won't even bother with the software side of things.... What Windows server has components with MTBF of decades with continuous heavy use?

Fine nines availability over what period, a day, month, year? We are talking about decades here and I'm saying mainframes not IBM mainframes (Ok so there is a bit of a large bias towards IBM in the market!) A client I work for has a Unisys mainframe for example that has been running non-stop for over 15 years. These are not systems made from off the shelf motherboards where cheap labour pops a chip / mem into say a Dell wintel server. Redundant power supplies, memory, IO everything you can think of is built into a mainframe, and built in by engineers in a clean room. Ok so this example is IBM only - the eFuse technology even allows bits of a CPU to be re-routed when they start to fail to avoid system failure.

No amount of configuring is going to make a Windows box any where near as reliable as a mainframe. I think though you have confused availability with reliability in your last paragraph - I mentioned before I would not deny any well designed distributed system running Windows / UNIX or any other OS or hardware you fancy could be 100% available as long as you design for failure and the workload is suited to being distributed.

Availability

Seems we are arguing on the same side now - availability is always possible with cheap windows or UNIX boxes. And you are right to say its a function of reliability of the underlying components to a degree, although designing the system to be parallel will make for a very highly available system even with unreliable components.

This is not the space the Mainframe operates in -> mostly workloads are not able to be distributed so the reliability of the underlying components is very important when you have one very large box in your primary datacentre and another parallel sysplexed into your backup DC. You would never put such a workload on one Windows box in a DC - even if it could handle the demands it would never be reliable enough. You no longer seem to be arguing against this point...

The physical storage MTBF is a poinless discussion since disk is not in the mainframe but would be FICONd in from an attached SAN. Same SANs (DS8000s for example) are used in pSeries and Z so its a different question. Its also an example where the sub-system is designed to be highly available even when the components it is made up of are not, so an analogy there to the overall discussion of reliability vs availability....