Count key data

IBM
Industry	Computer hardware
Founded	June 16, 1911; 115 years ago in Endicott, New York, United States
Products	Mainframe computers, DASD (direct-access storage devices), CKD (Count Key Data) format
Website	www.ibm.com

Count key data (CKD) is a data recording format for direct-access storage device (DASD) technology, first introduced by IBM in 1964 alongside the IBM System/360. This format remains emulated on IBM mainframe systems today. CKD is characterized as a self-describing structure where each data record contains a Count Area that identifies the record and defines the lengths of optional Key and Data Areas, differing from devices with fixed sector sizes.

The term CKD also denotes the collection of channel commands (Channel Command Words, CCWs) employed by IBM mainframes to interface with DASD subsystems utilizing the CKD format. These original CKD CCWs, developed in 1964, underwent progressive enhancements through the 1990s.

CKD track format

The CKD track layout supports variable-length fields for data storage. Each data block recorded on a DASD track—termed a record—includes a count field that both identifies the record and specifies the size of its key area (which can be user-defined up to 255 bytes) and data area. The count field employs cylinder-head-record addressing and may either exclude the key or incorporate a character string.

Tracks commence with an index marker detected by sensing equipment, succeeded by a home address that provides track location details and control metadata. This is followed by a fixed-length gap and then Record 0 (R0), which serves as the track descriptor record designed to facilitate relocation if sections of the track become defective. Subsequent data records are interspersed with gaps.

Because of these gaps and control fields, the utilized space on a track surpasses just the sum of count, key, or user data areas. IBM supplies reference cards for each device model to assist in calculating the number of records per track for various field dimensions, optimizing device utilization. Later, software tools were developed to automate these computations. Selecting incorrect record sizes can lead to issues since records typically do not span multiple tracks.

In most cases, keys are omitted; records are accessed sequentially or via cylinder-head-record addressing. When keys are present, they facilitate record retrieval using Search Key Equal or Search Key High or Equal CCWs, enabling direct hardware-level access. Since the debut of IBM System/360, virtually all IBM large-scale and midrange system DASDs have employed the CKD format.

Key benefits of CKD include:

Precise alignment of record size with application data blocks
Decreased CPU and memory consumption through utilization of search-key commands
Initially designed for synchronous operation with system channels to improve performance by processing data during gaps; later subsystems support both synchronous and asynchronous modes

Although improvements in CPU speed, memory capacity, and device performance have diminished some advantages of CKD, it remains prevalent because IBM’s flagship operating system z/OS does not support sector-based interfaces.

Originally, each CKD record corresponded directly to a physical DASD track; modern IBM mainframes have virtualized these records without maintaining strict physical track equivalence.

Packaging

Early logical representations of DASD access closely mirrored physical hardware configurations, using three-digit identifiers for channel, control unit, and device addresses.

On entry-level systems, Channel and Control Unit components were often physically combined but logically distinct. Starting with the 3830 Model 2 in 1972, IBM’s New Attachment Strategy physically separated the Storage Control Unit (SCU) into a director and controller while preserving logical integration. The controller oversees CKD track formatting and is packaged alongside the initial drive(s) in a string, referred to as an "A-Unit" (for instance, a 3350 Model A2 containing a controller plus two DASDs). Drives lacking controllers are termed B-Units and carry a "B" prefix.

IBM and plug-compatible vendors offered CKD subsystems and directors through at least 1996 (covering models from 2301 up to 3390 Model 9). IBM produced 22 distinct DASDs arranged into over 35 subsystem configurations. Plug-compatible manufacturers supplied many of these configurations as well as four unique CKD subsystems: double density 2314, triple density 3330, double density 3350, and solid state disk variants.

Programming

On IBM mainframes, access to input/output devices is governed by Channel Command Words (CCWs). While some CCWs serve general purposes (such as No Operation), many are tailored to specific devices. For DASD, CCWs are categorized into five main types:

Control — overseeing the DASD and its communication path
Sense — retrieving status information; certain commands like RESERVE or RELEASE modify the controller or DASD state similarly to control commands
Write — transferring data to the controller or DASD, potentially using buffering
Search — comparing data from the CPU against DASD contents; involves channel writes concurrent with storage reads
Read — extracting data from DASD, which may also be buffered

CKD CCWs are designed specifically for CKD DASD subsystems and differ from fixed block architecture (FBA) CCWs that operate with FBA DASDs.

