HP OpenVMS Systems Documentation

By default, a cluster satellite configures its Phase IV Prefix as 49:: and its node synonym directory as .DNA_Nodesynonym. Some clusters may want to have different values for one or both of these attributes. To change these defaults for satellites added to the cluster, define the following logicals in SYS$COMMON:[SYSMGR]NET$LOGICALS.COM before running CLUSTER_CONFIG.

$ define/system/nolog net$phaseiv_prefix "<prefix value>"
$ define/system/nolog decnet_migrate_dir_synonym "<synonym dir>"

To change these values for a satellite that has already been configured, run NET$CONFIGURE from that satellite.

9.1.4 Customizing Your MOP Client Database for Multiple Boot Nodes

By default, the file NET$MOP_CLIENT_STARTUP.NCL resides in SYS$SYSROOT:[SYSMGR]. In this location, however, the MOP client information is only available to the node on which the file resides. It is up to the system manager to make that information available to more boot nodes, if desired.

Both CLUSTER_CONFIG.COM and NET$CONFIGURE.COM modify the file SYS$MANAGER:NET$MOP_CLIENT_STARTUP.NCL for the node on which the procedure is invoked. If the file is found in SYS$SYSROOT:[SYSMGR], it is modified and left in that location. Similarly, if the file is found in SYS$COMMON:[SYSMGR], it is modified and left in that location.

One way of allowing more boot nodes to access NET$MOP_CLIENT_STARTUP.NCL is to move it to SYS$COMMON:[SYSMGR]NET$MOP_CLIENT_STARTUP.NCL. All nodes in the OpenVMS Cluster then have access to it.

Alternatively, you can create one file for common MOP client information. Designated boot nodes can execute this file by placing @ncl_script_name in their own SYS$MANAGER:NET$MOP_CLIENT_STARTUP.NCL file. This method requires more work by the system manager, however, because the configuration procedures does not modify the common file directly.

9.2 Using an OpenVMS Cluster Alias

All or some nodes in an OpenVMS Cluster environment can be represented in the network as a single node by establishing an alias for the OpenVMS Cluster. To the rest of the network, an alias node looks like a normal node. It has a normal node object entry in the namespace, which provides a standard address tower. The alias has a single DECnet address that represents the OpenVMS Cluster environment as a whole. The alias allows access to common resources on the OpenVMS Cluster environment without knowing which nodes comprise the OpenVMS Cluster.

Using an alias never precludes using an individual node name and address. Thus, a remote node can address the OpenVMS Cluster as a single node, as well as address any OpenVMS Cluster member individually.

You decide which nodes participate in an alias. It is not necessary for every member of an OpenVMS Cluster environment to be part of the alias. Those nodes in the OpenVMS Cluster environment that have specifically joined the alias comprise the alias members, and connections addressed to the alias are distributed among these members. You can also have multiple aliases. Multiple aliases allow end nodes to be members of more than one alias. Multiple aliases also allow a mixed architecture cluster. You can have one alias for all the nodes, one for Alpha systems, and another for the VAX systems.

You can have a maximum of three aliases. Members of the same alias must be members of the same OpenVMS Cluster environment. Nodes joining the same alias must be in the same DECnet area.

When creating multiple aliases, the first alias created is used for outgoing connections for any applications, with the outgoing alias attribute set to TRUE. If this alias is not enabled, the local node name is used for the outgoing connection.

Finally, nodes that assume the alias should have a common authorization file.

To add a node in an OpenVMS Cluster environment to the alias, use the NET$CONFIGURE.COM procedure. For information about NET$CONFIGURE.COM, refer to the DECnet-Plus for OpenVMS Applications Installation and Advanced Configuration guide.

Before an alias can be identified by name, you must create a node object entry for it in the namespace. Do this only once for each OpenVMS Cluster.

To add an object entry for an OpenVMS Cluster alias in a DECnet Phase V area, you need:

• The DECdns full name (such as .site.group.my_alias)
• The node id (which is a unique Phase IV-style address such as 63.135)

The decnet_register tool converts a Phase IV-style address of the form area.node into a 6-byte address when registering a Phase IV node (see Section 5.3.4 and Chapter 5 for decnet_register). (In Phase IV, an area has a value in the range of 1--63, and a node has a value in the range of 1--1023. For example, 63.135.) The converted 6-byte address has the form AA-00-04-00-87-FC.

