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.
Hardware quality is the key here. It may not matter, if the application is even 30% faster on x86. But if the motherboard is buggy, or the parallel port is flaky, or cable can fluctuate, or the video card can get loose (early AGPs anyone?) — it is death. Even if the probability of it ever happening is very low, the costs will be devastating. Thus the expectation (probabilty times cost) of the loss is still lower than the cost.
I've heard of machines, where the CPUs or memory can be replaced without shutting down — 15 years ago (Sequoia)... Meanwhile, some controllers and OSes still don't fully support hard-disk replacement, or even network cable unplugging — today...
In Soviet Washington the swamp drains you.
No, I'm sorry. I just cant do it.
I clicked on the link, but did not see any photos of mainframes fighting each other to the death. It wasn't even mentioned in the text! I want my money back.
... and then they built the supercollider.
FYI...AS/400 is NOT a mainframe
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
Just a guess, do you work in marketing?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Many years ago, I had the opportunity to work on a VAX VMS system. It was an 11/750, shaped like an oversized washing machine, and took up an entire room with all its cabling, Hard Disk stack, RAM box, and a huge multiplexer.
Although it was a thunderously loud, kilowatt-sucking machine with the processing power of an 80286, it had a number of features that are simply not available until you start ponying up some serious cash:
1) Dynamic memory remapping - when memory failed, it would "fix" the bad parts with checksum or by reloading the data in the memory from disk, and remap the addresses to another chip that wasn't failed. It would VM out as needed if/when it simply ran out.
2) File versioning - you could "bring back" previous copies of any file in the system simply by specifying its revision NN times back. EG: "edit myfile.txt" could be replaced with "edit myfile.txt:1" to see the previous edition. This was simply awesome and I've not seen this elsewhere.
3) Automated clustering - simply by connecting several of these machines together with a fairly simple serial adapter, they would immediately "recognize" each other and start sharing loads as needed. I don't know how many of these could be clustered together, what the limits were, but the fact that it was so simple to set up and it "just worked" was simply amazing.
ECC RAM doesn't hold a candle to #1. I'm unaware of a production-ready filesystem that can match #2 above, and #3 is simply in another league.
Why hasn't this technology persisted to this day? DEC/Compaq/HP screwed the pooch on this one.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Well, what else would you orient your rocket propelled grenade at? Not hitting anything wouldn't be any fun.
My first experience was with the CDC 3200 series back in 1970. It programmed in Compass (assembler level). Cobol and Fortran as compiled languages. It was an Octal machine with the primary input being the card reader.
Each gate was on a separate printed circuit board and there were probably in excess of 5,000 PCB's in the mainframe and the various controllers. Quite a monster to troubleshoot unless the circuit was fully understood. We had a Tektronix's 545 scope with delayed sweep to trace out the circuits.
The main timing chain for the core memory was initiated by sending a "0" down a ringing coil that has various taps on it for the whole read/write cycle.
We kid about having to key in the boot code manually, but the 3200 required about a 20 step boot program. I still remember parts of the code even now.
And in the end, the love you take is equal to the love you make
Well, yes you are young. Perhaps a better definition for you would go thusly:
If it takes Chuck Norris a round house kick to destroy, instead of a simple side kick, then its a mainframe.
Well.. maybe. Or Maybe not. But Definitely not sort of.
So why not upgrade the OS to a supported version? If your hardware is recently purchased/new, it probably cannot even run too many releases of unsupported operating systems anyway. And all the latest IBM operating system versions run on all the mainframe models stretching back to the end of 2000 (three generations). IBM always has a lot of overlap.
If you have z/OS V1.x, the upgrade to 1.8 or (soon) 1.9 is free. If you have OS/390 still -- hard to imagine on recently purchased/new hardware since it doesn't run on the z9 anyway -- the upgrade to z/OS is probably better than free (i.e. you typically save money), and you usually save money on the other software that runs on z/OS. (z/OS introduced subcapacity licensing.) And you have a full year when you can run both on the same system for no additional charge to get the migration done.
An OS upgrade is extremely unlikely to break any applications. There's 40+ year old code that's still running, right along with 64-bit Java code written an hour ago. Your 17 to 18 year old code should be perfectly happy on the new OS. And here's a radical notion: you can actually change your code if you wish. You know, add features and functions. You're allowed to do that. :-) You run code as long as it has value on the mainframe, for as long as you wish, without the vendor saying, "Sorry, that code must die this year." Just keep your OS and middleware on at least relatively recent releases, that's all -- it's backward compatible. Change your code and add code as you want, when you want.
There are some pretty obvious reasons why there are still mainframes around: there's lots of "legacy" applications out there (in a US context, consider the Social Security Administration, the IRS, or the FAA). And there are systems with BIG databases (something like SABRE, or the IRS and SSA again). Mainframe technology has been running those for a while. To replace those with an unproven (in a similar context) new technology is not likely to be a career-enhancing move for the IT Director.
More to the point, though, is that in the rush to embrace the newest and coolest, some of the genuine virtues of the mainframe environment were overlooked. Back in the early 1980's, I was the head of IT, and a partner, in an investment management firm, the subsidiary of a larger financial services corporation. Our investment analysis process was pretty quantitative: we used statistical valuation models and optimization methods to build our portfolios. We ran all our internal applications on our IBM 4341 under VM/SP, and were linked into our parent's big iron running VM and MVS. We also were linked to fund custodians and to DTC [Depository Trust Co.] for trade confirmations, and got data transmissions from various exchanges to get prices for fund valuations.
Every person in the firm had an IBM 327x terminal, or the equivalent, on her/his desk. (The clerical staff had IBM DisplayWriters with 327x emulation.) I just pulled out a "Getting Started" guide from 1985: it has a terse synopsis of how to send and receive E-mail, how to use the scheduling system for things like conference rooms and overhead projectors, how to access our internal client and research data bases (including a small but growing index of technical documentation), and how to use our portfolio management application. Using these facilities was routine for the most non-technical people in the firm.
(Part of that was by design. For example, we made it nearly impossible for a portfolio manager to do a trade without using the portfolio management application. There was a bypass, for emergencies, but it was designed to be highly visible.)
Now, I am not claiming this was Nirvana. It was expensive, and I spent a lot of time negotiating with IBM, and other near-monopoly suppliers, to get better terms. And having what we had was entirely dependent on the fact that we were 100 percent an IBM shop. I'm not arguing for going back to those days at all; I do think, though, that sometimes people may have, as one of my colleagues memorably put it, "thrown the baby out with the dishwater". I still, for example, haven't seen a "virtualization" solution that is as elegant as VM on IBM hardware.
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.
What a fluff piece. The real news is that IBM is actively in the process of trying to kill the only competition that it has left in mainframes. And that they are using a bogus software patent lawsuit to do so. Against a product which is Linux based, no less.
The company in question is Platform Solutions, Inc., who realized that they can completely emulate the Mainframe CPU opcodes by changing the microcode in Intel CPUs. And use Linux to handle all of the IO. The result is that you end up with a much faster Mainframe than IBM can build. And you can charge a lot less for it.
IBM got pissed off with the only competition that they have left (since all of the other mainframe builders went out of business years ago; and in fact PSI has a ton of ex-Amdahl guys who are about the only ones left who understand mainframes outside of IBM, but I digress). So, IBM filed a bogus lawsuit against this start-up. This is Deja-vu if you remember how Amdahl got started.
PSI has countered with an Antitrust lawsuit, and some other ones, last I heard. But the bottom line is that IBM is behaving worse than Microsoft to try to kill off the only competition that it has left.
You almost never hear about IBM's actions with software patents in the Linux community. But their actions clearly show that they are willing to do whatever it takes to enhance their monopoly.
Mainframes have features that just aren't available in commodity or even server PC.
Mainframes are designed not just for speed, but also for reliability and throughput.
Throughput is limited in a standard PC because everything has to go through the northbridge chip and all I/O has to go though both the northbridge and southbridge chip. Depending on the make and model, a mainframe will have multiple and redundant I/O buses for drives and networking. And multiple CPUs with multiple redundant banks of memory.
Everything is monitored. If a stick of RAM starts to fail (they use ECC RAM of course), programs and data are dynamically moved to another bank and a service call is automatically logged. Same thing with drives, CPUs, power supplies, etc. Everything is monitored and redundant.
Mainframes are designed so they don't even have to be powered-down for service. Anything; CPUs, memory, drives, power supplies, can be replaced or upgraded while it's running. Users won't even notice.
Mainframes are designed from the ground-up for companies that absolutely, positively can not afford downtime. It's a completely different market than a typical server PC.
The reason Mainframes still rule the world is because of the IO speed. I do JAVA and COBOL development and the reason JAVA will NEVER win is because of the slow ass TCP/IP database access. My COBOL programs run 13.88x times faster because they use Assembler calls to DB/2 routines where as JAVA uses JDBC. JAVA loads at 3.6 recs/sec where as COBOL loads at 50 recs/sec. It doesn't matter how fast your CPU is when you are waiting on the network.
--Scott
--Scott 8-}
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
I think the generally-accepted criteria for a mainfame are:
(1) multi-user with fine-grained security model
(2) multiple access mechanisms (LAN, WAN, multiplexed terminals)
(3) multiple storage layers (caches, core, paging devices, disk storage, backup media), with redundancy and partitioning
(4) high-scalability, high-throughput busses
(5) error detection and correction (ability to 'rewind' your virtual machine at least a few steps back) which typically requires CPU redundancy, very good management of CPU state, and SECDED memory
(6) multiprogramming with good handling of parallelized tasks
(7) batch execution, and automatic recovery from nearly every imaginable error condition
All of this needs to be pretty transparent to applications and users, too.
--TheOrangeSquid Is it any wonder things seem so awry? We swim in a sea of confusion and don't have to think to survive
RAIS is great idea call me when they have invisible failover. The only company I know of doing this with PC hardware is Stratus. I'm talking about not losing any processing due to a machine or OS borking. I'm serious if you have this then the problem is solved.
Last time I looked the Linux/HA and all other projects had some serious issues with failover, there always seemed to be a single machine at some stage that could take the cluster away from the user.
The AS/400 like the mainframes has been built to be reliable. Hardware costs because it's specced not to fail, redundancy on everything is available. Not to sure about a processor failure on the As/400 though, might still be able to take the machine down. But everything else failsover cleanly.
So what have you?
It has to be big, insecure, have a big vent in the ceiling, be protected by inept guards with MP5s, eye scans, and laser beams, and have a 3D user interface that says "Access Denied" in big, big letters.
// MD_Update(&m,buf,j);
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.