OSF DCE Application Development Guide--Core Components

OSF DCE Application Development Guide—Core Components
environment, finding a server may not be difficult (if the network is relatively stable and
has enough resources), and adding comm_status serves only to introduce differences
between the local and distributed applications.
If a decision as to what action to take is based upon a communications failure, then you
may try to add the conditional code comm_status requires. Otherwise, using
auto_handle allows an attempt on each available server. If no server is available, the
application terminates because it cannot proceed. You can add an exception handler to
the main program to report the error in a user-friendly manner.
16.2.5.2 The Stock Quote Application Example
Assume that you have an application that reads from stock quote servers and displays
graphs of the data. Since you do not expect to get server failures because it is a
commercial-quality server, you are not interested in writing code to handle values
returned from fault_status. If high availability and robustness is important, you may
have a list of recovery plans to make sure a stock analyst can get the necessary
information as quickly as possible. For example:
retry_count = 10;
do {
query_stock_quote(h, ...,&st);
switch (st) /* st parameter can be used because */
{ /* [comm_status] is in the ACF */
case rpc_s_ok:
break;
case rpc_s_comm_failure:
retry_count -= 1;
break;
case rpc_s_network_unreachable:
h = some_other_handle;
break;
case
.
.
.
default:
retry_count -= 1;
}
}
while ((st == rpc_s_ok) || (retry_count <= 0))
If this is not a critical application, you may only report that the server is currently
unavailable. Depending upon the design of the application, there may be several places
to put the exception handler to report the failure but continue processing. For example:
TRY
update_a_quote(...);
16 − 10 Tandem Computers Incorporated 124245