Changing logicals on VMS?

From: Paul Thompson <thompson_at_mail.athenet.net>
Date: Mon Oct 2 23:53:17 2000

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
> > >
> >
>
>
Received on Mon Oct 02 2000 - 23:53:17 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:33:15 BST