CKD DASDs are addressed in a manner consistent with other I/O devices. System/360 and System/370 systems directly address them via channels and control units using three hexadecimal digits—one digit for the channel and two for the control unit/device—allowing up to 16 channels, 256 DASDs per channel, and a total of 4,096 addresses. Contemporary mainframes employ four hexadecimal digits as subchannel identifiers within subsets of the channel subsystem, enabling addressing of as many as 65,536 DASDs per subset. Despite this theoretical capacity, physical limitations restrict the actual number of attachable DASDs.

Initial CKD feature set

When IBM introduced the CKD track format in 1964, it included essential capabilities along with 41 Channel Command Words (CCWs) that supported sophisticated disk operations:

Defective/Alternative Track functionality provides automatic substitution for defective tracks.
Record overflow permits writing record segments that span multiple tracks, circumventing single-track length restrictions.
Multitrack operations allow CCWs to continue sequentially across heads within a single cylinder.
Command chaining facilitates complex channel programs that efficiently locate and retrieve data while minimizing CPU involvement. Initially synchronous, this feature was later expanded to include nonsynchronous modes.
Channel switching enables a Storage Control Unit (SCU) to be shared among multiple channels—starting with two channels and eventually supporting up to eight—across one or more CPUs.

A Scan feature set was once offered but was discontinued following the IBM 2314 subsystem.

The set of 41 CCWs encompasses control, sense, search, read, and write instructions applicable to various IBM DASD devices including the 2301 Drum, 2302 Disk Storage, 2303 Disk Drive (which replaced the slower 7320 Drum), 2311 Disk Drive, 2321 Data Cell, and the 2314 series of storage controls. These CCWs were executed by SCUs connected to high-speed Selector Channels. Initially, the 2820 SCU managed the 2301 Drum, whereas the 2841 SCU handled devices such as the 2302 and 2311. Later versions incorporated integrated attachments for System/370 models.

An example channel program designed to read a disk record by key is as follows:

  SEEK             <cylinder/head number>
  SEARCH KEY EQUAL <key value>
  TIC              *-8 Back to search if not equal
  READ DATA        <buffer>

The TIC (Transfer In Channel) command creates a loop that continues searching until either a matching key is found or the end of the track is reached. When a match occurs, the SCU instructs the channel to bypass TIC and proceed directly to READ DATA, thereby streamlining data retrieval.

Block multiplexer channel improvements

The block multiplexer channel debuted in 1971 on advanced System/360 models, introduced alongside the 2835 Control Unit and 2305 DASD. It subsequently became a standard feature on IBM System/370 and later mainframe generations, delivering substantial performance gains compared to the earlier Selector channel, especially for high-speed peripherals such as DASD. Key enhancements included:

Concurrent Requests

This capability allowed multiple channel programs to operate simultaneously—up to eight for a single disk drive and sixteen on the same SCU—unlike the Selector channel which restricted activity to one at a time. The exact number of supported subchannels depends on the specific system model and setup. Termed disconnected command chaining, this functionality permits the control unit to disconnect during a sequence of chained CCWs (for example, during a Seek operation), thereby freeing the channel to serve other subchannels.

Command Retry Mechanism

In certain scenarios, the channel and storage control can automatically retry a CCW without triggering an I/O interruption. This retry process is initiated by the storage control unit to recover from correctable errors.

Rotational Position Sensing

Implemented through two additional CCWs, SET SECTOR and READ SECTOR, rotational position sensing (RPS) allows delaying the chaining of commands until the disk reaches a specific angular position on the track. This feature enables the channel to disconnect during most of the rotational latency, improving channel efficiency. The control unit achieves RPS by dividing each track into equal angular segments.

Sample Channel Program

The following example illustrates formatting a track with an R0 record followed by three CKD records:

  SEEK             <cylinder/head number>
  SET FILE MASK    <enable write permissions>
  SET SECTOR       <sector number=0>
  WRITE R0         <cylinder/head/R0, key length=0, data length=6>
  WRITE CKD        <cylinder/head/R1, key length, data length>
  WRITE CKD        <cylinder/head/R2, key length, data length>
  WRITE CKD        <cylinder/head/R3, key length, data length>

With a block multiplexer channel, the channel remains available during DASD seeking and while waiting for disk rotation to reach the start of the track. By contrast, a selector channel stays occupied throughout these operations.