If you are converting an existing Phase IV OpenVMS Cluster to DECnet Phase V, use the existing Phase IV alias address for the Node ID when configuring and registering the alias. If you are installing a new OpenVMS Cluster in a DECnet Phase V network, use any Phase IV-style address that is unique to your network for the node ID when configuring and registering the alias.

If you want to set an outgoing alias for particular nodes in an OpenVMS Cluster, use the following command:

ncl> set alias port port-name outgoing default true

If you want to set an outgoing alias for an application, use the following command:

ncl> set session control application application-name -
_ncl> outgoing alias name alias-name

If you do not set application outgoing alias name and the application has the outgoing alias set to true, the alias name for which you set alias port outgoing default true is used.

If you define application outgoing alias name, this supersedes the setting of alias port outgoing default. If the application outgoing alias name is not enabled, the local node name is used.

If neither alias port outgoing default nor application outgoing alias name is set, the first alias created is used as the default for the system. If this alias is not enabled, the local node name is used.

9.2.4 Controlling Connect Requests to the OpenVMS Cluster Alias

When a node tries to connect to an alias node, it does not know that its destination is an alias. It consults the namespace to translate the alias node name into an address, and uses the address to send data packets to the alias. Data packets can arrive at any node that is an alias member. When a node in the alias receives a request for a connection to the alias, that node selects a member node (possibly itself) to own the connection.

The node makes its selection based on the following criteria:

• First, it checks to see which nodes in the alias are enabled to receive incoming alias connections for the target application in the session control application entity. For more information about connecting to network applications, see Section 9.2.4.1.
• Second, it checks that nodes have not exceeded their maximum connections as defined in the NSP or OSI transport module. For more information about the quota of alias connections, see Section 9.2.4.2.
• Third, for nodes able to accept incoming connect requests, it checks which nodes have a non-zero selection weight attribute. The higher the selection weight value, the more alias connections the node can have. For more information about selection weight, refer to the DECnet-Plus Network Control Language Reference.

Once an eligible node is selected, the incoming connect request is forwarded to that node, and the connection is established.

If your node is in an OpenVMS Cluster environment using an alias, you can specify which network applications will use incoming and outgoing connections in the application database. If you are using the defaults as specified by DIGITAL for the applications that are supplied with DECnet-Plus, the default is that only the MAIL application is associated with the alias (for outgoing connections). If other applications have been added to the database (such as Rdb, DQS, or your supplied application), outgoing alias for the objects associated with those applications can be enabled.

If you converted from Phase IV to Phase V (or added or changed objects prior to installing DECnet-Plus), the objects will not change back to the defaults.

When MAIL is associated with the alias, MAIL effectively treats the OpenVMS Cluster as a single node. Ordinarily, replies to mail messages are directed to the node that originated the message; the reply is not delivered if that node is not available. If the node is in an OpenVMS Cluster and uses the OpenVMS Cluster alias, an outgoing mail message is identified by the alias node address rather than the individual address of the originating node. An incoming reply directed to the alias address is given to any active node in the OpenVMS Cluster and is delivered to the originator's mail file.

The alias permits you to set a proxy to a remote node for the whole OpenVMS Cluster rather than for each node in the OpenVMS Cluster. The proxy for the OpenVMS Cluster system can be useful if the alias node address is used for outgoing connections originated by the application file access listener FAL, which accesses the file system.

Also, do not allow applications, whose resources are not accessible clusterwide, to receive incoming connect requests directed to the alias node address. All processors in the OpenVMS Cluster must be able to access and share all resources (such as files and devices). For more information about sharing files in an OpenVMS Cluster environment, see Section 9.3.

The following example configures a session control application entity to enable or disable incoming or outgoing connect requests. Refer to DECnet-Plus Network Control Language Reference for more information about these attributes.

ncl> create session control
ncl> enable session control

ncl> create session control application mail
ncl> create session control application foo

ncl> set session control application mail -
_ncl> outgoing alias true (1)

ncl> set session control application foo -
_ncl> incoming alias false (2)

ncl> enable session control application mail
ncl> enable session control application foo

1. Specifies that the network application, MAIL, use the OpenVMS Cluster alias rather than the node address for outgoing connections.
2. Restricts incoming connections to only those applications that are appropriate. For example, this command specifies that the network application foo is not allowed to receive incoming connect requests that are directed to the alias.

