In the previous DBAOTM post I have described the operating systems available for the IBM mainframe and seen z/OS is the flagship in this category. In this post I will introduce you into the z/OS operating system concepts and terminology. The goal of this piece is to give you a good idea what is special about z/OS are and how the peculiarities relate to more commonly known concepts in Unix and Windows operating systems.

z/OS: MVS and Unix combined

I will describe the z/OS operating system into two parts, and discuss these separately. The traditional part is MVS and this part deviates most from what we know from Windows and Unix. The second part is z/OS Unix, an extension that can run Unix applications, very much similar to other Unix flavours.

Next in my discussion, in upcoming posts about z/OS, I will talk about the unique clustering facility that z/OS brings, called parallel sysplex. Finally I will cover the green screens that the mainframe is often associated with, and discuss where this is still used. I will discuss modern tools and IDE’s for z/OS that come with modern user interfaces, replacing the old green-screen based tools.

The MVS part of z/OS

The MVS side of z/OS is the traditional mainframe side. This is the part that has its roots in the 1960s. MVS and its predecessors were built in the era in which batch processing with punch cards was the basic way of interacting with the mainframe. In MVS we find the features that today look a bit awkward.

Basic operation of the MVS part with batch and JCL

First let’s have a look at he basic operation of a batch process in z/OS. The batch process is core to the MVS part of z/OS. In essence, today it still works in the same way as it was when designed in the 1960.

To run a program on z/OS you need to have a means to tell it what to do. You do this by creating a script, which is usually quite small. The language for this script is called JCL – Job Control Language.

With the JCL script you tell the computer which program to run, and for that, what the input is for that program and where the output must be written to. This looks like a piece of code like this:

//RUNPROG  EXEC PGM=PROGRAM1
//INPUT    DD DISP=SHR,DSN=MY.INPUT.DATA
//OUTPUT   DD DISP=NEW,MY.OUTPUT.DATA

This code looks awful of course, despite its simplicity. This is because the language was designed for punch cards. Punch cards can carry 80 characters per line, and every line also needed some special positions to control the operation of the punch card reader. Also, to make things as simple as possible for the punch card reader, everything is in uppercase. All in all, JCL is probably easily readable for a punchcard reader device, but from an aesthetical and ergonomic perspective it is horrendous.

Anyway, with the above snippet of JCL you tell the computer to run PROGRAM1, use MY.INPUT.DATA as input file, and MY.OUTPUT.DATA as output file. If you feed this into the mainframe running z/OS it will try do execute this as such.

Figure – JCL to describe work to be done

In the old days the JCL was punched by the programmer on paper punch cards, one card for every line of JCL. The stack of cards were then inserted into a punch card reader attached to the mainframe.

Nowadays card reader devices do not exist anymore. They are replaced by a piece of software that is part of z/OS and called the internal reader.

The user starts his program by typing a “Submit” command with the JCL as a parameter or selecting the Submit option in the user interface of a modern IDE, as illustrated in Figure 7.

Figure – Submit JCL from a modern IDE

Now z/OS, the reader software, will read the JCL, find the program and the files needed,  and start the execution of the program.

Address Spaces are processes

The execution of the program is peformed by a dedicated process for the task at hand. In Unix and Windows you call these execution concepts simply: processes. But in the MVS part of z/OS this process concept is called an Address Space. You can imagine many tasks are running at the same time for many users. All these tasks are run in Address Spaces on z/OS.

Although the name Address Space seems to indicate this just has something to do with memory, it is actually the same concept as a process in Windows and Unix.

Virtual storage is memory

The Address Space gives the program the memory that is needs to execute. This is called virtual storage on z/OS.

The odd thing is that Mainframers often refer to memory as storage. They could do this without getting confused with disk storage because that was called DASD – an abbreviation of Direct Access Storage Device.

Take care when a mainframer talks about storage, he might mean memory, but also disk storage.

Datasets are files and catalogs organizes files like a directory structure does

On the MVS side data is stored in datasets. Datasets are files, but with some quirks I will discuss in a minute.

Datasets are administered in catalogs. Catalogs are designed to keep a record of dataset names and the place where these datasets are stored.

Datasets are record-oriented and can have different structures

Datasets are so-called record-oriented. This means a dataset is defined with details that prescribe a structure for how the data is organized.

When you define a data in z/OS you must define how big the records are, how z/OS must and how z/OS must organize the data in the dataset.

