Tape dumping programs for Unix/Linux...

From: Douglas H. Quebbeman <dquebbeman_at_acm.org>
Date: Thu May 2 15:10:10 2002

> > The emulator community is vigorously using a tape image container
> > format known as TAP for precisely this purpose.
...
> Darn...sounds like a subset of what I use. I'd be interested
> in knowing more about TAP (with an eye towards adopting use of it),
> and would suggest some possibly missing features might be:
>
> - ability to flag if the current tape record had a recovered read
> error (obviously, not all hardware/OS's support getting that information)

No. And I see no useful purpose in including that in the format.
If the read was recovered, you have the data; surely you would
*not* want to recreate a tape and make a previously marginal
block, marginal again on a clone?
 
> - ability to flag if a particular tape record had a hard error
> while reading it

No (I can say this even though I'm about to ask): do you mean an
unrecoverable error, or one that was corrected by the hardware
(as opposed to being corrected by software)? Either way, if the
error was corrected, see my response above.


> - ability to flag if an End-of-tape marker/indicator was seen
> while reading the the current record (again, not all
> hardware/OS's support getting that information)

No, and again, I can't see how this data would be used to recreate
the tape or would be needed by an emulator. It's kind of like asking
if a particular hardware emulator also emulates memory parity errors
so that you can see memory parity errors in the logs. Why??

> - overall header at start of file, recording information about the tape

No, although I did consider suggesting some extensions like this.
One problem I have encountered with some old CDC tape formats
dealt with how blocking got handled. But my current feeling on
this is that if its blocked on taped, then the records will come
off the taoe with their proper lengths (I encountered this not
trying to read a tape, but trying to create an image of a tape
that no longer exists by a desctiption of its contents).

Anyway, I encode that kins of descriptive information (what kind
of computer, encoding, #tracks, etc) in the filename, or in the
name of the directory containing the file, or in a README.

> I have a program called "tapedisk", which reads an arbitrary tape
> and "copies" it to a single disk file (or set of files, if the size of the
> output file exceeds the maximum disk file size). The purpose of
> tapedisk is to allow a future exact copy of the tape to be recreated
> on another tape (of equal or larger size). (That future copy would be
> made with the companion program, disktape.) Additionally, most of
> my other tape-reading utilities know how to read a tapedisk format
> disk file as though it were a tape.

This sounds familiar... is it on the web somewhere?

> This is what I store on a per-tape-record basis:

...

So you really do want to recreate bad tapes as bad tapes...

Why?

> This is some what I store as a "header" at the start of the
> overall output:

...

Yeah, this info is README fodder... why on earth program that?

> As you can see...a lot of info, but all necessary to faithfully
> reproduce the tape later and/or to understand *why* the file might
> (or can't) be used to completely reproduce the tape.

Uh, again, can't understand why you'd need to recreate bad tapes.

As to the understanding, README.DOC... etc...
 
> This is part of a product we sell on MPE/iX systems, but I'd be happy
> to document the structures and/or work with other people on standards
> in this area.
>
> There's room for potential improvement. For example, is it worthwhile
> to have a table at the front of the output file that specifies where
> the first N EOFs are?

You just used that nasty, bad word "standard"... TAP is a convention,
not a standard.

;)

However, I'm not King of this Kingdom, we're a collective
(right out of Monty Python's Search for the Holy Grail).
You might try hooking up with the emulator community and
ask your questions there.

Regards,
-doug q
Received on Thu May 02 2002 - 15:10:10 BST