A program unit receives information about its communication partners via different displays. This information enables the program unit to react selectively to special situations. openUTM makes the information available after an INIT or MGET call.
After INIT, the job receiver is informed about being called by an OSI TP partner and the OSI TP functions used by the job submitter for the dialog. Further displays after the INIT call inform the job receiver of whether the job submitter has requested end of transaction or dialog and whether another message has to be sent to the job submitter in the current transaction.
After an INIT or MGET call, the program unit run is informed about the communication partner for which a message is present for reading and about the abstract syntax which was used when sending the message. When receiving the messages, the program unit has to adhere to the predefined order of messages specified by openUTM.
Through the MGET call, the program unit is informed of the type of message received and receives information about the service and transaction status of the communication partner.
The information available after INIT or MGET is explained in more detail below.
Displaying the selected OSI TP functions for the dialog
During the INIT call, important information is entered in the KCCP and KCOF1 fields in KBKOPF (the KB header).
KCCP contains the communication protocol used by the partner: in the case of OSI TP, ’2’ is entered here. This tells the program unit that it has been called by an OSI TP job submitter.
KCOF1 contains information about the OSI TP functions available for the dialog with the job submitter. The values in the KCOF1 field have the following meanings:
B | Basic functions |
The functional units Dialogue and Polarized Control are selected for the dialog with the job submitter. | |
H | Basic and handshake functions |
The functional units Dialogue, Polarized Control and Handshake are selected for the dialog with the job submitter. | |
C | Basic and Commit functions with Chained Transactions |
The functional units Dialogue, Polarized Control, Commit and Chained Transactions are selected for the dialog with the job submitter. | |
O | (other combination) |
A standard combination was not selected for the dialog with the job submitter. If INIT PU was called and OSI TP information requested, the available OSI TPI functions are displayed in the message area. |
Requesting end of transaction or service by job submitter
After an INIT PU call, the KCENDTA field in the message area for the job-receiving service indicates whether the local service has been requested by its job submitter to terminate the transaction and which variant of the PEND call is to be used. The local service must respond to the request to terminate the transaction or dialog at the latest by the end of the processing step in which it next sends a message to the job submitter.
The following values are possible:
' ' | no instructions concerning the termination of the processing step. |
O | no end of transaction may be requested at the end of the processing step. |
R | the transaction and the dialog step must be concluded, the service may not be terminated (PEND RE or PGWT CM with a preceding MPUT to the job submitter). |
At the end of transaction, the job submitter possesses the send authorization in the job submitter dialog. The local service possesses the end-of-transaction send authorization in all other dialogs. | |
S | the transaction must be concluded, the dialog step must not be terminated (PEND SP or PGWT CM without a preceding MPUT to the job submitter). |
The local service possesses the send authorization in the dialog with the job submitter at the end of the transaction. | |
C | the transaction must be concluded, the service may not be terminated (PEND RE/SP or PGWT CM). The local service has end-of-transaction send authorization for the dialog to the job submitter. In another dialog, end-of-transaction send authorization may be passed to the job receiver. This is performed by issuing an MPUT to a job receiver, followed by PEND RE or PGWT CM. |
F | both the transaction and the service must be concluded (PEND FI). |
Displaying the send authorization for the dialog with the job submitter
After an INIT PU call, the KCSEND field indicates in the message area in the local service whether the local service may send a message to the job submitter in the current processing step. The following values are possible.
Y | It is necessary to send a message to the job submitter at the end of the dialog step. |
If KCENDTA has the value "S", in this case it is also necessary to send a message to the job submitter at the end of transaction. This combination (KCENDTA=S and KCSEND=Y) can only occur in the case of heterogeneous coupling. | |
N | No messages are permitted to be sent to the job submitter. However, messages may be sent to job receivers in which case the transaction must remain open after the end of the processing step. |
Displaying the type of message received
After an MGET call, the type of message received is displayed in the KCRMGT field of the return area. The following values are possible:
C | (confirm) |
A positive handshake confirmation has been received. | |
E | (error) |
An error message or negative handshake confirmation has been received. | |
H | (handshake) |
A handshake request has been received. | |
M | (message) |
A normal user message has been received. |
Service status
Following an MGET call, the service status of the communication partner from which a message has been received is displayed in the KCVGST/kcpcv_state field of the return area. The local service can use this display to draw conclusions about the dialog with this partner.
The following values are possible:
C | (closed) |
The job submitter has terminated the service. | |
D | (disconnected) |
The communication with the job submitter has been terminated because of loss of connection. | |
I | (inactive) |
The job-receiving service could not be started because, for example, the TAC is unknown. | |
O | (open) |
The partner service is open, i.e. end of dialog has not yet been requested. | |
P | (pending end dialogue) |
This status can only occur in the case of heterogeneous links and in dialogs for which the Commit functionality has not been selected. | |
The job receiver wants to end the communication. If the job submitter does not agree, it can continue the communication using MPUT EM. | |
T | (time out) |
No connection could be utilized in the generated wait time or the job receiver sent no message in the generated wait time; the dialog with the job receiver is terminated. | |
Z | (error) |
The dialog with the job receiver has been terminated because of an error. |
In the case of the service stati D, I, and T no message is transferred. The service status in the job-receiving service is always O.
Transaction status
Following an MGET call, the transaction status of the communication partner from which a message has been received is indicated in the KCVGST/kcpta_state field of the return area. The local service can use this display to draw conclusions about the dialog with this partner.
The following values are possible:
H | (heuristic hazard) |
The result of a transaction is undetermined since communication with at least one communication partner has been interrupted. The possibility that one of the communication partners involved in the last transaction has made a heuristic decision which conflicts with the actual result of zhe last transaction cannot be excluded. | |
I | (inactive) |
The transaction is inactive at the job receiver, e.g. because the TAC is invalid or no connection could be established in the generated wait period. | |
M | (mismatch) |
It was not possible to synchronize the transaction in the remote service with the transaction in the local service. This may occur after a timeout. | |
A mismatch can also occur if at least one of the communication partners involved in the transaction has made a heuristic decision which conflicts with the actual result of the transaction. | |
O | (open) |
The transaction is open in the remote service. | |
P | (prepare to commit) |
The partner service has either initiated the end of transaction itself or is requesting the local service to initiate the end of transaction. | |
R | (rolled back) |
The transaction in the remote service has been rolled back. | |
U | (unknown) |
The transaction status is unknown. This value is only possible in dialogs for which the Commit functionality has not been selected. |
In the job-receiving service, only the following transaction statuses are possible:'
with functional unit commit: O, P
without functional unit commit: U