GDSX Manual

Design and Development
Extended General Device Support (GDSX) Manual–134303
2-88
I/O Involving $RECEIVE
completed I/O list with header at tcb.qh. The IOCB is also deleted from the FCB list
and its state is changed to 5 (pending).
•
At some time, the task initiating the I/O calls either ^AWAITIO or WAIT^EVENT.
Assume that ^AWAITIO is called. Then TSCODE first determines if an I/O
matching the file parameter has already completed by calling ^LISTEN. ^LISTEN
scans the task’s completed I/O list looking for an appropriate IOCB. (Notice that
^LISTEN differs from the Guardian procedure LISTEN in that it is called to check
for all I/O completions.)
If ^LISTEN finds that the I/O is not complete, ^AWAITIO calls WAIT^EVENT and
the task is suspended. The events waited upon may include a combination of:
°
E^IOC: if the task has an outstanding I/O on files other than $RECEIVE
and the file number passed to ^AWAITIO is not equal to 0.
°
E^IMSG: if the task has a ^READUPDATE posted on $RECEIVE and the
file number passed to ^AWAITIO is less than or equal to 0.
When the task is awakened, TSCODE again calls ^LISTEN. This process is
repeated until ^LISTEN finds a completed I/O or until a timeout occurs. The first
call to WAIT^EVENT uses the user’s timeout parameter to ^AWAITIO. Subsequent
calls pass -2d.
•
Assuming that the I/O completes, ^LISTEN returns the address of the associated
IOCB. If the task passed a tag parameter, ^AWAITIO stores iocb.histag into the tag.
In this way, the user is returned the I/O tag (tag) that was supplied to the original
call. Similarly, the buffer address (iocb.bufaddr) and count transferred (iocb.iocnt)
may be returned to the user. The IOCB, having now fulfilled its role, is returned to
the available IOCB list.
The available IOCB list operates in FIFO fashion if DEBUG^FLAGS is nonzero and
IOCBs are cleared when they are allocated rather than when they are deallocated.
Thus the available IOCB list provides a history of completed I/O operations in the
order in which those operations were passed back to the initiating task. While this
list can be a handy debugging aid, it does tend to increase the memory requirements
of GDSX when any debug flags are set.
•
If the task initiating the I/O completes it with a call to WAIT^EVENT instead of
^AWAITIO, TSCODE determines whether the masked events have occurred by
scanning the task’s completed I/O list. TSCODE then causes an appropriate event
(E^IOC or E^IMSG, for example) for the calling task. The task then calls ^LISTEN
to obtain the address of the IOCB. (See the description of the LINE^HANDLER in
Section 7 for details on the use of WAIT^EVENT and ^LISTEN.)
I/O Involving $RECEIVE
For task I/O involving $RECEIVE, GDSX uses the IOCB and TCB tables described
previously and an additional table, the receive control block (RCB) table. An RCB is
associated with each GDSX opener.
When the TSCODE dispatcher is passed a new $RECEIVE request from Guardian
AWAITIO, it calls RECEIVEINFO (or FILE_GETRECEIVEINFO_) to obtain the