Serviceprogramm und Speicher

[Fuerchau]

Alles in *NEW ist grob fahrlässig!
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.

Zu obigem sollte man ergänzen:
- Hauptprogramme (also direkt aus dem Menü oder als Batch) können in eigene ACTGRP's
- Serviceprogramme, die in eine Transaktion eingebunden sind müssen *CALLER haben
- Serviceprogramme mit eigenständigen Transaktionen müssen eine eigene ACTGRP haben
- (Schnittstellen-)Unterprogramme wiederum mit ACTGRP *CALLER

Es gibt ja auch z.B. reine "Info"-Programme die auch durchaus rekursiv aufgerufen werden können.
Hier lohnt sich ACTGRP *NEW, da man sich das komplizierte Duplizieren von Programmen dann sparen kann. Oder man schreibt diesbezüglich Service-Funktionen, da diese auch rekursiv aufgerufen werden können (wer's kennt, z.B. das Info-Tool von Infors XPPS).

[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

[Tonazzo]

@Fuerchau
Praktisches Beispiel: Artikelstammverwaltung
Der Artikelstamm besteht aus mehreren Dateien: Basisartikeldaten, Lieferantenbezogene Daten, Landbezogend Daten usw.
Für jede Datei gibt es eigene Verwaltungsprogramme - allerdings gibt es ein übergeordnetes Steuerprogramm. Alle CRUD auf die Dateien erfolgen über Serviceprogramm (Pro Datei ein Service) . Das ganze läuft innerhalb einer Transaktion d.h. einige Dateien sind obligatorisch zu füllen und nur wenn diese gefüllt werden, wird der Artikel angelegt sprich "commitet. Die Prüfung und Commit bersorgt das Steuerungsprogramm. Die einzelnen Verwaltungsprogramme liefern die Nachricht angelegt oder nicht angelegt - die wiederum bekommen die Nachricht von den jeweiligen Services.

Also laufen alle Serviceprogramm unter *CALLER (wie bereits mehrfach geschrieben)
und alle an der Artikelneuanlage beteiligten Hauptprogramme inklusive Steuerungsprogramm müssen unter einer ACTGRP (ARTIKELVERWALTUNG) laufen. Ansonsten könnte das übergeordnete Steuerungsprogramm kein Commit/rollback absetzten....Richtig?

[BenderD]

@Fuerchau
Praktisches Beispiel: Artikelstammverwaltung
Der Artikelstamm besteht aus mehreren Dateien: Basisartikeldaten, Lieferantenbezogene Daten, Landbezogend Daten usw.
Für jede Datei gibt es eigene Verwaltungsprogramme - allerdings gibt es ein übergeordnetes Steuerprogramm. Alle CRUD auf die Dateien erfolgen über Serviceprogramm (Pro Datei ein Service) . Das ganze läuft innerhalb einer Transaktion d.h. einige Dateien sind obligatorisch zu füllen und nur wenn diese gefüllt werden, wird der Artikel angelegt sprich "commitet. Die Prüfung und Commit bersorgt das Steuerungsprogramm. Die einzelnen Verwaltungsprogramme liefern die Nachricht angelegt oder nicht angelegt - die wiederum bekommen die Nachricht von den jeweiligen Services.

Also laufen alle Serviceprogramm unter *CALLER (wie bereits mehrfach geschrieben)
und alle an der Artikelneuanlage beteiligten Hauptprogramme inklusive Steuerungsprogramm müssen unter einer ACTGRP (ARTIKELVERWALTUNG) laufen. Ansonsten könnte das übergeordnete Steuerungsprogramm kein Commit/rollback absetzten....Richtig?

... das mit dem Commitscope ACTGRP wirkt wie mehrere Connections zur selben Datenbank - und das ist auch gut so und das sollte man auch so lassen, sonst riskiert man großen Huddel (wieder mal was aus der Schachtel: no risc no fun).

Normalerweise hat man einen Commitmaster (das ist der, der die Transaktion steuert) und Commit slaves (das sind bei euch die Data Access modules). Die Commit slaves müssen unter *CALLER laufen, sonst kriegt man die nicht in die Transaktion rein.

Wenn man nun nicht sicher weiß unter welcher ACTGRP der Master läuft (weil er *CALLER hat) wird es kompliziert und das würde ich vermeiden, indem ich dem Master eine eigene ACTGRP gebe.

Kennt man den Status der vorherigen Transaktion nicht, will aber eine neue anfangen, startet man selbstredend mit ROLLBACK und keineswegs mit COMMIT (besser eien halbe Transaktion wegschmeißen als inkonsistente Daten commiten). (Alos so, wie oben skizziert).

Selbstredend darf keine Datenbank Transaktion mehrere Bildschirmtransaktionen umfassen (deshalb geht das unter CICS und Co. erst garnicht).

D*B

[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