Why OldTech Keeps Kicking

Hugh Pickens writes "In 1991 Stewart Alsop, the editor of InfoWorld, predicted that the last mainframe computer would be unplugged by 1996. Just last month, IBM introduced the latest version of its mainframe, and technologies from the golden age of big-box computing continue to be vital components in modern infrastructure. The New York Times explores why old technology is still around, using radio and the mainframe as perfect examples. 'The mainframe is the classic survivor technology, and it owes its longevity to sound business decisions. I.B.M. overhauled the insides of the mainframe, using low-cost microprocessors as the computing engine. The company invested and updated the mainframe software, so that banks, corporations and government agencies could still rely on the mainframe as the rock-solid reliable and secure computer for vital transactions and data, while allowing it to take on new chores like running Web-based programs.'"

Is it really "old" tech?

I.B.M. overhauled the insides of the mainframe

Uh, did they replace the insides with something old, or something new? Duuhhh.

Re:Is it really "old" tech?

It might be new tech, but the mainframe is still an old concept.

...Duuhhh?

Re:Is it really "old" tech?

As is the radio. I'll never understand why people think Television should have killed off the radio. Radio is still around for one major reason: It's hard (and usually illegal) to watch TV while driving. If anything is going to kill radio, it's the advent of the podcast, which in a lot of ways is close enough to the function of radio to be a real threat.

Re:Is it really "old" tech?

As is the radio. I'll never understand why people think Television should have killed off the radio.

A better analogy would be to see mainframes as movie theaters, and PCs as televisions.

Re:Is it really "old" tech?

I think the point is that the idea of the mainframe is old, and many of the naysayers predicted that once smaller computers became affordable, they would replace the centralized mainframe model.

Re:Is it really "old" tech?

So shouldn't the article be about how poor our prediction skills are rather than about how we cling to old tech? In the mainframes case, we cling to it because the concept was updated and still represents the most economically efficient solution to the problem.

The article may as well be asking "Why do personal automobiles keep kicking?". Because they work, and they solve they still solve the problems that they are meant to solve. And when a new problem crops up, (fuel prices/pollution) the solution isn't to get rid of the car, it is to redesign it to address the new concerns; just like IBM and other companies did with mainframes.

Re:Is it really "old" tech?

No. They used something borrowed, and something blue.

Re:Is it really "old" tech?

Isn't that the motto of IBM's business model?

Re:Is it really "old" tech?

It's an old idea, but there is nothing especially wrong with the idea itself...A stable, powerful computer with a rock solid operating system, supported by the sort of technical support only an old school provider like HP, IBM, or Sun can provide.

If you deal with money, it doesn't seem like a bad idea at all. I mean, keep your financials database on a Windows system? Are you nuts? Keep your finances in MySQL, running on Linux? I don't think so. Oracle on Linux, maybe, but what about the hardware? Going to buy yourself a nice Dell? (pause for laughter)

Buying a sexy mainframe with real hardware support, the kind where they send out a guy who knows what he's doing, 3 minutes after you call, and he's got the new part installed in an hour and a half or your money back...That stuff is priceless if you really really need your system to be reliable. I can definitely see why they're still around.

When Something Goes Wrong...

I love this "single point of failure" argument. It's a fallacy. The only single point of failure with a single mainframe is the building it physically sits in. A single mainframe is internally redundant in every possible respect you can think of (and several you didn't think of). It is that cluster you talk about fondly, except there's no (error-prone) self-assembly and no particular management burden required. It. Just. Works.

But if you're concerned about a building failure -- fire, flood, whatever -- you can buy a second machine. IBM will sell that second machine to you at a lower price. You can put the second machine in a second building, you can run fiber (preferably with two separate physical paths) between the two machines, keep them many tens of kilometers apart, and run them as a single, seamless cluster (called a Geographically Dispersed Parallel Sysplex). And, as a programmer, you have absolutely zero coding responsibility to make that all work. If anything bad happens all your transactions instantly flip over to the other site, in-flight, real-time. And you don't lose a single byte or a single customer, and you can prove you didn't. You can also service any element of that cluster -- any element, from software to hardware to network to whatever -- without any interruption in business service. Yes, you can upgrade your database engine version while everybody's credit cards keep working. Neat party trick, that, but it's business-as-usual for mainframes.

