TS/MP 2.5 Pathsend and Server Programming Manual

When the one-transaction-per-dialog model is used, the transaction 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 abort occurs. In either case, the requestor aborts the transaction
when it receives an error reply.
Correlating Messages With a Dialog
After a message with a “dialog begin” indication has been received, all messages received on
that open of $RECEIVE will pertain to that dialog until one of these occurs:
• The server terminates the dialog.
• A Pathsend dialog abort system message (system message -121) is received, indicating that
The dialog is aborted. To receive Pathsend dialog abort messages, the server must be
monitoring system messages of this type. For more information about Pathsend dialog abort
messages, see “Detecting an Aborted Dialog” later in this chapter.
• A path error (such as CPU down or network down) occurs on the link to the ACS subsystem
ROUT process.
Continuing a Dialog
To indicate that the dialog must continue, the server replies to a message in the dialog with an
error value of FECONTINUE (70).
Aborting a Dialog
The server can abort a dialog by replying to any message in the dialog with an error value of
FEEOF (1).
Terminating a Dialog
After the dialog has started, either the requestor or the server can abort it, but only the server can
end it. To end the dialog, the server replies to a message in the dialog with an error value of FEOK
(0).
Detecting an Aborted Dialog
When a dialog is aborted, either explicitly or by termination of the requestor, the server receives
a Pathsend dialog abort system message (system message -121), if the server is monitoring system
messages of this type. Context-sensitive Pathsend servers must ensure that Pathsend dialog abort
system messages are monitored on $RECEIVE. The Pathsend dialog abort system message is
described in the Guardian Procedure Errors and Messages Manual.
When a server receives a Pathsend dialog abort system message, the server calls
FILE_GETRECEIVEINFO_ to obtain the file number and process handle associated with the message.
The server can then use these parameters to identify the dialog. The server replies to the Pathsend
dialog abort system message with an error value of either FEOK (0) or FEEOF (1); these values
direct the ACS subsystem ROUT process to release the link for re-use.
If a processor or network failure occurs, it is possible to have a dialog abort but not receive a
Pathsend dialog abort message. Therefore, to monitor all aborted dialogs, your server must also
monitor CPU down, remote CPU down, and loss of communication with network node system
messages if it uses FILE_GETRECEIVEINFO_, or CLOSE system messages if it uses
CRE_Receive_Read_ or the COBOL85 or FORTRAN language. The server treats such messages
as dialog aborts.
Servers can monitor CPU down, remote CPU down, and loss of communication with network node
system messages by calling the Guardian procedures MONITORCPUS and MONITORNET, which
are described in the Guardian Programmer’s Guide.
72 Writing Pathway Servers