Count key data

Count key data (CKD) is a direct-access storage device (DASD)[lower-alpha 1] 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.[1] The initial set of CKD CCWs introduced in 1964 was substantially enhanced and improved into the 1990s.

CKD Track Format

Block diagram of count key data track format used on IBM mainframe computers beginning with S/360 shipment in 1965

The principle of CKD records is that since data record lengths can vary, they all have 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.[2][lower-alpha 2] The count field has the identification of the record[lower-alpha 3] 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.

Each CKD record consists of a count field, an optional key field, and an optional[lower-alpha 4] "user" data field with error correction/detection information appended to each field and gaps separating each field.[3][4] 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.

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.[5] 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.[6]

The advantages of count key data record format are:

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.

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 the a CKD record ID and a physical layout of a track.

IBM's CKD DASD subsystems

IBM S/360 & S/370 Input/Output operations for CKD DASD showing channel, storage control unit and DASD device

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:

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[7][8][9] (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 hexidecimal 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 subsytem 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.

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 above. Three digit labels were typically affixed[lower-alpha 6] 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[10] beginning with the 3380 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(s) 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[lower-alpha 7] and directors were offered by IBM and plug compatible competitors until at least 1996 (2301 to 3390 Model 9);[11] in total 22 unique[lower-alpha 8] 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.[lower-alpha 9]

Initial CKD feature set

The initial feature set provided by IBM with its 1964 introduction of the CKD track format and associated CCWs included: .

A Scan feature set was also provided but not continued into future CKD subsystems beyond the 2314.

Forty one CCWs implemented the feature set:

IBM S/360 DASD Channel Commands[14]
Command Class Command‡ 2301[15] 2302[3] 2303[3]
7320[16][lower-alpha 10]		 2311[3] 2321[3] 2314
2319[17]		 MT
Off		 MT
On †		 Count Length
ControlNo OpSSSSSS03
SeekSSSSSS076
Seek CylinderSSSSSS0B6
Seek HeadSSSSSS1B6
Set File MaskSSSSSS1F1
Space CountSSSSSS0F3
RecalibrateSS13Not zero
RestoreS17Not zero
SenseSense I/OSSSSSS046
Release DeviceOOOOOO946
Reserve DeviceOOOOOOB46
SearchHome Address EQSSSSSS39B94 (usually)
Identifier EQSSSSSS31B15 (usually)
Identifier HISSSSSS51D15 (usually)
Identifier EQ or HISSSSSS71FI5 (usually)
Key EQSSSSSS29A91 to 255
Key HISSSSSS49C91 to 255
Key EQ or HISSSSSS69E91 to 255
Key & Data EQO OOS2DADSee Note 2
Key & Data HIO OOS4DCDSee Note 2
Key & Data EQ or HIO OOS6DEDSee Note 2
Continue Scan
(see Note 1)  		Search EQO OOS25A5See Note 2
Search HIO OOS45C5See Note 2
Search HI or EQO OOS65E5See Note 2
Set CompareO OOS35B5See Note 2
Set CompareO OOS75F5See Note 2
No CompareO OOS55D5See Note 2
ReadHome AddressSSSSSS1A9A5
CountSSSSSS12928
Record 0SSSSSS1696Number of bytes transferred
DataSSSSSS0686
Key & DataSSSSSS0E8E
Count. Key & DataSSSSSS1E9E
IPLSSSSSS02
WriteHome AddressSSSSSS195 (usually)
Record 0SSSSSS158*KL*DL of RO
Count, Key & DataSSSSSS1D8+KL+DL
Special Count, Key & DataSSSSSS018+KL+DL
DataSSSSS05DL
Key & DataSSSSSS0DKL*DL
EraseSSSSSS118*KL*DL
Total CCWs41303930404040

Notes:

O = optional feature
S = standard feature
MT = multitrack: when supported CCW will continue to operate on next heads in sequence to end of cylinder
‡ = TIC (Transfer In Channel) and other standard commands not shown.
† = code same as MT Off except as listed
1. File Scan Feature (9 CCWs) only available on 2841 for 2302, 2311 and 2321; they were not available on subsequent DASD controllers for DASD later than 2314.
2. Count is number of bytes in search argument, including mask bytes

The CCWs were initially were executed by two types of SCU attached to the system's high speed Selector Channels. The 2820 SCU[15] controlled the 2301 Drum while the 2841 SCU[3] controlled combinations of the 2302 Disk Storage, 2311 Disk Drive, 2321 Data Cell and/or 7320 Drum Storage. IBM quickly replaced the 7320 with the faster and larger 2303.

Subsequently, the feature set was implemented on the 2314 family of storage controls and an integrated attachment of the System 370 Model 25.

The following example of a channel program[17] reads a disk record identified by a Key field. The track containing the record and the desired value of the key is known. The SCU will search the track to find the requested record. In this example <> indicate that the channel program contains the storage address of the specified field.

  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) will cause the channel program to branch to the SEARCH command until a record with a matching key (or the end of the track) is encountered. When a record with a matching key is found the SCU will include Status Modifier in the channel status, causing the channel to skip the TIC CCW; thus the channel program will not branch and the channel will execute the READ command.

