Document revision date: 15 July 2002
[Compaq] [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]
[OpenVMS documentation]

COM, Registry, and Events for OpenVMS Developer's Guide


Previous Contents Index


Appendix B
Troubleshooting

B.1 RPC Troubleshooting

When you perform a significant number of simultaneous NTLM authentications, the following errors are likely to occur. Several factors affect the number of simultaneous NTLM authentications, however, you are most likely to see these errors when the network is congested or when the RPC application server does not respond to requests in a timely manner. The errors are returned as standard RPC application return values.

Table B-1 provides a description of the suspected cause and possible workarounds.

Table B-1 RPC Errors
Error Cause/Corrective Actions
RPC_S_CONNECTION_REJECTED This error is seen by the client application as an exception when using either DECnet Phase IV or DECnet Phase V as a transport and when the server is heavily loaded servicing other DECnet clients.

The system returns this error when the client RPC run time binds to a newly created socket and the socket call returns error 61 (connection refused).

Possible solutions:

  1. Raise DECnet resource quotas.
  2. Enhance the client RPC program to catch the exception and either retry the RPC or choose a different server.
RPC_S_CONNECTION_TIMED_OUT This error is seen by the client application as an exception when using TCP or DECnet as a transport and when the server is heavily loaded.

The system returns this error when the client RPC run time binds to a newly created socket and the server takes too long to either accept or reject the connection.

Possible solutions:

  1. Configure TCP or DECnet to wait longer before sockets time out.
  2. Enhance the RPC client application to call rpc_mgmt_set_com_timeout() and instruct the RPC run time to retry when it gets this socket error.
  3. Recode the client RPC program to catch the exception and either retry the RPC or choose a different server.
RPC_S_ASSOC_SHUTDOWN This error is seen by the client application as an exception when using TCP or DECnet as a transport and when the client is heavily loaded (usually when the client is also an RPC server).

After an RPC server receives an RPC_BIND packet from a client and the server sends back an RPC_BIND_ACK packet to the client, the server expects to receive a REQUEST packet within 12 seconds. If the client does not send the REQUEST packet within 12 seconds, the RPC server deletes the association and sends a SHUTDOWN packet to the client. The client RPC run time raises an exception to the RPC application.

This scenario is likely to occur when the client RPC application is also acting as an RPC server and that RPC server is already heavily loaded.

Possible solutions:

  1. Implement the client RPC program to catch the exception and either retry the RPC or choose a different server.
RPC_S_COMM_FAILURE

This error is seen by the client application as an exception when using DG (UDP) as a transport and when the RPC server is heavily loaded.

The RPC client sends a REQUEST packet to the server. If the client does not get a WORKING packet response from the server within 30 seconds, the client sends a PING packet to the server to see if the server is still active and working on the client's request. If the RPC server is under heavy load, the server may not return the WORKING packet to the client before the client times out.

Possible solutions:

  1. RPC client application can call rpc_mgmt_set_com_timeout() to instruct the RPC run time to wait longer than 30 seconds before timing out.
  2. Implement the client RPC program to catch the exception and either retry the RPC or choose a different server.

B.2 Troubleshooting the ACME server

Use the following procedure to troubleshoot problems with the ACME server:

  1. Verify that the ACME_SERVER process is running (use the SHOW SERVER ACME command) and verify there is a connection between the MSV1_0 ACME agent and the Compaq Advanced Server for OpenVMS process.
  2. If no connection exists, verify that the PWRK$ACME_SERVER logical name contains the SCS node names of systems in the cluster that are running the Compaq Advanced Server for OpenVMS process.
  3. If the PWRK$ACME_SERVER logical name is defined correctly, verify that the Compaq Advanced Server for OpenVMS process is running on the systems specified (look for the PWRK$LMSRV process).
  4. If authentications are failing, check the following:

B.3 Troubleshooting the DCOM$RPCSS Process

