Talk:Count key data

Duplicate info

See Talk:Execute_Channel_Program#Duplicate_info for discussion. Peter Flass (talk) 16:19, 6 December 2019 (UTC)

Because blocks are normally not split between tracks

The article says: Because blocks are normally not split between tracks. Not normally, unless the device has the track overflow feature. One of the complications in getting Hercules to run MVS 3.8j was that it needs track overflow to work. It might be that it is needed for the catalog or TOC. But yes, that was for earlier devices, I believe the 3330 being the more recent one. Gah4 (talk) 23:47, 6 March 2024 (UTC)

CKD records are never split between tracks, but the access methods may write a logical block as multiple physical blocks on a device supporting track overflow. MVS does not use track overflow for a VTOC or CVOL, so if there is a dependency I would assume that it is in the VSAM catalog or in the paging datasets. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:04, 7 March 2024 (UTC)

Oh, yes, VSAM catalog is the one. The result, in the end, is that the Hercules CKD files are compatible with those of IBM's AWS disks, except for track overflow. Gah4 (talk) 07:52, 8 March 2024 (UTC)

Nomenclature: blocks versus records, hardware versus software

There is a disconnect in the vocabulary of IBM hardware manuals versus software manuals. The hardware manuals for CKD DASD use the term record while the software manuals use the term block or physical record. I believe that the lead should mention this. @Tom94022: Also, edit special:permalink/1212325573 changed or a copy of the highest key in the block, for "blocked" records) to the garbled or a copy of the first n bytes in of the first data when the record has several "blocks" data concatenated in one data field, which does not conform to either hardware or software nomenclature. I suggest or a copy of the highest key in the record, for blocked logical records) -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:29, 7 March 2024 (UTC)

I am not sure what substantive relevant distinction you are making - I am not aware of any reference manual for any CKD device that uses the term "block" to refer to "record." Ditto at the channel command reference manual level. Yes, at some level (e.g. to_IBM_Direct-Access_Storage_Devices_and_Organization_Methods_Dec75.pdf) IBM does distinguish between logical record and physical record with the "block" sometimes the same as "physical record" but I think that is a level of complexity we don't need here. IBM doesn't uses "record" not "physical record" in the relevant reference manuals I think that is best what we consistently use in this article. If someone wants to add a note someplace in the article that CKD record is sometimes referred to as "physical record" or "block" that should be more than enough. Tom94022 (talk) 22:05, 7 March 2024 (UTC)

Exactly what I wrote; the hardware and software nomenclature differ.

The quoted text in the cited edit broke consistency, even within a single sentence, and used nomenclature that is OR; since you removed it in permalink/1212432070, it is no longer an issue. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:33, 8 March 2024 (UTC)

Notes

Sections having nothing to do with CKD format

Some sections of the article deal with topics that seem unrelated to CKD format, such as Count key data § Dynamic paths, which discusses a feature that appears to discuss data paths; the feature sounds like one that could also be used with FBA. Others that might be unrelated to CKD include Count key data § Multiple Requesting and Count key data § Command Retry. Perhaps there should be a page, or a section of a page, discussing the architecture of IBM mainframe storage hardware and firmware, and perhaps the general notion of channel, control unit, and device. Guy Harris (talk) 06:28, 8 March 2024 (UTC)

The article lede does state the article also covers CKD channel commands but the sections cited above do seem to be inappropriate to this article. Problem is IBM channels are only briefly covered in the various IBM System articles, e.g. IBM System/360 Channels with the global article on Channel I/O being perhaps to generic for such material. Maybe these sections can be moved into the article on the IBM system in which such features were first announced. A bit of a research project, but maybe some of the editors will recall the announcement date and system. Tom94022 (talk) 19:22, 8 March 2024 (UTC)

Upon further study it seems to me most of what is in the block multiplexer channel enhancements section of this article should be moved to History of IBM CKD Controllers article. Tom94022 (talk) 21:40, 8 March 2024 (UTC)

History of IBM CKD Controllers looks as if it can serve as the page that "[discusses] the architecture of IBM mainframe storage hardware and firmware", at least for CKD drives. Guy Harris (talk) 21:55, 8 March 2024 (UTC)

