If less serious errors occur, the program unit retains control and can roll back the distributed transaction with PEND RS or PEND ER/FR, or the local transaction with RSET. If communication is via OSI TP transactions can also be rolled back using PGWT RB, see "Particularities of rollback and restart".
The comments below apply to distributed processing with global transaction management, i.e. for LU 6.1 and for OSI TP with functional unit commit. The effect of these calls in the case of OSI TP without functional unit commit is described on "Particularities of rollback and restart".
PEND RS
PEND RS can be called in a job-submitting or job-receiving service.
In a distributed transaction, a PEND RS has the following effect:
With PEND RS, all the services participating in a distributed transaction are rolled back to the last synchronization point. As opposed to the PEND ER/FR call, with PEND RS a service remains open if it has already reached a synchronization point. Services which have not yet reached a synchronization point are terminated.
The following situations are possible:
PEND RS in the first transaction of the uppermost job-submitting service.
All participating services are terminated without any service restart. Chained services are restarted after the rollback.
PEND RS in the first transaction of a job-receiving service
The job-receiving service is terminated. If the uppermost job-submitting service has already reached a synchronization point, openUTM executes a service restart (with the message K034 to the terminal). The job-submitting service receives status information (service status "R" / "Z" and transaction status "R") which you read using MGET NT.
PEND RS in a follow-up transaction of the job-submitting service or job-receiving service.
In this case a rollback message has to be sent with MPUT RM prior to the PEND RS, otherwise openUTM aborts the service with KCRCCC = 83Z. The rollback message goes to the follow-up program unit specified at the last synchronization point of the (local) service. After the rollback openUTM executes a service restart. The form this takes depends on the destination of the output message at the last synchronization point and on who called PEND RS:
In the case of an output message to the client the service restart begins in the job-submitting service.
If PEND RS was issued in the uppermost job-submitting service, then a screen restart is executed (as without distributed processing).
If PEND RS was issued in a job-receiving service, then a screen restart is executed and the message K034 output. The next entry from the client is read by the follow-up program unit of the last synchronization point. If a follow-up program unit sends a new message to the job receiver (which executed PEND RS), then this job receiver first reads the rollback message and then the message sent to it. If job-receiving services are terminated by the rollback (i.e. the job receiver was also a job submitter), then you also have to read the associated status information using MGET NT.
In the case of LU6.1, follow-up processing in the job-receiving service does not start until a message is present for this service. If the job receiver is not included in the next transaction after the rollback, this may not take place until a later follow-up transaction.
In the case of OSI TP, the follow-up program unit runs from the last synchronization point in the job-receiving service which called PEND RS and always runs in the next transaction: The program is started if a message is received from the job submitter or if the job submitter has requested end of transaction.
With an output message to a service, openUTM starts the follow-up program unit specified at the last synchronization point. This program unit has to read the rollback message; subsequently the output message can be read; status information from the job-receiving services may be present, too. If the (uppermost) job-submitting service participated in the rolled back transaction, then openUTM issues message K034.
Programmed PEND ER/FR
In distributed transactions, the effects of the PEND ER and PEND FR calls are identical; however PEND FR does not, in contrast to PEND ER, generate a DUMP. PEND FR enables you to respond to errors other than programming errors (e.g. meaningless data).
The effect of PEND ER or PEND FR differs in the job-submitting and the job-receiving services:
If PEND ER/FR is issued in the job-submitting service, this and all job-receiving services are terminated with PEND ER/FR.
If issued in the job-receiving service, only this service is terminated and the distributed transaction is rolled back to the last synchronization point. The service restart then begins at this synchronization point and the next program started receives status information from the job-receiving service which called PEND ER/FR. If the job-submitting service has not yet reached a synchronization point, it is also terminated by a PEND ER/FR.
If the preceding distributed transaction was terminated in the job-receiving service, the follow-up program unit specified at the last synchronization point is started in the job-submitting service.
If the job-receiving service wishes to terminate with PEND ER/FR, it first has to execute an MPUT, otherwise PEND causes it to be terminated by the system with KCRCCC = 83Z (service status Z instead of E). Exceptions to this rule are dialogs via OSI TP in which an MPUT to the job submitter is not permitted (KCSEND=N). The job-submitting service always receives status information which has to be read with MGET NT.
RSET
The effect of the RSET call is the same in job-submitting and job-receiving service.
After a RSET call in a program unit run belonging to a distributed transaction, the behavior of openUTM depends on the RSET generation parameter of the UTMD statement.
If RSET = LOCAL is generated, openUTM allows the RSET call merely to roll back the local transaction. Please note that the data environment (GSSBs, LSSBs, TLSs, ULS,...), with the exception of the SPAB, is rolled back to the last synchronization point. The following applies to job-receiving services addressed within the transaction: if a message was sent to a job-receiving service in a preceding dialog step terminated with PEND KP or PGWT KP, then this service remains addressed, otherwise the service identifier is deleted.
If RSET = GLOBAL is generated, the program unit run must be terminated with PEND FR/ER/RS. This then causes the distributed transaction to be rolled back.