The DCOM$RPCSS process must be running to run any COM for OpenVMS applications on your OpenVMS system. The DCOM$STARTUP.COM command file is automatically starts this process. If you have problems running COM for OpenVMS applications, check that this process is running. Use the following command:


  $ SHOW SYSTEM 

If the process is initializing, the process name is DCOM$STARTUP-**. If the process is in its normal running state, the process name is be DCOM$RPCSS.

Check the SYS$MANAGER:DCOM$RPCSS.OUT log file for error messages from the DCOM$RPCSS process. The messages can include the following:

B.4 Troubleshooting the Advanced Server for OpenVMS

The Advanced Server for OpenVMS must be running to authenticate users with NT credentials.

A troubleshooter may wish to enable the audit policy to capture failures for logonoff and system events. For example, on systems running Advanced Server for OpenVMS, issue the command:


    $ ADMINISTER SET AUDIT POLICY/AUDIT/FAILURE=(LOGONOFF,SYSTEM) 

To monitor events, issue the commands:


    $ ADMINISTER SHOW EVENT /FULL /TYPE=SYSTEM 
    $ ADMINISTER SHOW EVENT /FULL /TYPE=SECURITY 

For more information, the Advanced Server for OpenVMS Server Administrator's Guide provides a chapter on Monitoring Events and Troubleshooting.

Additionally, the system manager may want to check the system operator log, SYSMANAGER:OPERATOR.LOG, to verify that no network errors have occurred.

B.5 Troubleshooting COM for OpenVMS Application Failures

This section describes problems you may encounter when running a COM application.

B.5.1 Access Denied Failures

For information on access denied failures, see Section 5.4.6.


Appendix C
Cookbook Examples: Building a Sample Application on OpenVMS

Note

SAMPLE1 and DISPATCH_SAMPLE1 are taken from Dale Rogerson's book, Inside COM, published by Microsoft Press.

C.1 COM Example (Sample1)

This example implements a COM client and server in which the component provides two interfaces: IX and IY . The client also queries the component for a third interface, IZ , an interface that the component does not provide.

This example demonstrates connectivity between two OpenVMS systems, between two Windows NT systems, or between an OpenVMS system and a Windows NT system.

Note

Before you build the application on OpenVMS, you must run NTA$LOGON and acquire Windows NT credentials. For more information, see Section 8.2.

C.1.1 OpenVMS Instructions

The following sections describe how to build the application on an OpenVMS system.

C.1.1.1 Building the Application on OpenVMS

Copy files from the DCOM examples directory to your local directory. For example:


   $ set default mydisk:[mydirectory] 
   $ copy dcom$examples:[sample1]*.* [] 

To build the application, run the following command procedure:


   $ @build_sample1 

If you have MMS, you can use the included description file as follows:


   $  MMS/DESCRIPTION=BUILD_SAMPLE1.MMS 

The BUILD file builds and registers both the in-process and out-of-process servers.

C.1.1.2 Registering the Application on OpenVMS

The build procedure automatically registers both DISPCMPNT$SHR.EXE and DISPCMPNT.EXE . To register the components manually, use the following procedure:

C.1.1.3 Running the Application on OpenVMS as an Out-of-Process Server

To run the sample where the component is an out-of-process server, run DISPCMPNT.EXE . When the system displays the Server: Waiting message from the component, run the client in a separate window or terminal session.

The client displays the following:


  To which server do you want to connect? 
   1) In-Process Server 
   2) Out-of-Process Server 
   : 

Enter 2 to select the out-of-process server.

C.1.1.4 Running the Application on OpenVMS and Specifying a Remote Server

Run DISPCMPNT.EXE on the system you designate as the remote machine (or server system). The remote system can also be a Windows NT system. When you receive the Server: Waiting message from the component, run the client on the system you designate as the local machine (or client system). For example:


   $ client :== $path-nameCLIENT.EXE 
   $ client remote-system-name
   2 
   $ 

The client displays the following:


  To which server do you want to connect? 
   1) In-Process Server 
   2) Out-of-Process Server 
   : 

Enter 2 to select remote server execution, out-of-process server.

