TS/MP Pathsend and Server Programming Manual (H06.05+, J06.03+)

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, refer to the Extended General
Device Support (GDSX) Manual.
Dividing Function Between Requester and Server
In designing a Pathway application, you must decide how to divide function between requester
and server. In making this decision, you should consider the type of requester or client you are
writing (SCREEN COBOL, Pathsend, RSC/MP, or GDSX), and you should also consider performance,
maintainability, and other factors.
For example, which program module should check entry fields for validity? If you are writing a
SCREEN COBOL requester, 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 requester that communicates with servers using RSC/MP, having the requester check
the entry fields would save communications overhead.
As another example, which program module should change screen field attributes such as color,
blink, brightness or reverse video for such purposes as highlighting an entry field that contains an
42 Designing Your Application