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

Designing Your Application
NonStop TS/MP Pathsend and Server Programming Manual–132500
2-17
Requesters Using GDSX
character inserted before the procedure name. For example, SERVERCLASS_SEND_
becomes ^SERVERCLASS_SEND_. The GDSX interface supports both context-free
and context-sensitive Pathsend procedures.
When a GDSX process is used as a front-end process, multiple threads of a user-coded
device handler provide separate tasks to manage the input from I/O devices and provide
functions such as data-stream conversion, implementation of a communications
protocol, and network communications error handling. One instance of the device
handler manages one I/O device.
If the GDSX process is acting as a front-end process for a TCP, the GDSX process
simulates a terminal supported by the TCP; the simulated terminal is typically run by an
IDS requester program. When the IDS facility is used, the GDSX process does not
ordinarily control how data appears to the intelligent devices, nor does it perform any
other device-dependent functions. However, the GDSX process can be designed to
perform device-dependent functions if needed.
A GDSX process can also act as a front-end process to a LINKMON process, as shown
in Figure 2-4
. The figure shows the path of a transaction from a general device to a
Pathway server through a GDSX process.
In this example, the GDSX device handler contains the application requester logic and
uses the Pathsend interface to communicate with Pathway servers. Normal interaction
with a server process for each thread is similar to that of a Pathsend requester process.
Note. Figure 2-4 does not reflect the actual flow of data from the GDSX processes to the
Pathway server class. Only server-class control information is passed to the LINKMON
process; the application data moves directly from the GDSX process to the server class.