|
HP OpenVMS Systemsask the wizard |
|
The Question is: We are in the process of upgrading a Alpha Server 2100 to a 2100a. We have noticed this problem in the naming naming convention for t he SCSI devices. Prior to the conversion all SCSI device names were the same at the ">>>" prompt or when OpenVms has been boot. Example prior to the boot a device name would be DKA0 and after OpenVms has been boot it would stay as DKA0. After the system was updated to 210 0a the SCSI device names will change after OpenVMS has been booted. Example a disk prior to boot would "DKB0" but after VMS has been booted the device name has changed to DKF0. Can you explain why the device would change name? The Answer is :
This is a known and expected (and unfortunate) "disagreement" between
the algorithms used by OpenVMS and by the SRM console. The difference
tracks back to the use of a depth-first search used by the console (and
Tru64 UNIX) vs the modified depth-first scheme used by OpenVMS.
OpenVMS probes the SCSI bus using a modified depth-first algorithm,
depth-first for the devices and modified depth-first for the naming
of controllers. (The probing and naming are actually two different
things, and both will be addressed here.)
OpenVMS probes PCI bus 0 first. If it finds any bridges while probing,
it gives the bus behind that bridge the next available number and then
goes behind that bridge to continue probing (full depth-first). Once
a bridge has been probed behind, OpenVMS then pops back to the original
bus, and resumes probing it.
The AlphaServer 2100A has an EISA bridge at bus 0 slot 2, and a PCI
bridge at bus 0 slot 3. Bus 0 slots 6 to 9 are the option slots for
that bus (the low four PCI slots in the backplane). The EISA bus
(bus 1) has three slots. The PCI bridge (bus 2) has an NCR810 in
slot 1, and bus 2 slots 6 to 9 are the option slots for that bus
(the high four PCI slots in the backplane).
Here is the typical order of probing via OpenVMS:
bus 0 -- PCI
bus 0 slot 2 -- EISA bridge, bus 1
bus 1 slot 1
bus 1 slot 2
bus 1 slot 3
bus 0 slot 3 -- PCI bridge, bus 2
bus 2 slot 1 -- NCR810
bus 2 slot 6
bus 2 slot 7
bus 2 slot 8
bus 2 slot 9
bus 0 slot 6
bus 0 slot 7
bus 0 slot 8
bus 0 slot 9
The above order only holds if no additional PCI bridges are found in
any of the PCI option slots -- if there are such bridged found, they
are probed as they are found, depth-first, and could be added to the
list above.
As far as naming goes, OpenVMS names the controllers on entire buses
at a time. It names all controllers on bus 0, then all controllers
on bus 1, then all controllers on bus 2, etc:
for bus = 0 to max_bus
for slot = 0 to max_slot
assign_controller_letter
On the AlphaServer 2100, the standard I/O has an NCR810, which is the
PKA device on the typical system. In order to make the AlphaServer
2100A system built-in NCR810 also be PKA, there must be no SCSI devices
on buses 0 and 1 -- that means no SCSI devices on the EISA bus, nor
in the lower 4 PCI slots. You could then put the KZPSA in the top
PCI slot (option slot 1, or bus 2 slot 6), so it would be PKB, and
the (new) NCR810 (KZPAA) below it (option slot 2, or bus 2 slot 7),
so it would be PKC.
OpenVMS V7.1 and later offer port allocation class support, which
greatly simplifies configuring a multi-host SCSI configuration.
Also of interest will be the disk logical names (DISK$vollbl) based
on the volume label, as the use of these logical names can completely
avoid the use of device names.
|