Seagate ctl-96 & auto-advance to next tape

Greets everyone;

Last nite, my backup went a bit too close to EOT, and hit it while 
trying to write the last 75 megs worth of indices and configs.

This drive is supposed to be able to hit EOT, load the next tape and 
keep going, but I've never seen it work, nor is there a lot of docs 
available that tell one how to enable/disable this "feature" if you 
could call it that.

This is the message I got from that script, which gives no clue that 
it may have tried to do this auto-advance.
----------------------
11  <-- the striped off number of this tape.
7699200 <-- an 'mt -f /dev/nst0 tell' returned this
tar: Removing leading `/' from member names <-tar is run twice
tar: Removing leading `/' from member names
dd: writing `/dev/nst0': No space left on device
1940+0 records in
1939+0 records out
# note, one block short of completing the write
# then the second, config backup file,
dd: writing `/dev/nst0': No space left on device
1+1 records in
1+0 records out
# which hit EOT instantly
# but this actually leaves the drive unloaded, the actual command is
# /usr/local/sbin/amtape DailySet1 slot advance
amtape: changed to slot 3
----------------------

Now, the reason I'm concerned is that the next tape in the magazine is 
now trashed.  I've cleaned the drive, then backed up and grabbed the 
label block from the previous tape, edited the tape number to 12, and 
advanced the slot back to 3.  The drive has now apparently recognized 
the tape, or has given up.

Humm, must have given up, an mt -f /dev/nst0 rewind returns no error, 
but dd cannot write to either /dev/nst0 or /dev/st0.  But an mt -f 
/dev/nst0 tell says its at block 0.

So, it appears that either its a coincidence and tape 12 died, or 
hitting the EOT did something to the next tape in the magazine.  If 
the latter, then I'd like to find out how to prevent it from 
happening again.  In any event, it appears I must replace it before 
tonights run.  I opened the casette door, and the tape looks fine.

And I'd suspect it would be just fine if something hadn't boinked the 
hidden header.  

Does anyone have a clue how one would go about restoreing that?

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.26% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.