The simplest case possible is where one job submitter (A) has exactly one job receiver (B). This section explains all possible uses for this type of application.
Data transfer phase
The message transfer phase is the period in which neither of the two partners requests an end of transaction. For the job receiver, this option is only available if it has been requested explicitly by the job submitter.
Send authorization changes with each message sent to the partner. Displaying the service status "O" and transaction status "O" informs the job receiver that neither end of transaction nor end of service has been requested.
Example 1: Message to job receiver and PEND KP
End of transaction
A job receiver may only issue an end of transaction call if this has been requested to do so by the job submitter. The job receiver can read this information from the transaction status after the MGET call.
Example 2: Message and Prepare to job receiver and PEND KP
This should be regarded as the normal case when communicating via the OSI TP protocol, since the order of KDCS calls best corresponds to the protocol flow. Additionally, the job-submitting service has control after end of transaction and this simplifies service restart.
In the second job submitter program unit run you can also issue an MPUT to the client and a PEND RE in a dialog service instead of PEND SP. In this case, the command sequence is as follows:
Example 3: No message to the job receiver and CTRL PR
In this case the job receiver simply receives a request for end of transaction, but no message from the job submitter. Send authorization therefore does not pass to the job receiver (DATA-PERMITTED=FALSE). The job submitter possesses the send authorization at end of transaction - as in example 2.
It is also only possible to issue a PEND PA/PR in place of the MPUT, PEND KP the first time the program unit is run. If the job-submitting service is an asynchronous service, only this second variant is possible.
You should note that at the start of the program unit run, after the PEND KP, the system waits only for the message from the client but not for the TP-READY from the job receiver. I.e., after a PEND PA/PR the follow-up program unit is started immediately unless the system is waiting for a DGET message.
It is also only possible to issue a PEND SP in place of the MPUT, PEND KP the second time the program unit is run. If the job-submitting service is an asynchronous service, only this second variant is possible.
Example 4: Message to job receiver and PEND RE
This case most closely resembles the situation when using the LU6.1 protocol. In particular, the service and transaction stati are identical to those for communication via the LU6.1 protocol. This means that you can reuse these programs unchanged. However, you should remember that these programs to not adhere to the bottom up strategy recommended for LU6.1 communication.
In this example, the job receiver possesses control of end-of-transaction send authorization.
In this case, the job receiver can also use a PEND SP instead of the PEND RE call. The command sequence is then as follows:
Example 5: No message to job receiver and PEND SP/RE
This example illustrates that the job-receiving services are included in all transactions, even if the job submitter and job receiver have not communicated in the last transaction.
There are no so-called local transactions when using the OSI TP protocol with Chained Transactions. This has to be taken into account when you design your distributed applications.
The job submitter can issue an MPUT to the client and a PEND RE instead of PEND SP. The command sequence is then as follows:
Example 6: Defer-Grant-Control and Prepare(True)
This is an ‘exotic’ case which can only occur with heterogeneous coupling. The job receiver has to send two messages in sequence to the job submitter. The first message has to be sent within the first current transaction. Send authorization remains with the job receiver after the end of transaction, which means that the job receiver issues the first message in the follow-up transaction.
End of dialog
If the Commit functionality is used, the job receiver can only terminate the service if requested to do so by the job submitter.
Normally the job-receiving services are terminated first and the job-submitting service can terminate afterwards. It is also possible to terminate the job-submitting and job-receiving service simultaneously.
If the job-submitting service is to be continued, then the job receiver must use the CTRL PE call to request the job receiver to end the service.
Example 7: Message and end dialog to job receiver and PEND KP
In this example, the job receiver can send a last message to the job submitter before the job receiver terminates the service.
In the second job submitter program unit run, instead of PEND SP, you can issue an MPUT to the client and another PEND call to request end of service or end of transaction. The command sequence is then as follows:
Example 8: No message to the job receiver and PEND SP/RE
In the first job submitter program unit run, instead of PEND SP, you can issue an MPUT to the client, and another PEND call to request end of service or end of transaction. This results in the following command sequence:
Example 9: No message to the job receiver and PEND FC/FI
In the example above, the job-submitting service is not to be continued as in examples 6 and 7. Instead, it terminates at the same time as the job receiver. If PEND FC (service chaining) is used, the dialog step is continued in a follow-up service.
In the first job submitter program unit run, instead of PEND FC, you can issue an MPUT to the terminal and a PEND FI. In this case no follow-up service is performed in the job submitter. The command sequence is then as follows:
Example 10: Message to job receiver and CTRL PR, KCNORPLY=Y
In this case, the job receiver receives an end-of-transaction request and a message from the job submitter without, however, the job submitter passing the send authorization to the job receiver (DATA-PERMITTED=FALSE). The job receiver cannot send any more messages. When the follow-up program unit starts, the job submitter waits after the PEND KP for the receipt of TP-READY.