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.
Count key data (CKD) also refers to the set of channel commands (collectively Channel Command Words, CCWs) that are generated by an IBM mainframe for execution by a DASD subsystem employing the CKD recording format. The initial set of CKD CCWs, introduced in 1964, was substantially enhanced and improved into the 1990s.
CKD track format
The reason for CKD track format is to allow data field lengths to vary, each recorded block of data on a DASD track, called a record has an associated count field which identifies the record and indicates the size of the key, if used (user-defined up to 255 bytes), and the size of the data area, if used. The count field has the identification of the record in cylinder-head-record format, the length of the key, and the length of the data. The key may be omitted or consist of a string of characters.
"The beginning of a track is signalled when the index marker (index point) is detected. ... The marker is automatically recognized by a special sensing device." Following the index marker is the home address, which indicates the location of this track on the disk, and contains other control information internal to the control unit. A fixed-length gap follows the home address. Next, each track contains a Record 0 (R0), the track descriptor record, which is "designed to enable the entire content of a track to be moved to alternate tracks if a portion of the primary track becomes defective." Following R0 are the data records, separated by gaps.
Because of the gaps and other information, the recorded space is larger than that required for just the count data, key data, or user data. IBM provides a "reference card" for each device, which can be used to compute the number of records per track for various key and data field sizes, and to optimize the capacity of the device. Later, programs were written to do these calculations. Because records are normally not split between tracks, specification of an incorrect record size create problems.
Most often, the key is omitted and the record is located sequentially or by direct cylinder-head-record addressing. If it is present, the key is any data used to find the record, usually using the Search Key Equal or Search Key High or Equal CCW. The key (and hence the record) is locatable via hardware commands. Since the introduction of IBM's System/360 in 1964, nearly all IBM large and intermediate system DASDs have used the count key data record format.
The advantages of count key data record format are:
The record size can be exactly matched to the application data block sizes CPU and memory requirements can be reduced by exploiting search-key commands. IBM CKD subsystems initially operated synchronously with the system channel and can process information in the gaps between the various fields, thereby achieving higher performance by avoiding the redundant transfer of information to the host. Both synchronous and asynchronous operations are supported on later subsystems.
Reduced CPU and memory prices and higher device and interface speeds have somewhat nullified the advantages of CKD, and it is retained only because IBM's z/OS operating system does not fully support sector-oriented interfaces.
Originally CKD records had a one-to-one correspondence to a physical track of a DASD device; however over time the records have become more and more virtualized such that in modern IBM mainframes there is no longer a direct correspondence between a CKD record ID and the physical layout of a track.
IBM's CKD DASD subsystems Packaging
Initially there was a high degree of correspondence between the logical view of DASD accesses and the actual hardware, as shown in the illustration. Three digit labels were typically affixed to identify the address of channel, control unit and device.
On low end systems the Channel and the Control Unit were frequently physically integrated but remained logically separate. IBM's New Attachment Strategy beginning with the 3830 Model 2 in 1972 physically separated the SCU into two physical entities, a director and a controller while keeping them logically the same. The controller handles the CKD track formatting and is packaged with the first drive or drives in a string of drives and having a model number with the letter "A" as a prefix, an "A-Unit" (or "A-Box") as in 3350 Model A2 containing a controller and two DASDs. DASD without a controller, that is B-Units, have a "B" prefix in their model number.
CKD subsystems and directors were offered by IBM and plug compatible competitors until at least 1996 (2301 to 3390 Model 9); in total 22 unique DASD offered by IBM configured in at least 35 different subsystem configurations. Plug-compatible offered many of the same DASD including 4 CKD subsystems featuring unique DASD.
Programming Access to specific classes of I/O devices by an IBM mainframe is under the control of Channel Command Words (CCWs), some of which are generic (e.g. No Operation) but many of which are specific to the type of I/O device (e.g. Read Backwards for a tape drive). The group of CCWs defined by IBM for DASD fall into five broad categories:
Control control of the DASD including the path thereto Sense sense status of the DASD including the path thereto; some sense commands affect the status of the controller and DASD in a fashion more in keeping with a control command, e.g., RESERVE, RELEASE Write write information to the controller or DASD (which may be buffered or cached in the path) Search compare information from the CPU with information stored in the DASD; the Channel operates in the Write mode while the storage unit operates in the Read mode. Read read information from the DASD (which may be buffered or cached in the path)
CKD CCWs are the specific set of CCWs used to access CKD DASD subsystems. This is in contrast to fixed block architecture (FBA) CCWs which are used to access FBA DASD subsystems.
CKD DASD are addressed like other Input/Output devices; for System/360 and System/370 DASD are addressed directly, through channels and the associated control units (SCU or Storage Control Unit), initially using three hexadecimal digits, one for channel and two for control unit and device, providing addressing for up to 16 channels, for up to 256 DASD access mechanisms/channel and 4,096 DASD addresses total. Modern IBM mainframes use four hexadecimal digits as an arbitrary subchannel number within a channel subsystem subset, whose definition includes the actual channels, control units and device, providing addressing for up to 65,536 DASD per channel subsystem subset. In practice, physical and design constraints of the channel and of the controllers limited the maximum number of attached DASD attachable to a system to a smaller amount than the number that could be addressed.
Block size determination One aspect of systems design was determining optimal block (physical record) sizes for datasets, although "optimal" was often a trade-off between disk and main storage usage. DASD device capacity was described by a table on a pocket-sized reference card for a specific device. Here is an example for a 2311-1 + DASD Capacity and Transmission Time Bytes per Recordmin–max Records pertrack–cylinder–module Transmission time (msec)min–max 5–6 42–420–84000 0.03–0.04 7–8 41–410–82000 0.04–0.05 ... ... ... 812–1111 3–30–6000 5.21–7.12 1112–1720 2–20–4000 7.13–11.03 1721–3605 1–10–2000 11.03–23.11
Any space on a track too small to fit a complete block was normally wasted. Using 6-byte blocks, a track could hold 42×6 or 252 bytes, while with 3605-byte records (full track blocking) the track could hold 3605 bytes. On the other hand, a 1721-byte record was still written one-per-track. Optimum disk utilization was achieved by using a block size with a whole number of records as close as possible to but less than 1720 or 3605 bytes (half- or full-track). However, this had to be balanced with main storage usage, since a program with a number of open files would need buffer space for one or two blocks per file.
This chart described records without keys. Since keys required an additional gap on disk, a separate chart was used.
Programs were written that accepted the required record size and device type as input and computed optimum block sizes.
Initial CKD feature set The initial feature set provided by IBM with its 1964 introduction of the CKD track format and associated CCWs included: .
Defective/Alternative Track enables an alternate track to replace a defective track transparent to the access method in use. Record overflow AKA track overflow The Write Special Count, Key and Data CCW can write a record segment that is logically part of a record segment on the next track. While an individual record segment can not exceed the maximum track length of a DASD track, a sequence of record segments is not so limited.
Multitrack operations specific CCWs can continue onto the next sequential tracks up to the end of the cylinder. Command chaining CCWs could be chained together to construct complex channel programs. The gaps in a CKD track format provided sufficient time between the commands so that all channel and SCU activity necessary to complete a command can be performed in the a gap between appropriate fields. Such programs can search a large amount of information stored on a DASD, upon successful completion returning only the desired data and thereby freeing CPU resources for other activity. This mode of operating synchronous to the gap was later enhanced by additional CCWs enabling a nonsynchronous mode of operation. Data chaining when the current CCW has read or written the specified number of bytes, data chaining "causes the storage area of the next CCW to be used with the current I/O operation. The use of data chaining allows data to be transferred to or from noncontiguous areas of storage in a single I/O operation." Channel switching an SCU can be shared between channels initially two channel switching was provided and it was expanded to up to eight channels in later SCUs. The channels can be on the same or different CPUS.
A Scan feature set was also provided but not continued into future CKD subsystems beyond the 2314.
Forty one CCWs implemented the feature set: