| Updated: 21 January 1999 |
OpenVMS Connectivity Developer Guide
| Previous | Contents | Index |
There are no qualifiers unique to DEC C that you must specify when you
build COM for OpenVMS applications.
6.5 Step 4: Link the COM Application
To build a COM for OpenVMS application, you must build both client and component images. Because you can implement a component as either an in-process component or an out-of-process component, you must build either a shareable image or an executable image, or both. If you are creating a new interface, you must also build a proxy/stub shareable image. The proxy/stub shareable image provides an interface-specific object that packages parameters for that interface in preparation for a remote method call. A proxy runs in the sender's address space and communicates with a corresponding stub in the receiver's address space.
The following sections describe the steps you must follow to link the
client, component, and proxy/stub images.
6.5.1 Linking the Client and the Out-of-Process Component
Although you do not need to specify any qualifiers to link the client or the component executable images, you must link both images with the following:
The specific link-time dependencies are as follows:
If you have one or more C++ modules, use the C++ linker (CXXLINK) instead of the standard OpenVMS linker so you can specify the location of your C++ repository (/CXX_REPOSITORY qualifier). For example:
$ CXXLINK/your-specific-linker-qualifiers list-of-object-modules, - _$ DCOM$WIN32:WINDU.OPT/OPTIONS, DCOM$LIBRARY:DCOM.OPT/OPTIONS - _$ application.OPT/OPTIONS /REPOSITORY=[.CXX_REPOSITORY] |
Other ways of including the options file are as follows:
The component in-process shareable image dependency list differs slightly from that of the client and component executables. The specific link-time dependencies are as follows:
Linking the in-process component shareable image requires that you create a symbol vector for the entry points that COM for OpenVMS expects to call within the shareable image. The Win32 run-time environment enforces a naming standard on the DllMain entry point, which must contain the following:
For example, a component shareable image with the name CMPNT$SHR would define the symbol vector using the following options file:
!
! The list of symbols exported by CMPNT$SHR.EXE.
!
SYMBOL_VECTOR=(-
_WindU_DllMain_CMPNT$/DllMain = PROCEDURE,-
DllGetClassObject = PROCEDURE,-
DllCanUnloadNow = PROCEDURE,-
DllRegisterServer = PROCEDURE,-
DllUnregisterServer = PROCEDURE)
|
A component shareable image with the name CMPNT_SHARE would define the symbol vector using the following options file:
!
! The list of symbols exported by CMPNT_SHARE.EXE.
!
SYMBOL_VECTOR=(-
_WindU_DllMain_CMPNT_SHARE/DllMain = PROCEDURE,-
DllGetClassObject = PROCEDURE,-
DllCanUnloadNow = PROCEDURE,-
DllRegisterServer = PROCEDURE,-
DllUnregisterServer = PROCEDURE)
|
The proxy/stub shareable image dependency list differs slightly from that of the client and component executables. The specific link-time dependencies are as follows:
Linking the proxy/stub shareable image is more involved because you must create a symbol vector for the entry points that COM for OpenVMS expects to call within the shareable image. The Win32 run-time environment enforces a naming standard on the DllMain entry point, which must contain the following:
For example, a proxy/stub shareable image with the name PROXY$SHR would define the symbol vector using the following options file:
!
! RPC Shareable Image
!
SYS$LIBRARY:DCOM$RPCRT4_SHR.EXE/SHARE
!
!
! The list of symbols exported by PROXY$SHR.EXE.
!
SYMBOL_VECTOR=(-
_Windu_DllMain_PROXY$/DllMain = PROCEDURE,-
DllGetClassObject = PROCEDURE,-
DllCanUnloadNow = PROCEDURE,-
GetProxyDllInfo = PROCEDURE,-
DllRegisterServer = PROCEDURE,-
DllUnregisterServer = PROCEDURE)
|
A proxy/stub shareable image with the name PROXY_SHARE would define the symbol vector using the following options file:
!
! RPC Shareable Image
!
SYS$LIBRARY:DCOM$RPCRT4_SHR.EXE/SHARE
!
!
! The list of symbols exported by PROXY_SHARE.EXE.
!
SYMBOL_VECTOR=(-
_Windu_DllMain_PROXY_SHARE/DllMain = PROCEDURE,-
DllGetClassObject = PROCEDURE,-
DllCanUnloadNow = PROCEDURE,-
GetProxyDllInfo = PROCEDURE,-
DllRegisterServer = PROCEDURE,-
DllUnregisterServer = PROCEDURE)
|
The following sections list and describe the required OpenVMS Registry
entries.
6.6.1 HKEY_CLASSES_ROOT\CLSID
The CLSID subkey contains all CLSIDs for the components supported on your system. You must register your components' CLSIDs here. Each registered CLSID should contain the following:
A class identifier (CLSID) is a globally unique identifier (GUID) associated with an OLE class object. COM for OpenVMS server applications typically register their CLSIDs in the OpenVMS Registry so clients can locate and load the executable code associated with the OLE class object.
Register the CLSID for the component under the subkey HKEY_CLASSES_ROOT\CLSID.
A component CLSID registration should contain the following subkeys:
HKEY_CLASSES_ROOT\CLSID\{GUID}\TYPELIB {value=LIBID}
|
The proxy/stub shareable image provides an interface-specific object for packaging parameters for that interface. Because the proxy/stub shareable image contains an object, it needs a CLSID and it needs to be included in the OpenVMS Registry. You must register a CLSID for the proxy in the OpenVMS Registry the same way as the CLSID for the component.
The CLSID for the proxy should be registered under the subkey HKEY_CLASSES_ROOT\CLSID.
A proxy/stub CLSID registration should contain the following subkey:
The Interface subkey contains all interfaces registered with the system. You must register the component's interface IDs (IIDs) in this subkey.
Each interface registered contains at least one of the following subkeys:
The Windows NT Registry is a single, systemwide hierarchical database of configuration information about hardware and software (both the operating system and applications). The Windows NT Registry replaced Windows 3.x .ini files, providing a single place for storing application and configuration information.
To allow OpenVMS and Windows NT to interoperate, Compaq has provided a registry on OpenVMS. Like the Windows NT Registry, the OpenVMS Registry is made up of two components: the OpenVMS Registry database and the OpenVMS Registry server. The OpenVMS Registry database is a systemwide or clusterwide hierarchical database of configuration information. This information is stored in a database structure of keys and associated values. The OpenVMS Registry server controls all OpenVMS Registry operations, such as creating and backing up the OpenVMS Registry database, and creating, displaying, modifying, or deleting keys and values.
The OpenVMS Registry includes interfaces (COM APIs and system services) to allow applications to control the OpenVMS Registry server and to read and write to the OpenVMS Registry database. The OpenVMS Registry also includes server management utilities to allow system managers to display and update OpenVMS Registry information from the OpenVMS DCL command line.
The OpenVMS Registry is compatible with the Windows NT Registry. Windows NT
client applications such as RegEdt32 can connect to and edit
the OpenVMS Registry.
7.1.1 Suggested Reading
The following resources can provide you with more information about Windows NT Registry and related topics:
The OpenVMS Registry, like the Windows NT Registry, is a hierarchical database with several branches.
The following sections list and explain OpenVMS Registry database elements
and operation in more detail.
7.2.1 Keys, Subkeys, and Values
A key is one of the basic building blocks of the OpenVMS Registry database. A key contains information specific to the computer, system, or user; it is a header field in the OpenVMS Registry database. Keys can be arranged in a hierarchy (or tree).
There are two main (or root) keys in the OpenVMS Registry:
The key HKEY_CLASSES_ROOT points to the CLASSES subkey in HKEY_LOCAL_MACHINE. These root keys are discussed in more detail in Section 7.3.
A subkey is a key that is a child to another key. A key can have zero or more subkeys. Subkeys allow you to group related keys together below another key in a hierarchy or tree.
A value entry (or value) is a named element of data; it is a record field in the registry database. A key has zero or more associated values. A value has a value name, a value type, a collection of flags, and associated data (defined by the value's type). OpenVMS Registry supports the following value types:
Figure 7-1 summarizes the relationship between keys, subkeys, and values.
Figure 7-1 Key, Subkey, and Value Relationships
Key1=Value1
Key2
|
+-Subkey1=Value1
|
+-Subkey2=Value1,Value2
:
.
|
You can define OpenVMS Registry keys and values as either nonvolatile or volatile. Nonvolatile keys are saved to OpenVMS Registry files. Volatile keys are cached to a temporary file.
On Windows NT systems, volatile keys and values are removed when the system restarts.
On OpenVMS, volatile keys and values are automatically removed when all
nodes in a cluster are rebooted. OpenVMS extends the lifetime of
volatile keys to survive server failover but not a cluster reboot. (In
a standalone system, volatile keys and values are lost when the system
reboots.)
7.2.1.2 Key Write-through and Write-behind
When you create a key, you can specify when the OpenVMS Registry should write that key's changed information. The write options are as follows:
The Cache Action attribute allows you to specify a key's write characteristics. If you do not specify the Cache Action attribute when you create the key, the key inherits this attribute from its parent.
When you use the SYS$REGISTRY interface, you can use the the
REG$M_NOW function code modifier for a request in progress to
force an immediate write (write-through), regardless of the
Cache Action attribute value.
7.2.1.3 Linking a Key to Other Keys and Values
OpenVMS Registry keys can link to other OpenVMS Registry keys, providing multiple paths to the same piece of data. In the same way, OpenVMS Registry values can link to other OpenVMS Registry values. These key and value links, or symbolic links, are similar to file links. Symbolic links are name references.
For example, you can link Key A to Key B. When you query Key A and its value, the system returns Key B's value.
You can also chain symbolic links. That is, Key
A can point to Key B and Key B can point to
Key C; as a result, Key A also points to Key
C. You can specify a link through the $REGISTRY system service or
through the OpenVMS Registry server management command-line interface.
7.2.1.4 Rules for Creating OpenVMS Registry Keys and Value Names
The following rules apply to key and value names:
The Class attribute allows you to store additional descriptive
information with each key. For example, specifying Class text
string could allow you store permitted data types with a specified
key.
7.2.3 Hive
A hive is a collection of related keys, subkeys, and values stored in the OpenVMS Registry.
On Windows NT systems, a hive is stored in a single file in the %SystemRoot%\system32\config directory, along with an associated LOG file. Windows NT allows users to save hives to specified files on disk so that these files can be loaded at a later time.
On OpenVMS systems, the entire OpenVMS Registry database consists of two
hives: REGISTRY$LOCAL_MACHINE.REG and
REGISTRY$USERS.REG. OpenVMS does not support loading and
unloading hives.
7.3 OpenVMS Registry Structure
To allow Windows NT applications to interface with the OpenVMS Registry database, the OpenVMS Registry database includes a subset of the Windows NT Registry predefined keys and subkeys.
The OpenVMS Registry includes the following predefined standard keys:
$ MCR REG$CP REG> CREATE VALUE/NAME=REGISTRY$LOCAL_MACHINE/TYPE=DWORD/ - _REG> DATA=%D1000000 "hkey_local_machine\system\registry\File Quotas" |
$ MCR REG$CP REG> CREATE VALUE/NAME=COSMOS/TYPE=DWORD/DATA=%D100 - _REG> "hkey_local_machine\system\registry\Priority" |
You can read and write to the OpenVMS Registry in the following ways:
The OpenVMS Registry includes two OpenVMS system services that provide an interface to the OpenVMS Registry server. The OpenVMS Registry system services allow you to query, update, and create keys, subkeys, and values in the OpenVMS Registry database.
For more information about the $REGISTRY and $REGISTRYW system
services, see Chapter 10.
7.4.2 REG$CP Server Management Utility
The REG$CP server management utility allows you to display and update OpenVMS Registry information from the OpenVMS DCL prompt. The utility also allows you to back up and restore the entire OpenVMS Registry database to or from a file, as long as you have the required system privileges.
For more information about the REG$CP server management
utility, see Chapter 9.
7.5 OpenVMS Registry Security
The OpenVMS Registry implements both the OpenVMS and Windows NT security models.
To access to the OpenVMS Registry database, the calling process must have the proper OpenVMS Registry rights identifier for the operation you want to perform (for example, REG$LOOKUP for read operations, REG$UPDATE for write operations, or REG$PERFORMANCE for statistics operations) or the calling process must have the SYSPRV privilege.
The following sections describe the two models.
7.5.1 OpenVMS Security Model
When a user requests access to the OpenVMS Registry, the OpenVMS system checks the user's NT credentials and allows access as follows:
You can add the SYSPRV, REG$UPDATE, REG$LOOKUP, and REG$PERFORMANCE identifiers to user processes by using the OpenVMS Authorize utility.
Granting OpenVMS Registry rights overrides Windows NT security access checks. |
The following example shows how to use the SET RIGHTS_LIST command to allow all users to view keys and data in the OpenVMS Registry database. This command adds the REG$LOOKUP identifier to the system rights list.
$ SET RIGHTS_LIST/ENABLE/SYSTEM REG$LOOKUP |
Example 7-1 shows how to use AUTHORIZE to grant and remove OpenVMS Registry rights to a specific user.
| Example 7-1 Using AUTHORIZE to Grant Rights to a User |
|---|
$ SET DEF SYS$SYSTEM $ RUN AUTHORIZE UAF> GRANT/IDENTIFIER REG$LOOKUP SMITH (1) UAF> GRANT/IDENTIFIER/ATTRIBUTES=DYNAMIC REG$UPDATE SMITH (2) UAF> REVOKE/IDENTIFIER REG$UPDATE SMITH (3) UAF> GRANT/IDENTIFIER REG$PERFORMANCE SYSTEM (4) |
Windows NT users can access the OpenVMS Registry only through the
Advanced Server for OpenVMS. OpenVMS grants Windows NT users access to the
OpenVMS Registry based on the user's NT credentials.
7.6 Controlling the OpenVMS Registry Server Operations
OpenVMS Registry server operations include control of file quotas, server priority, error recovery actions, frequency of database backup, and OpenVMS Registry server tuning.
The following sections describe OpenVMS Registry server operations, and
provide minimum, maximum, and default values for each setting. For
information about how to change these settings, see Chapter 9.
7.6.1 Defining Maximum Reply Age/Age Checker Interval Settings
The OpenVMS Registry server handles duplicate requests by tracking work in progress and returning a REG$_DUPLREQUEST error. The OpenVMS Registry server also holds completed requests in case a duplicate request is received for work that is already completed. In this case, the OpenVMS Registry server reconstructs the reply. After a specified time, the requests are discarded. The Maximum Reply Age setting determines how long these requests are retained. The Age Checker Interval setting determines how often the OpenVMS Registry server checks for requests that exceed this age.
By default, the server checks for old completed requests every five seconds. By default, the server discards completed requests that are older than five seconds.
| Setting Name | Default value | Minimum value | Maximum value |
|---|---|---|---|
| Maximum Reply Age | 5 | 1 | 60 |
| Age Checker Interval | 5 | 1 | 60 |
The OpenVMS Registry uses a a two-phase commit process to write modifications to the OpenVMS Registry database. The OpenVMS Registry first writes the modifications to a log file and then applies the log file to the OpenVMS Registry database. The Database Log Cleaner Interval setting determines how often the OpenVMS Registry applies the log file to the OpenVMS Registry database. After the OpenVMS Registry applies the log file, the OpenVMS Registry creates a new log file based on the size you specify in the Initial Log File Size setting.
The Database Log Cleaner Interval setting should be short enough so that writes to the database do not require that the log file be extended. Also, the log file size should be small to keep the amount of time spent applying the log relatively short, because this operation blocks writes to the database.
By default, the log file is applied every five seconds. By default, the OpenVMS Registry log file is created using a size of 32 blocks (16 KB).
| Setting Name | Default value | Minimum value | Maximum value |
|---|---|---|---|
| Database Log Cleaner Interval | 5 | 1 | 30 |
| Initial Log File Size | 32 | 16 | 256 |
The OpenVMS Registry server limits the size of OpenVMS Registry database files by applying file quotas. You can assign file quotas to the individual files that make up the OpenVMS Registry database. If you do not assign a file quota, the OpenVMS Registry uses the Default File Quota setting.
The OpenVMS Registry server periodically recalculates the size of the OpenVMS Registry database files to see whether quota is exceeded. The File Quota Interval setting determines how often the OpenVMS Registry performs this calculation.
By default, the Default File Quota setting is 10 MB. By default, the server recalculates the file quota every 30 seconds.
| Setting Name | Default value | Minimum value | Maximum value |
|---|---|---|---|
| Default File Quota | 0x10000000 | 0x7d00 | 0x3fffffff |
| File Quota Interval | 30 | 10 | 60 |
In an OpenVMS Cluster, you can run OpenVMS Registry servers on more than one node; however, only one OpenVMS Registry server is active at a time. A OpenVMS Registry server's priority relative to the other OpenVMS Registry servers in the cluster determines which OpenVMS Registry server is active. If the cluster configuration changes, the system manager can adjust the priority of one or more OpenVMS Registry servers. After the system manager changes the priority, the OpenVMS Registry servers in the cluster determine which server now has the highest priority and automatically change their states as necessary. The Scan Interval setting determines how often a OpenVMS Registry server checks for changes in its priority.
By default, a server checks for changes in priority every 120 seconds.
| Setting Name | Default value | Minimum value | Maximum value |
|---|---|---|---|
| Scan Interval | 120 | 60 | 300 |
The OpenVMS Registry server logs an error if one of the OpenVMS Registry server parameter values is out of the acceptable range. If the OpenVMS Registry detects an out-of-range error, the OpenVMS Registry server uses the default value for that parameter. The Log Registry Value Error setting is a Boolean value that determines whether the error should be logged.
By default, the OpenVMS Registry server does not log out-of-range errors.
| Setting Name | Default value | Minimum value | Maximum value |
|---|---|---|---|
| Log Registry Value Error | 0 | 0 | 1 |
If an I/O error occurs, the OpenVMS Registry server can display a message to the operator console using OPCOM. The Operator Communications Interval setting determines how long the OpenVMS Registry server waits after the I/O error to determine if the error is going to persist. If the error does persist, OpenVMS Registry writes a message to the operator console.
By default, the OpenVMS Registry server writes a message to the operator console if the error persists longer than 60 seconds.
| Setting Name | Default value | Minimum value | Maximum value |
|---|---|---|---|
| Age Checker Interval | 5 | 1 | 60 |
| Operator Communication Interval | 60 | 30 | 120 |
The OpenVMS Registry server writes a message to the server log file if it takes too long to process a request. The Process Time Limit setting determines when a request has taken too long.
By default, 180 seconds are allowed per request before the OpenVMS Registry logs a message.
| Setting Name | Default value | Minimum value | Maximum value |
|---|---|---|---|
| Process Time Limit | 180 | 60 | 600 |
The OpenVMS Registry server maintains a log of recent replies that it uses to reconstruct work in progress in the case of failover. After a specified time, the server discards these replies. The Reply Log Cleaner Interval setting determines how often the OpenVMS Registry discards these replies.
By default, the OpenVMS Registry server discards replies every five seconds.
| Setting Name | Default value | Minimum value | Maximum value |
|---|---|---|---|
| Reply Log Cleaner Interval | 10 | 5 | 60 |
The OpenVMS Registry server maintains backup copies of the OpenVMS Registry database. The Snapshot Interval setting determines how often the OpenVMS Registry server creates a backup copy. The Snapshot Location setting determines where the OpenVMS Registry stores the copy. The Snapshot Versions setting determines how many previous copies the OpenVMS Registry keeps.
By default, the OpenVMS Registry database is copied to backup once per day. By default, the OpenVMS Registry database is copied to the location determined by the definition of the SYS$REGISTRY logical name. By default, the OpenVMS Registry keeps five previous versions of the OpenVMS Registry database.
| Setting Name | Default value | Minimum value | Maximum value |
|---|---|---|---|
| Snapshot Interval | 86400 | 3600 | 604800 |
| Snapshot Location | SYS$REGISTRY | --- | --- |
| Snapshot Versions | 5 | 1 | 10 |
In the OpenVMS Registry finds an error when writing to the OpenVMS Registry database, the OpenVMS Registry server retries the write at an interval specified by the Write Retry Interval setting.
By default, the OpenVMS Registry server attempts to retry failed writes to the OpenVMS Registry database every five seconds.
| Setting Name | Default value | Minimum value | Maximum value |
|---|---|---|---|
| Writer Retry Interval | 5 | 1 | 30 |
The OpenVMS Registry server is installed as part of the OpenVMS Version 7.2 system installation. The first time you start the OpenVMS Registry server using the startup process described in Section 8.3, the OpenVMS system creates the OpenVMS Registry database.
You must define the SYS$REGISTRY logical name before you start the OpenVMS Registry server. The OpenVMS Registry server will not function correctly if you have not defined the SYS$REGISTRY logical name.
You can access the OpenVMS Registry in several ways. Depending on how you want to access the OpenVMS Registry, you must install the following products:
You can also access the OpenVMS Registry using the OpenVMS Registry server
management utility or the OpenVMS Registry system services, which are
installed as part of the OpenVMS Registry in OpenVMS Version 7.2.
8.2 Configuring the OpenVMS Registry
The SYS$REGISTRY logical name value determines the disk location of the OpenVMS Registry database files. You must define the SYS$REGISTRY logical name before the system can start and run 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 8-1 shows how to define the SYS$REGISTRY logical name.
| Example 8-1 Sample SYS$REGISTRY Logical Name Definition |
|---|
$ CREATE/DIRECTORY DISK$MEAGAN:[SYS$REGISTRY] $ DEFINE/SYSTEM SYS$REGISTRY DISK$MEAGAN:[SYS$REGISTRY] |
You can control how the OpenVMS Registry will start as follows:
The following sections describe how to define the different startup
options for the the OpenVMS Registry.
8.3.1 Starting the OpenVMS Registry Automatically on Reboot
If you define the REG$TO_BE_STARTED logical name to TRUE, the OpenVMS Registry server starts automatically when you reboot the system. Modify the SYS$MANAGER:SYLOGICALS.COM file to include the following definition:
$ DEFINE REG$TO_BE_STARTED TRUE |
If you leave the REG$TO_BE_STARTED logical name undefined or set the REG$TO_BE_STARTED logical name to TRUE, the OpenVMS Registry server will be started automatically by the COM for OpenVMS startup procedure or by the Advanced Server for OpenVMS startup procedure when you start either of these products on your system.
Modify the SYS$MANAGER:SYLOGICALS.COM file to include the following definition:
$ DEFINE REG$TO_BE_STARTED TRUE |
8.3.3 Starting the OpenVMS Registry Manually
Under some conditions, you might want to start the OpenVMS Registry server
manually. Compaq recommends that you use the
SYS$STARTUP:REG$STARTUP.COM command procedure. This command
procedure ensures that the server process quotas are set to the
required minimum values.
Example 8-2 shows an example of how to define the SYS$REGISTRY logical name and start the OpenVMS Registry using the SYS$STARTUP:REG$STARTUP.COM command procedure.
| Example 8-2 OpenVMS Registry Manual Startup Procedure |
|---|
$ CREATE/DIRECTORY DISK$MEAGAN:[SYS$REGISTRY] $ DEFINE SYS$REGISTRY DISK$MEAGAN:[SYS$REGISTRY] $ @SYS$STARTUP:REG$STARTUP.COM |
If you do not want the OpenVMS Registry server to start automatically on a system, modify the SYS$MANAGER:SYLOGICALS.COM file to include the following definition:
$ DEFINE REG$TO_BE_STARTED FALSE |
Table 8-1 lists the minimum process requirements for the OpenVMS Registry server.
| Process | Value |
|---|---|
| ast_limit: | 64 |
| buffer_limit: | 100000 |
| enqueue_limit: | 200 |
| file_limit: | 64 |
| maximum_working_set: | 4096 |
| page_file: | 400000 |
| priority: | 8 |
| working_set: | 2048 |
| Privilege: | SYSPRV |
Use the following procedure to shut down the OpenVMS Registry:
$ SHOW LOGICAL REG$OUTPUT "REG$OUTPUT" = "3" (LNM$SYSTEM_TABLE) |
$ DEFINE/SYSTEM REG$OUTPUT "7" |
The equivalence name is a string; the value within the string is a decimal value. The quotes are required. |
$ MCR REG$CP LIST VALUE HKEY_LOCAL_MACHINE\SYSTEM\REGISTRY |
Value name: Scan Interval
Volatile: REG$K_NONE
Data: 00000078
|
To restart the OpenVMS Registry, use the procedure described in
Section 8.3.3.
8.5 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 OpenVMS Registry server process that is active in
the cluster remains active until either the process no longer exists or
the priority among OpenVMS Registry server processes changes.
8.5.1 Changing the Priority of OpenVMS Registry Server Processes
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 8-3 shows priority values being assigned so that NODENAME1 will be the active OpenVMS Registry server process in the cluster.
| Example 8-3 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 8-3, if NODENAME1 shuts down, control of the OpenVMS Registry database passes to the server process on NODENAME2.
Example 8-4 shows the system manager increasing the priority value of NODENAME3 to 20.
| Example 8-4 Changing Priority Values |
|---|
$ mcr reg$cp REG> MODIFY VALUE HKEY_LOCAL_MACHINE\SYSTEM\REGISTRY\PRIORITY - _REG> /NAME=NODENAME3/DATA=20/TYPE=DWORD |
In Example 8-4, the OpenVMS Registry server process on
NODENAME1 goes into standby mode and the OpenVMS Registry server
process on NODENAME3 becomes active.
8.6 Connecting to the OpenVMS Registry from a Windows NT System
To connect to the OpenVMS Registry from a Windows NT system, you must do the following:
When you access the OpenVMS Registry database from a Windows system, you will have all the privileges granted on your Windows NT system. For example, if you are logged on 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. Access to OpenVMS Registry keys is based on your Windows NT user profile (username and Group membership).
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.
| Previous | Next | Contents | Index |
|
Copyright © Compaq Computer Corporation 1999. All rights reserved. |
6539P002.HTM
|