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:

• IDL compiler
• NIDL-to-IDL converter
• Universal unique identifier generator uuidgen utility

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

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.

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

• rpcd, the RPC daemon, can be started with the new startup command procedure, DCE$RPC_STARTUP.COM.
• DCE$SETUP calls DCE$RPC_STARTUP to start rpcd instead of starting it directly.
• DCE$RPC_STARTUP does UCX parameter checking instead of DCE$RPC_SETUP.
• DCE$SETUP no longer stops rpcd under any circumstances. rpcd can only be stopped by calling DCE$RPC_SHUTDOWN.
• DCE$RPC_SHUTDOWN checks to see if any DCE components are running before it stops the rpcd.
• DCE components can be started, stopped or configured without shutting down rpcd.
• Invoking DCE$SETUP with the CLEAN or CLOBBER option no longer deletes the RPC endpoint database (DCE$LOCAL:[VAR.RPC]RPCDEP.DAT). However, the endpoints for any DCE components will be removed. To delete the entire RPC endpoint database, you must invoke DCE$RPC_SHUTDOWN with the CLEAN option.
• Modifications to informational messages have been made to remind the user of the above changes.

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:

1. Run DCE$RPC_STARTUP.COM.
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:

1. Run DCE$RPC_SHUTDOWN.COM.
2. Specify the following options in any order:
   • [NO]CONFIRM to turn user prompting on or off. CONFIRM is the default.
   • CLEAN to delete all entries from the RPC endpoint database.

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:

$ @SYS$MANAGER:DCE$SETUP.COM

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 DCE security server makes UDP port 88 (service name "kerberos5") available for use by native Kerberos clients for authentication.

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

• DCE application development in the OpenVMS POSIX environment
• Use with DECrpc Version 1.0 or 1.1
• Interoperability with other DCE systems
• Use with Microsoft RPC
  Digital DCE for OpenVMS VAX and OpenVMS Alpha also interoperates with non-DCE systems that are running the Microsoft DCE-compatible RPC. This chapter briefly describes how to run the name service interface daemon (nsid), also known as the PC Nameserver Proxy Agent, which allows systems running the Microsoft RPC software to access a DCE name service.
• Use in VMScluster environments
  DCE and VMScluster environments are distributed computing systems. This chapter includes information to consider when using the two technologies together.

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:

• /usr/dce/examples, which points to the following directory: SYS$COMMON:[SYSHLP.EXAMPLES.DCE]
  This directory is the top-level directory for all OpenVMS DCE examples. Each subdirectory also includes makefiles for POSIX builds.
• /usr/dce/bin, which points to the following directory: SYS$COMMON:[SYSHLP.EXAMPLES.DCE.POSIX].
  This directory contains POSIX images for dce_login, kinit, klist, kdestroy, and acl_edit. These images may be called without specifying their full pathname. The path name is added to the user's PATH environment variable during POSIX shell activation.

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:

• Both client and server must have a compatible interface definition, as described in Section 3.3.2.
• Both client and server must run on hosts that support UDP/IP. Because DECrpc used only UDP/IP, all applications must communicate with DECrpc clients and servers over that network transport.
• If your original DECrpc application (client and server) used the Location Broker to register and look up server addressing information, new or modified clients or servers must continue to use the DECrpc Location Broker routines.
  The new or modified server or client should also use the DCE name service interface (NSI) and endpoint map API routines. For example, to modify a DECrpc server so that it can service both DECrpc clients and DCE clients, your new server must register its addressing information two ways, as follows:
• Using the DECrpc endpoint broker API routines, so DECrpc clients can continue to find the server.
• Using the Digital DCE NSI export and endpoint map register API routines, so DCE clients can find the server.

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.