Updated: 11 December 1998

OpenVMS System Manager's Manual

To configure SNMP on the system and enable the master agent to accept SET commands from SNMP clients, issue the following TCP/IP Services management command from the TCPIP> prompt. This operation requires SYSPRV or BYPASS privileges.

TCPIP> SET CONFIGURATION SNMP /FLAGS=SETS

To enable or disable the type of access to your local MIB data, use the following commands, qualifiers, and options:

TCPIP> SET CONFIGURATION SNMP /[NO]COMMUNITY="name" - _TCPIP> /[NO]ADDRESS=host address - _TCPIP> /TYPE=[NO]READ,[NO]TRAP,[NO]WRITE

For example, the following command configures SNMP, specifies the community name and address, specifies that the agent can accept SET commands from members of the community, and enables the master agent to send trap messages to members of the community. (Note that READ access is assumed when specifying TRAP or WRITE.)

TCPIP> SET CONFIGURATION SNMP /COMMUNITY="public" /ADDRESS=128.45.2.8 - _TCPIP> /TYPE=TRAP,WRITE

For your convenience, the following files have example entries to start, run, and shut down the DSM subagents.

• [TCPIP$SNMP]TCPIP$EXTENSION_MIB_STARTUP.COM. (This file is called by TCPIP$SNMP_STARTUP.COM.)
• [TCPIP$SNMP]TCPIP$EXTENSION_MIB_RUN.COM. (This file is called by TCPIP$SNMP_RUN.COM.)
• [TCPIP$SNMP]TCPIP$EXTENSION_MIB_SHUTDOWN.COM. (This file is called by TCPIP$SNMP_SHUTDOWN.COM.)

Search the files for SVRSYSTEM_MIB entries and edit them as needed. You must also remove the GOTO entries, which cause the command procedures to simply exit.

C.2 Compaq Cluster MIB Subagents

The Compaq Cluster MIB (DCM) is a private Compaq management information base that delivers management information about OpenVMS Cluster systems.

The DCM consists of two extensions, or subagents:

Extension	Describes
System	A management interface to cluster system information not defined by standard MIBs
Management	Instrumentation in the Compaq extension agent, including the ability to detect and monitor thresholds on integer variables

The representation of the DCM within the standard Structure of Managed Information (SMI) framework is:

iso(1) org(3) dod(6) internet(1) private(4) enterprises(1) 36

OpenVMS Alpha Version 7.2 implements the DCM subagents. With the DCM subagents, you can remotely determine status information for an OpenVMS Cluster system, including the following:

• Cluster software version
• Status of the cluster software: installed, running, failed, and so forth
• Type of cluster that is running
• State change to reflect when a cluster member is added or deleted

Use the following software to access the DCM subagents:

• The DIGITAL ServerWORKS Manager Version 3.0 or any MIB browser that has access to the DCM definitions.
• DIGITAL TCP/IP Services for OpenVMS Version 4.1 or later. The DCM subagents use the SNMP agent supplied with TCP/IP Services to communicate with SNMP clients.

The following sections describe the DCM subagents and explain how to set up your system to use them.

C.2.1 Overview of DCM Subagents

DCM subagents respond to SNMP requests for a DCM object --- the data item that the network manager is concerned with, or a trap --- information about a change of status. A subagent is responsible for reporting on and maintaining the data pertaining to these objects and traps.

The DCM subagents implement the objects listed in Table C-4. Each object returns information relevant to an OpenVMS Cluster system and can be accessed by a network manager through ServerWORKS Manager.

Table C-4 DCM Subagent Objects Implemented on OpenVMS

Object	Data Type	Access	Description
Cluster Information
svrCluSoftwareVendor	DisplayString	Read only	Cluster software vendor name. The current value is Digital.
svrCluSoftwareVersion	DisplayString	Read only	Cluster software version. This is the OpenVMS version string.
svrCluSoftwareStatus	ClusterStatus	Read only	The status of the cluster software. Possible values are running and not running.
svrCluClusterType	ClusterType	Read only	The type of cluster that is running. The current value is OpenVMS.
svrCluExtensionOID	Object Identifier	Read only	The authoritative identification for the MIB. If no such identifier exists, the value {0.0} is returned.
svrCluThisMember	Integer	Read only	Index into the member table (svrCluMemberTable) that corresponds to this node.
SMNP Traps
svrCluMemberAdded	Trap Packet	Read only	Generated when a cluster member is added.
svrCluMemberDeleted	Trap Packet	Read only	Generated when a cluster member is deleted.
Node-Specific Information
svrCluMemberIndex	Integer	Read only	A unique index for the entry. Values of svrCluMemberIndex must remain constant at least between reboots of the network management system on the managed node. Where possible, this value should reflect the system's native member identifier.
svrCluMemberName	DisplayString	Read only	The SCS node name of this cluster member. A zero-length value means the member's node name is unknown. This name may not necessarily resolve to an address.
svrCluMemberComment	DisplayString	Read only	This is the hardware name of the node, as returned by the $GETSYI system service.
svrCluMemberStatus	MemberStatus	Read only	Status of this member. Possible values are normal and removed.
svrCluMemberAddressIndex	Integer	Read only	The index for this address.
svrCluMemberAddress	IpAddress	Read only	An IP address of this cluster member. This address may not be reachable from nodes that are not configured into the cluster.

