If the process has it’s UIC set to DCE$SERVER, and does not have the BYPASS privilege set, DCE command line utilities will fail with the following error:

error creating SMG virtual keyboard. %NONAME-E-NOMSG, Message number 00000002

The resolution to this problem is to either run under a UIC other than DCE$SERVER, or to set the BYPASS privilege on accounts set to the DCE$SERVER UIC.

This problem does not effect the running of the DCE deamons, only user processes.

14.28 Dumping the CDS Cache

The CDSCP and DCECP commands to examine the CDS cache will fail if CDSCP or DCECP is run under a Process UIC other than [DCE$SERVER].

$ cdscp dump clerk cache Cannot map -1 - check id and protection An error occurred calling a CDS API function. (dce / cds) $ dcecp -c cdscache dump Cannot map -1 - check id and protection Error: The cache dump failed in an indeterministic mode.

To work around this restriction, issue the following DCL command before you invoke CDSCP or DCECP:

$ SET UIC [DCE$SERVER]

Remember to reset your UIC to its original value after you use this command.

14.29 CDS Clerk Failing on UCX Shutdown

If you issue a SYS$STARTUP:TCPIP$SHUTDOWN command while running DCE, you may get a CDS Clerk failure and an Access Violation. You may then encounter problems restarting the CDS Clerk (and DCE itself) with the DCE$SETUP START command.

The primary problem is that UCX is being shut down while DCE is still active. Since DCE uses UCX, DCE should always be shut down first.

To recover from this problem, you need to shut down DCE first and then restart. Simply trying to restart without first shutting DCE down will not fix the underlying problem. Because temporary files may be left in an indeterminate state, you may also want to perform a DCE$SETUP CLEAN operation before restarting.

14.30 Global Directory Agent Configuration

The Global Directory Agent (GDA) is configured on the OpenVMS node that contains the CDS Master Replica name server. The DNS domain name (for example, zko.dec.com) and the Internet Address of an authoritative DNS Master Bind Server (for example, 16.32.2.11) are required during configuration if you are using DNS Bind style cellnames.

Before access to multiple CDS namespaces is possible, the following are required after the configuration:

1. The Master Bind Server identified during configuration becomes the repository for information the GDA requires to resolve the Internet addresses and binding information needed by CDS to access foreign cell name spaces. This applies to DNS Bind cellnames only. See the Intercell Naming chapter in the HP DCE for OpenVMS Alpha and OpenVMS I64 Product Guide for the binding information content, location, and access.
2. Authenticated access to foreign (intercell) cell name space requires performing the RGY_EDIT cell command. The information needed for the cell command requires coordination with the foreign cell administrator. For more information, see both the Administering a Multicell Environment chapter in the OSF DCE Administration Guide and the Intercell Naming chapter in the HP DCE for OpenVMS Alpha and OpenVMS I64 Product Guide.
3. Before doing the RGY_EDIT cell command, you must first delete the krbtkt account for the foreign cell if one already exists. Similarly, the administrator for the foreign cell must also delete the krbtkt account in the foreign cell’s registry for your cell. For example, if your cell is called first_cell and the foreign cell is called second_cell, then you must run RGY_EDIT on first_cell to delete the account called krbtkt/second_cell, and the administrator on second_cell must delete the registry account called krbtkt/first_cell.

After the cell command, both cell administrators should rerun DCE_LOGIN before attempting authenticated cross-cell requests.

If you are unsuccessful in configuring intercell communication, check for the following:

• TThe clocks on the systems that are attempting to communicate show times that differ by no more than five minutes. (Use DTS to change the system time once you are running DCE.)
• CDS has the information that should be contained in the CDS_ GDAPointers field in the cell’s root directory. If CDS does not have this information in the cell’s root directory, restart the GDA daemon process (DCE$GDAD) by entering the following commands:

  $ STOP/ID=xxxxxxxx $ @sys$manager:dce$setup start

  
  where xxxxxxxx is the PID of the DCE$GDAD process.

