27 Jan
2008
27 Jan
'08
9: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