![[Compaq]](../../images/compaq.gif)
![[Go to the documentation home page]](../../images/buttons/bn_site_home.gif)
![[How to order documentation]](../../images/buttons/bn_order_docs.gif)
![[Help on this site]](../../images/buttons/bn_site_help.gif)
![[How to contact us]](../../images/buttons/bn_comments.gif)
![[OpenVMS documentation]](../../images/ovmsdoc_sec_head.gif)
| Document revision date: 19 July 1999 | |
|
|
|
|
|
|
| Previous | Contents | Index |
The following sections list and describe the required OpenVMS Registry
entries.
6.5.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:
As you develop and test COM components, you will find that the OpenVMS and Windows NT systems return seemingly indecipherable error codes. To help you make these codes more understandable, Compaq has included the NTA$VMSGetMessage routine to translate error codes into displayable text.
To implement this routine, you must include the NTA_MESSAGE.H file in the DCOM$LIBRARY: directory and link with the DCOM$LIBRARY:NTA_GETMSG.OBJ object module.
The following section describes the NTA$VMSGetMessage routine.
The NTA$VMSGetMessage routine translates error codes into displayable text. The input error code must be one of the following:
- An OpenVMS error code
- A Windows HRESULT
- A Windows Win32 error code
- A Windows NT status code set as "user defined"
Return=NTA$VMSGetMessage (status, text, flag, [count])
Description This routine uses the OpenVMS SYS$GETMSG system service. The messages are stored in the SYS$MESSAGE:NTAWINMSG.EXE and SYS$MESSAGE:NTARPCMSG.EXE images.status
OpenVMS usage: error_code type: longword (unsigned) access: read only mechanism: by value
This status field must be one of the following:
Input Error Code Example OpenVMS error code 0x074AA6BA Windows HRESULT 0x80070031 Windows Win32 error code 0x00000031 Windows NT status code with the user-defined bit set 0xE74AA6BA If the security API returns a Windows NT status code, the format of the status field is an OpenVMS status code OR'd with the Windows NT status control bits set. For example:
Input Error Code Result OpenVMS error code 0x074AA6BA Windows NT status code 0xE74AA6BA text
OpenVMS usage: error_text type: character string access: write mechanism: by reference
This argument is a NULL terminated string that contains the returned text from the SYS$GETMSG system service. The maximum size returned (as defined by the SYS$GETMSG system service) is 256 bytes. To avoid overwriting memory, the caller must provide a buffer address of at least 257 bytes.flag
OpenVMS usage: flag type: longword (unsigned) access: read only mechanism: by value
Controls the translation of the error code. The following values are defined in NTA_MESSAGE.H:
NTAWIN$_UNKNOWN Unknown error code NTAWIN$_VMS OpenVMS error code NTAWIN$_NT Windows HRESULT error code NTAWIN$_WINDOWS Windows Win32 error code NTAWIN$_USER Windows NT status code If you provide the value NTAWIN$_UNKNOWN, the routine makes its best estimate as to the correct text. The routine parses the text as follows:
- Check for a Windows HRESULT (high-order nibble = 0x8). If this check fails, go to the next step.
- Check for a Windows NT user defined status code (high-order nibble = 0xE). If this check fails, go to the next step.
- Assume this is an OpenVMS error code.
The system cannot tell the difference between an OpenVMS error code and a Windows Win32 error code.count
OpenVMS usage: FAO count type: longword (unsigned) access: write mechanism: by reference
This argument is the optionally returned FAO argument count in the returned message. Currently all NTAWIN messages use ASCII substitution arguments (!AS) only. The caller must convert all numeric data to ASCII before performing the substitution with SYS$FAO.
To call this routine, you must include the NTA_MESSAGE.H file in the DCOM$LIBRARY: directory and link with the SYS$LIBRARY:DCOM$WIN32_SHR shareable image.
- Any status from the SYS$GETMSG system service.
For more information about the SYS$GETMSG system service, see the OpenVMS System Services Reference Manual.
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.
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 Windows NT credentials and allows access as follows:
You can use the OpenVMS Authorize utility (AUTHORIZE) to add the SYSPRV privilege and REG$UPDATE, REG$LOOKUP, and REG$PERFORMANCE identifiers to user processes.
Granting OpenVMS Registry rights overrides Windows NT security access checks. |
Because rights identifiers are specific to an application, you cannot use the AUTHORIZE command to create the rights identifiers. Use the REG$CP server management utility to create these rights on your system. Running the REG$CP server management utility creates these rights by default. You must run REG$CP from a privileged account. For more information about running REG$CP, see Chapter 9.
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 Windows 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-1 system installation.
Before you can use the OpenVMS Registry, you must configure the OpenVMS Registry server and populate the OpenVMS Registry database. For more information about configuring the OpenVMS Registry server, see Section 8.2. For more information about populating the OpenVMS Registry database, see Section 5.2.
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 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-1.
8.2 Configuring the OpenVMS Registry: the REG$CONFIG Configuration Utility
The OpenVMS Registry Configuration utility (REG$CONFIG) provides information about the OpenVMS Registry server status and the OpenVMS Registry database location, and allows you to change OpenVMS Registry logical names and paths.
Enter the following command to start the OpenVMS Registry Configuration utility:
$ @SYS$MANAGER:REG$CONFIG |
The system displays the following menu:
---------------------------------------------------------
OpenVMS Registry Configuration Utility
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 - Configure OpenVMS Registry logical names and directory paths
2 - Display OpenVMS Registry logical names and directory paths
3 - Check the state of the OpenVMS Registry server
4 - Start the OpenVMS Registry server on this node
H - Help about this utility
[E] - Exit
Please enter your choice :
---------------------------------------------------------
|
To select an option, enter the option number. The options are as follows:
The OpenVMS Registry server is started in the cluster. The OpenVMS Registry server is started on this node. The OpenVMS Registry server is not started. |
The OpenVMS Registry server has successfully started. |
You can enter Q at any prompt to return to the OpenVMS Registry Configuration utility menu. If you quit while you are configuring logical names, the system updates only those values for which you have received a confirmation message. |
The system displays the following questions:
Is this system now a node in a cluster or will this system become part of a cluster? (Y/N/Q): |
- REG$TO_BE_STARTED -
[current value of REG$TO_BE_STARTED]
NOTE: Setting this logical to TRUE starts the OpenVMS Registry
server automatically when the system boots. Setting this logical
to FALSE prevents the OpenVMS Registry server from starting
when the system boots and prevents other products from starting
the OpenVMS Registry server. If the OpenVMS Registry Server is not
started at boot time, but other products that require an OpenVMS
Registry server are able to start the OpenVMS Registry server, you
do not need to assign a value to this logical.
Do you want to change this value? (Y/N/Q) [Y]:
|
Enter the new value (TRUE/FALSE/NOVAL/Q): |
| Action | Value |
|---|---|
| Start the OpenVMS Registry server on reboot. Allow other products to start the server. | TRUE |
| Do not start the OpenVMS Registry server on reboot. Do not allow other products to start the server. | FALSE |
| Do not start the OpenVMS Registry server on reboot. Allow other products to start the server. (Deassigns the logical name.) | NOVAL |
| Quit this procedure and return to the OpenVMS Registry Configuration utility menu. | Q |
In which logical name table do you want the logical defined?
(SYSTEM/SYSCLUSTER/CLUSTER/Q) :
|
| Action | Value |
|---|---|
| Add the REG$TO_BE_STARTED logical to the LNM$SYSTEM logical name table. This table contains names that are shared by all processes in the system. | SYSTEM |
| Add the REG$TO_BE_STARTED logical to the LNM$SYSCLUSTER logical name table. This table contains names that are shared by all processes in an OpenVMS Cluster. | SYSCLUSTER |
| Add the REG$TO_BE_STARTED logical to the LNM$CLUSTER logical name table. This table is the parent table for all clusterwide logical name tables. | CLUSTER |
| Quit this procedure and return to the OpenVMS Registry Configuration utility menu. | Q |
The logical REG$TO_BE_STARTED has been temporarily defined.
Before you reboot the system you must edit your SYLOGICALS.COM
to include the line:
DEFINE/TABLE=table-name REG$TO_BE_STARTED value
Press [Enter] to continue.
|
- SYS$REGISTRY logical -
current value of SYS$REGISTRY
Note: When the OpenVMS Registry server is started, the system
creates an OpenVMS Registry database at this location.
If an OpenVMS Registry database already exists on your system,
you must redefine the SYS$REGISTRY logical to point to the
existing OpenVMS Registry database location.
Do you wish to change this value? (Y/N/Q) [Y]:
|
Enter the new value for SYS$REGISTRY ("yourvalue"/NOVAL/Q):
|
| Action | Value |
|---|---|
| Define a new or changed location for the OpenVMS Registry database. | A valid directory specification, such as DKA0:[SYS$REGISTRY]. |
| Deassign the logical name. | NOVAL |
| Quit this procedure and return to the OpenVMS Registry Configuration utility menu. | Q |
You have entered: value Is this correct? (Y/N/Q) [Y]: |
In which logical name table do you want the logical defined?
(SYSTEM/SYSCLUSTER/CLUSTER/Q):
|
| Action | Value |
|---|---|
| Add the SYS$REGISTRY logical to the LNM$SYSTEM logical name table. This table contains names that are shared by all processes in the system. | SYSTEM |
| Add the SYS$REGISTRY logical to the LNM$SYSCLUSTER logical name table. This table contains names that are shared by all processes in an OpenVMS Cluster. | SYSCLUSTER |
| Add the SYS$REGISTRY logical to the LNM$CLUSTER logical name table. This table is the parent table for all clusterwide logical name tables. | CLUSTER |
| Quit this procedure and return to the OpenVMS Registry Configuration utility menu. | Q |
The logical SYS$REGISTRY has been temporarily defined.
Before you reboot the system you must edit your SYLOGICALS.COM file
to include the line:
DEFINE/TABLE=table-name SYS$REGISTRY dir-spec
Press [Enter] to continue.
|
- SYS$REGISTRY directory -
[directory status]
|
!!Caution!! When the OpenVMS Registry server starts, the system
creates an OpenVMS Registry database at this location. If you
already have an OpenVMS Registry database on your system, you must
redefine the SYS$REGISTRY logical to point to that location.
Do you wish to create the directory? (Y/N/Q) [Y]:
|
The SYS$REGISTRY directory has now been created.
Press [Enter] to return to the menu.
|
You can control how the OpenVMS Registry will start as follows:
Use the OpenVMS Registry Configuration utility described in Section 8.2 to control how the OpenVMS Registry starts.
| Previous | Next | Contents | Index |
|
|
| privacy and legal statement | ||
| 6539PRO_003.HTML | ||