The following sections provide details on restrictions and known bugs in this version of HP DCE for OpenVMS.

14.1 Kernel Threads and UPCALLS Support

As of OpenVMS V7.2-1, HP DCE for OpenVMS Version 3.0 and above supports DCE applications on Alpha built with Kernel Threads and Thread Manager upcalls enabled.

The DCE daemons (dced, secd, cdsd, etc.) are shipped with Kernel Threads disabled. Enabling Kernel Threads and Thread Manager upcalls on these images is not currently supported.

14.2 DCE Applications Need Not Be Relinked

All the new APIs implemented in HP DCE for OpenVMS Version 3.0 and 3.1 are also available in HP DCE for OpenVMS Version 3.2. Although, there any many new APIs implemented from DCE Version 3.0 onwards, existing DCE applications need not be re-linked before they can run on this release. However, if the application developer wishes to use any of the new APIs, then it will be necessary to recompile and relink.

14.3 Integrated Login and OpenVMS External Authentica tion

As of OpenVMS Version 7.1, the operating system provides support for external authentication via PATHWORKS. DCE Integrated Login is incompatible with this functionality. DCE$SETUP.COM will warn the user if external authentication is enabled on the host system. If Integrated Login is enabled inspite of the warning, external authentication will be disabled and applications that are dependent on external authentication may not function as expected.

14.4 Minimum Global Pages

HP DCE for OpenVMS Alpha and OpenVMS I64 Version 3.2 has the following global pages requirements:

• HP DCE for OpenVMS Alpha requires 7350 global pages before installation. (Previously, the requirement was 6000.)
• HP DCE for OpenVMS I64 now requires 17500 global pages before installation.

RTI RPC is a transactional RPC that is provided for use with HPs ACMSxp TP product. RTI RPC requires OSI TP from the OSI Application Developers Toolkit.

The DCE$SOCKSHR_TPS .EXE no longer ships with the I64 Kit. The image has a dependency on OSI TPS Runtime Library. The OSITP has been retired and does not ship with the OSI Application Developer’s Tool Kit.

14.6 Format of X.500 Cell Names

X.500 cell names have the form c=country/o=organization/ou= organization unit. X.500 cell names can contain spaces or hyphens if they are enclosed in double quotes, but underscores are never allowed, even if they are enclosed in double quotes. For example, the X.500 cell names /c=us /o=hp/ou="excess cell" and/c=us/o=hp/ou="excess- cell" are allowed, but /c =us/o=hp/ou=excess_cell and /c=us/o=hp/ou="excess_cell" are not allowed.

14.7 Shutting Down HP DCE for OpenVMS Before Reinstallation

If you are installing HP DCE for OpenVMS Version 3.2 over an existing version of DCE on a common system disk in a OpenVMS Cluster environment, be sure to shut down DCE and RPC on all nodes that share the common system disk before the installation. If you do not shut down DCE and RPC, parts of DCE and your Open VMS cluster may exhibit undesirable characteristics.

If you are reinstalling HP DCE for OpenVMS Version 3.2 over a previous version kit and you are using Integrated Login, and if you do not shut down DCE on all nodes that share the common system disk, you can cause the LOGINOUT image to fail to run on all of the nodes that share the common system disk.

You can correct this problem by shutting down and restarting DCE on the affected nodes. However, if LOGINOUT is not running, you cannot log in; therefore, you must reboot the system to correct the problem.

14.8 Configuring a CDS Replica Clearinghouse

Before you configure a CDS replica clearinghouse, make sure that the system clock is synchronized to within seconds of the CDS master server. To validate the time, use the following command:

$ dtscp show local servers

This shows the skew between the host and all other DTS servers in the cell.

14.9 Reconfiguring a CDS Replica Clearinghouse

If it becomes necessary to reconfigure or rebuild a host that includes a CDS replica clearinghouse, you may find that the creation of the clearinghouse succeeds but the skulk that is executed immediately after fails. If this happens, you will see the following message:

