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

Writing Pathway Servers
NonStop TS/MP Pathsend and Server Programming Manual–132500
4-3
LINKMON Process Failures
When a requester fails, all transactions initiated by that requester but not yet completed
at the time of the failure are automatically aborted.
LINKMON Process Failures
If a halt occurs in the processor where a LINKMON process is running, all the Pathsend
requesters in that processor fail. (See the previous subsection for details about requester
failures.) The links that the LINKMON process established with the server processes are
relinquished.
Linkage Space Considerations
If the server allocates too little space for $RECEIVE messages, system performance can
be adversely affected, and the requester can get errors at peak workload times. To avoid
this problem, the number of links specified by the server (for example, in the COBOL85
RECEIVE-TABLE OCCURS clause) should be greater than the value specified in the
SET SERVER MAXLINKS parameter in PATHCOM. The server’s specified number of
links should be large enough for all openers, including requesters from other
PATHMON environments that specify associative servers and from outside the Pathway
environment (for example, operations applications).
The default value for MAXLINKS is an unlimited number of links; therefore, to avoid
this problem, MAXLINKS must be set to a value. The error returned to a Pathsend
requester is error 905 (FEScNoServerLinkAvailable) or 923
(FEScTooManyServerLinks). The error returned to a SCREEN COBOL requester is
error 4 (link denied).
Considerations for Servers Used With SCREEN COBOL Requesters
SCREEN COBOL requesters require that the first two bytes of a server reply message
contain an integer reply-code value. For more information about reply-code values, refer
to the description of the REPLY CODE clause of the SCREEN COBOL SEND
statement in the Pathway/TS SCREEN COBOL Reference Manual.
The checkpointing requirements of the Pathway/TS terminal control process (TCP) can
be reduced significantly if TMF protected servers read outside of transaction mode—
that is, perform their read operations while no transaction is in progress—before
updating the database.
You can improve the performance of a server used by SCREEN COBOL requesters by
taking advantage of the TCP’s checkpointing strategy for TMF protected servers, as
follows:
•
Do not use transaction mode for a server with read-only access to a database if the
requester displays the data before making any attempt to change it. In the event of a
failure, the read operations are retryable and fault-tolerant operation is maintained.
•
Do not use transaction mode for a server that writes to an entry-sequenced logging
file in which duplicates are acceptable. In the event of a failure, the write operations
can be rewritten.