HP OpenVMS Systems Documentation

Suggestion: Normally, you use the SET CLUSTER/EXPECTED_VOTES command only after a computer has left the cluster for an extended period. (For more information about this command, see the OpenVMS DCL Dictionary.)

Example: For example, if you want to change expected votes to set the cluster quorum to 2, enter the following command:

$ SET CLUSTER/EXPECTED_VOTES=3

The resulting value for quorum is (3 + 2)/2 = 2.

Note: No matter what value you specify for the SET CLUSTER/EXPECTED_VOTES command, you cannot increase quorum to a value that is greater than the number of the votes present, nor can you reduce quorum to a value that is half or fewer of the votes present.

When a computer that previously was a cluster member is ready to rejoin, you must reset the EXPECTED_VOTES system parameter to its original value in MODPARAMS.DAT on all computers and then reconfigure the cluster according to the instructions in Section 8.6. You do not need to use the SET CLUSTER/EXPECTED_VOTES command to increase cluster quorum, because the quorum value is increased automatically when the computer rejoins the cluster.

• Whether the disk is available to the cluster
• Whether the disk is MSCP served or dual ported
• The name and type (VAX or HSC) of the primary and secondary hosts
• Whether the disk is mounted on the system where you enter the command
• The systems in the cluster on which the disk is mounted

• Lists files opened only on this node.
• Finds all open files on a disk. You can use either the SHOW DEVICE/FILES command or SYSMAN commands on each node that has the disk mounted.

• /HOST displays the names of processors that have devices online through the local MSCP server, and the number of devices.
• /RESOURCE displays the resources available to the MSCP server, total amount of nonpaged dynamic memory available for I/O buffers, and number of I/O request packets.
• /COUNT displays the number of each size and type of I/O operation the MSCP server has performed since it was started.
• /ALL displays all of the information listed for the SHOW DEVICE/SERVED command.

1. Create a node-by-node summary of disk I/O using the MONITOR/NODE command
2. Adjust the "row sum" column for MSCP served disks as follows:
   • I/O rate on serving node includes local requests and all requests from other nodes
   • I/O rate on other nodes includes requests generated from that node
   • Requests from remote nodes are counted twice in the row sum column
3. Note disks with the row sum more than 8 I/Os per second
4. Eliminate from the list of cluster problem disks the disks that are:
   • Not shared
   • Dedicated to an application
   • In the process of being backed up

• If a disporportionate amount of a disk's I/O comes from a particular node, the problem is most likely specific to the node.
• If a disk's I/O is spread evenly over the cluster, the problem may be clusterwide overuse.
• If the average queue length for a disk on a given node is less than 0.2, then the disk is having little impact on the node.

• Page and swap files from any node are on the disk.
• Commonly used programs or data files are on the disk (use the SHOW DEVICE/FILES command).
• Users with default directories on the disk are causing the problem.

If the SHOW CLUSTER command displays a high number of credit waits for the VMS$VAXcluster connection, you might consider increasing the value of CLUSTER_CREDITS on the other node. However, in large cluster configurations, setting this value unnecessarily high will consume a large quantity of nonpaged pool. Each receive buffer is at least SCSMAXMSG bytes in size but might be substantially larger depending on the underlying transport.

It is not required that all nodes in the cluster have the same value for CLUSTER_CREDITS. For small or memory-constrained systems, the default value of CLUSTER_CREDITS should be adequate.

By default, the value is 1. The connection manager sets a quorum value to a number that will prevent cluster partitioning (see Section 2.3). To calculate quorum, the system uses the following formula:

estimated quorum = (EXPECTED_VOTES + 2)/2

FDDI supports transfers using large packets (up to 4468 bytes). PEDRIVER does not use large packets by default, but can take advantage of the larger packet sizes if you increase the LRPSIZE system parameter to 4474 or higher.

PEDRIVER uses the full FDDI packet size if the LRPSIZE is set to 4474 or higher. However, only FDDI nodes connected to the same ring use large packets. Nodes connected to an Ethernet segment restrict packet size to that of an Ethernet packet (1498 bytes).

A value of 1 causes other nodes in the MEMORY CHANNEL cluster to fail with bugcheck code MC_FORCED_CRASH if this node bugchecks or shuts down.

The default value is 0. A setting of 1 is intended only for debugging purposes; the parameter should otherwise be left at its default state.

The default for MC_SERVICES_P2 is 1. This default value causes PMDRIVER to be loaded when you boot the system.

Compaq recommends that this value not be changed. This parameter value must be the same on all nodes connected by MEMORY CHANNEL.

The default value is 800. Compaq recommends that this value not be changed.

This parameter value must be the same on all nodes connected by MEMORY CHANNEL.

The default value is 200. Compaq recommends that this value not be changed.

This parameter value must be the same on all nodes connected by MEMORY CHANNEL.

For such systems, you can reduce the memory consumption of MEMORY CHANNEL by slightly reducing the default value of 992. This value must always be equal to or greater than the result of the following calculation:

1. Select the larger of SCS_MAXMSG and SCS_MAXDG.
2. Round that value to the next quadword.

This parameter value must be the same on all nodes connected by MEMORY CHANNEL.

The default value is 0. Compaq recommends that this value not be changed except for debugging MEMORY CHANNEL problems or adjusting the MC_SERVICES_P9 parameter.

Note that MC_SERVICES_P9 is not a dynamic parameter; you must reboot the system after each change in order for the change to take effect.

The default value is 150. Compaq recommends that this value not be changed.

This parameter value must be the same on all nodes connected by MEMORY CHANNEL.

On VAX systems, MSCP_BUFFER specifies the number of pages to be allocated to the MSCP server's local buffer area.

On Alpha systems, MSCP_BUFFER specifies the number of pagelets to be allocated the MSCP server's local buffer area.

An MSCP_CMD_TMO value of 0 is normally adequate. A value of 0 provides the same behavior as in previous releases of OpenVMS (which did not have an MSCP_CMD_TMO system parameter). A nonzero setting increases the amount of time before an MSCP command times out.

If command timeout errors are being logged on client nodes, setting the parameter to a nonzero value on OpenVMS servers reduces the number of errors logged. Increasing the value of this parameter reduces the numb client MSCP command timeouts and increases the time it takes to detect faulty devices.

If you need to decrease the number of command timeout errors, set an initial value of 60. If timeout errors continue to be logged, you can increase this value in increments of 20 seconds.

Starting with OpenVMS Version 7.2, the serving types are implemented as a bit mask. To specify the type of serving your system will perform, locate the type you want in the following table and specify its value. For some systems, you may want to specify two serving types, such as serving the system disk and serving locally attached disks. To specify such a combination, add the values of each type, and specify the sum.

In a mixed-version cluster that includes any systems running OpenVMS Version 7.1- x or earlier, serving all available disks is restricted to serving all disks except those whose allocation class does not match the system's node allocation class (pre-Version 7.2 meaning). To specify this type of serving, use the value 9 (which sets bit 0 and bit 3).

The following table describes the serving type controlled by each bit and its decimal value.

Although the serving types are now implemented as a bit mask, the values of 0, 1, and 2, specified by bit 0 and bit 1, retain their original meanings:

• 0 --- Do not serve any disks (the default for earlier versions of OpenVMS).
• 1 --- Serve all available disks.
• 2 --- Serve only locally attached (non-HSx and non-DSSI) disks.

If the MSCP_LOAD system parameter is 0, MSCP_SERVE_ALL is ignored. For more information about this system parameter, see Section 6.3.1.

Caution: If the NISCS_LOAD_PEA0 parameter is set to 1, the VAXCLUSTER system parameter must be set to 2. This ensures coordinated access to shared resources in the OpenVMS Cluster and prevents accidental data corruption.

The NISCS_MAX_PKTSZ parameter allows the system manager to change the packet size used for cluster communications on network communication paths. PEDRIVER automatically allocates memory to support the largest packet size that is usable by any virtual circuit connected to the system up to the limit set by this parameter.

Its default values are different for OpenVMS Alpha and OpenVMS VAX.

• On Alpha, the default value is the largest packet size currently supported by OpenVMS, in order to optimize performance.
• On VAX, the default value is the Ethernet packet size.

PEDRIVER uses NISCS_MAX_PKTSZ to compute the maximum amount of data to transmit in any LAN packet as follows:

LAN packet size <= (LAN header (padded Ethernet format) + NISCS_MAX_PKTSZ + NISCS checksum (only if data checking is enabled) + LAN CRC or FCS)

