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

error? The SCREEN COBOL language allows such work to be done by the requester, but it could
also be done by the server.
For more considerations about dividing function among modules within an application, see
“Packaging Server Functions” (page 44), under “Designing Server Programs” (page 43), later in
this section.
Designing Server Programs
Request validations, security checks, calculations, database inquiries, and database changes made
in response to a request message should be performed by individual units of code within Pathway
server programs. As an application programmer, your task is to create a server program to perform
specific tasks (for example, create a customer account).
You can write Pathway server programs in C, C++, COBOL85, Pascal, TAL, pTAL, FORTRAN, or
Extended BASIC in the Guardian environment. Alternatively, you can write Pathway server programs
in C or COBOL85 in the OSS environment; you must program such servers to read the Guardian
$RECEIVE file as described in the Open System Services Programmer’s Guide. In both cases, you
configure and manage the servers using the PATHCOM interactive interface or the Pathway
management programming interface (based on SPI) in the Guardian environment.
Regardless of which operating environment or programming language you use, your Pathway
server programs can access database files through the SQL/MP relational database management
system or the Enscribe database record manager. Refer to “Designing the Database” (page 34)
earlier in this section for information about these two database managers.
You can use the same server programs, whether developed in the Guardian environment or in the
OSS environment, with several different requester and client interfaces. These interfaces include
SCREEN COBOL, the Pathsend procedures, the RSC/MP interface, and the POET. Requesters or
clients using different interfaces can share the same Pathway server classes if you ensure that the
server program’s request and reply formats are consistent for all requesters.
After you code and compile your server program, the server object code and library code are
shared among all processes of the same server class.
Design Considerations
Before structuring and coding a server program, you should consider some design issues that can
affect server performance and efficiency. First, you must decide whether to program single-threaded
or multithreaded servers. Additionally, you should be aware of the issues related to context-free
versus context-sensitive servers, server packaging, nested servers, aborting transactions, process
pairs, early replies, and audited and unaudited servers. You might also consider the use of a GDSX
back-end process.
Single-Threaded Versus Multithreaded Servers
When writing Pathway server programs, you need to consider whether to write them as
single-threaded or multithreaded programs.
Typically, you can get solid performance from single-threaded servers, which are simpler to design,
program, and maintain than multithreaded server programs. For most applications, single-threaded
server design is recommended.
Single-threaded servers generally perform well because they are highly utilized. Server processes
handle requests from many requester programs (for example, a few servers might support 100
terminals), keeping the server processes highly utilized. Servers are not idle waiting for input from
a single requester or device; they can get work from any requester or device.
Low server utilization, however, might still result if the server experiences long waits while processing
a request. The main reason for writing multithreaded servers is to provide resource efficiency in
applications where processes have long waits (for example, when a server creates Guardian
Designing Server Programs 43