GDSX Manual

Design and Development
Extended General Device Support (GDSX) Manual–134303
2-95
The LINE^HANDLER Procedure
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 request’s
IOCB. Next, a test is made to determine if this is a WRITE (or WRITEREAD) request.
If it is a WRITE, a call is made to INSERT^WRITE^QUEUE; otherwise,
READ^DEVICE is called.
INSERT^WRITE^QUEUE determines whether the write queue is empty. If the queue is
empty, INSERT^WRITE^QUEUE calls CHECK^HALT^POLL.
CHECK^HALT^POLL maintains a flag named polled^halting in LINE^HANDLER’s
locals. If poll^halting is false and the line is currently polling, a call to HALTPOLL is
made, and poll^halting is set to one. This is necessary because continuous polling is
used on the multipoint line. The only purpose for passing a DCB to
CHECK^HALT^POLL is to be able to trace the select index of the subdevice that
necessitated stopping polling. The design strategy is to favor WRITE operations over
READs so that if there are any DCBs in the write queue, no polling is done (the poll
may be halting, however). Next, the DCB for the current request is linked into the
WRITE^QUEUE.