| The first question I'd ask here is which is the client and
which is the server? It's not obvious from the problem
statement. The chances are that the client is on Windows NT
and the server on VAX - so I'll assume this for now. If I've
got this wrong then you'll have to re-interpret my comments
the other way round...
Generally speaking, if a server throws an exception while
servicing a client request, that exception is passed back
to the client, unless the server manager code (the application
code that actually services the request) traps the error
itself (for example, using the TRY...CATCH...ENDTRY macros).
So, if the server accesses an invalid memory address, then
instead of exiting with an Access Violation (as it might do
if it were a standalone program), the exception is caught
by the RPC runtime and/or the server stub, and an exception
is returned to the client (running under Windows NT).
If, using an Attribute Configuration File (same name as the
Interface Definition Language file but with a .ACF suffix)
you declare a parameter to hold fault or communication
errors, then this exception is returned to your client
application code as an error number. Your client code can
then check this, before checking the actual application
status, as in the following code fragment:
result = CommandExecute (handle,
&context,
(unsigned_char_t *)command,
&pid,
&message,
&errstat);
if (errstat == rpc_s_ok)
{
if (result)
{
Here, CommandExecute is the RPC call to the server,
errstat is the communications/fault status parameter,
and I check this for rpc_s_ok first of all. Using this
technique, you prevent server (or communication) errors
from causing your client to crash.
To achieve this, I inserted the following in the .ACF file:
[explicit_handle] interface command
{
.
.
CommandExecute ([comm_status,fault_status] cf_status);
.
.
}
If you do not use this technique, then the same exception
is actually raised in your client, so that your client
crashes instead of the server (even though the server
actually make the mistake).
I hope this is helpful.
- Cameron
|
| .1 has given a good diagnosis of a possible problem you're having. I just
want to point out that OpenVMS VAX V5.5-2 is the minimum supported version
for DCE for OpenVMS. You indicated that V5.5-1H4 is what is being run.
Now... I'm not certain of anything specific that would prevent this from
working, but if the information is correct, you're running in an
unsupported configuration and ANYTHING is suspect. It would also be
helpful in cases like this to provide the version of UCX or 3rd party
TCP/IP product in use. This can make a big difference as well.
Wayne Morrison
Project Leader
DCE for OpenVMS
|