Backing up VAX/VMS?

Antonio Carlini arcarlini at iee.org
Sat Jan 26 07:20:07 CST 2008


Dave Dunfield wrote:
>> 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
> a CD.

That might work. It will give you something bootable but you
would normally need to do some VMS tweaking to persuade
it that the system disk is not writeable. Might not be
necessary beyond V7 or so since I believe that the latest
VMS distribution CDs are directly bootable (from [SYS1] iirc).

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

> drive ... Q1: Anyone know for sure - I would like to have an
> understanding of exactly what is going on?

I don't know what SIMH does: it might well extend as needed.

> 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

Now I'm confused. Your CD is 650MiB or so. That works out
to about 1331200 blocks (as you calculated). Can you post
the actual SHOW DEVICE DUA3:/FULL output?

For comparison, here's a logical device on OpenVMS and
its backing file:

KRAKAR> sh dev /fu lda1

Disk $1$LDA1: (KRAKAR), device type Foreign disk type 1, is online,
mounted,
    software write-locked, file-oriented device, shareable.

    Error count                    0    Operations completed
15
    Owner process                 ""    Owner UIC
[SYSTEM]
    Owner process ID        00000000    Dev Prot
S:RWPL,O:RWPL,G:R,W
    Reference count                1    Default buffer size
512
    Total blocks             1166232    Sectors per track
4
    Total cylinders            48593    Tracks per cylinder
6
    Allocation class               1

    Volume label      "OVMSVAX062L1"    Relative volume number
0
    Cluster size                   3    Transaction count
1
    Free blocks               148032    Maximum files allowed
291250
    Extend quantity                5    Mount count
1
    Mount status              System    Cache name
"_$1$DKA0:XQPCACHE"
    Extent cache size             64    Maximum blocks in extent cache
14803
    File ID cache size            64    Blocks currently in extent cache
0
    Quota cache size               0    Maximum buffers in FCP cache
854
    Volume owner UIC        [SYSTEM]    Vol Prot
S:RWCD,O:RWCD,G:RWCD,W:RWCD

  Volume Status:  subject to mount verification, do not unload on
dismount, file
      high-water marking, write-back caching enabled.

KRAKAR> ld show
_LD_Device: lda1
Connected $1$LDA1: to $1$DKA200:[LD]OVMSVAX062L1.DSK;1 (Write protect)
KRAKAR> dir/siz=all $1$DKA200:[LD]OVMSVAX062L1.DSK;1

Directory $1$DKA200:[LD]

OVMSVAX062L1.DSK;1   1166232/1166253

Total of 1 file, 1166232/1166253 blocks.

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

I believe that Nero by default creates a block-for-block copy,
which is exactly what you want.

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

No Quota file is because you have no quota file. You don't need one BTW.

The other message is OK. It's because ANA/DISK is assuming that you
have a physical device with real numbers of cylinders, sectors, tracks
etc. that match the size of the disk. Here's what the OpenVMS Wizard
says:
                   These particular CHKSCB geometry-related messages
                   reported by ANALYZE/DISK_STRUCTURE are entirely
benign,
                   are commonly and widely seen on existing recorded
                   optical media used with OpenVMS. These messages can
                   safely be ignored. An example of the messages typical
                   of an analysis of a recorded volume follows:

                   $ analyze/disk dqa1:
                   Analyze/Disk_Structure for _VMS$DQA1: started on
                   dd-mmm-yyyy  hh:mm:ss.cc

                   %ANALDISK-W-CHKSCB, invalid storage control block,
RVN 1
                   %ANALDISK-I-OPENQUOTA, error opening QUOTA.SYS
                   -SYSTEM-W-NOSUCHFILE, no such file
                   $

> ANALYZE/DISK DUA3: (the actual mounted CDROM) reports "Invalid
> storage control block, RVN 1". Q5: Why?

As above

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

I'm assuming that you're image and your physical disk size don't
match. I can only think that somewhere along the line you've
misread the output of SHOW DEVICE.

> 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?"

You can do this. Given a large enough spare disk I would go the
LD device route. Create a logical disk of an appropriate size
on your spare disk, lets callit LDA1:. INIT LDA1:, do an image
backup of your source disk onto LDA1:, dismount LDA1: and disconnect
from LDDRIVER. FTP to PC. Burn to CD. That should get you around
the bitmap size issues. If your intermediate LDA1 file is of the
right size (a multiple of 8 blocks?) then it probably fixes
the SCB warnings too, although something in the back of my mind
tells me that there is slightly more to it than that (plus it
does not matter).

>
> 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 limitation only comes into play if you try to boot from the
disk in question. The limitation applies only to the console drivers
in EPROM used to boot the system (and also to take write a crashdump).
Once OpenVMS is running it will quite happily access data disks of
up to some number of terabytes ... I've used a 9GB drive on a
VAXstation 3100 M76.

If you really do mean you want to boot from a disk that exceeds the
1.073GB limit and you really do have a system that is limited
(any VAXstation 3100 and the early MicroVAX 3100 M10/20 and that's
all iirc), then there are some tricks.


> This would also be useful to be able to do when creating a drive
> to be put on CD.

I'm not sure how you expect to fit a 1GB drive onto a 650MB CD.
Do you mean you just want to install a new system disk
temporarily?

Antonio
arcarlini at iee.org


No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.19.11/1244 - Release Date:
25/01/2008 19:44






More information about the cctech mailing list