Document revision date: 19 July 1999

There are two ways to assign a node allocation class: by using CLUSTER_CONFIG.COM or CLUSTER_CONFIG_LAN.COM, which is described in Section 8.4, or by using AUTOGEN, as shown in the following table.

Step	Action
1	Edit the root directory [SYS n.SYSEXE]MODPARAMS.DAT on each node that boots from the system disk. The following example shows a MODPARAMS.DAT file. The entries are hypothetical and should be regarded as examples, not as suggestions for specific parameter settings. ! ! Site-specific AUTOGEN data file. In an OpenVMS Cluster ! where a common system disk is being used, this file ! should reside in SYS$SPECIFIC:[SYSEXE], not a common ! system directory. ! ! Add modifications that you want to make to AUTOGEN's ! hardware configuration data, system parameter ! calculations, and page, swap, and dump file sizes ! to the bottom of this file. SCSNODE="NODE01" SCSSYSTEMID=99999 NISCS_LOAD_PEA0=1 VAXCLUSTER=2 MSCP_LOAD=1 MSCP_SERVE_ALL=1 ALLOCLASS=1 TAPE_ALLOCLASS=1
2	Invoke AUTOGEN to set the system parameter values: $ @SYS$UPDATE:AUTOGEN start-phase end-phase
3	Shut down and reboot the entire cluster in order for the new values to take effect.

6.2.2.2 Assigning Node Allocation Class Values on HSC Subsystems

Assign or change node allocation class values on HSC subsystems while the cluster is shut down. To assign a node allocation class to disks for an HSC subsystem, specify the value using the HSC console command in the following format:

SET ALLOCATE DISK allocation-class-value

To assign a node allocation class for tapes, enter a SET ALLOCATE TAPE command in the following format:

SET ALLOCATE TAPE tape-allocation-class-value

For example, to change the value of a node allocation class for disks to 1, set the HSC internal door switch to the Enable position and enter a command sequence like the following at the appropriate HSC consoles:

[Ctrl/C] HSC> RUN SETSHO SETSHO> SET ALLOCATE DISK 1 SETSHO> EXIT SETSHO-Q Rebooting HSC; Y to continue, Ctrl/Y to abort:? Y

Restore the HSC internal door-switch setting.

Reference: For complete information about the HSC console commands, refer to the HSC hardware documentation.

6.2.2.3 Assigning Node Allocation Class Values on HSJ Subsystems

To assign a node allocation class value for disks for an HSJ subsystem, enter a SET CONTROLLER MSCP_ALLOCATION_CLASS command in the following format:

SET CONTROLLER MSCP_ALLOCATION_CLASS = allocation-class-value

To assign a node allocation class value for tapes, enter a SET CONTROLLER TMSCP_ALLOCATION_CLASS ALLOCATE TAPE command in the following format:

SET CONTROLLER TMSCP_ALLOCATION_CLASS = allocation-class-value

For example, to assign or change the node allocation class value for disks to 254 on an HSJ subsystem, use the following command at the HSJ console prompt (PTMAN>):

PTMAN> SET CONTROLLER MSCP_ALLOCATION_CLASS = 254

6.2.2.4 Assigning Node Allocation Class Values on HSD Subsystems

To assign or change allocation class values on any HSD subsystem, use the following commands:

$ MC SYSMAN IO CONNECT FYA0:/NOADAP/DRIVER=SYS$FYDRIVER $ SET HOST/DUP/SERVER=MSCP$DUP/TASK=DIRECT node-name $ SET HOST/DUP/SERVER=MSCP$DUP/TASK=PARAMS node-name PARAMS> SET FORCEUNI 0 PARAMS> SET ALLCLASS 143 PARAMS> SET UNITNUM 900 PARAMS> WRITE Changes require controller initialization, ok? [Y/(N)] Y PARAMS> EXIT $

6.2.2.5 Assigning Node Allocation Class Values on DSSI ISEs

To assign or change node allocation class values on any DSSI ISE, the command you use differs depending on the operating system.

For example, to change the allocation class value to 1 for a DSSI ISE TRACER, follow the steps in Table 6-2.

Table 6-2 Changing a DSSI Allocation Class Value

