Slashdot Mirror
Why The Dinosaurs Won't Die
DaveAtFraud writes "Ace's Hardware has a nice introductory article to the animal that will not die: The Mainframe. Ever wonder why these things are still around and what makes them different from a PC or UNIX box? The article is IBM-centric so there's no discussion of say the CDC Cyber series but when most people don't even believe that mainframes exist anymore, what the hay, let's disabuse them of that notion first. Hopefully, the author will follow up with the additional promised articles that go into more technical detail but this is a good place to start. I wonder if they still make card readers, too?" This guide came out last month, but it's worth looking through, even just for the pictures.
They must coordinate? Completely?
Are you sure?
I seem to be thinking of an identification technique involving numbers. IIRC, it was highly distributed. Each client in the system was given a 32 bit numerical representation which was used as an "address" to communicated with the other clients. These "addresses" could be assigned dynamically by various agents who were authorized to destribute a subset and report which client had which address.
The whole layout was mainly hierarchical, and completely unsynchronized.
In case you haven't caught on yet, I'm talking about the IP protocol. Its a demonstration that handing out numbers can easily be done in a distributed way.
Of course some transactions need to be sequential, like the ones you mentioned. That's why we have semaphores, and why individual records aren't usually distributed! This is basic database design, and there are plenty of good ways of doing it which DON'T require a huge amount of I/O.
Theres a good bit of Computer Science theory on the subject, and there has been for about twenty years. Many professional databases designed today can work in a distributed manner and almost all of them are capable of scaling.
Mod me down and I will become more powerful than you can possibly imagine!
I think you missed one of the main points of the article. Mainframes are _IO_ machines, not compute engines. Mainframes are designed to deal with enormous streams of data, not huge numbers of calculations.
Clusters like google can give you enormous compute capability, and a form of redundancy, but they can't give you the type of error checking and correction done in the mainframes, like the self-checks done by the paired CPUs. (At least not practically.)
A couple of years ago I read an article that pointed out that todays desktop PCs have equal or greated CPU power than a 1970s mainframe. But when you measured IO capability, the mainframe would still wipe the floor with the PC.
Theres little wonder in that. Look at all the IO channels and processors that the mainframe has. Instead of moving every byte between peripherials with the CPU, the mainframe tells one of its IO processors: "Move that data for me, and tell me when its done."
A typical task for a mainframe might be (every night): Read the financial records of my 10 million customers with their average of 3 accounts, 8 mutual funds, etc. Inactivate closed accounts. Activate new accounts. Put in all of the deposits from cash, checks, wire transfers, refunds, etc. Subtract the withdrawls from cash, checks, wire transfers, refunds, etc. Update the number of shares in the accounts. Now apply interest to every account. Find and report all accounts that are: overdrawn, below minimal balance, over limit. Apply penalties. You get the picture. Even if you could do this with a cluster, all that you've done is move the point where the massive IO occurs from the mainframe to a huge, expensive, database cluster to service all of the IO. (It won't be on MySQL either.) Might be simpler than a mainframe. Proabably not.
Google uses the large number of systems for more than redundancy. It uses them for caching its database in ram. They figure that the extra speed from ram caching reduces the total number of systems that they need. So, perversely enough, they have a lot of machines to save them from having even more machines.
I'm happy letting google/SETI/Folding/etc.. search, crack, whatever.
I want a mainframe handling my bank account and mutual funds.
Currently the TSN is assigned through a cluster-wide 'semaphore' maintained by the distributed lock manager. However, one system at any time has the responsibility for logging the transactions (although the job can 'fail-over' to any other system. The design of the system means that every state change must be written out of the system so that if an individual system dies, the others can continue from the same point with no loss of information permitted unless a major disaster occurs.
Oh and you can forget databases as they tend to be rather slow. Recovery unit journalled ISAM files was the only way fast enough.
There may be a lot of CompSci Theory on this subject but there is very little that is relevant when you want a highly reliable system with several thousand transactions per minute.
Oh and this particular system is running the trading at CBOT, EUREX and XETRA.
For the benefit of /.ers:
CBOT = Chicago Board of Trade. Futures and options trading, mainly on commodities (corn, wheat, etc) and equities.
XETRA = European electronic securities trading system.
EUREX = Largest European equity derivatives exchange.
These are places where downtime can easily be measured in millions of USD per hour. The London Stock Exchange has had only one unplanned outage in the last decade. That's the kind of reliability these systems require, and it ain't easy to achieve. So, when you do, you tend to leave well enough alone...
The April 1998 Byte cover story has a graphic Why PCs Crash, and Mainframes Don't. It's interesting to see how little has changed in almost 5 years.
Best Slashdot Co
And the funny thing is that the average failure time per CPU is 30 years. That means if you start today, you will run each instruction twice (once in each pipeline) and in 2032 you can expect your CPU to fail to the alternate.
Umm... ancient? Ancient? ANCIENT?!?
AS/400 has been fully 64 bit for 6 years. AS/400's database has had working cost-based optimization forever (something oracle still struggles with). AS/400 has had mainframe-like LPAR before the mainframe had it. AS/400 can scale to 24 CPUs and so much RAM and disk it would make your head swim. It's got dedicated I/O processors for handling disk and in many cases can out-benchmark a mainframe in sheer I/O capability. It's got a native java runtime that maintains native executables without destroying the bytecode.
You are uninformed. Your AS/400s sitting right beneath your nose are the most advanced servers in your company hands down. Legacy certainly has power, but AS/400 is not ancient any more than stonehenge is new.