Slashdot Mirror
The Mainframe Still Lives!
coondoggie passed us a NetworkWorld blog post about the incredible rock-em-sock-em mainframe. Knocked frequently in recent years, the site notes that IBM's workhorse continues to do important work in a number of enterprise environments. "While there are some out there who'd like to see its demise, a true threat to the Big Iron has never really amounted to much. Even today, the proponents of commodity boxes offering less expensive x86/x64 or RISC technologies say the mainframe is doomed. But the facts say otherwise. For example, IBM recently said the mainframe has achieved three consecutive quarters of growth, marked by new customers choosing the platform for the first time and existing customers adding new workloads, such as Linux and Java applications."
no shit dept.
Of course it lives, and in fact it has done things in 20+ years ago the the PC is just now approaching.
The Kruger Dunning explains most post on
Why would anyone want to see the demise of the mainframe, or any other particular technology? I don't understand all the emotion about such things: if the mainframe continues to provide value in certain areas, then customers in those areas will continue to buy it.
With the flexibility afforded by virtualization who wouldn't want big iron to pump out the megabytes? You can run dozens or hundreds of webservers or databases on a single mainframe with virtualization.
What is better equipped to handle iSCSI and fibre channel storage data that the massive crossbar-IO throughput capabilities of the mainframe.
Blade servers are to mainframes as a pack of mice are to an elephant.
All hail Big Iron! All Hail IBM! Hail Eris!
I'm just sayin'
The move away from mainframes, minis and midrange boxes happened because the commodity PC platform reached a point where it was a viable replacement for processing/storage requirements for which the old systems were sold as complete overkill (or there was no choice at the time). Wherever it was actually needed, there has been exactly ZERO migration and the mainframe is still the king of the hill, by far. So no, some of us are not "surprised" at all.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
This is inexcusable on ANY platform, never mind on a mainframe....
Sounds like it was written by my current crop of interns....sigh.
Which is not to say that using mainframes never makes sense. If you have a lot of tried-and-true legacy software, it might well be cost effective to keep legacy hardware around to run it. The alternative is to write replacement software that runs on modern systems, meaning you have to go through the whole development, QA, and deployment thing all over again, at huge cost. Very often it makes more sense just to keep using mainframes. But that's a matter of economics, not technology.
I would also point out that modern mainframes are not really "mainframes" in the original sense. The original mainframes used technology that became obsolete on the day microprocessor-based systems became more cost effective. What we now call "mainframes" are just specialized microcomputers that are optimized to run legacy mainframe code.
I knew this news was coming.
After the advent of client/server and GUI interfaces the mainframe was declared dead. Yet the web happened, and all of a sudded all the inefficiencies of the GUI interface was replaced with, effectively, a 3270 terminal because it's a more efficient network model. Enter data, submit, wait for a response, just like a mainframe, but somehow... new?
In the past few years, virtualization has become a huge topic, and it's most interesting following the developments of Xen and Vmware and Solaris Containers and all the hardware vendors just now designing and building support for virtualization... and then I realize again... haven't we been here before? Virtualization is old technology, tried and true on the mainframe, and it's going to be some more years before it becomes a commodity. Oh it'll be here, someday, but again, don't hold your breath waiting the mainframe to go away as yet another generation realizes the advantages of what as invented long ago.
#1 is available on x86 workstation systems in the form of Chipkill, which isn't too far from being commodity hardware, it's relatively easily obtainable. I'm sure Intel and AMD could easily bring it down to consumer systems if there was any call for it, but there really isn't.
Tell that to Google. The PC world needs better tools to break up processing tasks and data into small units that can be distributed over a large number of inexpensive and unreliable machines. With automatic failover and recovery. Google seem to be inventing and using such tools all the time.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
Don't forget the thin client technologies that are currently making a big impact. We're pretty much back to dumb terminals again. Having a large, centralised system is obviously an advantage until we find some way of utilising all that wasted power in the 2GHz desktops with 1Gib of RAM that companies buy in the hundreds.
It strikes me that along time ago some clever sod managed to dupe companies into buying and maintaining individual PCs at huge cost when small, lightweight terminals connected to a central mainframe were doing a great job. It's taken us nearly 20 years to notice that all people in most companies ever run is Office and most of them don't use even half of the features that were available in, say, Word 6.0. The idea of having hundreds of desktop PCs was a big mistake full of compromises like network drives, roaming profiles and remote control apps like VNC or Microsoft's Remote Assistance, none of which you need if you have the mainframe serve out desktops.
The greatest example of the evolution of the mainframe is the web. Web apps and office suites are quickly evolving thanks to technologies like AJAX and this all harks back to the general mainframe concept: Your clients show the UI, your (possibly distributed) servers do the work, keep the backups, and store everything in one place that's relatively easy to administer. If it goes down you have redundancy in the form of HA clusters or whatever to keep the system as a whole working. These ideas never went away, for some reason we just lost focus.
One important reason for the refusal of mainframes to die, is the enormous body of non-portable software written for them. Non-portability is a key advantage. Non-portable applications are what kept people buying mainframes, what kept DOS alive for many years, and what kept people using Windows 3.1 and Windows ME when it sucked ass.
Non-portable applications were written for Mainframes and DOS because the systems were so old that portability wasn't really a consideration when those apps were written. In other words, non-portable apps are a side-effect of having an old system, and they cause the old system to linger.
...The problem with running Oracle on a Sun E10k, is that you can swap out the E10k. Your application code doesn't have to change. Same with java applications. But something written in COBOL that accesses weird hardware-specific data ports and weird OS APIs will keep that hardware around forever. Because those applications will never be rewritten. Because, when it comes time to re-write the apps (ie when you want to run them on another system) they will have decades of convoluted business logic embedded in them, making a re-write practically impossible.
If I were a mid-sized business that needed an accounting system or other line-of-business app, I'd be looking at AS/400 based products.
You buy an AS/400, plug it in, and ignore it. It just works for years and years.
Sure, it's not sexy-GUI, but who cares -- you're tracking profit-loss numbers, not pictures of your classmates.
For techno-lust: they're 64-bit with single-level storage. Which means that all attached storage is mapped into a single address space. Add a new RAID array? To the OS, it just means that there's now an additional block of addressable memory. None of this kinda-sorta 64-bit support like on the x86 platform -- it's FULLY 64 bit.
Security is enforced in hardware, too. No TCM chip needed -- there's an extra bit that's used to separate user and system code. The only way a user program can elevate it's priviledges is by way of a soldering iron.
Chip H.
Google isn't the end all and be all of technology. Their problems are large, but easy. Searching is easily broken up, and there is no penalty for being late or for failure. If a ton of boxes goo down and the job can't be completed, boo hoo, people get search results that are a day old and nobody even notices.
Lets talk about, for instance, a bank. What you want to do is accept trades from almost anyone, for almost anything, while simultaniously analyzing all your positions so you can do offsetting trades and make sure that your net position doesn't grow too large.
If the server fails, that's a problem.
If the server is late, that's a problem.
If the server ever gives a wrong answer, that's a problem.
And, of course, many of these tasks would really, really, really like to know pretty much everything about the whole state of the market, which is far too large to fit into a single machine, but it could fit in a mainframe (or a supercomputer, I suppose).
At work, all the booking goes through mainframes eventually. Also, a lot of our DBs are just too large and too intensely used to fit on any standard server. We could split it between servers, but that doesn't really work very well either, joins don't like to be separated. If only there were a giant box that has more memory than a whole building full of PCs, etc... Oh, right, that would be a mainframe.
I work on stuff that doesn't use a mainframe, just quad proc boxes with 8GB of ram, and they're way too small. We end up recomputing numbers hundreds of times because these machines just can't have enough space to store them.
Of course it lives, and in fact it has done things in 20+ years ago the the PC is just now approaching.
Mainframes aren't just about capacity. Mainframes are about reliability. They keep running - even as broken pieces are repaired or replaced, and equipment is upgraded. They use error correction to insure that the overall machine never drops a bit or makes an error, even though the individual components do. And so on.
It's not just IBM either. For instance there's Amdahl (now wholly owned by Fujitsu). Last time I looked (a few years back) ALL the baby bells did their real-time call accounting on Amdahl mainframes. Keeping them running was important - because if you had to reboot all the calls on the network were free. That's several million per hour down the drain - but NOTHING compared to a similar problem in a server supporting a brokerage's trading.
There's a lot of stuff you can do on networks of comodity machines. But when you truly need a "no bit shall fall" environment there's still no substitute for a mainframe.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
IBM Z-boxes and Unisys Clearpath boxes are to high=end Sun boxes as High=end Sun boxes are to UNIX workstations and high-end PCs.
There's a very large performance gap between all three of those groups of computing hardware.
I would also put SuperComputers in a fourth unrelated group.
The difference isn't just software. Believe me. And most Big Iron isn't "old" -- it has been going through the same types of advancements that single-user desktop machines have been, but their focus in advancement has been on wider and faster I/O channels, on clustering, and on hardware and software redundancy and integrated failover/recovery rather than 3D video graphics and faster CPU MIPS values.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
I could buy something like 60 nice Dell rackmount servers for the same price and make a small Linux cluster of them. I'd end up with about 30 times the throughput, 100 times the storage, and 0% of the software cost. I cannot believe that the AS/400, solid as it is, has better uptimes than a 60-machine cluster (given that only about one tenth of those machines had to be online to exceed the AS/400's performance). Heck, for half the price, you could have two smaller clusters in geographically distinct locations with a high-speed link between them.
I don't doubt your numbers, but I believe you're leaving a lot out. Let's analyze this:
1) You equate an AS/400's price with 60 Dell rackmount servers. Although you didn't specify *which* Dell rackmount servers, assuming 1U each, this is two racks of Dell, minimum. The AS/400 takes about half a rack, but we'll just generalize to 1 rack. The Dells cost at least twice as much in floor space. Data center space: AS/400 wins.
2) Power. Minimum 60 AC-DC converting power supplies for Dell. How much is wasted in the conversion for the Dells? AS/400 wins. Minimum 60 power drops needed for Dell. How many does the AS/400 need? AS/400 wins.
3) Cooling. 1 rack for the AS/400 vs 2 or more for the Dells. AS/400 wins. I will guess that all the extra heat from having so many power supplies will just make the Dells more of a loser.
4) Network access. 60 individual NICs to configure for the Dells, and 60 different network sessions. AS/400 wins. 60 individual network drops for the Dells, and that would be at least a 48 port and a 12 port switch combo --maybe three 24 port switches? AS/400 wins again.
5) Storage access. You have 2.5 options. 60 individual disks for the Dells, 60 individual Fibre Channel HBAs for the Dells, or 60 saturated NICs running iSCSI for the Dells. AS/400 wins on either not needing 60 disks, or 60 HBAs. iSCSI could be a wash.
6) Console access. If the network fails, you will need to get onto the console. All 60 of them for the Dells; 1 for the AS/400. AS/400 wins. Good luck with 60 KVM ports. I recommend Avocent. If you can "get by" on one console at a time for the Dells, you'll need to pay someone to switch the cables, or physically be there yourself. AS/400 wins.
7) Sys admins. You only need 1 for the AS/400 -- and still have time for 59 more AS/400 servers. Good luck with the Dells -- you'll be bogged down with just that one cluster while the AS/400 admin is busy with the equivalent of your 60th (just an educated guess). AS/400 wins.
8) Fault tolerance: See #1-7. Simplification allows for easier problem resolution and time for other tasks. AS/400 wins.
9) Service contract: 60 machines for Dell vs 1 for IBM. Does the AS/400 support cost 60 times more for the same level? I'm guessing, no. AS/400 wins. Dell might not even offer service contracts for the machines you're comparing (hard to tell since you never mentioned which ones).
Hey, I'm not an IBM shill, nor am I short on Dell (I'm only expanding on your comparison). But you have to seriously consider the application here. And you will run into scalability issues with that many machines -- and scalability means money. Along the same lines, you might not want a whole lot of reliability, but you'll sure be spending the money you save (and likely more than that) for all the hidden costs I've listed above.
Google does fail though. I have gotten error messages when trying to load google.com and the search results. Only twice mind you, but still.
:x
Let's assume gdb actually works and delivers the information you want.
Were you running it at the time? In production? All the time? Did it catch the fault? And did the hardware/driver/OS stay up in order to catch it? Was there hardware key-protected memory so that you know exactly what put what into that memory location? Did a cosmic ray bounce an electron inside the microprocessor?
Say what you will about the mainframe, the original poster was right. Debugging, tracing, fault analysis, and related tasks are like nothing else around. These capabilities are embedded deep into the hardware levels, and you cannot escape them. The philosophy is that if you're going to run it you damn well better be able to troubleshoot it at all times. And I'm serious about that cosmic ray reference. The dirty little secret is that microprocessors, as they get faster and hotter and more dense, are getting less reliable and generate less consistent computations. Mainframe processors effectively run everything twice, compare, and reconcile automatically, and the layers above (OS, middleware, applications) have absolutely no clue it's happening. The mainframe never lets so much as a fault add or bit shift surface to the OS: it'll dynamically swap in a spare under the covers until the redundant circuitry fully agrees.
There's a lot of stuff you can do on networks of comodity machines. But when you truly need a "no bit shall fall" environment there's still no substitute for a mainframe.
Tell that to Google.
Google is not a "no bit shall fail" environment. They have entire machines fail every day, and just replace them. If a search fails, run it on an other machine. Lost a couple of pages from the search database? Googlebot will find them again... Not so with financial data.
Google is kind of a special case. Individual nodes do fail constantly, but it doesn't really matter because they form a distributed system designed to take such failures into account, and the search algorithm is a parallelisable task. If you need to do something difficult / impossible to parallelise with very high reliability and accuracy, and/or don't have the space etc for a huge number of PCs, then a mainframe makes sense.