Die Anwendungen auf der IBM i sind z.T. sehr komplex.

Die gewachsenen Datenbanken sind oft nicht optimal normalisiert und enthalten redundante Daten. Damit muss durch zusätzlichen Programmier-Aufwand (z.B. Updates in mehreren Tabellen) sichergestellt werden, dass die Daten konsistent bleiben.

Unabhängig davon gibt es viele Vorgänge, die aus mehreren Schritten, vielleicht sogar aus mehreren Programm- oder Prozedur-Aufrufen bestehen, die entweder alle korrekt ausgeführt oder komplett zurückgesetzt werden müssen (z.B. Auftrag muss komplett geliefert werden… Reservierung Bestand, Auslagerung, Umbuchung, Reservierung auflösen, Status im Auftrag setzen).

Vielfach geht man einfach davon aus, dass ja schon alles funktionieren wird (was wahrscheinlich auch in 90% der Aktionen zutrifft) . . . und wenn was schiefgeht dann korrigiert man halt „von Hand“ oder „mit SQL“.

Das darf nicht sein! Programmatisch versuchen im Fehlerfall alles zurückzusetzen ist ebenfalls keine Lösung, da sich ja zwischenzeitlich, also zwischen Fehler und Korrektur, schon wieder etwas geändert haben könnte. Wenn jetzt noch Daten durch Trigger-Programme geändert werden, hat man keine Chance mehr!

Die Lösung heißt Commitment Control!

Was ist Commitment Control?

Commitment Control sorgt dafür, zusammen gehörige Schritte als Einheit(Transaktion) ausgeführt werden oder wieder zurückgesetzt werden.

Das bedeutet: Alle Änderungen einer Transaktion werden entweder korrekt ausgeführt und anschließend durch ein COMMIT-Statement festgeschrieben oder vollständig durch die Ausführung eines ROLLBACK-Statements (bis zum letzten COMMIT-Statement) zurückgenommen – unabhängig davon, wie viele Änderungen in wie vielen Tabellen durch wie viele Programme oder Prozeduren erfolgt sind.

Voraussetzungen

Um Commitment Control auf IBM i zu nutzen, müssen die Tabellen/physischen Dateien in einem Journal aufgezeichnet werden.

Da die meisten Firmen inzwischen Hochverfügbarkeits-Lösungen einsetzen und fast alle Hochverfügbarkeits-Lösungen auf Journaling basieren, muss „weiter nichts“ getan werden, als die Commit-Steuerung im aktuellen Job zu starten.

Transaktionen – durchdacht planen und sicher umsetzen

Bevor Commitment Control produktiv gesetzt werden kann, sollten die Anwendungen analysiert und die Transaktionen definiert werden:

Dabei ist zu beachten:

• dass die Transaktionen nicht zu groß werden, d.h. die Datensätze, die unter Commit geändert werden von anderen Jobs oder Programmen nicht geändert werden können. Die Freigabe erfolgt erst mit dem Commit oder Rollback
• dass im Fehlerfall die Transaktion ohne Probleme erneut durchgeführt werden kann. Am einfachsten ist es, Commit und Rollback in ein Programm zu legen, das jederzeit aufgerufen werden kann, während in den aufgerufenen Unter-Programmen und Prozeduren weder ein Commit, noch ein Rollback, ausgeführt werden darf.
• dass die Commitment Control „richtig“ gestartet wird, so dass bei einem Rollback auch wirklich alle Schritte zurückgesetzt werden.

Commitment Control kann schrittweise in die vorhandene Anwendung integriert werden. Was zuvor nicht unter Commitment Control gelaufen ist, läuft auch weiterhin unverändert. Da Commitment Control bereits seit Beginn der AS/400 eingesetzt werden kann, können selbst Schritte die in OPM(Original Program Model) Programmen (RPGIII, CLP) erfolgen, sauber zurückgesetzt werden.

Interesse

Sofern Sie Commitment Control einsetzen wollen und bei der Umsetzung Unterstützung benötigen, kontaktieren Sie uns direkt und lassen Sie uns gemeinsam über die Einführung und Umsetzung von Commitment Control sprechen.