Digital DCE for OpenVMS VAX and OpenVMS Alpha
Product Guide

Previous Contents Index

1.10.6 DCL Interfaces to DCE Tools

DCE is multiplatform software designed to be used and managed on many different operating systems. For that reason, Compaq has worked to keep as much of the standard OSF DCE interface available as possible within the OpenVMS environment. For example, you can define foreign commands to execute DCE tools and utilities as you do on a UNIX system.

Note that the OpenVMS operating system does not differentiate between commands using lowercase and uppercase characters, but operating systems based on UNIX are case-sensitive. Many of the standard DCE commands differentiate between lowercase and uppercase characters. Many literal strings that appear in text, examples, syntax descriptions, and function descriptions must be typed exactly as shown.

To assist users more accustomed to OpenVMS syntax and conventions, Compaq also provides DCL interfaces for the following DCE tools:

Note that you can use these interfaces only on OpenVMS DCE systems; OSF DCE documentation includes no DCL interface information. For information about the available DCL interfaces, refer to the chapter on DCL command interfaces to DCE tools in the Digital DCE for OpenVMS VAX and OpenVMS Alpha Reference Guide. Some of these interfaces can be enabled during installation and configuration.

1.10.7 Integrated Login

Compaq provides Integrated Login, which combines the DCE and OpenVMS login procedures. See Chapter 8 for more information.

1.10.8 Object-Oriented RPC

IDL has been extended to support a number of C++ language syntax features that provide a distributed object framework. The DCE RPC runtime environment now supports C++ bindings to remote objects. The combination of these new features creates an Object-Oriented RPC. (See Chapter 12 for more information.)

Chapter 2
DCE System Configuration

Digital DCE for OpenVMS VAX and OpenVMS Alpha includes a system configuration utility, SYS$MANAGER:DCE$SETUP.COM, that is used after the kit installation to configure and start the DCE services. The Digital DCE for OpenVMS VAX and OpenVMS Alpha Installation and Configuration Guide provides important information about setting up your initial DCE environment. This chapter provides general information about the DCE configuration utility options and provides details about the clobber option.

Compaq recommends that you use only DCE$SETUP.COM, the DCE system configuration utility, to reconfigure and restart the Digital DCE services. This utility ensures that the proper configuration and sequencing of DCE operations occur. For example, instead of starting the RPC daemon rpcd directly, use DCE$SETUP.COM to start and stop daemons.

The DCE system configuration utility invokes a number of other utilities while it is configuring and starting the DCE services and creates a log file called SYS$MANAGER:DCE$SETUP.LOG. This error log file can be helpful in diagnosing problems that may occur during the product installation or subsequent reconfiguration. Old log files are purged, leaving only one version following use of the utility.


In a VMScluster environment, you must configure each VMScluster node separately. Although a DCE kit can be installed clusterwide, DCE services need specific DECnet node names and endpoints for each host. You must configure each VMScluster node that will be part of a DCE cell. Configure the VMScluster nodes exactly as single nodes are configured.

2.1 Starting and Stopping the RPC Daemon

DCE V1.5 contains the following enhancements to the DCE system management command procedure DCE$SETUP.COM:

The RPC daemon can be started or stopped with the two new command files DCE$RPC_STARTUP.COM and DCE$RPC_SHUTDOWN.COM, which are located in SYS$COMMON:[SYSMGR].

To start the Remote Procedure Call daemon, complete the following:

  2. Specify [NO]CONFIRM to turn user prompting on or off. CONFIRM is the default.

To stop the Remote Procedure Call Daemon, complete the following:

  2. Specify the following options in any order:


The RPC daemon must not be stopped if any DCE components or RPC applications are running on the system.

2.2 Limiting RPC Transports

The RPC daemon can limit which protocols will be used by RPC applications. To restrict the protocols that can be used, set a logical name RPC_SUPPORTED_PROTSEQS that contains the valid protocols seperated by a colon. Valid protocols are ncadg_ip_udp, ncacn_ip_tcp, ncacn_dnet_nsp.

To prevent RPC applications from registering endpoints that use TCP/UDP, use the following comand:

   $ Define RPC_SUPPORTED_PROTSEQS "ncacn_ip_tcp:ncacn_dnet_nsp" 

2.3 Using the DCE System Configuration Utility

To access the DCE system configuration utility menu, log in to the SYSTEM account and enter the following command:


The system configuration utility displays the following menu:

1)  Config      Configure DCE services on this system 
2)  Show        Show DCE configuration and active daemons 
3)  Stop        Terminate all active DCE daemons 
4)  Start       Start all DCE daemons 
5)  Restart     Terminate and restart all DCE daemons 
6)  Clean       Terminate all active DCE daemons and remove 
                all temporary local DCE databases 
7)  Clobber     Terminate all active DCE daemons and remove 
                all permanent local DCE databases 
8)  Test        Run Configuration Verification Program 
0)  Exit        Exit this procedure 
?)  Help        Display helpful information     
Please enter your selection number: 