The CCW opcodes controlling Dynamic paths are specific to ECKD controllers, and belong here until there is an ECKD article. I'm not aware of any FBA controller supporting them, I don't know enough about SCSI drives accessed over FCP to comment on them.

Some of the material belongs in IBM System/360#Input/Output. Some, however is specific to DASD, e.g., the Set Sector and Read Sector CCW opcodes.

There really ought to be architecture article fir S/360 through z/Architecture, as well as an ECKD article; much of what you mention would fit naturally there. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:25, 10 March 2024 (UTC)

"Architecture article", singular, or "architecture articles", plural? There's already IBM System/360 architecture, with IBM System/360 covering the family as a product line, and z/Architecture, with IBM Z covering the family as a product line, but the intermediate architectures don't have such a split.

(x86 has a single x86 page, which covers the product line of chips, and has some details common to 16-bit, 32-bit, and 64-bit architectures, and also IA-32 for the 32-bit version and x86-64 for the 64-bit version.) Guy Harris (talk) 23:17, 10 March 2024 (UTC)

The IBM System/360 architecture doesn't cover S/370. 370/XA, ESA/370, ESA/390 or z/Architecture, and is already at 86K; a single architecture article would be too big. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:27, 11 March 2024 (UTC)

Actually I think all architectures have homes either in articles or sections as follows S/370, 370/XA, ESA/370, ESA/390 or z/Architecture so all we have to do is find the right one to move the irrelevant material. Tom94022 (talk) 17:42, 11 March 2024 (UTC)

The item about "virtualized" CKD should probably be expanded

The sentence

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.

should perhaps have more text explaining what that means. As I understand it, the drives are just ordinary fixed-block drives, and some combination of hardware, firmware, and software(?) makes that look like a CKD device. I don't know if the details of how that's done are available in any reference. Guy Harris (talk) 06:34, 8 March 2024 (UTC)

Does US 5581743A , "CKD to fixed block mapping for optimum performance and space utilization", describe one way IBM does that CKD emulation? (US551743A at Google Patents) Guy Harris (talk) 06:53, 8 March 2024 (UTC)

I doubt if the existence of an IBM patent is sufficient to establish it was ever practiced in any actual product. We would have to find an RS linking the patent to a product to make such an assertion. It is OR but I am pretty sure the first RAMAC RAID mapped CKD into FBA devices by writing the entire physical CKD track, gaps, ECC, etc into fixed blocks and then staging the track into a buffer before reconnecting for a transfer. Not a very efficient use of storage but made the virtualization straight forward. I am pretty sure later virtualizations were more efficient but don't know any details. Also IBM was not the first virtualizer, I believe EMC was and I am not aware of any published material on its virtualization architecture. It is indeed a combination of hardware and mainly firmware in a storage subsystem but maybe that is all we can say and even then finding a RS might be difficult. I tried BARD and got no help. :-) Tom94022 (talk) 07:45, 8 March 2024 (UTC)

This slideshow seems to suggest that the first emulated CKD device was from a product code-named "Iceberg" from Storage Technology Corporation. Guy Harris (talk) 07:51, 8 March 2024 (UTC)

The "EMC Symmetrix Integrated Cached Disk Array" introduced in September 1990 was an IBM CKD emulating storage device using a RAID array of Seagate FBA HDDs; it was likely the first such system and well before STC's Iceberg in 1994. Tom94022 (talk) 19:03, 8 March 2024 (UTC)

There are two things. One is that IBM sells boxes that to the hardware look like traditional disk drives, though (if you open the box) you find a bunch of ordinary drives. I suspect, though, that you are not supposed to open them. The second is the files used for P/370 and P/390 systems, by AWSCKD, where you can access the files on the host system. The former should be considered as black boxes, as IBM could change them at any time. Gah4 (talk) 08:17, 8 March 2024 (UTC)

That sentence is iffy anyway: it is the logical track that was in 1-1 correspondence with the physical track, not the individual records, especially when there were multiple records per track.

Virtual tracks go back at least as far as the IBM 3350, which could be configured to look like a 3330-11 or like a pair of 3330-1 volumes; in either case the logical volumes had a different track size from a native volume. I believe that the 3350 was the last CKD device to simulate a dissimilar device. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:11, 8 March 2024 (UTC)