Hercules mainframe emulator

Installation Steps

Installation of CentOS on the mainframe can be done across the wire. Because mainframes and Hercules do not support CD drives, it is necessary to export the mounted DVD via NFS or copy the content of the DVD to an exported directory. Typing ipl /cdrom/generic.ins boots the system at the Hercules console.

Going forward, you should see normal Linux boot messages flash across your screen. Launching the network configuration program, which prompts you for the information required to set up a connection, comes next. Listing 4 shows the messages and responses. Note that the Hercules console passes commands that start with a dot through to the running system.

After completing this phase, the message shown in line 32 will appear. Now you can establish an SSH connection to the guest address, which takes you to the CentOS standard installation tool, Anaconda. After changing a few settings and mounting the installation source via NFS, everything should fall into place. Because the virtual network connection is not very fast, you can expect the system to be busy configuring itself for the next hour or so.

With a real mainframe, on which you can opt between HMC (hardware management console) and bootable tapes or prepare a volume for zLinux z/OS-side, this process looks very different.

Listing 4

Installation of zLinux: First Phase


After the Installation

The ipl command will boot an installed system on Hercules. As a parameter, Hercules expects the boot volume address (ipl 0a01, in my example). After IPL, a grub-style boot menu appears, although the system automatically will boot after waiting 15 seconds. The console shows typical startup messages for a (Red Hat) Linux system up until the login prompt. Working directly at the console is impractical because it means typing a dot in front of every command and because some programs will not run at the console. The use of an SSH connection from a different machine makes more sense.

The Mainframe Principle

Although Linux still relies on various schedulers to ensure fair and optimum resource usage, the mainframe world has gone its own way. On a mainframe, users specify the resources they need, which enables the system to decide whether the program should run now, later, or not at all. Listing 5, a classic copying program, looks fairly complicated compared with the cp command, but complexity has both disadvantages and advantages.

Jobs on a mainframe are not much more than a stack of punch cards shifted to a file. The job printed here starts with a job card that specifies the memory, run time, and job class, which makes it fairly easy to prioritize. Next comes the copying program, IEBGENER, and its parameters. Host programs use logical filenames to access files; for IEBGENER, these names – defined by DD (data definition) cards – are SYSUT1 and SYSUT2.

SYSUT1 (line 5), the input file, is designated as "OLD" – which means that you need the file exclusively. If another job is processing this file, your job will have to wait. An alternative to this is DISP=SHR, which allows shared (read) access (and might be a more realistic alternative for a copying program).

Note the specification of the target file in lines 6-9. (NEW,CATLG) stipulates that the file must not exist and that it should be cataloged after successful processing. If the file exists, the job will not run. The other details specify the space requirements (primary 5 cylinder, additionally up to 15 times 2 cylinders) and the physical file format. On Linux, a rogue program can completely fill up the filesystem; on a mainframe, the program is stopped if it oversteps its space assignment.

Optimization entails additional effort. In the past, when mainframes were much smaller, this kind of safeguard was more important, whereas today's mainframes include options that simplify the process. The goal of maximizing use has not changed. Utilization values of 90 percent for 24x7 operations are possible, and they make financial sense.

The protocol that mainframe terminals use to communicate with the host provides another example of maximum resource utilization. Physical terminals no longer exist; programs such as x3270 emulate the protocol. In contrast to Unix keyboard drivers, which process every single key press, the user of a 3270 terminal fills out all the fields on the screen and then transmits everything at once. This reduces the number of processing steps, at the cost of making programs such as Vi or Emacs impossible to run.

Listing 5

Copying a File with IEBGENER


Dynamically Adding Disks

In principle, zLinux is no different from Linux on any other platform, except for the way it handles hardware. The following example mounts another disk in /home on the system, but first you must generate the new disk (file dasd/home.dasd). Hercules emulates a high-availability system; the administrator does not shut down zLinux but does use the Hercules console to introduce the new device:

attach 0a03 3390 dasd/home.dasd

On the zLinux page, typing lsdasd -s -a shows a list of available DASD devices; you can see that a new device is available, but offline. Whereas a mainframe operator would now type vary online, root would do this:

echo 1 > /sys/bus/ccw/drivers/dasd-eckd/0.0.0a03/online

A quick check with lsdasd and a peek at the /dev directory show that a dasdc now exists.

Now you need to low-level format and partition the device: dasdfmt handles the first of these tasks, and fdasd handles the second:

dasdfmt -p -v -l HOME01 -b 4096 -d cdl -f /dev/dasdc
fdasd -a /dev/dasdc
mke2fs -j /dev/dasdc
mount /dev/dasdc /home

If you are setting up multiple partitions, you need to call fdasd without the -a parameter, which takes you to an fdisk-style partitioning menu.

In the example, you will be using the whole volume as a large partition; however, the new device is lost on rebooting. To prevent this, you need to add a line for the device to the Hercules configuration file and add a mount entry in /etc/fstab.

The dasd_mod kernel module expects the available devices as a start option; a change to /etc/modprobe.conf takes care of this:

options dasd_mod dasd=0a01-0a03

To start the system, you need a new Initrd. If you want to be on the safe side, you might want to copy the existing Initrd and add an entry to the boot menu in /etc/zipl.conf, to be able to launch the previous version in case of an error:

cd /boot
mv initrd-2.6.9-55.EL.img initrd-2.6.9-55.EL.img.orig
mkinitrd -v initrd-2.6.9-55.EL.img 2.6.9-55.EL
vi /etc/zipl.conf
# -> Modify to load the original initrd
zipl -V

This procedure is something like the legacy Linux bootloader, lilo, in which you needed to launch the lilo program after modifying the configuration file.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More