Stayin' alive: Ten years of Linux on the mainframe It would be hard to find two technologies that would seem to be more diametrically opposed in the data center than the IBM mainframe and the open source Linux operating system. But the combination of the two, which then-IBM president and now IBM chairman and CEO Sam Palmisano championed (or more precisely, gets credit for …
Why anyone would choose to run Linux on such an unspeakably overpriced hardware / host platform which has such a small available skills base to support it?
Is it still the quaint idea that reliability and availability comes from Jurassic park scale overkill in hardware resilience and that somehow if you pray hard enough you will never have a failure?
In the existing mainframe victims, erm , customers, I can see why the mainframe priests would want to run something else on their expensive white elephant to preserve their jobs by ensuring that you can't run a basic Linux without being inducted into the company of white coats. This doesn't hold for new customers though, unless their CIO is ex-mainframe shop and doesn't want to start paying for his own golf club membership at this point in his career.
"Cheap" in the context of mainframe is like "truth" in the context of politicians, a purely relative term that has little relation to the generally accepted meaning.
Perhaps I just underestimate how good the IBM sales people are, maybe they stopped selling snow to Eskimos and Oil to Gulf fishermen because it was too easy, now they make their real sport convincing people that a mainframe can be cheaper than something else? Maybe it is cheaper to run your Linux on a mainframe than develop a new stealth bomber but that is about it...
Mainframes still do both more efficiently than any other architecture out there. That's not to say that you HAVE to have a mainframe to do these things. Sometimes you need a one pound hammer, and sometimes you need something that'll drive 3 foot pilings through 60 feet of sand and rock. :)
I, for one, am glad that some services employ hardware that doesn't need to be powered off just to replace, say, a failed processor or memory module, and which, unlike "commodity" hardware, is happy to run at a hair under full utilization for a decade without choking on the thousands of transactions per second it has to handle in real time.
Does your ATM card work? Your country's power grid? Air traffic control? If so, thank "Jurassic Park scale overkill in hardware resilience." It's there for a reason. The first customers for Tandem were airports, if I remember history well. Does everybody need a mainframe? No, of course not. There's no need to spend over a million dollars on a reliable computer unless your company is worth more than that and depends on having something that reliable; frequently, however, that is the case. Alternatively, maybe you need something that does the work of several hundred "commodity" servers with a fraction the floor space, power draw, heat dissipation, component failure rates, and maintenance costs. I guess that's important sometimes too.
but there have been in the past compelling reasons why mainframes made good sense as UNIX/Linux systems.
If you look as a sysplex or whatever they are called now, you can effectively have uptime as good as your software resilience, provided that the hardware it has been designed properly. The different parts of a sysplex can be in different locations (not sure about the distance between them) on different power infrastructure.
I'm not sure about the IFL's, but normal z9/z10/z11 processors have multi-bit memory protection, register parity, multiple data paths, failed instruction re-execution and dead processor detection that gives almost complete protection from single component failures within a system.
And while virtualization in the x86 world has been progressing leaps and bounds, it is nowhere near the maturity of the mainframe world, except when deployed as a mainframe (like Unisys do). As far as I am aware, there is no way to aggregate multiple x86 servers to make a single large general purpose system image, even using clustering technologies.
When you build multi-processor single systems even using x86 technologies, the prices tend to climb quite rapidly.
All of this technology costs money, and whether it is worth this is a value judgment that the customer has to make, but it is certainly not the no-brainer that you appear to believe.
Next time you see Karl, or for that matter Sam, say hi from me.
I think if you check Tim, Sam was in fact head of IBM Systems Group when Linux was first proposed for System Z and Karl was System P marketing.
I still have somewhere in my collection the spoof analyst and press reports I made up to illustrate how this might get perceived and how to position the speciality engines.
However, be clear, the whole IBM Linux strategy was really about positioning the company to be ready for the tidal wave of people, technology and skills that would grow out of the emerging economies adoption of Linux, which was inevitable as it was, err, free.
The fact it might sustain the mainframe, or provide a wedge to drive between Microsoft and developers etc. Were all side effects of the former, not the drivers.
Still I failed in one respect. At a keynote at the, I think, 2002 System Z expo, or whatever it was called in those days, I claimed that as an industry we would have failed business if we were still talking about Linux as an OS in 5-years.
I had meant, instead of focussing on business apps and their runtimes like Java, Grid(ah hem) etc. IBM wasn't so pleased with the remark and I was called to explain myself.
Good fun, enjoying myself over in x86 land at Dell these days working on, err, embedded Linux "solutions".
"I had meant, instead of focussing on business apps and their runtimes like Java, Grid(ah hem) etc. IBM wasn't so pleased with the remark and I was called to explain myself."
But there are also people who need to process a bit more data than beancounters. Think of engineers, scientists or quant traders. Java would make their computations ten times more inefficient and/or expensive.
IBM basically makes support contract mandatory on their high-end systems. So no specialized staff are required.
I'm remember "working" with an IBM "Shark" ESS. Our on-site staff couldn't even open it. It, like most IBM high-end gear, had a "phone home" system. IBM techs just showed up, did work, and recorded something in the maintenance log book. All part replacements, firmware replacement, just happen by themselves, and were all included in the cost of the unit.
So, no "priests" or "white coats" required.
Plus, uptimes of 10 years on average is pretty good too. If your business needs that, IBM is the only game in town.
As others have pointed out, if your yearly revenues exceed 50 billions or so, you could loose about 200 millions per day of IT downtime.
Certainly it makes sense to shell out 50 millions per year for IBM mainframes to bring unscheduled downtime per year to less than an hour.
IBM did nearly everything which is technologically possible to ensure these availability levels. You can hot-swap disks, CPUs and memory. Restart full OS instances without affecting anyone else. The MVS OS is know for very good security and it is now very reliable. Most of the world's banking and credit card transactions run on IBM mainframes.
I think Linux is more an attempt to have a modern operating system in case MVS/zOS falls out of favour. IBM was scared about all those Unix upstarts so they decided to have something of their own. It turns out that MVS shops don't want to switch at all. Probably there will be some kind of MVS around in 30 years time. New people learn it, as there is lots of money behind it and the Unix vendors often deliver cheap and crappy systems.
You can see it just by looking at the physical quality of the racks. Cheap plastic parts of HP server casings don't foster any feeling of high quality.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
