TS/MP 2.5 Pathsend and Server Programming Manual

Figure 7 GDSX as a Front-End Process
When developing a front-end process using GDSX, consider these points:
• A GDSX front-end process is a good choice when a specified data communications protocol
is not supported by the Pathway TCP but is supported by GDSX.
• A GDSX front-end process is also a good choice when performance is critical. SCREEN COBOL
might not be efficient enough to handle a large amount of application function.
• A GDSX process can be designed to be context-sensitive, through use of the context-sensitive
Pathsend pseudo-procedures.
• GDSX processes are managed either through the Subsystem Control Facility (SCF) interactive
interface or through a management application program using SPI.
For further information about designing and coding GDSX processes, see the Extended General
Device Support (GDSX) Manual.
Dividing Function Between Requestor and Server
In designing a Pathway application, you must decide how to divide function between requestor
and server. In making this decision, you must consider the type of requestor or client you are writing
(SCREEN COBOL, Pathsend, RSC/MP, or GDSX), and you must also consider performance,
maintainability, and other factors.
For example, which program module must check entry fields for validity? If you are writing a
SCREEN COBOL requestor, you can easily code it so that the TCP performs these checks. However,
a special edit-checking server could provide better performance. If your application includes a
workstation requestor that communicates with servers using RSC/MP, having the requestor check
the entry fields would save communications overhead.
As another example, which program module must change screen field attributes such as color,
blink, brightness or reverse video for such purposes as highlighting an entry field that contains an
Designing Requestor Programs 41