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

Writing Pathsend Requesters
NonStop TS/MP Pathsend and Server Programming Manual–132500
3-9
Programming for Failure Recovery
Programming for Failure Recovery
The SERVERCLASS_DIALOG_BEGIN_ procedure allows two types of TMF
protection for dialogs:
•
The one-transaction-per-dialog model
•
The any-transaction-per-dialog model
You use bit 14 of the flags parameter in the SERVERCLASS_DIALOG_BEGIN_
procedure call to select which model will be used.
A value of 0 for bit 14 of flags (the default) selects the one-transaction-per-dialog
model. In this model, the dialog records the transaction identifier that is current at the
time of the SERVERCLASS_DIALOG_BEGIN_ call. Subsequent Pathsend calls for
this dialog must use this transaction identifier, or the calls will fail; that is, the current
transaction at the time of all Pathsend calls for the dialog must be the same as when the
dialog was started.
With the one-transaction-per-dialog model, the transaction cannot commit—that is, calls
to ENDTRANSACTION will fail—until the server ends (not aborts) the dialog and the
requester calls SERVERCLASS_DIALOG_END_. In other words, when bit 14 of
flags is set to 0, the TMF subsystem treats a dialog like an I/O operation: the
ENDTRANSACTION operation fails until the dialog has finished. The same restriction
applies to nested servers: if a server receives a message in a dialog and then initiates a
dialog with another server, it must complete the entire initiated dialog before replying to
the message from the received dialog.
A value of 1 for bit 14 of flags selects the any-transaction-per-dialog model. In this
model, all server-class send operations within the dialog will contain the transaction
identifier that is current at the time of the send, and there are no restrictions on
ENDTRANSACTION other than those associated with calls to the WRITEREAD
procedure (as described in the NonStop TM/MP Application Programmer’s Guide).
When the one-transaction-per-dialog model is used, the dialog must be ended rather than
aborted for the transaction to be completed successfully. The requester can ask the server
to end the dialog by specifying a user-defined END REQUEST command that is
recognized by the server.
If the dialog is aborted, the requester receives error 233, FEScError, and
SERVERCLASS_SEND_INFO_ returns Pathsend error 929, FEScDialogAborted.
The file-system error returned by SERVERCLASS_SEND_INFO_ provides information
about the reason for the abort. If the server explicitly aborts the dialog, the file-system
error is FEEOF (1).
If the server abends and the dialog is not in an ended state, the dialog is aborted, and the
requester receives error 233, FEScError, and SERVERCLASS_SEND_INFO_ returns
Pathsend error 929, FEScDialogAborted.
When the one-transaction-per-dialog model is used, the current TMF transaction, if any,
is automatically aborted when the server returns an error value (FEEOF, or any other
value besides FEOK or FEContinue) in the reply. When the any-transaction-per-dialog
model is used (when bit 14 of the dialog flags is equal to 1), no automatic transaction