TS/MP 2.5 Pathsend and Server Programming Manual

3. Checks the value of bit 14 of the dialog flags if the TMF subsystem is being used, the server
is enforcing transaction commit protection during the dialog, and the value of bits <12:13>
of the dialog flags is 1 (first message in a new dialog). If the value of bit 14 is 1, aborts the
dialog by replying with FEEOF (1).
4. Processes the message and performs the requested services.
5. Issues a reply by using the $RECEIVE writing mechanism of the language, such as a call to
the REPLY or REPLYX procedure.
Dialog Control
The server controls the dialog by means of a file-system error code it returns in a reply. Table 4
(page 71) shows the effect of the reply error codes.
Table 4 Meaning of Error Codes Returned by Context-Sensitive Server in Reply
MeaningError Returned by Server
Allow the dialog to continue.70 (FEContinue)
End the dialog. After the server replies with this code, the associated TMF transaction (if
any) will be allowed to commit, and the server will receive no further sends associated with
this dialog.
0 (FEOK)
Abort the dialog. After the server replies with this code, there will be no further sends
associated with this dialog.
1 (FEEOF)
Abort the dialog. After the server replies with this code, there will be no further sends
associated with this dialog.
The requestor receives this error as the file-system error of the FEScServerLinkConnect error.
Any other value
1
1
Use of other error values is not recommended because of their effect on the link to the server. see accompanying text
for details.
Use of error values other than 1 (FEEOF) is not recommended. Any other error value causes the
ACS subsystem ROUT process to close the link to the server and return it to the PATHMON process.
If there are no other links to that server process, the server process is deleted; then, if that process
is later needed to service subsequent requests, it will need to be recreated, thereby affecting system
performance. It is recommended, therefore, that servers always reply with FEEOF to abort a dialog.
The server returns any additional information in the message itself rather than in the reply code.
Whether the current TMF transaction, if any, is also aborted when an error value is returned
depends on the setting of dialog flag bit 14 in the call to SERVERCLASS_DIALOG_BEGIN_, as
explained in this subsection.
Use of TMF Transactions With Dialogs
A context-sensitive server participates in a TMF transaction in the same manner as context-free
servers would do. The server inherits the transaction identifier of the received message. The server
can abort the transaction when it has the transaction identifier.
When the server calls FILE_GETRECEIVEINFO_ or CRE_Receive_Read_ and detects the first message
in a dialog, it can also check the dialog flags used to initiate the dialog. If you want to enforce
transaction commit protection during the dialog—that is, ensure that the requestor cannot call
ENDTRANSACTION until the server has ended the dialog—you can code your server to verify
that bit 14 of the dialog flags is 0 whenever the value of bits <12:13> is 1. If the value of the
requestor for bit 14 is 1, the server can abort the dialog by replying to the message with an error
value of FEEOF (1).
When the one-transaction-per-dialog model is used (when bit 14 of the dialog flags is equal to 0),
the server must end the dialog by replying FEOK to a message before the requestor can commit
the associated TMF transaction. To allow requestors to ask the server to end the dialog, you can
program your server to recognize a user-defined “end request” command.
Writing Context-Sensitive Servers 71