GDSX Manual

Overview of GDSX
Extended General Device Support (GDSX) Manual134303
1-4
TSCODE Components
Two of the user exits are called the DEVICE^HANDLER and the LINE^HANDLER.
USCODE is typically written in TAL, compiled separately, and bound with TSCODE to
produce a functional GDSX front-end process. See Section 9 for a description of all the
user exits.
TSCODE Components
This subsection describes the functional components provided within TSCODE.
Multithreading Functions
GDSX is a nonprivileged, multithreaded Guardian process that builds and manages tasks
within itself in a manner similar to that of an operating system. A GDSX task is an
independent job entity running within GDSX to perform a specific function. While only
one task can actually be executing at any given time, TSCODE coordinates the
processing of many simultaneously active tasks. TSCODE also picks up all system
messages and I/O requests from $RECEIVE, and wakes up and executes the appropriate
active task to process messages and requests.
A task is a running instance of either a TSCODE procedure or a USCODE procedure. A
TSCODE task is called a system task, and a USCODE task is called a user task. A task
has its own data stack, calls TSCODE procedures, and usually executes in a infinite
loop. Generally, a user task manages exactly one terminal, line, or process.
Fault-Tolerance Facilities
Fault tolerance is achieved 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.
If GDSX is run as a process pair, TSCODE creates a backup task and a GDSX backup
process. Without any user checkpointing, the backup task automatically checkpoints to
the backup GDSX process the initial values for all globals, the changing values for
control block variables, and the changing state of each configured task. The backup
process monitors the status of the primary GDSX process and takes over in case of
primary process failure, restarting from the beginning the user tasks that were active at
the time of failure and were doing no checkpointing. This is the default level of fault
tolerance.
TSCODE supports two additional levels of fault tolerance, depending on the type of
checkpointing done by a user task. If a task does type 1 checkpointing, its stack images
and task control block are copied to the backup process. After a takeover, such a task is
restarted at the instruction following the last type 1 checkpoint call. If a task does type 2
checkpointing, its stack images, task control block, and allocated memory pool buffers
are copied to the backup process. After a takeover, such a task is restarted at the
instruction following the last type 2 checkpoint call, and all its memory pool data is
preserved.