Volume Table of Contents

Last updated

In the IBM System/360 [note 1] storage architecture, the Volume Table of Contents (VTOC), is a data structure that provides a way of locating the data sets that reside on a particular DASD volume. With the exception of the IBM Z compatible disk layout [1] [note 2] in Linux on Z, [2] it is the functional equivalent of the MS/PC DOS File Allocation Table (FAT), the NTFS Master File Table (MFT), and an inode table in a file system for a Unix-like system. [note 3] The VTOC is not used to contain any IPLTEXT [note 4] and does not have any role in the IPL process, therefore does not have any data used by or functionally equivalent to the MBR. It lists the names of each data set on the volume as well as size, location, and permissions. Additionally, it contains an entry for every area of contiguous free space on the volume. The third record on the first track of the first cylinder of any DASD (e.g., disk) volume is known as the volume label and must contain a pointer to the location of the VTOC. The location of the VTOC may be specified when the volume is initialized. For performance reasons it may be located as close to the center of the volume as possible, since it is referenced frequently. A VTOC is added to a DASD volume when it is initialized using the Device Support Facilities [note 5] program, ICKDSF, in current systems.

Contents

When in OS/360 and successors allocates a data set, it generally searches the catalog to determine the volumes on which it resides. [note 6] When a program opens a Direct Access Storage Device (DASD) dataset, the OPEN routine searches the VTOC index (VTOCIX) if there is one, or directly searches the VTOC if there is no VTOCIX.

Data Set Control Block types

The VTOC consists of a sequence of 140-byte records known as Data Set Control Blocks [3] [4] (DSCBs). There are ten types of DSCB.

DSCB types in a VTOC
DSCB format typePurposeNotes
0Empty entry
1Data set primaryDescribes first three extents of a data set (Starting and ending cylinders and tracks)
2ISAM data setDescribes ISAM data sets
3Data set extensionDescribes data set extents after the third
4VTOCDescribes volume attributes
5Free space26 extents on non-index volumes
6 [3] :  191-192  Shared Cylinder AllocationIn OS/360, Format 6 DSCB is used for Shared Cylinder Allocation, which enabled multiple datasets to be interleaved across a range of cylinders (such that, for example, the first half of each cylinder was allocated for data set A, and the second half for data set B). This was intended as a performance optimisation to reduce head movement when two or more datasets were expected to be used simultaneously. In current releases of z/OS, shared cylinder allocation format 6 DSCB is no longer supported. [4]
7Free spaceExtension of Format 4 DSCB
8Data set primaryEAV [note 7] version of Format 1 DSCB
9Data set extensionEAV extension of Format 3 DSCB

The VTOC must reside within the first 64K tracks on the volume, and The first DSCB in the VTOC is always a format 4 DSCB which describes the VTOC itself [note 8] and attributes of the DASD volume on which this VTOC resides. The second DSCB is always a format 5 DSCB which describes free space within the VTOC. Normally, the rest of the VTOC will contain format 0 DSCBs, which are empty entries, and format 1 or format 3 DSCBs, which describe the extents of data sets, giving their start address and end address [note 9] of up to 16 such extents on disk. The initial part of a data set is described by a format 1 DSCB. If necessary, format 3 DSCBs are used to describe further extents of the data set. When a data set is deleted, its format 1 DSCB is overwritten to become a format 0 DSCB, and the format 3 DSCB, if one exists, is similarly deleted.

Originally, a VTOC search was a sequential scan of the DSCBs, stopping when the correct format 1 DSCB was found or the end of the VTOC was reached. As DASD volumes became larger, VTOC search became a bottleneck and so a VTOC index was added.

Format 1 DSCB

This VTOC entry describes a dataset and defines its first three extents. This is the format of the DSCB from OS/360 Release 21.7 in 1973, prior to changes for Y2K. [5]

PositionLengthDescription
044Dataset name, left-adjusted and space-filled
this is the DSCB record key.
441Format identifier, '1' for Format-1 DSCB (character)
456Volume serial number of first DASD volume for this dataset (alphanumeric)
512Volume sequence number of this volume for multi-volume datasets (binary)
533Dataset creation date (binary) one byte for year of century and two bytes for day-of-year
563Dataset expiration date (same format as creation date)
99365 indicates that this dataset will never expire.
591Number of extents for this dataset (binary)
601If this dataset is a partitioned dataset this is the number of bytes used in the last directory block. (binary)
611Unused, listed as reserved by IBM.
6213Code identifying the operating system that created this dataset. (character)
757Unused, listed as reserved by IBM.
822Code indicating dataset organization (sequential, indexed, etc.) (bitfield)
841Code indicating the record format of this dataset (fixed, variable, etc.) (bitfield)
851Option code, other options specified when the dataset was created (bitfield)
862Block size (fixed size, or maximum size for files of variable-length records) (binary)
882Record length (fixed size or maximum length for variable length records) (binary)
901Key length if this file has recorded record keys. (binary)
912Position of the key (if any) in the record relative to zero. (binary)
931Indicator bits, for example indicating that the dataset is password-protected. (bitfield)
944Dataset allocation parameters, indicating, for example that space for this dataset is to be allocated in blocks, cylinders, etc. (bitfield)
953Secondary allocation quantity: Number of blocks, cylinders, etc. to be allocated if additional space is required. (binary)

