Re:
> I am looking for a utility to copy from one back-up tape to another tape.
> The tapes happen to be BackPack tapes.

There are three ways of copying tapes:

   1. with a program that understands the original tape(s) format/contents;

      (Note: it must either capable of handling reel switches at different
      points in the output than in the input *or* the output tape(s) may
      need to be at least as long/large as the input tape(s).

   2. with a priv mode program that correctly copies generic tapes;

      (Note: the output tape may need to be at least as long/large
      as the input tape.

   3. with a non-priv mode program that copies ordinary tapes, but
      will (usually quietly) fail to correctly copy some tapes;

      (Note: the output tape may need to be at least as long/large
      as the input tape.

:)


Consider what happens if the output tape isn't *quite* as long as the input
tape, and the input tape was 100% full ... you've got a problem unless
the tape copying program can properly handle this case.  For STORE tapes,
that means emitting a "reel switch" marker at the correct spot in the
output tape, asking for another reel/DDS/DLT, and synthesizing a correct
"start of reel" record and a correct directory list for the start of the
next output reel, then continuing the data from the end of the input
reel.  If the input was a multi-reel tape set, then when the end of the
input reel is hit, the program must properly handle (perhaps by ignoring)
the "reel switch" information from the input reel, and the start-of-next
reel data.  Whew!  This isn't easy!

That's why I second Michael Berkowitz's suggestion: use the backup product's
own "copy a backup set" feature, if it has one.

(<plug> For STORE tapes, our X-Over product copies backup sets from one set
of media to another </plug>)

What if you don't have #1?

Then you have to use a generic tape copier.

But ... by definition, a generic copier won't know how to handle reel
switches, so it would have to treat a multiple-reel set (STORE, BackUp,
or whatever) as a bunch of separate reels.

This means that if an output reel/DDS/DLT isn't large enough to hold
the entire input reel's data, the copy fails.

reel/DDS/DLT tapes are sold in specified lengths...but that doesn't mean
that two DDS tapes of the same ostensible size are 100% the same size.
A variation of as little as a couple of inches, or a variation in
the condition of the media, could result in two apparently identical
tapes having a different capacity.

That's why #1 above is better than #2 or #3.

But, a second problem rears its head: the size of the data records
on the tape.  The MPE file system FREAD/FWRITE intrinsics (and POSIX
read/write) have a maximum tape record size of 32766 16-bit words,
or 65532 bytes ... or about 4 bytes short of 64 KB.

This means that if a tape has a record of exactly 64 KB, then a
maximum FREAD (or read()) will quietly return 65532 bytes, and it
won't tell the program that 4 bytes were lost.  If the tape record
was 70 KB, a maximum FREAD will quietly return 65532 bytes, and
it won't tell the program that 6 KB were lost.  (BTW, the next FREAD
will start at the start of the next tape record.)

Some backup programs can create tapes using sendio (which requires
priv mode).  sendio allows extremely large tape records.

Type #2 copy programs use sendio to read/write, bypassing the
file system limits.
<plug> Our TAPEDISK product, which includes TAPETAPE, is this
kind of copier.
Info at http://www.allegro.com/products/hp3000/tapedisk.html
</plug>

Type #3 copy programs use FREAD/FWRITE, and are therefore subject
to file system limits.
TAPECOPY is this kind of copier.
Info at: http://jazz.external.hp.com/src/


It's important for all three types of programs to always try to
request a few more bytes than they expect to get.  E.g., if I'm
copying a tape that I think has 8KB records, I'll do FREAD (or
sendio read) requests of 8KB + 2.  If I get 8KB+2 bytes back, then
I report an error: I encountered a record larger than expected.
If I had only requested 8 KB, I'd never know that a larger record
was on the tape.

Hope this sheds some light :)

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

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *