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

Compaq DCE for OpenVMS VAX and OpenVMS Alpha
Product Guide

Previous Contents Index

Chapter 14

This chapter provides help for tracking down problems you may have with Compaq DCE for OpenVMS VAX and OpenVMS Alpha.

14.1 General Troubleshooting Steps

If you are experiencing problems with DCE on your system, go through the following steps to help you isolate the problem:

  1. Use the DCE$SETUP SHOW option to examine the current state of the DCE services on your system:


    This command tells you how DCE is configured on your system, what daemons should be active, and what daemons are currently active.

  2. Make sure that your system has the correct DCE configuration. If not, you may need to repeat the CONFIGURE operation of DCE$SETUP:


  3. You should also use the DCL command:


    to ensure that the TCP/IP Internet ACP process (INET_ACP) is running. If it is not running, you may need to restart TCP/IP services on your system with the following commands:


  4. If the DCE$SETUP SHOW command indicates that a configured DCE daemon is not currently running on your system, check for component-specific output, error, and log files (*.OUT, *.ERR, *.LOG) in the following directories:
  5. It may be possible to start up missing DCE daemons with the START option:


  6. If DCE daemons will not start properly, try a RESTART operation. This STOPs all daemons and STARTs them again in an orderly fashion:


  7. If problems persist, try a CLEAN followed by a START operation. This will delete the temporary DCE databases and restart the daemons in an orderly fashion:

    $ @SYS$MANAGER:DCE$SETUP CLEAN !This will stop all daemons

  8. Ensure that all files and directories in the DCE$SPECIFIC: directory tree have the proper owner and protection:

    All other directories:               [DCE$SERVER]   (RWE,RWE,RE,RE) 
    [KRB5]V5SRVTAB.;                     [DCE$SERVER]   (RWD,RWD,,) 
    [DCE$SERVER]       (RWD,RWD,R,) 
    [VAR.RPC]RPC*.*                      [SYSTEM]       (RWD,RWD,RWD,) 
    All other [VAR.SECURITY.CREDS] files [DCE$SERVER]   (RWD,RWD,,) 

  9. Ensure that all files and directories in the DCE$COMMON: directory tree have the proper protection:

     All [ETC] files and directories             (RWED,RWED,RWED,RE) 
     All [ETC.DIRECTORY] files and directories   (RWED,RWED,RWED,RE) 
     All [ETC.SECURITY] files and directories    (RWED,RWED,RWED,RE) 

  10. If DCE on the security registry server system for your cell is reconfigured, you must reconfigure all OpenVMS client systems in the cell.

14.2 Time Problems During Configuration

This section discusses problems with time and time zones that you may encounter during configuration or startup.

14.2.1 Time Zone Configuration

During DCE configuration or startup, you may encounter the following message:

Error: UTC services and run-time library don't agree on the local time 

This message indicates that your current time zone configuration is invalid. Verify the definition of the logical names used by UTC services by entering the DCL command:


You should see five logical names listed:

If these logicals appear to be incorrect, reconfigure your time zone information as follows:


The procedure DTSS$INSTALL_TIMEZONE_RULE.COM asks you several questions regarding your local time zone and then creates a new UTC startup procedure, DTSS$UTC_STARTUP.COM. Execute the new UTC startup:


This process clears up the system time conflicts and you should be able to continue with your DCE configuration or startup operation.

14.2.2 Time Synchronization Problems

If your system clock is not synchronized with the system clock on the security server, you may receive an error during the Compaq DCE configuration. An error can occur even if the clocks are skewed by as little as five minutes.

Following is an example of an error that can occur because of a time synchronization problem between your system clock and the security server system clock:

    Please enter the principal name to be used [cell_admin]: 
    Please enter the password for principal "cell_admin": 
Establishing security environment for principal "cell_admin" . . . 
Error: Cannot bind to the registry 
Registry server unavailable (dce / sec) 249791450 (0x052000000)%SYSTEM-F- 
****************************    ERROR    **************************** 
***  An error occurred while setting up the security environment 
***  using principal name "cell_admin" 
Do you want to restart the client configuration (YES/NO/?) [Y]? n 

A workaround is to set the time on your system to match the time on the node running the security server. On OpenVMS systems, use the following command:

$ SET TIME=dd-mmm-yyyy:hh:mm:ss

14.2.3 Time OPCOM Messages

Occasionally, OPCOM messages may appear on your screen. (These messages also are logged in SYS$MANAGER:OPERATOR.LOG.) You can safely ignore these messages as long as you have the DTS servers you need. (If you do not have the DTS servers you need, investigate the status of the DTS servers.)

Following are three messages you may see.

