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

Designing Your Application
NonStop TS/MP Pathsend and Server Programming Manual–132500
2-21
Design Considerations
program or in the database. When you program a server to be context-free, you code the
server to be independent of its previous request. In essence, every request must be
treated as if it were the first request received by the server.
SCREEN COBOL and the TCP support only context-free servers. However, if you use
Pathsend requesters, you can use either context-free or context-sensitive servers. In most
cases, it is preferable to use context-free servers. However, context-sensitive servers
might be a better solution if you need to do one of the following:
•
Retrieve large blocks of information (larger than 32 KB) from a database
•
Browse a database and repeatedly get the next record, saving the cursor position
Context-sensitive servers require additional programming for both requester and server.
The requester must first establish a dialog with a server class and then send messages
within the dialog. All messages in a dialog will be sent to the same server process in the
server class. Programming details are explained in Section 3, Writing Pathsend
Requesters, and Section 4, Writing Pathway Servers.
Packaging Server Functions
Another major decision that you must make during server design is how to package the
individual functions, or services, that the server performs. This decision is related to the
decision about how to divide function between requester and server, discussed earlier in
this section at the end of the subsection Designing Requester Programs
.
Based on various operational considerations (for example, security, management, file
access, throughput, and response-time requirements), you could choose one or more of
the following server packaging alternatives:
•
One server class for each database: Called a single-function server, this server
(for instance, a list-item server or a change-item-quantity server) services an entire
database.
•
One server class for each file: Each file has its own dedicated server that executes all
I/O (reads, updates, adds, and deletes) against the file. The server performs no
functions beyond file access.
•
Similar service times: Transactions with similar I/O rates are grouped and processed
by the same server. Grouping transactions with different service times in separate
servers minimizes server queues and facilitates application tuning.
•
One server for each business function: A single server handles all tasks of a specific
business function, including business decisions (for example, loan approvals based
on predefined criteria) and database navigation.
•
One server for similar business functions: Similar business transactions (for
instance, enter orders less than $100 in value or delete orders) are handled by a
single server.
•
One server for similar business functions and all database functions: A single server
services similar business transactions and handles both business decisions and
database navigation.