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

This is a transient error. The send operation will be successful when the ACS subsystem
automatically restarts. The application program must retry the send operation till it succeeds.
The application uses a combination of waited and nowaited sends.
TS/MP differentiates between waited and nowaited sends; therefore, separate communication
channels are established for each. The behavior is the same as explained in the above scenarios
for each type.
Pathsend Programming and the TMF Subsystem
The Pathsend procedure calls support TMF transactions. Calling a Pathsend procedure to start a
server-class send operation propagates the current transaction identifier, if any, to the server
process. If the Pathsend procedure call fails, use of the TMF subsystem allows your application to
abort the transaction and retry the call. As an application developer, you do not have to be
concerned about the role of LINKMON processes or ACS subsystem processes in the propagation
of transaction identifiers.
If you use the TMF subsystem, you should check for errors after each call to the
BEGINTRANSACTION, ENDTRANSACTION, ABORTTRANSACTION, and RESUMETRANSACTION
procedures. Failure to perform these checks could cause important parts of your application to fail.
If a server error occurs during a TMF transaction, the requester should explicitly abort the transaction
(even though in some cases, the transaction might already have been aborted). For further
information, including a list of the file-system errors that can be returned by each of the TMF
procedure calls, refer to the HP NonStop Transaction Management Facility (TMF) Application
Programmer’s Guide.
When designing and coding your application, you should pay attention to whether or not your
Pathsend requests are in transaction mode. For example, your application should not be in
transaction mode while using Pathsend procedure calls to make requests to subsystems whose
operations are not TMF protected, such as the spooler.
Instead:
1. Save the value of the transaction identifier.
2. Suspend the transaction by calling the RESUMETRANSACTION procedure with a tag value
of 0.
3. Make the subsystem request.
4. Resume the transaction by calling the RESUMETRANSACTION procedure with a tag value
equal to the saved transaction identifier.
Attempting to send to a server class configured with the TMF parameter set to OFF fails with
Pathsend error 917 (FEScServerClassTmfViolation) if the requesting process has a current transaction.
The NonStop TS/MP System Management Manual describes how to set the TMF parameter in the
PATHCOM SET SERVER command.
Fault-Tolerant Programming
The following paragraphs describe issues related to the use of Pathsend procedure calls in
fault-tolerant programs and discuss the appropriate levels of recovery that your application can
perform after takeover by a backup Pathsend process.
For Pathsend calls that are protected by the TMF subsystem, on takeover the new primary process
must determine whether the current transaction ended or aborted. If the transaction aborted, the
new primary process can retry the entire TMF transaction. That is, the backup process can begin
a new TMF transaction and reissue the Pathsend calls. This retry mechanism relies on the TMF
subsystem’s capability to back out all work that the server process carried out on the original
request.
56 Writing Pathsend Requesters