For MHPs, the user service definition must include the specification of atomic_update=Y indicating that the MHP has the transaction attribute.

During MHP processing, the synchronization point can be acquired as a commitment in chained mode. To acquire the synchronization point, call the function dc_mcf_commit() [CBLDCMCF('COMMIT ')]. When the function dc_mcf_commit() returns, the subsequent MHP process becomes a global transaction.

Suppose that a global transaction beginning with an MHP consists of more than one transaction branch (the MHP calls the SPP with the function dc_rpc_call()). Unless the processing result of each transaction branch brings about a commitment, no commitment comes into effect. If the global transaction is not committed, all transaction branches are rolled back.

Before a message is received, the synchronization point cannot be acquired using the function dc_mcf_commit(). In addition, once the synchronization point is acquired using the function dc_mcf_commit(), the MHP can no longer receive the message.

Message processing for which synchronization point acquisition using the function dc_mcf_commit() is performed is the activation of an asynchronous message and an application. Processing for sending or receiving a synchronous message is not the target of synchronization point acquisition.

The function dc_mcf_commit() can be used only from MHPs for which the nonresponse type (noans type) is specified in the MCF application definition. If the function is called from an MHP of another type, it returns with an error. UAPs other than MHPs cannot call the function dc_mcf_commit().

(a) If MHP processing terminates abnormally:

If an MHP terminates abnormally or rolls back,^#1 an error event is generated. The type of the error event depends on whether the function dc_mcf_receive() has received the first segment.

• ERREVT2^#2: The MHP terminated abnormally before the function dc_mcf_receive() received the first segment.
• ERREVT3: The MHP terminated abnormally after the function dc_mcf_receive() received the first segment.

#1

Excludes cases in which r is specified for the recvmsg operand in the MCF application definition (mcfaalcap -g) or in which DCMCFRTRY or DCMCFRRTN is specified for action of the function dc_mcf_rollback().

#2

When a non-resident MHP cannot start for a reason such as those given below, ERREVT2 is not reported.

• The corresponding load module does not exist.
• There is no service function corresponding to the entry point defined in the RPC interface definition file.

In this case, the system shuts down the schedule of the input queue for the relevant service group and leaves a receive message in the input queue.

(b) If an error occurs during MHP processing:

If MHP transaction processing ends up with an error, call the function dc_mcf_rollback() [CBLDCMCF('ROLLBACK')] from the MHP in order to return to the status before the message was received. If the MHP that received the message was rolled back, OpenTP1 decides whether to reschedule the MHP according to the argument specification in the function dc_mcf_rollback().

• If NORETURN (DCMCFNRTN for action) is specified:
  After the rollback, control does not return to the MHP. The MHP terminates abnormally and ERREVT3 is reported.
  
• If RETURN (DCMCFRRTN for action) is specified:
  If the rollback is successful, the function dc_mcf_rollback() returns. Thereafter, the MHP can continue any processing. After the rollback, a new separate transaction comes into effect.
  
• If RETRY (DCMCFRTRY for action) is specified:
  When the function dc_mcf_rollback() does not return, the MHP terminates the process. After the rollback, the MHP is rescheduled. Before the function dc_mcf_rollback() can be used for setting this value, an application startup process must be present on the node.
  

The figure below shows the relationship between message exchange processing and transactions.

Figure 3-12 Relationship between message exchange processing and transactions

Explanation:

1. When TP1/Message Control receives a message, processing started by the MHP becomes a global transaction.
2. If an error occurs during MHP transaction processing, control is returned to the MCF after rollback processing (partial recovery) is executed.
   New transaction processing can be executed by using the function dc_mcf_rollback() in which return is specified (DCMCFRRTN set in action).
   

If MHP processing is terminated because the message exchange function returns with an error, the transaction itself might be committed. If the resource manager (RM) has been accessed (DAM, TAM) in the MHP processing, this access processing is committed. To roll back the access processing, call the abort function or create processing for using the function dc_mcf_rollback() after an error is returned.

Even MHPs can use a transaction starting function (dc_trn_begin()) if the function is outside the service function processing range (within the main function processing range). The transaction start function and commitment functions can be called between main functions (e.g., between the dc_rpc_open() and the dc_mcf_mainloop() or between the dc_mcf_mainloop() and the dc_rpc_close()).

If the function dc_trn_begin() is called as an MHP main function, acquire a synchronization point by using the function dc_trn_unchained_commit() (commitment in unchained mode) as an MHP main function.