Document revision date: 28 June 1999

COMPAQ PROPRIETARY INFORMATION

RELEASE NOTES

Digital DCE for OpenVMS VAX and OpenVMS Alpha

Version 1.5

Version 1.5 of Digital DCE for OpenVMS VAX and OpenVMS Alpha replaces Digital DCE for OpenVMS VAX and OpenVMS Alpha Version 1.4. Version 1.5 is a complete kit that does not require a previous version of Digital DCE for OpenVMS for installation. Version 1.5 can be installed in a new system or can be installed as an update to a previous version of DCE for OpenVMS.

Information on Microsoft's NT Lan Manager (NTLM) is provided as a preview of functionality that will be available in a future version of Digital DCE for OpenVMS Alpha only. This advanced documentation will help you in future planning.

1 Services Digital DCE Offers

Version 1.5 of Digital DCE for OpenVMS VAX and OpenVMS Alpha consists of the following services:

• Remote Procedure Call (RPC) service provides connections between individual procedures in an application across heterogeneous systems in a transparent way.
• Interface Definition Language (IDL) compiler (required for developing distributed DCE applications).
• Threads service provides user-mode control and synchronization of multiple operations. Threads is packaged with the base operating system.
• Cell Directory Services (CDS) provides a location-independent method of identifying resources within a cell. A cell is the smallest group of DCE systems that share a common naming and security domain.
• Distributed Time Service (DTS) provides date and time synchronization within a cell.
• DCE Security Services provides authentication and authorization within a cell and is based upon MIT's Kerberos private key encryption system.

Version 1.5 of Digital DCE for OpenVMS VAX and OpenVMS Alpha includes the following new features. (For more information on these new features, see the Digital DCE for OpenVMS VAX and OpenVMS Alpha Product Guide, unless otherwise stated.)

• OpenVMS Version 7.2 Support --- Digital DCE for OpenVMS Version 1.5 is supported on OpenVMS Version 7.2. (Digital DCE for OpenVMS Version 1.5 does not run with Kernel Threads enabled. By default, DCE is built and shipped with Kernel Threads disabled.)
• New in DCE Version 1.5 on OpenVMS Version 7.2 (Alpha only)
  • Provides a new Authenticated RPC mechanism that uses NTLM security (See Section 17 for more information.)
  • Support for a server to impersonate a client. This means that the server may now run with the security credentials of the client. All the capabilities of the client belong to the server. (See Section 18 for more information.)
• New in DCE Version 1.5 on OpenVMS Version 6.1---7.2 (Alpha and VAX)
  • A mechanism for blocking RPC traffic on specific network interfaces.
  • Y2K compliant
• Bug Fixes --- The following bugs were fixed in Version 1.5:
  • When the security server is not running, sec_login_refresh_identity() returns an undocumented status code 336760967. The documentation states that the sec_rgy_server_unavailable status code should be returned. Example programs from OSF and other vendors show the refresh thread testing for the sec_rgy_server_unavailable status to determine if the refresh should be retried.
  • Executing an RPCLM command results in a fault invalid bound message on Alpha systems.

    $ RPCLM String Binding of Server:ncadg_ip_udp:16.32.80.42[2301] RPCLM> inq %CMA-F-EXCCOPLOS, exception raised; some information lost -DCERPC-E-FAULTINVALIDBOU, fault invalid bound (DCE / RPC)

  • In the directory DCE$SPECIFIC:[KRB5] there are hundreds of versions of KRB5KDC_RCACHE created by the DCE$SECD process. These files are cleaned up during a CLEAN operation but they are not cleaned up during a start or restart of DCE.
  • If you do not include <stdio.h> before including <DCE/dce_cf.h>, the header will not compile because it uses the datatype FILE*.
  • Attempting to kinit on an OpenVMS system results in the following error:

    $ kinit cell_admin $5$dkb0:[sys0.syscommon.]sysexe]dce$kinit.exe;4: Malformed representation of principal when parsing name T@

  • When an "Illegal state transition" occurs, the correct state is not reported. The code clobbered the state before reporting it. A state of 255 (No State) is reported but it is meaningless.
  • Print four-digit years on output from DCE processes. Allow four-digit data input from DCE administration functions. Fix leap year calculations for years after 2017.
  • OSF/DCE has a potential problem in the security server that could allow for a denial of service attack.
    If a principal, group, or organization name is greater than 1024 characters (including the cell name, so the actual name limit is less than 1024) when passed to security daemon (secd), it causes the secd core dump. The buffer is overrun which causes memory corruption. In certain cases, the lookup (or add, and so on) attempt on the client will then rebind to another secd to make the request, which will eventually crash all security daemons in the cell.
  • The new PathWay IP version can cause DCE setup to abort abruptly with error messages. PathWay changes the output of an image that returns the PathWay version. This causes output parsing routines to fail beause they search for runtime on the line containing the version.

