Count Key Data
Count Key Data (CKD) is a DASD data architecture. Each physical disk record consists of a count field, an optional key field, and a ("user") data field with error correction/detection information appended to each field and gaps separating each field. 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.
The principle behind the architecture is that since data record lengths can vary, they all have an associated count field which indicates the size of the key if used and the size of the data. The count field has the identification of the physical location 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. Most often the key is omitted, the record located sequentially or by direct cylinder-head-record addressing. If it is present, the key is typically a copy of the first n bytes of the data record (for "unblocked" records, or a copy of the highest key in the block, for "blocked" records) but can be any data which will be 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 Architecture. Compare to Fixed Block Architecture (FBA).
The advantages of Count Key Data architecture are:
- The record size can be exactly matched to the application block size
- CPU and memory requirements can be reduced by exploiting search-key commands.
- IBM CKD devices operate 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.
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 flagship operating system z/OS does not support sector-oriented interfaces.
Extended Count Key Data (ECKD) refers to the CCW commands used with cached controllers for IBM DASD. The new commands were introduced on the cached versions of the IBM 3880 DASD controller and were extended on the IBM 3990 DASD controller (and their compatibles from Amdahl, EMC and others). The ECKD channel commands provide improved performance for the legacy IBM OEMI (Bus & Tag) parallel interface, ESCON (or Enterprise Systems Connection) interface or the newer FICON (Fiber Connectivity) protocol. ECKD allows the programmer to provide the control unit with information on intent and to perform operations in a simpler channel program (Define Extent and Locate Record) that would require multiple channel commands (and looping) with CKD (Seek, Set File Mask, Search ID Equal, Transfer-in-Channel back to the Search ID equal, etcetera), thereby greatly reducing I/O channel overhead. Define Extent/Locate Record is represented by a Format 1 CCW string, whereas Search ID Equal, etcetera, is represented by a Format 0 CCW string. Additionally, Format 1 CCWs are defined for 31 bit memory addresses, whereas Format 0 CCWs are limited to 24 bit memory addresses.
- Systems Reference Library, IBM System/360 Component Description, circa 1966, Track Format, p.3-7 ,
IBM 3390 Direct Access Storage Introduction, GC26-4573-03, May 1993, Chapter 2, Count-Key-Data Record Format
- Count key data, IBM infocenter
- Houtekamer, Gilbert E. and Artis, H. Pat, MVS I/O Subsystems, McGraw-Hill 1991, ISBN 0-07-002553-3
- Introduction to Nonsynchronous Direct Access Storage Subsystems, IBM GC46-4519-0, January 1990, Chapter 2, Synchronous DASD Operations
- Volume table of contents (VTOC)
- IBM Corporation (1974). Introduction to IBM Direct-Access Storage Devices and Organization Methods (GC20-1649).