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.
...with the rotational energy of Douglas Adam's coffin. That was the most painful and continuous referencing-HHGTG-for-referencing's-sake I've read in a long time.
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"
the reason they won't yet die is that they are incredibly reliable. If you need a computer that has to work all the time you need a mainframe. Now, the software isn't the funnest thing to work with and you don't get pretty graphics (for the most part) but nothing can compare to its rock solid reliability. Another reason is that the hardware itself runs forever. Most of the older stuff still running was built to last. Unlike alot of today's hardware that is only built to last until it's obsolete.
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?
By the way, what happened to Jon Katz?
He probably got tired of posting the only original stories on slashdot, only to be rewarded with "STFU Jon" and other such bitchiness. I thought he had some interesting points, even if his opinions were usually different from mine.
And in response to your impending queries: No, I am not Jon Katz. I'm just posting anonymously because I know my opinion here doesn't match everyone else's exactly and I'd rather not take the karma hit. Oh, yeah, and I'm wandering off topic too.
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.
You mean like X11? Yes, XFree86 is fully supported on Linux for S/390. If you truly want a GUI on your server..
Now why on earth would you constrain it to work over HTTP? The design requirements of a "decent GUI" are very different from the design goals of HTTP. Or are you one of those inexplicable people who believe "tunneling over HTTP" == "web-enabled" == "good"?
HTTP was never intended for low latency. It was never intended for persistence. It was never intended for asynchronous server->client updates. (Or even client->server updates.) All of these are necessary for a decent GUI protocol. Some of them have been shoehorned into HTTP as time marches on, but I don't, in general, see the point.
Note, though, that the GUI front-end doesn't have to run on the mainframe. Indeed there are quite a few good reasons to run the front-end on a front-end server instead - or even deploy direct to the end-user. This basic architectural principle is called the "client-server model", and it works pretty well.
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
I keep hearing this, and it keeps making no sense.
If the application deployment guy and the firewall guy can't agree on whether to open the firewall port, the company has bigger problems. Somebody needs to be in charge.
In summary, using HTTP for the sole purpose of defeating firewalls is an arms race between two branches of IT. Now, arms races between competitors is what capitalism is all about ... but arms races within a company are pointless. You're supposed to be on the same team here! Instead you set up a situation where the app developers and the firewall admins both have to use increasingly sophisticated measures to do their jobs.
And don't give me that "but the firewall guy doesn't know how / can't be bothered to open up ports when we ask for them". That's his job. If nobody at the company has the time or skill to operate a firewall, you may as well not even have one.
I have to conclude that the real purpose of this whole fad of overloading HTTP with things that have nothing to do with HTTP is for deploy unauthorised applications - things the company doesn't know about and hasn't approved.
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
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.
I just got laid off from an operator position at a large, old company that has invested a lot of time and money into their IBM AS/400's. Not exactly mainframes, but it's the same idea. They have been there forever, they're doing their job, etc. No problems with the machines at all. The only problem is that the developers are nearly all in their 60's and will probably retire soon. And most of this generation (and probably the last one) don't even want to look at anything in COBOL, RPG, CL, or whatever the system's applications are developed with, much less make it a career. Eventually these things will die because nobody will know what to do with them. In 10 years it will be damn near impossible to find people who will work with anything that isn't GUI-based. Chris
... when the applications designs are flawed, turgid chunks of garbage that poorly attempt to mimic a bizarre corporate organizational structure that is changing next week.
Hardware design always has been (and probably always will be) WAY out in front of software design, and yet people are all too willing to spend the odd extra million on hardware while putting as little effort into software as possible.
In most companies they are clutching obsolete applications like life preservers, when in reality they are anchors.
Mainframes aren't going away because they are actually cheaper to run. And regardless of what some posters have said, don't have vacume tubes. What thay do have is dynamic CPUs, HUGE I/O buses, Optical data connections, massive storage, etc....
/wo pretty graphics).
While some companies have poured cash down the drain in order to use the latest buzzword technology, smart companies use mainframes with COBOL/CICS/DB2. Train your people once and only once.
What do webservers provide over this combination aside from pretty graphics? Not much. HTML based apps are the rich mans CICS. Granted, it isn't a glamorous career, but it is a VERY effective technology that is rock solid. Programmers that do PC work can't imagine working on the Mainframe. But it is very efficient.
The tech world has come full circle. Client server was hot for awhile, but very hard to keep the clients up to date in a large organization and requires bandwidth of the GODS to transfer all the data around. Oh, lets go to web services. Okay. Now we are back to the mainframe model. The centralized server model is basically this (Webservers) = (Mainfraim
--Scott 8-}
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.
There is also the issue of the aging of the pool of experienced mainframers. Training (for example) an IBM systems programmer isn't something done at the drop of a hat. It takes time and someone with the experience and knowledge to do the job well, and a fair number of these people will be retiring someday soon.
Fortunately, IBM is pretty good at maintaining backwards compatibility so skills learned on older versions of IBM's mainframe operating systems generally transfer pretty well to the newer versions. Fortunately for someone wishing to dip a toe into the IBM mainframe world there are (apparently) public domain versions of older IBM mainframe operating systems available. I use the weasel "apparently" because I'm not aware that IBM has officially declared these versions to be in the public domain, but they are devoid of copyright statements and unlicensed.
Now here's the beauty part: a group of retro-computing enthusiasts has resurrected these old public domain IBM mainframe operating systems and run them under the Hercules mainframe emulator under Linux, Windows and a few other platforms. Public domain versions of MVS, DOS/VS, and VM are available from the late 1970s/early 1980s. A turnkey MVS system from this era is available, which gives you a running MVS system capable of doing some fairly useful work. Many people have contributed their efforts to providing various MVS tools, and the historical archives at CBT tape have proven a real treasure-trove of goodies just waiting to be rediscovered. Most of the CBT tape offerings include source code, providing a tremendous learning opportunity.
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?
Given 1,000 virtual Linux images running on a single mainframe LPAR using VM:
- how many virtual power supplies are going to need to be replaced?
- how many square feet of real estate are going to be used up by their virtual racks?
- how many miles of virtual cable and/or fiber are going to be laid underneath the clean room floor?
- how much does an idle virtual server cost to operate during off-peak hours? (OK, it's a trick question. When you can dial up new images on-demand, you need never run more virtual servers than are absolutely required.)
- when capacity planning finally admits their estimates were 20% below actual usage, how much will it cost (in both time and money) to dial up another 20 virtual servers to meet the workload?
- how many virtual servers will receive an automatic 'upgrade' when the host box gets a performance boost?
It's funny how people say "Linux is great for legacy hardware" when talking about their $500 486sx, but not for a $500k s370.
- Despite popular opinion, I am not perfect.
A cluster of PC's isn't even in the same league as a mainframe. PC operating systems aren't designed for that type of thing. Anyone stupid enough to try this is probably also stupid enough to try using Microsoft Cluster Services. And anyone who has seen Microsoft Cluster Services in action knows that it only protects you from hardware failure --- if Windows fails (and we all know that Windows is far less reliable than the hardware it runs on), you get two parallel blue screens. (Don't mod this up as 'Funny' -- I'm dead serious here.)
Linux is reliable but most of the clustering software we have available for Linux is geared more towards parallelizing an application and getting more work done with more machines, than towards N+1 reliability. You need to be able to have processes maintain their state in parallel on multiple machines -- not an easy thing to do.
Tired of FB/Google censorship? Visit UNCENSORED!
And note that IBM called the system managers, not the other way around. The hardware notified IBM that maintenance was needed.
...phil
"For a list of the ways which technology has failed to improve our quality of life, press 3."
A friend of the family works for IBM and was telling me recently about one of these beauties running 75,000 virtual machines. These virtual machines can be set up in virtual networks behind virtual firewalls. Do you need a development version of the current production network? Duplicate the configuration, no new hardware required. This guy was telling me that each developer had his own private copy of the system to screw around in. The power of this just makes me drool.
Beowulf might be good for science, because to get the power of 75,000 CPUs you actually need 75,000 CPUs, but for commercial applications that mainly want to move data a mainframe is the way to go.
Pardon my pessimism, but that is not reliability.
So Google can remove broken units and replace them later. But what happens to the work that was happening on that unit when it broke? Someones query gets lost, and they have to submit it again. No loss in googles case.
On the other hand, a Bank could not allow even one transaction to be lost to such a failure. In the mainframe discussion they talked about how even a running program, even an individual instruction, on a failed unit could be saved, moved and restarted on another unit. You can't do that on a PC.
A web server can be parallelized easily, but database servers are not so lucky. Sure, Oracle, DB2 and others can be run on multiple machines in parallel, but if one of the units goes down, so does its disks. Disk failover is not as seemless as the Mainframe Channel failover.
True seemless failover, down to the instruction, is something that takes a lot of effort. And there are some places where it is vitally important. Web servers are just not that vital.
There is nothing so silly as other peoples traditions, and nothing so sacred as our own.
The point being missed is that apps which are this critical are being used in the first place. Everything for a company should not rely on one program or system not going down. If company systems were more tolerant to faults, it wouldn't make sense to run with mainframes. This is the problem with computer systems, and will always be. Paperwork is slow, but paper never crashes.
In most companies they are clutching obsolete applications like life preservers, when in reality they are anchors.
God knows you're right! When I worked at very-large-retailer-to-be-unnamed in the IT department I was floored by how much crappy software they had built on top of their hardware. I can't remember how many times I thought, "Why not just use CVS?" or "Why do we have to use this thing?"
First, if you replace something that's working, even if it's working extremely ineffeciently, it might break. The perception of something breaking is about one trillion times worse to the PHBs and the execs than the perception of something working extremely ineffeciently, especially in a retail management mindset.
Second, especially if you have legions of data-entry people trained to use the extremely ineffecient software, then the cost to replace and retrain is higher in the short-term than to stay with the extremely inefficient system. PHBs and execs, especially in a retail mindset, can't thing about long-term cost savings in IT becuase IT is already a "cost center," not a "profit center."
In short, two reasons for bone-headed software in the enterprise: perception and cost. Mainly perception.
I don't make the rules. I just make fun of them.
Recently we added the ability for the students to pay their bills online via the web, taking a bold step into 1998, albeit four years late. In fact, we mainly only did it because another university in this state (the bigger one) did it, and we didn't want to look like we were behind. The software to do this literally just adds more layers to the mainframe process. That was easier than moving to a new system. While the seasoned web pro got to use ASP.NET and C#, I'm sitting here at the age of 25 writing COBOL from scratch to be able to post transactions he captures. That the process is disconnected and difficult to keep in sync no one seems to mind.
They say that we're getting a new, web-based system, "in about six months". I'm still not sure if this means no more mainframe, but apparently the project has been six months away for about two years now.
My coworkers fall into three categories - people younger than me who are still in school and are getting the heck out of here when they graduate, people my age who are married (like me) but they have kids and are completely stuck here, and people who are much older than me. One of my coworkers is literally a grandmother who codes COBOL and hates computers.
And that's really the big problem. I'm sure COBOL and Natural (a pseudo-scripting language for the ADABAS databases we use) are fine languages but you'd never know it by the way they're used here. I recieved no training once I got here - I was literally thrown in with a vague premise of further training, only to have the promiser go on to a better job. I was able to swim and get promoted within fifteen months.
People here aren't concerned with keeping their skillset up to date, they're more concerned with getting their kids to little league practice. The guy across the room from me is trying like hell to get a better job, but he's 56, divorced, in hellacious debt, he knows one thing (COBOL), and he steadfastly refuses to learn anything else. He's like the guy with a hammer who sees everything as a nail. He regularly gets turned down for jobs he's perfect for in favor of young, know nothing punks (like me).
A few months back (for some reason) they gave us VB.net training. While everyone in the room looked terrified of object oriented programming, I was making shit dance across the screen and rewriting everything in C# for kicks. That we're a 80% conservative university that's terrified of change doesn't help things either. My coworkers are mostly more concerned with keeping the new stuff out so that they don't have to learn anything new before they retire.
Now, I'm not saying that Mainframes are evil or that people's natural desire to stay the same is dragging anything down, but part of the reason Mainframes are still around is due to a complete reluctance to upgrade. Sure, at some point it will become inevitable, but most of my co-workers are ready and willing to put that off until after they retire.
And I'm not saying that everything should always be re-written in "flavor of the month" language to run on "hardware platform of the moment", that's not practical either. I mainly think we're seeing the results of a generation and a mentality that started at the low end of the Moore's Law curve and attacked it like any other job. People here don't see programming as a passion, but that thing they do until they go home (not unlike people who sell radio air time or something trivial like that).
As for me, I'm getting out of here as soon as I can.
Schnapple
I stumbled across Sun's Mainframe rehosting the other day and thought it was interesting. Runs CICS programs on SPARC/Solaris, and seems like it's pretty real.
Sure, may not do everything a mainframe can, but could be an interesting way to transition to open platforms.
So does Anonymous Coward have good karma?
This troll need no answering but I cannot resist pointing out the obvious.... 1.Tree filesystem - why the catalog is fast, reliable and recoverable. Just because you have a hard time understanding IDCAMS does not make the file system bad. 2. fast interaction shell - ISPF is plenty fast, faster than my windows gui. 3. TCP/IP able kernel(and not TCPIP started task - TCPIP is a service used by many subsystems, and in the subsystems the TCPIP function is a kernel level(CICS TCPIPdomain) and it works as fine as any other TCPIP installation on other platforms. 4. scripts - REXX, CLIST and now even PERL, 5. clean integration between the various components - Cross memory services, very, very, very fast and easy to use. one more thing, I will not trust my banking on you're cheap linux box. I have my own thank you and still, I bank at the bank with the BigBlue Badass Mainframe.
UNIX is unsuitable for this platform. It does an excellent job of using the hardware available, memory especially. Mainframe memory is hugely expensive, why waste it by having n copies of the same page in the buffer caches of n instances of Linux?
Bizarre idea...
The company that I work for has a massive data center in the Phoenix area. Over 100,000 square feet of space to accommodate thousands of Unix and Windows machines, as well as our mainframe systems. The building houses only 125 of the hundreds of employees involved with the support of the machines; the rest of the workers are in another building a few blocks a way. Several miles away, we have a redundant data center -- same size and same number of machines -- sitting idle with only a few employees working there (mostly security guards).
Consider for a moment the huge facilities cost of cooling 200,000 square feet of raised floor during the summer months in Arizona. Or the cost of electricity for thousands of servers. And don't forget the cost of general maintenance of such large buildings. Sounds expensive, doesn't it? Might be a pretty massive cost savings if we could eliminate a significant number of those Unix and Windows machines and move to a data center a quarter the size.
Even if we ignore the facilities, there is money to save elsewhere, by looking at the actual usage patterns of our hardware. Every night, the mainframes sling terabytes of data in massive batch jobs. But during the day they mostly sit idle. The Windows and Unix boxes show the exact opposite usage: busy days, idle nights. Why use the mainframe for Linux stuff? Why the hell not! Who cares how much it cost up front, that's a sunk cost. Which is more expensive and inefficient: use the hardware for Linux emulation; or let it sit idle throughout the day?
The number of enterprise Linux applications is miniscule in comparison to those on available on Solaris, HP-UX and AIX, so you're likely to be developing them in-house - why bother, if you're spending that sort of cash on the hardware, I sure you can afford some decent software?
For a small 50 - 100 person company this may be the case. But look at a company like Merrill-Lynch: tens of thousands of employees with an annual IT budget that is measured in hundreds of millions of dollars. And they have embraced Linux.
When a vendor walks in the door at M-L, looking at a $15 million a year licensing deal, they listen to the customer's needs. And if the customer wants the product to run on Linux, then you can bet your ass they will make it happen. Vendors that don't offer a Linux version are fast becoming the exception.
The welfare of the people has always been the alibi of tyrants. - Albert Camus
The most important thing about mainframes isn't their intrinstic stablity - its their ability to run the same app written in 1964, now, and get the same results faster and better, without uptime issues.
Every line of code written costs money, and provides another chance for a bug, if it works don't monkey with it. The longer a block of code can just sit and work, the better. If the same code can do its job for 20 or 30 years that is just wonderful.