Evangelizing Mainframe
Print Email

Virtualization in the Time of Myth

Many people think virtualization was invented with VMware. Most mainframe people think it was invented by IBM with VM (or more precisely CP/67), or so they had been told by the elders. But the roots of virtualization go back even further than that. The kind of virtualization I’m thinking of is not the server virtualization of CP/67, VM, or VMware but rather could be called virtualized access to data. The OS/360 operating system supported two forms of data-access virtualization from its very beginning in 1964. I refer to this as the Time of Myth because even I, whose personal experience of computing goes back to 1969, did not personally witness the introduction of these concepts and had to learn of them from the elders.

The first virtualization concept I want to talk about is indirect data reference. That is, relating to how you identify the file to be processed. In a system that doesn’t have an integrated job definition language, the names of files have to be imbedded in the application program itself or passed to the program as parameters. This was the case on early computer systems and happened again when PCs were introduced. I experienced this myself using Turbo Pascal on an IBM PC.

OS/360 provided a very powerful job definition language called Job Control Language or JCL. With JCL, a program did not need to contain or obtain the actual names of the files to be accessed. In the program, a file is referred to by a data definition name, or DDNAME. A data definition statement in the JCL maps (or virtualizes) the symbolic DDNAME onto the actual data set name. Programs could be written that can process an entire class of data set without the extra code and complexity of having to receive the data set name as a parameter, or worse yet, modifying the program to name a different file (like I did with Turbo Pascal).

This was not the full extent of indirect data reference virtualization. Knowing the name of a data set is not sufficient on a system that has multiple data storage devices. To go further, OS/360 used a catalog. The catalog was used to locate the data set on a tape or disk volume. This not only relieved the programmer or JCL coder from having to know which volume actually contained the data, it also allowed the data to be moved around without invalidating the virtualization provided through the DDNAME. These days, the Data Facility Storage Management Subsystem Hierarchical Storage Manager (DFSMShsm) uses the indirection provided by the catalog to be able to actually move data off the systems while it isn’t being accessed and then move it back the next time it is accessed.

The last step of this virtualization applies only to direct-access storage media like disk and drum storage. It is the volume table of contents or VTOC, which maps a data set name to the actual physical extents of the volume that contains the data. Multiple extents, possibly on multiple volumes, hold the actual data. The programmer and the JCL coder imagine that the data is a set of contiguous records, but this is not the case. It’s an illusion created by this virtualization in OS/360.

The use of the catalog and VTOC to virtualize the location of the data segues into another from of data-access virtualization provided in OS/360. This one relates to how programmers access the data within files, or data sets. OS/360 provided access methods that shielded the programmer from concerns about the type of medium on which the data was stored. Access methods allowed the data to be accessed based on its logical organization without regard to the physical medium type. For example, the queued sequential access method (QSAM) provided access to sequential data sets regardless of what medium they were stored on. The data could be a card deck or a file on tape or stored in a collection of extents on a disk volume. These days, it could even be a file stored on media attached to a remote system. A single program, which only cared about the sequential nature of the data records, could access a file without ever knowing which medium it was stored on.

The access methods also shielded the programmer from having to deal with the physical geometry of direct access storage devices like disk or drum. These devices stored data on tracks that were physically grouped into cylinders. In those days, different devices could have different numbers of tracks per cylinder. OS/360 provided a virtualization concept called relative track number that allowed even direct access to data without knowledge of the device geometry or the breakdown of the data set into physical extents. The programmer could reference a physical record simply by providing its relative track number and record number on that track.

Another access method, the indexed sequential access method (ISAM) provided access to data records based on keys associated with them. In a sense, this access method virtualized the location of the data completely. The programmer provided a key and the access method accessed the associated record regardless of which volume it resided on, the type of devices, which extent contained the selected record, or the track capacity of that device. The programmer only needed to know that the data was stored with the ISAM organization.

In most cases, the actual interfacing with the access methods was done by the run-time library of a high-level language like COBOL. This relieved the programmer of even more details of how the data was physically stored.

We have no trouble believing in this virtualization that arose in the time of myths almost 50 years ago because it is still with us today. All of these capabilities that were introduced in OS/360 are still provided by z/OS. Programs and JCL written in that mythical time still work on the latest processors running the latest release of z/OS. This is truly amazing but definitely not the stuff of myth.

Bob Rogers is a z/OS designer, philosopher and evangelist. An IBM Distinguished Engineer, he frequently presents at SHARE and other conferences.

Posted: 6/26/2012 4:03:05 AM by Bob Rogers | with 1 comments

Print Email

Please sign in to comment.

Sign In

with 40 years working on the mainframe, this is a great write up on
the file system.
Posted: 7/5/2012 2:50:20 PM by danbouch

Join Now!