Hercules mainframe emulator
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.
Installation of zLinux: First Phase
001 Which kind of network device do you intend to use: 002 .ctc 003 Enter the bus ID and the device number of your CCW devices. 004 CTC/ESCON and LCS need two subchannels: 005 (e.g. "0.0.0600,0.0.0601" will configure the CTC or ESCON interface 006 with the subchannels 0x600 and 0x601) 007 QETH needs three subchannels p.e. 0.0.0300,0.0.0301,0.0.0302 008 .0.0.0cc0,0.0.0cc1 009 Enter the FQDN of your new Linux guest (e.g. s390.redhat.com): 010 .emu-guest.bablokb-local.de 011 Enter the IP address of your new Linux guest: 012 .192.168.2.2 013 Enter the network address of the new Linux guest: 014 .192.168.2.0 015 Enter the IP of your CTC / ESCON / IUCV point-to-point partner: 016 .192.168.2.1 017 Select which protocol should be used for the CTC interface 018 0 for compatibility with p.e. VM TCP service machine (default) 019 1 for enhanced package checking for Linux peers 020 3 for compatibility with OS/390 or z/OS peers 021 .0 022 Enter your DNS server(s), separated by colons (:): 023 .10.173.112.250 024 Enter your DNS search domain(s) (if any), separated by colons (:): 025 . 026 Enter DASD range (e.g. 200-203 or 200,201,202,203) 027 Press <Enter> for autoprobing (not recommended): 028 .0a01-0a02 029 030 Starting telnetd and sshd to allow login over the network. 031 032 Connect now to 192.168.2.2 to start the installation.
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.
Copying a File with IEBGENER
01 //MYJOB JOB (COPY),'COPY',CLASS=A,MSGCLASS=A,REGION=256K, 02 // TIME=5,MSGLEVEL=(1,1),NOTIFY=HERC04 03 //COPY EXEC PGM=IEBGENER 04 //SYSPRINT DD SYSOUT=* 05 //SYSUT1 DD DISP=OLD,DSN=HERC04.DATEI2 06 //SYSUT2 DD DSN=HERC04.FILE2.BAK,DISP=(NEW,CATLG), 07 // UNIT=SYSDA,VOL=SER=PUB002, 08 // SPACE=(CYL,(5,2,0)), 09 // DCB=(RECFM=FB,LRECL=80,BLKSIZE=4096,DSORG=PS) 10 //SYSIN DD DUMMY
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
According to a report, many potential victims of the Heartbleed attack have patched their systems, but few have cleaned up the crime scene to protect themselves from the effects of a previous intrusion.
DARPA and NICTA release the code for the ultra-secure microkernel system used in aerial drones.
Should you trust an online service to store your online passwords?
New B+ board lets you build cool things without the complication of a powered USB hub.
Redmond rushes in to root out alleged malware haven.
New initiative will bring futuristic virtual reality effects to the web surfing experience.
Dyreza malware launches a man-in-the-middle attack that compromises SSL.
New cloud combines worldwide access with local attention to data security.
A first cousin of the recent Heartbleed attack affects EAP-based wireless and peer-to-peer authentication.
FOSS community acts to protect freedom of choice for laptop devices.