GDSX Manual

DEVICE^HANDLER Example, Design
Extended General Device Support (GDSX) Manual–134303
5-21
Testing Failure at a ^WRITEREAD
At the TACL terminal, enter:
> STATUS *, TERM
Record the new CPU and PIN values for the GDSX process:
primary-cpu,primary-pin backup-cpu,backup-pin
When $GDS was stopped, file-system error 210 was returned to $A1. The code then
executed by $A1 is shown in Example 5-6. A message is sent by way of the new
primary process to the OUT file requesting that data be reentered, because anything that
was entered at a prompt before a carriage return was entered was not transferred to the
IOP. Then, after a two-second delay, a new prompt is sent to the terminal, starting a new
WRITEREAD-WRITE transaction. Therefore, the DEVICE^HANDLER is designed so
that it does not retry a ^WRITEREAD following a takeover.
Fault-tolerance processing in the DEVICE^HANDLER is diagrammed in Figure 5-6.
The fault-tolerance code is included in the listing in Appendix B. Suppose that the
DEVICE^HANDLER was executing a ^WRITEREAD when the primary process failed.
The GDSX backup process then takes over, and TSCODE restarts the
DEVICE^HANDLER at the return from the call to ^CHECKPOINT(2), which in this
case is the TAKEOVER := TRUE statement.
TSCODE restarts at this point because whenever there is a call to the ^CHECKPOINT
function, TSCODE establishes a restart point in the calling task at the return from the
call, in a manner similar to a call to the Guardian procedure CHECKPOINT. If there
had been no ^CHECKPOINT call, the task would have been restarted from its main
entry point.
Example 5-6. Requester Code for Takeover at a ^WRITEREAD
ELSE IF (FERR = 210) THEN
BEGIN ! OUTFILE SWITCHED TO BACKUP, CONTINUE
WT^CT :=28;
S^MSG^BUF ':=' 8*[“ “] & [“PLEASE RE-ENTER DATA“];
CALL WRITE(MSG^FILE,MSG^BUF,WT^CT);
IF <> THEN
BEGIN ! CONTINUE ON GDSX SWITCHOVER
CALL FILEINFO(MSG^FILE,FERR);
IF (FERR <> 210) THEN CALL DEBUG;
END;
END