Document revision date: 28 June 1999

Version 1.5 of Digital DCE for OpenVMS has been designed to be used with Wollongong's PathWay product in place of Digital's TCP/IP Services for OpenVMS.DCE.¹

If you wish to use PathWay with Digital DCE for OpenVMS, you must contact Wollongong for availability information and for a copy of PathWay that contains support for DCE. (Wollongong has not yet released a version of PathWay that supports Digital DCE for OpenVMS.)

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

Add 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 PATHWAY

To configure DCE with PathWay, enter the following command:

@SYS$STARTUP:DCE$STARTUP CONFIG PATHWAY

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

11 Using TCPware with DCE

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

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

Add 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 TCPWARE

To configure DCE with TCPware, enter the following command:

@SYS$STARTUP:DCE$STARTUP CONFIG TCPWARE

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

12 Kerberos

The DCE Security Server makes UDP port 88 (service name "kerberos5") is available for use by native Kerberos clients for authentication.

Kerberos realm names must match the cell name of the DCE security server.

Support for native kerberos5 clients has undergone minimal interoperability testing. Interoperability has been tested between Digital DCE for OpenVMS V1.5 and MIT Kerberos V BL2. On non-OpenVMS platforms, interoperability fails when you use DCE Security with versions of MIT Kerberos V later than BL2. Full support will be provided in a future version of Digital DCE for OpenVMS VAX and OpenVMS Alpha.

13 Windows NT LAN Manager

