Compaq DCE for OpenVMS VAX and OpenVMS Alpha
Release Notes


Previous Contents

8.1 Sufficient TCP/IP Sockets

DCE RPC and CDS use TCP/IP 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 TCP/IP 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 Compaq 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                ! Valid on TCP/IP Version 5.0 
$ UCX SET CONFIGURATION PROTOCOL TCP /NODELAY  ! Valid on TCP/IP Version 5.0 
 
$ 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 Compaq 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 four additional ports are defined:


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

This service definition is required on Compaq TCP/IP Services Version 5.0 as well as Version 4.0.

8.5 Using MultiNet with DCE

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

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

Note

1 Compaq is not responsible for third-party application support. Any issues around third-party IP applications should be directed to those third-party companies and not to Compaq.

9 Using PathWay with DCE

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

If you want to use PathWay with Compaq DCE for OpenVMS, you must contact Wollongong for availability information and for a copy of PathWay, which contains support for DCE.

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

10 Using TCPware with DCE

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

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

11 Kerberos

The DCE Security Server makes UDP port 88 (service name "kerberos5") 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 had minimal interoperability testing.

12 Windows NT LAN Manager

Another mechanism to provide Authenticated RPC has been added to DCE for OpenVMS. Support for NTLM (Microsoft's NT LAN manager protocol) has been added in OpenVMS Alpha Version 7.2-1 and higher.

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.

To select NTLM security, set the authn_svc parameter of the rpc_binding_set_auth_info call to rpc_c_authn_winnt . More information about manipulation of the data structures involved can be found in Section 15.

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


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

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

13.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 
 $ 

13.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 myshr.opt options file that is used to build the myshr.exe shareable image. 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> 
$ 

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 


Previous Next Contents