Talk:Volume Table of Contents

Active discussions
WikiProject Computing (Rated Start-class, Low-importance)
This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 Low  This article has been rated as Low-importance on the project's importance scale.

The VTOC was for all S/360 DASD, not just diskpacksEdit

The statement VTOC was originally designed for removable disk packs. is false; the VTOC was designed for all Direct Access Storage Devices (DASD) on the S/360, including data cells, drums and fixed disks. Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:17, 27 September 2020 (UTC)


@Chatul: I noticed you removed the stuff about the VTOC being like a partition table (GPT/MBR) and replaced it with a statement that VTOC isn't comparable to MBR. I think it is a bit more complex than that. You have to distinguish between two different ways of using VTOC:

  • in traditional IBM operating systems (z/OS and z/VSE) – in this way of using VTOC, VTOC functions like a root directory in a DOS/Windows/Unix filesystem, albeit it embeds allocation information (like FAT or inodes), and it doesn't have subdirectories per se (although there are a bunch of features which vaguely approximate the idea of subdirectories–name segments, user catalogs, PDS(E), etc). Individual (non-VSAM) datasets are entries in the VTOC. In this use case, VTOC isn't really comparable to an MBR or GPT
  • z/Linux, however, uses VTOC as a partition table. Each z/Linux filesystem on the disk is a single contiguous dataset. So in this use case, VTOC is in fact directly comparable to GPT or MBR. The Linux kernel treats VTOC as a partition table format along with the others it supports (GPT, MBR, Apple Partition Map, BSD disklabel, etc). (Unlike MBR, VTOC partition table doesn't store any IPL text, but IPL text is not a necessary constituent of a partition table format.)

(z/Linux actually supports three different disk layouts – VTOC partition table, CMS partition table, and no partition table. VTOC partition table is preferred for coexistence with z/OS and z/VSE; CMS partition table is preferred for coexistence with z/VM; no partition table is ideal for pure z/Linux environments in which there is no z/OS or z/VSE or z/VM. Only VTOC supports multiple partitions; the CMS layout and the no table layout only support a single partition. All three layouts are supported for ECKD disks, but for FBA disks you can use CMS partition table only. z/Linux can use z/VM DIAG to accelerate disk access with CMS layout and no table layout but not with VTOC layout.)

So I think the stuff you removed was correct when viewed from the z/Linux viewpoint, but wrong from the z/OS and z/VSE viewpoint. Whereas, the statement you've replaced it with is correct from the z/OS and z/VSE viewpoint, but wrong from the z/Linux viewpoint. I think it needs to say that VTOC is a partition table format in the context of z/Linux but not in the context of z/OS and z/VSE. Mr248 (talk) 23:47, 30 November 2020 (UTC)

@Mr248:The use of a period as a component separator is reflect in other aspect's of IBM's operating systems, but has no relevance to how the VTOC is structured or used. It's an artifact of the old Control VOLume (CVOL), which is no longer supported, although it is till relevant to prefixing of dataset names and to locating user catalogs. PDS and PDSE are certainly analogous to subdirectories, but the directories of member names are in the dataset, not in the VTOC.
From what you write it sounds like there should be parallel sections for legacy IBM operating systems and for z/Linux; can you provide sources to cite for what z/Linux supports?
I'm not sure what you mean by CMS layout or CMS partition table. CMS normally[a] uses a minidisk with a dummy VTOC showing no available space, and formats everything past the VTOC with a CMS file system, with two component names for the files. Do you mean a minidisk with a dummy VTOC and a Linux filesystem rather than a CMS filesystem? Shmuel (Seymour J.) Metz Username:Chatul (talk) 03:01, 1 December 2020 (UTC)
@Chatul: This manual talks about how z/Linux handles partitioning. As to CMS partition table layout, that is documented here. As it notes, there are two different subformats for CMS partition tables – one in which the minidisk contains a single CMS file taking up all the space, which contains the Linux filesystem (this file can be created using the CMS RESERVE command), and another in which the disk has a CMS disk label but not a proper CMS filesystem (I think in this minimal format the FST is missing). Actually I think the Linux kernel source code is a pretty good source for how this all works – see in particular the files vtoc.h and partitions/ibm.c. The find_label function shows how to distinguish the three types of disks – the first four bytes of the DASD volume label record are VOL1 for a VTOC disk, LNX1 for a Linux disk, CMS1 for a CMS disk. The volume label record is block 2 on an ECKD disk (that's the third block since Linux uses zero-based block numbers), block 1 on an FBA disk (second block). (The source code also mentions some nuance about where it is located when CMS disks are accessed via DIAG which I don't quite claim to understand.) Internally Linux uses FBA-style addressing even for ECKD disks, it works with FBA-style addresses and converts them to ECKD format before sending them to the DASD. Reading this code, I don't see any evidence for a protective VTOC on CMS-format disks; CMS-format disks have a volume label record type of CMS1 instead of the expected VOL1 so z/OS and z/VSE should refuse to read them. They should be validating the volume label record type before retrieving the VTOC address from the volume label record and that will fail for CMS-format and native Linux format disks.) Linux running under z/VM has no support for running out of an SFS/BFS file, and it only supports running from a minidisk containing a CMS filesystem if that filesystem contains a single file taking up all the disk. (From reading the Linux source code, it looks like it does very little validation of the minidisk layout, so if you gave it a CMS minidisk containing multiple files I think it would just go ahead and trash the minidisk for you.) Also, I've discovered there is one other format, although use of it is discouraged, this is the native Linux format but without the LNX1 volume label record. Under Linux, that can be generated by passing the -L argument to the dasdfmt command. Mr248 (talk) 04:32, 1 December 2020 (UTC)


  1. ^ CMS can also access files in Shared File System (SFS), running in a service virtual machine.


Return to "Volume Table of Contents" page.