[Info-vax] Backup TK50 tapes

[Johnny Billquist]

On 2013-02-26 18:35, Paul Sture wrote:
> In article <kgh0n3$gjv$1 at Iltempo.Update.UU.SE>,
>   Johnny Billquist <bqt at softjar.se> wrote:
>
>> On 2013-02-25 15:24, Paul Sture wrote:
>>> In article <kgdca9$jnv$1 at Iltempo.Update.UU.SE>,
>>>    Johnny Billquist <bqt at softjar.se> wrote:
>>>
>>>> On 2013-02-23 16:47, Stephen Hoffman wrote:
>>>>> Last time I did a dd with a tape ⤲ which was admittedly a very, very
>>>>> long time ago, as serious use of bootable tape media has been shunned
>>>>> for years ⤲ it didn't deal at all well with the differing block sizes,
>>>>> which caused all sorts of problems when replicating the media.   I don't
>>>>> know of an automatic tool to do that, other than rebuilding the kit as
>>>>> DEC VMS engineering once did, with the various tools in OpenVMS.
>>>>
>>>> Right. dd just is the wrong tool. It's really easy to throw together
>>>> your own small program to actually read blocks, and keep the block
>>>> structure around. But no standard utility for this exists. (On Unix - as
>>>> far as I know.)
>>>
>>> COPY on a Files-11 mounted tape got me most places I wanted to go here,
>>> although back in the V2 to V3 era you had to mount the tape with a
>>> sufficiently large block size to cope with files whose block size
>>> exceeded the default for MOUNT of 2048.
>>>
>>> If COPY failed (though I don't recall it doing so), I had plenty of tape
>>> reading and writing programs I could use as a template.  COBOL was
>>> excellent for this stuff; you just needed to understand that each COBOL
>>> READ of a tape mounted foreign would retrieve a whole tape block and it
>>> was up to you to unpack into records to process typical data files.
>>> Properly labelled tapes had the record and block size info in the
>>> headers.
>>
>> This is one of those times where my VMS ignorance shines through. For a
>> PDP-11 tape, COPY will not do, even if you mount the tape on VMS.
>> Yes, it is ANSI labeled. Yes, the savesets are all there.
>> However, the boot block of the ANSI tape is not visible as a file.
>>
>> But maybe it differs on a VAX with VMS?
>
> My memory isn't shining here, but I'll agree with other posters that
> tape to disk to tape wasn't the same as tape direct to tape.  I also did
> what another poster mentioned and experimented with the ordering of
> files on TU58s to get faster boot times.

TU58... Brrr.... The TK50 was a huge improvement...
Although the concept of the TU58 is nice.

Anyway, the problem with bootable tapes, at least on a PDP-11, is that 
your tape starts with a boot block. That block is read into memory, and 
the boot rom jumps into the code read in. This boot block on the tape is 
outside of what is visible as files on an ANSI-labelled tape. So you 
cannot see, or access this block except by doing low level reads from 
the tape. Any tool like COPY is unable to see or access this data.

The boot block in turn have enough intelligence to actually start 
accessing things in a more structured way. The boot roms just assumes 
that the first or second block on the tape is the boot block.

	Johnny