[Info-vax] Backup TK50 tapes

[Paul Sture]

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:
> > On 2013-02-23 15:16:11 +0000, supervinx said:
> >
> >> Before any misunderstanding will occur...
> >> Together with a VAX4000/300 I rescued some original TK50 tapes.
> >> They contain VMS 5.5, 5.5-1 and they seem not to contain any saveset,
> >> but only
> >> *.EXE files (VMB.EXE, SYSBOOT.EXE...) so they looks like bootable tapes.
> >> Am I wrong?
> >> Since I never installed VMS except from a CD, I'm dubious about boot
> >> tapes.
> >
> >
> > Presuming you have the necessary permission to replicate these files,
> > you can MOUNT the magtapes Files-11 (not /FORIEGN), extract the OpenVMS
> > VAX installation files — the .A, .B, .C, etc. saveset files that are
> > after all the OpenVMS VAX baggage needed for a sequential OpenVMS VAX
> > bootstrap — with DCL commands including COPY, and then transfer those
> > files to the target system via LD, done.
> 
> I have not looked at how bootable tapes under VMS looks like, but if 
> they are anything like under PDP-11, this would give you all the regular 
> stuff, like the savesets, but it misses the boot blocks and related 
> data, since that is not visible as a file on the ANSI tape format.

STABACKIT.COM could also be used to build a standalone backup on disks. 
I did poke around inside the procedure many moons ago and vaguely recall 
that if the target was a disk, WRITEBOOT.EXE was invoked with the 
necessary values.  Building on the system disk would default to IIRC the 
[SYSE] system root.  Again IIRC the [SYSF] root was reserved for use as 
a scratch area in VMS upgrades.  Someone will no doubt correct me if I 
got those the wrong way around.

I would routinely build standalone backup on at least the system disk 
and a couple of non-system disks so that I could avoid the prolonged 
time it took to load standalone backup from TU58 tapes in the pre-TK50 
era.

Incidentally you didn't need to put standalone backup in front of all 
your backup tapes.  It was possible to boot off a tape containing 
nothing else, deliberately enter a command with a syntax error to get 
the system to read the whole of S/A backup into memory, then unload the 
tape and insert the tape of your choice.

In a similar manner you could boot S/A backup from the disk you wanted 
to overwrite, force it all into memory via a deliberate syntax error, 
then perform your restore operation.

> > 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.

> By the way, if you have a current RSX system, there is a tool in there 
> to do exactly this work.

-- 
Paul Sture