HP DCE for OpenVMS Alpha and OpenVMS I64
Release Notes
Previous Contents

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

Version 3.2 of HP DCE for OpenVMS Alpha and OpenVMS I64 requires installation of HP TCP/IP Services for OpenVMS Version 5.0 or above.

8.1 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 HP 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:

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.

9 Using MultiNet with DCE

Version 3.2 of HP DCE for OpenVMS can be used with TGV, Inc.’s MultiNet product in place of HP’s TCP/IP Services for OpenVMS. If you want to use MultiNet with HP 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.

Define the following logical for using MultiNet product for TCP/IP communications. 


$ DEFINE /SYSTEM DCE$INTERNET MULTINET

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

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 HP TCP/IP Services: 


$ @SYS$MANAGER:DCE$SETUP START

To configure DCE with MultiNet, enter the following command: 


$ @SYS$MANAGER:DCE$SETUP CONFIG

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:

Note
1 HP 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 HP.
 


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

10 Using TCPware with DCE

Version 3.2 of HP DCE for OpenVMS can also be used with Process Software’s TCPware product in place of HP’s TCP/IP Services for OpenVMS. If you wish to use TCPware with HP 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.

Define the following logical for using TCPWARE product for TCP/IP communications. 


$ DEFINE /SYSTEM DCE$INTERNET TCPWARE

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

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 HP TCP/IP Services: 


$ @SYS$MANAGER:DCE$SETUP START

To configure DCE with TCPware, enter the following command: 


$ @SYS$MANAGER:DCE$SETUP CONFIG

11 Kerberos

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

By default, both DCE Security Server and native Kerberos5 KDC server cannot co-exist in the same system.

Support for native kerberos5 clients has undergone minimal interoperability testing.

12 Windows NT LAN Manager

Another mechanism to provide Authenticated RPC has been added to HP DCE for OpenVMS from Version 3.0 onwards. 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 18.

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 which 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 were 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

Previous Next Contents