The organization of a dataset can be a linear layout. We then call these sequential datasets. A dataset can also have a more complex hierarchical layout. We call these VSAM datasets (I will spare you the meaning of the abbreviation).

In sequential files the data is order from first records to last record. To read or write a sequential dataset you start at the beginning and proceed with the next record until you are done.

VSAM datasets have a sort of database structure. The records you store in a VSAM files have a key value. You do not usually browse through the VSAM dataset, but you read a specific record based of its key value. z/OS finds the record in the file with that key value. To do this, VSAM keeps indexes of key values and records. The benefit of VSAM files is that they can provide very fast access to the records is has stored.

When you create and MVS dataset you also have to specify a number of physical characteristics. These are characteristics like record size, format of the records, the size of blocks on disk that will hold the records, and more. These things were mostly aimed to optimize access speed and storage on disk. But with modern storage hardware these things have become obsolete. Many of these details can be removed for the user of z/OS, but unfortunately oftentimes this often is not yet done.

The applications you build on z/OS nowadays would only use sequential files only. The things that VSAM solved for applications in the past can now be much easier done in a database management system like Db2. The main use of VSAM that remains is for special operating system and middleware datasets, when very fast access to data is required. Under the hood of z/OS and the middleware.

Figure – Sequential and VSAM file structures

When you compare a Unix or Windows file to a dataset, you observe that a file in Unix and Windows does not have this prescribed structure that an MVS dataset has. From the user program perspective a file is just a big string of bytes. The data in the files can be organized internally. Often this is done with control characters, like Carriage Return (CR) and Linefeed (LF). The applications themselves have to provide that structure to the files.

Figure – File structure in Unix

The EBCDIC character set

In the traditional part of z/OS, data in the datasets is encoded in the Extended Binary Coded Decimal Interchange (EBCDIC) character set. This is a character set that was developed before ASCII (American Standard Code for Information Interchange) became commonly used.

Most systems that you are familiar with use ASCII. By the way, we will see z/OS UNIX files are encoded in ASCII.

Normally you will not notice anything different when you read files on z/OS and you will be unaware of the EBCDIC representation of data. However, if you want to transfer files between Windows or Unix and z/OS datasets, you will need to convert the characters from their ASCII representation to their EBCDIC representation, and vice versa. Typically file transfer programs will do this operation for you, called code page transformation, as part of the transfer action.

Catalogs are like directories

In Unix and Windows files are organized in a directory structure, and a hierarchy of file systems to manage the various disks on which the files may be stored. Files systems are defined on hard disks and hold the physical files, and the directory structure provides an organizing hierarchical mechanism for the files in the file systems. The root file system holds the operating system’s core files, other files systems can be mounted to extend the file storage over multiple storage devices.

The operating systems can find a file if you give it the name of the file and the directory in which it is defined.

Figure – File system and directory structures

In the MVS part of z/OS, the datasets are organized in catalogs. A catalog is in essence an index of dataset names in the z/OS system and the disk names on which the datasets are stored. With the catalog mechanism, if the user knows the name of the dataset, the catalog can tell on which disk it can be found.

To make the mechanism of catalogs a bit easier for the system administrator, catalogs are divided in a master catalog and user catalogs. There is one master catalog and there can be many user catalogs. The master catalog contain the system datasets. The user catalogs contain the user and application datatsets. The system administrator can define which datasets are administered in which catalog. When the system administrator decides to administer datasets for application APP2 in a certain user catalog, he put a little information in the master catalog to inform z/OS about that. This information is called an ALIAS.

To find a dataset with a certain name, z/OS first looks in the master catalog. z/OS finds it there, or it finds an ALIAS reference. The ALIAS reference tells z/OS to look in the associated user catalog for a dataset with that name. When z/OS has found the antry for a dataset, it uses the disk name in the index entry to access the file on disk.

Again, comparing this to Unix, you can say that the master catalog has a similar function as the root filesystem: it is meant for the operating system and middleware datasets. The user catalogs are like mounted file systems: for application and user datasets.

A catalog is however a registration that is separate from the physical storage. In Unix, the registration of files is done on the filesystems themselves. With a catalog this is not the case. In fact, a catalog is just a dataset itself. A VSAM dataset to be precise. It can be stored on any disk.

Figure – The structure of master and user catalogs

This concludes an introduction to the MVS side of the z/OS operating system. In a next post I will turn to the Unix side of z/OS.