*** The creation of the CDS Replica Clearinghouse has succeeded *** but the namespace has been left in an inconsistent state. *** This condition will correct itself in a short period of time. *** Once the command "cdscp set dir /.: to skulk" can be *** successfully executed the namespace will be consistent and *** the replica clearinghouse will be fully operational. *** In the meantime you can replicate directories.

This is a known restriction. The situation will clear itself in about an hour; however, you will not be able to create any other clearinghouses until this condition has been corrected.

If you want to correct the problem immediately, you can restart DCE on the master server. You will then be able to skulk the root directory and add additional clearinghouses.

14.10 Privileged User Refreshing Credentials

When a privileged process creates or refreshes credentials, the owner UIC for the files is [DCE$SERVER]. If a privileged process needs to refresh credentials for an unprivileged process, the privileged process should first change its owner UIC to be the same as the unprivileged process and disable its privileges. Otherwise, the owner UIC for the updated credentials will be [DCE$SERVER], and the unprivileged process may no longer be able to read its own credentials.

14.11 Support for Integrated Login Before DCE Startup on OpenVMS Systems

If your OpenVMS system startup allows interactive logins to occur before DCE is started, the interactive logins that occur before DCE is started will not support Integrated Login.

If you interactively log in to OpenVMS before DCE is started, you must specify your OpenVMS username and password. You will not be logged in with DCE credentials. (If you log in after DCE is started on systems where Integrated Login is enabled, it is recommended that you specify your DCE principal name and password at the username and password prompts when using Integrated Login.)

14.12 Support for Integrated Login Before DCE Startup on OpenVMS Workstations

If your OpenVMS system startup allows DECwindows Motif to start up and display the DECwindows login box before DCE is fully started, the first DECwindows login will not support Integrated Login. In this case, Integrated Login will not be supported even if the first login occurs after DCE is up and running.

If DECwindows Motif displays the DECwindows login box before DCE is started, you must specify your OpenVMS username and password. You will not be logged in with DCE credentials. (If the DECwindows login box is displayed on your workstation after DCE is started and Integrated Login is enabled, it is recommended that you specify your DCE principal name and password at the username and password prompts when using Integrated Login.)

14.13 32-Character Restriction on DCE Principal Names for Integrated Login

When you log in to an OpenVMS system that has Integrated Login enabled, you can specify either your OpenVMS username or your DCE principal name at the username prompt. However, the DCE principal name you specify can contain no more than 32 characters. If your principal name and cell name combination contains more than 32 characters, specify the OpenVMS username that is associated with your DCE account instead. (This username is entered in the DCE$UAF file.) You should still enter your DCE password to obtain DCE credentials even if you specify your OpenVMS username.

14.14 Running DCE IMPORT in Batch Mode Without Password

If you run DCE IMPORT in batch mode and you do not supply a password for the DCE account on the command line, the password valid flag incorrectly remains set in the DCE registry. Because a password was not supplied, the flag should indicate password not valid and the user should not be allowed to log in. A scan of the DCE account via RGY_EDIT reveals the incorrect flag setting (password valid when actually the password is not valid). However, the user will not be allowed to log in (which is the correct behavior).

14.15 Potential Integrated Login and SYSGEN Problems

The Integrated Login component of HP DCE for OpenVMS uses the SYSGEN parameter LGI_CALLOUTS. LGI_CALLOUTS must be set to 1 only in the ACTIVE SYSGEN parameter set when DCE is running with Integrated Login enabled. LGI_CALLOUTS must never be set to 1 in the CURRENT SYSGEN parameter set - this would prevent all logins from occurring on a subsequent reboot of the system. The following paragraphs discuss the reasons for this restriction and solutions if the problem occurs.

