HP OpenVMS Systems Documentation

Content starts here

HP OpenVMS Cluster Systems

Previous Contents Index

10.7.2 Sharing Dump Files

Another option for saving dump-file space is to share a single dump file among multiple computers. While this technique makes it possible to analyze isolated computer failures, dumps will be lost if multiple computers fail at the same time or if a second computer fails before you can analyze the first failure. Because boot server failures have a greater impact on cluster operation than do failures of other computers you should configure dump files on boot servers to help ensure speedy analysis of problems.

Dump files cannot be shared between architectures. However, you can share a single dump file among multiple Alpha computers, and another single dump file among multiple Integrity computers and another single dump file among VAX computers. Follow these steps for each operating system:

Step Action
1 Decide whether to use full or selective dump files. (Selective recommended.)
2 Determine the size of the largest dump file needed by any satellite.
3 Select a satellite whose memory configuration is the largest of any in the cluster and do the following:
  1. Specify DUMPSTYLE = 9 (or DUMPSTYLE = 8) in that satellite's MODPARAMS.DAT file.
  2. Remove any DUMPFILE symbol from the satellite's MODPARAMS.DAT file.
  3. Run AUTOGEN on that satellite to create a dump file.
4 Rename the dump file to SYS$COMMON:[SYSEXE]SYSDUMP-COMMON.DMP or create a new dump file named SYSDUMP-COMMON.DMP in SYS$COMMON:[SYSEXE].
5 Rename the old system-specific dump file on each system that has its own dump file:

The value of n in the command line is the root for each system (for example, SYS0 or SYS1). Rename the file so that the operating system software does not use it as the dump file when the system is rebooted.

6 For each satellite that is to share the dump file, do the following:
  1. Create a file synonym entry for the dump file in the system-specific root. For example, to create a synonym for the satellite using root SYS1E, enter a command like the following:
  2. Add the following lines to the satellite's MODPARAMS.DAT file:
    DUMPFILE = 0
    DUMPSTYLE = 0 (or DUMPSTYLE = 1)
7 Reboot each node so it can map to the new common dump file. The operating system software cannot use the new file for a crash dump until you reboot the system.
8 After you reboot, delete the SYSDUMP.OLD file in each system-specific root. Do not delete any file called SYSDUMP.DMP; instead, rename it, reboot, and then delete it as described in steps 5 and 7.

10.8 Maintaining the Integrity of OpenVMS Cluster Membership

Because multiple LAN and mixed-interconnect clusters coexist on a single extended LAN, the operating system provides mechanisms to ensure the integrity of individual clusters and to prevent access to a cluster by an unauthorized computer.

The following mechanisms are designed to ensure the integrity of the cluster:

  • A cluster authorization file (SYS$COMMON:[SYSEXE]CLUSTER_AUTHORIZE.DAT), which is initialized during installation of the operating system or during execution of the CLUSTER_CONFIG.COM CHANGE function. The file is maintained with the SYSMAN utility.
  • Control of conversational bootstrap operations on satellites.

The purpose of the cluster group number and password is to prevent accidental access to the cluster by an unauthorized computer. Under normal conditions, the system manager specifies the cluster group number and password either during installation or when you run CLUSTER_CONFIG.COM (see Example 8-13) to convert a standalone computer to run in an OpenVMS Cluster system.

OpenVMS Cluster systems use these mechanisms to protect the integrity of the cluster in order to prevent problems that could otherwise occur under circumstances like the following:

  • When setting up a new cluster, the system manager specifies a group number identical to that of an existing cluster on the same Ethernet.
  • A satellite user with access to a local system disk tries to join a cluster by executing a conversational SYSBOOT operation at the satellite's console.

Reference: These mechanisms are discussed in Section 10.8.1 and Section 8.2.1, respectively.

10.8.1 Cluster Group Data

The cluster authorization file, SYS$COMMON:[SYSEXE]CLUSTER_AUTHORIZE.DAT, contains the cluster group number and (in scrambled form) the cluster password. The CLUSTER_AUTHORIZE.DAT file is accessible only to users with the SYSPRV privilege.

Under normal conditions, you need not alter records in the CLUSTER_AUTHORIZE.DAT file interactively. However, if you suspect a security breach, you may want to change the cluster password. In that case, you use the SYSMAN utility to make the change.

To change the cluster password, follow these instructions:

Step Action
1 Invoke the SYSMAN utility.
2 Log in as system manager on a boot server.
3 Enter the following command:

4 At the SYSMAN> prompt, enter any of the CONFIGURATION commands in the following list.

    Updates the cluster authorization file, CLUSTER_AUTHORIZE.DAT, in the directory SYS$COMMON:[SYSEXE]. (The SET command creates this file if it does not already exist.) You can include the following qualifiers on this command:

    • /GROUP_NUMBER---Specifies a cluster group number. Group number must be in the range from 1 to 4095 or 61440 to 65535.
    • /PASSWORD---Specifies a cluster password. Password may be from 1 to 31 characters in length and may include alphanumeric characters, dollar signs ($), and underscores (_).

    Displays the cluster group number.


    Explains the command's functions.

5 If your configuration has multiple system disks, each disk must have a copy of CLUSTER_AUTHORIZE.DAT. You must run the SYSMAN utility to update all copies.
Caution: If you change either the group number or the password, you must reboot the entire cluster. For instructions, see Section 8.6.

10.8.2 Example

Example 10-2 illustrates the use of the SYSMAN utility to change the cluster password.

Example 10-2 Sample SYSMAN Session to Change the Cluster Password

%SYSMAN-I-ENV, current command environment: 
        Clusterwide on local cluster 
        Username SYSTEM        will be used on nonlocal nodes
%SYSMAN-I-CAFOLDGROUP, existing group will not be changed
%SYSMAN-I-CAFREBOOT, cluster authorization file updated
 The entire cluster should be rebooted.

10.9 Adjusting Packet Size for LAN or IP Configurations

You can adjust the maximum packet size for LAN configurations with the NISCS_MAX_PKTSZ system parameter.

10.9.1 System Parameter Settings for LANs and IPs

Starting with OpenVMS Version 7.3, the operating system (PEdriver) automatically detects the maximum packet size of all the virtual circuits to which the system is connected. If the maximum packet size of the system's interconnects is smaller than the default packet-size setting, PEdriver automatically reduces the default packet size.

Starting with OpenVMS 8.4, OpenVMS can make use of HP TCP/IP services for cluster communications using the UDP protocol. NISCS_MAX_PKTSZ will only affect the LAN channel payload size. To affect the IP channel payload size use the NISCS_UDP_PKTSZ parameter. For more information about the NISCS_UDP_PKTSZ parameter, see HELP.

10.9.2 How to Use NISCS_MAX_PKTSZ

To obtain this parameter's current, default, minimum, and maximum values, issue the following command:


You can use the NISCS_MAX_PKTSZ parameter to reduce packet size, which in turn can reduce memory consumption. However, reducing packet size can also increase CPU utilization for block data transfers, because more packets will be required to transfer a given amount of data. Lock message packets are smaller than the minimum value, so the NISCS_MAX_PKTSZ setting will not affect locking performance.

You can also use NISCS_MAX_PKTSZ to force use of a common packet size on all LAN paths by bounding the packet size to that of the LAN path with the smallest packet size. Using a common packet size can avoid VC closure due to packet size reduction when failing down to a slower, smaller packet size network.

If a memory-constrained system, such as a workstation, has adapters to a network path with large-size packets, such as FDDI or Gigabit Ethernet with jumbo packets, then you may want to conserve memory by reducing the value of the NISCS_MAX_PKTSZ parameter.

10.9.3 How to Use NISCS_UDP_PKTSZ

This parameter specifies the upper limit on the size, in bytes, of the user data area in the largest packet sent by NISCA on any IP network.

NISCS_UDP_PKTSZ allows the system manager to change the packet size used for cluster communications over IP on network communication paths.

PEdriver uses NISCS_UDP_PKTSZ to compute the maximum amount of data to transmit in any packet.

Currently, the maximum payload over an IP channel is defined by one of the following three parameters. The least of the 3 values will be in effect.

  • 1500 bytes
  • IP_MTU of the interface supported by TCP/IP stack


This parameter only affects the IP channel payload and not the LAN channel payload. LAN channel payload is controlled by the NISCS_MAX_PKTSZ parameter.

10.9.4 Editing Parameter Files

If you decide to change the value of the NISCS_MAX_PKTSZ or NISCS_UDP_PKTSZ parameter, edit the SYS$SPECIFIC:[SYSEXE]MODPARAMS.DAT file to permit AUTOGEN to factor the changed packet size into its calculations.