For example, if the dataset is created with the DD card specification SPACE=(CYL,(4,2)) the dataset is initially allocated four cylinders, and an additional two cylinders, not necessary contiguous, will be allocated each time more space is needed, up to fifteen additional extents.

983DASD address of last block written in the dataset.
1012Number of bytes remaining on last track following last block indicated above. (binary)
1032Unused, listed as reserved by IBM.
10510Description of first or only extent.
Type of extent (one byte, bitfield),
extent sequence number (one byte, binary),
extent starting cylinder and track (four bytes, binary),

extent ending cylinder and track (four bytes, binary).

11510Description of possible second extent, same format as above.
12510Description of possible third extent, same format as above.
1355Pointer to Format-2 (index) DSCB in VTOC in format cylinder/head/record if this is indexed dataset.

Pointer to Format-3 (extension) DSCB if this dataset has more than three extents.

See also

Notes

  1. ↑ Including the successors S/370 through z/Architecture
  2. ↑ The VTOC for an IBM Z compatible minidisk has a VTOC with up to three datasets, each containing a Linux File system.
  3. ↑ While the VTOC only needs to associate names directly with storage allocations, a Unix file system has an indirect association via inodes.
  4. ↑ However, the IPL text on cylinder 0 track 0 does read and use the VTOC.
  5. ↑ DSF replaces the original IBCDASD and IEHDASDR, which IBM no longer distributes and which can not run on current hardware.
  6. ↑ It is possible, although unusual, for a job to bypass the catalog and specify the volume via dynamic allocation or JCL parameters.
  7. ↑ Extended Address Volume, a volume with more than 65,520 cylinders.
  8. ↑ The VTOC has a dataset name as the VTOC is, indeed, a dataset; the VTOC's dataset name is (44) X'04' characters, which, in later instances of the OS, has become a protected name; a program may not write into it without authorization.
  9. ↑ Each extent is described by a starting CCHH and an ending CCHH, relative to the beginning of the disk, which is CCHH=x'00000000'.

Related Research Articles

<span class="mw-page-title-main">Booting</span> Process of starting a computer

In computing, booting is the process of starting a computer as initiated via hardware such as a button on the computer or by a software command. After it is switched on, a computer's central processing unit (CPU) has no software in its main memory, so some process must load software into memory before it can be executed. This may be done by hardware or firmware in the CPU, or by a separate processor in the computer system.

In computing, a core dump, memory dump, crash dump, storage dump, system dump, or ABEND dump consists of the recorded state of the working memory of a computer program at a specific time, generally when the program has crashed or otherwise terminated abnormally. In practice, other key pieces of program state are usually dumped at the same time, including the processor registers, which may include the program counter and stack pointer, memory management information, and other processor and operating system flags and information. A snapshot dump is a memory dump requested by the computer operator or by the running program, after which the program is able to continue. Core dumps are often used to assist in diagnosing and debugging errors in computer programs.

Journaled File System (JFS) is a 64-bit journaling file system created by IBM. There are versions for AIX, OS/2, eComStation, ArcaOS and Linux operating systems. The latter is available as free software under the terms of the GNU General Public License (GPL). HP-UX has another, different filesystem named JFS that is actually an OEM version of Veritas Software's VxFS.

A direct-access storage device (DASD) is a secondary storage device in which "each physical record has a discrete location and a unique address". The term was coined by IBM to describe devices that allowed random access to data, the main examples being drum memory and hard disk drives. Later, optical disc drives and flash memory units are also classified as DASD.

Disk formatting is the process of preparing a data storage device such as a hard disk drive, solid-state drive, floppy disk, memory card or USB flash drive for initial use. In some cases, the formatting operation may also create one or more new file systems. The first part of the formatting process that performs basic medium preparation is often referred to as "low-level formatting". Partitioning is the common term for the second part of the process, dividing the device into several sub-devices and, in some cases, writing information to the device allowing an operating system to be booted from it. The third part of the process, usually termed "high-level formatting" most often refers to the process of generating a new file system. In some operating systems all or parts of these three processes can be combined or repeated at different levels and the term "format" is understood to mean an operation in which a new disk medium is fully prepared to store files. Some formatting utilities allow distinguishing between a quick format, which does not erase all existing data and a long option that does erase all existing data.

Virtual Storage Access Method (VSAM) is an IBM direct-access storage device (DASD) file storage access method, first used in the OS/VS1, OS/VS2 Release 1 (SVS) and Release 2 (MVS) operating systems, later used throughout the Multiple Virtual Storage (MVS) architecture and now in z/OS. Originally a record-oriented filesystem, VSAM comprises four data set organizations: key-sequenced (KSDS), relative record (RRDS), entry-sequenced (ESDS) and linear (LDS). The KSDS, RRDS and ESDS organizations contain records, while the LDS organization simply contains a sequence of pages with no intrinsic record structure, for use as a memory-mapped file.