Digital DCE for OpenVMS has four kits available:

• Runtime Services Kit
• Application Developer's Kit:
• CDS Server Kit
• Security Server Kit

Note that the right to use the Runtime Services Kit is included as part of the OpenVMS license. The other kits each require a separate license.

The following sections list the contents of each of these kits.

2.1 Runtime Services Kit

The Runtime Services provide the basic services required for DCE applications to function. The Runtime Services Kit contains the following:

• NTLM (Windows NT LAN Manager) security (OpenVMS Alpha Version 7.2 only)
• Authenticated CDS Advertiser and Client Support
• CDS Browser
• CDS Control Program (CDSCP)
• Authenticated DCE RPC runtime support (supports DECnet, TCP, and UDP)
• RTI (Remote Task Invocation) RPC for Digital's ACMSxp TP product
• Security Client Support
• Integrated Login
• A DCE_LOGIN tool for obtaining credentials
• A RGY_EDIT tool for registry maintenance functions
• KINIT, KLIST, and KDESTROY Kerberos tools
• An ACL_EDIT tool for access control lists (ACLs) for DCE objects
• RPC Control Program (RPCCP)
• Name Services Interface Daemon (nsid); also known as the PC Nameserver Proxy
• Native Kerberos support
• XDS Directory Services
• XDS Object Managment

The Application Developer's Kit is used by developers to build DCE applications. The Application Developer's Kit contains the following:

• The above contents of the Runtime Services Kit
• A mechanism to act as a porting aid in mapping MSRPC calls to DCE RPC calls (OpenVMS Alpha Version 7.2 only)
• Required DCE application development header files
• Interface Definition Language (IDL) compiler
• DCE IDL Compiler with C++ Extensions (Object-Oriented RPC)
• NIDL-to-IDL compiler (on OpenVMS VAX only)
• Generic Security Service (GSSAPI)
• LSE Templates for IDL
• UUID Generator
• .H (Include) files and .IDL files for application development
• Sample DCE applications

The CDS Server kit provides the naming services necessary for DCE clients to locate DCE server applications. The CDS Server kit includes the following:

• CDS server (cdsd)
• Global Directory Agent (GDA)

The Global Directory Agent (GDA) lets you link multiple CDS namespaces using the Internet Domain Name System (DNS).

2.4 Security Server Kit

The Security Server kit provides security services necessary for authenticated RPC calls between DCE client and server applications to function.

• Security server (secd)
• Tool used to create the security database (sec_create_db)
• Security server administrative tool (sec_admin)

Digital DCE for OpenVMS VAX and OpenVMS Alpha must be installed by running the DCE$INSTALL.COM procedure. Do not install the product by invoking the POLYCENTER Software Installation utility (PCSI) directly. DCE$INSTALL.COM calls PCSI and performs several preinstallation and postinstallation tasks. To install DCE, run the DCE$INSTALL.COM procedure as follows:

$ @ddcu:DCE$INSTALL.COM [help] ! optional PCSI help

See the Digital DCE for OpenVMS VAX and OpenVMS Alpha Installation and Configuration Guide for more information.

Make sure that you run DCE$SETUP.COM from a valid directory. Errors may occur during the installation that leave the default directory invalid.

See the first chapter in the Digital DCE for OpenVMS VAX and OpenVMS Alpha Installation and Configuration Guide for information on installation and configuration prerequisites.

3.1 Reconfiguring After Installation

If you are installing DCE over an existing Digital DCE for OpenVMS VAX or OpenVMS Alpha Version 1.5, perform the following steps:

1. Stop the DCE deamons with the following commands:

   $ @SYS$MANAGER:DCE$SETUP CLEAN

   $ @SYS$MANAGER:DCE$RPC_SHUTDOWN

2. After the installation, enter the following command:

   $ @SYS$MANAGER:DCE$SETUP START

A chapter on troubleshooting is part of the Digital DCE for OpenVMS VAX and OpenVMS Alpha Product Guide. This chapter includes the following sections:

• General troubleshooting hints
• Time zone and time synchronization problems
• Client/Server Check List

To define foreign commands, have the system manager add the following to your SYLOGIN.COM after the installation:

$ If F$SEARCH("SYS$MANAGER:DCE$DEFINE_REQUIRED_COMMANDS.COM")- .NES. "" THEN @SYS$MANAGER:DCE$DEFINE_REQUIRED_COMMANDS.COM $ If F$SEARCH("SYS$COMMON:[DCE$LIBRARY]DCE$DEFINE_OPTIONAL_COMMANDS.COM")- .NES. "" THEN @SYS$COMMON:[DCE$LIBRARY]DCE$DEFINE_OPTIONAL_COMMANDS.COM

6 Sizing for a Large Number of Users

