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

(for example, WRITEREAD calls, which do not provide a timeout parameter) and you also use a
timeout value on the Pathsend calls, timeouts can occur in one of the preceding two ways, depending
on which timer expires first. To avoid this complex error handling, it is recommended that you use
a timeout value only on the AWAITIOX call.
For programs whose only I/O operations are Pathsend procedure calls, it is not useful to use both
a timeout on the Pathsend procedure calls and a time limit on AWAITIOX, because you would be
timing the same operation twice. In this case, choose either Pathsend timeouts or AWAITIOX time
limits.
When an AWAITIOX time limit is reached, whether an I/O operation is canceled depends on the
filenum parameter used in the AWAITIOX call. If filenum is set equal to scsend-op-num and the
AWAITIOX time-limit value is greater than zero, the oldest outstanding send operation is canceled.
If filenum is set to-1 or if the AWAITIOX time-limit value is zero or less, no operation is canceled.
When a Pathsend timeout is reached, no send operation is canceled regardless of parameter
settings.
Note that any time a send is canceled, the current TMF transaction, if any, is automatically aborted.
Any time a send timeout occurs when an I/O operation is outstanding on a server process, the
I/O operation to the server is canceled and the transaction, if any, is aborted. However, you
should code the requester to call the ABORTTRANSACTION procedure so that the appropriate
cleanup is done on the requester’s side.
Also, for Error 918.40, if a server process is delayed in its request processing (for example: when
it gets stuck behind a lock, is blocked by a higher priority process, or due to any performance
pitfall), TS/MP may time out the request using the timeout value from either the SET SERVER TIMEOUT
configuration parameter or the timeout argument of a SERVERCLASS_SEND_ call.
Despite being timed out, the server may continue to process the request or continue to be "stuck".
Read-only type processing is especially vulnerable to this.
An insert/update/delete type processing may have a TMF transaction associated with the I/Os.
This transaction abnormally ends as a result of the timeout, which eventually leads to File System
error FEINVTRANSID, thereby terminating the processing early.
Read-only processing has no way to know that the server request was cancelled, unless the server
is multi-threaded and monitors $RECEIVE for incoming messages and cancellations while processing
its current request(s).
If MAXLINKS > 1, any requests queued on $RECEIVE will continue to queue there, possibly up to
the point of timing out themselves. Configuring MAXLINKS 1 for a serverclass minimizes these
additional effects.
Therefore, a single-threaded server is incapable of processing $RECEIVE "message cancellation"
system messages in a timely fashion.
Bridging Pathsend API into Pathway Domain
Any one of the Pathmon process names associated with the Pathway domain can be used to access
the set of Pathmon processes under the same domain. This can be useful when an older code has
hard coded references to a Pathmon process name and now needs to access the set of Pathmon
associated with a Pathway domain. This functionality can be overridden by setting bit 9 in the
flags parameter of SERVERCLASS_SEND_ or SERVERCLASS_DIALOG_BEGIN_ calls. If overridden,
the server class request will be serviced by a process controlled by the identified Pathmon process.
If this bit is set and a Pathway domain name has been referenced, the Pathsend call initiation will
fail with error 29 (FEMissParam). If the Pathmon name is not associated with a Pathway domain,
this flag bit has no function.
NOTE: For more information on TS/MP 2.3 and later versions, see the TS/MP Release Supplement
Manual.
108 Pathsend Procedure Call Reference