4 Jun
2020
4 Jun
'20
1:19 a.m.
On a distantly related note, when I worked part time for the MIT
administration in the 60's, we'd do processing on the 7094 in the main comp
center, then bring a tape of results back to our office to do the printing
and card punching. For reasons that were never explained to me, the blocks
of print and punch data were combined on a single tape, and were
distinguished by being written with different parities. If you attempted to
read a block with the correct parity setting, the tape could stream. If you
guessed wrong, you had to stop, back up a block, change the parity, and try
again. So I wrote a simple 360 assembly program to keep track how often
blocks of each parity followed the observed parities of the previous 8
blocks. Essentially, 256 pairs of parity observations, indexed by the
previous 8 parity observations. Blocks of print and punch data tended to
fall into patterns that depended on what job was being run on the 7094, so
detecting those patterns and correctly anticipating the upcoming parity
made the tapes move much more smoothly. It was fun to watch the tape at the
start of a run. It was mostly just a coin-toss, so the tape was jerking
around fitfully. As the patterns started to emerge, the predictions got
better, the jerking got less and less common, and the tapes were streaming
most of the time. My introduction to learning algorithms.
On Wed, Jun 3, 2020 at 12:33 PM Paul Winalski <paul.winalski(a)gmail.com>
wrote:
On 6/2/20, Rich Morin <rdm(a)cfcl.com> wrote:
IIRC, we had five tape drives; my challenge was to keep them all as busy
as
possible, so as
to dump the data set expeditiously. Because I had asynchronous I/O
(mostly
in the form of
BUFFER IN and BUFFER OUT commands), I was able to implement a simple but
quite effective
polling loop. The machine room was a bit of a madhouse, but the tapes
were
written about
as quickly as the hardware allowed. Asynchronous I/O FTW...
With 9-track magnetic tape devices, reading and writing can't start
until the tape is up to speed. Once up to speed the drive can read
and write records while keeping the tape moving at speed. This is
called streaming. If there's a pause in the read/write requests from
the CPU, time is lost as the drive stops and starts moving the tape.
It was essential that applications doing large amounts of tape I/O
keep up the I/O requests at a rate that allows streaming.
Asynchronous I/O with multi-buffering is a straightforward way to
accomplish this. The IBM S/360 channel commands for tape devices
provided a mechanism for the tape control unit to send an interrupt to
the CPU when a read or write channel command completed. This notified
the sequential access method (the user program I/O interface) when I/O
to each buffer had completed and the buffer was available for reuse.
OS/360's Sequential Access Method could read or write an entire tape
using a single SIO (start I/O) instruction, as long as no read or
write errors were encountered.
-Paul W.