The DCE daemons require a number of system resources for each concurrent DCE client or server process. The default number of resources allocated to the daemons is based on a maximum of 70 concurrent users (servers and clients) running on a node. If you are running more than 70 DCE users on a node, you must do the following:

1. Stop DCE if it is running.
2. Define a system-wide logical called DCE$MAX_USERS to the maximum number of users desired. For example, to configure DCE for a maximum of 80 users, enter the following:

   $ define/system dce$max_users 80

   
   Add this command to your system startup command file so that it is executed prior to starting DCE.

3. Restart DCE.

Refer to Section 8.1 for information about adding UCX sockets if the current number of sockets is insufficient for the number of DCE users running on the node.

7 Support for Applications

The Application Developer's Kit provides support for building DCE applications using DCE Services. It provides Application Programming Interfaces (APIs) to RPC communication services, security services, and CDS name services via the RPC Name Services Interface (NSI). (Version 1.1 of Digital DCE for OpenVMS VAX and OpenVMS Alpha replaced the Local Directory Services (LDS) with the Cell Directory Services (CDS).) The Application Developer's Kit contains the IDL compiler and Runtime support. The header files and IDL files for developing applications are installed in the following directory:

SYS$COMMON:[DCE$LIBRARY]

DCE applications must also be linked with the following shareable image:

SYS$LIBRARY:DCE$LIB_SHR.EXE

This image provides the entry points and global symbol definitions for the DCE API services.

A link options file, SYS$COMMON:[DCE$LIBRARY]DCE.OPT, is also provided. It is recommended that this options file be included when linking your DCE applications.

For example:

$ LINK PROG,DCE:DCE/OPT

Linking applications in this way makes your build procedures more portable between OpenVMS VAX and OpenVMS Alpha. It also prevents link environment changes from requiring changes to command files.

To help you port an MSPRC application to the DCE format, a new shareable image called SYS$LIBRARY:MSRPC_MAPPING_shr.exe can be used to link with the RPC application. This new image provides entry points that map a subset of MSRPC calls to their DCE equivalents. To identify which APIs have been mapped, see the MSRPC_MAPPING.h file. This file must be included in the RPC application.

8 Using TCP/IP Services for OpenVMS (UCX) with DCE

Version 1.5 of Digital DCE for OpenVMS VAX and OpenVMS Alpha requires modification of several UCX parameters for proper operation. You should carefully look through the parameters discussed in the next sections to understand any impact they may have on your local system.

All parameter changes described below, except for the cdsLib service definition, involve volatile parameters. That is, if UCX is restarted on your system, the parameter settings revert back to UCX-defined defaults, unless the configuration is also modified. The appropriate commands to modify both the volatile and configuration values are shown in the following sections.

DCE RPC and CDS use UCX sockets for interprocess communication. The UCX default maximum number of sockets is inadequate for most DCE sites. It is recommended that this parameter be set to a value of at least 250. Your site may require a higher value if you are using UCX for other than DCE. To modify the number of UCX sockets, enter the following commands with the appropriate value for the number of sockets. For example:

$ UCX SET COMMUNICATION /DEVICE_SOCKETS=250 $ UCX SET CONFIGURATION COMMUNICATION /DEVICE_SOCKETS=250

If the number of sockets is insufficient for the number of DCE users running on the node, increase the number of device sockets by two for each additional DCE user (client or server).

8.2 Sufficient UCX Small and Large Buffers

The number of UCX small and large buffers necessary for proper performance depends on the number of network software applications running on your system. As a minimum for DCE sites, the following values are recommended:

• Maximum Small Buffers = 600
• Maximum Large Buffers = 200

Before you configure DCE, you should check the maximum and peak values for both small and large buffers as follows:

$ UCX SHOW COMMUNICATION $ UCX SHOW COMMUNICATION/MEMORY

A nonzero drop value or a nonzero wait value indicates that you should increase the maximum buffer value. In general, the maximum value should be at least 20 percent higher than the peak value. Additionally, these counts will change in the future, and should be checked periodically, making adjustments as necessary. For example:

$ UCX SET COMMUNICATION/SMALL=(MAXIMUM:600) $ UCX SET CONFIGURATION COMMUNICATION/SMALL=(MAXIMUM:600) $ UCX SET COMMUNICATION/LARGE=(MAXIMUM:200) $ UCX SET CONFIGURATION COMMUNICATION/LARGE=(MAXIMUM:200)

See the UCX system management guide for more information on tuning UCX.

8.3 UCX TCP Protocol Settings

DCE CDS is sensitive to the values of the TCP protocol parameters of the underlying TCP communication package. Improperly setting these parameters may cause CDS client operations to appear to hang. (Hangs occur when the TCP parameters are incorrectly set and CDS client operations initiate operations that result in very large data messages being transferred between CDS clients and servers.) If this happens, other CDS clients continue to function and the hung client process may be aborted.

