TM78 (TU78) question: Read Opposite operation

[Griff Smith]

In article <2323 at umd5.umd.edu>, chris at trantor.umd.edu (Chris Torek) writes:
> The TM78 User's Guide says that the proper response to a Read
> Opposite is to issue another read command using the opposite of
> the previous direction (forward if the last was a read reverse;
> reverse otherwise).  The 4.3BSD driver simply does a read reverse.
> Probably it is wrong.  It seems, however, that after one, or perhaps
> several, read reverse operations, the driver winds up re-reading
> a previously read block.
> 
> So the question:  Is the 4.3BSD driver wrong once or twice?

The driver, as released in 4.3BSD, does have a few bugs - not in error
recovery that I know of.  I posted fixes to comp.bugs.4bsd for the bugs
that I found.

I have tested the positioning code thoroughly with a tape that has
intermittent read errors; the contents always match, even though the
number of soft errors varies from run to run.  I have also tested it
with a tape that has a hard error in the middle of a block.  The tape
always ends up positioned after the damaged block.  After using the
driver for about 4 years I have seen no unexplained cases of
mis-positioning.

> That
> is, is there some reason to ignore the advice in the TM78 User's
> Guide, or to believe that a Read Opposite will only occur once per
> transfer?

I can't find my manual right now, but my impression is that it was
misleading.  My memory is that a trace of the commands from the
controller was "RETRY RETRY RETRY RETRY RETRY RETRY RETRY RETRY RETRY
RETRY RDOPP RDOPP RDOPP RDOPP RDOPP RDOPP RDOPP RDOPP RDOPP RDOPP
RETRY".  The "read opposite" refers to the sense of the original
command, not to that of the retry.  Since the driver does not support
"read reverse" as a user-specified command, "Read Opposite" can only
mean read backwards.

> In addition, is it necessary to issue a Forward Record
> operation after a successful reverse read, or will the controller
> do this automatically?

The controller will position automatically.

> -- 
> In-Real-Life: Chris Torek, Univ of MD Computer Science, +1 301 454 7163
> (hiding out on trantor.umd.edu until mimsy is reassembled in its new home)
> Domain: chris at mimsy.umd.edu		Path: not easily reachable

One likely explanation for your problem: you may have a one-way tape.
I have occasionally seen bad blocks that don't look like records when
read backward.  When the controller backs up to re-read the block, it
skips to the good block that preceeds the block in error.  This block
is then successfully read, and the error is assumed to be corrected.
When the drive hits the bad block again, the cycle start over.
-- 
Griff Smith	AT&T (Bell Laboratories), Murray Hill
Phone:		1-201-582-7736
UUCP:		{allegra|ihnp4}!ulysses!ggs
Internet:	ggs at ulysses.att.com