Guardian Programmer's Guide

Communicating With Processes
Guardian Programmer’s Guide — 421922-014
6 - 24
Checking for Cancellation Messages
These methods are described in the following paragraphs. Both methods involve use
of the message tag. The message tag is generally used to distinguish among multiple
messages when the server chooses to concurrently process several messages (see
Handling Multiple Messages Concurrently earlier in this section). Here, the message
tag is used to identify the canceled message.
You use the FILE_GETRECEIVEINFO_ procedure to obtain the message tag of the
last message read from $RECEIVE. This procedure returns information about the
message just read.
STRUCT .INFORMATION(ZSYS^DDL^RECEIVEINFORMATION^DEF);
INT TAG;
.
.
CALL READUPDATEX(RECV^NUM,SBUFFER,RCOUNT);
IF <> THEN ...
CALL FILE_GETRECEIVEINFO_(INFORMATION);
TAG := INFORMATION.Z^MESSAGETAG;
Checking for Cancellation Messages
When a requester sends a message to a server and that message is later canceled
(for any of the reasons stated earlier), the operating system sends a system message
to the server to inform the server that the message has been canceled. The system
message is called a cancellation message and is made up of two words: the first word
contains the message type (-38), and the second word contains the message tag of
the canceled message.
The effect of the message and the way the server process must respond are
influenced by when the cancellation message arrives with respect to the processing of
the request to be canceled:
•
If the request has not yet been read by the server process, the operating system
removes the request from $RECEIVE and the server never receives the
cancellation message.
•
If the request is currently being processed by the server, the cancellation message
will be delivered. The server should stop processing the request. A REPLYX call
is required. There is no point checking for a cancellation message immediately
after reading the request because the requester will usually not issue a
cancellation message right away.
•
If the server has already replied to the request, the server will not receive the
cancellation message.
•
The cancellation message is not delivered if the server has read but not replied to
the number of messages specified in the receive-depth parameter of the
FILE_OPEN_ call.
If you check for cancellation messages, you should do so at points during message
processing only if the processing takes a long time.