When communicating with more than one job receiver, the situation of the job submitter is essentially the same whatever the physical number of job receivers. It is therefore sufficient to consider a configuration involving one job submitter (A) and two job receivers (B and C).
From the job receiver’s point of view, this case is identical to the situations illustrated in the previous section, since the only communication partner known to the job receivers is the job submitter.
However, this scenario is also not very different for the job submitter. There is simply an increase in the number of possible combinations.
The job submitter can communicate with each individual job receiver as described in the previous section. Additionally, the job submitter can communicate either with one or with multiple job receivers in a single processing step. The follow-up program unit run in the job-submitting service is not started until responses have been received from all the job receivers to which messages were sent in the last processing step.
The job submitter can either use the CTRL call to request individual job receivers to request end of transaction or end of dialog or issue an appropriate PEND call to inform all job receivers of the situation simultaneously.
Since the situation has not changed greatly compared to communication with a single job receiver, a single example will suffice here. For reasons of space, the protocol flow is not illustrated.
Example 11: Multiple job receivers
In this example, job submitter A communicates with job receivers B and C. The dialog with C is to be terminated. However, C has to send a final message to A before terminating. To make this possible, A issues an MPUT and a CTRL PE to partner C. The dialog with partner B is not to be terminated yet. A therefore simply sends a message to B and keeps the transaction open by using PEND KP to terminate the program run.
The "F,Y" specifications inform C that it still has to send a message to A and that the transaction has to be terminated with PEND FI. For B, the transaction and dialog remain open. This is indicated by "O,Y".
In the second program unit run, A now uses CTRL PR to request B to end the transaction. However, A wants to receive the response from B in the current transaction and therefore uses PEND KP to terminate the program run. The stati "R,Y" signal the end of transaction request to B. B then sends a response to A and uses PEND RE to terminate the transaction.
Since both C and B have now requested end of transaction, A can finally terminate the distributed transaction. At the end of transaction the dialog with C is simultaneously terminated, whereas the dialog with B remains open.