Block Multiplexer Channel Enhancements

The block multiplexor channel was introduced beginning in 1971 on some high end System/360 systems along with the 2835 Control Unit and associated 2305 DASD,[18] This channel was then standard on IBM System/370 and subsequent mainframes; when contrasted to the prior Selector channel it offered performance improvements for high speed devices such as DASD, including:

Multiple Requesting

Allowed multiple channel programs,[lower-alpha 11] to be simultaneously active in the facility[18] as opposed to only one with a Selector channel. The actual number of subchannels provided depends upon the system model and its configuration.[19] Sometimes described as disconnected command chaining, the control unit could disconnect at various times during a chained set of CCWs, for example, disconnection for a Seek CCW, freeing the channel for another subchannel.

Command Retry

The channel and storage control under certain conditions can inter-operate to cause a CCW to be retried without an I/O interruption.[18] This procedure is initiated by the storage control and used to recover from correctable errors.

Rotational Position Sensing

Rotational position sensing (RPS) was implemented with two new CCWs, SET SECTOR and READ SECTOR enabled the channel to delay command chaining until the disk rotated to a specified angular track position. RPS permits channel disconnection during most of the rotational delay period and thus contributes to increased channel utilization. The control unit implements RPS by dividing each track into equal angular segments.[18]

Example Channel Program

The following example channel program will format a track with an R0 and three CKD records.[18]

  SEEK             <cylinder/head number>
  SET FILE MASK    <allow write operations>
  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>

In this example the Record 0 conforms to IBM programming standards. With a block multiplexer channel the channel is free during the time the DASD is seeking and again while the disk rotates to beginning of the track. A selector channel would be busy for the entire duration of this sample program.

Defect skipping

Defect skipping allows data to be written before and after one of more surface defects[lower-alpha 12] allowing all of a track to be used except for that portion that has the defect. This also eliminates the time that was formerly required to seek to an alternate track.[20] Only a limited number of defects could be skipped so alternate tracks remained supported for those tracks with excess defects.

Defect skipping was introduced in 1974 with the 3340 attached via the 3830 Model 2 Storage Control Unit[20] or integrated attachments on small systems. Defect skipping was essentially a factory only feature until 1981 when CCWs for management along with associated utilities were released.[21]

Dynamic paths

First introduced with the 3380 DASD on the 3880 Storage Control Unit[22] in 1981 the feature was included with the later CKD DASD subsystems. The dynamic path selection function controls operation of the two controllers, including simultaneous data transfer over the two paths. When supported by the operating system, each controller can serve as an alternate path in the event the other controller is unavailable.[23]

Three additional commands, Set Path Group ID, Sense Path Group ID, and Suspend Multipath Reconnection, are used to support attachment of the 3380 Models havaing two controllers at the head of a string.[22]

