TS/MP 2.5 Pathsend and Server Programming Manual

The default value for MAXLINKS is an unlimited number of links. To avoid this problem, MAXLINKS
must be set to a value. The error returned to a Pathsend requestor is error 905
(FEScNoServerLinkAvailable) or 923 (FEScTooManyServerLinks). The error returned to a SCREEN
COBOL requestor is error 4 (link denied).
Considerations for Servers Used With SCREEN COBOL Requestors
SCREEN COBOL requestors require that the first two bytes of a server reply message contain an
integer reply-code value. For more information about reply-code values, see 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 requestors by taking
advantage of the TCP 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 requestor
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, see 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 reply message of the server. 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 must 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, see 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 requestor that
sends requests to it, but it is also acting as a Pathsend requestor 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 must 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 requestor functions of nested servers (that is, how to use
the Pathsend procedure calls), see “Writing Pathsend Requestors” (page 50). An example of a
nested server, called PATHSRV, is given in Example 4 (page 188)
Using Context-Free Servers With Context-Sensitive Requestors
Dialogs using context-sensitive requestors are described under “Context-Sensitive Pathsend
Programming” (page 57) in chapter 3. A context-free server-class send operation (initiated by a
call to SERVERCLASS_SEND_) is, in effect, a dialog consisting of a single send operation. Pathway
servers that are coded to be context-free can participate in single-send dialogs with context-sensitive
Basic Pathway Server Programming 63