Impressive as they are, these demonstrations are really nothing more than lab curiosities unless they accomplish something useful in the real world. Why would you want to run Linux on a mainframe, especially if you are a manager or businessperson?

For starters, how about user productivity? Quite a few companies have staff who use UNIX or Linux for CAD, databases, scientific computing, and so on. Why train all these people to use another command shell or menu system on the mainframe, if you can give them a UNIX-like environment there for free? And since it's user-by-user selectable, you don't have to force-march all the mainframe-trained staff to the Linux world, either.

What if your company bases most of its enterprise applications on mainframes but you need some selectively-deployed Linux to meet specific needs, such as a DNS server or firewall? Simply run it on Linux within a logical partition or virtual machine. The VM environment is where this really pays off, because there is literally zero cost for hardware.

In the world of Certain Other Operating Systems (which shall remain nameless) it is fairly common to dedicate an entire PC server to a single application or even to a single tier of a complex client/server application. Part of this is blamed on overhead in the operating system, but some of the problem is due to limitations of the PC architecture and its limited I/O systems. No matter how much technology improves, I will always be able to do more with 20 cubic meters of space than with 2. So a mainframe can handle many times the concurrent user load of a PC server, and this is unlikely to change. If you need Linux as a server, therefore, it makes sense to consider mainframe hardware as a place to host it if you really need to push some bits.

To me, though, the most interesting possibility for Linux under VM is a combination of the second and third points above. In addition to performance and load balancing, multitiered applications are often split across several machines simply for functional partitioning. This makes it easier, for example, to upgrade the SQL database back end without worrying about it breaking the client interface. With Linux on an S/390 running VM, you could run one virtual Linux as a front-end firewall, to protect against intruders. A second virtual Linux would run Apache and would be the client interface. Server-side components, such as Java Servlets, would receive XML-based content from the back end and format it to the needs of each client. A third virtual Linux could hold the JavaBeans or CORBA components that create the XML from database-driven raw content, and which provide the business logic. Finally, the native VM environment itself supplies a fine platform for a DB2 or Oracle database to hold the data. The administration of all this would be nicely partitioned among multiple virtual machines, but there would only be one physical hardware environment to manage and maintain.

Running Linux under VM has some administrative advantages, too. For instance, software distribution and backups are greatly simplified. Resources, such as real memory and MIPS, can be portioned out on an extremely dynamic basis, depending on the needs of each Linux guest at any given time. Those LPARs that were mentioned previously are incredibly versatile, much more so than separate machines would be unless you were willing to move hardware around day after day.

Finally, here's a possible application from out on the fringes. Suppose you are a Web-hosting provider and you want to give your clients as much flexibility as you can without jeopardizing your own systems' security. Instead of buying a huge farm of PCs, you buy one S/390 mainframe with lots of RAM and the VM operating system. Now each client company gets their own virtual Linux machine with full root privileges. They can start and stop their Web servers, upgrade software, test new code, or whatever, without risk to your infrastructure. In fact, since the Linux virtual disks are visible as raw data (not as a filesystem) to the native VM environment, you can even recreate their default root filesystems from a canned image in seconds, should a new Web programmer really make a mess of things. A large-scale Web-hosting company could easily cost justify the price of a mainframe in terms of administrative costs, site upkeep (one mainframe is a good deal smaller than 1,000 PCs, even if they are mounted in racks), and disaster recovery support. The ability to add a new client in minutes, rather than hours or days, would be quite a marketing advantage in today's fast-paced Web.

Remember, too, that the price of hardware is only one factor in the total cost of operation of a system. Serious, large-scale applications will have disaster recovery plans, onsite and/or offsite "hot" spares, and top-notch (read: expensive) service contracts with the manufacturer. If your company already owns a mainframe, you are already paying for these things. Why add more PC hardware and then duplicate all this effort and expense for that, too?

Of course, you don't have any of these options with NT or Windows 2000, because they don't run on S/390 and probably never will. But that's another story.

Next: The Devil's in the Details »