Digital DCE for OpenVMS VAX and OpenVMS Alpha
Product Guide


Previous Contents Index


double d[10][20]; 
short e[2..4][3..6]; 

The statements map into the following VAX FORTRAN constructs:


REAL*8 D(0:9,0:19) 
INTEGER*2 E(2:4,3:6) 

  1. The size of the pointer depends on the platform. It is INTEGER*4 for OpenVMS systems and INTEGER*8 for DEC OSF/1 Alpha systems.

18.3.5 Operations

Operations can pass parameters and return function results. This section explains these topics.

18.3.5.1 Parameter Passing by Reference

The following rules explain the mapping between IDL parameters and VAX FORTRAN parameters.

18.3.5.2 Function Results

The only possible function result types in VAX FORTRAN are scalars and CHARACTER*n. The mappings from IDL to VAX FORTRAN never produce CHARACTER*n, where n is greater than 1.

IDL hyper integers are not scalars in terms of function results, but IDL pointers are treated as scalars because they are mapped to INTEGER*4.

For an operation that has a result type that is not allowed by VAX FORTRAN, the stubs treat the operation result as an extra [out] parameter added to the end of the parameter list.

If the type of an operation is not void, you must state the type of the function result in VAX FORTRAN.

18.3.6 Include Files

Usually, a VAX FORTRAN routine that is part of an RPC client or manager for the interface defined in filename.IDL must include the following files:

Program units PRINT_PAY.FOR and MANAGER.FOR (containing subroutine subprogram CALCULATE_PAY) in the example of a distributed payroll application do not include NBASE.FOR because the units contain none of the IDL data types in Table 18-2. Otherwise, the program units would include NBASE.FOR. Furthermore, these units could safely include NBASE.FOR even though it is unnecessary in the example.

18.3.7 The NBASE.FOR File

DCE:NBASE.FOR declares standard data types used in mapping IDL to VAX FORTRAN. The declarations include those listed in Table 18-4.

Table 18-4 Standard Declarations
IDL Data Type FORTRAN Declaration Comments
hyper STRUCTURE /IDL_HYPER_INT/  
  INTEGER*4 LOW  
  INTEGER*4 HIGH  
  END STRUCTURE  
unsigned hyper STRUCTURE /IDL_UHYPER_INT/  
  INTEGER*4 LOW  
  INTEGER*4 HIGH  
  END STRUCTURE  
handle_t STRUCTURE /HANDLE_T/
INTEGER*4 OPAQUE_HANDLE
END STRUCTURE
Size of pointer is platform specific: INTEGER*4 on OpenVMS systems INTEGER*8 on DEC OSF/1 Alpha systems
ISO_MULTI_LINGUAL STRUCTURE /ISO_MULTI_LINGUAL/  
  BYTE ROW  
  BYTE COLUMN  
  END STRUCTURE  
ISO_UCS STRUCTURE /ISO_UCS/  
  BYTE GROUP  
  BYTE PLANE  
  BYTE ROW  
  BYTE_COLUMN  
  END STRUCTURE  

18.3.8 IDL Attributes

This section describes IDL attributes that apply to RPC applications containing VAX FORTRAN modules.

18.3.8.1 The transmit_as Attribute

The presented type must be expressible in VAX FORTRAN. Because addresses are involved, the routines used for data conversion cannot be written in VAX FORTRAN.

18.3.8.2 The string Attribute

A VAX FORTRAN data item corresponding to an IDL string contains the number of characters specified for the IDL string. Because IDL strings are usually terminated with a null byte, the following transmission rules apply:

An IDL operation can have a conformant string parameter. Such a parameter is presented to VAX FORTRAN as type CHARACTER*(*). If the base type of the string consists of w bytes and the string consists of n characters, then the parameter size is n*w. The maximum parameter size supported is 65535.

A conformant string field of a structure will have type CHARACTER*w, where w is the number of bytes in the base type of the string.

In all other cases where a string is not the target of a pointer, the IDL file specifies the string. Such a string is presented to VAX FORTRAN as CHARACTER*s, where s is the product of the string length and the number of bytes in the base type of the string. Furthermore, s must be between 1 and 65535 inclusive.

18.3.8.3 The context_handle Attribute

A context handle rundown routine cannot be written in VAX FORTRAN because the routine must handle address information.

18.3.8.4 The Array Attributes on [ref] Pointer Parameters

A [ref] pointer parameter that has array attributes attached to it is presented to VAX FORTRAN as the equivalent array.

18.3.9 ACF Attributes

The following items can occur in an Attribute Configuration File (ACF). They require special consideration when you are using VAX FORTRAN.

18.3.9.1 The implicit_handle ACF Attribute

You must supply a COMMON block whose name is the name given in the implicit handle clause. This COMMON block must contain the binding handle as its only data item.

For example, suppose an ACF contains the following interface attribute:


[implicit_handle(handle_t i_h)] 

Then, any VAX FORTRAN routine that calls an operation which uses the implicit binding must include statements with the following form:


RECORD /HANDLE_T/ BINDING_HANDLE 
COMMON /I_H/      BINDING_HANDLE 

18.3.9.2 The represent_as ACF Attribute

The local type must be expressible in VAX FORTRAN. Because addresses are involved, you cannot write the data conversion routines in VAX FORTRAN.

A type name in a represent_as attribute that does not occur in the interface definition and is not an IDL base type is assumed to be a STRUCTURE type.

Suppose that the represent_as type is not an IDL base type or a type defined in your IDL source. Then, you must supply a .h file whose unextended name is given in an include statement in the ACF. (An unextended name is a filename without the file extension that follows the dot (.) in the name. For example, the unextended filename for file EXAMPLE.H is EXAMPLE.) This file must include a definition of the local type in C syntax. You will need a filename.FOR file containing a VAX FORTRAN definition of the local type. Compaq recommends that you assign this file the same unextended name.


Chapter 19
Troubleshooting

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

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


    $ @SYS$MANAGER:DCE$SETUP SHOW
    

    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:


    $ @SYS$MANAGER:DCE$SETUP CONFIGURE
    

  3. You should also use the DCL command:


    $ SHOW SYSTEM
    

    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:


    $ @SYS$STARTUP:UCX$SHUTDOWN
    $ @SYS$STARTUP:UCX$STARTUP
    

  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:


    $ @SYS$MANAGER:DCE$SETUP START
    

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


    $ @SYS$MANAGER:DCE$SETUP RESTART
    

  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
    $ @SYS$MANAGER:DCE$SETUP START
    

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


    [VAR.SECURITY]CREDS.DIR              [DCE$SERVER]   (RWE,RWE,RWED,RWED) 
    All other directories:               [DCE$SERVER]   (RWE,RWE,RE,RE) 
    [ETC.SECURITY]PE_SITE.;              [DCE$SERVER]   (RWED,RWED,RWED,RE) 
    [KRB5]V5SRVTAB.;                     [DCE$SERVER]   (RWD,RWD,,) 
    [VAR.ADM.DIRECTORY.CDS]CDS_CACHE.*   [DCE$SERVER]   (RWD,RWD,,) 
    [VAR.ADM.DIRECTORY.CDS]CLERK_MGMT_ACL.DAT 
    [DCE$SERVER]       (RWD,RWD,R,) 
    [VAR.ADM.TIME]MGT_ACL.DAT;1          [DCE$SERVER]   (RWD,RWD,R,) 
    [VAR.RPC]RPC*.*                      [SYSTEM]       (RWD,RWD,RWD,) 
    [VAR.SECURITY]SEC_CLIENTD.BINDING;1  [DCE$SERVER]   (RWD,RWD,R,R) 
    [VAR.SECURITY.CREDS]*.NC             [DCE$SERVER]   (RWED,RWED,RWED,) 
    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.

19.2 Time Problems During Configuration

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

19.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 
%SYSTEM-F-ABORT, abort 

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:


$ SHOW LOGICAL SYS$TIME*

You should see four logical names listed:

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


$ DEASSIGN /SYS /EXEC SYS$TIMEZONE_RULE
$ DELETE SYS$SYSTEM:DTSS$TIMEZONE_DIFFERENTIAL.DAT;*
$ DELETE SYS$STARTUP:DTSS$UTC_STARTUP.COM;*
$ @SYS$UPDATE:DTSS$INSTALL_TIMEZONE_RULE

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:


$ @SYS$STARTUP:DTSS$UTC_STARTUP

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

19.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 Digital 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- 
                                                              ABORT,abort 
 
****************************    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

19.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-1993 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-1993 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-1993 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.

19.3 Client/Server Problems

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

19.3.1 OpenVMS Client System

To check the OpenVMS client system:

  1. Run the CDS Control Program:


    $ RUN SYS$SYSTEM:DCE$CDSCP.EXE
    cdscp> SHOW CELL /.:
    

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


                  SHOW 
                  CELL   /.../dcecelldcesvr 
                    AT   1993-09-02-19:28:07 
        Namespace Uuid = 6BA397C1-A138-11CC-85D6-08002B30910E 
    Clearinghouse Uuid = 6AE01D40-A138-11CC-85D6-08002B30910E 
    Clearinghouse Name = /.../dcecelldcesvr/dcesvr_ch 
          Replica Type =   Master 
                 Tower = ncacn_ip_tcp:16.32.0.199[] 
                 Tower = ncadg_ip_udp:16.32.0.199[] 
     
    

    If you get a socket error, a problem with communications within the local client system exists. Verify that DEC TCP/IP Services for OpenVMS (UCX) is started on your system and ensure 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:


    $ UCX SHOW SERVICE
    

    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:


    $ TYPE DCE$SPECIFIC:[ETC.SECURITY]PE_SITE.;
    

    You will see text such as:


    /.../dcecelldcesvr 535ace40-a138-11cc-ba08-08002b30910e@ncadg_ip_udp:16.32[] 
    /.../dcecelldcesvr 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 19.3.2.


Previous Next Contents Index