Kontrola transakcji (commitment control) to potężny środek pozwalający na zachowanie integralności bazy danych DB2 w systemie AS/400. Transakcyjność daje możliwość wykonywania aktualizacji zbioru lub zbiorów bazy danych bez definitywnego ich zastosowanie do czasu aż nastąpi właściwe potwierdzenie wykonanych zmian (commit). Alternatywą przedstawionego scenariusza jest możliwość wycofania wykonanych zmian (tzw. roll back), i powrót do stanu wyjściowego, sprzed ich wprowadzenia.

Każdy programista, który kiedykolwiek wykorzystywał wbudowany SQL (embedded SQL) w swoich programach świetnie kojarzy parametr COMMIT, który należy podać przy kompilacji źródła CRTSQL*.

Transakcyjność często była i jest pomijana ze względu na brak kronikowania zbiorów bazy danych (journaling). Brak kronikowania zbiorów zwykle wynikał z kosztów związanych z zapewnieniem odpowiednio większej przestrzeni dyskowej a także koniecznością administrowania dziennikami/kronikami.Starsze wersję języka RPG nie pozwalały na opcjonalne użycie kontroli transakcji w programie, a zakres jej stosowania dotyczył aktualnego zadania.

Koszty pamięci dyskowych są obecnie znikome a wiele systemów korzysta z rozwiązań High Availability (HA), które działają w oparciu o kronikowanie. Język RPG od wersji IV pozwala na opcjonalne użycie kontroli transakcji a zakres działania można ograniczyć wewnątrz zadania, więc nic nie stoi na przeszkodzie aby obsługę transakcji dołączyć do oprogramowania.

Kronikowanie

Aby móc korzystać z możliwości jakie daje kontrola transakcji wymagane jest kronikowanie zbioru bazy danych, który taką kontrolą ma być objęty.
Idea kronikowania polega na zapewnieniu możliwości odtworzenia bazy danych do stanu w jakim była w wybranym momencie. Gdy plik jest kronikowany, manager bazy danych rejestruje kopię rekordu pliku bazy danych przy każdej jego aktualizacji (dodaniu, aktualizacji lub usunięciu). Oznacza to, że system posiada kopię każdej zmiany w pliku podłączonym do kroniki i w przypadku utraty danych może odtworzyć wszystkie wykonane zmiany.

Mechanizm kronikowania skÅ‚ada siÄ™ z dwóch obiektów: kroniki (journal) i dziennika (journal receiver). W momencie gdy nastÄ™puje zmiana w pliku bazy danych, kopia zmienianego rekordu wÄ™druje do kroniki, która nastÄ™pnie „skÅ‚aduje” informacje w dzienniku. Gdy dziennik siÄ™ zapeÅ‚ni, można go zeskÅ‚adować na zewnÄ™trznym noÅ›niku danych a do kroniki podÅ‚Ä…czyć kolejny dziennik.

Jak sprawdzić czy wybrany plik bazy danych jest kronikowany ? Wystarczy użyć komendy DSPOBJD i odnaleźć parametry opisujące aktualny stan kronikowania dla wybranego obiektu.

DSPOBJD OBJ(plikBD)  OBJTYPE(*FILE) DETAIL(*FULL)

Kronikowanie pliku

Jeśli plik  jest kronikowany, pozostaje tylko zaimplementować obsługę transakcyjności w kodzie programów, w przeciwnym wypadku należy utworzyć dla niego kronikę oraz dziennik.

Dziennik tworzymy za pomocÄ… komendy Create Journal Receiver

CRTJRNRCV JRNRCV(dziennik)

Kronika zaÅ› tworzona jest komendÄ… Create Journal  i w momencie jej definiowania „podÅ‚Ä…czamy” do niej dziennik.

CRTJRN JRN(kronika) JRNRCV(dziennik)

Aby zapewnić kronikowanie wybranego pliku bazy danych wykorzystujemy komendę Start Journal Physical File

STRJRNPF FILE(plikBD) JRN(kronika)

W jaki sposób powinna wyglÄ…dać implementacja transakcyjnoÅ›ci w przykÅ‚adowym programie, już niedÅ‚ugo…