Following abnormal termination of a UTM-S application (UTM-Secure), openUTM offers enhanced, high-speed restart (= warm start) functions. All open transactions are rolled back to a consistent state, interrupted services are restarted, and users can continue working with the screen belonging to this consistent state (screen restart).
For this purpose, openUTM enters a record containing restart information in the KDCFILE for each transaction during operation of the UTM-S application.
Consistency for interrupted transactions
However, openUTM does not simply roll back all open transactions. Instead it proceeds as follows:
Transactions that were undergoing end-of-transaction processing at the time of the failure are handled differently by openUTM, depending on whether or not the transactions of external resource managers were complete when the error occurred.
If the transactions of the resource managers were not complete and were rolled back when the resource manager was restarted, openUTM also rolls back the UTM transaction.
If the transactions of the resource managers were complete, openUTM also completes all UTM transactions open at the time of the failure (commit).
This also applies to the case of distributed transactions.
All transactions that had not yet undergone end-of-transaction processing at the time of the failure are rolled back.
Restarting dialog services
Interrupted dialog services may be resumed under certain circumstances after an application restart (service restart).
If a user has an open service and has signed on via a sign-on service, then the sign-on service decides if a service restart is to be performed or the service is to be terminated abnormally.
If a user has an open service and has signed on via a client program, then a service restart must be explicitly requested by the client program, otherwise openUTM terminates the service abnormally.
If a user has an open service and has signed on via a terminal, then openUTM always performs a service restart.
The response of openUTM depends on whether or not the last action was closed with a synchronization point. When a service is restarted, it is always rolled back to the last synchronization point.
| Detailed information on the restart procedure when connecting client programs can be found in the openUTM-Client manuals. |
Restarting background and output jobs
The openUTM transaction-oriented queuing mechanism ensures that all queues containing background or output jobs are retained following a failure that openUTM has accepted for processing and which have not yet been completely processed.
openUTM operates as follows during a restart:
Background jobs whose processing has not yet been started or that have not yet reached a synchronization point are restarted after the restart.
Background jobs that have already reached a synchronization point will be processed starting at this synchronization point.
All output jobs whose processing has not yet been started or that have not yet been completely processed at the time of the crash are available for output after the restart.
All messages from service-controlled queues that have not yet been read in completed transactions are available for reading again after restart.