The z114 CPU doesn't keep up with anything > midrange x86, and its IO capabilities are limited by the inifiniband links it uses to communicate with the IO drawers. A pretty basic dual socket E5 v3 has more PCIe bandwidth available than you can get out of the z114. It appears that is the case for larger machines as well (aka there are E7 configurations with significantly more bandwidth than the z13). And yes, I've heard all about SC's and all that. But what most people fail to realize is that most storage adapters have some form of ARM/etc cpu onboard that does most of what the SC does on a mainframe, and people have been fighting the CPU vs offload engine battle for years for network adapters.

So, a lot of the mainframe advantage is in zOS/zTPF and not the hardware. Running linux with its inefficient block layer, misses the point.

Heck, your probably better off running linux on POWER8.

The biggest selling point was redundancy in the hardware being able to handle CPU/RAM/Disk/PSU failures without taking down the Linux VMs running on it.

Our workload was network bound, not much CPU or Disk IO load.

We ended up using generic Intel PCs (some custom built, some Dell and some IBM Netfinities). We had more down time with the IBM managed Netfinities, then with the custom built rack mount servers.

Back then we also had some Sun UltraSparc E3500 & E6500s, but we found that the Java VM (from Sun!) was much slower on the UltraSparc CPUs then on Intel CPUs.

I find it interesting that we had much better results from generic no brand rack mount servers then most of the expensive "enterprise" class servers.

Note: This was over 10 years ago.

Anyone have more recent experience with servers in a self-managed DC or co-location? It seems most companies/developers now use cloud/vps/hosted servers.

It's also not so easy to judge x86 as low end. Stratus and HP make some really high end fault tolerant/instruction retry x86 servers that could be considered mainframes IMHO.

Low end x86 servers are "good enough" for a large portion of what people use servers for, and a massive amount of work has gone into making distributed systems that can scale and handle faults semi-predictably. That said, I'd much prefer my bank account to reside on an IBM mainframe SysPlex for the time being.

Sun kind of struggled in the CPU market as well as indecision around x86 for a long time, it's one of the primary reasons they are now part of Oracle. Those E3500/6500 systems are very high quality and would probably still be running fine today if performance isn't the only measure of worth.

I've long been a fan of IBM's POWER system p or whatever they want to call it depending on the day of the week. It's positioned somewhat in the middle of x86 and mainframe, but you generally get more powerful systems than x86 with mainframe inspired reliability. Still, these fill a much narrower niche than cheap x86 boxes.

We also had two large (U8) Compaq ProLiant servers that we used to run Oracle DB. We didn't have any problems with them, and only replaced them with newer faster Dell servers later. The redundant PSUs and hot-swap drives were the main reason we ran our database on them (one master, the other a standby slave). Those server were later used for our beta site (used for staging/development).

We later ported the backend Java service to C++, which most likely would have run fine on the UltraSparcs, but I think we had already sold them or returned them back to the vendor. I really wished Sun's UltraSparc T1 & T2 CPUs had taken off. I think they could have really good CPUs, but it was hard to compete with x86 because of all the software that was already compiled/optimized for the x86 architecture.

For us it was important to be able to fix problems quickly. Having to call in a service tech. to fix a hardware problem just increased downtime. Also we just had really bad luck with the IBM Netfinities, all 4 servers had a bad motherboard which failed in each server at different times. After that we didn't have any problems with them.

Personally I prefer to deal with generic hardware that I can service myself when a problem happens. But for some companies, it is better to have managed hardware with service contracts.

It was awful and we discovered why a few days in -- running our workload on a few VMs on my crappy corporate laptop in VMWare smoked the mainframe.

I guess it's better now, but it seems more like an Oracle license laundering scheme that something anyone would choose to run.

POWER8 is designed for UNIX, and adjusting for certain parameters goes beyond what x86 servers can do in the same footprint and reliability. Price is approachable to people who need the reliability these kinds of systems can provide. IBM systems have grown a lot in common over the years, with AS/400 or System i and RS/6000 or System p melding together, POWER8 kit has a lot of mainframe inspired RAS features.

+1 Insightful

Of course, this scenario isn't what LinuxONE boxes are made for; they are more focused towards open source deployments in the enterprise, with low license costs (usually only support contract costs).

That and getting software to run on it was almost impossible. In the end we ended up moving everything to HP servers for a fraction of the cost.

The Linux dichotomy IBM created is pretty stupid. I don't know why you'd want to run a tire fire on such expensive HW, sure maybe utility VMs, but not as the raison d'etat. Instead they should be a lot more willing to provide cheap z/VM, z/OS, z/TPF licenses for smaller shops to build up an ISV, admin, and porting community. But they charge thousands of dollars for an emulator when Hercules is freely available and ADCD is quite restricted.

I recently bought an older one for the cost of a soda https://twitter.com/kevinbowling1/status/685240077161598976. I would warn against doing this for a number of reasons, namely FICON storage and licensing, but if you are determined it is a lot of fun.