You can examine the current settings of the UCX TCP protocol parameters with the command:

$ UCX SHOW PROTOCOL TCP /PARAMETER

8.3.1 OpenVMS UCX TCP Parameter Settings

The correct default settings for the UCX TCP protocol parameters on OpenVMS VAX systems are as follows:

$ UCX SHOW PROTOCOL TCP /PARAMETERS TCP MTU size segment: disabled Delay ACK: disabled Loopback: disabled Drop timer: 600 Probe timer: 75 Receive Send Checksum: enabled enabled Push: disabled disabled Quota: 4096 4096

Note that the TCP /LOOPBACK and TCP/DELAY_ACK parameters must be disabled on Digital DCE for OpenVMS.

If either of these parameter settings do not match the default settings above, enter one of the following sets of commands:

$ UCX SET PROTOCOL TCP /NODELAY $ UCX SET CONFIGURATION PROTOCOL TCP /NODELAY $ UCX SET PROTOCOL TCP /NOLOOPBACK $ UCX SET CONFIGURATION PROTOCOL TCP /NOLOOPBACK

8.4 cdsLib Service Definition

CDS uses a TCP service definition in the UCX services database. This service defines the port number for CDS client and clerk communication. The DCE$SETUP CONFIGURE operation should properly define this service for you. By default, port number 1234 is used. If your site has another application that has defined a service using port 1234, the CONFIGURE operation will ask you to choose another port number for use with the cdsLib service.

After Digital DCE for OpenVMS is configured, should you need to change the port number assigned to the cdsLib service (for example, you want to install an application that needs port 1234), use the following commands:

$ UCX SET NOSERVICE "cdsLib"

• The current service definition is displayed and you are asked if you wish to delete it. Answer YES and enter the following command:

$ UCX SET SERVICE "cdsLib" /PORT=nnnn /file=NL: - /USER=DCE$SERVER /PROTOCOL=TCP /PROCESS=DCE$CDSCLERK

• Where nnnn is an unused port number to be used by CDS.
  Note that three additional ports are defined:
  • cdsAdver uses port number 1235 for process DCE$CDSADV
  • cdsDiag uses port number 1236 for process DCE$CDSD
  • kerberos5 uses port number 88 for process DCE$SECD

$ UCX SHOW SERVICE

• This command lets you examine the current UCX service definitions.
  The State for all of the DCE services should be Disabled.
  Also note that the service definitions in UCX are permanent settings; that is, once defined, they will still be set if UCX is restarted. For this reason, you do not need to put changes to the service definitions in your UCX startup procedure.

Version 1.5 of Digital DCE for OpenVMS can be used with TGV, Inc.'s MultiNet product in place of Digital's TCP/IP Services for OpenVMS. If you wish to use MultiNet with Digital DCE for OpenVMS, you must contact TGV, Inc. for a copy of MultiNet which contains support for DCE.¹

Then, follow the installation procedure and choose MULTINET when the installation process prompts you for the specific TCP/IP product you want to use.

Add or replace the following command to the system startup command procedure
(SYS$MANAGER:SYSTARTUP.COM) after the startup commands for the network transports, DECnet, and/or DEC TCP/IP Services:

$ @SYS$STARTUP:DCE$STARTUP START MULTINET

To configure DCE with MultiNet, enter the following command:

@SYS$STARTUP:DCE$STARTUP CONFIG MULTINET

Otherwise, DCE will expect TCP/IP communications to be provided by UCX.

The SYSGEN parameter MAXBUF must be set to a value greater than the maximum message size to be transferred between the CDS Clerk and CDS clients. If MAXBUF is not large enough, client processes will hang in an I/O wait state. If this happens, other CDS clients will continue to function and the hung process may be aborted without affecting them. The recommended setting for MAXBUF is 20,000 bytes or greater. (If you have a large CDS database with many directories, you may have to set it even higher.) If DCE processes hang while performing name service requests that transfer larger amounts of data, you probably need to increase the value of MAXBUF as follows:

$ RUN SYS$SYSTEM:SYSGEN SYSGEN> USE ACTIVE SYSGEN> SET MAXBUF nnnn ! nnnn = new value for MAXBUF SYSGEN> WRITE ACTIVE SYSGEN> USE CURRENT SYSGEN> SET MAXBUF nnnn ! nnnn = new value for MAXBUF SYSGEN> WRITE CURRENT SYSGEN> EXIT

Note that this setting will remain in effect until the next time AUTOGEN is invoked. Make the changes permanent by editing SYS$SYSTEM:MODPARAMS.DAT and adding MIN_MAXBUF = nnnn and then invoking AUTOGEN as described in the installation and configuration guide.

For further information on modifying SYSGEN parameters or on AUTOGEN, refer to the OpenVMS system management documentation.

	privacy and legal statement
DCE_RELNOTES.HTML