Mainframes commonly are regarded as being reliable, but also big, complicated, pricey, and outmoded in today's IT landscapes. Here, the Hercules mainframe editor, which emulates the CPU architecture, can help. Even if Linux is running in a production environment on a mainframe, Hercules still can provide a useful service for testing and development.

In this article, I will describe how to set up and configure Hercules and its virtual hardware, and then I will focus on installing zLinux on Hercules. Finally, I'll take a quick look at z/OS – the native mainframe operating system – and its freely available predecessor MVS.

Download and Installation

Hercules 3.04 does not support current zLinux variants, which is why you should download the current source code for version 3.05 [1]. The RPM, also available from the homepage, will install but does not support network connections, making it unsuitable for the purposes of this article.

In a directory of your choice (e.g., /usr/local/src), unpack the sources, change to the /usr/local/src/hercules-3.05 directory, and enter configure as shown in Listing 1. After doing so, don't forget to check config.log, paying particular attention to whether Zlib support is available. If the zlib-devel package is not installed on SUSE, you will still be able to build and use Hercules, but you will not be able to use the typical Zlib compressed virtual hard disks.

After completing the configuration phase, follow the normal make and su -c "make install" procedure. Now Hercules is installed, but some manual finishing work is necessary. The HTML-formatted documentation is available in /usr/local/share/hercules, with links to additional resources on the Internet; if you run into difficulty, try the mailing list.

If you will be using TCP/IP networking with a Hercules guest system, it is important to configure the host system correctly. First, you need to modify the privileges for the /usr/local/bin/hercifc script, which configures the Tun/Tap network device when Hercules starts up. Just as for any direct device access, you need root privileges for this. The --enable-setuid-hercifc configure option (see Listing 1, line 9) sets the SUID bit, but the installation script sets group ownership for the file to root, making it impossible to execute the script as a non-privileged user. The following lines will set the permissions correctly:

# chgrp users /usr/local/bin/hercifc
# chmod 4750 /usr/local/bin/hercifc

The following sections only apply to openSUSE systems; some details will vary for other operating systems. For the network connection, Hercules uses the Tun/Tap device; on a normal system, the device is owned by root:root and has permissions of 0600. Again, this rules out access by normal users. However, changing the permissions manually will not do you much good because the original status is restored when you reboot.

Udev is used for device management on today's systems, which is why you will need to modify the corresponding Udev rule. On an openSUSE system, the /etc/udev/rules.d/50-udev-default.rules file controls this, and you must add:

KERNEL=="tun", GROUP="users", NAME="net/%k",MODE="0660"

To give /dev/net/tun the right permissions, type rm /dev/net/tun and modprobe tun. If the device still has incorrect permissions after a reboot, don't worry. At system launch time, /etc/init.d/boot.udev copies a number of devices from /lib/udev/devices to /dev, so you will need to delete the Tun device in this directory or modify its permissions:

chgrp users /lib/udev/devices/net/tun
chmod 660 /lib/udev/devices/net/tun

Network Preparation

The Tun/Tap device supports a point-to-point connection between the host and the guest, which other virtualization solutions call host-only networking. If you want to grant the guest system access to the local network – or even the Internet – you also will need to set up NAT. To do so, first enable IP forwarding, either permanently in /etc/sysconfig/sysctl (IP_FORWARD=yes) or manually:

echo "1" > /proc/sys/net/ipv4/ip_forward

Then use iptables to define two rules:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i tun0 -j ACCEPT

This completes preparation of the host system. Next comes creating and configuring the virtual hardware.

Virtual Hardware

Hercules supports a whole bunch of virtual hardware components, but you just need some hard disks and a network connection for zLinux. Because this is a high-end server system, video, audio, and USB support are irrelevant. Although Hercules supports emulated printers, there are no Linux drivers for the old, line-oriented 1403 printer (Figure 1). However, this is not a major drawback; you can print over the network to the host's CUPS server or to any other print server available on the network.

The virtual hardware is defined in a configuration file (Listing 2), which is passed in to the emulator with the -f option when it's launched. Hercules does not impose any restrictions with respect to the name and directory structure. Depending on your personal preferences, you can store all your files in a single directory or organize them in subdirectories by file type.

Virtual hard disks are normal files, as with any other emulator. In IBM speak, hard disks are referred to as DASDs (for direct-access storage devices). To create hard disks for your zLinux installation, enter:

dasdinit -z -lfs dasd/sys1.dasd 3390-3 SYS1
dasdinit -z -lfs dasd/sys2.dasd 3390-3 SYS2

The -z option configures Zlib compression. Alternatively, you could select -bz2 for Bzip2 compression; note that the method is slower, and thus means performance hits without giving you major disk space savings. The -lfs option refers to large file support; that is, dasdinit will not split up the hard disk into 2GB chunks. Depending on your DASD size, you might want to omit this option so you can store files on DVD media.

The file names (dasd/sys?.dasd) are arbitrary. The hard disk type (3390-3) defines the size, which is about 2.7GB in my example. The Hercules documentation gives you a list of available types and their respective sizes [2].

The last parameter for dasdinit, the VOLSER name (the disk label), really is not necessary for Linux, but the installation writes the label anyway. As a final step, the administrator needs to add the disks to the Hercules configuration file (Listing 2, lines 29-30), thereby assigning the device addresses for Linux to reference the disks.