GDSX Manual

Design and Development
Extended General Device Support (GDSX) Manual–134303
2-33
Takeover Processing
When the backup process receives the checkpoint message, any global data included is
copied to the same address in the backup. The checkpointing task’s stack image is
copied to an extended memory area of size specified by the TASKSIZE configuration
parameter. The backup copies the checkpointed portion of the TCB to the appropriate
location in the TCB pool. The task’s buffer images are copied to the TASKCPSIZE area
in extended memory.
User tasks would overwrite each other’s data if they were allowed to checkpoint memory
pool buffers directly across to corresponding addresses in memory pools for the backup
process. Suppose, for example:
1. Task 3 owns a buffer at address A and performs a type 2 checkpoint.
2. Task 3 deallocates the buffer at A.
3. Task 6 allocates a buffer at address A.
4. Task 6 performs a type 2 checkpoint.
If buffers were checkpointed directly, the data checkpointed by task 6 would have
overwritten the data checkpointed by task 3. Therefore, pool buffers are checkpointed to
a section of the backup process’s extended memory where each task has a separate,
TASKCPSIZE-sized area for checkpointing. Buffer images are copied, but to different
addresses, outside the memory pools.
Takeover Processing
If there is a takeover, any sync depth specified by external processes when GDSX is
opened has no effect. I/O operations of external requesters are not automatically
redirected to the backup GDSX process. Instead, GDSX emulates data communications
I/O processes: any outstanding requester I/O operation is terminated with file-system
error 210 (device ownership changed). For WRITEREADs and READs, no data is
returned to the requester. All I/O that the previously active tasks had outstanding is
canceled by TSCODE, and any semaphores that were held by those tasks (including the
checkpoint semaphore) are released.
Initializing Tasks
No matter what level of fault tolerance is supported by USCODE tasks, when the backup
takes over, the following occurs:
1. Those preconfigured tasks that were active in the primary but had not checkpointed
are queued for reinitialization. They will be restarted from their main entry point.
2. Those tasks that had checkpointed and did not own a semaphore (either the
checkpoint semaphore or a user-defined semaphore) at their last checkpoint have
their takeover flag set (tcb.statex.takeover^bit) and are placed on the ready list.
They will be restarted at the instruction following the last checkpoint.
3. Those tasks that owned a semaphore (either the checkpoint semaphore or a user-
defined semaphore) at their last checkpoint are placed on linked lists, one list for
each semaphore. They will be restarted at the instruction following the last
checkpoint.