The Set Path Group ID command, with the dynamic path selection (DPS) function, provides greater flexibility in operations on reserved devices. Once a path group for a device has been established, it may be accessed over any path which is a member of the group to which it is reserved. In addition, on 370-XA systems which set the multipath mode bit in the function control byte (byte 0) to a 1, block multiplex reconnections will occur on the first available path which is a member of the group over which the channel program was initiated (regardless of the reservation state of the device).[22]

If the controller designated in the I/O address is busy or disabled, the dynamic path selection allows an alternate path to the device to be established via another storage director and the other controller in the model AA.[23]

Nonsynchronous operation

Prior to the 1981 introduction of the 3880 director, CKD records were synchronously accessed, all activities required to end one CCW and initiate the next occurred in the gaps between the CKD fields.[12] This placed limitations on gap size and cable length but did provide for very high performance since complex chains of CCWs could be performed by the subsystem in real time without use of CPU memory or cycles.

Nonsynchronous operation provided by the Extended CKD ("ECKD") set of CCWs removed the gap timing constraint[12] The five additional ECKD CCWs are Locate Record, Define Extent, Write Update Data, Write Update Key and Data, and Write CKD Next Track.[22]

In nonsynchronous operation, the transfer of data between the channel and the storage control is not synchronized with the transfer of data between the storage control and the device. Channel programs can be executed such that channel and storage control activities required to end execution of one command and advance to the next do not have to occur during the inter-record gap between two adjacent fields. An intermediate buffer in the storage control allows independent operations between the channel and the device. A major advantage of ECKDs is far longer cables; depending upon application it may improve performance.[12]

ECKD CCWs are supported on all subsequent CKD subsystems.

This example nonsynchronous channel program reads records R1 and R2 from track X'OE' in cylinder X'007F'. Both records have a key length of 8 and a data length of X'64' (10010) bytes.[22]

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

Caching

Caching first introduced in DASD CKD subsystems by Memorex[24] (1978) and StorageTek[lower-alpha 13] (1981) was subsequently introduced in late 1981 by IBM on the 3880 Model 13 for models of the 3380 with dynamic pathing.[lower-alpha 14]

The cache is dynamically managed by an algorithm; high activity data is accessed from the high-performance cache and low activity data is accessed from less-expensive DASD storage. A large memory in the Director, the cache, is divided into track slots that store data from the 3380 tracks. A smaller area is a directory that contains entries that allow data to be located in the cache.[25]

Caches were also provided on subsequently introduced storage controls.

Other extensions

Over time a number of path control, diagnostic and/or error recovery CCWs were implemented on one or more storage controls. For example:

Beyond System/370

Reduced CPU and memory prices and higher device and interface speeds have somewhat nullified the advantages of CKD, and support continues by IBM to this date because its flagship operating system z/OS continues to use CKD CCWs for many functions.

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 a modern IBM mainframe there is no longer a direct correspondence between the a CKD record ID and a physical layout of a track. An IBM mainframe constructs CKD track images in memory and executes the ECKD and CKD channel programs against the image. To bridge between the native fixed block sized disks and the variable length ECKD/CKD record format, the CKD track images in memory are mapped onto a series of fixed blocks suitable for transfer to and from an FBA disk subsystem.[26]

Of the 83 CKD CCWs implemented for System/360 and System/370 channels 56 are emulated on System/390 and later systems.[26]

See also

Notes

  1. ↑ Most commonly a hard disk drive.
  2. ↑ data length 0 indicates EOF
  3. ↑ Because records are variable length and because the record number on the track need not be unique, the record number does not correspond to an angular displacement.
  4. ↑ A record with a zero data length is an EOF record and reading it causes a Unit Exception.
  5. ↑ Technically writes
  6. ↑ In some early DASD the label was on a plug which allowed the address to be moved between DASD
  7. ↑ That is the combination of an SCU and one or more DASDs or an A-Unit with any attached B-Units.
  8. ↑ A unique combination of number of tracks and maximum track length. With this definition a double density DASD counts as a unique DASD.
  9. ↑ double density 2314, triple density 3330, double density 3350 and solid state disk
  10. ↑ The 2302 replaced the 7230. Datamation, March 1966, p. 81
  11. ↑ In the case of the 2305, up to 8 channel programs for the same disk drive and 16 on the same SCU
  12. ↑ Number of skippable defects varies by DASD model
  13. ↑ STK 8890 CyberCache for STK 3350 compatibles
  14. ↑ Simultaneously announced was the 3880-11 using its cache in a paging mode 3350s as paging devices

