If the distributed transaction has to be rolled back, service restart tries as far as possible to restart the program for which there was a message at the end of the last distributed transaction, or to which the next input from the client is directed. The programming rules (see "Programming rules and recommendations" for LU6.1 and "Programming rules for dialogs without the functional unit commit" for OSI TP) ensure that one and only one message exists for the client or for a program in a service at the end of a distributed transaction.
The program unit can tell from the service ID in the KCKNZVG/ kccv_status field in the KB header if a service restart has occurred: after a service restart this field has the value "R".
If the service restart occurs in the job-submitting service, the program unit normally receives status information from the job-receiving service if the job-receiving service caused the rollback and is or was consequently terminated. Such status information is read with MGET NT; it is a message of length 0 and provides the service and transaction status of the job-receiving service in the KCVGST/kcpcv_state and KCTAST/kcpta_state fields in the KB return area (see "Programming aids").
There are 3 different cases with service restart:
There was a message for the client at the last synchronization point.
The follow-up program unit in the job-submitting service can now read the new input from the client with MGET and receives as status information the service status O and the transaction status C.
If the rollback of the transaction was caused by an error in a job-receiving service and the job-receiving service was subsequently terminated, the KCRPI field receives the service ID of the service which caused the rollback. Status information from this service can then be read with MGET NT and KCRN = service ID.
There was a message at the last synchronization point from a job-receiving service to a job-submitting service.
The follow-up program unit in the job-submitting service can now use MGET as usual to read the message, and additionally receives the service and transaction status of this job-receiving service.
If this job-receiving service was rolled back and terminated by an error, you only receive the corresponding status information. If the rollback was caused by another job-receiving service, you receive the transaction status C as status information with the first MGET. Subsequently more status information can be read, as in case 1.
If the message cannot be sent by the job-receiver (see next section), then you just receive status information from the job-receiving service.
There was a message at the last synchronization point from a job-submitting service to a job-receiving service. If possible, the follow-up program unit is then started in the job-receiving service.
If the follow-up program unit cannot be started (e.g. because the application was terminated and not restarted within the generated wait time or because the service terminated with PEND ER), then the follow-up program unit in the job-submitting service is started and receives status information.
There is status information from all job-receiving services which caused rollback of the distributed transaction and which were or are being terminated.
If, after a service restart of the job-submitting service, a job-receiving service is addressed again and an error recurs, the job-submitting service can be rolled back more than once to the same synchronization point. Since the status information from the preceding rollback is retained, it is possible to have multiple status information.
If there is multiple status information, then with each MGET you receive the service ID of the next service with status information. Status information from several job-receiving services has to be read in the order proposed by openUTM (KCRPI). The KCMF/kcfn field is to be set with blanks when reading the status information.
If a remote service in the rolled back transaction is newly created by the APRO call, then there is likely to be status information from it although this service does not actually exist at the synchronization point from which the restart begins.
No message from job receiver
There are two reasons why a job-receiving service cannot send a result to the job submitter service:
The job receiver was not started for one of the following reasons:
no logical connection to the application of the job receiver exists and no connection could be established during the generated wait period
no session or association to the japplication of the job receiver could be reserved during the generated wait period
the job was sent to the application of the job receiver. However, the transmitted transaction code is unknown or locked
The application of the job submitter is terminated using KDCSHUT W
The job-receiving service was started, but errors have occurred during processing of the job-receiving service or the communication path was disturbed. For this reason the transaction was rolled back in the job-receiving service and the job-receiving service has been terminated. Additionally, the session/association to the job-receiving service which terminated through error has been released. The following error situations can occur:
no response has been received by the application of the job submitter from the job-receiving service within the generated wait period
the application of the job receiver has been terminated abnormally because of a severe error
the job-receiving service has terminated using PEND ER or was terminated because of a severe program error.