To enter a system configuration menu command directly from the command line, type the following command:

$ @DCE$SETUP.COM command

where command is one of the system configuration commands described in Table 2-1.

Table 2-1 System Configuration Commands
Command Description
config The config command modifies the DCE configuration. To use this utility you must be logged in to either the SYSTEM account or an account with the same privileges as the SYSTEM account. The utility displays the current system configuration and then prompts for changes to the configuration. The default answers to the prompts depend on the existing configuration. To choose the default answer, press Return. You can also type a question mark (?) in response to any of the prompts to have help text displayed. A third choice is to enter new input at the prompt.

After you select all the services, the utility displays the new configuration and asks whether the permanent configuration database should be updated. The utility optionally starts all of the daemons for the configured services and runs the Configuration Verification Program (CVP).

show The show command displays the current DCE system configuration in read-only mode. You need WORLD privileges to execute this command. The Digital DCE for OpenVMS VAX and OpenVMS Alpha Installation and Configuration Guide also provides information on this command.
stop The stop command terminates all active DCE daemons. You must have the SYSPRV privilege to use this command.
start The start command starts all DCE daemons based on the current DCE system configuration. You must have the SYSPRV privilege to use this command.
restart The restart command terminates all active DCE daemons and restarts the daemons based on the current DCE system configuration. You must have the SYSPRV privilege to use this command.
clean The clean command terminates all active DCE daemons except for rpcd. It deletes temporary local databases associated with DCE services on this system while leaving rpcd running which allows RPC applications to continue. You must have the SYSPRV privilege to execute this command. After you execute this command, you must restart the DCE services and applications. To restart the daemons after executing the clean command, use DCE$SETUP start.
clobber The clobber command terminates all active DCE daemons except for rpcd. It deletes temporary and permanent local databases associated with DCE services on this system, including the DCE system configuration files and any portion of the RPC name service database for the cell that is maintained on this system. The clobber command leaves rpcd running which allow RPL applications to continue. You must have the SYSPRV privilege to execute this command.

After you execute this command, you must reconfigure the services on this system because clobber returns the system to the state it was in during the kit installation before the initial DCE system configuration was performed. To reconfigure the services and restart the daemons after executing the clobber command, use DCE$SETUP config.

test The test command begins the Configuration Verification Program.
exit The exit command allows you to exit from the DCE System Configuration menu without executing an option.

Implications of Using the clobber Command


The clobber command destroys a DCE cell. If you use it, you must reconfigure major portions of the cell. Using this command causes the following events:
  • All temporary and permanent DCE databases and files are deleted, including:
    • Configuration databases:
      DCE$LOCAL:[000000]DCE_CF.DB (permanent data base)
      DCE$LOCAL:[000000]DCE_SERVICES.DB (permanent database)
      Loss of these databases means you must reconfigure the host by entering @SYS$MANAGER:DCE$SETUP CONFIG.
  • If the host on which the clobber command has been executed is the name service server for the cell, the namespace and all files are deleted.
    All name service entries and directories must be re-created. To re-create the DCE entries and directories by reconfiguring DCE on this host, you can enter the command @SYS$MANAGER:DCE$SETUP CONFIG. Users can create all user namespace entries and directories. You must restart the daemons either by responding YES at the configuration procedure's prompt, or by entering the command @SYS$MANAGER:DCE$SETUP START at a later time.

2.4 Kerberos

The DCE security server makes UDP port 88 (service name "kerberos5") available for use by native Kerberos clients for authentication.


Kerberos realm names must match the cell name of the DCE security server.

Support for native kerberos5 clients has undergone minimal testing. Full support will be provided in a future version of Digital DCE for OpenVMS VAX and OpenVMS Alpha.

Chapter 3
Interoperability and Compatibility

This chapter describes interoperability and compatibility issues for Digital DCE for OpenVMS VAX and OpenVMS Alpha. Information is provided on the following topics:

3.1 Application Development in the OpenVMS POSIX Environment

If you are building and executing DCE applications on OpenVMS VAX in the OpenVMS POSIX environment, make sure you have installed the OpenVMS POSIX Version 1.2 or higher Mandatory Update (MUP). (If you are using an OpenVMS Alpha system, you should already have the correct version.)

3.1.1 Symbolic Links

The DCE system configuration utility (DCE$SETUP.COM) defines the following symbolic links:

3.1.2 C Compiler Usage

The OpenVMS DCE POSIX example program makefiles can provide a template for application makefile development. VAX C and DEC C environmental differences are automatically taken into account. Option file selection for program linking with OpenVMS DCE shared libraries is also taken into account.

