IBM's mini computerslack thereof 825

Anne & Lynn Wheeler

there was a hack done in the mid-to-late 70s to address this performance issue w-o having intermediate electronic storage at the drive. it was originally done for database logs on CKD dasd

basically the database log was being written a full-track of data at a time (and commit couldn't complete until the related log records had actually landed on the disk).

the scenario is that CKD dasd allows quite a bit of freedom in formating the records on the track. the standard procedure is to sequentially increment the "ID" portion of the record ... and then when reading (or updating) ... use "search id equal" to locate the specific record to be read or written. The log hack was to format a track with something like 1k byte records ... and sequentially increment the ID field.

However, when going to write the log ... use something like "search id high" to begin writting ... and have one channel I-O program that consecutively wrote as many 1k byte records as had been formated for the track. The "search id high" would be succesful for whatever record was the first to rotate under the head ... and then it would consecutively write a full track of records from that position (w-o having to rotate around to a specific track location to start writing full track of data).

On log recovery ... the records had to have some minimal sequence number embedded in the record itself, ... since on a full-track read of a track ... you wouldn't otherwise now the sequence that the records had been written in.

This approach basically allowed the equivalent of local drive full-track storage for rotational latency compensation ... w-o actually requiring any local memory on the drive.