Linux on the Mainframe

Let us take a look at how the IBM team ported Linux to the mainframe and how the mainframe Linux distributions have developed.

IBM calls Linux on the mainframe "Linux for S/390" or "Linux for zSeries." Don't let the "for" confuse you. The Linux that IBM ported on the mainframe is the same Linux that is out there on the Internet. What the developers at IBM did was contribute a new architecture for inclusion in the Linux source tree the zSeries (and S/390) architecture. Linux for zSeries supports the 64-bit z/Architecture in both real mode and virtual mode on zSeries CPUs. Linux for S/390 supports the 31-bit S/390 architecture and will also run on zSeries in 31-bit mode. The Linux code maintainers did not need to modify the common code, nor did they have to change the Linux system structure. (See Figure 3-1.) The new architecture code was accepted into the Linux code tree and is now a standard part of the Linux kernel.^[10]

^[10] You can even see this code on your PC Linux. It is in the code tree that ships with all Linux distributions.

For the friends of the mainframe, let it be said that no changes were needed in the zSeries or S/390 architecture. No adaptation layer was required. The bottom line is that Linux runs on the mainframe architecture, period. The goal of the developers at IBM is to combine the strengths of Linux and the mainframe, not to reinvent a mainframe-specific Linux.

So how much code was added by IBM? The patches to the kernel that are needed to build Linux for the mainframe, at the time of writing, boil down to between 0.5% in the areas of glibc, gdb, gcc, and strace, up to 0.8% for the binutils, and about 2% in the Linux kernel. These were changes due to the system environment, the CPU architecture, and device support.

3.2.1 Porting Linux to the mainframe

Despite the fact that Linux is mostly developed on PCs and the majority of users run Linux on a PC, the design of Linux has been architecture-independent since its early days. Given the availability of a well-defined and well-documented hardware architecture, a working platform-specific compiler, and an operating system that has proven to be easily portable, what else do you need to bring it to the mainframe? Just a team of skilled programmers who were very enthusiastic about Open Source, Linux, and how this could fit on the mainframe!

Within a few weeks, the programmers could show that there were no technical obstacles that prevented the port of Linux to the mainframe architecture. From the start, it was clear that this had to be more than just a proof of technology. Therefore, the Linux kernel design was carefully studied and analyzed. Two objectives had to be met:

• The port had to become an official part of the Linux source. The platform-independent part of the Linux kernel must run unchanged on the zSeries architecture. The new code had to integrate seamlessly with the old, without impacting other architectures or violating the design and coding styles of Linux.

• The port had to run on the basic architecture definition of zSeries as documented in the Principles of Operation, the reference description. No emulation layer, or other "glue" code, could be used, nor could any extensions to the existing zSeries architecture be required.

  While an emulation layer approach typically helps avoid porting problems and thus leads to fast results, it comes with some major disadvantages. You typically have a performance degradation, and you have another layer of code that has to be maintained and synchronized with both the layer beneath (the architecture) and the layer above (the operating system). The Linux for zSeries programmers wanted to avoid using an emulation layer and meet the challenge of a technically clean solution. The "right thing to do" was to implement Linux on the pure architecture definition.

The work progressed rapidly, thanks to the clear separation between architecture-specific and architecture-independent parts in Linux. (The code for the former is placed in subdirectories for each architecture.) Because it is all Open Source code, it could be used as template and be adapted smoothly for the S/390 architecture. The majority of the architecture-dependent part for S/390 was written by developers at the IBM laboratory in Boeblingen, Germany, in 1998 and 1999.

Some special considerations went into the design of unique mainframe characteristics and how they relate to the Linux design. One example is the I/O channel subsystem of S/390 and the interrupt concept of Linux. Other presumed issues simply vanished. One example was the assumption that S/390 computes EBCDIC data only. Few people realize this, but the S/390 architecture is actually code-page neutral. Thus Linux works as a pure ASCII operating system on the mainframe.

3.2.2 Spreading the word the Linux install fest

The first set of patches from IBM that enabled Linux to run on a mainframe were released to the Open Source world in December 1999. In 2000, the first commercial Linux for S/390 distribution (from SuSE) based on these patches became available.

To bring the mainframe and the Linux worlds together, and to increase the number of installations, IBM sponsored an installation party with the potential administrators of Linux on the mainframe. It was called an "install fest" because it was run from Germany. (You may have heard of the October Fest in Munich.)

There was no way that customers could bring in their heavyweight mainframes and disk subsystems over long distances to the location of the install fest as they would for a Linux user group PC install fest. The install fest had to be run remotely and without impact on the parts of the system that were running production work.

Materials were sent to participants in advance planning guides, installation documentation, Linux distributions for the mainframe and also for desktop systems to help participants become familiar with Linux. The actual installation took place during conference calls with four to seven participants who were ready to install Linux on their mainframes. For some of them, this was their first contact with Linux. The phone calls were staged by time zone, as several continents were involved North and South America, Europe, and Asia.

The idea worked well. There was a great overall satisfaction with the ease of the process, the quality of help, and the speed of the installation. A lot of people expected an installation of a mainframe operating system to be a tedious task, given their prior experience with traditional mainframe operating systems. Installing Linux during a three-hour phone conference was a new experience.

Many customers overcame the initial hurdle of dealing with a new operating system on their mainframes. Furthermore, some mainframe experts showed their Linux system to Linux experts who had never dealt with the mainframe platform before, but were familiar with Linux on the PC and UNIX worlds. To a great degree, experts from both sides could talk about the same thing despite their different backgrounds. These technical contacts created synergy by getting the various technical people together and having them learn from each other.

Table 3-1 shows the rapid development of Linux on the mainframe.