{"history":[],"article":{"id":"1f5bcfa3-9f1d-4a1a-b8a3-fb6ec545f5f0","title":"Count key data","slug":"count-key-data","content":":::summary\n:::\n\n# \n**Count key data** (**CKD**) is a [direct-access storage device](https://bliptext.com/articles/direct-access-storage-device) (DASD) data recording format introduced in 1964, by IBM with its [IBM System/360](https://bliptext.com/articles/ibm-system-360) and still being emulated on IBM mainframes.\nIt 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.\nThis is in contrast to devices using [fixed sector size](https://bliptext.com/articles/fixed-block-architecture) or a separate format track.\nCount 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.\nThe initial set of CKD CCWs, introduced in 1964, was substantially enhanced and improved into the 1990s.\n\n# CKD track format\nThe reason for CKD track format is to allow data field lengths to vary, each **record**ed 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.\nThe count field has the identification of the record in cylinder-head-record format, the length of the key, and the length of the data.\nThe key may be omitted or consist of a string of characters.\n\"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.\"\nFollowing 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.\nA fixed-length gap follows the home address.\nNext, 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.\"\nFollowing R0 are the data records, separated by gaps.\nBecause of the gaps and other information, the recorded space is larger than that required for just the count data, key data, or user data.\nIBM 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.\nLater, programs were written to do these calculations.\nBecause records are normally not split between tracks, specification of an incorrect record size create problems.\nMost often, the key is omitted and the record is located sequentially or by direct cylinder-head-record addressing.\nIf 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.\nThe key (and hence the record) is locatable via hardware commands.\nSince the introduction of [IBM's System/360](https://bliptext.com/articles/ibm-system-360) in 1964, nearly all [IBM](https://bliptext.com/articles/ibm) large and intermediate system [DASDs](https://bliptext.com/articles/direct-access-storage-device) have used the count key data record format.\nThe advantages of count key data record format are:\nReduced 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](https://bliptext.com/articles/z-os) does not support sector-oriented interfaces.\nOriginally 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.\n# [Block diagram of count key data track format used on IBM mainframe computers beginning with S/360 shipment in 1965 | upload.wikimedia.org/wikipedia/commons/c/cf/CKD///Track///Format.png]\n\n# IBM's CKD DASD subsystems\n\n## Packaging\nInitially there was a high degree of correspondence between the logical view of DASD accesses and the actual hardware, as shown in the illustration.\nThree digit labels were typically affixed to identify the address of channel, control unit and device.\nOn low end systems the Channel and the Control Unit were frequently physically integrated but remained logically separate.\nIBM'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.\nThe 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.\nDASD without a controller, that is B-Units, have a \"B\" prefix in their model number.\nCKD 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](https://bliptext.com/articles/history-of-ibm-ckd-controllers).\nPlug-compatible offered many of the same DASD including 4 CKD subsystems featuring unique DASD.\n# [IBM S/360 & S/370 Input/Output operations for CKD DASD showing channel, storage control unit and DASD device | upload.wikimedia.org/wikipedia/commons/2/25/IBM///CKD///Arch.png]\n\n## Programming\nAccess to specific classes of I/O devices by an IBM mainframe is under the control of [Channel Command Words](https://bliptext.com/articles/channel-i-o) (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).\nThe group of CCWs defined by IBM for DASD fall into five broad categories:\nCKD CCWs are the specific set of CCWs used to access CKD DASD subsystems.\nThis is in contrast to [fixed block architecture](https://bliptext.com/articles/fixed-block-architecture) (FBA) CCWs which are used to access FBA DASD subsystems.\nCKD 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.\nModern 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.\nIn 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.\n\n# Initial CKD feature set\nThe initial feature set provided by IBM with its 1964 introduction of the CKD track format and associated CCWs included:.\nA Scan feature set was also provided but not continued into future CKD subsystems beyond the 2314.\nForty one CCWs implemented the feature set:\n**Notes:**\nThe CCWs were initially executed by two types of SCU attached to the system's high speed [Selector Channels](https://bliptext.com/articles/ibm-system-360-architecture).\nThe [2820 SCU](https://bliptext.com/articles/history-of-ibm-ckd-controllers) controlled the 2301 Drum while the 2841 SCU controlled combinations of the [2302 Disk Storage](https://bliptext.com/articles/ibm-2302), [2311](https://bliptext.com/articles/ibm-2311) Disk Drive, [2321 Data Cell](https://bliptext.com/articles/ibm-2321-data-cell) and/or 7320 Drum Storage.\nIBM quickly replaced the 7320 with the faster and larger 2303.\nSubsequently, the feature set was implemented on the [2314 family of storage controls](https://bliptext.com/articles/history-of-ibm-ckd-controllers) and an [integrated attachment of the System 370 Model 25](https://bliptext.com/articles/history-of-ibm-ckd-controllers).\nThe following example of a channel program reads a disk record identified by a Key field.\nThe track containing the record and the desired value of the key is known.\nThe SCU will search the track to find the requested record.\nIn this example <> indicate that the channel program contains the storage address of the specified field.\nSEEK \nSEARCH KEY EQUAL\nTIC *-8 Back to search if not equal\nREAD DATA\n\n# Block multiplexer channel enhancements\nThe [block multiplexor channel](https://bliptext.com/articles/ibm-system-360-architecture) was introduced beginning in 1971 on some high end System/360 systems along with the 2835 Control Unit and associated 2305 DASD, 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:\n\n## Multiple Requesting\nAllowed multiple channel programs,\nto be simultaneously active in the facility as opposed to only one with a Selector channel.\nThe actual number of subchannels provided depends upon the system model and its configuration.\nSometimes 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.\n\n## Command Retry\nThe channel and storage control under certain conditions can inter-operate to cause a CCW to be retried without an I/O interruption.\nThis procedure is initiated by the storage control and used to recover from correctable errors.\n\n## Rotational Position Sensing\nRotational position sensing (RPS) was implemented with two new CCWs, SET SECTOR and READ SECTOR\nenabled the channel to delay command chaining until the disk rotated to a specified angular track position.\nRPS permits channel disconnection during most of the rotational delay period and thus contributes to increased channel utilization.\nThe control unit implements RPS by dividing each track into equal angular segments.\n\n## Example Channel Program\nThe following example channel program will format a track with an R0 and three CKD records.\nSEEK \nSET FILE MASK\nSET SECTOR\nWRITE R0 \nWRITE CKD \nWRITE CKD \nWRITE CKD \nIn this example the Record 0 conforms to IBM programming standards.\nWith 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.\nA selector channel would be busy for the entire duration of this sample program.\n\n# Defect skipping\nDefect skipping allows data to be written before and after one of more surface defects allowing all of a track to be used except for that portion that has the defect.\nThis also eliminates the time that was formerly required to seek to an alternate track.\nOnly a limited number of defects could be skipped so alternate tracks remained supported for those tracks with excess defects.\nDefect skipping was introduced in 1974 with the 3340 attached via the 3830 Model 2 Storage Control Unit or integrated attachments on small systems.\nDefect skipping was essentially a factory only feature until 1981 when CCWs for management along with associated utilities were released.\n\n# Dynamic paths\nFirst introduced with the 3380 DASD on the [3880 Storage Control Unit](https://bliptext.com/articles/history-of-ibm-ckd-controllers) in 1981 the feature was included with the later CKD DASD subsystems.\nThe dynamic path selection function controls operation of the two controllers, including simultaneous data transfer over the two paths.\nWhen supported by the operating system, each controller can serve as an alternate path in the event the other controller is unavailable.\nThree additional commands, Set Path Group ID, Sense Path Group ID, and\nSuspend Multipath Reconnection, are used to support attachment of the\n3380 Models having two controllers at the head of a string.\nThe Set Path Group ID command, with the dynamic path selection (DPS)\nfunction, provides greater flexibility in operations on reserved devices.\nOnce a path group for a device has been established, it may be accessed\nover any path which is a member of the group to which it is reserved.\nIn addition, on 370-XA systems which set the multipath mode bit in the\nfunction control byte (byte 0) to a 1, block multiplex reconnections will\noccur on the first available path which is a member of the group over which\nthe channel program was initiated (regardless of the reservation state of the device).\nIf the controller designated in the I/O address is busy or disabled, the dynamic path selection allows an alternate\npath to the device to be established via another storage\ndirector and the other controller in the model AA.\n\n# Nonsynchronous operation\nPrior to the 1981 introduction of the 3880 director, CKD records were synchronously accessed, all activities required that one CCW be ended and the next initiated in the gaps between the CKD fields.\nThe gap size placed limitations on 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.\n**Nonsynchronous operation** provided by the Extended CKD (\"ECKD\") set of CCWs removed the gap timing constraint.\nThe five additional ECKD CCWs are Define Extent, Locate Record, Write Update Data, Write Update Key and Data, and Write CKD Next Track.\nIn 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.\nChannel 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.\nAn intermediate buffer in the storage control allows independent operations between the channel and the device.\nA major advantage of ECKDs is far longer cables; depending upon application it may improve performance.\nECKD CCWs are supported on all subsequent CKD subsystems.\nThis example nonsynchronous channel program reads records R1 and R2 from track X'0E' in cylinder X'007F'.\nBoth records have a key length of 8 and a data length of X'64' (10010) bytes.\nDefine Extent \nLocate Record \nRead Data \n\n# Caching\n[Caching](https://bliptext.com/articles/cache-computing) first introduced in DASD CKD subsystems by Memorex (1978) and StorageTek (1981) was subsequently introduced in late 1981 by IBM on the 3880 Model 13 for models of the 3380 with dynamic pathing.\nThe 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.\nA large memory in the Director, the cache, is divided into track slots that store data from the 3380 tracks.\nA smaller area is a directory that contains entries that allow data to be located in the cache.\nCaches were also provided on subsequently introduced storage controls.\n\n# Other extensions\nOver time a number of path control, diagnostic and/or error recovery CCWs were implemented on one or more storage controls.\nFor example:\n\n# Beyond System/370\nReduced 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.\nOriginally 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.\nAn IBM mainframe constructs CKD track images in memory and executes the ECKD and CKD channel programs against the image.\nTo 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.\nOf the 83 CKD CCWs implemented for System/360 and System/370 channels 56 are emulated on System/390 and later systems.","current_revision":null,"created_by":"kACnuQmH5k9Nr5VNVEpVeg7XpvUmMctD","created_at":"2025-01-26T09:14:42.330Z","updated_at":"2025-01-26T09:14:42.330Z","search_vector":"'count':1 'data':3 'key':2","search_content":" \n \n\n# \n**Count key data** (**CKD**) is a [direct-access storage device](https://bliptext.com/articles/direct-access-storage-device) (DASD) data recording format introduced in 1964, by IBM with its [IBM System/360](https://bliptext.com/articles/ibm-system-360) and still being emulated on IBM mainframes.\nIt 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.\nThis is in contrast to devices using [fixed sector size](https://bliptext.com/articles/fixed-block-architecture) or a separate format track.\nCount 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.\nThe initial set of CKD CCWs, introduced in 1964, was substantially enhanced and improved into the 1990s.\n\n# CKD track format\nThe reason for CKD track format is to allow data field lengths to vary, each **record**ed 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.\nThe count field has the identification of the record in cylinder-head-record format, the length of the key, and the length of the data.\nThe key may be omitted or consist of a string of characters.\n\"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.\"\nFollowing 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.\nA fixed-length gap follows the home address.\nNext, 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.\"\nFollowing R0 are the data records, separated by gaps.\nBecause of the gaps and other information, the recorded space is larger than that required for just the count data, key data, or user data.\nIBM 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.\nLater, programs were written to do these calculations.\nBecause records are normally not split between tracks, specification of an incorrect record size create problems.\nMost often, the key is omitted and the record is located sequentially or by direct cylinder-head-record addressing.\nIf 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.\nThe key (and hence the record) is locatable via hardware commands.\nSince the introduction of [[IBM](https://bliptext.com/articles/ibm)'s System/360](https://bliptext.com/articles/ibm-system-360) in 1964, nearly all [IBM](https://bliptext.com/articles/ibm) large and intermediate system [DASDs](https://bliptext.com/articles/direct-access-storage-device) have used the count key data record format.\nThe advantages of count key data record format are:\nReduced 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](https://bliptext.com/articles/z-os) does not support sector-oriented interfaces.\nOriginally 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.\n# [Block diagram of count key data track format used on IBM mainframe computers beginning with S/360 shipment in 1965 | upload.wikimedia.org/wikipedia/commons/c/cf/CKD///Track///Format.png]\n\n# IBM's CKD DASD subsystems\n\n## Packaging\nInitially there was a high degree of correspondence between the logical view of DASD accesses and the actual hardware, as shown in the illustration.\nThree digit labels were typically affixed to identify the address of channel, control unit and device.\nOn low end systems the Channel and the Control Unit were frequently physically integrated but remained logically separate.\nIBM'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.\nThe 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.\nDASD without a controller, that is B-Units, have a \"B\" prefix in their model number.\nCKD 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](https://bliptext.com/articles/history-of-ibm-ckd-controllers).\nPlug-compatible offered many of the same DASD including 4 CKD subsystems featuring unique DASD.\n# [IBM S/360 & S/370 Input/Output operations for CKD DASD showing channel, storage control unit and DASD device | upload.wikimedia.org/wikipedia/commons/2/25/IBM///CKD///Arch.png]\n\n## Programming\nAccess to specific classes of I/O devices by an IBM mainframe is under the control of [Channel Command Words](https://bliptext.com/articles/channel-i-o) (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).\nThe group of CCWs defined by IBM for DASD fall into five broad categories:\nCKD CCWs are the specific set of CCWs used to access CKD DASD subsystems.\nThis is in contrast to [fixed block architecture](https://bliptext.com/articles/fixed-block-architecture) (FBA) CCWs which are used to access FBA DASD subsystems.\nCKD 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.\nModern 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.\nIn 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.\n\n# Initial CKD feature set\nThe initial feature set provided by IBM with its 1964 introduction of the CKD track format and associated CCWs included:.\nA Scan feature set was also provided but not continued into future CKD subsystems beyond the 2314.\nForty one CCWs implemented the feature set:\n**Notes:**\nThe CCWs were initially executed by two types of SCU attached to the system's high speed [Selector Channels](https://bliptext.com/articles/ibm-system-360-architecture).\nThe [2820 SCU](https://bliptext.com/articles/history-of-ibm-ckd-controllers) controlled the 2301 Drum while the 2841 SCU controlled combinations of the [2302 Disk Storage](https://bliptext.com/articles/ibm-2302), [2311](https://bliptext.com/articles/ibm-2311) Disk Drive, [2321 Data Cell](https://bliptext.com/articles/ibm-2321-data-cell) and/or 7320 Drum Storage.\nIBM quickly replaced the 7320 with the faster and larger 2303.\nSubsequently, the feature set was implemented on the [2314 family of storage controls](https://bliptext.com/articles/history-of-ibm-ckd-controllers) and an [integrated attachment of the System 370 Model 25](https://bliptext.com/articles/history-of-ibm-ckd-controllers).\nThe following example of a channel program reads a disk record identified by a Key field.\nThe track containing the record and the desired value of the key is known.\nThe SCU will search the track to find the requested record.\nIn this example <> indicate that the channel program contains the storage address of the specified field.\nSEEK \nSEARCH KEY EQUAL\nTIC *-8 Back to search if not equal\nREAD DATA\n\n# Block multiplexer channel enhancements\nThe [block multiplexor channel](https://bliptext.com/articles/ibm-system-360-architecture) was introduced beginning in 1971 on some high end System/360 systems along with the 2835 Control Unit and associated 2305 DASD, 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:\n\n## Multiple Requesting\nAllowed multiple channel programs,\nto be simultaneously active in the facility as opposed to only one with a Selector channel.\nThe actual number of subchannels provided depends upon the system model and its configuration.\nSometimes 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.\n\n## Command Retry\nThe channel and storage control under certain conditions can inter-operate to cause a CCW to be retried without an I/O interruption.\nThis procedure is initiated by the storage control and used to recover from correctable errors.\n\n## Rotational Position Sensing\nRotational position sensing (RPS) was implemented with two new CCWs, SET SECTOR and READ SECTOR\nenabled the channel to delay command chaining until the disk rotated to a specified angular track position.\nRPS permits channel disconnection during most of the rotational delay period and thus contributes to increased channel utilization.\nThe control unit implements RPS by dividing each track into equal angular segments.\n\n## Example Channel Program\nThe following example channel program will format a track with an R0 and three CKD records.\nSEEK \nSET FILE MASK\nSET SECTOR\nWRITE R0 \nWRITE CKD \nWRITE CKD \nWRITE CKD \nIn this example the Record 0 conforms to IBM programming standards.\nWith 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.\nA selector channel would be busy for the entire duration of this sample program.\n\n# Defect skipping\nDefect skipping allows data to be written before and after one of more surface defects allowing all of a track to be used except for that portion that has the defect.\nThis also eliminates the time that was formerly required to seek to an alternate track.\nOnly a limited number of defects could be skipped so alternate tracks remained supported for those tracks with excess defects.\nDefect skipping was introduced in 1974 with the 3340 attached via the 3830 Model 2 Storage Control Unit or integrated attachments on small systems.\nDefect skipping was essentially a factory only feature until 1981 when CCWs for management along with associated utilities were released.\n\n# Dynamic paths\nFirst introduced with the 3380 DASD on the [3880 Storage Control Unit](https://bliptext.com/articles/history-of-ibm-ckd-controllers) in 1981 the feature was included with the later CKD DASD subsystems.\nThe dynamic path selection function controls operation of the two controllers, including simultaneous data transfer over the two paths.\nWhen supported by the operating system, each controller can serve as an alternate path in the event the other controller is unavailable.\nThree additional commands, Set Path Group ID, Sense Path Group ID, and\nSuspend Multipath Reconnection, are used to support attachment of the\n3380 Models having two controllers at the head of a string.\nThe Set Path Group ID command, with the dynamic path selection (DPS)\nfunction, provides greater flexibility in operations on reserved devices.\nOnce a path group for a device has been established, it may be accessed\nover any path which is a member of the group to which it is reserved.\nIn addition, on 370-XA systems which set the multipath mode bit in the\nfunction control byte (byte 0) to a 1, block multiplex reconnections will\noccur on the first available path which is a member of the group over which\nthe channel program was initiated (regardless of the reservation state of the device).\nIf the controller designated in the I/O address is busy or disabled, the dynamic path selection allows an alternate\npath to the device to be established via another storage\ndirector and the other controller in the model AA.\n\n# Nonsynchronous operation\nPrior to the 1981 introduction of the 3880 director, CKD records were synchronously accessed, all activities required that one CCW be ended and the next initiated in the gaps between the CKD fields.\nThe gap size placed limitations on 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.\n**Nonsynchronous operation** provided by the Extended CKD (\"ECKD\") set of CCWs removed the gap timing constraint.\nThe five additional ECKD CCWs are Define Extent, Locate Record, Write Update Data, Write Update Key and Data, and Write CKD Next Track.\nIn 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.\nChannel 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.\nAn intermediate buffer in the storage control allows independent operations between the channel and the device.\nA major advantage of ECKDs is far longer cables; depending upon application it may improve performance.\nECKD CCWs are supported on all subsequent CKD subsystems.\nThis example nonsynchronous channel program reads records R1 and R2 from track X'0E' in cylinder X'007F'.\nBoth records have a key length of 8 and a data length of X'64' (10010) bytes.\nDefine Extent \nLocate Record \nRead Data \n\n# Caching\n[Caching](https://bliptext.com/articles/cache-computing) first introduced in DASD CKD subsystems by Memorex (1978) and StorageTek (1981) was subsequently introduced in late 1981 by IBM on the 3880 Model 13 for models of the 3380 with dynamic pathing.\nThe 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.\nA large memory in the Director, the cache, is divided into track slots that store data from the 3380 tracks.\nA smaller area is a directory that contains entries that allow data to be located in the cache.\nCaches were also provided on subsequently introduced storage controls.\n\n# Other extensions\nOver time a number of path control, diagnostic and/or error recovery CCWs were implemented on one or more storage controls.\nFor example:\n\n# Beyond System/370\nReduced 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.\nOriginally 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.\nAn IBM mainframe constructs CKD track images in memory and executes the ECKD and CKD channel programs against the image.\nTo 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.\nOf the 83 CKD CCWs implemented for System/360 and System/370 channels 56 are emulated on System/390 and later systems.","revisionCount":0},"hasMore":false,"nextCursor":null}

History