OSF DCE Application Development Guide--Core Components

Topics in RPC Application Development
The comm_status attribute is useful only if the call to the operation has a specific
recovery action to perform for one or more communications failures; for example,
rpc_s_comm_failure or rpc_s_no_more_bindings. The comm_status attribute is
recommended only when the application knows that it is calling a remote operation. If
you expect communications to fail often because the server does not have enough
resources to execute the call, you can use this attribute to allow the call to be retried
several times. If you are using an implict or explicit binding, you can use the
comm_status attribute if you want to try another server because the operation cannot be
performed on the one you are currently using. You can also use an exception handler for
each of the two previous instances.
In general, the advantange of using comm_status if the recovery is local to the routine is
that the overhead is less. The disadvantage of using comm_status is that it results in
two different operation signatures. Distributed calls contain the comm_status attribute,
however; local calls do not. Also, if all of the recovery cannot be done locally (where
the call is made), there must be a way to pass the status to outer layers of code to process
it.
The fault_status attribute is useful only if the call to the operation has a specific
recovery action to perform for one or more server faults; for example, rpc_s_invalid_-
tag, rpc_s_fault_pipe_comm_error, rpc_s_fault_int_overflow,orrpc_s_fault_-
remote_no_memory. Use fault_status only when the application calls a remote
operation and wants different behavior than if it calls the same operation locally. If you
are requesting an operation on a large data set, you can use this attribute to trap rpc_s_-
fault_remote_no_memory and retry the operation to a different server, or you may
break your data set into two smaller sections. You can also handle the previous case
with exception handlers. The advantange of using fault_status if the recovery is local is
that the overhead is less. The disadvantage of fault_status is that the operation is
different between the local and distributed case. Also, if all of the recovery cannot be
done locally, there must be a way to pass the status to outer layers of code to process it.
16.2.5 Examples of Error Handling
The following subsections present two examples of error handling. The first example
assumes that the comm_status attribute is in use in the ACF. The second example
assumes that the comm_status attribute is not in use.
16.2.5.1 The Matrix Math Server Example
Assume that you have an existing local interface that provides matrix math operations.
Since it is local, errors such as floating-point overflow or divide by zero are returned to
the caller of a matrix operation as exceptions. It is likely that these exceptions are
caused by providing data to the operation in an improper form.
In this case, the exceptions are part of the interface, so fault_status changes the way the
application calls the matrix interface and probably is undesirable. Depending on the
124245 Tandem Computers Incorporated 16−9