As we’ve seen in previous articles, Linux on the mainframe is largely similar to Linux on a PC. However, the main thrust of this ongoing series has been to show how Linux guests in a z/VM environment can leverage VM’s capabilities to do things otherwise impossible on a stand-alone Intel server. In this article, we’ll examine the use of CMS as an extremely smart BIOS for the z/Linux guest and how to maximize CP services and the CMS file system from within Linux itself.
Booting Into CMS
If you have a Linux guest, it in no way depends on CMS. So, in its directory entry, you ought to have it IPL the Linux file system with the Linux IPL records, or the named saved segment (NSS) containing Linux (as was discussed in the June/July 2003 z/Journal article, “Playing Well With Others: Linux on z/VM”), right? Wrong. Certainly, it’ll work that way, and of course you have to IPL from something containing a Linux boot record eventually, if you want to run Linux. However, to IPL Linux without IPLing CMS first means you lose access to a lot of functionality and flexibility otherwise present.
It’s best to think of CMS as an extremely bright, scriptable BIOS. You’re not using it for any CMS applications, but merely to set up things to better support your Linux system. PROFILE EXEC runs when a CMS guest logs on, so if we put the setup steps into that file, they’ll all happen during a lights-out IPL.
Figure 1 shows a PROFILE EXEC from a Linux service machine. Let’s take it from the top: PF12 as Retrieve brings up the last line typed. Pressing it repeatedly scrolls through the command history. This is hardcoded into my fingers by now, and I get frustrated if it isn’t present, so I make sure this goes in all my guest machines. I also have a standard PROFILE XEDIT that gets used, for the same reasons. I get aggravated when editing files, unless my editor settings load automatically.
In this case, 39F is a shared tools disk; this is one of Sine Nomine’s local conventions that I highly recommend. The disk is mounted read-only to this guest (and to all Linux guests). It contains the images of the IPL decks necessary to IPL from the virtual card reader, DEBIAN EXEC (which punches the cards into the virtual reader and then IPLs from it), and SWAPGEN and RXDASD to facilitate creation of V-DISK-based swap space before booting Linux. This is also where I put my PROFILE XEDIT. Our standard new Linux machine directory template includes a link to this disk, so it is available to all Linux guests.
Another use of CMS not shown here is as a tool to enable some functionality that Linux currently lacks. For instance, Linux out of the box doesn’t understand tape libraries. UTS Global makes an excellent Linux/390 tape-handling package, but if you have a constrained budget, a way to emulate tape library support is to create a CMS guest whose job is to manipulate the tape library (because CMS knows how to drive the libraries) and then give it a CMS pipelines-based network socket controller. Your Linux guest can connect to it over TCP/IP, send commands, and collect responses. This is a more circuitous way to get access to some device than directly through a device driver, but it doesn’t require you to write a Linux driver for a (possibly undocumented) new device.