putrec() in tapeio.c is missing TF_SIMH support

[mossbeachlarry]

tapedump, taperead, and tapewrite support an option -s to enable SIMH .TAP image file format (tape_flags |= TF_SIMH). In a SIMH .TAP file, odd-length records are padded to an even number of bytes when written to the file. The extra padding bytes are discarded when the records are read.

getrec() in tapeio.c implements SIMH .TAP image file format with code that discards the extra padding bytes when TF_SIMH is enabled:

  if ((l & 1) != 0 && (mtape->flags & TF_SIMH) != 0)
    doread (mtape->tapefd, &x, 1);

However, putrec() in tapeio.c does not have any code that implements SIMH .TAP image file format, i.e., putrec() does not add padding for odd-length records when TF_SIMH is enabled.

The result is that the -s option is silently ignored by tapewrite, leaving the user with the mistaken impression that the image file created is SIMH .TAP format when it might not be, i.e., if the input tape happens to contain any odd-length records (an extremely unusual possibility, I admit).

Otherwise, tapewrite -s looks like exactly what I am looking for to rescue a collection of old archive tapes so that I can go through them at my leisure using a SIMH VAX/VMS system.

Thank you,

Larry Baker

[mossbeachlarry]

Looks like I'm not so lucky after all.

I was wrong about tapewrite; tapecopy is the program I should use to transfer a mag tape to a SIMH .TAP image file, but tapecopy does not support the -s option. That should not be hard to add once putrec() is modified to support the TF_SIMH flag.

Worse, though, I see in every tape utility the reader logic assumes double tape marks mean end-of-tape. That makes it impossible to copy an ANSI labeled tape containing a zero-length file. You have to keep reading, but for how long when I/O is being done using file system I/O, not raw tape I/O?

When I worked with tapes in the past it was on PDP-11 RSX-11 and VAX VMS. As I recall, I made calls directly to the mag tape subsystem. I think there was a way to detect the physical end-of-tape reflector (EOT). There certainly is when doing a write. But that is not an error. When EOT is detected, the writer is supposed to "wrap things up" and continue on another reel, for multi-volume labeled tapes, or inform the user the tape is full and quit. Reads are trickier. By convention, a double tape mark means end-of-volume, except in the data section of a file on a labeled tape. I don't see any logic in the tapeio library that knows this. Since it is perfectly legal for data to be written past the EOT reflector, you can't simply use EOT to stop reading either.

I am not sure how anyone can make a tape image file of a complete ANSI or IBM labeled tape without extra logic in the tapeio code. I have written mag tape analyzers that will detect ANSI and IBM labeled tapes. I suppose that kind of logic would have to be added, probably by default, with an option to suppress label detection, or to force ANSI or IBM label processing (others? TOPS?).

Rats.

Still, I think it is worth supporting the -s command line option in all the tape utilities and tapeio.c.

Thank you,

Larry Baker