If Integrated Login is enabled on your system, the DCE startup and configuration procedure, DCE$SETUP.COM, sets the SYSGEN parameter LGI_CALLOUTS to 1 in the ACTIVE SYSGEN parameter set when DCE is started and resets the parameter when DCE is shut down. LGI_CALLOUTS must never be set to 1 in the CURRENT SYSGEN parameter set because, in that case, the next time the system is booted the LGI_CALLOUTS parameter is set in the ACTIVE SYSGEN parameter set before DCE is started. This prevents logins from occurring.

If the ACTIVE value of LGI_CALLOUTS is set to 1 when DCE and Integrated Login are not running, the following error is displayed when LOGINOUT attempts to run (for example, for interactive or batch logins):

No logical name match

Consequently, all users are prevented from logging in to the system.

This problem can occur if, for example, a SYSGEN parameter is modified in the following way while Integrated Login is enabled. This prevents logins because it causes LGI_CALLOUTS to be set to 1 the next time the system is booted.

$ RUN SYS$SYSTEM:SYSGEN SYSGEN> SET param value SYSGEN> WRITE CURRENT SYSGEN> EXIT $

The correct way to modify a SYSGEN parameter is to make the change in MODPARAMS.DAT and then run AUTOGEN. If it is essential to modify a SYSGEN parameter without using MODPARAMS.DAT and AUTOGEN, you must ensure that if you use ACTIVE, you write the parameters into ACTIVE only; and if you use CURRENT, you write the parameters into CURRENT only. Do not copy the ACTIVE parameters into CURRENT.

Following are two examples of acceptable ways to modify a SYSGEN parameter:

$ RUN SYS$SYSTEM:SYSGEN SYSGEN> USE CURRENT SYSGEN> SET param value SYSGEN> WRITE CURRENT SYSGEN> EXIT $ $ RUN SYS$SYSTEM:SYSGEN SYSGEN> USE ACTIVE ! optional, default is ACTIVE SYSGEN> SET param value SYSGEN> WRITE ACTIVE SYSGEN> EXIT $

If you cannot log in because LGI_CALLOUTS is set to 1 and DCE is not running, there are two solutions, as follows:

• If you are already logged into the system, use SYSGEN to correct the problem.

  $ RUN SYS$SYSTEM:SYSGEN SYSGEN> SET LGI_CALLOUTS 0 SYSGEN> WRITE ACTIVE SYSGEN> EXIT $

• Reboot the system with a conversational boot and ensure that the LGI_CALLOUTS parameter is zero.

  SYSBOOT> SET LGI_CALLOUTS 0 SYSBOOT> C

HP DCE for OpenVMS supports the rpc_c_prot_level_pkt_privacy level of data encryption as of this baselevel. Recent changes in the government's encryption regulations allow this functionality to be provided in the base DCE kit, as opposed to a separate product (as was done previous versions of HP DCE for OpenVMS). See the documentation on rpc_binding_set_auth_info for details.

14.17 DCE IDL Compiler and C++ Exceptions

A client using the DCE IDL compiler with C++ extensions invokes methods on objects that causes IDL generated client stub code to be invoked. By default, communications errors or remote faults that occur during the stub’s processing cause exceptions to be raised using the DCE Threads exception handling mechanism. Therefore, C++ code that needs to catch and respond to these exceptions must also use the DCE Threads exception handling mechanism.

Some, but not all, C++ compilers have built-in language support for exceptions. Exceptions are not supported in older versions of the DEC C++ for OpenVMS compilers. C++ application code that processes exceptions returned from DCE IDL stubs should continue to use DCE Threads exceptions if using compilers without exceptions support.

You can avoid the raising of exceptions from DCE IDL stubs by using the [comm_status] and [fault_status] ACF attributes. For more information, see the Guidelines for Error Handling chapter in the DCE Application Development Guide.

14.18 Automatic Registration of Servers

In the IDL compiler, servers are now automatically registered by server stubs. If you call rpc_server_register_if() , the "already registered" status is returned. (Remove the call to rpc_server_register_if() from the server.cxx file before you build the example programs in the Example Programs section of the HP DCE for OpenVMS Alpha and OpenVMS I64 Product Guide.)