SYS$COMMON:[SYSHLP.EXAMPLES.DCE...] and /usr/dce/examples/* are the locations of the example makefiles.

3.1.3 OpenVMS DCE Login Credentials

DCE_LOGIN is an executable that performs a DCE login in the OpenVMS POSIX environment. The DCE_LOGIN executable is located in SYS$COMMON:[SYSHLP.EXAMPLES.DCE.EXAMPLES.POSIX] or /usr/dce/bin. (/usr/dce/bin is added to each user's PATH environment variable during DCE setup.) Once DCE_LOGIN executes, the DCE credentials cache handle logical, KRB5CCNAME, is defined (LNM$JOB) in the child shell created. Any POSIX compiled and linked (c89) executable child process has scope to this logical (psx> show_log KRB5CCNAME). If you invoked, compiled, and linked OpenVMS executables through psx> dcl x.exe, they run in a detached child process as a distinct job and do not scope the DCE credentials cache handle logical.

3.1.4 Executing OpenVMS DCE Utility Programs in the POSIX Environment

Before DCE_LOGIN executes, the user default DCE credentials are those of the client node. The POSIX executable versions of the Ktool utilities (kinit, klist, and kdestroy) are in SYS$COMMON: [SYSHLP.EXAMPLES.DCE.EXAMPLES.POSIX] or in /usr/dce/bin. (/usr/dce/bin is added to each user's PATH environment variable during DCE setup.) RGY_EDIT, a Digital DCE utility program, remains an OpenVMS executable in this release of Digital DCE.

To perform operations beyond those permitted by default credentials, execute the login function within RGY_EDIT. RGY_EDIT (as found in Digital DCE) can be executed by exporting a POSIX alias for the OpenVMS executables. An example follows. Note that the aliases are available to each POSIX user as part of DCE setup.

psx> alias -x rgy_edit="dcl mcr dce \\ $rgy_edit.exe" 
psx> rgy_edit 

Because RGY_EDIT on OpenVMS POSIX currently has limitations, it is recommended that you run this utility within the OpenVMS environment. (It is also recommended that you run RPC and CDS control programs from within the OpenVMS environment. While an alias for RPCCP is provided, it is not recommended.)

3.2 Interoperability with DECrpc

Digital DCE for OpenVMS VAX is a functional upgrade to DECrpc Version 1.0 and 1.1, which shipped with both VMS/ULTRIX Connection (UCX) Version 1.3 and DEC TCP/IP Services for OpenVMS Version 2.0. DECrpc was Digital's version of the NCS RPC Version 1.5 from Apollo Computer, Inc., a subsidiary of Hewlett-Packard Corporation.

If you have applications that were developed using these products, and you want to use them in this Digital DCE environment, consider which of the compatibility and interoperability options described in the following sections are suitable for your situation.

Compaq recommends that you convert DECrpc applications to make use of the DCE programming interfaces.

Note that this compatibility applies to Digital DCE for OpenVMS VAX only and not Digital DCE for OpenVMS Alpha.

If certain conditions are met, your existing DECrpc Version 1.0 or 1.1 clients and servers can interoperate with clients and servers developed using this release. In the following paragraphs, the terms DECrpc client and DECrpc server refer to application code that uses only DECrpc Version 1.0 or 1.1 application programming interface (API) routines. This code uses DECrpc API routines exclusively. Similarly, the terms DCE client and DCE server generally refer to application code that uses only Digital DCE for OpenVMS VAX API routines. However, by creating DCE client and DCE server code that uses both the DCE API routines and selected DECrpc API routines, you can maintain interoperability with corresponding DECrpc clients and DECrpc servers.

For example, you can create a new server or modify a DECrpc server to interoperate with both new DCE clients and existing DECrpc clients. You can continue to use DECrpc clients with a new DCE server only if you code the new DCE server by using DCE API routines and selected DECrpc API routines.

To interoperate with DCE clients and servers, DECrpc clients and servers must meet the following conditions:

Section 3.3.5 provides additional information about why you should modify applications to use both DECrpc and DCE API routines.

3.3 Compatibility with DECrpc

The following sections describe the various levels of compatibility to consider when migrating DECrpc applications to DCE.

3.3.1 Object Compatibility

The DCE RPC runtime library has a different application programming interface (API) than the DECrpc library. However, the DCE RPC runtime library includes a compatibility service that maps calls from the previous API to the DCE RPC API. Therefore, the object files for an application with stubs that were compiled with the DECrpc NIDL compiler, and that make calls to the DECrpc runtime library, can be linked and executed by using the Digital DCE runtime library (SYS$LIBRARY:DCE$LIB_SHR.EXE).

3.3.2 Interface Compatibility

The DCE RPC uses an Interface Definition Language (IDL) with a syntax that differs from that used by the DECrpc Network Interface Definition Language (NIDL). The IDL compiler cannot process NIDL interface definitions. However, Digital DCE for OpenVMS VAX provides a utility program (nidl_to_idl) that converts an NIDL interface definition to a compatible IDL interface definition that can then be used with DCE applications. Usually, you perform the NIDL-to-IDL conversion once when you upgrade an existing application to a DCE-compliant application.

Previous Next Contents Index