ExaByte feom problem

[Dave Olson]

In <9103200941.aa07171 at VGR.BRL.MIL> FL17 at DLRVMBS.BITNET writes:

| the sequence
| 
| 	mt -t guest at remhost:/dev/nrexa rewind
| 	mt -t guest at remhost:/dev/nrexa feom
| 	bru -cvf guest at remhost:/dev/nrexa files ...
| 
| works nicely on our 4D25GT with the remote host being a 4D70GT to create
| multiple archives on an ExaByte tape as long as the remote host is not
| rebooted. If, however, the remote host is rebooted, feom doesn't work as
| expected and a new archive is written at the beginning of the tape overwriting
| what was already there. If the remote host is not rebooted again, the next
| archive is appended to the archives already on tape as expected.

The bug is in the setup of the drive on the very first use after
reboot (or after a tape is first inserted, if I remember correctly).

The hack work-around till 4.0 is to add after the rewind:

	mt ... fsr 1

and ignore any resulting errors (which might occur if the tape
is blank).

Sorry about that; it only happens on the Exabyte, due to the fact
that it doesn't support space to EOD, and it therefore has to be
faked; some condition codes weren't set/checked correctly in this
one case.
--

	Dave Olson

Life would be so much easier if we could just look at the source code.