Hi,

> again, so we killed it.  However, are you telling me that HP engineers
> just
> wiped out my backup, without even asking for a by your leave?!?!?!

Well...they'd say: you gave us "leave" to do it by running STORE
with the "ONERROR=REDO" option (even though it was probably the
default option) :)

The basic problem is historical: when we were using reel-to-reel tape,
the HP division in charge of tape drives said "you cannot backspace a
tape and write a record reliably", which meant that upon encountering
a write error STORE couldn't just backup (to before the error) and write
a note like "ok, that's it for this reel...switch to next reel now".
So, the only form of recovering from a tape error during a STORE was
to throw away the reel and start a new reel at the same logical point
as the bad reel started.  (See below for why we mark it "bad")

So, when STORE wants to give up on a reel, it rewinds and writes
an "I'm bad" record to the reel.  Any write to a DDS will eventually be
followed by the writing of an End-of-tape marker (unless a power fail
occurs).  DDS drives won't let you read past an EOT.  Thus, even if the
DDS was 99% full when you got the error, you can't get access to any of
the data on it.  However ... there are always exceptions.  If you *really*
want the data on the reel (past the EOT), there's an expensive method
of getting it.  There are at least 2 companies that have special hardware
that let them get data past the EOT mark on a DDS tape...they could
retrieve the data and dump it onto another DDS tape.  You'd then probably
have to send the tape to us to retrieve the partial STORE-formatted files
off that raw data.

> What I'm really looking for is a RESTORE;YES_I_KNOW_THE_TAPE_IS_
> BAD_BUT_RESTORE_IT_ANYWAY option.  Or at least, STORE;DONT_
> WIPE_TAPE_IF_BAD option.

STORE has "ONERROR=QUIT", but lacks "ONERROR=REDO_BUT_SKIP_MARKING_TAPE_BAD"

BTW, the reason STORE marks it is that (AFAIR) over half the alpha test
sites for "ONERROR=REDO" on the Q-MIT STORE (the first with redo) made
errors by saving the bad tape(s) along with the good tapes, and running
into problems at RESTORE time.  So, we decided to mark the bad tape as
"bad" ... of course, this was before we had DDS ... and was done in a manner
that was known to not invalidate any user data bytes (just the STORE tape
header and directory).

> Sorry for the complaints, it's just been a very frustrating Monday.

here too!

--
Stan Sieler                                          [log in to unmask]
                                     http://www.allegro.com/sieler.html