C.2.2 Setting Up the System to Use the DCM Subagents

For your convenience, the following files have example entries to start, run, and shut down the DCM subagents.

• [TCPIP$SNMP]TCPIP$EXTENSION_MIB_STARTUP.COM. (This file is called by TCPIP$SNMP_STARTUP.COM.)
• [TCPIP$SNMP]TCPIP$EXTENSION_MIB_RUN.COM. (This file is called by TCPIP$SNMP_RUN.COM.)
• [TCPIP$SNMP]TCPIP$EXTENSION_MIB_SHUTDOWN.COM. (This file is called by TCPIP$SNMP_SHUTDOWN.COM.)

Search the files for SVRCLUSTER_MIB entries and edit them as needed. You must also remove the GOTO entries, which cause the command procedures to simply exit.

The OpenVMS Registry Server manages the OpenVMS Registry Database. For more information, see the OpenVMS Connectivity Developer's Guide.

This chapter describes how to install and manage the OpenVMS Registry server, which is part of the OpenVMS Version 7.2 system installation.

D.1 Accessing the OpenVMS Registry

The OpenVMS Registry database is created the first time you start the OpenVMS Registry server. You must define the SYS$REGISTRY logical before starting the OpenVMS Registry server. The OpenVMS Registry server will not start if you have not defined the SYS$REGISTRY logical.

To access the OpenVMS Registry using the COM APIs, you must install COM for OpenVMS.

To access the OpenVMS Registry using the Windows NT application RegEdt32, you must first install, configure, and start Advanced Server for OpenVMS.

D.2 Configuring the OpenVMS Registry

The value of the SYS$REGISTRY logical determines the disk location of the OpenVMS Registry database files. You must define the SYS$REGISTRY logical name before the system will start the OpenVMS Registry server.

In an OpenVMS Cluster, the OpenVMS Registry database must reside on a central disk accessible to each node that will run an OpenVMS Registry server. For each node you must define the SYS$REGISTRY logical name to point to the same centrally accessible disk and directory.

Compaq recommends that you modify the SYS$MANAGER:SYLOGICALS.COM command file to include the definition of SYS$REGISTRY. The SYLOGICALS.TEMPLATE file includes the following information:

$! If any component uses the OpenVMS Registry, you must uncomment the $! following line, editing it to provide a common cluster-wide definition. $! $! DEFINE SYS$REGISTRY cluster-visible directory specification $!

Example D-1 shows how to define the SYS$REGISTRY logical.

Example D-1 Sample SYS$REGISTRY Definition

$ CREATE/DIRECTORY DKA100:[SYS$REGISTRY] $ DEFINE SYS$REGISTRY DKA100:[SYS$REGISTRY]

D.2.1 Starting the OpenVMS Registry

After you configure the system to run the OpenVMS Registry, the OpenVMS Registry server is started automatically when you reboot the system. You can use the REG$TO_BE_STARTED logical to enable or disable automatic OpenVMS Registry server startup.

By default, the REG$TO_BE_STARTED logical is undefined. If the REG$TO_BE_STARTED logical is undefined or set to TRUE, the OpenVMS Registry server starts automatically when you reboot the system.

If the REG$TO_BE_STARTED logical is undefined, the OpenVMS Registry server starts automatically by the COM for OpenVMS startup procedure when you start COM for OpenVMS on your system.

If you do not want to start the OpenVMS Registry server automatically on a system, modify the SYS$MANAGER:SYLOGICALS.COM file to include the following definition:

$ DEFINE REG$TO_BE_STARTED FALSE

Compaq recommends that you use the SYS$STARTUP:REG$STARTUP.COM command procedure to start the OpenVMS Registry server manually. This command procedure ensures that the server process quotas are set to the required minimum values.

The minimum process requirements for the OpenVMS Registry server are described in Table D-1.

