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

To participate in a dialog with a context-sensitive Pathway requester, a server must perform
additional tasks besides those required of all servers. These additional tasks are described under
“Writing Context-Sensitive Servers” (page 70) in Section 4.
Using Context-Sensitive Requesters With Context-Free Servers
Context-sensitive requesters can perform single-send dialogs with Pathway servers that are coded
to be context-free. However, if these servers check for system messages and they use the Common
Run-Time Environment (CRE), they must be modified to recognize and respond to Pathsend dialog
abort system messages. Section 4, “Writing Context-Sensitive Servers” (page 70), describes how
to code servers to handle these system messages.
Resource Utilization
On a requester’s first SERVERCLASS_DIALOG_BEGIN_ call, an extended segment is added to the
requester’s segment space for use as a workspace. This segment can be up to 64 KB in size. It is
deallocated when the requester process is terminated.
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 HP NonStop Transaction
Management Facility (TMF) 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.
Context-Sensitive Pathsend Programming 59