The actual packet size automatically used by PEDRIVER might be smaller than the NISCS_MAX_PKTSZ limit for either of the following reasons:

• On a per-LAN-path basis, if PEdriver determines that the LAN path between two nodes, including the local and remote LAN adapters and intervening LAN equipment, can convey only a lesser size.

  Only nodes with large-packet LAN adapters connected end-to-end by large-packet LAN equipment can use large packets. Nodes connected to large-packet LANs but having an end-to-end path that involves an Ethernet segment restrict packet size to that of an Ethernet packet (1498 bytes).

• For performance reasons, PEDRIVER might further limit the upper bound on packet size so that the packets can be allocated from a lookaside list in the nonpaged pool.

The actual memory allocation includes the required data structure overhead used by PEDRIVER and the LAN drivers, in addition to the actual LAN packet size.

The following table shows the minimum NISCS_MAX_PKTSZ value required to use the maximum packet size supported by LAN types.

MEMORY CHANNEL devices ignore this parameter.

This parameter should be set to the same value on each cluster computer.

This parameter should be set to the same value on each cluster computer. This parameter also affects the tolerance of the OpenVMS Cluster system for LAN bridge failures (see Section 3.4.7).

Note: AUTOGEN provides feedback for this parameter on VAX systems only.

++On Alpha systems, the SCS buffers are allocated as needed, and SCSBUFFCNT is reserved for OpenVMS use, only.

If no SCS ports are configured on your system, this parameter is ignored. The default value is adequate for all SCS hardware combinations.

Note: AUTOGEN provides feedback for this parameter on VAX systems only.

Specify SCSNODE as a string of up to six characters. Enclose the string in quotation marks.

If the computer is in an OpenVMS Cluster, specify a value that is unique within the cluster. Do not specify the null string.

If the computer is running DECnet for OpenVMS, the value must be the same as the DECnet node name.

If no SCS or DSA port is configured on your system, this parameter is ignored.

If the computer is in an OpenVMS Cluster, specify a value that is unique within the cluster.

If the computer is running DECnet for OpenVMS, calculate the value from the DECnet address using the following formula:

SCSSYSTEMID = (
DECnet-area-number * 1024)

+
DECnet-node-number

Example: If the DECnet address is 2.211, calculate the value as follows:

SCSSYSTEMID = (2 * 1024) + 211 = 2259

Starting with OpenVMS Version 7.2, the serving types are implemented as a bit mask. To specify the type of serving your system will perform, locate the type you want in the following table and specify its value. For some systems, you may want to specify two serving types, such as serving all tapes except those whose allocation class does not match. To specify such a combination, add the values of each type, and specify the sum.

In a mixed-version cluster that includes any systems running OpenVMS Version 7.1- x or earlier, serving all available tapes is restricted to serving all tapes except those whose allocation class does not match the system's allocation class (pre-Version 7.2 meaning). To specify this type of serving, use the value 9, which sets bit 0 and bit 3.

The following table describes the serving type controlled by each bit and its decimal value.

Although the serving types are now implemented as a bit mask, the values of 0, 1, and 2, specified by bit 0 and bit 1, retain their original meanings:

• 0 --- Do not serve any disks (the default for earlier versions of OpenVMS).
• 1 --- Serve all available disks.
• 2 --- Serve only locally attached (non-HSx and non-DSSI) disks.

If the TMSCP_LOAD system parameter is 0, TMSCP_SERVE_ALL is ignored.

• 0 --- Specifies that the computer will not participate in a cluster.
• 1 --- Specifies that the computer should participate in a cluster if hardware supporting SCS (CI or DSSI) is present or if NISCS_LOAD_PEA0 is set to 1, indicating that cluster communications is enabled over the local area network (LAN).
• 2 --- Specifies that the computer should participate in a cluster.

You should always set this parameter to 2 on computers intended to run in a cluster, to 0 on computers that boot from a UDA disk controller and are not intended to be part of a cluster, and to 1 (the default) otherwise.

Caution: If the NISCS_LOAD_PEA0 system parameter is set to 1, the VAXCLUSTER parameter must be set to 2. This ensures coordinated access to shared resources in the OpenVMS Cluster system and prevents accidental data corruption. Data corruption may occur on shared resources if the NISCS_LOAD_PEA0 parameter is set to 1 and the VAXCLUSTER parameter is set to 0.