TS/MP Pathsend and Server Programming Manual (G06.24+, H06.03+)

Writing Pathsend Requesters
NonStop TS/MP Pathsend and Server Programming Manual–132500
3-4
Programming for Failure Recovery
requests more smoothly. However, because the TMF subsystem guarantees only the
consistency of the database and not fault tolerance for other operations (such as
messages sent over data communications lines), your application might need to use
process pairs along with TMF level recovery.
TMF programming is described in the NonStop TM/MP Application Programmer’s
Guide. The Guardian Programmer's Guide discusses process pairs and checkpointing.
The following paragraphs provide information specific to the use of these features in a
Pathsend program.
Server Process Failures
A server process can fail for reasons that include the following: the server process calls
ABEND, a processor fails, or someone stops the process.
If the server process fails while there are outstanding SERVERCLASS_SEND_,
SERVERCLASS_DIALOG_BEGIN_, or SERVERCLASS_DIALOG_SEND_ calls to
it, error 904 (FEScServerLinkConnect) is returned to the requester. If the server-class
send operation is protected by a TMF transaction, the requester should abort the
transaction and reissue the request or the dialog. If the request is repeatable, the
requester should just retry the request. Context-free requesters need only retry the call to
SERVERCLASS_SEND_, but context-sensitive requesters must retry the entire dialog.
If the server process fails while there are no outstanding SERVERCLASS_SEND_,
SERVERCLASS_DIALOG_BEGIN_, or SERVERCLASS_DIALOG_SEND_ calls to it
but a dialog is in progress, the dialog is aborted and the requester receives error 929
(FEScDialogAborted) on its next call to SERVERCLASS_DIALOG_SEND_.
If the server process is in transaction mode and fails, the TMF transaction is
automatically aborted. This treatment of the TMF transaction is a feature of the TMF
subsystem.
LINKMON Limit Errors
In some cases, you can recover from a LINKMON limit error by retrying the Pathsend
procedure call. Whether a retry will work depends on the design and operating
environment of your application, including the configuration of static and dynamic links.
Static links between a LINKMON process and a PATHMON process generally persist
for some time, depending on the application and the system workload. Dynamic links
and server classes come and go more frequently, again depending on the application and
the system workload. The number of concurrent server-class send operations is very
dynamic.
Therefore, it might be appropriate to retry a call to SERVERCLASS_SEND_,
SERVERCLASS_DIALOG_BEGIN_, or SERVERCLASS_DIALOG_SEND_ (after a
short wait) if the concurrent calls limit is exceeded. Conversely, it might not be
appropriate to retry a call if the limit for the maximum number of PATHMON processes
is exceeded.
For more information about PATHMON configuration and performance, refer to the
NonStop TS/MP System Management Manual.