%%%%%%%%%%%  OPCOM  27-SEP-1999 10:30:09.50  %%%%%%%%%%% 
Message from user SYSTEM on OPNDCE 
dtsd.dce:  DCE error: Failure in rpc_mgmt_inq_server_princ_name: 
/.../dceopnfst/hosts/opnvms/dts-entity communications 
            failure (dce / rpc) 
%%%%%%%%%%%  OPCOM  27-SEP-1999 10:30:09.65  %%%%%%%%%%% 
Message from user SYSTEM on OPNDCE 
dtsd.dce:  DCE error: Failure in rpc_mgmt_inq_server_princ_name: 
/.../dceopnfst/hosts/opnvms/dts-entity not registered in 
            endpoint map (dce / rpc) 
%%%%%%%%%%%  OPCOM  27-SEP-1999 13:46:04.70  %%%%%%%%%%% 
Message from user SYSTEM on OPNDCE 
dtsd.dce:  DCE error: Error requesting time 
            from server : communications failure (dce / rpc) 

These messages indicate either the time daemon is not active because the system is down, you choose to have the time daemon stop running on a node, or the DTS daemon needs to be restarted because of an unexpected error.

14.3 Client/Server Problems

Successful DCE operation requires components on both the OpenVMS client system and your server system (for example, Compaq Tru64 UNIX Alpha) to work together. There are several things you can check on your client and on your server if DCE is not operating correctly.

14.3.1 OpenVMS Client System

To check the OpenVMS client system:

  1. Run the CDS Control Program:

    dcecp> CELL SHOW /.:

    If DCE is working correctly, this will obtain cell information from the server and display it for you:


    If you get a socket error, a problem with communications within the local client system exists. Verify that Compaq TCP/IP Services for OpenVMS (UCX) is started on your system and ensure that it is configured for proper DCE operation, as described in the release notes.

  2. Verify that the server system is reachable from your client system:

    $ UCX PING server_node

    If you get the following error:

     %UCX-E-GETHST, Error in getting host name 
     %RMS-E-RNF, record not found 

    then the server system host name is not defined in the UCX hosts database. You can define it in the database with the command:

    $ UCX SET HOST* hostname /ADDRESS=nn.nn.nn.nn

    Note that it is not required that your server hostname be defined in the local UCX hosts database for proper DCE operation. If your server host is not defined in the UCX hosts database, however, you will be asked to provide the Internet address of the server host during the DCE configuration process.
    If the UCX PING command returns the message:

     %UCX-I-LOOPACT, <SERVER_NODE>  is alive 

    then basic communication with your server node is working.

  3. Next, ensure that the CDS library service is defined in the UCX services database:


    You should see a service definition for the service cdsLib in the listing, indicating the port number to be used for CDS client and clerk communication. Note that the service state should be Disabled . See the release notes for more information about the cdsLib service.

  4. Examine the security PE_SITE file used to locate the security registry for the cell:


    You will see text such as:

    /.../opndce-cell 535ace40-a138-11cc-ba08-08002b30910e@ncadg_ip_udp:16.32[] 
    /.../opndce-cell 535ace40-a138-11cc-ba08-08002b30910e@ncacn_ip_tcp:16.32[] 

    Compare this information with the output from the rpccp show mapping command on the server, as described in Section 14.3.2.

14.3.2 Server System

Note that the following examples assume a Compaq Tru64 UNIX DCE server system.

  1. Use the DCESETUP SHOW option to ensure that the server daemons are active:

    # /etc/dcesetup show 
    The following DCE daemons are active on this system: 
      RPC daemon                    (rpcd)         pid: 756 
      Security Server daemon        (secd)         pid: 762 
      Security Client daemon        (sec_clientd)  pid: 768 
      CDS Advertiser daemon         (cdsadv)       pid: 774 

  2. Ensure that CDS is functioning properly:

    # cdscp show dir /.: 

    If this command fails or hangs, you may need to restart DCE on your server:

    # /etc/dcesetup restart 

    If the cdscp command still fails, try a CLEAN operation followed by a START operation on the server:

    # /etc/dcesetup clean 
    # /etc/dcesetup start 

  3. Ensure that the security registry is known to RPC:

    # rpccp show mapping 

    You should see an object listed such as:

    <OBJECT>          2eef26c0-668f-11cc-8640-08002b35b39a 
    <INTERFACE ID>    4c8782805000.0d.,1.0 
    <STRING BINDING>  ncacn_ip_tcp:[1322] 
    <ANNOTATION>      DCE user registry 

    Verify that the object UUID and the string binding protocol name and Internet address match the definitions in the PE_SITE file located on the OpenVMS DCE client system as described in Section 14.3.1. If they do not match, you must reconfigure the OpenVMS DCE client system.

14.4 Configuration and CDS

