GDSX Manual

Design and Development
Extended General Device Support (GDSX) Manual–134303
2-29
Fault-Tolerance Processing in GDSX Initialization
•
Starts the monitor task.
•
Attempts to create a backup process. The backup task calls PROCESS_CREATE_
to create a backup process.
After a successful PROCESS_CREATE_ call, brother (the backup process) calls
USER^INIT^CONFIG^PARAMS and opens $RECEIVE. (The processing by brother
follows the same general sequence described for the primary process in "Overview of
GDSX Processing" on page 2-9.)
Then the backup task opens brother and sends it a type -32768 system message. This
message contains the startup message data received by the primary process, including
TACL ASSIGN values and configuration parameters set by TACL PARAM commands
that brother requires for data space initialization.
Brother then calls the USER^VERSION user exit.
The backup task next closes brother, signaling that brother should proceed with data
space initialization.
Having initialized its data space, brother does the following:
•
Determines that it is in fact the backup.
•
Sets the global variable backup^process^flag to 1.
•
Bypasses the remainder of normal initialization (such as opening the log file) and
starts up the monitor task.
•
Calls the USER^INITIALIZE user exit. The monitor then creates the listener task
and backup task.
•
Idles in the listener task’s CHECKMONITOR procedure.
In the meantime, the backup task in the primary process has reopened brother. This
open is assigned to the backup process’s listener task (that is, any messages from the
primary will be handled by the backup’s listener). The backup task in the primary next
sets the global variable nonstop to one, signaling all other tasks that brother is up and
running and that checkpointing of significant events is required. The backup task then
proceeds to bring brother up-to-date. (This process is similar to that involved in reviving
a mirrored volume.) The backup task makes a pass through the primary’s data
structures, including all the control blocks, checkpointing them to the backup. When the
backup task has completed its work, it sets the global variable backup^process^flag to
one and checkpoints it to brother. This signals brother that it is now a consistent backup
and is capable of takeover if necessary. The backup task in the primary GDSX process
then calls USER^BACKUP, giving users the opportunity to checkpoint their own global
data (declared in a named or private global data block).
An example of USER^BACKUP that checkpoints data input at a terminal is given in
"USER^BACKUP" on page 9-9. In the example, obtaining the checkpoint semaphore is
not necessary, because TSCODE is not checkpointing and no user task exists. Also,
calling DO^CP is not necessary, because after exiting USER^BACKUP a DO^CP is
done automatically by the backup task.
The USER^BACKUP procedure is only called once in the lifecycle of a GDSX process.