Defect skipping

Defect skipping allows data to be recorded around one or more surface defects on a disk track, enabling nearly full utilization of the track except for the damaged areas. This approach avoids seeking alternative tracks; however, since only a limited number of defects can be bypassed this way, alternate tracks are still reserved for those with excessive defects.

This capability was introduced in 1974 with the 3340 DASD using the 3830 Model 2 Storage Control Unit or integrated attachments on smaller systems. Initially available only through factory installation, defect skipping became accessible via CCWs and management utilities starting in 1981.

Dynamic paths

Dynamic path selection was first implemented in 1981 with the 3380 DASD connected through the 3880 Storage Control Unit. It facilitates operation of dual controllers by allowing simultaneous data transfers over two communication paths. Supported by operating system software, each controller can serve as a backup if its counterpart becomes unavailable.

Three commands—Set Path Group ID, Sense Path Group ID, and Suspend Multipath Reconnection—enable attachment of dual-controller 3380 devices at the head of a device string. The Set Path Group ID command grants access across any path within an assigned group. On 370-XA systems with multipath mode activated, block multiplex reconnections automatically occur using the first free path within that group regardless of device reservation status.

If the preferred controller is busy or disabled, dynamic path selection reroutes operations through an alternate path via another storage director and controller.

Nonsynchronous Operation

Prior to the 1981 debut of the 3880 director, access to CKD records was strictly synchronous, necessitating the completion of one CCW before starting the next within predetermined inter-field intervals. Although this restricted cable length, it allowed for high throughput by minimizing CPU involvement in managing complex CCW sequences.

Nonsynchronous operation, enabled through Extended CKD (ECKD) CCWs, eliminated these timing restrictions. The five additional ECKD commands include Define Extent, Locate Record, Write Update Data, Write Update Key and Data, and Write CKD Next Track.

In nonsynchronous mode, the data flow between the channel and storage control is separated from the transfer between storage control and the device. An intermediate buffer facilitates channel programs running without waiting for inter-record gaps, supporting extended cable lengths and potentially enhancing performance depending on workload characteristics.

All subsequent CKD subsystems provide support for ECKD CCWs.

An example nonsynchronous channel program that reads records R1 and R2 from track X'0E' in cylinder X'007F', each containing an 8-byte key and 100 bytes of data:

  Define Extent       <extent= X'007F 0000' through track X'0081 000E'>
  Locate Record       <cylinder = X'007F', head = X'000E'>
  Read Key and Data   <key record = X'001038'>
  Read Data           <record = X'001108'>

Caching

The concept of caching was initially introduced in S/370 DASD CKD subsystems by Memorex in 1978 and StorageTek in 1981. IBM subsequently implemented caching with the Speed Matching Buffer (SMB) on the 3880 Models 2 and 3 to enable connection of 3375 and 3380 drives to slower channels. Formal caching support arrived in late 1981 with the 3880 Model 13, targeting 3380 devices featuring dynamic pathing.

Cache management relies on a dynamic algorithm that prioritizes frequently accessed data for retrieval from high-speed cache memory, while less active data remains stored on cost-effective DASD media. The Director unit houses a substantial memory cache divided into track-sized slots holding data from 3380 tracks, supported by a directory structure that maps cached data locations.

Caching functionality was incorporated into later storage control units as well.

Additional Enhancements

Over time, various path control, diagnostic, and error recovery CCWs were introduced into storage controls, including:

Unconditional Reserve: allows a channel to release a device reserved by another channel and immediately reserve it for itself.
Read Multiple Count Key Data: enhances efficiency by reading entire tracks at once, accelerating backup operations.

Post-System/370 Developments

With decreasing costs of CPUs and memory combined with faster hardware and interfaces, the performance benefits of CKD have diminished. Nevertheless, IBM maintains CKD support because its premier z/OS operating system depends on CKD CCWs.

Initially, each CKD record directly corresponded to a physical DASD track; nowadays, records are virtualized. Modern IBM mainframes generate CKD track images within memory and execute ECKD/CKD channel programs against these images. To communicate with native fixed-block disk devices, these virtual track representations are mapped onto fixed blocks compatible with FBA disk subsystems.

Of the original 83 CKD CCWs designed for System/360 and System/370 channels, 56 continue to be emulated on System/390 and subsequent platforms.