Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!decwrl!sgi!shinobu!odin!anchor!olson
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi
Subject: Re: ExaByte feom problem
Message-ID: <1991Mar21.070033.27965@odin.corp.sgi.com>
Date: 21 Mar 91 07:00:33 GMT
References: <9103200941.aa07171@VGR.BRL.MIL>
Sender: news@odin.corp.sgi.com (Net News)
Organization: Silicon Graphics, Inc.  Mountain View, CA
Lines: 34

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

| the sequence
| 
| 	mt -t guest@remhost:/dev/nrexa rewind
| 	mt -t guest@remhost:/dev/nrexa feom
| 	bru -cvf guest@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.