Random Access Tape 2451

Charles Shannon Hendrix

I validated this feature on IBM 2420 9 tracks in about 1968 plus 1. When you wrote the tape using the standard OS access method, 2 file marks were written after you closed a file being written. This signalled end-of-tape and the access method would not let you open any subsequent files for input, but you could append a new file and the OS would erase the 2nd file mark and then write the file, again closing it with 2 file marks. Simple but workable.

But we had an app where we wanted to write some kind of table of contents or summary as the 1st record in the 1st file, and update it as we added data at the end of the tape. Simple, if you're a smart kid who can read manuals. I wrote a channel program (low level device code) to rewrite block 1 and then exit without writing a file mark at all.

Worked great ... about 98% of the time. The other 2%, the tape was unreadable after the rewritten block. Oops, guess there *was* a reason for this restriction. We found this out in production, of course.

This was probably my first personal lesson, and a good one, on the topic of demonstrating an undocumented feature of some component and then buttuming that it is safe to use just because it works in some particular case.

WM