Availability Guide for Application Design

Availability in the Pathway Transaction-Processing
Environment
Availability Guide for Application Design—525637-004
6-7
Design Implications for Server Processes
Design Implications for Server Processes
The availability of server processes under NonStop TS/MP is largely transparent if
appropriate application design considerations and appropriate operational
considerations are followed. As with all business applications, responsibility for correct
design lies with both development and operations.
Development Concerns
Consider the following development concerns when designing server processes:
•
Ensure that TMF transactions are correctly coded in the requester or client process
with clear transaction boundaries enclosing all critical input/output operations.
Refer to the appropriate subsection later in this section for the requester or client
type.
•
Ensure that your server process is context free.
•
Ensure that enough client or requester processes can open the server during peak
loads. For COBOL85 servers, this limit is set at compile time in the receive control
table. You should consider the effects of a processor failure during peak business
activity when setting this value. For languages other than COBOL85, the Guardian
Programmer’s Guide describes how to handle the opener table.
•
Consider the availability effects of using the concept of service rather than servers.
Choose carefully the services that you package together in the same server; if the
server stops, then all the services it contains also stop.
•
Consider the availability effects of packing multiple functions into a server process.
For performance reasons or for avoiding limits, you might choose to reduce your
number of processes by packing several functions into one process. Like working
with services, packaging functions together does increase the loss of functions if a
server process fails.
•
Ensure that your server design is not prone to performance problems that can slow
your application beyond the acceptable limits specified in your company’s business
plans. For example, you should avoid mixing long transactions and short
transactions in the same server. The danger of mixing these two transaction types
is that short transactions can be locked out while the long transactions are
executing. Response time to the user might be unacceptably long.
•
Ensure that your server process is designed with adequate error-handling
capabilities. Refer to Section 9, Minimizing Programming Errors, for general
information on error handling. Specific to server processes, be sure to respond to
the client or requester with some appropriate information if an error occurs.
Operational Concerns
Consider the following operational concerns when designing server processes: