TS/MP Pathsend and Server Programming Manual (G06.24+, H06.03+)

Designing Your Application
NonStop TS/MP Pathsend and Server Programming Manual–132500
2-24
Design Considerations
increases its potential queue by one request. A single-threaded server queue can result in
poorer performance for the application system.
Audited and Nonaudited Servers
If your Pathway application uses a database that is a combination of TMF audited files
and nonaudited files, write separate servers to process the two types of files. Updates to
audited files must occur within a TMF transaction; updates to nonaudited files should
not occur within a transaction, because the transaction imposes unnecessary overhead.
Use of a GDSX Back-End Process
The Extended General Device Support (GDSX) communications subsystem product,
described under Requesters Using GDSX
, earlier in this section, can also be used as a
back-end process for Pathway server classes.
A GDSX back-end process receives input from multiple processes on a Tandem
NonStop system and provides access to a limited number of I/O devices. Common uses
of GDSX back-end processes include implementing communications protocols; message
switching; and coordinating access to shared resources or I/O devices, such as log files,
terminals, or remote ports.
In a back-end process, each thread of the device handler has no direct association with
an I/O device. Figure 2-5
shows a typical message-switching application in which
processes on the Tandem system send messages to the communications process on the
remote system. Here, the GDSX process might run a line-handler task to handle data on
the communications lines and a device-handler task for each server process. The device
handlers forward data to the line handler for forwarding to the remote system.
For further information about designing and coding GDSX processes, refer to the
Extended General Device Support (GDSX) Manual.
Figure 2-5. GDSX as a Back-End Process
CDT129
Server
Server Class
GDSX
Comm
Process
Tandem NonStop System Remote System