GDSX Manual

DEVICE^HANDLER Example, Design
Extended General Device Support (GDSX) Manual–134303
5-23
Testing Failure at a ^WRITE
In the event of a takeover, however, any memory pool buffer addresses that the task has
stored in its data stack are no longer valid. A task must recover its buffer images by
making calls on ^RECLAIMBUFFER. Thus, the statement CALL
^RECLAIMBUFFER (@e^rcv^buf , 10), which remaps rcv^buf from the buffer pool
(indicated by 0) is executed.
After a terminal buffer is allocated, the CASE statement determines that the operation
was a WRITEREAD. Then an IF statement, testing the value of take^over, causes the
code for normal processing of a WRITEREAD to be bypassed. The
DEVICE^HANDLER releases its buffers and returns to the beginning of its transaction
processing loop. The DEVICE^HANDLER does not retry the ^WRITEREAD, because
the requester is designed to start a new WRITEREAD-WRITE transaction if a takeover
occurs when the DEVICE^HANDLER is doing a ^WRITEREAD.
Testing Failure at a ^WRITE
Now you can continue the fault-tolerance processing exercise to observe how
checkpointing in the GDSX process can recover from a process failure during a WRITE
operation. First, PAUSE the Inspect terminal. Suppose that the terminal’s device name
is $TC2.
At the TACL terminal, bring the GDSX primary process under the control of Inspect by
entering:
> DEBUG primary-cpu, primary-pin, TERM $TC2
To make the source code visible under Inspect, in high-level Inspect at the Inspect
terminal, enter:
- SOURCE ON
- SCOPE #DEVICE^HANDLER
- SOURCE
Put a breakpoint at the CASE RQST^TYPE OF statement in DEVICE^HANDLER’s
main loop. Resume program execution.
At the application terminal, enter a short text string followed by a carriage return. This
forces the GDSX primary process to its breakpoint, which will be displayed on the
Inspect terminal.
At the Inspect terminal, display the value of rqst^type (it should be a 1), and check it
against the literals defined in DEVICE^HANDLER to confirm that the requester’s
operation is a WRITE.
Force a primary process failure by entering:
- STOP
At the application terminal, confirm that the transaction completes properly, and that
GDSX still functions as usual.
When the GDSX primary process was stopped, the requester received file-system error
210 on its WRITE and completed its transaction processing loop as if the WRITE had
been completed normally. The requester is designed to let the DEVICE^HANDLER
retry the WRITE.