Read and write a CMS minidisk on a z/VM system from a user/guest running Linux

When you’re managing a z/VM host running multiple Linux images, it can be interesting to have access to the data which resides on a CMS owned minidisk. Such type of minidisk is probably used to control the z/VM related configuration of the guest itself in some way. Also, when scripting, the explained technique can be used to read or write data from and to one of the minidisks. One example could be to change the PROFILE.EXEC from a user from within the user itself.

For this explanation, I assume that a guest (or used as it should be called in z/VM terms) is running Linux for zSeries (zLinux as it once was) on a z/VM host. I was using SLES11 running on z/VM 6.3.

Most distributions which are for the s390(x) platform contain the s390-tools package. That package contains some tools that are used to interact with specific system z devices and z/MV. In case some binaries would be missing which I use here, you should check if the package is installed.

Access the CMS minidisk on the Linux user

As a first step, we’ll load the fuse kernel module which will allow us to have a vitual filesystem for the minidisk.

Before we can access a minidisk for the z/VM user, we need to set the allocated minidisk online with chccwdev. For the example, I chose to put the 191 minidisk online which exists for most CMS-users since it’s the default work disk. Normally your PROFILE.EXEC, which defines what is executed when the guest/user starts, resides on the 191 minidisk.

When putting the device online, we should see some messages in /var/log/messages, explaining us that a new device was “connected”. The same as would happen when you would connect a usb drive to an x86 system. A minidisk is considered a channel attached device and will be given a Linux block device name in the form of /dev/dasdx.

To check which device name our 191-minidisk has been given, we can use lsdasd:

Once we have the device in Linux, we can mount the device and make the filesystem on the 191 minidisk accesible to our Linux guest. In order for the Linux guest to understand the data on the minidisk, we use the cmsfs-fuse filesystem. Here is also where data is converted between EBCDIC and ASCII:

Read data from the minidisk

Once the minidisk is mounted, it behaves almost like any other filesystem under Linux. We can list and read “files” on the filesystem as we can do with any other filesystem. A basic operation could be to list the files on the minidisk. We should be able to see the PROFILE.EXEC for our guest:

Change existing files on the minidisk

The easiest way, and least dangerous way to edit an existing file on the CMS minidisk, is to take a copy of the file to another filesystem, edit the file as desired and copy it back to the minidisk. This way, you can be sure that everything gets converted as it should and that the data on the minidisk doesn’t get corrupt and stays in the same format as it originally was.

Create new files on the minidisk

To create new files on the minidisk, we start by creating a new, empty file:

The next step is to set the correct attributes of the file. Since Linux has no knowledge of allocation parameters like record length or block format, we’ll need to tell the cmsfs-fuse filesystem which type of data for CMS we want to create:

To check the current file attributes of the file, we can use getfattr.

In the above example, I used the -n option which allows you to specify one attribute to list. If you want to see all attributes, you can use -d.

As you can see, a new file gets a variable blocked attribute by default.

Let’s say we want to create a fixed block file with a record length of 80, then we need to change the attributes as follows:

When checking the file attributes after our changes, we can see that the file is allocated as we wanted:

After allocating the new file, we can edit or read it as explained before.

Unmount and put the minidisk offline

After doing the necessary file operation on the data that is residing on one of the z/VM guest’s minidisks, it’s important to safely unmount the device and put it back offline to prevent problems.

Leave a Reply

Your email address will not be published. Required fields are marked *