SBP (See Below, Please ;-)
Antonio Carlini wrote:
>>VAXen that were part of a cluster *can* have an NVRAM setting
>>that tells them their node ID, which they need to correctly
>>address the
>>(shared) system disks... this happens a lot with shared-DSSI clusters.
...
>>I cant remember what the name of the setting was.
>
>
> ALLOCLASS is the SYSGEN setting that determines the
> number you see in front of disks (so my VAXstation
> here has ALLOCLASS set to 42 and its disks are
> $42$DKA0: etc.)
>
> Antonio
To me, the remark about shared system disks sounds more like the number
in SYSn (the first-level directory in the SYS$SYSROOT path on the system
disk) that is unique for each cluster member.
This number is passed from the console software to the operating system
as a single number (32 bit in /R5:<n> for a VAX, 64 bits as -flags
<root>,<flags> for an Alpha). The mechanism of passing the number does
not depend on the operating system (Unix on Alpha uses it as well as VMS
does), but the meaning that is assigned to each bit depends on the
operating system.
For VAX/VMS, the high-order four bits in processor register R5 determine
the SYSn, while the low-order bits specify boot options such as
conversational bootstrap, inhibit memory test etc.
For OpenVMS/AXP, the <root> argument specifies the SYSn, and the <flags>
do the remaining part.
How the information is stored in nonvolatile memory, in turn, depends on
the hardware. Some VAXen - an 8600 comes to my mind - even have a
frontend processor, which in this case happens to be a PDP-11 running
RT-11 or something very similar. Since the PDP-11 has its own file
system on a console medium (RL02 in this case), it can comfortably store
boot command files to specify all desired options.
Since there are differences between processors, there is nothing like a
single name for the parameter that specifies the system root. The VAX
8600 has the PDP front end processor, a VAX 6xx0 would have NVRAM
holding complete boot strings, Alphas have the BOOT_OSFLAGS variable
that serves as a default for the BOOT command. Just a few examples that
I had the honor of laying my hands on so far.
The ALLOCLASS comes in when SYSBOOT has gained access to the SYSGEN
parameters (very early in the course of a VMS boot), and indeed it is
one of the parameters that control device naming. At this time, however,
the system root must already be fixed, since the exact location from
which SYSBOOT.EXE is loaded also depends on the root and might be node
specific in a cluster.
Andreas
--
Andreas Freiherr
Vishay Semiconductor GmbH, Heilbronn, Germany
http://www.vishay.com
Received on Tue Jan 13 2004 - 07:05:33 GMT