GDSX (Extended General Device Support) Manual

Design and Development
Extended General Device Support (GDSX) Manual—529931-001
2-100
The LINE^HANDLER Procedure
First, a call is made to ^CHECKPOINT(1) to checkpoint the task stack. This is the only
call to ^CHECKPOINT in the LINE^HANDLER and merely serves to speed up takeover
after a failure.
Next LINE^HANDLER^BODY posts ^READUPDATE operations on $RECEIVE and
IN^QUEUE^FILE^NUM and calls the subprocedure LINE^STATE^MACHINE to start
the line. Although the parameter IOCB does not contain a valid IOCB address, the
state machine does not expect any IOCB to be associated with this call and does not
reference the parameter.
LINE^HANDLER^BODY then enters its main processing loop. The first step in this
loop is a CASE statement based on the value returned from WAIT^EVENT. This is the
only call to WAIT^EVENT in LINE^HANDLER. The events waited on are DISP^CAN,
DISP^IMSG, DISP^IOC, and DISP^ITC. In addition, if no event occurs in 10 seconds,
the wait will time out.
If a timeout occurs and the line is in a closed state, the state machine is called in an
attempt to restart the line. The error handling in this sample code is rather crude. If an
error cannot be dumped on a particular terminal, the line goes into a closed state, with
a restart attempted after 10 seconds.
If a cancel event occurs, a call is made to the subprocedure CANCEL^REQUESTS
(see the following paragraphs).
If an ITC event occurs, the IOCB describing the request is obtained by a call on
^LISTEN and passed to the subprocedure QUEUE^REQUEST. QUEUE^REQUEST
may handle the IOCB immediately or it may queue the request for later processing by
LINE^STATE^MACHINE (see the following paragraphs).
If an I/O completion event occurs, it must be a completion on the LINE file as this is the
only file other than $RECEIVE and IN^QUEUE^FILE^NUM that the LINE^HANDLER
deals with. Consequently, the IOCB describing the result of the I/O is obtained by
calling ^LISTEN and is passed to the state machine for processing.
The last step in the main processing loop is to call LINE^STATE^MACHINE if the line
is idle so that it can process any new requests that may have been queued as a result
of the last event.
As mentioned previously, initial request processing is done in QUEUE^REQUEST.
This subprocedure first does minimal tests to determine if the request’s openid is valid.
If it is not, the LINE^HANDLER suspends itself with fault 999 by invoking the define
“TRAP.” Otherwise, the procedure enters a CASE statement based on the operation
type of the passed IOCB. CONTROL and SETMODE requests are handled
immediately by calls on the subprocedures CONTROL^REQUEST and
SETMODE^REQUEST respectively. These subprocedures do not simulate the
behavior of Guardian CONTROL and SETMODE operations, but rather end the
request with no error if the request is likely for a terminal, or FEINVALOP if not.
For WRITE, READ and WRITEREAD requests, a test is made to see if there is already
an active request on the terminal. If so, the request is immediately completed with
error FETOOMANY. Otherwise, dcb.iocbaddr is set to the address of the current