TK50, was: Re: [TUHS] Ultrix Tape: Block Size?

[Warner Losh]

On Thu, Oct 18, 2018 at 7:23 AM Paul Koning via cctalk <
cctalk at classiccmp.org> wrote:

>
>
> > On Oct 18, 2018, at 4:31 AM, Christian Corti via cctalk <
> cctalk at classiccmp.org> wrote:
> >
> > On Wed, 17 Oct 2018, Clem Cole wrote:
> >> As Paul W pointed out correctly, the TK50 and its children in the DLT*
> >> family all used a fixed format 512 byte *blocks on the tape*.    This
> >
> > And that is wrong. The TK50 clearly uses variable block sizes. For
> example, have a look at a RSX11 or VMS tape: ...
>
> Different point.  You're talking about the host programming interface;
> Clem was talking about the physical representation of the data on the
> tape.  Clearly it's easy to accept random-length blocks from the host and
> translate them to a sequence of 512 byte blocks on the media.  SIMH is an
> example of how that is done: it stores tape images as a count field plus
> data, laid down in a disk file that internally consists of a sequence of
> fixed length (512 bytes, traditionally) sectors.
>

Although they may be on the tape in some funky way, there's a higher layer
in the protocol stack that imposes block length, and if that's not properly
honored, the tapes written for Ultrix won't work when read back. You can't
write weird block lengths and expect the applications that read it
downstream to work. I have a vague memory of lecturing one of the
hydrologists I worked for in college on this point when they were sloppy
with their reading / writing of a TK50 with their water flow data on it...
The code fix, which I wound up doing, was easier than explaining this
concept to the hydrologist who, while he knew finite difference code better
than I ever learned, had trouble understanding record boundaries....  In
the end, though, we got a larger disk so we could stage / unstage multiple
runs of data at once and then used VMS' BACKUP to save them to tape... The
TK50's were a *LOT* faster when the only job on the system was BACKUP since
they could stream and none of the other OS activity could get in the way...

Warner