Technical data

System Management Release Notes
5.9 OpenVMS Cluster Systems
To avoid this problem, disable autonegotiation on the new node’s DEGPA, as
follows:
• Perform a conversational boot when first booting the node into the cluster.
• Set the new node’s system parameter LAN_FLAGS to a value of 32 to disable
autonegotiation on the DEGPA.
5.9.20 DQDRIVER Namespace Collision Workaround
V7.3
Multiple systems in a cluster could each have IDE, ATA, or ATAPI devices
potentially sharing the following names: DQA0, DQA1, DQB0, and DQB1.
Such sharing of device names could lead to confusion or errors. Starting with
OpenVMS Version 7.2-1, you can avoid this problem by creating devices with
unique names.
To create a list of uniquely named devices on your cluster, use the following
procedure:
1. In SYSGEN, make sure DEVICE_NAMING is set to 1 and ALLOCLASS is
set to a nonzero value.
2. Create a file named SYS$SYSTEM:SYS$DEVICES.DAT that specifies a port
allocation class of 0 for the two DQ controllers (DQA and DQB).
You can either edit this file to add the information manually, or update this
file automatically by using the following commands at bootstrap time:
SYSBOOT> SET /CLASS DQA 0
SYSBOOT> SET /CLASS DQB 0
Following is a sample SYS$SYSTEM:SYS$DEVICES.DAT file (for node
ACORN::):
[Port ACORN$DQA]
Allocation Class = 0
[Port ACORN$DQB]
Allocation Class = 0
This procedure causes all DQ devices to be named according to the following
format, which allows for unique device names across the cluster:
node-name$DQxn:
where:
node-name is the system name.
x is either A or B.
n is either 0 or 1.
Port allocation classes are described in the OpenVMS Cluster Systems manual,
where this technique is fully documented.
You have the option of using a nonzero port allocation class in the
SYS$DEVICES.DAT file. However, if you use nonzero port allocation classes,
be sure to follow the rules outlined in the OpenVMS Cluster Systems manual.
5–22 System Management Release Notes