Section F.2 provides more examples of setting up a session control application entity.

9.2.4.2 Controlling the Number of Connections Allowed for an Alias

The number of connections allowed for an alias equals the number of connections you have specified with the nsp maximum transport connections or osi maximum transport connections characteristic. For more information about configuring the NSP and OSI transports, refer to the DECnet-Plus for OpenVMS Applications Installation and Advanced Configuration guide.

9.3 Sharing Network Applications in an OpenVMS Cluster Environment

If your OpenVMS Cluster environment participates in a DECnet Phase V network, you must decide if you want nodes in the OpenVMS Cluster to share common network definitions for such items as network applications. Sharing common network definitions simplifies updates. You change only the shared definitions rather than changing definitions for each member of the OpenVMS Cluster. To share files, copy the following script files from SYS$SPECIFIC:[SYSMGR] (where they are normally created) to SYS$COMMON:[SYSMGR]:

• NET$APPLICATION_STARTUP.NCL
• NET$MOP_CLIENT_STARTUP.NCL

If you do not want certain files shared, keep them in SYS$SPECIFIC:[SYSMGR]. Keep communication-specific startup scripts, such as the following, that contain hardware-specific information in SYS$SPECIFIC:[SYSMGR]:

• NET$ROUTING_STARTUP.NCL
• NET$MOP_CIRCUIT_STARTUP.NCL
• NET$CSMACD_STARTUP.NCL

If the application database is identical on every node in an OpenVMS Cluster environment, you can share those common definitions among all nodes in the OpenVMS Cluster by issuing the following commands:

1. Rename (or move) the application database on one node to the common system root, for example:

   $ rename sys$specific:[sysmgr]net$application_startup.ncl - _$ sys$common:[sysmgr]net$application_startup.ncl

   
   or

   $ copy sys$specific:[sysmgr]net$application_startup.ncl - _$ sys$common:[sysmgr]net$application_startup.ncl

2. Delete (or rename) the application database from the private system root on each node in the OpenVMS Cluster environment, for example:

   $ delete sys$specific:[sysmgr]net$application_startup.ncl;*

   
   or

   $ rename sys$specific:[sysmgr]net$application_startup.ncl;* - _$ sys$specific:[sysmgr]net$application_startup_old.ncl;*

A system running DECnet-Plus software can act as a host system that performs the following services for remote client systems:

• Downline load a memory image to a network server, such as a wide area router or DECNIS router, or an OpenVMS Cluster satellite
• Upline dump memory from a network server
• Use the console carrier on a network server
• Use the configuration monitor
• Run loopback tests (refer to the DECnet-Plus Problem Solving guide)

The Maintenance Operations Protocol (MOP) module allows you to do these tasks. You can downline load or upline dump DECnet Phase IV or Phase V nodes. Table 10-1 lists the data links that MOP supports and the supported functions for those links.

10.1 Automatically Configuring MOP

Either the configuration procedure creates MOP scripts from the information you supply to the prompts or the software provides a permanent client database:

• The mop client startup script creates and enables the mop entity. Initially, this file does not define any clients.
  sys$manager:net$mop_client_startup.ncl
• The mop circuit startup script creates a mop circuit, links it to a data link station, and then enables the circuit.
  SYS$MANAGER:NET$MOP_CIRCUIT_STARTUP.NCL

If you start MOP (see Section 10.3) after running your configuration procedure, MOP can do its various tasks provided that you supply all necessary attributes in the NCL command or in the passive load request. This includes:

• An NCL command that supplies the address of the client, as well as the names of all images to be loaded
• A passive load request from a device, specifying a file name to be loaded

To downline load an OpenVMS Cluster satellite or to store information about downline loads to specific network servers, you can use the mop client database. The mop client database stores information, so you do not have to enter it every time you issue an NCL command.

The mop client database is the NET$MOP_CLIENT_STARTUP.NCL script file. You can add information to or delete information from it with the NET$CONFIGURE.COM Option 8, "Configure MOP Client database." If you want to add a client, the procedure prompts you for information about the client such as the following:

• Client name
• Circuit name
• LAN address(es)
• Secondary loader
• Tertiary loader
• System image
• Diagnostic image
• Script file
• Management image