26 Jan
2008
26 Jan
'08
1:20 p.m.
Dave Dunfield wrote:
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).
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. 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