14 Jan
2008
14 Jan
'08
3:22 a.m.
Building on previous posts:
Standalone backup can be installed on the system drive, it gets
installed as [.SYSE] and is then started by:
>> B /R5=E0000000 DKA300
Any disks it needs to use must be ready before it goes looking for them
during initialisation.
The one off creation of the standalone backup kit (i.e. [.SYSE]) goes
something like:
$set def sys$update
$@stabackit
[Ref VMS System Manager's Manual]
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 1 Gby. This means
that you can't use it with RZ27/28/29 StorageWorks (1/2/4/8/.. Gby)
disks.
On a machine with a SCSI bus and with spare scsi disks to hand my
preference would be to write the backup to another blank scsi disk as a
save set, and then to archive the backup on modern hardware. The save
set condenses the disk to it's minimal file size, and on restore you get
a "fresh" copy with contiguous files. The basic incantation is:
$init DKA200 volnam /nohigh
$backup/image/verify DKA300: DKA200:filename.sav/save
It's best practice to fix up any lint on the disk prior to backing up /
archiving it, i.e. to resolve any block allocation / file index
inconcistencies:
$analyse/disk DKA300: -- generates a list of issues
$analyse/disk/repair DKA300: -- lists and fixes any issues
$analyse/disk/read DKA300: -- reads all the blocks and tells you which
ones have irrecoverable parity errors
With three spindles on a system you can produce a compact copy of a disk
image, with the file index at the beginning rather than the centre of
the disk. One spindle runs the system and backup, another disk (which
could also be the system disk) has a saveset copy of the imaged disk on
it, the final disk will be initialised and have the saveset written to
it.
$initialise dkb000 /index=beginning/nohighwater
$mou/foreign dkb000:
$backup/image/verify/noinitialise dka200:filename.sav/save dkb000:
The reason for doing this used to be to produce the smallest possible
"necessary" disk image for burning on a CD or whatever. Nowadays, I
would probably copy the entire disk - GigaBytes are cheap, ensuring you
have copied to the HWM can be expensive. Obviously, a live disk volume
should have the file index in its default location at the centre of the
disk.
IIRC there are/were some (free) SalesWare utilities which permit
Files-11 disks to be mounted on XP and read. This would provide a much
neater (and safer) way of eliciting the .sav (save set) file for
archival on a PC than croping an image at it's high water mark.
However, dd of the entire disk containing the savesets may be even
better.
Regards
Martin
26 Jan
26 Jan
6:40 a.m.
From:"Martin Bishop"
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
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?"
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
1 Gby.
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
8:20 a.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
9:40 a.m.
Thanks Antonio, good info and more Q's
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).
I left out an important point - I'm really only interested in booting
stand-alone backup off of the CD.
I successfully did this under the simulator since my last message.
I couldn't figure out how to make stand-alone backup write to a saveset
on a disk drive - It kept telling me that I had to have only a device
name in the destination. I had hoped that I could just install stand-alone
backup on a blank disk and then use it to create it's own saveset from
the system disk...
So I did:
Mounted a scratch disk on DUA1
Stand-alone backuped/image DUA0 (the boot disk to DUA1) - Now DUA1
is a copy of the system disk.
Rebooted to DUA0, then used live BACKUP to backup/image DUA1 to
a file called SYSTEM.SAV on DUA0 (There's lots of space)
INIT/index=beginning DUA1:
[I used /index=beginning to put the storage allocation information
at the beginning of the CD so it wouldn't have to keep seeking out
to the middle - Other than that, I assume it would work without it.]
Then I used @stabackit to install stand-alone backup to DUA1:,
then I copied SYSTEM.SAV to DUA1:[000000]SYSTEM.SAV
Shutdown and attached the file formerly on DUA1 to SIMH as a CDROM,
then booted from the CD - stand-along backup came up and I was able
to restore SYSTEM.SAV to another virtual disk, then boot that disk
and it all worked.
Next step is to get an image of my VMS 5.5 drive (probably DD under
netbsd and then FTP it over) and see if I can do it again - once that
works, I'll try and burn a physical CD.
Do you know a reason why VMS would write that "high" on the drive
during a simple restore (minimal system) and subsequent boot. I
know it would put dir/maps in the middle, but this is a fair way
above the middle.
I don't know if I can capture the output of SIMH, but I will
try to do this on a real vax later today and capture the output.
I didn't do /FULL, this was just the #blocks listed in the short
listing.
I guessed as much.
No SHOW DEV involved - the 1331208 number came by dividing the actual
size of the CD image file by 512. - Just looking to understand why it
behaves differently - Perhaps SIMH adjusts the blocksize somehow, so
this is not the actual size of the disk created.
Yes, I really do mean it - I have two 3100 series machines which suffer
What I mean is that I want to create a 650M image to burn to the CD,
however I don't have any 650M drives - I've got LOTS of 1G drives,
so if I could mount them smaller (650M or less) I could create a
filesystem on them that will fit on a CD.
But I don't think it really matters - What I will probably do is
transfer an image of the drive to SIMH where I can then perform a
backup of it to a virtual disk which can be any size I want.
Q: Is stand-alone backup from OpenVMS 7.x compatible with older
version filesystems? - If I backup my VMS 5.5 disk using stabackup
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. 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? 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. 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. 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.
Wouldn't this result in trying to boot a full image on the CD (although
I could specifically boot stabackup assuming it's on the image). My
goal was to put stabackup and a save set on the CD.
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. from the limitation, and I want to put 1G drives in
them - but all of
my 1G drives are "just a little too big". Please
elaborate on the "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? from 7.2, and restore it with same, will I get a
workable VMS 5.5
system disk again? I haven't tried booting 5.5 under SIMH yet
- If
for some reason it doesn't work, then I may need to do this with
the OpenVMS utilities.
Thanks again,
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
11:35 a.m.
Dave Dunfield wrote:
Do you know a reason why VMS would write that
"high" on the drive
during a simple restore (minimal system) and subsequent boot. I
know it would put dir/maps in the middle, but this is a fair way
above the middle.
I don't know exactly where the issue lies here. You have a virtual
1.5GB RA92. SIMH hasn't seen fit to ask for a 1.5GB file yet,
just a 1GB one. I presume that this means that SIMH will grow the
file dynamically. As for why that much of the disk has been used,
I don't know. I do know that and image backup followed by a
restore was the recommended way of defragmenting disks
for a long time. So backup will "rearrange" things. I guess it boils
down to how the filesystem goes looking for available blocks,
and I don't remember how that works in detail. I do know
that the default INIT places the bitmap and other "high usage"
things in the middle (as you've found). That's because it used to cut
down
seek times back in the days of days of RA60s and RL02s.
It may well be that the allocation scheme works from the middle
of the disk outwards, or something like that.
I don't know if I can capture the output of SIMH,
but I will
try to do this on a real vax later today and capture the output.
I didn't do /FULL, this was just the #blocks listed in the short
listing.
If it's this one:
KRAKAR> sh dev dka0
Device Device Error Volume Free
Trans Mnt
Name Status Count Label Blocks
Count Cnt
$1$DKA0: (KRAKAR) Mounted 0 OPENVMS071 28246713
424 1
KRAKAR>
then that's just the _free_ block size.
No SHOW DEV involved - the 1331208 number came by
dividing the actual
size of the CD image file by 512. - Just looking to understand why it
behaves differently - Perhaps SIMH adjusts the blocksize somehow, so
this is not the actual size of the disk created.
Going back to your RA92 initial query, that's a 1.5GB disk. So that's
roughly 3,000,000 blocks, give or take. You installed VMS onto that.
What you saw was 2,479,032 blocks, but if that's the output of SHOW DEV
(and not SHOW DEV/FULL) then that's the free blocks. So your VMS install
ate up 500,000 blocks (or ~250MB or so). The exact size of the VMS
install
depends on how big a PAGEFILE and SWAPFILE you gave it, but 250MB
seems perfectly reasonable.
Given what you say, I think that you are reading the output of SHOW DEV
and not realising that this is the number of free blocks. Maybe.
Wouldn't this result in trying to boot a full
image on the CD
(although
I could specifically boot stabackup assuming it's on the image). My
goal was to put stabackup and a save set on the CD.
You want a bootable CD along with a saveset that you can then use
to restore to a new disk? That's fine. I'd still go the LD route,
backing up to a saveset on the LD disk and building SABKP on the
LD disk, but I just like LD :-)
If you are doing this to restore a data CD you don't strictly
need SABKP on that CD. You can build SABKP on any disk attached
to the machine: so you can install SABKP on the system disk. Then
you boot SABKP off the system disk (/R5=E0000000 iirc) and
restore the saveset.
Back in the day, there was a strong recommendation to having
SABKP on the system disk (and on a few data disks too, in case
the system disk was the one you needed to restore and its
SABKP had gone south). Booting a SABKP on a VAX-11/750 off a
local disk took a few minutes. Doing the same thing using
TU58 took almost an hour (and you needed to swap TU58s once
or twice!). There was even a command procedure that would
"optimise" your TU58s by putting stuff on there in the order
that the boot process asked for them - shaved maybe 10 minutes
off the overall time!
Yes, I really do mean it - I have two 3100 series
machines which
suffer from the limitation, and I want to put 1G drives in them - but
all of
my 1G drives are "just a little too big". Please elaborate on the
"tricks".
What I mean is that I want to create a 650M image to burn to the CD,
however I don't have any 650M drives - I've got LOTS of 1G drives,
so if I could mount them smaller (650M or less) I could create a
filesystem on them that will fit on a CD.
Pick up LDDRIVER from the OpenVMS Freeware and install. Use
SYSGEN to create a 650MB contiguous file on your 1GB disk, tell
LD about the file and have it map LDA1: to it. You now have
a 650MB disk (LDA1:) that is conveniently stored on your
disk as a file.
But I don't think it really matters - What I will
probably do is
transfer an image of the drive to SIMH where I can then perform a
backup of it to a virtual disk which can be any size I want.
That also works.
Q: Is stand-alone backup from OpenVMS 7.x compatible
with older
version filesystems? - If I backup my VMS 5.5 disk using stabackup
from 7.2, and restore it with same, will I get a workable VMS 5.5
system disk again? I haven't tried booting 5.5 under SIMH yet - If
for some reason it doesn't work, then I may need to do this with
the OpenVMS utilities.
It most certainly had better be backwards compatible at least as
far as ODS-1 used on VAX/VMS 1.0! OK, I've never gone that far
back, but I would consider it a bug (and a fairly serious one, given
that this is BACKUP!) if this did not work.
Antonio
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
3:06 p.m.
Thanks again for the info...
It may well be that the allocation scheme works from
the middle
of the disk outwards, or something like that.
Agreed. I'm not going to worry about it.
Given what you say, I think that you are reading the
output of SHOW DEV
and not realising that this is the number of free blocks. Maybe.
Uh-huh ... yup yup ... thats exactly it (and there's even a label on the
column "FREE") ... Foolish me. Looking at the total counts with /FULL
everything makes sense now.
You want a bootable CD along with a saveset that you
can then use
to restore to a new disk? That's fine. I'd still go the LD route,
backing up to a saveset on the LD disk and building SABKP on the
LD disk, but I just like LD :-)
Main reason I want to do this without adding software etc. is that I've
just gotten the system, and I want to preserve the system disk exactly
as I received it *before* I go adding/changing/removing things...
Good news is that it all worked. I put the drive in my NetBSD VAX and
dd'd the content into a file, then FTP'd it over to the PC where I
mounted it under SIMH - I could read it just fine, however VMS 5.5
wouldn't boot under SIMh - it reported a whole bunch of bad licenses
(not surprising) and crash/dumped almost all the way through the
boot process - I tried it a few times trying to "catch" the output
with CTRL-S to see what exactly was failing, but I was unsuccessful
(I guess I need a slower system for SIMh).
Anyway, using VMS 7.2 BACKUP I created a save set from the VMS 5.5
disk which I copied to a CD image with VMS 7.2 stand-alone restore.
Then I burned a disk from that with Nero - and amazingly it all
works - I can boot the CD on the original system (4000 VLC) and
restore the save set to a never-vmsed-before drive and it then
boots up and runs! (whew!)
I do have one question relating to a difference - see later:
Booting a SABKP on a VAX-11/750 off a
local disk took a few minutes. Doing the same thing using
TU58 took almost an hour (and you needed to swap TU58s once
or twice!).
Yeah - I tried booting it from a DAT drive once ... I have it
on the SYSE boot of my system disk, and also on CD (it's not
bad from CD).
Pick up LDDRIVER from the OpenVMS Freeware and
install. Use
SYSGEN to create a 650MB contiguous file on your 1GB disk, tell
LD about the file and have it map LDA1: to it. You now have
a 650MB disk (LDA1:) that is conveniently stored on your
disk as a file.
I read about doing this - but what about the system disk case.
You can't boot from an LD disk can you? (I assume the LD doesn't
exist until you are booted?) If the system crash-dumps it could
wipe out the root of the drive due to the 1G wraparound.
I'd really like to be able to use my 1.09G drives as system drives
in the 3100's (next closest I have is a few RZ23's (100m).
Now my question:
I see a difference when I boot the system from the original drive,
and the backups - this happens with BOTH the direct drive to drive
backup that I origianlly made, and also when restored from the
saveset (Both restores boot the same, which is different from the
original drive).
Basically I'm getting a message from AUTID$SERVER saying that there
is an event (security alarms disabled) that does not occur when booting
from the original drive.
A couple of other messages come out in a slightly different order - I
expect this is just due to asynchronous processes during startup, and
I have not verified that they always come out in this order...
Here is an abbreviated listing of the console output during booting
the system:
B> Indicates output that occurs on both Old and New drives
O> Indicates output that occurs on the Old drive
N> Indicates output that occurs on the New drive
Most of the N> / O> differences are rearranged messages that I indicated
above, however the audit message occurs only on the N>ew drive ... Can
you tell me what this means, and what is different about the restored
system from the original? I can send you the complete console boot logs
if needed.
B> VAX/VMS Version V5.5 Major version id = 1 Minor version id = 0
B>%STDRV-I-STARTUP, VMS startup begun at 1-JAN-2000 00:15:43.09
B>The VAX/VMS system is now executing the system startup procedure.
B>%SET-I-NEWAUDSRV, identification of new audit server process is 00000048
B>%%%%%%%%%%% OPCOM 1-JAN-2000 00:16:37.16 %%%%%%%%%%%
B>Operator _MAGVS8$OPA0: has been enabled, username SYSTEM
B>%%%%%%%%%%% OPCOM 1-JAN-2000 00:16:37.31 %%%%%%%%%%%
B>Operator status for operator _MAGVS8$OPA0:
B>%%%%%%%%%%% OPCOM 1-JAN-2000 00:16:37.59 %%%%%%%%%%%
B>Logfile has been initialized by operator _MAGVS8$OPA0:
B>%%%%%%%%%%% OPCOM 1-JAN-2000 00:16:37.60 %%%%%%%%%%%
B>Operator status for operator MAGVS8::SYS$SYSROOT:[SYSMGR]OPERATOR.LOG;354
B>%%%%%%%%%%% OPCOM 1-JAN-2000 00:16:40.33 %%%%%%%%%%%
B>Message from user SYSTEM on MAGVS8
B>Warning: DECdtm log file not found (SYS$JOURNAL:SYSTEM$MAGVS8.LM$JOURNAL)
B> %RMS-E-FNF, file not found
B> TP server process waiting
B>The VAX/VMS system is now executing the site-specific startup commands.
B>%RUN-S-PROC_ID, identification of created process is 0000004C
B>%%%%%%%%%%% OPCOM 1-JAN-2000 00:16:43.71 %%%%%%%%%%%
B>Message from user DECNET on MAGVS8
B>DECnet starting
N>%NCP-I-NOINFO, No information in database
N>%RUN-S-PROC_ID, identification of created process is 0000004E
B>%%%%%%%%%%% OPCOM 1-JAN-2000 00:16:49.54 %%%%%%%%%%%
B>Message from user DECNET on MAGVS8
B>DECnet event 4.10, circuit up
O>%NCP-I-NOINFO, No information in database
O>%RUN-S-PROC_ID, identification of created process is 0000004E
O>%MOUNT-F-NOSUCHDEV, no such device available
--- This is the additional message I get on the backups ---
N>%%%%%%%%%%% OPCOM 1-JAN-2000 00:16:51.87 %%%%%%%%%%%
N>Message from user AUDIT$SERVER on MAGVS8
N>Security alarm (SECURITY) and security audit (SECURITY) on MAGVS8, system id: 1632
N>Auditable event: Security audit alarms disabled
N>Event time: 1-JAN-2000 00:16:51.77
N>PID: 00000043
N>Username: SYSTEM
N>Auditing flags: ACL,MOUNT,AUTHORIZATION,INSTALL
N> BREAKIN: (DIALUP,LOCAL,REMOTE,NETWORK,DETACHED)
N> LOGIN: (BATCH,DIALUP,LOCAL,REMOTE,NETWORK,SUBPROCESS,
N> DETACHED)
N> LOGFAIL: (BATCH,DIALUP,LOCAL,REMOTE,NETWORK,SUBPROCESS,
N> DETACHED)
N> LOGOUT: (BATCH,DIALUP,LOCAL,REMOTE,NETWORK,SUBPROCESS,
N> DETACHED)
N> FAILURE: (READ,WRITE,EXECUTE,DELETE,CONTROL)
N> SUCCESS: (READ,WRITE,EXECUTE,DELETE,CONTROL)
N> SYSPRV: (READ,WRITE,EXECUTE,DELETE,CONTROL)
N> BYPASS: (READ,WRITE,EXECUTE,DELETE,CONTROL)
N> GRPPRV: (READ,WRITE,EXECUTE,DELETE,CONTROL)
N> READALL: (READ,WRITE,EXECUTE,DELETE,CONTROL)
O>%MOUNT-F-NOSUCHDEV, no such device available
B>*** Start Configure VCP300 KL- May /93 ***
B>%RUN-S-PROC_ID, identification of created process is 0000004F
B> LAT Control Program
B>%SYSTEM-W-NOSUCHDEV, no such device available
B>*** Done Configure VCP300 KL- May /93 ***
B>%SET-I-INTSET, login interactive limit = 64, current interactive value = 0
B> 1-JAN-2000 00:17:06
B>%RUN-S-PROC_ID, identification of created process is 00000051
B> SYSTEM job terminated at 1-JAN-2000 00:17:33.82
B> Accounting information:
-- The I/O counts, page faults etc. are slightly different
Thanks again.
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
27 Jan
27 Jan
4:32 p.m.
Dave Dunfield wrote:
It's no good for the system disk. I use it either to produce
a container file that is just the right size for a CD or to
match some other disk I'm restoring. The former comes in
handy for burning an ODS-2 CD or a mixed ISO9660/ODS-2 CD
and the latter is useful if I have a disk from another
system that I want to browse on my current box (since a
disk from a real VMS system - at least from the era that
I'm interested in - is likely to be 1.5GB or less, I
can have a copy of said disk available as a disk on
my box; then I can assign logicals etc and have it available
almost exactly as it was on the original system.)
Good news is that it all worked. I put the drive in my
NetBSD VAX and
dd'd the content into a file, then FTP'd it over to the PC where I
mounted it under SIMH - I could read it just fine, however VMS 5.5
wouldn't boot under SIMh - it reported a whole bunch of bad licenses
(not surprising) and crash/dumped almost all the way through the
boot process - I tried it a few times trying to "catch" the output
with CTRL-S to see what exactly was failing, but I was unsuccessful
(I guess I need a slower system for SIMh).
If it crashes and you have a dumpfile and you've not set it up not to,
then the system will store crashdump information in the dumpfile.
You can then use ANALYZE/CRASH to try and work out why
it died.
As for the bad licences, what exactly does the message say?
Once you've booted, SHOW LIC/LIST will tell you exactly
what is there and LICENCE LOAD <whatever> should try
to load up just one of them.
There could be any of a dozen issues, for example
licences can be disabled, the checksum might be wrong,
etc. Try loading a few and see what message comes
out.
Note that the output of SHOW LIC/LIST (and LICENSE LIST/FULL
for that matter) will not list the licence checksum, which
you need if you want to preserve a worthwhile record of an
actual licence. For that you need to to do something like:
$ LICENSE LIST/PROCEDURE * /OUT=MY-LICENCES.COM
This will produce a command procedure that you can
invoke to load up an empty licence database with your
licences. As a side-effect, it disables all issued
licences in your current database, so you need
to enable them again.
Pick up
LDDRIVER from the OpenVMS Freeware and install. Use
SYSGEN to create a 650MB contiguous file on your 1GB disk, tell
LD about the file and have it map LDA1: to it. You now have
a 650MB disk (LDA1:) that is conveniently stored on your
disk as a file.
I read about doing this - but what about the system disk case.
You can't boot from an LD disk can you? (I assume the LD doesn't
exist until you are booted?) If the system crash-dumps it could
wipe out the root of the drive due to the 1G wraparound.
I'd really like to be able to use my 1.09G drives as system drives
in the 3100's (next closest I have is a few RZ23's (100m). I see a difference when I boot the system from the
original drive,
and the backups - this happens with BOTH the direct drive to drive
backup that I origianlly made, and also when restored from the
saveset (Both restores boot the same, which is different from the
original drive).
Basically I'm getting a message from AUTID$SERVER saying that there
is an event (security alarms disabled) that does not occur when
booting from the original drive.
A couple of other messages come out in a slightly different order - I
expect this is just due to asynchronous processes during startup, and
I have not verified that they always come out in this order...
Here is an abbreviated listing of the console output during booting
the system:
FWIW, the B>, O> N> designations showed up in your
email but vanished as I tried to reply. I expect Outlook
mangled them and I expect it is about to do the same again
in this message ...
O>%MOUNT-F-NOSUCHDEV, no such device available
This means what you would expect it to mean: the startup
could not find some device or other. I'm guessing that
when you boot the Original it was as DKA0: (SCSI ID 0)
and when you booted the New one it was DKA100: (SCSI ID 1).
Or some other minor difference between the Orignal
and New systems.
N>%NCP-I-NOINFO, No information in database
N>%RUN-S-PROC_ID, identification of created process is 0000004E
You list this both for N> and O>. It is DECnet starting up.
Indicates output that occurs on both Old and New
drives
Indicates output that occurs on the Old drive
Indicates output that occurs on the New drive
Most of the N> / O> differences are rearranged messages that I
indicated above, however the audit message occurs only on the N>ew
drive ... Can you tell me what this means, and what is different
about the restored system from the original? I can send you the
complete console boot logs if needed. > %%%%%%%%%%% OPCOM 1-JAN-2000 00:16:51.87
%%%%%%%%%%%
> Message from user AUDIT$SERVER on MAGVS8
> Security alarm (SECURITY) and security audit (SECURITY) on MAGVS8,
> system id: 1632 Auditable event: Security audit alarms
> disabled
This indicates that a command during the startup changed what should
and should not be audited. No idea why it would happen on N but not O.
Unless there's something clever in there that decides to enable
auditing but only if there's enough free space? In which case
differences between the disk used for N and O would account for it.
If you want to follow this up, email me the
SYS$MANAGER:SYSTARTUP_VMS.COM procedure and we can take
it from there. (BTW: I know we've had email problems before
when I tried to send you some stuff to do with having tested
various floppy controllers on motherboards; so if you
don't hear anything back, revert to the mailing list. Or
maybe get a throwaway gmail account - I'm sure my gmail will
be able to talk to your gmail!).
> *** Start Configure VCP300 KL- May /93 ***
This sounds like the Datability VCP300 terminal server.
You might have some interesting software lying around
there!
Antonio
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.19.12/1245 - Release Date:
26/01/2008 15:45
28 Jan
28 Jan
9:17 a.m.
Hi,
renamed SYSTARTUP_V5.COM on a copy of the disk under SIMH
and without it it does boot - so it's definately something
in the startup files that crashing it.
I didn't get LICENSE LIST/PROC to work, but I found
LICENSE ISSUE/PROC which I think is what you intended.
I extracted the license and was surprised to discover
that there's no hardware ID in them - so I dug a bit
deeper and discovered SHOW LICENSE/CHARGE which indicates
to me that SIMH is simulating a VAXserver which does not
permit VAXstation licenses - the VAX-VMS 5.5 license
indicates that it's 'D' (VAXstation). This is probably
why it will not activate.
I have another big (5.25") drive with VMS 5.4-1 on it.
I can boot it but it requests for other drives to be
mounted and can't go any further.
It's got a LOT of stuff on it. I have trouble mounting
it under OpenVMS7.2 because it keeps going offline and
then remounting with mount verification - I don't know
why it does this. I did manage to copy off the license
.LDB file and used license issue/proc * /DATA=file to
extract the license data from it. There are a total of
490 licenses installed on it! I can send you the list
if you want to see if there's anything on there of
interest/worth trying to recover.
It has an unrestricted VAX-VMS license - I hoped I might
be able to use it for the VMS 5.5 under SIMH, however it
complains about the product release date - apparently
it's not valid for a newer version of VMS.
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
9:23 a.m.
Hi,
renamed SYSTARTUP_V5.COM on a copy of the disk under SIMH
and without it it does boot - so it's definately something
in the startup files that crashinh
That was supposed to be off-list.
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
5997
days inactive
6011
days old
8 comments
3 participants
participants (3)
-
arcarlini＠iee.org -
dave06a＠dunfield.com -
mjd.bishop＠emeritus-solutions.com