Step	Task
1	Log into the SYSTEM account on the computer connected to the hardware device TRACER and load its driver as follows: If the computer is an Alpha system, then enter the following command at the DCL prompt: $ MC SYSMAN IO CONN FYA0:/NOADAP/DRIVER=SYS$FYDRIVER If the computer is a VAX system, then enter the following command at the DCL prompt: $ MCR SYSGEN CONN FYA0:/NOADAP/DRIVER=FYDRIVER
2	At the DCL prompt, enter the SHOW DEVICE FY command to verify the presence and status of the FY device, as follows: $ SHOW DEVICE FY Device Device Error Name Status Count FYA0: offline 0
3	At the DCL prompt, enter the following command sequence to set the allocation class value to 1: $ SET HOST/DUP/SERVER=MSCP$DUP/TASK=PARAMS node-name params >set allclass 1 params >write Changes require controller initialization, ok?[Y/N]Y Initializing... %HSCPAD-S-REMPGMEND, Remote program terminated--message number 3. %PAxx, Port has closed virtual circuit - remote node TRACER %HSCPAD-S-END, control returned to node node-name $
4	Reboot the entire cluster in order for the new value to take effect.

6.2.2.6 Node Allocation Class Example With a DSA Disk and Tape

Figure 6-5 shows a DSA disk and tape that are dual pathed between two computers.

Figure 6-5 Disk and Tape Dual Pathed Between Computers

In this configuration:

• URANUS and NEPTUN access the disk either locally or through the other computer's MSCP server.
• When satellites ARIEL and OBERON access $1$DJA8, a path is made through either URANUS or NEPTUN.
• If, for example, the node URANUS has been shut down, the satellites can access the devices through NEPTUN. When URANUS reboots, access is available through either URANUS or NEPTUN.

Figure 6-6 shows how device names are typically specified in a mixed-interconnect cluster. This figure also shows how relevant system parameter values are set for each CI computer.

Figure 6-6 Device Names in a Mixed-Interconnect Cluster

In this configuration:

• A disk and a tape are dual pathed to the HSC or HSJ subsystems named VOYGR1 and VOYGR2; these subsystems are connected to JUPITR, SATURN, URANUS and NEPTUN through the star coupler.
• The MSCP and TMSCP servers are loaded on JUPITR and NEPTUN (MSCP_LOAD = 1, TMSCP_LOAD = 1) and the ALLOCLASS and TAPE_ALLOCLASS parameters are set to the same value (1) on these computers and on both HSC or HSJ subsystems.

Note: For optimal availability, two or more CI connected computers should serve HSC or HSJ devices to the cluster.

6.2.2.8 Node Allocation Classes and VAX 6000 Tapes

Avoiding Duplicate Names

Duplicate names are more probable with VAX 6000 computers because TK console tape drives (located in the VAX 6000 cabinet) are usually named either MUA6 or MUB6. Thus, when you configure a VAXcluster system with more than one VAX 6000 computer, multiple TK console tape drives are likely to have the same name.

Specifying a Tape Allocation Class

To ensure that the TK console tape drives have names that are unique across the cluster, specify a tape allocation class name as a numeric value from 0 to 255, followed by the device name, as follows:

$tape-allocation-class$device-name

Example:

Assume that $1$MUA6, $1$MUB6, $2$MUA6 are all unique device names. The first two have the same tape allocation class but have different controller letters (A and B, respectively). The third device has a different tape allocation class than the first two.

Ensuring a Unique Access Path

Consider the methods described in Table 6-3 to ensure a unique access path to VAX 6000 TK console tape drives.

Table 6-3 Ensuring Unique Tape Access Paths

Method	Description	Comments
Set the TK console tape unit number to a unique value on each VAX 6000 system.	For VAXcluster systems in which tapes must be TMSCP served across the cluster, the tape controller letter and unit number of these tape drives must be unique clusterwide and must conform to the cluster device-naming conventions. If controller letters and unit numbers are unique clusterwide, the TAPE_ALLOCLASS system parameter can be set to the same value on multiple VAX 6000 systems.	The unit number of the TK console drives is controlled by the BI bus unit number plug of the TBK70 controller in the VAX 6000 BI backplane. A Compaq services technician should change the unit number so that it is unique from all other controller cards in the BI backplane. The unit numbers available are in the range of 0 to 15 (the default value is 6).
For VAXcluster systems configured with two or more VAX 6000 computers, set up the console tapes with different controller letters.	If your VAXcluster configuration contains only two VAX 6000 computers, contact a Compaq services technician to move the TBK70 controller card to another BI backplane within the same VAX computer.	Moving the controller card changes the controller letter of the tape drive without changing the unit number (for example, MUA6 becomes MUB6). Note: The tape drives can have the same unit number.

6.2.2.9 Node Allocation Classes and RAID Array 210 and 230 Devices