In DCE for OpenVMS Version 1.5, a change was made to disassociate RPC shutdown from DCE shutdown. This was done to allow RPC only applications to remain active while DCE changes were being made.

In DCE Version 1.5, DCE$SETUP stop/clean/clobber did not call the RPC shutdown procedure, and merely gave a warning that RPC would not be shut down. DCE 3.1 requires that dced (the new RPC endpoint mapper) be shut down during certain operations. Therefore, the behavior was changed in DCE Version 3.0, and the RPC shutdown procedure is now called from DCE$SETUP.COM. The same is applicable for HP DCE V3.2 as well. This requires the system manager to be aware of any RPC-only applications that may be active at the time of DCE configuration operations.

14.32 IDL Error When Installing DCE

If installing DCE over an existing implementation, you may see an IDL error if the DCE Application Developer’s Kit was previously installed, but is not being installed for the upgrade.

The installation is attempting to remove the DCL commands which are associated with the developer’s kit from DCLTABLES.EXE, and failing. This error can safely be ignored - answer NO to the question "Do you want to terminate?".

%PCSI-E-MODDELERR, error deleting module IDL_CLD from library %PCSI-E-OPFAILED, operation failed Terminating is strongly recommended. Do you want to terminate? [YES] n

14.33 Port Error During DCE Configuration

If the error shown below occurs during DCE configuration, your system has the TCP/IP NTP daemon configured. Since DCE also provides an NTP daemon, you must decide which one you intend to use.

If you choose to use the DCE NTP daemon, then you must disable the TCP/IP NTP daemon via your TCP/IP configuration program before you can enable the DCE one.

If you choose to use the TCP/IP NTP daemon, then you can ignore the following error, and answer "Y" to the question about whether you want to proceed.

*************************** ERROR ******************************** Port number 123 is in use by a service other than "ntp". Please check configuration! Service "ntp" must use port number 123. ****************************************************************** Press to continue . . . Do you want to proceed with this operation (YES/NO/?) [N]?

14.34 Problems With Sun Solaris DCE System as CDS Master

There are known problems with Sun Solaris Version 2.6 and Transarc DCE Version 2.1 as the CDS master if you are attempting to configure a split server configuration using HP DCE on OpenVMS, Tru64 UNIX or Windows NT. Solaris Version 2.4 and Transarc DCE Version 1.1 work correctly. Contact your DCE vendor for further information.

14.35 Compile Warning in Example Programs

The CXX example programs may produce the following warning on compilation:

IDL_ms.IDL_call_h = (volatile rpc_call_handle_t)IDL_call_h; ...............^ %CXX-W-CASTQUALTYP, type qualifier is meaningless on cast type at line number 117 in file USER$1:[DCE12.EXAMPLES.RPC.IDLCXX. ACCOUNT]ACCOUNT_SSTUB.CXX;1 This warning can be safely ignored.

14.36 "Missing" CXX Library

Some versions of CXX may not include the library SYS$LIBRARY:LIBCXXSTD.OLB. If this is the case, this line may be removed from the options file found in SYS$COMMON:[DCE$LIBRARY]DCE_CXX.OPT.

14.37 Unknown Ethernet Device on Host System

If your system is using a new type of Ethernet device, then it is possible that DCE might not know about the Ethernet device on the system. DCE uses the Ethernet device to obtain an Ethernet address which is used in the generation of UUIDs. If you see errors such as the following:

%UUIDGEN-F-RPC_MESSAGE, Received Error Status: "no IEEE 802 hardware address (dce / rpc)"

then your Ethernet device is not known by DCE.

You can define one additional Ethernet device in the table used by DCE by defining the logical name DCE$IEEE_802_DEVICE to the name of your Ethernet device as shown in the following example:

$ DEFINE/SYSTEM DCE$IEEE_802_DEVICE EWA0

This will allow DCE to operate using the Ethernet device named EWA0 (a device type of DE500).

14.38 Public Key Routines Not Supported on OpenVMS

