Serviceprogramm und Speicher

[B.Hauser]

Wichtig ist, ob man Transaktionssteuerung einsetzt oder nicht.
Wie gesagt, jede ACTGRP's hat seine eigene Commit-Definition!
Dadurch sind dann keine gemeinsamen Transaktionen über mehrere Programme möglich.

Man kann durchaus eine Transaktion über mehrere Aktivierungsgruppen steuern!
Voraussetzung dafür ist allerdings, dass die Commitment Control auf Job-Ebene gestartet wurde, d.h. STRCMTCTL mit CMTSCOPE=*ACTGRP ausgeführt wird.

- Serviceprogramme mit eigenständigen Transaktionen müssen eine eigene ACTGRP haben

Was soll das?
Es kommt doch darauf an wo und wann COMMIT bzw. ROLLBACK ausgeführt werden. Deshalb am Besten einen Commit setzen bevor die Transaktion beginnt.
Dadurch werden evtl. nicht festgeschriebene Änderungen festgeschrieben werden und bei einem Rollback nicht versehentlich zurück gesetzt werden.
Nachdem alle Änderungen erfolgt sind erfolgt der nächste COMMIT. Ob diese beiden COMMITs in der Main-Procedure eines Programms oder einer Prozedur in einem Service-Programm erfolgen ist Jacke wie Hose. Wichtig ist nur, dass die aufgerufenen Prozeduren in Service-Programmen, die mit Aktivierungsgruppe *CALLER erstellt wurden hintelegt sind.

Die Regel heißt und hieß eigentlich schon immer:
Beide Commits (Beginn und Ende) sollten auf dem gleichen Bildschirm (im Haupt-Programm oder in der gleichen Prozedur oder füher Sub-Routine) sichtbar sein.

Hier lohnt sich ACTGRP *NEW, da man sich das komplizierte Duplizieren von Programmen dann sparen kann.

Um Programme rekursiv aufzurufen, sind weder die Aktivierungsgruppe *NEW, noch komplizierte Duplizier-Vorgänge erforderlich!
Lineare Main-Procedures heißt hier das Zauberwort!
Dabei wird eine "ganz normale" Prozedur über Schlüssel-Wort MAIN(ProzedurName) in den H-Bestimmungen als Main-Procedure/Programm definiert. Im Prototypen muss das Schlüssel-Wort EXTPGM angegeben werden.

Birgitta

Birgitta

[Fuerchau]

Es gibt durchaus getrennte Transaktionen, vor allem wenn Anwendungen gemischt werden und in verschiedenen Journalen aufzeichnen. Dann benötigt man auch getrennte Commitdefinitionen und kann nicht auf Jobebene arbeiten. Oder hat sich das etwa geändert?
Und es gibt durchaus Anwendungen oder Funktionen in eigenen Triggern/Serviceroutinen die eben nicht durch übergeordnete Transaktion rückgängig gemacht werden.
Ich protokolliere z.B. bestimmte Aktivitäten per Trigger und schreibe diese in eine weitere journalisierte Datei. Hier darf durch den Aufrufer kein Rollback durchgeführt werden. Da sich das aber nicht verhindern lässt werden eben eigene ACTGRP's mit eigener Commitdefinition verwendet.
Ich kann also nicht einfach einen Commit machen um meine eigene Transaktion zu öffnen da ich ja nicht weiß ob der Aufrufer die Transaktion auch wirklich abgeschlossen hat.
Savepoints in SQL kamen auch erst später was mir bei getrennten Journalen auch nicht hilft.

[BenderD]

Es gibt durchaus getrennte Transaktionen, vor allem wenn Anwendungen gemischt werden und in verschiedenen Journalen aufzeichnen. Dann benötigt man auch getrennte Commitdefinitionen und kann nicht auf Jobebene arbeiten. Oder hat sich das etwa geändert?
Und es gibt durchaus Anwendungen oder Funktionen in eigenen Triggern/Serviceroutinen die eben nicht durch übergeordnete Transaktion rückgängig gemacht werden.
Ich protokolliere z.B. bestimmte Aktivitäten per Trigger und schreibe diese in eine weitere journalisierte Datei. Hier darf durch den Aufrufer kein Rollback durchgeführt werden. Da sich das aber nicht verhindern lässt werden eben eigene ACTGRP's mit eigener Commitdefinition verwendet.
Ich kann also nicht einfach einen Commit machen um meine eigene Transaktion zu öffnen da ich ja nicht weiß ob der Aufrufer die Transaktion auch wirklich abgeschlossen hat.
Savepoints in SQL kamen auch erst später was mir bei getrennten Journalen auch nicht hilft.

... das mit dem einen Journal ist, soweit ich das im Kopf habe (normal mache ich das so nicht) wohl aufgehoben.
So ein Protokoll läuft dann am einfachsten ohne Commit (DB2 Erweiterung auf Statement Ebene), oder ich mache das in einem eigenen logger SRVPGM (wo es eh' hingehört) und dann auch wieder ohne commit.

D*B