Document revision date: 19 July 1999
[Compaq] [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]
[OpenVMS documentation]

OpenVMS Connectivity Developer Guide


Previous Contents Index

6.5 Required OpenVMS Registry Entries

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:

6.5.1.1 Component CLSIDs

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:

6.5.1.2 Proxy/Stub CLSIDs

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:

6.5.2 HKEY_CLASSES_ROOT\Interface

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:

6.6 Converting OpenVMS and Windows Error Codes to Text

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.


NTA$VMSGetMessage

The NTA$VMSGetMessage routine translates error codes into displayable text. The input error code must be one of the following:

Format

Return=NTA$VMSGetMessage (status, text, flag, [count])


Arguments

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:

  1. Check for a Windows HRESULT (high-order nibble = 0x8). If this check fails, go to the next step.
  2. Check for a Windows NT user defined status code (high-order nibble = 0xE). If this check fails, go to the next step.
  3. 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.
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.

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.


Condition Values Returned


Part 2
OpenVMS Registry

The following chapters describe the OpenVMS Registry database, its structure, and the $REGISTRY and $REGISTRYW system services that interface with the OpenVMS Registry.


Chapter 7
Overview of OpenVMS Registry

7.1 What is the Registry?

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:

7.2 OpenVMS Registry Concepts and Definitions

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 
       : 
       . 

7.2.1.1 Key and Value Volatility

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:

7.2.2 Class

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:

7.4 Reading and Writing to the OpenVMS Registry

You can read and write to the OpenVMS Registry in the following ways:

7.4.1 $REGISTRY System Services

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:

  1. Does the user have Windows NT credentials?
  2. Does the user have the OpenVMS SYSPRV privilege?
  3. Does the user have the REG$UPDATE, REG$LOOKUP, or REG$PERFORMANCE rights identifier?
  4. If the user has no Windows NT credentials, OpenVMS grants the OpenVMS user Windows NT Everyone group access. In this case, the OpenVMS user's access to OpenVMS Registry keys depends on what permissions the key owner defined for Everyone when the key owner created the key or subkey. Based on these permissions, the OpenVMS user will be able to do one of the following:

7.5.1.1 Granting OpenVMS Registry Access Rights Using the AUTHORIZE Utility

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.

Caution

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)
 

  1. This AUTHORIZE command grants the REG$LOOKUP identifier to user Smith, allowing Smith to view keys and data in the OpenVMS Registry database.
  2. This AUTHORIZE command grants the REG$UPDATE identifier to user Smith, allowing Smith to modify keys and data in the OpenVMS Registry database. The dynamic attribute allows Smith to remove or restore the REG$UPDATE identifier from the process rights list by using the SET RIGHT/ENABLE or the SET RIGHT/DISABLE command.
  3. This AUTHORIZE command removes the REG$UPDATE identifier from user Smith.
  4. This AUTHORIZE command grants the REG$PERFORMANCE identifier to the system manager account, allowing the system manager to enable and disable the monitoring of OpenVMS Registry performance data.

7.5.2 Windows NT Security Model

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

7.6.2 Defining the Database Log Cleaner Interval/Initial Log File Size Settings

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

7.6.3 Defining Default File Quota/File Quota Interval Settings

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

7.6.4 Defining the Scan Interval Setting

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

7.6.5 Defining the Log Registry Value Error Setting

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

7.6.6 Defining the Operator Communications Interval Setting

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

7.6.7 Defining the Process Time Limit Setting

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

7.6.8 Defining the Reply Log Cleaner Interval Setting

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

7.6.9 Defining Snapshot Interval/Snapshot Location/Snapshot Versions Settings

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

7.6.10 Defining the Write Retry Interval Setting

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


Chapter 8
OpenVMS Registry System Management

8.1 Installing the OpenVMS Registry

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:

Tip: Enter Q (Quit) at any time

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.

8.2.1 Configuring OpenVMS Registry Values

The system displays the following questions:

  1. The system prompts you to enter standalone or cluster information. The system displays the following message:


     Is this system now a node in a cluster or will this system 
     become part of a cluster? (Y/N/Q): 
    

  2. The system displays the current information about the REG$TO_BE_STARTED logical, then prompts you to change the value.


                 - 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]: 
    

    If you choose Y, the system prompts you for the new value.


     Enter the new value (TRUE/FALSE/NOVAL/Q): 
    

    Enter one of the following:
    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) : 
    

    Enter one of the following:
    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

    After you enter the new or updated value, the system confirms the change and displays the line you must add to your SYLOGICALS.COM file.


            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. 
    

  3. The system displays the current information about the SYS$REGISTRY logical, then prompts you to change the value.


                 - 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]: 
    

    If you choose Y, the system prompts you for the new value.


    Enter the new value for SYS$REGISTRY ("yourvalue"/NOVAL/Q): 
    

    Enter one of the following:
    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

  4. The system displays your updated value and prompts you to confirm the value.


     You have entered:  value 
     Is this correct? (Y/N/Q) [Y]: 
    

  5. The system prompts you to enter a logical table name in which to store the new or updated logical.


    In which logical name table do you want the logical defined? 
           (SYSTEM/SYSCLUSTER/CLUSTER/Q): 
    

    Enter one of the following:
    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

    After you enter the new or updated value, the system confirms the change and displays the line you must add to your SYLOGICALS.COM file.


            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. 
    

  6. The system displays information about the location of the OpenVMS Registry database.


                 - SYS$REGISTRY directory - 
     
      [directory status]
     
    

    If the directory does not exist, the system prompts you to create the directory.


            !!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]: 
    

    If you enter Y the system confirms the directory creation.


            The SYS$REGISTRY directory has now been created. 
     
    Press [Enter] to return to the menu. 
    

8.3 Starting the OpenVMS Registry

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

  [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]  
  privacy and legal statement  
6539PRO_003.HTML