GDSX (Extended General Device Support) Manual

Service Routines
Extended General Device Support (GDSX) Manual529931-001
8-62
^READUPDATE[X]
^READUPDATE[X] and ^CANCEL are the only two operations that a
LINE^HANDLER may call against the pseudo-$RECEIVE file.
^REPLY[X] should be called after ^READUPDATE[X] to release the IOCB used by
^READUPDATE[X].
To minimize buffer requirements, ^READUPDATE[X] operations can be posted on
the pseudo-$RECEIVE without specifying a buffer address or size. For example:
CALL ^READUPDATE(0);
If ^READUPDATE is called, TSCODE attempts to obtain the buffer in the local
buffer pool. If ^READUPDATEX is called, TSCODE attempts to obtain the buffer in
the extended buffer pool. When a buffer is obtained, its address is stored in
iocb.bufaddr[x], and data is moved from the GDSX $RECEIVE buffer to the buffer
addressed by iocb.bufaddr[x]. (Unlike Guardian I/O handling, TSCODE can modify
the buffer at any point after initiation of the I/O, rather than only at the time the I/O
is completed.) The size of this buffer will be the greater of the pseudo-$RECEIVE
message size and the maximum reply size for the request.
If TSCODE receives a -22 system message (TIME SIGNAL) for the task calling
^READUPDATE[X], the buffer is automatically deallocated by TSCODE. In this
case only, USCODE does not have to deallocate the buffer allocated by TSCODE.
If ^AWAITIO[X] is called after the call to ^READUPDATE[X], TSCODE passes the
address of the buffer back in the buffer buffer-addr parameter to ^AWAITIO[X]. If
WAIT^EVENT and ^LISTEN are called after the call to ^READUPDATE[X],
TSCODE passes the address of the buffer in iocb.bufaddr[x].
Except for the case of a -22 system message, all buffers received by a
^READUPDATE on file 0 must eventually be released by a call to
PUTLOCALPOOL with the pool parameter equal to 0 by the task that completes
the I/O. Buffers received by a ^READUPDATEX on file 0 must eventually be
released by a call to PUTEXTPOOL with the pool parameter equal to 10 by the
task that completes the I/O.
When a ^READUPDATE[X] on the pseudo-$RECEIVE that was initiated into a
preallocated buffer (CALL ^READUPDATE[X] (0, BUF, ...)) is subsequently
canceled by ^CANCEL(0), an incoming request may already be in the buffer before
^CANCEL is called. In this instance, TSCODE attempts to obtain space in its
extended data segment and move the request data into that space. If space
cannot be obtained, ^CANCEL replies to the request with FENOBUFSPACE (31).
Internally generated $RECEIVE messages, such as the -64 system message,
cause ^CANCEL to set CCL. A subsequent call to ^FILEINFO(0,ERR) returns
FENOBUFSPACE. In all cases, the task’s READUPDATE[X] on $RECEIVE is
canceled.