TS/MP 2.5 Pathsend and Server Programming Manual

error? The SCREEN COBOL language allows such work to be done by the requestor, 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 43), under “Designing Server Programs” (page 42), later in
this chapter.
Designing Server Programs
Request validations, security checks, calculations, database inquiries, and database changes made
in response to a request message must 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. see “Designing the Database” (page 33) earlier
in this chapter 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 requestor and client interfaces. These interfaces include
SCREEN COBOL, the Pathsend procedures, the RSC/MP interface, and the POET. Requestors 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 requestors.
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 must 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 must 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 requestor 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 requestor or device; they can get work from any requestor 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
42 Designing Your Application