Disk Storage Devices

VSAM, the Virtual Storage Access Method, is a general purpose access method intended to assist users in storing and retrieving data on disk devices of various types. In IBM jargon, these disk devices are often referred to as DASD, or Direct Access Storage Devices.

Disk devices have a number of characteristics that make their use desirable:

• Relatively fast data transfers
• Direct access, which means a program may retrieve data from any point without having to retrieve all the data preceeding it.
• High reliablity, meaning that there is a very high probability of correct retrieval -- what is read is very likely an exact copy of what is written.

  In addition, given modern technology, it is very uncommon for a disk subsystem to fail in a way that causes loss or corruption of data.

The ability to perform these functions quickly and reliably requires a certain complexity in those systems which use disk files. Access methods were developed as operating system components in order to relieve application designers and programmers from concern with the details of disk device management.

Some Disk Device Details

IBM disk devices used by System/390 and zSeries systems have a number of characteristics in common. Note that even though physical hardware implementation may be significantly different from what is described in this section, the hardware implementation provides an interface that appears equivalent to this, even at the operating system level. Detailed ramifications of this difference will be discussed in other areas.

Disk devices use rotating magnetic recording surfaces to store the user's data. Most devices have multiple platters mounted on a single shaft, and rotating as a unit. Early (1965 - 1975) disk recording surface coatings looked very similar to that of magnetic tape -- a redish brown layer of magnetic iron oxide particles in a plastic binder. Today, that surface still contains magnetic particles, but is usually so highly polished that it appears mirror bright.

Early devices used aluminum platters of about 15 inches (about 40 centimeters) in diameter, storing a few megabytes of data at most. Today, the smallest commercial disk storage products use platters one inch (2.5 centimeters) in diameter, and these small disks store one gigabyte (one thousand million bytes) in a finished package small enough to fit into a digital camera compact flash card format.

Magnetic recording and reading heads can be moved radially to select the radial position, or track of the disk where the data is to be written or read. Initially, disk devices used 50 to 100 radial positions per inch (20 to 40 positions per centimeter), but technology has permitted increases in track density to more than 2000 positions per inch or 800 positions per centimeter today.

Early disk devices recorded data along the tracks at a few thousand bits per revolution. Today, that density has also increased to several hundred thousand bits per revolution. At the same time, error detecting and correcting codes have been developed that permit the detection and correction of recording error bursts automatically without loss of user data.

Rotation speeds have increased from 1800 revolutions per minute to 7200 to 10800 revolutions per minute today. When the faster rotational speed and the higher linear density of data along a track are both considered, data transfer speeds have improved from under 100 thousand bytes per second to over 10 million bytes per second.

For manufacturing and other efficiencies, there are generally several recording heads moved by a single actuator mechanism. In some early disk subsystems (IBM 305, 1301, 2311, 2314, for example), the principal motive mechanism was hydraulically powered. Later devices use electromagnetic voice coil motors.

There will be a group of arms with the heads mounted on them, in a comb-like manner, so that the arms can be moved between the rotating platters. Each head can read one track at any given radial position, and as there is one head for each recording surface, all of the tracks that can be accessed without moving the arm-head comb assembly are referred to as a cylinder.

When the arm-head comb assembly is moves, the device is said to seek to the desired radial position. Years ago, average seek times could be quite lengthy -- on the order of tenths of a second or more, but today most seek operations are on the order of a few milliseconds.

Data on the disk track is recorded in one of several ways. Logically, most current disk subsystems use either Count-Key-Data (CKD) or Extended Count-Key-Data (ECKD) format, or Fixed-Block Architecture (FBA) format.

CKD/ECKD Formats

CKD and ECKD tracks store a variable number of records of a variable size. Each track begins with a special record called a Home Address (HA) record, and this is followed by a Record Zero (R0) record. These two records are special and used by the hardware and the operating system and access method software to keep track of track position and remaining capacity. R0 is followed by one or more user data records, normally numbered R1 through Rn, where the maximum number of records recorded on the track depends on device characteristics and the length of the recorded records.

Each data record recorded on the track contains a number of fields:

Address Marker

Used by the hardware to indicate the begininning of a new record on the track.

Count Area

Used by the hardware to identify the specific record (its record number), and the length of the key and data areas. The length of the key area can be zero. If the length of the data area is also zero, then this record represents a hardware end-of-file record.

Key Area (optional)

Used by the hardware to identify a record by a character string value, which permits the hardware to search for the record by the contents of this field. This area was extensively used in the old Indexed Sequential Access Method (ISAM) which VSAM effectively replaced in the early 1970s. Key areas are also used in Volume-Table-of-Contents (VTOC) files which map file ids to disk location, and in the System Label Area, used by the operating system to store disk file information for subsequent use during the processing of file open requests. VSAM files do not use the key area -- it has a length of zero for all records in all VSAM files.

Data Area

This component of a disk record actually contains the user data. As indicated above, each data area can be a different length, but VSAM will use a fixed length for all the records used in a data component -- a different fixed length may be used for all the records used in an index component as well. This choice of fixed length records permits VSAM to calculate the rotational position where any record being read or written will begin on the disk track, in turn permitting more efficient use of other system resources, such as channel paths.

In modern disk subsystems (introduced by IBM in the last 20 years or so), each of these physical record fields contains the same kind of error checking structures used to protect user data, so that even in the event of a burst of errors, it is most likely that the system and user data written on the disk will be protected.

FBA Formats

The FBA format was introduced in the late 1970s as a simpler architecture. All blocks of data on a disk were of the same (512 bytes plus control and check fields) length, and the were addressed by their relative position on the disk. Applications could specify that they wanted to write or read some whole number of blocks beginning with a particular block number -- no specification of the cylinder position or track number was required, as the disk device itself made all the necessary computations to locate the desired record position on the disk.

The intent of this concept was to make application programming, disk space management, and access method programming and maintenance much simpler and more reliable. FBA disks were supported by DOS/VSE (now VSE/ESA) and VM (now zVM) operating systems, but support for this disk architecture was never added to the MVS (now zOS) operating system.

Because of the simplicity of this architecture, when VSE/ESA and VM/ESA added support for virtual disks (a way to use system storage to contain very frequently needed data -- data whose retrieval speed was critical) the virtual disks were implementations that simulated FBA disks. Both the work needed to create the channel programs used by the application to request the data and the work needed by the virtual disk to interpret that channel program were significantly reduced, saving a lot of overhead. In addition, the access method programming used by the application program to generate its channel programs already existed and needed no changes.

While FBA formats have some similarities to the 512-byte sector sizes used on PC disks, they had significant differences.

File Systems...

There's much more to this ... IBM hardware and software documentation can provide you with all you need to know in great detail.