z/OS system managed VTOC? All in favor, say “aye!”
🖥 🖥 🖥
The primary means of managing space in z/OS® is through the Data Facility Storage Management Subsystem (DFSMS™), which comprises a suite of related data and storage management products. DFSMS performs the essential data, storage, program, and device management functions of the system.
Since DFSMS performs the essential management functions of the system, wouldn’t it be cool if it managed the most essential part of being able to store data on the system? This data is managed by the volume table of contents (VTOC).
In z/OS, data is stored on a direct access storage device (DASD) volume as a data set. These DASD volumes contain tracks, which are where the data is recorded. The locations of the data on these tracks are known as data set extents. A data set may consist of multiple extents spread across different tracks on the volume.
The VTOC is made up of data set control blocks (DSCBs), which are records on the tracks. The DSCBs will contain the name of the data set, its structure, and the extents of the data set. The VTOC is used to access the data. The VTOC will also have a space map that will contain what tracks are being used (allocated) and which tracks are free (unallocated). These data sets are managed by the VTOC and cannot be created without one.
Before we can put data on a DASD volume, we must first initialize it. You must be cognizant of the VTOC requirements, as the VTOC is placed on the volume when initialized. The size of the VTOC determines how many data sets can fit on the volume. When the VTOC is full you cannot allocate any more data sets without expanding it.
However, the problem with expanding the VTOC, is that it requires contiguous space on the volume and only has one extent. This means that you may not be able to expand it in place if space after the VTOC is unavailable. If there is not space available to expand the VTOC in its current location your only alternatives are to either move the data sets that are occupying the space after the VTOC or vary the device offline and move the VTOC to another location on the volume.
If the VTOC was treated like a data set, it could have multiple extents that would alleviate the problem of not being able to expand the VTOC in place. When you think about it, data is placed on the volume as data sets and the VTOC itself is just one data set. The space map within the VTOC not only accounts for the space that the data sets occupy, but it also accounts for the space that the VTOC occupies. The only real difference I see between a data set and the VTOC is that the data set has a name associated with it whereas the VTOC does not.
A unit control block (UCB) holds information about a volume. One of the fields within the UCB is the track address of where the VTOC is located. The first record in the VTOC is known as the format 4 DSCB and it describes the contents of the VTOC along with the extent size of the VTOC. There is a field within this format 4 DSCB that describes the number of extents that the VTOC has. This field has a value of one, as currently the VTOC can only have a single extent. There is also a field that contains the VTOC extents, being the beginning and ending track address for the VTOC. After this field there are ten bytes that are defined as being reserved. Five of these bytes could be used to define a new field that would contain the track address of the next VTOC extent.
Since the UCB field only points to the beginning of the VTOC we do not care where the VTOC ends, as that location is kept within the format 4 DSCB. Each extent would now begin with a format 4 DSCB that would describe the beginning and ending track address of that extent, and also have the track address of the next extent if one existed.
The VTOC index is actually a data set with the name SYS1.VTOCIX.volser, which has entries arranged alphabetically by data set name with pointers to the VTOC entries. A VTOC index allows the user to find the data set much faster. This index data set is built by reading the VTOC DSCBs and could be rebuilt when a new VTOC extent was added.
By lifting the restriction of the VTOC requiring contiguous space and allowing it to have multiple extents, DFSMS gains the ability to manage the VTOC itself. The VTOC could now automatically be resized to add additional extents as your data set allocations grow. By letting the system manage the VTOC, the storage administrator has one less task to worry about.
Please feel free to leave me your comments, as would love to know how others feel on this topic.
