« Forrester: Service Level Shortcomings Are Pervasive & Costly | The Mainframe Blog Home | South Dakota Migrates (1 Application) Off Mainframe; Chaos Ensues »
The Pitfalls of Mainframe Linux
In another forum, an IT project manager from the financial sector asked what might be the downside to mainframe Linux. Since so many have touted the positive aspects of Linux on System z, in balance, what are the drawbacks? Excellent question!
My answer ...
I come from the "big iron" side, but have been a multi-platform player for decades so have some objectivity. Disadvantages of Linux on the mainframe are few and include:
- high entry bar because of the class of hardware
- lack of graphical console and confusion over text mode consoles
- emotional stigma attached to mainframe stereotype
The first challenge is the bar to entry. Even a low-end System z represents a bigger up-front investment than most laymen can make, so running Linux there is beyond the reach of hobbyists or casual Linux users. When such a user shifts and begins to consider Linux professionally, there is a gap due to lack of exposure; they are unfamiliar with the mainframe port. As hardware goes, System z scales extremely well in both directions, up and down. But the very lowest end of the action is the realm of other hardware. (got hand-held?)
A second negative is lack of sexy graphics. While there are plenty of graphical devices for System z and its predecessors (S/390 and older), the Linux port makes no use of them. You can run X windows applications, as most of us mainframe Linux users do every day. But the physical display for such use is attached elsewhere. This goes hand-in-hand with the lack of warm fuzzy feelings many consumers have about their computers: they can't usually touch and see Linux on System z so they don't get to know it in the same intimate way. Virtual machines help, and z/VM is the most robust virtualization environment, but it still does not fill in this gap of a graphical console for Linux. (Then again, some users have the same problem with virtual machines as with mainframe hardware because of the need to touch, see, feel, ... scratch, sniff.)
But surely the worst thing about Linux on the mainframe is the political baggage of the word "mainframe". When people hear it, they immediately think of green screen applications which they hated in prior experience. Forget the advantage that the hardware can support retro code letting companies defer costly package upgrades or painful package replacements. Never mind that the hardware and traditional operating systems have nothing directly to do with the in-your-face formalities of business. "It's a mainframe and we know that that means." [sigh]
Our friend in the financial world probably expected to hear about dollar costs. Sorry, Charlie. Better fishing elsewhere for that kind of stuff. He did, however, ask an important and uncomfortable question. Now, I do not work for IBM and hold no stock in that company so my opinion is not tainted by personal gain: I can fairly say that the biggest con to mainframe Linux is social. There is also a real boundary for low-end scale down, but it is minor.
Mainframe Linux pitfalls? Few and hard to find.
-- R;
| by sirsanta | July 10, 2008 Permalink |
TrackBack
TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d834521c8469e200e553b053568834
Listed below are links to weblogs that reference The Pitfalls of Mainframe Linux:
Comments
The lack of a (directly-attached, X-Windows) graphical Linux console is not unique to System z. The typical blade server, and certainly any mid-range or large distributed RISC server, behaves similarly. Most servers are "headless."
And I'm not sure it's even true for System z anyway, since there is a "head." The System z Hardware Management Console (HMC) runs a "sealed," graphical Linux now, and you can (and typically do) perform the initial z/VM load right there from a DVD, not tape. Novell SUSE Linux for System z now comes in a pre-built, ready-to-start image -- you don't even have to bother with the traditional Linux installation procedure. (Pre-built is possible with System z because the hardware is a known quantity.) And here's the "complexity" involved in starting the graphical interface in that pre-built image:
Step 1: Log on using the default password.
Step 2: Enter the vncserver command (that'd be 9 letters).
Step 3: Connect using any of a dozen free VNC clients on your PC.
Step 4: Run Firefox on your mainframe if you want. You're fully graphical.
Yesterday I trained 20+ people how to install and configure various popular software products on Linux on System z. Exactly zero of them had any prior experience working with mainframes. I had a 100% pass rate: they all were masters after an 8 hour class. "This is easy," they said, and it is.
Anyway, I'd scratch that one off the list.
Posted by: Timothy Sipples | Jul 11, 2008 4:24:03 AM
Well- let's see- how about add this one to the list:
linux like all unixes on the mainframe are essentially a cpu performance pig compared to traditional mainframe operating systems. Applications will inherently consume more cpu because the interpretive overhead of unix i/o in cpu time overshadows any benefit in concurrency and offload that channels could have provided, at least for disk. Networking seems to me to be less clear, but in both cases, IBM certainly doesn't give its customers any real research-based performance information to rationally arrive at a decision. After all, their business is to sell engines, and the more they can cater to linux and java, the more cpu engines they can sell.
Posted by: emes | Jul 14, 2008 5:03:20 AM
Well- let's see- how about add this one to the list:
linux like all unixes on the mainframe are essentially a cpu performance pig compared to traditional mainframe operating systems. Applications will inherently consume more cpu because the interpretive overhead of unix i/o in cpu time overshadows any benefit in concurrency and offload that channels could have provided, at least for disk. Networking seems to me to be less clear, but in both cases, IBM certainly doesn't give its customers any real research-based performance information to rationally arrive at a decision. After all, their business is to sell engines, and the more they can cater to linux and java, the more cpu engines they can sell.
Posted by: emes | Jul 14, 2008 7:03:51 AM
...But, even if that were true (Linux=more piggy), Linux CPUs (IFLs) are cheaper. Same with Java (IFLs or zAAPs).
For perspective, keep in mind that people complained about COBOL performance many years ago compared to 360 and 370 assembler. Times change.
Posted by: Timothy Sipples | Jul 14, 2008 9:52:28 AM
The difference today, in the context of profligate resource waste thanks to the miseducation of professionals of the computer science persuasion, is that energy costs a whole lot more, and so do people(unless they've been outsourced to some distant land of exploited labor).
It's not about cobol vs assembler- it's about the aggregate ongoing costs in energy, management, maintenance, and refinement of systems as a whole due to the culture of inefficiency and lack of sensitivity to a shared workload environment.
Posted by: emes | Jul 16, 2008 11:10:18 AM
But assuming that's correct -- that those darn programmers are wasting computing resources -- the way to begin addressing the problem is to embrace the mainframe, not to run away from it. And mainframes do a wonderful job saving energy.
Mainframes measure resource utilization and can pinpoint exactly what is using what (and when). It's like an MRI: it'll tell you what's going on inside the code.
Now, that is a cultural adjustment for many developers. You're asking them to code well, not only code. In my experience most of them seem to make the adjustment without too much difficulty, although it's much better if you anticipate that and clue them in first.
All that said, it's a matter of degree. Very few people are counting individual instructions in code path lengths any more. People focus on much coarser measurements, as they should. The cost of each instruction has collapsed and continues to decline. Resource optimization costs money, and you don't over spend to optimize unless there's a big enough benefit.
Posted by: Timothy Sipples | Jul 17, 2008 12:58:56 AM
No one argues for instruction code path length counting today. It is empirically true that the mainframe is the best instrumented for true understanding of resource utilization. Nothing said here argues against the mainframe- what is being asked is whether linux is the best target for business oriented transactional work given that as a unix-derived environment, it cannot even begin to properly support the shared workload environment of a mainframe in the same manner that zTPF, zVM, and zOS can. If there were not the skewed and distorted monthly licensing schemes associated with these systems, as well as the desire to exploit cheap labor, no one would waste their time with linux on the mainframe. Unfortunately, distorted pricing schemes make linux very often a cost-effective and functional albeit inefficient solution guaranteed to sell engines and services.
It could be argued that if IBM would simply get serious about VM, stop turning it into a mere sandbox for inefficient virtualization-based workload rationalization, provide it with a more up-to-date and useful internal way of porting useful unix applications, and offer a more friendly and comprehensive development context inclusive of traditional IBM languages as well as the newer ones, I think we would find the green computing argument becoming even more compelling at an even lower cost, along with many other benefits. If IBM would license TPF under more reasonable terms and only require this enhanced VM rather two to three additional operating systems to make it functional, combined with a genuine marketing effort to make it properly understood, this would also go a long way. Any of these options will always be better than linux on the mainframe any day of the week. Just because the crowd is doing something doesn't make it intrinsically compelling.
Posted by: emes | Jul 24, 2008 10:25:16 AM
Who said Linux is the "best target for business oriented transactional work"? Let's stipulate purely for sake of argument that it is not. Isn't it still possible that Linux has substantial value? Like maybe non-business oriented transactional work? Or business oriented non-transactional work? Or non-business oriented non-transactional work? :-)
It doesn't make any sense that there would ever be a single operating system "best" optimized for every mission. There never has been so far, and there's at least 60 years of electronic computing history behind us. My iPod does not run z/TPF or Microsoft Windows Vista, nor should it. Different operating systems serve different roles, and are optimized and designed differently. There's a reason that there are multiple (and multiple growing, and possibly additional) System z operating systems: they aren't substitutes for one another.
Posted by: Timothy Sipples | Jul 25, 2008 6:00:16 AM
Ho hum! All this mainframe bigotry is a bit of a bore! I'm a 20 year mainframer and think I know the platforms strengths and weaknesses. Number crunching is a weakness. I worked for a UK food retailer that was the first company in the UK to implement a DB2 data warehouse on the mainframe. When it came to data mining we got an SP2, great box. It was fast, very fast! That was in 1993, the current crop of *nix boxes are scary monsters, and they scale up to supercomputers.
I think zLinux is a good thing. It gives the customer a lot of options, open source etc. Not to mention great QOS when connecting to z/OS legacy applicatons in the same complex.
If linux is so bad then how come it's the platform of choice for one of the worlds biggest OLTP systems http://highscalability.com/amazon-architecture.
Posted by: David Crayford | Jul 31, 2008 8:15:17 AM
For the record, the System z10 is quite excellent at many different types of "number crunching," something not previously typically associated with mainframes. It's one of only two processor architectures (the other is POWER6) that has an IEEE754r hardware decimal floating point unit, for example, which greatly speeds up (by roughly 3 orders of magnitude) high precision decimal floating point calculations compared to the software-based alternatives.
Another type of number crunching is cryptography, and the mainframe is absolutely wonderful doing that.
Posted by: Timothy Sipples | Aug 1, 2008 2:09:43 AM
I agree that hardware based DFP is a good thing. Mike Cowlishaw did a fine job, not just with the specification but with software packages like the C decNumber package and the Java BigDecimal class.
As for crytpgrapy, most high end *nix boxes would chomp up a SHA-0/1/2 hash for breakfast and then size up SHA-256/224/512/384 for lunch without a co-processor.
The z10 is an impressive machine, but there are many impressive machines on the market with much lower price points. I hope zLinux will be a success, and the recent announcement that z/VM is free for z10 customers running linux is a big step in the right direction.
Posted by: David Crayford | Aug 2, 2008 12:27:02 AM
