TS/MP Pathsend and Server Programming Manual (H06.05+, J06.03+)

The SERVERCLASS_SEND_ procedure enables Pathsend requesters to send data to and receive
replies from a specified Pathway server class. This procedure communicates with the LINKMON
process or the ACS subsystem processes in the processor where the Pathsend requester is running,
passing information that enables the LINKMON process or the ACS subsystem processes to choose
a link to a server process. After a link to the server has been obtained, the requester’s data is sent
directly from the requester’s data space to the server.
Subsequent server-class send operations to the same server class might not be sent to the same
server process; therefore, the requester must provide all necessary context on each send.
When a server process replies to the request, the LINKMON process or the ACS subsystem processes
complete the server-class send operation. If you use waited I/O, the reply data is in the reply buffer
when the SERVERCLASS_SEND_ call is completed. If you use nowait I/O, you complete the I/O
operation with a call to the AWAITIOX procedure.
A Pathsend requester can use the SERVERCLASS_SEND_INFO_ procedure to get detailed information
about server-class send initiation and completion errors.
Programming for Failure Recovery
A Pathsend requester must provide a mechanism for failure recovery. It can do so in one or both
of these ways:
• By using TMF level recovery through the TMF subsystem
• By providing fault tolerance through process pairs and checkpointing
TMF level recovery is the recovery of the database to a consistent state through the use of the TMF
subsystem. When a failure occurs, the TMF subsystem allows the application to back out (abort)
the entire transaction, returning the contents of the database to the values it held when the transaction
was started. The application can then retry the transaction.
In general, TMF level recovery is recommended for use with Pathsend programs: this method is
easier and faster to program than process pairs, and it handles nonretryable 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 HP NonStop Transaction Management Facility (TMF)
Application Programmer’s Guide. The Guardian Programmer's Guide discusses process pairs and
checkpointing. The paragraphs below 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 these: 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.
Basic Pathsend Programming 53