By now, I hope you're convinced that mainframes and Linux have a great future together. Even if you don't have access to an IBM mainframe, you have to admit this is one groovy hack! Now let's take a further look into how it works and some of the things yet to be done.

The first thing you should know about the mainframe port of Linux is that there are two of them. The original port was done by Linas Vepstas, with help from others, and was called "Bigfoot." This port has never really reached usable status because IBM has now announced their own port, called Linux for S/390, which has basically stolen the show. The IBM port came from IBM's labs in Germany, and from what I understand it started out as a Skunk Works project there.

There's a bit of a controversy between the two camps, and some folks are not too happy that IBM chose to work independently and in secret rather than joining the existing porting effort. To IBM's credit, however, they have open sourced their patches to the stock kernel and the gcc except for the device driver for their "OSA" network adapter hardware, whose internal circuitry is still considered a trade secret.

From a technical standpoint, the Bigfoot port is able to run on older IBM hardware, whereas Linux for S/390 only runs on the newer generations. Bigfoot is also a more "pure" open-source initiative, having been an open-source project from its inception, whereas Linux for S/390 was developed internally by IBM and then published (with source code) afterward. IBM seems to have stated an intent that Linux for S/390 be an open-source project, but it is my understanding that they need to execute some legal releases before it can become part of the stock kernel. Since the IBM port is the one receiving most or all of the active development work today, and since it is the only one I have personally used, this article focuses primarily on that version. I respect Linas Vepstas' work very much, though, and if anyone is interested in volunteering to help continue that port I would certainly encourage you to do so.

Setup is, to put it mildly, not exactly plug and play yet. Part of the problem is that you need a mainframe geek to get the disks allocated and the image booted, but you need a Linux geek to finish configuring it from there. Unless you are lucky enough to have one person who knows both areas, a team approach is probably best.

There are prebuilt binary images of a basic, bootable filesystem and an initial RAMdisk on the Marist College web site (see the links on the left side of this page for the URLs). The process of booting is different depending on whether you are running under the VM operating system, under a logical partition (LPAR) on a physical processor, or running on the bare metal. The Marist College site has instructions for all three.

Once the basic system is running, there is a large tarball containing the rest of the /usr directory tree and some other things you'll need. After that, configuration is just about the same as configuring from a bare-bones build of other distributions. The ways in which Linux for S/390 is very standard were simply amazing to me, given how hugely different this hardware environment is from Intel-compatible platforms. One of the coolest features, to me at least, is that it runs natively with the ASCII character set instead of the EBCDIC codes that are normally used on IBM mainframes.

Installing most open-source software turns out to be relatively easy. Just ./configure, make, and make install as usual. There are a few programs that have trouble with the version of gcc that is included. The assembler has trouble handling certain kinds of link references and structures, requiring patches or turning off compiler optimizations. Quite a lot of code, including Apache 1.3.9, seems to compile and run just fine, however. Intel-based binary RPMs obviously won't work, nor will commercial products (such as StarOffice and WordPerfect) that don't include source code.

A good deal of work still remains. There are some issues about how to map VM's virtual device addresses (VADDRs, as they are called) to Linux major and minor node numbers. In VM, the I/O address assigned to a given virtual device is configured in software, not in hardware. How do you make sure that they are assigned to the same device special file each time the Linux system is booted? Also, VM can have more of these VADDRs than Linux allows as minor node numbers, so the mapping is not 1:1 transparent. There was a very interesting thread about this online, and it appears that most of Linux can support more nodes but there was concern about breaking legacy code.

As for X11 applications, I understand that someone has GNOME up and running on Linux for S/390. KDE probably won't be far behind. That should give you some idea of the potential of this project.

Next: Networking Outside--and Inside--the Box »