Job Control Language (JCL) is a name for scripting languages used on IBM mainframe operating systems to instruct the system on how to run a batch job or start a subsystem. The purpose of JCL is to say which programs to run, using which files or devices for input or output, and at times to also indicate under what conditions to skip a step. Parameters in the JCL can also provide accounting information for tracking the resources used by a job as well as which machine the job should run on.

<span class="mw-page-title-main">File system</span> Computer filing system

In computing, a file system or filesystem governs file organization and access. A local file system is a capability of an operating system that services the applications running on the same computer. A distributed file system is a protocol that provides file access between networked computers.

In the context of IBM mainframe computers in the S/360 line, a data set or dataset is a computer file having a record organization. Use of this term began with, e.g., DOS/360, OS/360, and is still used by their successors, including the current z/OS. Documentation for these systems historically preferred this term rather than file.

This article discusses support programs included in or available for OS/360 and successors. IBM categorizes some of these programs as utilities and others as service aids; the boundaries are not always consistent or obvious. Many, but not all, of these programs match the types in utility software.

In computing, channel I/O is a high-performance input/output (I/O) architecture that is implemented in various forms on a number of computer architectures, especially on mainframe computers. In the past, channels were generally implemented with custom devices, variously named channel, I/O processor, I/O controller, I/O synchronizer, or DMA controller.

Count key data (CKD) is a direct-access storage device (DASD) data recording format introduced in 1964, by IBM with its IBM System/360 and still being emulated on IBM mainframes. It is a self-defining format with each data record represented by a Count Area that identifies the record and provides the number of bytes in an optional Key Area and an optional Data Area. This is in contrast to devices using fixed sector size or a separate format track.

In IBM mainframe operating systems OS/360 and its successors, a Unit Control Block (UCB) is a memory structure, or a control block, that describes any single input/output peripheral device (unit), or an exposure (alias), to the operating system. Certain data within the UCB also instructs the Input/Output Supervisor (IOS) to use certain closed subroutines in addition to normal IOS processing for additional physical device control.

In IBM mainframe operating systems, Execute Channel Program (EXCP) is a macro generating a system call, implemented as a Supervisor Call instruction, for low-level device access, where the programmer is responsible for providing a channel program—a list of device-specific commands (CCWs)—to be executed by I/O channels, control units and devices. EXCP for OS/360 and successors is more specifically described in the OS System Programmer's Guide.; EXCP for DOS/360 and successors is more specifically described in DOS Supervisor and I/O Macros. This article mostly reflects OS/360 through z/OS; some details are different for TOS/360 and DOS/360 through z/VSE.

<span class="mw-page-title-main">OS/360 and successors</span> Operating system for IBM S/360 and later mainframes

OS/360, officially known as IBM System/360 Operating System, is a discontinued batch processing operating system developed by IBM for their then-new System/360 mainframe computer, announced in 1964; it was influenced by the earlier IBSYS/IBJOB and Input/Output Control System (IOCS) packages for the IBM 7090/7094 and even more so by the PR155 Operating System for the IBM 1410/7010 processors. It was one of the earliest operating systems to require the computer hardware to include at least one direct access storage device.

Fixed-block architecture (FBA) is an IBM term for the hard disk drive (HDD) layout in which each addressable block on the disk has the same size, utilizing 4 byte block numbers and a new set of command codes. FBA as a term was created and used by IBM for its 3310 and 3370 HDDs beginning in 1979 to distinguish such drives as IBM transitioned away from their variable record size format used on IBM's mainframe hard disk drives beginning in 1964 with its System/360.

Basic Direct Access Method, or BDAM is an access method for IBM's OS/360 and successors computer operating systems on System/360 and later mainframes. BDAM "consists of routines used in retrieving data from, and storing data onto, direct access devices." BDAM is available on OS/360, OS/VS2, MVS, z/OS, and related high-end operating systems.

A master boot record (MBR) is a special type of boot sector at the very beginning of partitioned computer mass storage devices like fixed disks or removable drives intended for use with IBM PC-compatible systems and beyond. The concept of MBRs was publicly introduced in 1983 with PC DOS 2.0.

Data Facility Storage Management Subsystem (DFSMS) is a central component of IBM's flagship operating system z/OS. It includes access methods, utilities and program management functions. Data Facility Storage Management Subsystem is also a collective name for a collection of several products, all but two of which are included in the DFSMS/MVS product.

References

  1. ↑ "IBM Z compatible disk layout". IBM Knowledge Center.
  2. ↑ "Linux on Z and LinuxONE". IBM Knowledge Center.
  3. 1 2 "Data Set Control Blocks" (PDF). IBM System/360 Operating System: System Control Blocks (PDF). IBM Systems Reference Library (Tenth ed.). IBM Corporation. April 1973. pp. 165–173. GC28-6628-9.
  4. 1 2 "Data Set Control Block (DSCB) Types" (PDF). z/OS Version 2 Release 4 DFSMSdfp Advanced Service (PDF). IBM Corporation. 2020-12-13. pp. 2–17. SC23-6861-40.
  5. ↑ IBM Corporation (April 1973). IBM System/360 Operating System: System Control Blocks (PDF). pp. 170–173. Retrieved 2016-08-01.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.