Path: ...!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!not-for-mail
From: John Levine <johnl@taugh.com>
Newsgroups: comp.arch
Subject: Where did CKD disks come from?
Date: Thu, 12 Dec 2024 20:31:53 -0000 (UTC)
Organization: Taughannock Networks
Message-ID: <vjfh7p$1ua9$1@gal.iecc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 12 Dec 2024 20:31:53 -0000 (UTC)
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970";
	logging-data="63817"; mail-complaints-to="abuse@iecc.com"
Cleverness: some
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: johnl@iecc.com (John Levine)
Bytes: 3623
Lines: 47

This is a question about I/O architecture rather than CPU architecture, but close enough.

IBM's early disks all had fixed size sectors, or in one case I found, an option to
write one big record per track if the computer had enough memory to buffer it.

System/360 changed that to a much more complicated Count-Key-Data format where
each track was formatted with records of arbitrary size (that's what the count
was for) and records could have a hardware key. The keys were used for ISAM
files, where the channel and device controller could search through a track or
cylinder to find a record with a desired key.

I can somewhat see the motivation, since that made it possible to make the
records on the disk match the logical sizes that applications used, and the CPU
could tell the channel and controller to do a key search while the CPU went off
to do something else. But in practice, this turned out to be a bad idea. Nearly
everyone had more than one disk attached to each controller which meant that if
it was doing a key search on one drive, it couldn't do anything with the other
drives. Originally, even if the disk was formatted with fixed sized records the
channel and controller had to start at the track origin and search for the
record number. 

Soon they added Rotational Position Sensing (RPS) which let the channel do other
stuff until the drive got close to the desired position, and eventually they
invented a new acronym FBA to describe the block format everyone else used and
for many years CKD disks have been simulated in microcode on FBA devices. ISAM
was replaced with VSAM KSDS which uses B-trees of fixed sized blocks.

Even in the CKD era, at the low end, 360/20 and 1130 and 1800 had 2311 disk
drives formatted with fixed sectors that simpler controllers could handle. The
physical disk packs were the same but couldn't be used on CKD drives without
being erased and reformatted.

My question is where did CKD come from? I looked at the 1964 IBM Systems Journal
issue that describes the design of S/360 which has an article describing the way
the channels work, but nothing about the disks. Wikipedia has a long list of CKD
drives and controllers but no hint of whose idea it was. 

One clear mistake is that they underestimated how quickly main memories would
grow, which meant that you could cache keys in memory so most of what would
otherwise be found by a channel ISAM search was in the cached keys and you could
usually directly read correct record on the disk. Similarly, if you have
plenty of memory to buffer multiple disk blocks, splitting logical records of
whatever size across fixed size blocks is no big deal.

-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly