Particularities of rollback and restart

The OSI TP protocol enables you to work either with global transaction management (functional unit commit) or without global transaction management (Cooperative Processing).

OSI TP with functional unit commit

If you select the functional unit commit for OSI TP, the rollback of transactions with PEND RS is performed in the same way as in LU6.1.

When a service is restarted after PEND RS, the behavior is the same as with LU6.1, with one exception: when using the OSI TP protocol it is not possible to restart an interrupted dialog.

A synchronization point can also be set with PGWT CM when using OSI TP. The next transaction may then be rolled back with PGWT RB only. In this case a return is always made to the program unit that issued the PGWT RB. No service restart is performed.

OSI TP without functional unit commit

If you do not select this functional unit, the job-submitting service is not automatically rolled back when an error occurs in the job-receiver service or if the connection is lost. The job-submitting service is continued with the program unit specified in the last PEND. However, if it waits for a result from the job receiver, it receives an error message (with service status "Z" and transaction status "U") and can also react with a rollback.

If an error occurs in the job-submitter service, openUTM rolls back the transactions in the job-submitting service and job receiving services and terminates the job-receiving service. If the job-submitting service has already reached a synchronization point, a service restart is performed after the rollback of the transaction. The follow-up program unit receives an error message with service status "Z" and transaction status "U".

A global service restart is not possible, since no common synchronization points exist.

If you use calls for programmed rollbacks, you have to take the following into account:

• PEND RS

  For a call in the job-submitting service:
  All job-receiving services with which the job-submitting service communicates without functional unit commit are terminated.

  For a call in the job-receiving service:

  • If PEND SP has been used to terminate the preceding transaction, then PEND RS rolls back the local transaction and the service is continued with the follow-up program unit specified with PEND SP.

  • If PEND SP has not been used to terminate the preceding transaction and the service is running under a user ID without the restart property, then the service is rolled back to the last synchronization point and the dialog with the job submitter is terminated.

  • In all other cases, openUTM terminates the service with PEND FR.

• PGWT RB

  PGWT RB rolls back the current transaction and the program unit continues.

• PEND ER/FR

  No special considerations apply when this call is used in the job-submitter service: The transactions in the job submitter and all its job receivers are rolled back and the job receivers terminated.

  If called in the job-receiver service, the job receiver is rolled back and terminated. However, the job-submitter service is continued in the program unit specified with the last PEND. The job-submitter service can read the messages which have been sent by the job receiver with MPUT.

To ensure consistent operation even when a transaction is rolled back, it is advisable to use only PGWT or only PEND calls within a distributed transaction.

• RSET

  The RSET call always applies only to the local service. The RSET=GLOBAL setting in the KDCDEF statement UTMD has no effect. This setting only has an effect in distributed processing with global transaction management (see "Programmed rollback").