| Previous | Contents | Index |
Note that the following examples assume a DEC OSF/1 DCE server system.
# /etc/dcesetup show The following DCE daemons are active on this system: RPC daemon (rpcd) pid: 756 Security Server daemon (secd) pid: 762 Security Client daemon (sec_clientd) pid: 768 CDS Advertiser daemon (cdsadv) pid: 774 |
# cdscp show dir /.: |
# /etc/dcesetup restart |
# /etc/dcesetup clean # /etc/dcesetup start |
# rpccp show mapping |
<OBJECT> 2eef26c0-668f-11cc-8640-08002b35b39a <INTERFACE ID> 4c8782805000.0d.00.02.87.14.00.00.00,1.0 <STRING BINDING> ncacn_ip_tcp:25.0.0.145[1322] <ANNOTATION> DCE user registry |
When DCE$SETUP starts CDS, it may occasionally fail to contact the CDS master server. This may happen for one of the following reasons:
Is the CDS Master Server within broadcast range (YES/NO/?) [Y]? NO |
When configuring a cell, you may receive an error similar to the following from rpc_binding_set_auth_info():
336760839 (decimal), 14129007 (hex): Server not found in Kerberos database (dce / krb) |
To solve this problem, be sure that you do not configure a cell with the same name as another cell on the same network.
If you run system and functional tests that configure cells, make sure
that the tests generate a unique name each time the test is run. You
can also use the hostname of the server machine as part of the cell
name.
19.6 Modifications to DEC TCP/IP Services (UCX)
Digital DCE for OpenVMS VAX and OpenVMS Alpha requires modification of
several UCX parameters for proper operation. Make sure you read the
current Digital DCE for OpenVMS release notes for the most recent
recommendations.
19.7 Principal Quota Exhausted
If you try to use DCE$RGY_EDIT to add a principal name, you may receive the following error message:
?(rgy_edit) Unable to add principal "Xyzzy" - Principal quota exhausted (dce / sec) |
The message means that your process does not have sufficient DCE
credentials to complete the task. Therefore, you must login as
cell_admin or another privileged DCE account before retrying
the command.
19.8 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 specifications usually do not change, so it is rarely required that they be set to a writable PSECT attribute. RPC interface specifications are frequently shared. If your shareable image contains more than one cluster and the same interface specification is defined in multiple object modules, these interface specifications 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).
19.8.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.
19.8.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 $ |
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\bold) ncacn_dnet_nsp 63.503 RPC270002590001\bold) ncadg_ip_udp 16.32.0.87 1485 |
The following sections describe problems that may occur when Integrated
Login is enabled on your system, and solutions to those problems.
19.9.1 No Logical Name Match Error When Integrated Login Is Enabled
If you receive the error:
\*C%SYSTEM-F-NOLOGNAM, no logical name match) |
when you try to set host to another system, the problem may be occurring because the SYSGEN parameter LGI_CALLOUTS has been set nonzero, but the logical name LGI$LOGINOUT_CALLOUTS has not been defined.
This situation can only occur as a result of one of the following:
To solve this problem, enter one of the following commands to reenable Integrated Login by running DCE$SETUP or DCE$STARTUP, as follows:
$ @sys$startup:dce$setup start $ @sys$startup:dce$startup |
The Integrated Login component of DCE 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. See the chapter on Integrated Login for more information.
The following paragraphs explain how to solve this problem if it occurs.
If you cannot log in because LGI_CALLOUTS is set to 1 and DCE is not running, there are two solutions, as follows:
$ RUN SYS$SYSTEM:SYSGEN SYSGEN> SET LGI_CALLOUTS 0 SYSGEN> WRITE ACTIVE SYSGEN> EXIT $ |
SYSBOOT> SET LGI_CALLOUTS 0 SYSBOOT> C |
The Application Developer's Kit of Digital DCE for OpenVMS VAX and OpenVMS Alpha contains many example programs. These programs are located in subdirectories of the following directory:
SYS$COMMON:[SYSHLP.EXAMPLES.DCE]
Each example program has an online README file located in the same directory as the program. The README files introduce each program and tell you how to build and run the programs on OpenVMS or OpenVMS POSIX.
Table 20-1 briefly describes each example program.
| Example Program | Description |
|---|---|
| RPC Test Program #1 | Simple client/server program that makes minimal use of the DCE services. Server does not register end points; binding information not exported to namespace. |
| RPC Test Program #2 | Simple client/server program that makes slightly more use of the DCE services than does Test Program #1. Server registers end points; binding information exported to namespace; uses security. |
| Object-Oriented RPC Test Program #1 | Example that implements a 2x2 matrix in a server application and allows the client application to manipulate the matrix with an IDL interface. |
| Object-Oriented RPC Test Program #2 | Example that implements a 2x2 matrix in a server application and allows the client application to manipulate the matrix with an IDL interface; the location transparency feature is emphasized. |
| Book Program | More complex client/server application that uses many DCE services. Server registers end points; binding information is exported to namespace; uses mutex locks and security. |
| System Exerciser Program | Exercises much of the DCE system. |
| Payroll Program | Complex client/server application that uses many DCE services. Demonstrates mixed language support for IDL compiler; see Chapter 15 for a complete description. |
| RPC Phonebook Program | Complex client/server application that uses many DCE services. Distributes a phone number directory. Uses RPC and the name service. |
| Arithmetic Program | Demonstrates the basics of a distributed application with a remote procedure call. See the appendixes in the Guide to Writing DCE Applications for a complete description. |
| Inventory Program | Demonstrates many features of IDL and RPC application development. See the appendixes in the Guide to Writing DCE Applications for a complete description. |
| Remote File Program | Demonstrates advanced features of IDL and RPC application development. See the appendixes in the Guide to Writing DCE Applications for a complete description. |
| Transfer Data Program | Demonstrates additional advanced features of IDL and RPC application development. See the appendixes in the Guide to Writing DCE Applications for a complete description. |
You should copy the example files to another area before you attempt to build them. You also may want to open two separate windows for the client and server processes.
Please see the Digital DCE for OpenVMS VAX and OpenVMS Alpha release notes for current restrictions on using the example programs.
The following sections describe the example programs in more detail.
20.1 RPC Test Program #1
The RPC Test Program #1 is a simple client/server program that makes minimal use of the DCE services. The server does not register transport end points with the RPC daemon, and no binding information is exported to the directory service. The server binding information has to be transferred to the client manually by the user.
To build this example program, enter the following commands:
$ COPY/LOG SYS$COMMON:[SYSHLP.EXAMPLES.DCE.RPC.TEST1]*.* [] |
$ @TEST1.COM |
After the build is completed, define the server executable file as a foreign command. Assign a symbol using the following command syntax.
$ TEST1D:==$disk:[directoryTEST1D.EXE |
For example, enter the following command:
$ TEST1D:==$WORK1:[SMITH.MYDCETEST]TEST1D.EXE |
Then start the server with the following command:
$ TEST1D |
The server reports binding information for each of the various protocol sequences that are available and both displays the information on the terminal screen and writes it to a file called binding.dat. This binding information consists of three elements: a protocol sequence, a network address, and a transport end point. For example, the server might report the following binding information:
ncacn_ip_tcp 66.0.0.7 4344 |
If you want the server to use a specific protocol sequence, you can include that as an argument in the server startup command. For example:
$ TEST1D ncacn_ip_tcp |
This command causes the server to use only that protocol sequence. The protocol sequences currently supported include ncacn_ip_tcp (connection protocol), ncadg_ip_udp (datagram protocol), and ncacn_dnet_nsp (DECnet connection protocol).
Once the server is running, you can run the client on the same host or on another host. To run the client, define the client executable file as a foreign command. Assign a symbol using the following command syntax:
$ TEST1:== $disk:[directoryTEST1.EXE |
For example, enter the following command:
$ TEST1:== $WORK1:[SMITH.MYDCETEST]TEST1.EXE |
You must then provide the server binding information reported by the server. For example, you can run the client with the following command:
$ TEST1 ncacn_ip_tcp 66.0.0.7 4344 |
The client makes a number of remote procedure calls, each of which results in a simple arithmetic function being executed. After making a sequence of calls, the client reports the average elapsed time for the calls to complete. By default, the client makes 10 passes with 100 calls per pass. You can specify the number of passes and the number of calls per pass by adding two additional arguments to the client startup command. For example, the following command instructs the client to make 5 passes, with 1000 calls per pass:
$ TEST1 ncacn_ip_tcp 66.0.0.7 4344 5 1000 |
Because of the granularity of the clock on most systems, the average time per call will not be very accurate unless you set the number of calls per pass to a relatively high number (at least 1000).
The client can be run as many times as desired, as long as the server is still running.
| Previous | Next | Contents | Index |