Another mechanism to provide Authenticated RPC has been added to DCE for OpenVMS Alpha Version 1.5. Support for NTLM (Microsoft's NT LAN manager protocol) has been added on OpenVMS Alpha Version 7.2.

To use Authenticated RPC, a client passes its user security information (credentials) to the client's runtime. The client runtime forwards these credentials to the server runtime through 3-legged protocol exchange. This provides a secure mechanism for authenticating the client, and also allows server impersonation of that client.

14 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:

• Program sections (PSECTs) in shareable images should be SHR,NOWRT or NOSHR,WRT unless the image is installed with priviledges.
• Program sections in modules linked against shareable images must match exactly or conflicting PSECT errors will occur.
• Until the program runs, you may have to correct PSECT attributes as far back as the shareable image.

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

(GBL,SHR,NOWRT)

RPC interface specs usually do not change, so it is rarely required that they be set to a writable PSECT attribute. RPC interface specs are frequently shared. If your shareable image contains more than one cluster and the same interface spec is defined in multiple object modules, these interface specs 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.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/map=myshr.map - _$ test1_mgr,test1_sstub,dce:dce.opt/opt %LINK-I-BASDUERRS, basing image due to errors in relocatable references %LINK-W-ADRWRTDAT, address data in shareable writeable section in psect TEST1_V0_0_S_IFSPEC offset %X00000000 in module TEST1_SSTUB file USER:[MY.CODE.DCE]TEST1_SSTUB.OBJ; $

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/map=myshr.map - $_ 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.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/map=test1d.map 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 myshr.map and test1d.map 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/map=test1d.map test1_main,sys$input/opt PSECT= TEST1_V0_0_S_IFSPEC, shr,nowrt,gbl myshr.exe/share ctrl-z $

14.3 Errors Activating Shareable Images

When you run this program, the following results occur:

$ run test1d %DCL-W-ACTIMAGE, error activating image MYSHR -CLI-E-IMAGEFNF, image file not found SYS$LIBRARY:MYSHR.EXE $

To allow the image activator to check a directory other than SYS$LIBRARY for your new shareable image, you must define a logical name or you must copy your new shareable image into SYS$LIBRARY. In the following example, a logical name is defined and the program is run again with the following results:

$ define MYSHR sys$disk:[]myshr.exe; $ $ run test1d %DCL-W-ACTIMAGE, error activating image MYSHR -CLI-E-IMGNAME, image file USER:[MY.CODE.DCE]MYSHR.EXE; -SYSTEM-F-NOTINSTALL, writable shareable images must be installed $

The problem is in the myshr.exe image: myshr.exe has PSECTs whose PSECT attributes specify both SHR and WRT. The solution is to add the correct PSECT attributes to the offending PSECTs in the myshr.exe shareable image to myshr.opt. This can be done on the command line, as follows:

$ link/share/exe=myshr.exe/map=myshr.map - $_ test1_mgr,test1_sstub,dce:dce.opt/opt,sys$input/opt psect= TEST1_V0_0_S_IFSPEC, shr,nowrt,gbl psect= RPC_SS_ALLOCATE_IS_SET_UP, noshr,wrt,gbl psect= RPC_SS_CONTEXT_IS_SET_UP, noshr,wrt,gbl psect= RPC_SS_SERVER_IS_SET_UP, noshr,wrt,gbl psect= RPC_SS_THREAD_SUPP_KEY, noshr,wrt,gbl psect= RPC_SS_CONTEXT_TABLE_MUTEX,noshr,wrt,gbl psect= TEST1_V0_0_C_IFSPEC, shr,nowrt,gbl ctrl-z $

All of the PSECTs that existed in the myshr.map mapfile that had SHR and WRT attributes were changed so that the PSECT was either SHR,NOWRT or NOSHR,WRT. The choice depends upon your use of the data item. IFspecs are usually shared and nonwritable. The RPC_SS PSECTs are written and not generally shared among program images linked against the shareable image.

The following example tries to relink the main program again, but another problem occurs:

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

Because the PSECT attributes of the TEST1_V0_0_S_IFSPEC PSECT was changed in the shareable image, its reference in test1_main.obj is not correct. To solve this problem, add the correct PSECT attribute. For example:

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

In the final example, the test1d program is run and the desired results occur.

$ run test1d ncacn_ip_tcp 16.32.0.87 3314 ncacn_dnet_nsp 63.503 RPC270002590001 ncadg_ip_udp 16.32.0.87 1485

15 Support for Workstations

Digital DCE for OpenVMS VAX and OpenVMS Alpha Version 1.5 contains features that support users who access DCE services from workstations, as follows:

• DCE menu in the DECwindows session manager
• DCE$REFRESH utility that refreshes the login credentials provided by Integrated Login beyond the default DCE credential lifetime

Digital DCE for OpenVMS V1.5 includes an additional menu in the DECwindows session manager. This menu makes DCE easier to use for those users accessing DCE services from a DECwindows workstation. The DCE menu, shown below, provides easy-to-invoke access to the following DCE services:

• Namespace Editor
  
• Show DCE Credentials
• Refresh DCE Credentials
• Change DCE Password
  
• DCE Registry Editor
• CDS Control Program
• RPC Control Program

Digital DCE for OpenVMS V1.5 provides the DCE$REFRESH utility that refreshes the login credentials provided by Integrated Login beyond the default DCE credential lifetime. (Login credentials expire at regular intervals unless they are refreshed.)

If you are a DECwindows workstation user, you can automatically refresh your login credentials by starting the DCE$REFRESH utility in one of the following ways:

• Select Refresh DCE Credentials from the DCE menu
• Run SYS$SYSTEM:DCE$REFRESH

The DCE$REFRESH utility asks for your DCE password and then runs in the background. It automatically refreshes your login credentials just before they expire.

You can interactively refresh credentials by entering the kinit command, but you must repeat that command each time the credentials are about to expire.

16 Restrictions and Known Bugs

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

16.1 OpenVMS Version 7.2 Support

Digital DCE for OpenVMS V1.5 is supported on OpenVMS V7.2. Digital DCE for OpenVMS V1.5 does not run with Kernel Threads enabled. By default, DCE is built and shipped with Kernel Threads disabled.

16.2 Minimum Global Pages

Digital DCE for OpenVMS VAX and OpenVMS Alpha Version 1.5 has increased its global pages requirements as follows:

• Digital DCE for OpenVMS VAX now requires 3750 global pages before installation. (Previously the requirement was 3000.)
• Digital DCE for OpenVMS Alpha now requires 7350 global pages before installation. (Previously the requirement was 6000.)

Before you upgrade from the Digital DCE Developers' Kit for OpenVMS VAX Version 1.0 to Digital DCE Version 1.5, you should shut down DCE Version 1.0 on the system. If DCE Version 1.0 is running in a cluster, be sure to repeat the shutdown procedure on all nodes of the cluster. The command to do this is:

$ @SYS$MANAGER:DCE$SETUP STOP

If you do not perform this step before installing Version 1.5 of DCE for OpenVMS, DCE$SETUP will not detect the presence of the Local Directory Service Daemon (LDSD) on your system and will not shut it down. The DCE$LDSD process will remain running on the system until the next reboot or until it is stopped with the STOP /ID=pid command. LDS is an obsolete facility that was replaced by CDS in Version 1.1 of Digital DCE for OpenVMS.

Note that if LDSD remains active on your system, it will have NO effect on the operation of Version 1.5 of Digital DCE for OpenVMS. RPC looks only for the Cell Directory Services (CDS) facility for name service operations.

16.4 Interoperability with the DCE Developers' Kit

No specific testing has been performed with the DCE Developers' Kit for OpenVMS Version 1.0. However, the RPC and Threads components of the Developers' Kit are prerequisites and should work as expected.

16.5 Support for RPC Only Configurations

Digital DCE for OpenVMS Version 1.5 supports the use of RPC without the use of other DCE components or the need to configure a DCE cell. Because OpenVMS DCE is based on Open Software Foundation's DCE source code, this functionality could become unsupported in a future version of OSF DCE, and thus unsupported in Digital DCE for OpenVMS. Compaq will make every effort to continue the support of RPC ONLY configurations; however, be advised that a possibility exists that future versions may not support RPC ONLY without configuring a DCE cell.

16.6 RTI (Remote Task Invocation) RPC

RTI RPC is a transactional RPC which is provided for use with Digital's ACMSxp TP product. RTI RPC requires OSI TP from the OSI Application Developer's Toolkit.

16.7 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=digital/ou="excess cell" and /c=us/o=digital/ou="excess-cell" are allowed, but /c=us/o=digital/ou=excess_cell and /c=us/o=digital/ou="excess_cell" are not allowed.

16.8 Shutting Down Digital DCE for OpenVMS Before Reinstallation

If you are installing Digital DCE for OpenVMS Version 1.5 over an existing version of DCE on a common system disk in a OpenVMS Cluster environment, be sure to shut down DCE on all nodes that share the common system disk before the installation. If you do not shut down DCE and you select the PURGE option within VMSINSTAL, parts of DCE and your OpenVMS cluster may exhibit undesirable characteristics.

If you are reinstalling Digital DCE for OpenVMS Version 1.5 over a Version 1.3 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.

16.9 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 dce local servers

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

16.10 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 problem. 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.

16.11 Privileged User Refreshing Credentials

When a priviledged 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.

16.12 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.)

16.13 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.)

16.14 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.

16.15 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. In Version 1.5, 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). This problem will be corrected to indicate an invalid password in the next release.

	privacy and legal statement
DCE_RELNOTES_001.HTML