It turns out that, with the "PR/SM" feature mentioned previously, the S/390 hardware can actually divide itself into units called Logical Partitions, or LPARs. Say you've got an eight-way S/390 machine. You want to bring up a test environment for a new version of the operating system, to be sure it's compatible before you commit to migrating thousands of applications. You can dedicate two of those eight CPUs, for example, to make a test machine that runs completely separately from the production machine except for sharing power connections. The processors don't even have to be allocated in whole units; you can prioritize and share them quite flexibly, depending on the hardware configuration. Say you have a hardware failure (rare, but they do happen) in one CPU. The failed CPU will generally be switched out and the others continue to run without interruption. Maybe you have a business that needs some applications on VM and some on OS/390. You can run both of these on the same physical hardware, at the same time. As a matter of fact, you could either use LPARs or just run OS/390 as a "guest" under VM, depending on your needs. This old "dinosaur" is looking pretty adaptable these days.

At the beginning of this article, I listed the words expensive, cumbersome, proprietary, and obsolete and said they don't describe big iron any more. Let's take a look at these, in order.

Expensive is a relative term, depending on what you are trying to do. I'm not sure where the starting price is for an S/390, but by the time you get a fully-configured system with disks, backup media, VM software, service and support, and a secured room to house it, you're definitely talking seven figures. That's a lot more than a five-thousand-dollar PC server from Compaq or Dell, but price isn't the same as cost. It is not at all unusual for one mainframe to support five thousand interactive users, or more. That's simultaneously-connected clients, not just login IDs. Take two million dollars (enough to buy a beast of a machine, I'm told) and divide it by five thousand users, and the cost of $400 per user doesn't look so bad any more. Add to that the fact that there is a big difference in the quality and reliability of the hardware itself. A good PC server may only have one hardware failure every thousand days. But if you have 100 of them, you will have a failure somewhere every few days. A mainframe builder can afford to spend more money on MIL-SPEC temperature ratings, higher-quality circuit boards, careful cooling design, better cable construction, and top-grade connectors. You get what you pay for.

There are also some low-end options in the mainframe world these days, including used equipment, smaller System/390 boxes, and even a single-board 390 CPU that plugs into a PCI slot. There is also competition from third-party hardware vendors such as Amdahl.

Cumbersome is probably a fair description of some of the really old software in the mainframe world. There are still FORTRAN programs from the 1970s running production systems today, and literally billions of lines of COBOL code still crunching along. Yet there are new tools on the mainframe coexisting right alongside the old ones. IBM supplies Java runtime and development environments as standard with their mainframes now. A wide variety of other languages and tools, including C and C++ compilers, are available from IBM and from third-party software companies. COBOL isn't the same old language from the punch-card days, either. Extensions have allowed it to keep pace with modern object-oriented languages and graphical user interfaces. COBOL may not be the most intuitive language for beginners, but neither are C++ and awk from the Linux environment. Yet all of these are popular because they do what they were designed to do, and they do it well. Why change?

One of the reasons that those "cumbersome" old programs are still around is that mainframe programmers--like UNIX programmers--are unwilling to throw away something that works and works well. Advocates of Windows often point to Linux and decry it as nothing but a clone of thirty-year-old engineering from UNIX. Most Linux users would point out that this is intentional and that UNIX has hung around for thirty years because it works and because its design has adapted to changing needs. We in the Linux community point to Windows as an operating system that is so immature its developers have to rewrite all their code every couple of years. The mainframe takes the same philosophy as Linux--if it ain't broke, don't fix it. The two environments have in common the fact that they place function and reliability well ahead of form and glitz.

For years, IBM was criticized (rightly, in my opinion) for their mainframes being proprietary systems. If you wanted to transfer a file between a mainframe and anything else, it took a costly adapter card and special software in the other system because the mainframe couldn't support TCP/IP. All that has changed, now. IBM has caught the open systems fever in a big way, and their mainframe systems now play nicely with the other children. Both VM and OS/390 operating systems now support TCP/IP over high-speed Ethernet and Token Ring, and they have a raft of TCP/IP utilities (FTP, telnet, and so on) built in. DB2, IBM's industrial-strength relational database, can be accessed using ODBC protocols over TCP/IP. There are several web servers available for OS/390 and VM as well, and in fact IBM is now fully supporting use of Apache on their mainframes.

The long and short of it is that, used in large-scale applications, mainframes are cost-effective, flexible, and more open than ever before. As companies move from internal client/server applications serving thousands of users to external web sites serving millions, the mainframe of today may in fact be the best damned web server you ever saw. Obsolete? No way--they're just hitting their stride.

Next: But It's Still Not Linux! »