C.1.1.5 Running the Application on OpenVMS as an In-Process Server

To run the sample where the component is an in-process server, run only the client. For example:


   For InProc: 
   $ client 
   1 
   $ 

The client displays the following:


  To which server do you want to connect? 
   1) In-Process Server 
   2) Out-of-Process Server 
   : 

Enter 1 to select the in-process server.

C.1.2 Windows NT Instructions

The following sections describe how to build the application on a Windows NT system.

Note

In order to build Visual C++ applications from a DOS window, you must first set up a number of environment variables. If you did not select the option to have these variables set up automatically when you installed Visual C++, you will need to set them up each time you create a DOS window. To set up these variables, execute the file


C:\Program Files\Microsoft Visual Studio\VC98\BIN\VCVARS32.BAT 

C.1.2.1 Building the Application on Windows NT

Copy the README-SAMPLE1.TXT file and the following files from the COM examples directory to your Windows NT system:


   CLIENT.CXX 
   CMPT.CXX 
   CMPT.DEF 
   MAKE-ONE. 
   MAKEFILE.BAT 
   PROXY.DEF 
   REGISTRY.CXX 
   REGISTRY.H 
   SERVER.IDL   

Build the sample using the MAKEFILE.BAT file. For example:


   > MAKEFILE 

The Makefile builds and registers both the in-process and out-of-process servers.

C.1.2.2 Registering the Application on Windows NT

The build procedure make-one automatically registers DISPCMPNT.DLL , PROXY.DLL , and CMPNT.EXE as follows:


   regsvr32 -s Dispcmpnt.dll 
   regsvr32 -s Proxy.dll 
   Dispcmpnt /RegServer 

To unregister the application, enter the following:


   regsvr32 -u Dispcmpnt.dll 
   regsvr32 -u Proxy.dll 
   Dispcmpnt /UnRegServer 

C.1.2.3 Running the Application on Windows NT

Run CLIENT . Follow the same procedure as described for OpenVMS for running the application as an in-process server ( Section C.1.1.5) and out-of-process server Section C.2.1.3).

Use the name of a remote machine (UNC or DNS) as an argument to instantiate the object on the remote machine. For example:


   >Client hostname        ! point the client at the remote system  
   2                       ! means outproc invocation       
   >                                                        

C.2 Automation Example (Dispatch_Sample1)

This example implements the Automation component server as a dual interface. There are two separate clients: Dclient , which connects to the dual interface through the dispinterface, and Client , which is a COM client implementation that connects through the IUnknown interface (using a v-table).

This example demonstrates connectivity between two OpenVMS systems, between two Windows NT systems, or between an OpenVMS system and a Windows NT system.

C.2.1 OpenVMS Instructions

The following sections describe how to build the application on an OpenVMS system.

C.2.1.1 Building the Application on OpenVMS

Copy files from the DCOM examples directory to your local directory. For example:


   $ set default mydisk:[mydirectory] 
   $ copy dcom$examples:[dispatch_sample1]*.* [] 

To build the application, run the following command procedure:


   $ @build_dispatch_sample1 

If you have MMS, you can use the included description file as follows:


   $  MMS/DESCRIPTION=BUILD_DISPATCH_SAMPLE1.MMS 

The BUILD file builds and registers both the in-process and out-of-process servers.

C.2.1.2 Registering the Application on OpenVMS

The build procedure automatically registers both DISPCMPNT$SHR.EXE and DISPCMPNT.EXE . To register the components manually, use the following procedure:

C.2.1.3 Running the Application on OpenVMS as an Out-of-process Server

To run the sample where the component is an out-of-process server, run DISPCMPNT.EXE .

When the system displays the Server: Waiting message from the component, run the client in a separate window or terminal session.

The client displays the following:


  To which server do you want to connect? 
   1) In-Process Server 
   2) Out-of-Process Server 
   : 

Enter 2 to select the out-of-process server.


Previous Next Contents Index

  [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]  
  privacy and legal statement  
6539PRO_018.HTML