GDSX (Extended General Device Support) Manual

Design and Development
Extended General Device Support (GDSX) Manual—529931-001
2-28
Pool Checking
extended memory where each task has a separate, TASKCPSIZE-sized area for
checkpointing. Buffer images are copied, but to different addresses. Therefore, in the
event of a takeover, any memory pool buffer addresses that the task has stored in its
data stack are no longer valid.
A task recovers its buffer images via calls on ^RECLAIMBUFFER. This procedure is
passed (by reference) the word pointer to the data as it was allocated in the primary.
The task’s last checkpoint block in the (former) backup’s extended memory is searched
for an address match. When one is found, space in the specified buffer pool is
allocated and the data image is copied. Finally, the word pointer in the task’s stack is
updated to point to the new location of the data. See the description of
^RECLAIMBUFFER on page 8-64 for more information.
Pool Checking
If the poolcheck^flag (see the DEBUGFLAGS configuration parameter later in this
section) is set, each time a task is dispatched, TSCODE will check the buffer pool,
message pool, extended buffer pool, and extended message pool for corruption. If
corruption is detected, GDSX stops with abend error 230 or 231.
The poolcheck^flag can be set when debugging a program and turned off during
production to allow GDSX to run more efficiently.
Bounds^checking of the DEBUGFLAGS configuration parameter is used to indicate
whether TSCODE is to do bounds checking on buffers used during USCODE service
routine (pseudo procedure and utility procedure) calls. If this bit is set to 1, TSCODE
ensures that all buffers used for I/O are in global or extended memory, not in the
swappable stack. If this bit is set to 0, TSCODE does not check the location of the
buffers used. The default setting for this flag is 0. See also the description of
CHECK^BUFFER^BOUNDS on page 8-17.
Fault Tolerance
You can create different levels of fault tolerance by the use of process pairs and
TSCODE-supported checkpointing procedures. GDSX tasks cannot use normal
Guardian checkpointing. Each user task within a GDSX process runs with one of three
possible levels of fault tolerance, depending on the checkpointing done within the task.
Level 0 Fault Tolerance
If GDSX is run as a process pair, TSCODE creates a backup task (task 3) and a GDSX
backup process. Whether user tasks do any checkpointing, the backup task
checkpoints to the backup GDSX process the following items:
Caution. TSCODE does not support the checkpoint facilities for dynamic tasks (those that are
not preconfigured) unless the DYNAMIC configuration parameter is set on. See DYNAMIC on
page 2-58.