The Mainframe Still Lives! 372
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."
Wrong Again! (Score:4, Interesting)
I have come to very much appreciate the high availability (24/7/365) and stability of the mainframe. In fact, when I get approached by vendors these days telling me I can support virtualization on high-end PCs, which cost $1M or more, I ask, "why not just by a Z-Series."
Long Live the Mainframe!
Maybe someday, I'll learn COBOL...
Put it like this ... (Score:4, Interesting)
Re:Some want to see the demise of the mainframe? (Score:5, Interesting)
Features that you can't even buy anymore (Score:5, Interesting)
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.
Re:Put it like this ... (Score:3, Interesting)
My first Mainframe (Score:5, Interesting)
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.
Re:Put it like this ... (Score:2, Interesting)
Re:Still going strong... (Score:3, Interesting)
True - getting screwed by an AS/400 is more like a state of being. I went to a free lunch given by the local IBM rep and he was talking about the wonderful, affordable iSeries. Everyone else in the room thought that subscribing to CPU output levels was perfectly reasonable, and that paying a base rate and a (much) higher per-time-unit rate for higher utilization so that you could power through quarterly reports was simply marvelous. Oh, and they'd dropped their prices for SCSI drives to only $3000 per 36GB or something amazingly affordable like that.
Honestly, it was like going to a Scientology convention. The audience ate it up and the sales rep just kept shovelling it on. The more outlandish the quote, the bigger the grins.
I don't mean to hate on any particular computing platform, but I swear to God, the costs that the rep and his customers were casually throwing around were mind-bending. Yeah, they might be wonderful, but at $250,000 for a decent size server, they damn well should be.
What Makes a "Mainframe" Anymore? (Score:3, Interesting)
What is it that makes a computer a "mainframe"? For years, the "Big Iron" programmers insisted that they worked with the only real computers, and the term "mainframe" was always associated with big machines that could only be used by the most experienced programmers. That's just silly; either your computer is Turing Complete or it isn't (making allowances for finate memory limitations, of course). The important distinctions are:
Big Iron has always had points 1 and 2, but clusters of cheap PCs can often match their level. In practice, current Big Iron hardware isn't fundamentally different from current PCs--it just tends to have better quality control and "more" than whatever's in the PC (more RAM, more hard drive, more processors, etc.). In fact, an AS400 is about the same size as a large server PC, not the room-filling Big Iron machines of yore.
Number 4 simply has to do with what sort of connectors and drivers you have available.
I've had personal experience with RPG, which is why I say with confidence that mainframes are utter failures at number 3. The languages are so primitive that they've barely discovered indentation blocks (and some older programmers shun this "freeform" mode). Sure, they run Java now, but I didn't need Big Iron to run Java. I'll take a VB job before I touch RPG again.
If the programming languages are what make it "Big Iron", then I hope it dies a horrible death.
Overall, we don't need the special terms "mainframe" and "Big Iron" anymore, because all the machines that fit those descriptions are better called "servers" or "supercomputers".
I must say, however, that I am impressed that old Big Iron still works, and in fact still runs a lot of financial transactions. It's no exaggeration to say that removing all the old Big Iron tonight would kill the world economy by tomorrow. It's best to keep those machines and programs in working order, since they obviously work, are quite robust, and solve many problems, whereas a new program may fail.
Re:Guess I'm too young (Score:2, Interesting)
It's similar to the difference between military grade and consumer grade equipment. For example, a GPS receiver you purchase that doesn't crashes on the trip to grandma is no big deal. A Navy SEAL squad that has a GPS receiver crash IS a big deal.
One of the things about the "Beowulf cluster" of commodity boxes is that they are cheap, giving some aspects of high-end computing power without the cost. This is for those garage-based start-ups that need some serious power but if a hard-disk drops out or a LAN connection goes dead it's not a huge deal.
Your mainframe setup is for large scale businesses, universities, nuclear research, all that fun kind of stuff. If your job is riding on it, get a mainframe.
Re:Sigh - the usual crap (Score:2, Interesting)
I have seen old crappy RPG apps, what you are reffering to (crunching 500 million unique vehicles) sounds it could have been one of those crappy 20 years old application full of spaghetti code.
Let's not mix hardware and software.
Linux and JBoss run just fine on zSeries. Rewriting an application in Java and running it on JBoss is one thing. The hardware you will run it on is another thing.
Note that I don't run zSeries, they are too expensive ;-)
I do use virtualization although to reduce the number of deployed servers. For rundundancy, the good old shared drive with a standby machine principle is used. This principle is used by Oracle, IBM, MSCS, etc. and is still viewed as more robust than linux grid computing by most corporate decision takers.
Linux grid computing is becoming more and more mature although and it will be interesting to see what happens in the long run.
Re:god bless virtualization and Big Blue's Iron (Score:3, Interesting)
I'm fairly sure my 400 blades run rings around any mainframe for what I do - floating point calculations.
Apart from that, go mainframe! As long as I don't have to get involved with it;)
Is this really surprising ? (Score:5, Interesting)
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.
What the article missed - IBM's illegal actions (Score:5, Interesting)
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.
Re:In a mid-sized manufacturing or distribution... (Score:3, Interesting)
I'm honestly not dissing the line; I'm sure they really are great hardware. But oh, the price! I don't remember the exact cost I heard for a mid-range server, but I do remember getting back to the office and running the numbers to find that 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 think the iSeries has a solid position of running legacy systems, and I could even understand the justification for buying newer, more powerful machines as those systems grow in size and scope. That seems perfectly reasonable. But for new development, I just don't get how that single expensive box is more cost-effective than a small group of decent x86 systems. Think of it as a RAIS (Redundant Array of Inexpensive Servers). I'd rather place my trust in a few good but affordable mirrored drives than one hyper-expensive bulletproof device. Well, same concept here.
From it-is-all-about-the-IO department (Score:4, Interesting)
--Scott
Re:Mainframes are not Magic (Score:3, Interesting)
This is taken from a website from Christopher Brown on operating systems (I didn't feel like typing it):
Object-based organization. Everything is an object, and only the relevant operations can be performed on them. You cannot 'open' a program object and 'read' it like a file, etc.
Capability-based addressing. System pointers are 128 bits wide, of which 96 bits are the address, and the remainder the authority. The hardware uses a tagged architecture to make it impossible to counterfeit a system pointer.
Single-level storage. Every object has a permanent, system-wide virtual address. From the OS's point of view, everything is always in memory, with disk pages to support it physically.
Abstract machine. Compilers for all object types target a high-level, registerless abstract machine, which does not change much from version to version. (In addition to executable code, program objects can contain a program 'template', which can be rendered into machine code on demand. Because of this, prgrams originally compiled for the 16-bit System/38 can be migrated to the newest 64-bit AS/400 without 'recompiling'; the program template is simply re-rendered as machine code when the OS detects that the executable out of date.)
Re:Still going strong... (Score:3, Interesting)
do you have lots and lots of things to learn
Are you trying to use CICS on the AS/400, I heard it was available but never seen it used?
Do tell more, I like a good laugh
Many years ago I did a CICS/COBOL to AS/400 COBOL conversion. The database came across real easy, almost no changes. The batch programs were pretty easy as well, All the JCL was re-written by hand. Reports were not to bad, once we convinced the grey beards to use PRTF with more than one format. Screens were a pig. We had to re-write most of them as they were used to serving multiple users from one program, whereas the 400 has one program per user. I cut my teeth on conversion pgms on that project, saved us a ton of time. Although, we burnt through two project leaders who tried to do everything manually before we got it through the third ones head.
Re:True, but.... (Score:3, Interesting)
IBM's hardware logistics is amazing. I've had many a part some hand delivered from Birmingham to Tupelo MS.
Long live Big Iron! (Score:2, Interesting)
We have two mainframe systems, IBM & Tandem (HP Non-Stop), as well as over 100 HP UNIX boxes. In general, the mainframes do the heavy lifting while the so-called 'distributed systems' handle storage, data warehousing & whatnot. There isn't a day that goes by without some kind of problem with the HP boxes. The UNIX tech services group is always running around putting out fires, while the IBM & (to a lesser degree) Tandem groups only have to deal with scheduled maintainence & upgrades & such. The running gag is to refer to them as Maytag repairmen since just like the commercials, they sit around waiting for something to go wrong.
Bottom line - a bunch of over-clocked PCs does not a mainframe make.
Comment removed (Score:2, Interesting)
Re:Some want to see the demise of the mainframe? (Score:1, Interesting)
Re:Mainframes are not Magic (Score:1, Interesting)
THAT's reliability.