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."
I do both mainframe programming and PC based programming and it's really far easier to maintain the mainframe stuff. It's also much more interesting. As a programmer perhaps the most telling thing I can say about the difference is that when your mainframe application dumps, you can actually analyze the dump and learn everything you need to know in most cases to fully diagnose the problem. PC programs on the other hand rely pretty much completely on recreating the abnormal situation in a debugging session in order to debug a problem. If you can't recreate the problem in your test case, you typically can't solve a problem. This pretty much insures that properly maintained mainframe programs will always be more reliable than PC based ones.
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.
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
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 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.
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-}