If you have RAID devices connected to StorageWorks RAID Array 210 or 230 subsystems, you might experience device-naming problems when running in a cluster environment if nonzero node allocation classes are used. In this case, the RAID devices will be named $n$DRcu, where: n is the (nonzero) node allocation class, c is the controller letter, and u is the unit number. (DR refers to DIGITAL StorageWorks RAID Array 200 Family logical RAID drives.)

If multiple nodes in the cluster have the same (nonzero) node allocation class and these same nodes have RAID controllers, then RAID devices that are distinct might be given the same name (for example, $1$DRA0). This problem can lead to data corruption.

To prevent such problems, use the DR_UNIT_BASE system parameter, which causes the DR devices to be numbered sequentially, starting with the DR_UNIT_BASE value that you specify. For example, if the node allocation class is $1, the controller letter is A, and you set DR_UNIT_BASE on one cluster member to 10, the first device name generated by the RAID controller will be $1$DRA10, followed by $1$DRA11, $1$DRA12, and so forth.

To ensure unique DR device names, set the DR_UNIT_BASE number on each cluster member so that the resulting device numbers do not overlap. For example, you can set DR_UNIT_BASE on three cluster members to 10, 20, and 30 respectively. As long as each cluster member has 10 or fewer devices, the DR device numbers will be unique.

6.2.3 SCSI Device Naming

When the node allocation class is nonzero, it becomes the device name prefix for all attached devices, whether the devices are on a shared interconnect or not. To ensure unique names within a cluster, it is necessary for the ddcu part of the disk device name (for example, DKB0) to be unique within an allocation class, even if the device is on a private bus.

This constraint is relatively easy to overcome for DIGITAL Storage Architecture (DSA) devices, because a system manager can select from a large unit number space to ensure uniqueness. The constraint is more difficult to manage for SCSI devices, because both the controller letter and the unit number are determined by the hardware configuration.

For example, in the configuration shown in Figure 6-7, each system has a private SCSI bus with adapter letter A. To obtain unique names, the unit numbers must be different. This constrains the configuration to a maximum of 8 devices on the two buses (or 16 if wide addressing can be used on one or more of the buses). This can result in empty StorageWorks drive bays and in a reduction of the system's maximum storage capacity.

Figure 6-7 SCSI Device Names Using a Node Allocation Class

The SCSI device name is determined in part by the SCSI controller through which the device is accessed (for example, B in DKBn). Therefore, to ensure that each node uses the same name for each device, all SCSI controllers attached to a shared SCSI bus must have the same OpenVMS device name. In Figure 6-7, each host is attached to the shared SCSI bus by controller PKB.

This requirement can make configuring a shared SCSI bus difficult, because a system manager has little or no control over the assignment of SCSI controller device names. It is particularly difficult to match controller letters on different system types when one or more of the systems have:

• Built-in SCSI controllers that are not supported in SCSI clusters
• Long internal cables that make some controllers inappropriate for SCSI clusters

The port allocation class feature has two major benefits:

• A system manager can specify an allocation class value that is specific to a SCSI port rather than nodewide.
• When a SCSI port has a nonzero port allocation class, the controller letter in the device name that is accessed through that port is always the letter A.

Using port allocation classes for naming SCSI devices removes the configuration constraints described in Section 6.2.3 and Section 6.2.3.1. First, each SCSI bus can be given its own unique allocation class value, so the ddcu part of the disk device name (for example, DKB0) does not need to be unique across buses. Second, SCSI controllers with different device names can be attached to the same SCSI bus, because the disk device names no longer depend on the SCSI controller letter.

Figure 6-8 shows the same configuration as Figure 6-7, with two additions: a host named CHUCK and an additional disk attached to the lower left SCSI bus. Port allocation classes are used in the device names in this figure. A port allocation class of 116 is used for the SCSI interconnect that is shared, and port allocation class 0 is used for the SCSI interconnects that are not shared. By using port allocation classes in this configuration, you can do what was not allowed previously:

• Attach an adapter with a name (PKA) that differs from the name of the other adapters (PKB) attached to the shared SCSI interconnect, as long as that port has the same port allocation class (116 in this example).
• Use two disks with the same controller name and number (DKA300) because each disk is attached to a SCSI interconnect that is not shared.

Figure 6-8 Device Names Using Port Allocation Classes

A port allocation class is a designation for all ports attached to a single interconnect. It replaces the node allocation class in the device name.

The three types of port allocation classes are:

• Port allocation classes of 1 to 32767 for devices attached to a multihost interconnect or a single-host interconnect, if desired
• Port allocation class 0 for devices attached to a single-host interconnect
• Port allocation class -1 when no port allocation class is in effect

Each type has its own naming rules.

6.2.4.1 Port Allocation Classes for Devices Attached to a Multi-Host Interconnect

The following rules pertain to port allocation classes for devices attached to a multihost interconnect:

1. The valid range of port allocation classes is 1 through 32767.
2. When using port allocation classes, the controller letter in the device name is always A, regardless of the actual controller letter.¹
   Note that it is now more important to use fully specified names (for example, $101$DKA100 or ABLE$DKA100) rather than abbreviated names (such as DK100), because a system can have multiple DKA100 disks.
3. Each port allocation class must be unique within a cluster.
4. A port allocation class cannot duplicate the value of another node's tape or disk node allocation class.
5. Each node for which MSCP serves a device should have the same nonzero allocation class value.

Examples of device names that use this type of port allocation class are shown in Table 6-4.

Table 6-4 Examples of Device Names with Port Allocation Classes 1-32767

Device Name	Description
$101$DKA0	The port allocation class is 101; DK represents the disk device category, A is the controller name, and 0 is the unit number.
$147$DKA0	The port allocation class is 147; DK represents the disk device category, A is the controller name, and 0 is the unit number.

6.2.4.2 Port Allocation Class 0 for Devices Attached to a Single-Host Interconnect

The following rules pertain to port allocation class 0 for devices attached to a single-host interconnect:

1. Port allocation class 0 does not become part of the device name. Instead, the name of the node to which the device is attached becomes the first part of the device name.
2. The controller letter in the device name remains the designation of the controller to which the device is attached. (It is not changed to A as it is for port allocation classes greater than zero.)

Examples of device names that use port allocation class 0 are shown in Table 6-5.

Table 6-5 Examples of Device Names With Port Allocation Class 0

Device Name	Description
ABLE$DKD100	ABLE is the name of the node to which the device is attached. D is the designation of the controller to which it is attached, not A as it is for port allocation classes with a nonzero class. The unit number of this device is 100. The port allocation class of $0$ is not included in the device name.
BAKER$DKC200	BAKER is the name of the node to which the device is attached, C is the designation of the controller to which it is attached, and 200 is the unit number. The port allocation class of $0$ is not included in the device name.

6.2.4.3 Port Allocation Class -1

The designation of port allocation class -1 means that a port allocation class is not being used. Instead, a node allocation class is used. The controller letter remains its predefined designation. (It is assigned by OpenVMS, based on the system configuration. It is not affected by a node allocation class.)

6.2.4.4 How to Implement Port Allocation Classes

Port implementation classes are available for implementation in OpenVMS Alpha Version 7.1 and supported in OpenVMS VAX Version 7.1. VAX computers can serve disks connected to Alpha systems that use port allocation classes in their names.

To implement port allocation classes, you must do the following:

• Enable the use of port allocation classes.
• Assign one or more port allocation classes.
• At a minimum, reboot the nodes on the shared SCSI bus.

Enabling the Use of Port Allocation Classes

To enable the use of port allocation classes, you must set a new SYSGEN parameter DEVICE_NAMING to 1. The default setting for this parameter is zero. In addition, the SCSSYSTEMIDH system parameter must be set to zero. Check to make sure that it is.

Assigning Port Allocation Classes

You can assign one or more port allocation classes with the OpenVMS Cluster configuration procedure, CLUSTER_CONFIG.COM (or CLUSTER_CONFIG_LAN.COM).

If it is not possible to use CLUSTER_CONFIG.COM or CLUSTER_CONFIG_LAN.COM to assign port allocation classes (for example, if you are booting a private system disk into an existing cluster), you can use the new SYSBOOT SET/CLASS command.

The following example shows how to use the new SYSBOOT SET/CLASS command to assign an existing port allocation class of 152 to port PKB.

SYSBOOT> SET/CLASS PKB 152

The SYSINIT process ensures that this new name is used in successive boots.

To deassign a port allocation class, enter the port name without a class number. For example:

SYSBOOT> SET/CLASS PKB

The mapping of ports to allocation classes is stored in SYS$SYSTEM:SYS$DEVICES.DAT, a standard text file. You use the CLUSTER_CONFIG.COM (or CLUSTER_CONFIG_LAN.COM) command procedure or, in special cases, SYSBOOT to change SYS$DEVICES.DAT.

	privacy and legal statement
4477PRO_009.HTML