DCE public key technology is not currently supported on OpenVMS. The pkc_* routines and classes ( pkc_add_trusted_key, etc.) are not in DCE$LIB_SHR.EXE, and will generate undefined symbols if an application that uses them attempts to link.

The Open Group has stated their intention to replace the existing public key technology in DCE with a non-interoperable replacement, based on X.509v3, in a future release.

"Note that there has been such a high volume of change activity in the IETF relative to Public Key Infrastructure (PKI) and Kerberos that the [RFC 68.3] functionality will not be forward compatible with this Specification. Therefore, current users of DCE 1.2.2-based products with [RFC 68.3] functionality should refrain from deploying the public key based login support."¹

For this reason, HP is not supplying the obsolete public key functionality in DCE from OpenVMS Version 3.0 onwards. For additional information on the status of public key in DCE, see the Open Group’s DCE website at:

http://www.opengroup.org/tech/dce/

14.39 Audit Trail Files Require UNIX-Style File Specifications

The command to show the DCE audit trail files requires a UNIX style file specification. For example:

$ dcecp -c audtrail show /dcelocal/var/audit/adm/central_trail

14.40 Installation Warnings

Some systems may see warnings during DCE installation, as shown below:

The following product will be installed to destination: DEC AXPVMS DCE V3.2 DISK$MOOSE2_SYS:[VMS$COMMON.] %PCSI-I-RETAIN, file [SYSUPD]DTSS$INSTALL_TIMEZONE_RULE.COM was not replaced because file from kit does not have higher generation number %PCSI-I-RETAIN, file [SYSUPD]DTSS$TIMEZONE_RULES.DAT was not replaced because file from kit does not have higher generation number

These warnings can be safely ignored. They indicate that certain files which may also be provided by OpenVMS are newer than the files in the DCE kit.

14.41 Registration failure of DCE$KERNEL image on I64

DCE startup on I64 reports the following error message.

The following product will be installed to destination: %RPI-F-UNSUPPORTED, Image registration is not supported in V8.2 on Integrity systems. You may safely ignore this message.

14.42 The utc_mulftime Factor Argument Type

The input argument, factor, for the DTSS API routine utc_mulftime must be a IEEE _FLOAT type on I64 and G_FLOAT type on Alpha. You can use either CVT$FTOF or CVT$CONVERT_FLOAT to convert the factor argument to appropriate floting point type before calling utc_mulftime.

14.43 NTLM RPC Support on I64

Authenticated RPC over NTLM (Microsoft NT LAN Manager Protocol) has not been tested in this release, as the infrastructure on which DCE RPC depends on is not available on I64.

14.44 DCE IDL C++ Application builds on I64

The C++ Compiler on I64 does not allow compilation of multiple sources separated by a comma list. The IDL C++ Application build procedures compiling multiple sources will need to be modified to build the source files individually.

15 New APIs for G_Float/IEEE_Float Support

HP DCE V3.2 for OpenVMS now supports both G_FLOAT and IEEE floating point types on I64 and Alpha platforms.

Use the floating point types consistently in a single RPC application. Different RPC applications, each using different floating point types, can be run on a single system.

On I64 Systems:

By default DCE uses IEEE_FLOAT type on I64 systems i.e. DCE applications built for I64 systems would use IEEE_FLOAT floating point types.

Use the following steps for using the G_FLOAT floating point type in RPC applications developed on the C and C++ language:

1. Call the new API function rpc_set_local_float_drep(RPC_APPLICATION_ FLOAT_TYPE, &status) before calling any RPC runtime functions. The constant RPC_APPLICATION_FLOAT_TYPE is automatically defined to the floating point type specified on the compiler command line qualifier.
2. Compile the RPC application programs using the compiler qualifier /FLOAT= G_FLOAT.
3. Use the appropriate IDL compile option while building the stubs for:
   • C applications: -CC_CMD "CC/FLOAT=G_FLOAT"
   • C++ application: -CPP_CMD "CXX/FLOAT=G_FLOAT"
