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

1. Reads a message from $RECEIVE by using the $RECEIVE reading mechanism for the
programming language, such as a call to the Guardian READUPDATE or READUPDATEX
procedure.
2. Checks bits <12:13> of the dialog flags returned by the FILE_GETRECEIVEINFO_ or the
CRE_Receive_Read_ procedure. If the value in these bits is 1, the message is the first in a new
dialog. If the value is 2, the message is for an existing dialog.
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 language’s $RECEIVE writing mechanism, 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 its reply. Table 4
(page 72) 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 requester 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. Refer to accompanying
text for details.
Use of error values other than 1 (FEEOF) is not recommended. Any other error value causes the
LINKMON process or the ACS subsystem processes 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
re-created, thereby affecting system performance. It is recommended, therefore, that servers always
reply with FEEOF to abort a dialog. The server should return 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 requester 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 requester’s value
72 Writing Pathway Servers