Scalable? Each machine contains up to 64 main processors (and a minimum of two spares!) running at 4.4 GHz with more cache (and more cache levels, including copious shared cache) than anything else. (Even the clock speed argument is gone. It's a faster clock speed than X86.) Plus scores of secondary processors -- the main processors only do real work, not encryption or I/O. They don't even handle clustering -- there are dedicated processors for that. You can stuff 1.5 TB of RAM in each frame. And you can have a single cluster -- which behaves like a single logical machine from a programmer's point of view -- containing up to 32 of these machines. That's a single "machine" with 2048 main processors and hundreds (thousands?) of assist processors. Beyond that you can still do everything an Intel cluster can, like conventional load-balancing (e.g. HTTP spraying) across multiple 2048-CPU clusters. But no one has yet invented a core banking system, for example, that exceeds even a couple of these 64-way machines for a large Chinese bank, to give you some perspective.

No, this stuff is in a different league. Please read up on it sometime before dismissing it offhand. I don't dismiss the value of X86 blades for certain applications, but this mainframe stuff is very different and has important roles. Telecom switching, maybe maybe not. Telecom billing, you bet.

Re:Is it really "old" tech?

Having just done an upgrade to our accounting software this morning, and going through a number of small but still very real headaches, I can appreciate why the guys managing a major bank's information systems is damned glad that IBM does things the way they do.

That's precisely why the mainframe still exists. When 5-nines uptime still isn't good enough, you don't adopt a radically different system just for the sake of change or progress. When billions of dollars rest on the absolute reliability of your computer infrastructure, migration and change are to be approached with the utmost caution, and anything that reduces complexity and presents a smaller degree of change is a godsend.

Why OldTech Keeps Kicking?

Because the people who are used to that tech haven't kicked (the bucket).
Basic psychology. People stick with what they're used to, even if it doesn't always make the most sense.

can be argued for other things too

Look at the inability of people to drive using joysticks, instead sticking to the classic wheel arrangement. I've seen drive by wire setups using joysticks, they work well, but people just can't get into them.

Re:can be argued for other things too

People have this idea in their heads that things with electricity can break while things without electricity can't.

Its not that things with electricity break while things without electricity don't, its that things with software break while things without software don't. Software, because of its discrete nature, is inherently harder to judge safe. A bridge rated for 10,000 pounds will easily carry 1000, but a piece of software that works with input 10,000 cannot automatically be guaranteed to work with input 1000. Any "drive by wire" system will need software (at least for the motor controllers that transform the steering wheel input into steering motion), and therefore consumers are understandably leery of it.

The other consideration is tactile feedback. A mechanical steering system provides lots of tactile feedback, since you're directly connected to the steering system via a mechanical linkage. Therefore, if there's something wrong you're liable to feel it (i.e. the car pulls to one side, or becomes difficult to steer), allowing you to detect problems before they become catastrophic. Without that mechanical linkage, you're dependent on the software designers to judge how much feedback the system provides. If there's a problem that the designers haven't anticipated, the system will not warn you, and small anomalies will grow to catastrophic proportions simply because the warning signs were filtered out from the driver's perception.

Worse yet, the two problems are interrelated. Increasing the amount of tactile feedback increases the amount of software needed, since you've got two output devices (steering wheel for tactile feedback, and steering mechanism for actual steering) and you need code to modulate output to both of them. This necessarily increases code complexity, making the job of making sure the code is bug-free even more difficult.

Finally, for those who are going to make an analogy with fighter jets' fly-by-wire systems, I must remind you that an aircraft has far more room to maneuver. And, even then, there were problems with the early fly-by-wire systems. The F-14, for example, had some serious issues with the flight control systems becoming confused and adjusting the wings inappropriately, leading to stalling and loss of control. These issues were eventually worked out, but the process took years. This is OK for a highly specialized system where your operators are specially selected and highly trained, but it is definitely not appropriate for any consumer grade system.

LOAD"$",8:LIST

I DON'T SEE WHAT THE BIG PROBLEM IS. I
HAVE BEEN POSTING FROM MY COMMODORE 64 F
OR TWENTY YEARS NOW AND IT IS WORKING JU
ST FINE FOR ME!


The damned lameness filter has just managed to destroy my joke. Thanks a lot, filter.

because it works!

The New York Times explores why old technology is still around

simple, because it still works. Using radio as an example, it works just fine for what we need it for and we really haven't found a suitable replacement [light based communication for example] same for mainframes, there are niches that still must be filled with "older" technologies until we find something that makes the older tech not worth using.

10 years ago, in Byte

Why PCs Crash, and Mainframes Don't [byte.com]

When a PC crashes, even the system administrator might not hear about it, much less the vendors who made the system, the OS, and the application software. The user shrugs, reboots, and keeps right on working. When a mainframe crashes, however, it's a major catastrophe. It's General Motors calling up IBM to demand answers.

Ten years gone, and still relevant.

Damn I miss Byte.

Old Technologies that are still kicking...

The x86 architecture

The QWERTY keyboard

SATA (yes, folks, a serial version of the old IBM AT bus!)

Drive letters, DOS devices

Does anyone actually use the tar program for its original purpose anymore?

From the Fine Article

"mainframe sales are a tiny fraction of the personal computer market"

I'm pretty sure that mainframe sales are 0% of the personal computer market.

Irony

Does noone else see the irony in a newspaper exploring the reasoning behind "old" technology being used in modern environments?

Mainframes... going out of style?!

With a "Bill Gates" 640k view of the world, of course we wouldn't need mainframe computers. Desktops now have more than enough power to run even the largest server applications of 1991 hands down and it's easy to see where that statement came from.

The problem with the vision is that Stewart Alsop didn't take into account the growing complexity of computer programs. We have plenty of (in comparison to the software of 1991) inefficient applications that require ridiculous amounts of computer power to serve and process everything we need done. We have complex server applications like gigantic databases and games and video servers that couldn't exist in the 1991 world.

The mainframe of yesteryear may now fit into the physical space of today's desktop... or smaller, but that doesn't mean there won't be a need for a bigger and faster one to take its place. That's as true now as it was then.

Had this discussion...

I was at a conference and at a BOF where I raised this question and technology. One person said that at the end of the day Microsoft will be replaced by Google apps.

I said, yeah sure Microsoft will be replaced like IBM and the mainframe will be replaced. He then went on and explained to me on how the mainframe is dead. I looked at him and laughed because there are still oodles of people using the mainframe and there will be oodles of people using Microsoft.

It is not that Google apps will replace, but will complement Microsoft, like the mainframe compliments Microsoft. Where the real understanding begins is when you know what to use when...

no built in obsolescence

I used to make CD players for one of the tech giants, as such I was in China alot. When I say "make" I'll be more specific - I wrote the firmware.

I remember vividly a conversation with one of the chinese project managers. I was discussing the build quality of a new CD player for the US markets. It had that brown cardboard like PCB that the racks leap off if you wave a soldering iron in the general vicinity. The PCBS, the unit front, the enfire casework was glued together with a hot glue gun. The radio tuning circuit was wire wrapped around a pencil and then "frozen" in place with dripped wax whilst the software was expected to adapt to mask any tolerance issues. The manager and his team gave it a projected life span of 18 months, then the consumer would be back to buy another, he was really enthusiastic about the repeat business.

*That* is why old tech survives because it was built to last, not with built in obsolescence. And no, I never brought a CD player from my employer ever again.

NY Times misses boat again

Gawker.com regularly makes fun of how the New York Times approaches a question the reporter knows little about and comes away with a convoluted answer. The article asks "Why Old Technologies Are Still Kicking". The best answer they come up with is "there must be some enduring advantage in the old technology that is not entirely supplanted by the new". There is an enduring advantage, although they don't go into what it is, and put it in a misleading way actually. It's cheap. Some of these companies have been putting business logic and programs into these systems since the 1950s. The cost of moving them from 370 to 390 to zSeries is minimal, as is replacing parts that break down etc. And it works. Sometimes better than modern machines - some of these machines have uptime of decades. High availability is not a new concept for them.

What would be the cost of hiring on top of the existing mainframe admins and developers a team to migrate this stuff to Windows or UNIX? Remember some of this code is written by people who not only have left the company but may have died. Then you have to hire new developers and administrators for the UNIX/Windows systems. Change always creates the potential for problems, so expect a higher percentage of disruptions to the business as you're doling out all this money. If IBM is making it easy for you to keep what you have going, and also allows Linux, web etc. capability, why spend all that money to transition? The answer is that a lot of times companies don't. I worked at a Fortune 100 company that still had plenty of IBM mainframes. They even had a lot of their printing handled by the mainframes, although there were Windows and UNIX gateways into the print queue.

Mainframe engineering is better.

Mainframes are still around because the engineering is better.

There's no secret about how to do this. It wouldn't even add much cost to servers to do it right. Here's what's needed.

• All the hardware must self-check. CPUs need checking hardware. Mainframe CPUs have had this since the Univac I. All memory, including the memory in peripherals, needs to have parity, if not ECC. Connections to peripherals must have checking. All faults must be logged and automatically analyzed. CPU designers are wondering what to do with all those extra transistors. That's what.
• Peripherals have to go through an MMU to get to memory; they can't write in the wrong place. IBM mainframes have done this since 1970. The PC world is still using a DMA architecture from the PDP-11 era, and it's time to upgrade.
• The OS has to be a microkernel, and it can't change much. The amount of trusted code must be minimized. IBM's VM has been stable for decades now, even though the applications have changed drastically. The QNX kernel changes little from year to year; Internet support, from IP up through Firefox, was added without kernel changes. This is incompatible with Microsoft's business model, and the UNIX/Linux crowd doesn't get it. So we're stuck there.
• Additional hardware support for debugging is helpful. Unisys mainframes at one time had hardware which logged the last 64 branches, and on a crash, that was dumped.
• All crash dumps are analyzed, at least by a program. Why did it fail? Someone has to find out and fix it. We need tools that take in crash dumps from server farms and try to classify them, so that similar ones are grouped together, prioritized, and sent to the correct maintenance programmer.

Once you have all that fault isolation, you know which component broke. This produces ongoing pressure for better components. It empowers customers to be effective hardasses about components breaking. With proper fault isolation and logging, you know what broke, you know when it broke, you know if others like it broke, and you probably know why it broke. So you know exactly which vendor needs the clue stick applied. There's none of this "reinstall the operating system and maybe it will go away" crap.