10.10 Determining Process Quotas

On Alpha systems, process quota default values in SYSUAF.DAT are often higher than the SYSUAF.DAT defaults on VAX systems. How, then, do you choose values for processes that could run on Alpha systems or on VAX systems in an OpenVMS Cluster? Understanding how a process is assigned quotas when the process is created in a dual-architecture OpenVMS Cluster configuration will help you manage this task.

10.10.1 Quota Values

The quotas to be used by a new process are determined by the OpenVMS LOGINOUT software. LOGINOUT works the same on OpenVMS Alpha and OpenVMS VAX systems. When a user logs in and a process is started, LOGINOUT uses the larger of:

  • The value of the quota defined in the process's SYSUAF.DAT record
  • The current value of the corresponding PQL_Mquota system parameter on the host node in the OpenVMS Cluster

Example: LOGINOUT compares the value of the account's ASTLM process limit (as defined in the common SYSUAF.DAT) with the value of the PQL_MASTLM system parameter on the host Alpha system or on the host VAX system in the OpenVMS Cluster.

10.10.2 PQL Parameters

The letter M in PQL_M means minimum. The PQL_Mquota system parameters set a minimum value for the quotas. In the Current and Default columns of the following edited SYSMAN display, note how the current value of each PQL_Mquota parameter exceeds its system-defined default value in most cases.


%SYSMAN-I-USEACTNOD, a USE ACTIVE has been defaulted on node I64MOZ 
Node I64MOZ:   Parameters in use: ACTIVE 
Parameter Name    Current    Default    Minimum    Maximum Unit  Dynamic 
--------------    -------    -------    -------    ------- ----  ------- 
PQL_DASTLM             24         24          4         -1 Ast         D 
PQL_MASTLM              4          4          4         -1 Ast         D 
PQL_DBIOLM             32         32          4         -1 I/O         D 
PQL_MBIOLM              4          4          4         -1 I/O         D 
PQL_DBYTLM         262144     262144     128000         -1 Bytes       D 
PQL_MBYTLM         128000     128000     128000         -1 Bytes       D 
PQL_DCPULM              0          0          0         -1 10Ms        D 
PQL_MCPULM              0          0          0         -1 10Ms        D 
PQL_DDIOLM             32         32          4         -1 I/O         D 
PQL_MDIOLM              4          4          4         -1 I/O         D 
PQL_DFILLM            128        128          2         -1 Files       D 
PQL_MFILLM              2          2          2         -1 Files       D 
PQL_DPGFLQUOTA     700000     700000     512000         -1 Pagelets    D 
PQL_MPGFLQUOTA     512000     512000     512000         -1 Pagelets    D 
PQL_DPRCLM             32         32          0         -1 Processes   D 
PQL_MPRCLM              0          0          0         -1 Processes   D 
PQL_DTQELM             16         16          0         -1 Timers      D 
PQL_MTQELM              0          0          0         -1 Timers      D 
PQL_DWSDEFAULT      53417      32768      16384         -1 Pagelets 
PQL_MWSDEFAULT      53417      16384      16384         -1 Pagelets 
PQL_DWSQUOTA       106834      65536      32768         -1 Pagelets    D 
PQL_MWSQUOTA       106834      32768      32768         -1 Pagelets    D 
PQL_DWSEXTENT     1619968     131072      65536         -1 Pagelets    D 
PQL_MWSEXTENT     1619968      65536      65536         -1 Pagelets    D 
PQL_DENQLM           2048       2048         64         -1 Locks       D 
PQL_MENQLM             64         64         64         -1 Locks       D 
PQL_DJTQUOTA         8192       8192          0         -1 Bytes       D 
PQL_MJTQUOTA            0          0          0         -1 Bytes       D 

In this display, the values for many PQL_Mquota parameters increased from the defaults to their current values. Typically, this happens over time when the AUTOGEN feedback is run periodically on your system. The PQL_Mquota values also can change, of course, when you modify the values in MODPARAMS.DAT or in SYSMAN. If you plan to use a common SYSUAF.DAT in an OpenVMS Cluster, with both Integrity servers and Alpha computers, remember the dynamic nature of the PQL_Mquota parameters.

10.10.3 Examples

The following table summarizes common SYSUAF.DAT scenarios and probable results on Integrity servers and Alpha computers in an OpenVMS Cluster system.

