Backing up VAX/VMS?
dave06a at dunfield.com
Sat Jan 26 05:40:30 CST 2008
>Building on previous posts:
>Standalone backup can be installed on the system drive, it gets
.. Lots of useful information snipped ..
Thanks for the information. I've been digesting it, experimenting
and learning. I've successfully backed up the VMS 5.5 to another
larger drive, and put the original 100mb drive away for safekeeping.
I've got it in my head that what I would really like to do is to
make a bootable CD which I can use to restore the system in much
the same way as the OpenVMS CD.
>From what I've read, creating a bootable CD for a VAX consists of
essentially building a bootable file system on a 650m hard drive,
reading that drive into a binary image, and writing that image to
To test some of this out, I installed SIMH/VAX on a PC with a CD
burner. A number of questions have surfaced ...
I was able to rip the single track from the OpenVMS CD with Nero
and boot it on SIMH - from there I installed OpenVMS 7.2 onto a
virtual RA92 drive.
This created a file 1,047,094,272 bytes in size. Looking at this
I assumed that SIMH must "format" the entire drive when you first
write to it (the file didn't exist until I installed OpenVMS).
Dividing /512, I expected to see 2,045,106 bytes with the SHOW
DEVICE command, or perhaps a slightly smaller number if some
"overhead" is not shown, however I see that it haws 2,479,032
blocks - over 400,000 more than exist in the file. Possible
explaination is that SIMH only grows the file as required, and
for some reason the OpenVMS install wrote data "up high" on the
drive ... Q1: Anyone know for sure - I would like to have an
understanding of exactly what is going on?
Moving on the CD, I mounted DUA3: (the CD) and SHOW DEV gave me
2479032 blocks. I then created a DUA2 in SIMH with this many
blocks pointed at a copy of the CD image file ... tried to mount
it and got that it was unreadable.
Checked the OpenVMS.ISO file that I got from Nero and it was
681,578,496 bytes in size. /512 gives me 1331208. Creating the
virtual DUA2: with this number of blocks worked! - I could
mount and read the CD image as a normal drive.
Q2: Why the large discrepancy between the actual size of the
CD file and the # blocks reported by SHOW DEV
Q3: I half expected this never to work, because I assumed the
.ISO file from Nero contained "CD formatting" - I could also
ask for a .IMG file but it was slightly larger hence I assume
"more formatting" Does SIMH recognize ISO images when mounted
as normal drives, or is this in fact a binary image?
ANALYZE/DISK DUA2: reported that the size of the bitmap was
smaller than the physical device (but no other errors except
for "no QUOTA file"). Q4: Why?
ANALYZE/DISK DUA3: (the actual mounted CDROM) reports "Invalid
storage control block, RVN 1". Q5: Why?
Reducing the size of the virtual hard drive to 1331200 blocks
resulted in DUA2 behaving exactly like DUA3 (mounts OK, read
files OK, no longer reports "bitmap too small", does report the
same "Invalid storage control block, RVN 1")...
Q6: Does all this make sense - can I actually read a drive into
a binary file, burn it to a CD and then boot/access it? Or am I
"persuing of an undomesticated ornithoid?"
>Standalone backup has some limitations, e.g. at ~V5.5 it only
>supports a cluster size of 1; i.e. it only supports disks up to
I have quite a few SCSI drives which are slightly larger than the
1.06g limit ... 1.08 and 1.09 - I've checked, and they do exceed
the original SCSI command set addressing by a few thousand blocks.
I understand that this is a problem for my 3100 series VAXen ...
Is there a way to intentionally initialize a drive with a specific
size (in this case slightly smaller than it's actual size).
This would also be useful to be able to do when creating a drive
to be put on CD.
dave06a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
More information about the cctech