HP OpenVMS Systems Documentation
OpenVMS Cluster Systems
5.4.5 Creating Clusterwide Logical Names
To create a clusterwide logical name, you must have write (W) access to the table in which the logical name is to be entered, or SYSNAM privilege if you are creating clusterwide logical names only in LNM$SYSCLUSTER. Unless you specify an access mode (user, supervisor, and so on), the access mode of the logical name you create defaults to the access mode from which the name was created. If you created the name with a DCL command, the access mode defaults to supervisor mode. If you created the name with a program, the access mode typically defaults to user mode.
When you create a clusterwide logical name, you must include the name of a clusterwide logical name table in the definition of the logical name. You can create clusterwide logical names by using DCL commands or with the $CRELNM system service.
The following example shows how to create a clusterwide logical name in the default clusterwide logical name table, LNM$CLUSTER_TABLE, using the DEFINE command:
To create clusterwide logical names that will reside in a clusterwide logical name table you created, you define the new clusterwide logical name with the DEFINE command, specifying your new clusterwide table's name with the /TABLE qualifier, as shown in the following example:
5.4.6 Management Guidelines
When using clusterwide logical names, observe the following guidelines:
5.4.7 Using Clusterwide Logical Names in Applications
The $TRNLNM system service and the $GETSYI system service provide
attributes that are specific to clusterwide logical names. This section
describes those attributes. It also describes the use of $CRELNT as it
pertains to creating a clusterwide table. For more information about
using logical names in applications, refer to the OpenVMS Programming Concepts Manual.
Two clusterwide attributes are available in the $TRNLNM system service:
LNM$V_CLUSTERWIDE is an output attribute to be returned in the itemlist if you asked for the LNM$_ATTRIBUTES item for a logical name that is clusterwide.
LNM$M_INTERLOCKED is an attr argument bit that can be set to ensure that any clusterwide logical name modifications in progress are completed before the name is translated. LNM$M_INTERLOCKED is not set by default. If your application requires translation using the most recent definition of a clusterwide logical name, use this attribute to ensure that the translation is stalled until all pending modifications have been made.
On a single system, when one process modifies the shareable part of the logical name database, the change is visible immediately to other processes on that node. Moreover, while the modification is in progress, no other process can translate or modify shareable logical names.
In contrast, when one process modifies the clusterwide logical name database, the change is visible immediately on that node, but it takes a short time for the change to be propagated to other nodes. By default, translations of clusterwide logical names are not stalled. Therefore, it is possible for processes on different nodes to translate a logical name and get different equivalence names when modifications are in progress.
The use of LNM$M_INTERLOCKED guarantees that your application will
receive the most recent definition of a clusterwide logical name.
The clusterwide attribute, SYI$_CWLOGICALS, has been added to the
$GETSYI system service. When you specify SYI$_CWLOGICALS, $GETSYI
returns the value 1 if the clusterwide logical name database has been
initialized on the CPU, or the value 0 if it has not been initialized.
Because this number is a Boolean value (1 or 0), the buffer length
field in the item descriptor should specify 1 (byte). On a nonclustered
system, the value of SYI$_CWLOGICALS is always 0.
When creating a clusterwide table, the $CRELNT requester must supply a
table name. OpenVMS does not supply a default name for clusterwide
tables because the use of default names enables a process without the
SYSPRV privilege to create a shareable table.
Initializing the clusterwide logical name database on a booting node requires sending a message to another node and having its CLUSTER_SERVER process reply with one or messages containing a description of the database. The CLUSTER_SERVER process on the booting node requests system services to create the equivalent names and tables. How long this initialization takes varies with conditions such as the size of the clusterwide logical name database, the speed of the cluster interconnect, and the responsiveness of the CLUSTER_SERVER process on the responding node.
Until a booting node's copy of the clusterwide logical name database is
consistent with the logical name databases of the rest of the cluster,
any attempt on the booting node to create or delete clusterwide names
or tables is stalled transparently. Because translations are not
stalled by default, any attempt to translate a clusterwide name before
the database is consistent may fail or succeed, depending on timing. To
stall a translation until the database is consistent, specify the
F$TRNLNM CASE argument as INTERLOCKED.
In general, system managers edit the SYLOGICALS.COM command procedure to define site-specific logical names that take effect at system startup. However, Compaq recommends that, if possible, clusterwide logical names be defined in the SYSTARTUP_VMS.COM command procedure instead with the exception of those logical names discussed in Section 5.5.2. The reason for defining clusterwide logical names in SYSTARTUP_VMS.COM is that SYSTARTUP_VMS.COM is run at a much later stage in the booting process than SYLOGICALS.COM.
OpenVMS startup is single streamed and synchronous except for actions taken by created processes, such as the CLUSTER_SERVER process. Although the CLUSTER_SERVER process is created very early in startup, it is possible that when SYLOGICALS.COM is executed, the booting node's copy of the clusterwide logical name database has not been fully initialized. In such a case, a clusterwide definition in SYLOGICALS.COM would stall startup and increase the time it takes for the system to become operational.
OpenVMS will ensure that the clusterwide database has been initialized
before SYSTARTUP_VMS.COM is executed.
To be effective, certain logical names, such as LMF$LICENSE, NET$PROXY, and VMS$OBJECTS must be defined earlier in startup than when SYSTARTUP_VMS.COM is invoked. Most such names are defined in SYLOGICALS.COM, with the exception of VMS$OBJECTS, which is defined in SYSECURITY.COM, and any names defined in SYCONFIG.COM.
Although Compaq recommends defining clusterwide logical names in SYSTARTUP_VMS.COM, to define these names to be clusterwide, you must do so in SYLOGICALS.COM or SYSECURITY.COM. Note that doing this may increase startup time.
Alternatively, you can take the traditional approach and define these
names as systemwide logical names with the same definition on every
For clusterwide definitions in any startup command procedure that is common to all cluster nodes, Compaq recommends that you use a conditional definition. For example:
A conditional definition can prevent unpleasant surprises. For example, suppose a system manager redefines a name that is also defined in SYSTARTUP_VMS.COM but does not edit SYSTARTUP_VMS.COM because the new definition is temporary. If a new node joins the cluster, the new node would initially receive the new definition. However, when the new node executes SYSTARTUP_VMS.COM, it will cause all the nodes in the cluster, including itself, to revert to the original value.
If you include a conditional definition in SYLOGICALS.COM or SYSECURITY.COM, specify the F$TRNLNM CASE argument as INTERLOCKED to ensure that clusterwide logical names have been fully initialized before the translation completes. An example of a conditional definition with the argument specified follows:
5.6 Coordinating Startup Command Procedures
Immediately after a computer boots, it runs the site-independent command procedure SYS$SYSTEM:STARTUP.COM to start up the system and control the sequence of startup events. The STARTUP.COM procedure calls a number of other startup command procedures that perform cluster-specific and node-specific tasks.
The following sections describe how, by setting up appropriate cluster-specific startup command procedures and other system files, you can prepare the OpenVMS Cluster operating environment on the first installed computer before adding other computers to the cluster.
Reference: See also the OpenVMS System Manager's Manual for more
information about startup command procedures.
Several startup command procedures are distributed as part of the OpenVMS operating system. The SYS$SYSTEM:STARTUP.COM command procedure executes immediately after OpenVMS is booted and invokes the site-specific startup command procedures described in the following table.
The directory SYS$COMMON:[SYSMGR] contains a template file for each
command procedure that you can edit. Use the command procedure
templates (in SYS$COMMON:[SYSMGR]*.TEMPLATE) as examples for
customization of your system's startup and login characteristics.
The first step in preparing an OpenVMS Cluster shared environment is to build a SYSTARTUP_VMS command procedure. Each computer executes the procedure at startup time to define the operating environment.
5.6.3 Combining Existing Procedures
To build startup procedures for an OpenVMS Cluster system in which existing computers are to be combined, you should compare both the computer-specific SYSTARTUP_VMS and the common startup command procedures on each computer and make any adjustments required. For example, you can compare the procedures from each computer and include commands that define the same logical names in your common SYSTARTUP_VMS command procedure.
After you have chosen which commands to make common, you can build the
common procedures on one of the OpenVMS Cluster computers.
To define a multiple-environment cluster, you set up computer-specific versions of one or more system files. For example, if you want to give users larger working set quotas on URANUS, you would create a computer-specific version of SYSUAF.DAT and place that file in URANUS's SYS$SPECIFIC:[SYSEXE] directory. That directory can be located in URANUS's root on a common system disk or on an individual system disk that you have set up on URANUS.
Follow these steps to build SYSTARTUP and SYLOGIN command files for a multiple-environment OpenVMS Cluster:
Example: Consider a three-member cluster consisting of
computers JUPITR, SATURN, and PLUTO. The timesharing environments on
JUPITR and SATURN are the same. However, PLUTO runs applications for a
specific user group. In this cluster, you would create a common
SYSTARTUP_VMS command procedure for JUPITR and SATURN that defines
identical environments on these computers. But the command procedure
for PLUTO would be different; it would include commands to define
PLUTO's special application environment.
The OpenVMS security subsystem ensures that all authorization
information and object security profiles are consistent across all
nodes in the cluster. The OpenVMS VAX and OpenVMS Alpha operating
systems do not support multiple security domains because the operating
system cannot enforce a level of separation needed to support different
security domains on separate cluster members.
In an OpenVMS Cluster system, individual nodes use a common set of authorizations to mediate access control that, in effect, ensures that a security check results in the same answer from any node in the cluster. The following list outlines how the OpenVMS operating system provides a basic level of protection:
The OpenVMS operating system provides the same strategy for the protection of files and queues, and further incorporates all other cluster-visible objects, such as devices, volumes, and lock resource domains.
Starting with OpenVMS Version 7.3, the operating system provides clusterwide intrusion detection, which extends protection against attacks of all types throughout the cluster. The intrusion data and information from each system is integrated to protect the cluster as a whole. Prior to Version 7.3, each system was protected individually.
The SECURITY_POLICY system parameter controls whether a local or a clusterwide intrusion database is maintained for each system. The default setting is for a clusterwide database, which contains all unauthorized attempts and the state of any intrusion events for all cluster members that are using this setting. Cluster members using the clusterwide intrusion database are made aware if a cluster member is under attack or has any intrusion events recorded. Events recorded on one system can cause another system in the cluster to take restrictive action. (For example, the person attempting to log in is monitored more closely and limited to a certain number of login retries within a limited period of time. Once a person exceeds either the retry or time limitation, he or she cannot log in.)
Actions of the cluster manager in setting up an OpenVMS Cluster system can affect the security operations of the system. You can facilitate OpenVMS Cluster security management using the suggestions discussed in the following sections.
The easiest way to ensure a single security domain is to maintain a single copy of each of the following files on one or more disks that are accessible from anywhere in the OpenVMS Cluster system. When a cluster is configured with multiple system disks, you can use system logical names (as shown in Section 5.10) to ensure that only a single copy of each file exists.
The OpenVMS security domain is controlled by the data in the following files:
Note: Using shared files is not the only way of achieving a single security domain. You may need to use multiple copies of one or more of these files on different nodes in a cluster. For example, on Alpha nodes you may choose to deploy system-specific user authorization files (SYSUAFs) to allow for different memory management working-set quotas among different nodes. Such configurations are fully supported as long as the security information available to each node in the cluster is identical.