GDSX Manual

Design and Development
Extended General Device Support (GDSX) Manual–134303
2-10
Overview of GDSX Processing
2. Calls the USER^INIT^CONFIG^PARAMS user exit.
3. Opens the $RECEIVE file for the GDSX process.
4. Calls the PROCESS^ASSIGNS user exit once for each ASSIGN command entered
from a TACL process before GDSX was started. If no such commands were
entered, this user exit is not called.
5. Calls the PROCESS^USER^PARAMS user exit once for each USERPARAM
defined in PARAM commands entered from a TACL process before GDSX was
started. If no such commands were entered, this user exit is not called.
6. Calls the USER^VERSION user exit.
7. Allocates memory for control blocks, memory pools, stack images, checkpointed
buffers, EMS log messages, and so on.
8. Initializes monitor and listener system tasks. Starts the listener task. If GDSX was
run as a process pair, a backup task is started.
9. Calls the USER^INITIALIZE user exit.
10. Starts the monitor task.
11. If GDSX is run as a process pair, the backup task starts the backup process, and in
the backup process TSCODE calls user exits in the following order:
a. USER^INIT^CONFIG^PARAMS
b. USER^VERSION
c. USER^INITIALIZE
12. If GDSX is run as a process pair, in the primary process TSCODE checkpoints data
to the backup, then calls USER^BACKUP.
When GDSX receives an open message for a file from an external process (for example,
a TCP dynamically opening a terminal), a user task is created. The listener task creates
an open system task to process the external open, and the task opens the requested
subdevice. Any errors encountered during the open are passed back to the external
process. If the open proceeds without error, the open task is relaunched as a user task
(either a DEVICE^HANDLER task or a LINE^HANDLER task).
User tasks never exit back to the procedure that first called them. Instead, they execute
in a perpetual loop, and when they require TSCODE services, they call an appropriate
TSCODE service routine (see Section 8). These service routines provide facilities
similar to those provided by the operating system, yet allow TSCODE to keep track of
each internal I/O operation and to ensure that every I/O operation is handled correctly at
completion time.
When a user task calls one of these routines, control is transferred to the TSCODE
kernel. TSCODE either passes the procedure call on to the operating system or
performs the requested function internally, returning immediately to the user task.
In other cases the routine has to wait for some external event (for example, the
completion of I/O). The service routine then transfers control to the kernel, which