Table D-1 OpenVMS Registry Server Process Requirements

Process	Value
ast_limit:	64
buffer_limit:	100000
enqueue_limit:	200
file_limit:	64
maximum_working_set:	4096
page_file:	400000
priority:	8
Privilege:	SYSPRV
working_set:	2048

D.2.2 Shutting Down the OpenVMS Registry

To shut down the OpenVMS Registry, use the STOP/ID=nnnnnnnnn command; this stops the OpenVMS Registry server process.

D.2.3 OpenVMS Registry Failover in a Cluster

To increase the availability and reliability of the OpenVMS Registry, you can run multiple OpenVMS Registry servers in a cluster, up to one per node. No matter how many OpenVMS Registry servers you run, you have only one OpenVMS Registry database.

When you run more than one OpenVMS Registry server in a cluster, only one OpenVMS Registry server process is active and writing to the OpenVMS Registry database. The other OpenVMS Registry server processes are standing by.

By default, the first active OpenVMS Registry server process in the cluster remains active until either the process no longer exists or the priority among OpenVMS Registry server processes changes.

D.2.4 Setting and Changing Priority Values

You can change the priority of OpenVMS Registry server processes by creating and modifying the priority value of each node in the cluster that will run the OpenVMS Registry server process; the higher the value, the higher the priority.

Example D-2 shows priority values being assigned so that NODENAME1 will be the active OpenVMS Registry server process in the cluster.

Example D-2 Setting Priority Values

$ mcr reg$cp REG> CREATE VALUE HKEY_LOCAL_MACHINE\SYSTEM\REGISTRY\PRIORITY - _REG> /NAME=NODENAME1/DATA=15/TYPE=DWORD REG> CREATE VALUE HKEY_LOCAL_MACHINE\SYSTEM\REGISTRY\PRIORITY - _REG> /NAME=NODENAME2/DATA=10/TYPE=DWORD REG> CREATE VALUE HKEY_LOCAL_MACHINE\SYSTEM\REGISTRY\PRIORITY - _REG> /NAME=NODENAME3/DATA=5/TYPE=DWORD

In Example D-2, if NODENAME1 shuts down, control of the OpenVMS Registry database passes to the server process on NODENAME2.

Example D-3 shows the system manager increasing the priority value of NODENAME3 to 20.

Example D-3 Changing Priority Values

$ mcr reg$cp REG> MODIFY VALUE HKEY_LOCAL_MACHINE\SYSTEM\REGISTRY\PRIORITY - _REG> /NAME=NODENAME3/DATA=20/TYPE=DWORD

In Example D-3, the OpenVMS Registry server process on NODENAME1 goes into standby mode and the OpenVMS Registry server process on NODENAME3 becomes active.

D.3 Connecting to the OpenVMS Registry from a Windows System

When you access the OpenVMS Registry database from a Windows system, you will have all the privileges granted on your Windows system. For example, if you are logged in to the Windows NT system as an Administrator, you will be able to read and write to all keys and values in the OpenVMS Registry.

Be careful when modifying OpenVMS Registry database keys and values. If you damage a Windows NT Registry database, you affect only one user (the user of the Windows NT system). If you damage the OpenVMS Registry database, you affect all applications and users on the system or cluster.

D.4 Using OpenVMS Registry Quotas

A quota mechanism limits the size of the OpenVMS Registry. The system assigns a quota to the root key for every OpenVMS Registry file. By default, these root keys are the USERS key and the LOCAL_MACHINE key. The quota limits the size of the information contained within the file, but does not include the size of information stored in other files, even if they are part of the subtree. For example, USERS has a quota. USERS has subkey1 and subkey2, but subkey2 is saved to a separate file. The quota for USERS limits the size of USERS and subkey1 and all of their descendants, but not the size of subkey2 and its descendants.

The default quota and file-specific quotas are stored in the OpenVMS Registry under the HKEY_LOCAL_MACHINE\SYSTEM\Registry key.

D.5 Using the OpenVMS Registry in an Alpha Mixed-Version Cluster

The OpenVMS Registry Server can run in an Alpha mixed-version cluster. That is, the OpenVMS Registry can run in a cluster that includes OpenVMS versions other than OpenVMS Version 7.2. However, the OpenVMS Registry must be running on the node that is running OpenVMS Version 7.2.

D.6 Internationalization and Unicode Support

To integrate with Windows NT, the OpenVMS Registry is Unicode compliant. For more information on Unicode, see the OpenVMS Version 7.2 New Features Manual.

Copyright © Compaq Computer Corporation 1998. All rights reserved. Legal

6017PRO_106.HTML