I settled for hercules at home, hell of a lot easier to manage, and is pretty fast given that its a fairly naive emulator (aka no JIT/tracing/etc). I think if the turbo hercules guys (or someone else) added a decent JIT, and solved the licensing problem IBM would be in a world of hurt. Although, maybe not, the few remaining customers aren't the kind to run their bank/airline/etc on a 10k piece of hardware and an open source emulator. Of course, I've been wondering for a few years what percentage of machines are being sold to development shops to support the limited number of real customers. That is why we purchased ours, to support real customers, not to run any actual work on it. Of course I've also heard that most of the business class machines are sold with tiny capacities, because they are simply hot fail-over targets. The assumption is that if something goes wrong at the primary site, someone calls up IBM and gets them to boost the capacity on the idle machine as the workload is shifting over.

I've got to imagine they are barely breaking even on a minimal config baby class system. The yield on an MCM has to be minimal. You can find videos of how labor intensive the build of a frame is, let alone the engineering. I wouldn't even be surprised if they were loss leaders.

And that begs the question, why not grow the user base with aggressive placement, training, and development. Another $1 billion investment in Linux has no appreciable affect to most mainframe users, and no way there is an ROI. Imagine that injection on this small, loyal platform of users.

Yeah, it is a weird environment. The i/o on them is nice though, but everything else is so wackadoo I never want to touch it.

See: https://books.google.nl/books?id=Do1WCAAAQBAJ&pg=PA78&lpg=PA...

But from what the mainframe guys at work told me, hardware between 2 z boxes are pretty much the same and it's kind of licensed by load usage or components usage.

So if you want to downgrade or upgrade memory/CPUs/etc. (to a certain degree), it's just a matter of having an IBM tech to enter the right license in the console.

Never worked on mainframes myself, but have on Unix (and Linux) a lot. Had read some years ago that mainframes had some powerful features that were often not available on Unixes. One such feature that was available, could be HP's PRM (Process Resource Manager), which, IIRC (from my time at a HP joint venture), could ensure allocation of a guaranteed minimum percentage of system resources (such as RAM and CPU time) to a specific process (say a payroll job running at the end of the month). I remember being impressed by the concept at the time.

There was also HP MC/Service Guard, but didn't have a good idea what it did, just remember the name.

P.S. Had also tried out rtprio and prioc(n)tl on some Unix boxes, maybe one was an HP one, the other a SVR4. They allowed assigning (quite) higher priorities to specified processes, IIRC.

P.P.S. Both those product names could have been changed by now, or been merged into bigger products, as sometimes happens.

Edited to say that HP's PRM _was_ an example of a mainframe-like feature.

Written originally in PL/I and Assembly, it contains a kernel level JIT.

All user space applications target a general purpose abstract Assembly and they are AOT to native either at installation time or on-demand.

Other mainframes had similar approaches to code portability.

Sounds familiar?

Another cool thing are the catalog based filesystem and OO Assembly.

Integrating DB-like functionality into the system was ahead of time. The original, System/38, had capability security in the hardware enforcing an object-based view of memory with permissible operations on different types of objects: processes, I/O, arrays, stacks, and so on. The security implications of that means I'd recommend one to a business in a heartbeat if they hadn't ditched that for POWER.

https://homes.cs.washington.edu/~levy/capabook/Chapter8.pdf

All in all, System/38 was a very, forward-thinking and practical design that continues to prove itself year after year. If it doesn't exist, I'd like to see a Lesson's Learned report on that project and how the team decided what would be in it.

OS/400/IBM i (or whatever its called this week) is actually probably one of the cooler OS's still around. It should be mandatory study in any comp sci/comp eng OS classes, but sadly its not and because of that, a lot of wheels are being reinvented.

Java JIT doesn't write machine code to disk. OS/400 does, and then it re-uses the machine code until it no longer exists (you move to new hardware) or the bytecode is newer (you change the program and recompile), at which point it compiles the bytecode to machine code and stores it to disk again.

You just need to look to the correct JVM. Apparently people keep forgetting Java is like C and C++. There are plenty options to choose from and OpenJDK only plays the role of reference implementation.

If I am not mistaken IBM J9 is one of those JVMs.

>Sounds familiar?

I suppose you mean like Java and Python bytecode running on their VMs (of the language, not OS kind).

I've sometimes thought, as well as heard others say, that some of the tech advancements of earlier decades haven't been "re-invented" :) yet ...

Also the way Java gets used on Android and other embedded platforms.

Or the new deployment model for iDevices.

But the original idea was from Mesa/Cedar at Xerox PARC.

http://www.cl.cam.ac.uk/~mr10/

(Richards invented BCPL.)

He has an interpreter for BCPL. The page says:

BCPL, an interpretive implementation of the BCPL language and system, including many demonstration programs. Click on BCPL.html to obtain a copy of the current version. This version can be installed easily on most machines running Linux, Windows and MAC OSX. In particular, it is easy to install this version on the Raspberry Pi machine. See the Young Person's Guide to BCPL Programming on the Raspberry Pi (bcpl4raspi.pdf) for details.

His Wikipedia page:

https://en.wikipedia.org/wiki/Martin_Richards_(computer_scie...

says:

He was awarded the IEEE Computer Society's Computer Pioneer Award in 2003 for "pioneering system software portability through the programming language BCPL".[9]

C followed B which followed BCPL.

http://lowlevelbits.org/bitcode-demystified/

The 8000 VM tests I've seen picked apart are typically "a webserver" type load, not meaningful work.