14.19 Support for sigwait()

The DCE Application Guide and DCE Reference Guide include incorrect information about support for sigwait(). DECthreads does not support sigwait() on the OpenVMS platform.

14.20 Compiling Stubs on Alpha

If a stub is compiled on Alpha with optimization switched on, it may not handle exceptions correctly, depending on the version of DEC C. Therefore, on Alpha, you should compile stubs with optimization switched off, unless you are sure that the version of DEC C that is on your system handles this situation correctly.

14.21 Using the -cpp_cmd (/PREPROCESS) IDL Compiler Option on OpenVMS Alpha

When you specify the -cpp_cmd (/PREPROCESS) option in an IDL command, the IDL compiler preprocesses any IDL or ACF sources by invoking the DEC C compiler with the /PREPROCESS_ONLY qualifier. Because of a bug in some versions of the DEC C compiler on OpenVMS Alpha, the IDL compiler may incorrectly report source line numbers and contents when it reports error messages.

If your IDL and ACF source files do not use C preprocessor directives (such as #define), then you do not need to specify the -cpp_cmd (/PREPROCESS) option. Otherwise, the workaround is to change multiline comments to a series of single line comments.

14.22 POSIX

The OpenVMS POSIX product has been retired, and support for the POSIX command line is not available for HP DCE for OpenVMS Alpha and OpenVMS I64 Version 3.2. The OpenVMS C runtime support for many of the POSIX calls has improved, and most applications should see no change in behavior. Only those applications which require the POSIX command line interface are affected.

14.23 C RTL Routine Sleep Not Thread Safe

The C RTL routine sleep is not thread safe. The sleep call may wake up prematurely if calls to DCE APIs are made at the same time. It is recommended that you use a thread-safe mechanism such as pthread_delay_np, pthread_cond_wait, pthread_cond_timedwait, and pthread_cond_signal to delay a thread. For more information on these APIs, please refer to the OSF DCE Application Development Reference Manual.

14.24 Ordering of System Startup Procedures

The order of startup procedures should be as follows: DECnet, TCP/IP software, DCE, then DCE applications.

14.25 Case Sensitivity of DCE Utilities

Some input to HP DCE for OpenVMS utilities is case-sensitive (for example, CDSCP entity attribute names). Since the DCL command line interface converts all input to uppercase before passing it to a utility, some input to the DCE utilities will need to be enclosed in quotation marks (" ").

When you enter commands directly at DCE utility prompts, you should not use the quotation marks because case-sensitivity is preserved. (Case-sensitivity is not preserved by the Integrated Login utilities DCE$UAF, IMPORT, and EXPORT because these are true native OpenVMS applications.)

14.26 CDSCP and DCECP Commands Requiring a Local Server

There are several CDSCP commands that assume the presence of a CDS server on the local system. These commands will not execute properly in the absence of a local server. At present,

CDSCP will return the following error:

Failure in routine: Failure in routine: cp-xxxxxxx not registered in endpoint map (dce/rpc) The affected commands are: $ cdscp show server $ cdscp disable server $ cdscp create clearinghouse <clearinghouse_name> $ cdscp delete clearinghouse <clearinghouse_name>

DCECP will return the following error:

Failure in routine: Failure in routine: Error: Binding incomplete (no object ID and no endpoint) The affected commands are: $ dcecp -c clearinghouse create <clearinghouse_name_list>) $ dcecp -c clearinghouse delete <clearinghouse_name_list>) $ dcecp -c clearinghouse initiate <clearinghouse_name_list> -checkpoint) $ dcecp -c clearinghouse repair <clearinghouse_name_list> -timestamps) $ dcecp -c clearinghouse verify <clearinghouse_name_list>) $ dcecp -c clearinghouse disable <clearinghouse_name_list>)