References

  1. ↑ IBM 3990 Storage Control Introduction – 6th Ed., IBM Corp, GA32-0098-05 February 1994
  2. ↑ "Count key data". IBM Knowledge Center. International Business Machines Corporation. Retrieved 6 August 2014.
  3. 1 2 3 4 5 6 7 8 IBM System/360 Component Descriptions - 2841 and Associated DASD (PDF). Eighth Edition. IBM. December 1969. GA26-5988-7.
  4. ↑ "Count-Key-Data Record Format". IBM 3390 Direct Access Storage Introduction. International Business Machines Corporation. 22 October 1965.
  5. ↑ Houtekamer, Gilbert E.; Artis, H. Pat (1993). MVS I/O Subsystems: Configuration Management and Performance Analysis. New York: McGraw-Hill. ISBN 0-07-002553-3. OCLC 26096983.
  6. 1 2 3 "Synchronous DASD Operations". Introduction to Nonsynchronous Direct Access Storage Subsystems. International Business Machines Corporation. January 1990.
  7. ↑ IBM System/360 Principles of Operation, GA22-6821, Input/Output Operations
  8. ↑ IBM System/370 Principles of Operation, GA22-7000, Input/Output Operations
  9. ↑ IBM Enterprise Systems Architecture/370 Principles of Operation, SA22-7000, Chapter 13. I/O Overview
  10. ↑ Historical Narrative of the 1970s, US v IBM, Exhibit 14971, p.1051
  11. ↑ 3390 withdrawn from marketing in 1996
  12. 1 2 3 4 Introduction to Nonsynchronous Direct Access Storage Subsystems, IBM. GC26-4519-0, January 1990
  13. ↑ I/O Subsystem Architecture, J. Buzen, Proc IEEE, June 1975, p. 871
  14. ↑ Derived from IBM System/360 Reference Data (Green) Card, GX20-1703-9
  15. 1 2 2820 SCU controlling the 2301 Drum
  16. ↑ IBM System/360 Component Descriptions - 2841 and Associated DASD (PDF). First Edition. IBM. A26-5988-0.
  17. 1 2 IBM Corporation (1969). IBM System/360 Component Descriptions: 2314 Direct Access Storage Facility and 2844 Auxiliary Storage Control (PDF). IBM Corporation. p. 50.2.
  18. 1 2 3 4 5 Reference Manual for IBM 2835 Storage Control and IBM 2305 Fixed Head Storage Module, GA26-1589-5, October 1983
  19. ↑ Input/Output - A White Paper, J. Kettner, IBM, November 2007
  20. 1 2 Reference Manual for 3830 Model 1
  21. ↑ Device Support Facilities, User's Guide and Reference. Release 4.0, May 1981, pg vi, 46, 61, 87
  22. 1 2 3 4 5 IBM 3880 Storage Control ,Models 1, 2, 3, and 4 Description Manual, GA26-1661-9,September 1987, Section 4
  23. 1 2 IBM 3380 Direct Access Storage Description and User's Guide, GA26-1664-1, December 1981
  24. ↑ "Now Memorex fills the gap in your system's performance." Datamation Advertisement, August 1978, p. 85-6
  25. ↑ Introduction to IBM 3880 Storage Control Model 13, GA32-00622-0, September 1981
  26. 1 2 IBM S/390 Multiprise 3000 Enterprise Server, Internal Disk Subsystem: Reference Guide. IBM. November 1999.

Further reading

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.