Guardian Programmer's Guide

Introduction to Guardian Programming
Guardian Programmer’s Guide — 421922-014
1 - 10
The Requester/Server Application Model
symbolic command-line debugger used for debugging TNS/E native process and
snapshots on HP TNS/E systems.
Certain critical error conditions occurring during process execution prevent normal
process execution. They are mostly unrecoverable. In TNS processes, these errors
cause traps. In native processes, these errors cause the process to receive a signal.
(Refer to TNS/E Program Execution Modes and TNS/R Program Execution Modes,
later in this section, for descriptions of native processes and TNS processes.) Traps
and signals are handled by trap handlers and signal handlers, respectively.
When a trap occurs in a TNS process, the default action is for the process to enter
Debug (or the Inspect debugger can be explicitly specified for a process). If you prefer
to write your own trap handler, you can call the ARMTRAP procedure to install your
handler. Your trap handler is subsequently notified of the particular trap condition.
When a native process receives a signal, the default action is for the process to
abnormally terminate. If you prefer to write your own signal handler, you can call the
SIGACTION_INIT procedure to install your handler. Your signal handler is
subsequently executed when the process receives a signal.
Section 25, Debugging, Trap Handling, and Signal Handling, describes the debugging,
trap-handling, and signal-handling features of the operating system for Guardian
processes. For debugging and signal handling in OSS processes, see the Open
System Services Programmer’s Guide.
The Requester/Server Application Model
Traditionally, application designers have placed the logic for all the functions of an
application in one unified program. This program handled all aspects of the
application: terminals, database, remote communication, and so on. The operating
system, allows the application designer to divide the application into requester
processes and server processes. These processes then communicate with each other
by sending and receiving messages.
Requester processes typically represent the external user, while server processes
provide most of the functional logic of the application. A typical requester/server
application might have requester processes to control terminals, while server
processes provide database control. Figure 1-1 shows the model in its simplest form.
Figure 1-1. A Requester/Server Application
VST002.VSD