Sorry, read your message backwards apparently....
I would look into sys$system:writeboot.exe. It hardcodes the device name
and location on disk of the minimal boot files. Your location on disk is
the same so theboot worked but I wonder if the incorrect device name is
lousing your logicals.
You can use writeboot to reset things correctly.
On Mon, 2 Oct 2000, Chuck McManis wrote:
Hi Paul,
This isn't an allocation class issue. Its something I brought on myself,
and for that am paying the price :-). My true question is whether or not
I'm going to be stuck re-installing VMS, however given the way VMS works
I'm sure there is some voodoo to fix it.
I got in this mess as follows:
I installed an RF72 drive into my 4000/200 and proceeded to do a 'sho dev'
on it. It showed up on the DSSI bus as $24$DIA264:
I then installed VMS 7.2 on to this drive, followed by a bunch of layered
products.
Then I read in the KA660 technical manual how to "talk" to the DSSI drives,
(which is very arcane using the KFQSA but a snap on the KA640 and KA660)
and proceeded to tell the drive to call itself node SYSTEM and unit 0.
This worked fine, and I noted that I could now boot the system by
specifying DIA0: rather than DIA264: (which I never could remember anyway).
Then I went to install another layered product. That installation failed
because it couldn't find a file is was expecting in
SYS$SYSDEVICE:[SY0.SYSTEMP] (or something very similar). So I did a dir
SYS$SYSDEVICE: and sure enough there was nothing there, then I did a SHOW
LOGICALS and from there discovered that SYS$SYSDEVICE: was defined to be
$24$DIA264: (the original name of the DSSI drive)
Now I could name it back again. But I'd rather tell VMS where the SYSDEVICE
now sits (for all the system, like on a permanent basis). If I 'define' it,
it changes for the current process but doesn't change universally and more
importantly other things are stuck that way to.
Nothing is
SYSTARTUP_VMS.COM defines these so they must be in a parameter
database somewhere else. That is where I'm looking now ...
On a somewhat related note, I went out and forked over $100 for a true 5
port switch so that I can put my VLC cluster on a switch! Now all I need is
a console multiplexor.
--Chuck
At 08:35 PM 10/2/00 -0500, you wrote:
The system$dia0 isn't especially newer or
better. It is the name of the
disk with the allocation class set to 0. Check your drive firmware to
make sure that the alloclass on that disk didn't get changed to 24 wen you
changed the node name.
There is also a MSCP_ALLOCLASS parameter in SYSGEN but that is less likely
to be the culprit.
The allocation class is a mechanism to prevent like-named devices (i.e.
machines on a CI or DSSI each with a DxAxxx device) from confusing one
another.
On Mon, 2 Oct 2000, Chuck McManis wrote:
I know, I should ask info-vax. But I'm not
subscribed there :-(
I changed the nodename on my DSSI drive (looks like an HSC50 to the VAX)
and it still boots VMS but SYS$SYSDEVICE is set to $24$DIA264 not the
newer, more friendly SYSTEM$DIA0: I tried doing an autogen but that didn't
seem to change anything :-). Clues?
--Chuck