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.
any new article on mainframes would necessarily be ibm-centric because ibm is the only mainframe manufacturer left on the planet. all the others have dropped out.
legacy apps are not the reason mainframes hang around. legacy apps last because of the incredible ease of centralized management on mainframes.
gone are the days of the dumb mainframe terminal, also. modern mainframe of today offer advanced graphics and windowed desktops. more often than not, the modern mainframe terminal is a low end pc with attached host print emulation.
increased miniaturization only makes for better mainframes. modern mainframes are just well put together microprocessor clusters.
mainframes make killer webservers: cheaper, faster, more reliable, smaller footprint, and easier to maintain than huge farms of pc servers.
please.
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.
The etymology of mainframe is incorrect in the article. While nowadays "mainframe" is indeed used to distinguish big lumps of computers from smaller ones, back in the day the "box" or "chassis" of even a microcomputer was originally called the "mainframe".
I have documentary evidence from the dawn of microcomputing to prove it. It was the Main Frame of the computer, to which one attached Peripherals. Microcomputers just had very small Main Frames.
If anything could be said in detriment to mainframes, it could only be at the hardware level (like hotswapping CPUs, and IO devices), but Sun machines can already do that sort of stuff...
You say already like that's a good thing, but IBM had the capability decades ago and Sun are only really just catching up.
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...
Database design theory comes to mind.
The goal is to pick fields & tables such that:
1) Locking is minimal
2) Dependencies are minimal
3) Storage size is minimal
4) Records are meaningful
The main technique involves decomposing a database to a minimal architecture based upon all possible elements in the database, and then building it back from the basis to the desired state.
It gives you specific knowledge of the conditions by which transactions may require waiting and a way to characterize that waiting, as well as how to reduce the number of transactions you need for a given task.
Of course, that's just the database design theory that one can apply. There's also the distributed information theories that can be applied. The most primitive approach to this is to use time stamp semaphores, but it can be extended beyond that. There is actually an area of database dependency resolution devoted to making locks. I imagine the "distributed lock manager" you spoke of uses it to minimize the amount of information needed to be locked at any given node.
In both of these cases (distributed info theory and database design theory), the formalism sprang from necessity - people invented creative ways to improve how their mainframe worked, and they used the formalism to describe it. I think it might even be right to say that without using the CompSci theory, you probably won't get a terribly reliable system. You'll get a kludge - it'll work, if you're lucky.
Mod me down and I will become more powerful than you can possibly imagine!
By now every travel reservation system is ditching mainframes as fast as they possibly can and replacing them with racks of PCs or medium-end Unix workstations. By spending 1/50th as much money they get orders of magnitude more useful computation: those nice low-fare-searches you see on Orbitz and Expedia run on PCs, not mainframes. I've been in all the other travel reservation systems complexes since my 1998 visit and more and more you find little stacks of cheap "low end" machines doing the heavy lifting.
This is simply not true. I work at a company that uses 390 mainframes and TPF
to handle travel reservations for airlines. When you use Obitz or Expedia you are using a pretty front end that gets all of its data from the mainframe.
There have been some systems that offload stuff from the mainframe. Notably, Orbitz stores fares because it can apply its own search algorithms and find fares for more esoteric travel iterneraries than can be done on the mainframe and it can do fare searches faster and cheaper. Where does Orbitz get their fare data? From the mainframe where it is still generated and updated. Orbitz simply caches that data and updates their cache on a regular basis. From everything I've seen there have been more new applications and sub-systems hooked to the mainframe for data than have been moved off the mainframe.
Although there are several IBM mainframe operating systems, the MVS line is frequently considered the most feature-rich.o s390/
http://www-1.ibm.com/servers/s390/
I also have a minor quible with other posters that have said or implied that there are a shops running 10 - 20 year old mainframe hardware. Generally speaking, IBM places limits on the period of time a given release of their operating systems are supported. From time to time IBM decrees that the new operating systems will only run on newer hardware. So if you want to run a currently supported operating system, you end up running newer hardware. IBM is in the process of doing just such a thing with the migration to the 64-bit processors, which in MVS's case means you need to be running z/OS (the latest incarnation of MVS) to exploit 64-bit features.
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.
I agree. This dinosaur can still be bought and delivered brand new...
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.
Sure. You know how that works? You get an email in the morning over your nasty Folgers and a nice Shipley's donut that a processor has cratered. You already know this because in the time it took the email to work through your neat, cool Exchange server with pretty pictures for the monkeys who call themselves NT admins, you were paged by the system and then by the IBM CE, you got in early to meet him, you varied off the processor, drained the module, added the new one, topped off the distilled water, varied it on to check the microcode, and the varied it on for processing. And the mainframe kept running like nothing had happened. You really don't care if it happends twice a week -- there is never an outage.
I think the best analogy is if PC's are cars, and UNIX servers are semi-trucks, then mainframes are 747's. If you're just tooling around town, or even going cross country, then your favorite auto will work. If you want to (have to?) do more useful things without all the idiot-proofing, then UNIX is the way. But if you're doing something industrial, then the mainframe is the way to go. But the user interface is, well, like flying a 747. And it's not the most efficient way to run to the store for a gallon of milk.
Disclaimer: I work for IBM (I wrote this on my company-issued ThinkPad). I use mainframes everyday, but spend most of my time using p690's running AIX--a web front end to processing that will continue to execute on the four clustered mainframes.
That is so true. At my bank, they have a cheesy windows based account management system. Last time I opened an account, the employee spent about 30 minutes trying to make the system accept that I wanted an account. Something always snagged, stupid little things. Then she went to the basement to use the 3270, 5 minutes later I had an account. It probably took her 3 minutes to type my name considering her typing skills.
I've also done data entry on a well designed windows NT system. Such a thing exist. It basically boils down to consistent interface. That and the system was intelligent about where the focus for keyboard was at every point. You could tell that the whole interface was built (by UNISYS) to conform perfectly to the work flow. F-keys used to set the values of drop-downs. The same F-Key would also move from the number entry field to its drop-down menu automagically. All in all, mostly similar to my 3270 data entry experience.
Quibble: IBM mainframes have not been water-cooled for several product generations. Last one I worked on was in '91. They're all air-cooled now.
:)
Other than that, you're generally on target.
If all you have is a hammer, everything looks like a nail.