18 Oct
2018
18 Oct
'18
6:50 a.m.
On Thu, Oct 18, 2018 at 7:23 AM Paul Koning via cctalk <
cctalk at classiccmp.org> wrote:
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
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:
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.
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