4. Link the RPC applications using the appropriate DCE options file for:
   • C applications: DCE.OPT
   • C++ applications: DCE_CXX.OPT

To use IEEE_FLOAT floating point type in RPC applications developed on the C or C++ language:

• Compile the RPC application programs using the Compiler Qualifier /FLOAT=IEEE_FLOAT (default option).
• Link the RPC application with DCE.OPT or DCE_CXX.OPT.

On Alpha Systems:

By default DCE uses G_FLOAT type on Alpha systems i.e. DCE applications built on Alpha systems would use G_FLOAT floating point types.

The following are the details for using the IEEE_FLOAT floating point type in RPC applications developed on the C and C++ language:

1. Call the new API function rpc_set_local_float_drep(RPC_APPLICATION_ FLOAT_TYPE, &status) before calling RPC runtime functions. The constant RPC_APPLICATION_FLOAT_TYPE is automatically defined to the floating point type specified on the compiler command line qualifier.
2. Compile the RPC application programs using the compiler qualifier /FLOAT= IEEE_FLOAT.
3. Use the appropriate IDL compile option while building the stubs for:
   • C applications: -CC_CMD "CC/FLOAT=IEEE_FLOAT"
   • C++ applications: -CPP_CMD "CXX/FLOAT=IEEE_FLOAT"
4. Link the RPC applications using the appropriate DCE options file for:
   • C applications: DCE.OPT
   • C++ applications: DCE_CXX.OPT

To use G_FLOAT floating point type in RPC applications developed on the C or C++ language:

1. Compile the RPC application programs using the CC or C++ Compiler Qualifier /FLOAT=G_FLOAT (default option).
2. Link the RPC application with DCE.OPT or with DCE_CXX.OPT.

Please also refer the HP C++ Release Notes documentation for any known restrictions or problems with running C++ applications that have been compiled using non-native floating point type.

15.1 RPC_SET_LOCAL_FLOAT_DREP

NAME rpc_set_local_float_drep - Sets the float type in the runtime to the one with which the application is being compiled. SYNOPSIS #include void rpc_set_local_float_drep ( unsigned8 float_drep, unsigned32 *status); PARAMETERS INPUT unsigned8 - float_drep The parameter should always be passed as using the macro "RPC_APPLICATION_FLOAT_TYPE". This macro will be defined to 0 or 1 based on the compilation option specified for the float type. OUTPUT unsigned32 - *status The routine will always return "rpc_s_ok" status. DESCRIPTION: The routine rpc_set_local_float_drep allows the RPC application to set the floating point type being used by the application. Only G_FLOAT and IEEE_FLOAT floating types are supported. This routine if used, should be placed before any other API calls to the RPC runtime. The first parameter float_drep should be passed using the macro RPC_APPLICATION_FLOAT_TYPE that is defined in IDLBASE.H header file. This macro will be set to appropriate value based on the /FLOAT compilation option. This routine can be used only on Alpha and I64 and will not be supported on VAX. RETURN TYPE: No value is returned.

16 New APIs for Authenticated RPC

The following APIs are included in DCE Version 1.5 and above to manipulate the sec_winnt_auth_identity structure. They are supported on OpenVMS V7.2-1 onwards.

16.1 RPC_WINNT_SET_AUTH_IDENTITY

NAME rpc_winnt_set_auth_identity - This function is called by the client RPC application to allocate and populate a WINNT auth_identity structure to be used as a parameter to rpc_binding_set_auth_info(). The caller must use the rpc_winnt_free_auth_identity() function to free the WINNT auth_idenity. The strings that are passed in may be ASCII or Unicode (UCS-4) strings. The input flag will tell which type of strings they are. SYNOPSIS #include <dce/rpc.h> PUBLIC void rpc_winnt_set_auth_identity ( rpc_winnt_auth_string_p_t Username, rpc_winnt_auth_string_p_t Password, rpc_winnt_auth_string_p_t Domain, unsigned32 CharacterSetFlag, rpc_auth_identity_handle_t *auth_identity, unsigned32 *stp) PARAMETERS INPUT username - Pointer to a null terminated string containing username. password - Pointer to a null terminated string containing password. domain - Pointer to a null terminated string containing domain. CharacterSetFlag SEC_WINNT_AUTH_IDENTITY_UNICODE 4 byte Unicode (UCS-2) SEC_WINNT_AUTH_IDENTITY_ANSI ASCII (ISO8859-1) OUTPUT auth_identity - Pointer to a pointer to WINNT auth_identity structure. stp - Pointer to returned status.