When DCE$SETUP starts, it may occasionally fail to contact the CDS master server. This may happen for one of the following reasons:

14.5 Configuration and Naming

When configuring a cell, you may receive an error similar to the following from rpc_binding_set_auth_info() :

 336760839 (decimal), 14129007 (hex): 
 Server not found in Kerberos database (dce / krb) 

To solve this problem, be sure that you do not configure a cell with the same name as another cell on the same network.

If you run system and functional tests that configure cells, make sure that the tests generate a unique name each time the test is run. You can also use the hostname of the server machine as part of the cell name.

14.6 Modifications to Compaq TCP/IP Services (UCX)

Compaq DCE for OpenVMS VAX and OpenVMS Alpha requires modification of several UCX parameters for proper operation. Make sure you read the current Compaq DCE for OpenVMS release notes for the most recent recommendations.

14.7 Principal Quota Exhausted

If you try to use DCE$RGY_EDIT to add a principal name, you may receive the following error message:

?(rgy_edit) Unable to add principal  "Xyzzy" - Principal quota 
  exhausted (dce / sec) 

The message means that your process does not have sufficient DCE credentials to complete the task. Therefore, you must login as cell_admin or another privileged DCE account before retrying the command.

14.8 Linking RPC Stub Modules into Shareable Images

If you build shareable images that contain RPC generated stub modules, you should use a linker options file. PSECT statements in the linker options file are used to resolve differences in the PSECT attributes between the RPC generated object file and the new shareable image. The following sections discuss how to solve problems that can arise when you create, link against, or activate a shareable image that contains RPC generated stub modules. This section can be summarized as follows:

The PSECT attributes of the RPC generated interface specifications (IFspecs) should be set to the following:


RPC interface specifications usually do not change, so it is rarely required that they be set to a writable PSECT attribute. RPC interface specifications are frequently shared. If your shareable image contains more than one cluster and the same interface specification is defined in multiple object modules, these interface specifications can be effectively collected into the same global cluster with the GBL PSECT attribute. Note that, in this case, the first module encountered by the linker that defines the IFspec will be used to initialize the value of the IFspec in the shareable image. A map file can help you identify and correct problems with PSECTs and their contents. The contents of any PSECT should be nonzero.

If you find a zero byte PSECT, you may need to explicitly specify the module name in the options file. The module name can be specified directly on its own or as part of the /library/include=() statement associated with an object library. PSECTs should not be zero unless they are initialized at runtime, and this presumes that the PSECT is writable (WRT).

14.8.1 Errors Creating a Shareable Image

The following examples show some of the errors that might occur when you try to create a shareable image with RPC stub object modules:

$ link/share/exe=myshr.exe/ -
$-        test1_mgr,test1_sstub,dce:dce.opt/opt
$ %LINK-I-BASDUERRS, basing image due to errors in relocatable 
$ %LINK-W-ADRWRTDAT, address data in shareable writeable section
$ in psect TEST1_V0_0_S_IFSPEC offset %X00000000

The PSECT name is causing the linker problem. To correct this problem, create an option file including the following line, and place it on your link command line as follows:

$ create myopt.opt
$ PSECT= TEST1_V0_0_S_IFSPEC, shr,nowrt,gbl
$ ctrl-z
$ link/share/exe=myshr.exe/ -
$-        test1_mgr,test1_sstub,dce:dce.opt/opt,myopt.opt/opt

This will remove the link problems so that you can create a shareable image. There are still errors in this shareable image whose solutions are shown in the following examples.

14.8.2 Errors Linking Against a Shareable Image

Once you have a shareable image, you may still see linker problems related to the PSECT attributes between the shareable image and new object files. In the following example, a main routine is linked against the same shareable image from the previous example. The new object module references some of the same variables defined by the RPC stub module.

$ link/exec=test1d/ test1_main,sys$input/opt
$ myshr.exe/share
$ ctrl-z
$ %LINK-W-MULPSC, conflicting attributes for psect TEST1_V0_0_S_IFSPEC
$       in module TEST1_MAIN file USER:[MY.CODE.DCE]TEST1_MAIN.OBJ;

If you search the map files of both and for the PSECT TEST1_V0_0_S_IFSPEC, you will see that the PSECT attributes for this PSECT match; however, the map files are incorrect. The solution to this link problem is to include the PSECT directive in a linker options file for the offending PSECT name. The previous example simply typed in the options from the command line, but you should place these linker statements in a linker option file. The options are typed in from SYS$INPUT in the following example:

$ link/exec=test1d/ test1_main,sys$input/opt
$ PSECT= TEST1_V0_0_S_IFSPEC, shr,nowrt,gbl
$ myshr.exe/share
$ ctrl-z

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