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

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/iTS SCREEN
COBOL Reference Manual.
The checkpointing requirements of the Pathway/iTS 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.
For more information about the checkpointing strategy used by the TCP, refer to the Pathway/iTS
TCP and Terminal Programming Guide.
Consideration for Servers Used With RSC/MP Clients
Some RSC/MP clients are written to check for an integer reply-code value in the first two bytes of
the server’s reply message. If the RSC/MP client program calls the RscSetOption function to set
TMF_OPTION to either 2 (RSC_END_TRANS) or 3 (RSC_BEGIN_END_TRANS), the RSC/MP
transaction delivery process (TDP) monitors this reply code from the server to determine whether
the client should end the transaction. The reply code is a feature that can allow optimization to
reduce network traffic. For further information about use of the RSC/MP reply code, refer to the
Remote Server Call (RSC) Programming Manual.
Nested Servers
A Pathway server can use Pathsend procedure calls to make requests to servers in other server
classes. In such a case, the server is acting as a server with respect to the requester that sends
requests to it, but it is also acting as a Pathsend requester with respect to another server. Servers
communicating with each other in this way are known as nested servers. Because they are Pathsend
programs, nested servers must be written in C, C++, COBOL85, Pascal, pTAL, or TAL.
If you use nested servers, you should try to prevent queues of requests from developing, because
a single-threaded server that calls Pathsend procedures waits for a response before proceeding.
Servers usually just wait for disk I/O, a high-priority activity. Waiting for a low-priority server might
tie up system resources.
For information about how to code the requester functions of nested servers (that is, how to use
the Pathsend procedure calls), refer to “Writing Pathsend Requesters” (page 51). An example of
a nested server, called PATHSRV, is given in Example 4 (page 182)
Using Context-Free Servers With Context-Sensitive Requesters
Dialogs using context-sensitive requesters are described under “Context-Sensitive Pathsend
Programming” (page 58) in Section 3. A context-free server-class send operation (initiated by a
64 Writing Pathway Servers