NAME rpc_winnt_free_auth_identity - This function is called by the client RPC application to free a a WINNT auth_identity structure that was previously allocated by a call to rpc_winnt_set_auth_identity(). SYNOPSIS #include <dce/rpc.h> PUBLIC void rpc_winnt_free_auth_identity ( rpc_auth_identity_handle_t *auth_identity, unsigned32 *stp) PRAMETERS INPUT auth_identity - Pointer to a pointer to WINNT auth_identity structure. On output auth_identity will be set to NULL. OUTPUT stp Pointer to returned status.

17 New APIs for Impersonation in DCE

The following APIs are included in DCE Version 1.5 and above to support server impersonation of a client. This means that the server runs with the security credentials of the client, and all of the capabilities of the client belong to the server.

17.1 RPC_IMPERSONATE_CLIENT

NAME rpc_impersonate_client - This function is called by the server application to allow the current server thread to run with all of the client privileges. SYNOPSIS #include <dce/rpc.h> void rpc_impersonate_client( rpc_binding_handle_t binding_handle, unsigned32 *status) PARAMETERS INPUT binding_handle - Specifies a server-side call handle for this RPC which represents the client to impersonate. OUTPUT status - Specifies a pointer to an unsigned 32 bit integer that holds a status code.

17.2 RPC_REVERT_TO_SELF

NAME rpc_revert_to_self - This function is called by the server application to revert back to its original security context after impersonating a client. SYNOPSIS #include <dce/rpc.h> rpc_revert_to_self(st) PARAMETERS INPUT NONE OUTPUT st - Specifies a pointer to an unsigned 32 bit integer that holds a status code.

17.3 RPC_REVERT_TO_SELF_EX

NAME rpc_revert_to_self_ex - This function is called by the server application to revert back to its original security context after impersonating a client. This acts as a call to rpc_revert_to_self(); SYNOPSIS #include <dce/rpc.h> rpc_revert_to_self_ex( rpc_binding_handle_t binding_handle, unsigned32 *status) PARAMETERS INPUT call handle - This parameter is ignored. OUTPUT status - Specifies a pointer to an unsigned 32 bit integer that holds a status code.

17.4 Enhanced RPC Security APIs

For more information on existing enhanced RPC security APIs, see the HP DCE for OpenVMS Alpha and OpenVMS I64 Reference Guide.

18 The Routing File

To use routing file services on OpenVMS, you will need to define the following logical name for the process or the system for which logging information is desired:(Syntax is exact for the routing file).

$ DEFINE/SYS DCE_SVC_ROUTING_FILE "DCE_LOCAL/VAR/SVC/ROUTING."

This will enable DCE applications to find and interpret the routing file and direct any output to the location specified in the routing file.

You can also set the number of buffered writes to perform before data is flushed to the file, as shown below:

$ DEFINE/SYS DCE_SVC_FSYNC_FREQ 10

The example above will flush the buffer every 10 writes.

18.1 Specifying Filenames in the Routing File

The OpenVMS routing file uses UNIX style filenames when specifying output log files. You can see examples of this in the current routing file that is found in the directory dce$common:[var.svc]routing. The DCE code that reads the routing file uses colons and forward slashes to parse the routing file data lines for output files.

18.2 Using the Routing File

The routing file contains examples of how to set up logging for various components. See the routing file itself for additional information. The routing file can be found in DCE$COMMON:[VAR.SVC]ROUTING.