9 track tapes and block sizes

[Jeff Woolsey]

> On 10/2/20 1:42 PM, Eric Smith via cctalk wrote:
>
> >/Of course, that scheme breaks programs that use tape images but don't />/expect enormous or "negative" record lengths. /
> Those would already be broken with Bob's use of large negative numbers for physical end of
> tape and 'bad block is here' (you don't get to know how big that bad block was, so that is
> hell with tapes with variable-length records, grumble..)
0xFFFFFFFF is end-of-medium. I've encountered only a few tapes with this
marker.

0xFFFFFFFE is an erase gap.  I've never encountered one, perhaps because
I treat all 0xFFnnnnnn as EOM, even though they are reserved.

0x00000000 is a tapemark.

The above three are dataless.

0x80nnnnnn is a bad block (Medium Error) of size nnnnnn > 0. Woe to me
when my tape drive returns a zero-length block for those, so sometimes I
cobble up a BAD0 label and surround it with these Medium Errors. 
Heroics can ask my tape drive what happened (to distinguish it from a
normal tapemark).

I could suggest that other values for the first byte might be used for
metadata, but I think there are too many readers and existing images to
let that work.  I just put metadata in the same directory, but it can
get misplaced easily, and nothing limits a directory to just one tape
image.  Not optimal.

>
> But for all the people who get clean reads off their tapes, none of this is an issue.
> I wish I was so lucky.
I can't believe that anyone never gets a clean read from any of their
tapes; most of mine have been clean.  But not all of them...

-- 
Jeff Woolsey {{woolsey,jlw}@jlw,first.last@{gmail,jlw}}.com
Nature abhors straight antennas, clean lenses, and empty storage.
"Delete! Delete! OK!" -Dr. Bronner on disk space management
Card-sorting, Joel.  -Crow on solitaire