Starting the business transaction

To start this instance of the Sale business transaction, on return from the DEFINE PROCESS request DFH0SAL1 issues a RUN ACQPROCESS command.

A program can acquire a process in two ways: by defining it, or by issuing an ACQUIRE PROCESS command. Here, DFH0SAL1 has acquired a process by defining it; thus the RUN ACQPROCESS causes the DFH0SAL2 program specified on the DEFINE PROCESS command to be executed.

Using RUN causes the process to be activated in a separate unit of work from the unit of work of the requesting transaction, under the transaction identifier specified on the TRANSID option of the DEFINE PROCESS command. (A LINK ACQPROCESS command would have caused DFH0SAL2 to be executed in the same unit of work as MNU001 and DFH0SAL1, and under the same TRANSID, MENU.) The advantages of giving a process a separate TRANSID from the TRANSID of its creator are explained in Creating the business transaction. The SYNCHRONOUS option on the RUN command causes DFH0SAL2 to be executed synchronously with DFH0SAL1.

Although a RUN ACQPROCESS command causes a process to be activated in a separate unit of work from the unit of work of its requestor, the start and finish of the activation are related to the sync points of the requestor. In the example application, the DFH0SAL2 root activity runs its first child activity (Order) synchronously and as part of its own unit of work. If the Order activity is successfully completed (in the business sense as well as the transactional sense), the Sale business transaction is accepted. If not, it is rejected. “Accepted” means committed - this instance of the Sale transaction is ready to start its next activity. “Rejected” means rolled back - this instance of the Sale transaction no longer exists.