Table 10-5 Common SYSUAF.DAT Scenarios and Probable Results
WHEN you set values at... THEN a process that starts on... Will result in...
Alpha level An Alpha node Execution with the values you deemed appropriate.
  Integrity server node LOGINOUT ignoring the typically lower Integrity server level values in the SYSUAF and instead use the value of each quota's current PQL_M quota values on the Alpha system. Monitor the current values of PQL_M quota system parameters if you choose to try this approach. Increase as necessary the appropriate PQL_M quota values on the Alpha system in MODPARAMS.DAT.
Integrity server level Integrity server node Execution with the values you deemed appropriate.
  An Alpha node LOGINOUT ignoring the typically lower Integrity server level values in the SYSUAF and instead use the value of each quota's current PQL_M quota values on the Alpha system. Monitor the current values of PQL_M quota system parameters if you choose to try this approach. Increase as necessary the appropriate PQL_M quota values on the Alpha system in MODPARAMS.DAT.

You might decide to experiment with the higher process-quota values that usually are associated with an OpenVMS Alpha system's SYSUAF.DAT as you determine values for a common SYSUAF.DAT in an OpenVMS Cluster environment. The higher Alpha-level process quotas might be appropriate for processes created on host Integrity server nodes in the OpenVMS Cluster if the Integrity server systems have large available memory resources.

You can determine the values that are appropriate for processes on your Integrity server and Alpha systems by experimentation and modification over time. Factors in your decisions about appropriate limit and quota values for each process will include the following:

  • Amount of available memory
  • CPU processing power
  • Average work load of the applications
  • Peak work loads of the applications

10.11 Restoring Cluster Quorum

During the life of an OpenVMS Cluster system, computers join and leave the cluster. For example, you may need to add more computers to the cluster to extend the cluster's processing capabilities, or a computer may shut down because of a hardware or fatal software error. The connection management software coordinates these cluster transitions and controls cluster operation.

When a computer shuts down, the remaining computers, with the help of the connection manager, reconfigure the cluster, excluding the computer that shut down. The cluster can survive the failure of the computer and continue process operations as long as the cluster votes total is greater than the cluster quorum value. If the cluster votes total falls below the cluster quorum value, the cluster suspends the execution of all processes.

10.11.1 Restoring Votes

For process execution to resume, the cluster votes total must be restored to a value greater than or equal to the cluster quorum value. Often, the required votes are added as computers join or rejoin the cluster. However, waiting for a computer to join the cluster and increasing the votes value is not always a simple or convenient remedy. An alternative solution, for example, might be to shut down and reboot all the computers with a reduce quorum value.

After the failure of a computer, you may want to run the Show Cluster utility and examine values for the VOTES, EXPECTED_VOTES, CL_VOTES, and CL_QUORUM fields. (See the HP OpenVMS System Management Utilities Reference Manual for a complete description of these fields.) The VOTES and EXPECTED_VOTES fields show the settings for each cluster member; the CL_VOTES and CL_QUORUM fields show the cluster votes total and the current cluster quorum value.

To examine these values, enter the following commands:


Note: If you want to enter SHOW CLUSTER commands interactively, you must specify the /CONTINUOUS qualifier as part of the SHOW CLUSTER command string. If you do not specify this qualifier, SHOW CLUSTER displays cluster status information returned by the DCL command SHOW CLUSTER and returns you to the DCL command level.

If the display from the Show Cluster utility shows the CL_VOTES value equal to the CL_QUORUM value, the cluster cannot survive the failure of any remaining voting member. If one of these computers shuts down, all process activity in the cluster stops.

10.11.2 Reducing Cluster Quorum Value

To prevent the disruption of cluster process activity, you can reduce the cluster quorum value as described in Table 10-6.

Table 10-6 Reducing the Value of Cluster Quorum
Technique Description
Use the DCL command SET CLUSTER/EXPECTED_VOTES to adjust the cluster quorum to a value you specify. If you do not specify a value, the operating system calculates an appropriate value for you. You need to enter the command on only one computer to propagate the new value throughout the cluster. When you enter the command, the operating system reports the new value.

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 HP OpenVMS DCL Dictionary.)

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


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.

Use the IPC Q command to recalculate the quorum. Refer to the HP OpenVMS System Manager's Manual, Volume 1: Essentials for a description of the Q command.
Select one of the cluster-related shutdown options. Refer to Section 10.6 for a description of the shutdown options.

Previous Next Contents Index