GDSX Manual

LINE^HANDLER Example, Design
Extended General Device Support (GDSX) Manual–134303
7-8
Transaction Flow
queue referenced by the variable in^queue^file^num, so that another intertask message
can be picked up from the DEVICE^HANDLER task.
When the ^WRITEREAD completes, WAIT^EVENT detects the completion (E^IOC).
The task then calls ^LISTEN to get a pointer to the LINE IOCB (line^iocb, allocated by
TSCODE after the ^WRITEREAD is initiated) containing information about the
completion. Relevant fields in the line^iocb, including the text string input by the user at
the prompt, are transferred to the original dh^iocb, and the task then calls
NOTIFY^IO^COMPLETION, which sends a message to the DEVICE^HANDLER task
that sent the request, notifying it of the completion. (This message looks like a standard
Guardian I/O completion to the DEVICE^HANDLER task.)
Then the LINE^HANDLER task calls DEALLOCATEIOCB to release the LINE object
IOCB that was allocated by TSCODE. Even though TSCODE allocates the LINE IOCB
, TSCODE depends on the LINE^HANDLER task to deallocate it, because only the
LINE^HANDLER task can determine when the information in the line^iocb is no longer
useful.
The DEVICE^HANDLER task passes the response back to the requester application,
which reverses the string and sends a WRITE request to the terminal through GDSE.
TSCODE passes the request to the same DEVICE^HANDLER task as before, and the
task does datastream conversion on the string and then issues a ^WRITE to the terminal
file number.
Once again TSCODE intercepts the request, determines that the terminal file number is
an ITC file number, and sends the request to the ITC file for the corresponding
LINE^HANDLER task, which detects it as an intertask message (E^ITC) when it calls
WAIT^EVENT. Then the task calls ^LISTEN to get the address of the IOCB for the
message (@dh^iocb := ^LISTEN (0, 0, 1)).
When data is picked up from the IOCB, it is determined that the operation is a ^WRITE,
and a nowait ^WRITE (the reversed string) is immediately sent to the terminal. The
^WRITE may be sent because requester design ensures that a completed WRITEREAD
of the string input at the prompt for the same thread preceded the ^WRITE; and because
after a WRITEREAD to the terminal has been initiated but before the transaction has
been completed, the LINE^HANDLER queues all I/O (^WRITEREADs starting other
threads) picked up with WAIT^EVENT until a ^WRITE (assumed to be for the same
thread) is received.
Once a thread displays its prompt at the terminal, it keeps control of the terminal until its
transaction is completed with the display of a reversed string. A ^READUPDATE is
posted on the queue assigned in the variable in^queue^file^num, so that another
intertask message can be picked up from the DEVICE^HANDLER task.
When the ^WRITE completes, WAIT^EVENT detects the completion (E^IOC). The
task then calls ^LISTEN to get a pointer to the LINE IOCB (line^iocb, allocated by
TSCODE after the ^WRITE is initiated) containing information about the completion.
The relevant error code in the LINE IOCB is transferred to the original dh^iocb, and the
task then calls NOTIFY^IO^COMPLETION, which sends a message to the
DEVICE^HANDLER task that sent the request, notifying it of the completion.
Then the pointer to the transaction’s ^WRITEREAD IOCB is taken off the queue, and if
there is another thread’s ^WRITEREAD on the queue, it is sent to the LINE file. The