Bei Fehlern in Teilprogrammen oder bei Formatierungsfehlern sorgt openUTM dafür, dass die Auswirkungen begrenzt bleiben: Andere Transaktionen oder die Arbeit der gesamten Anwendung werden nicht beeinträchtigt.
Dafür stellt openUTM die folgenden Funktionen zur Verfügung:
Bei leichteren Fehlern und Störungen gibt openUTM Returncodes zurück, die den Fehler beschreiben. Das betroffene Teilprogramm hat so die Möglichkeit, auf den Fehler oder die Störung entsprechend zu reagieren.
Da UTM-Anwendungen parallel mit mehreren Prozessen arbeiten, kann selbst ein gravierender Fehler in einem Anwendungsprogramm höchstens zum Abbruch des betroffenen Prozesses führen. Es gibt also in UTM-Anwendungen keinen „Single Point of Failure“. Ein abgebrochener Prozess wird automatisch neu gestartet. Da alle offenen Transaktionen - auch die offenen Transaktionen externer Resource Manager - koordiniert zurückgesetzt werden, bleibt die Datenkonsistenz Anwendungs-übergreifend erhalten.
Jedem Prozess einer UTM-Anwendung wird automatisch ein eigener prozesslokaler Speicherbereich zugeordnet, in dem die für einen Auftrag bzw. einen Programmlauf aktuellen Systemdaten gespeichert werden. Der Datenbereich ist nur von dem eigenen Prozess unter Kontrolle des UTM-Systemcodes erreichbar. Das heißt, die Prozesse einer UTM-Anwendung sind voreinander geschützt.
Falls auf Grund eines gravierenden Fehlers Dialog-Services abgebrochen werden, informiert openUTM den Client über den Fehler. Der Client kann danach weitere Services starten. Beim Abbruch eines Asynchron-Services wird der Auftrag aus der Queue entfernt, so dass nachfolgende Aufträge gestartet werden können. Falls gewünscht, kann durch Quittungsaufträge auch beim Abbruch von Asynchron-Services der Auftraggeber über den Fehler informiert werden.
Wenn während der Formatierung von Nachrichten Fehler auftreten, erkennt openUTM dies und reagiert entsprechend:
Dialog-Services werden abgebrochen. Der betroffene Client wird durch eine Meldung informiert und kann danach andere Services starten.
Bei Asynchron-Services entfernt openUTM nach Abbruch des Service den Auftrag aus der Queue. Nachfolgende Aufträge können so ungehindert gestartet werden.
Jedes UTM-Teilprogramm muss mit einem speziellen UTM-Aufruf verlassen werden. Wenn Sie mit der KDCS-Programmschnittstelle arbeiten, ist dies der PEND-Aufruf. Damit ist u.a. gewährleistet, dass lokale Speicherbereiche freigegeben werden. Wird ein Fehlerfall nicht schon im Teilprogramm abgefangen (bei KDCS mit PEND ER), setzt openUTM intern einen PEND ER-Aufruf ab: Der Prozess wird in jedem Fall „geordnet“ abgebrochen. Zugleich wird in diesem Fall zur Diagnose ein Dump erzeugt.
Die KDCS-Speicherbereiche KBPROG und SPAB können am Ende eines Dialogschritts mit einem beliebigen, per Generierung festzulegenden Zeichen beschrieben werden. Zusätzlich wird von openUTM überprüft, ob in einem Teilprogramm ein größerer Speicherbereich (KBPROG / SPAB) angefordert wird, als bei der Generierung angefordert.