Backing up VAX/VMS?

.. 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. essentially building a bootable file system on a 650m hard drive, reading that drive into a binary image, and writing that image to a CD. 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?" Related question: 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. Dave -- dave06a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Collector of vintage computing equipment: http://www.classiccmp.org/dunfield/index.html