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.
Nobody in their right mind is going to mess with them until they absolutely can't get strung along anymore, because they know that crashing, say, a HMO's appointment handling system would be what we call a "career limiting" move.
If it ain't broke, don't fix it. If it ain't broke and it's mission critical to the tune of millions of dollars an hour, avoid it like someone carrying the plague, ebola, leprosy, herpes and a bad hangnail.
Every year during my review, I just pray the words "slashdot.org" aren't mentioned.
Imagine...
:)
You're a big organisation thats been in business for 50+ years. You are in the biz of manufacturing Weezops (or whatever) for the various Gazaah(wtf?!) industries.
10-20 years ago you paid a big buttload of cash for a mainframe.
Today this main frame is chugging away. Occasionaly you need to screw in the vaccum tube, or maybe fill up the cooling liquid and in winter its a little noisy.
However, your little dino is happily chugging away, calculating whatever you want it and doing whatever it was that you got it for.
Its working. Its doing that you paid big cash for. You dont need it to make coffe, play videos, particpate in distributed.net or send spam. You want it to chug along. And its doign it.
Why change? Why pay another buttload of cash because someone is telling you "whoa, what you got here? an oversized heater?! pay another buttload of cash for this new machine that will do everything its doing PLUS play mp3s for you, make coffe, crack encryptions, search for ufos and connect your grandma to the net!"
I dont think so.
If a machine, no matter how old, is working, and you paid a lot of cash for it, no business will get rid of it to get something new just because its new/flashy.
Just like banks and credit card companies who still use systems like GlobeStar, 8 colors text based account management software written over 10 years ago. Why? because it does the job. Pull down menus, icons, angry slad shooting out of cdrom drives, live video straming, its all nice and cute, but if you have somethign that works, does the job the way you want it and how you want it, there's no need to change.
Sorry its so drawn out and long, but thats the way i see it. Plus I am sure you enjoyed the sleep
In words of a famous comedian, "Those are my ideals, if you dont like them, I have others"
In my experience, this stuff hasn't changes significantly in years -- it's tweaked now and then, but it basically works and as such isn't messed with.
What you have to remember is that entities who are still using mainframes are both (a) very large and (b) very well established. The mainframes tend to be involved with really important tasks that are mission critical (and I mean "mission critical" in a very real sense, not in the 1999 out-webserver-is-down way), like flight reservation systems or bank account tracking systems.
What I'm trying to say is that it's a really bad idea to mess with these systems unless you really have to -- anyone with a couple years at a suitably large company could tell you that there's nothing to be gained and everything to be lost by messing with them. The hardware and support costs are laughible if you compare them with what just a few minutes of downtime from buggy new software would cause.
Every year during my review, I just pray the words "slashdot.org" aren't mentioned.
I'm sure the humblest x86 can now run rings around old PDP 11 and IBM 360 systems, but it's still amazing how fast some parts of those old machines were, including core memory swap disks.
A feeling of having made the same mistake before: Deja Foobar
Google is unique in that it doesn't really matter whether the latest data is in its cache or not, or even if they lose it or not. It could take a hit, even lose all of the data that it crawled through yesterday, yet still have an operational site (I know I wouldn't be able to tell the difference, could you?)
You don't want your bank using the same unreliable hardware. Do you want to wait a week while the maintenance guy comes along to replace the failed node that held the records of your last deposit?
Mainframes are built for customers who simply can't take downtime or data loss. Some businesses can, many can't. If you build a bank off this idea, let me know. I'll be sure to stay away.
/ \
\ / ASCII ribbon campaign for peace
x
/ \
The terminal interface is the most efficent human interface designed to date for data entry. I have never seen a GUI app that can come close to the user efficency of the ole mainframe terminal interfaces. That combined with the scalability, reliablity and ease of maintenence will insure that the mainframe will be around for yet a very long time.
Got Code?
So you need to tag every transaction with a unique sequence number. This is really, really difficult when you don't have a single system with an amazing I/O throughput to assign those numbers.
A Google type solution uses a lot of execution units each with limited I/O capability. Queries may be parallelised without much interaction. In my example, every transaction must be synchronised. It doesn't matter if the application is spread over a cluster, the nodes must still coordinate to assign the sequnce number.
I agree though with your point about adding better cluster management though to open source operating systems. However, this is much more difficult than improvements to a standalone system because how many people can afford to run a cluster of say 4 or more systems for playing around.
The argument for what I call economic inertia is a good one, especially with corporate shareholders these days demanding that management squeeze everything they can out of every dollar and stretch every last penny as far as it will go.
A mainframe that does everything that you need it to do (and more) and works well with your company processes is worth far more to you than the investment of time and resources in an untested, unknown system that may or may not work. Remember that new systems don't go online until after extensive use and testing in parallel with the current one (if it's done correctly). That means duplication of efforts and resources.
Anyone who has worked at a company that builds enterprise-scale applications or mission-critical solutions knows that when the customer has an XYZ mainframe, you'd better have applications that support XYZ or you'll find the contract goes to your competitor who does. It's not an option not to support it.
Unless there is a strong business case for moving to a newer technology, mainframes will be with us for quite a long time.
A hint to the coders out there: the number of people who know and understand these systems is declining. There's a mint to be made if you can deliver services to support them.
The main feature of mainframes are the staggering amounts of data it can move. The mainframe is like the bulldozer of the Computer world. The CPU is terribly slow at certain operations - run X11 on it, and have 20 people log in - say bye bye to your performance. But the amounts of data it can move, and the speed with which it can move that data is nothing short of amazing. Oh, and let's see you doing processor lock-stepping on a PC-based cluster.
I can't believe you got modded up to +5 for this drivel....
People who think they know everything are a great annoyance to those of us who do.
First, let me say you are being misled.
MIPS doesn't stand for million instructions per second. It stands for Meaningless Indicator of Processor Speed. IBM never liked publishing benchmarks for mainframes because they don't say the whole story.
Mainframes don't run one application. They run thousands at the same time. I/O requests, CPU, and device contention are just a few of the many factors in a machine's speed. Just look at your PC. If you get the fastest dual Pentium, that just tells CPU spped. Put a slow hard drive and a 2MB video card, and any PC will seem faster. Mainframes are the same way so IBM has always been reluctant to publish numbers because businesses scream.
As for the software being buggy you are exactly right. The difference is that some of that software has had 20-30 years to work out the bugs.
And finally, yes, you are correct in saying that computationally demanding tasks using floating point multiplication and division don't perform well on the mainframe. Most businesses don't need to compute PI, so it was never a priority to IBM. Floating point addition & subtraction are very very fast if you write your application correctly.
The really sad thing that holds processor speed back on the mainframes is the software licenses. On a mainframe, the faster the machine, the more your software costs. This made it possible for smaller companies to buy a little mainframe. The big customers pay the most. This means you never buy a bigger machine than you need, because the software license costs get more expensive and no business wasts money.
And how much I/O can your PC do? Or a cluster of PCs? Nowhere even close to what mainframes can handle... 24 GB/s -- take 96 Gigabit ethernet cards, stick them all in your PC (oh... you can't...), and then blast them at absolute maximum theoretical bandwidth.
Of course, if you want to be "realistic" you'll have to use 128 Gb ethernet interfaces, since the maximum realized bandwidth on a full duplex circuit is around 1.5 Gbps.
Oh... what's that? Your bus can't even handle the full bandwidth of a single Gigabit ethernet interface? Well, then I suppose your I/O is going to royally suck in comparison.
Oh, and let's not even get on the topic of reliability... PCs just aren't. I'm a PC guy (I shudder at the thought of having to deal with mainframes), but I know their limitations. And while you're dead wrong about travel reservation systems running on PC clusters (they don't - the entire backend system is still on mainframes), whoop de doo if it was run on PCs. This isn't something where a node going down would cause major problems.
If a node goes down on the air traffic control system, however, you can damn well bet there's problems. Big ones. Weighing several hundred tons, moving at a few hundred miles an hour, and disinclined to stay aloft while you take a few hours to get the system back up.
maybe live with a little data incoherency
Yes... a little data incoherency is no big deal. I'm sure the power grid will work just fine with a "little" incoherency. You don't mind a power plant (be it coal, nuke, whatever) having a massive cascade failure every couple years, right?
I have absolutely no desire to ever work on mainframes -- the software in place is largely old and crufty, but by god it works. The hardware isn't old crap either -- you can buy new machines that will run the old software perfectly. And have capabilities that us PC weenies can't even comprehend. You realize that virtually every advance in the PC industry was tested and proven in the mainframe world first, right?