Serviceprogramm und Speicher

[Tonazzo]

Ist es sinnvoll nach Beendigung der Hauptprogramme (Menü, Submit) die benannte
Aktivierungsgruppe mit RCLACTGRP auch zu beenden oder riskiere ich damit enventuell irgendwelche
Datenverluste.

[DEVJO]

Wenn der Job zu Ende ist, ist es egal was in der Activation Group läuft, da sich die Activation Group nur auf den Job bezieht.
Wenn der Job nach der Beendigung weiter läuft, kann man das ruhig machen...es schadet zumindest nichts. Allerdings weiß ich nicht, wie es sich verhält, wenn man dann wieder in das Hauptprogramm geht, da kennen sich andere hier besser aus. Ich glaube aber bei erneuten Aufruf, geht alles wieder von vorne los....
Aber Vorsicht, bei CL - Programmen die einen OVR benutzen muss der Overscope auf *JOB gesetzt werden, sonst bekommt man an der Stelle ein paar Problem.

[BenderD]

Ist es sinnvoll nach Beendigung der Hauptprogramme (Menü, Submit) die benannte
Aktivierungsgruppe mit RCLACTGRP auch zu beenden oder riskiere ich damit enventuell irgendwelche
Datenverluste.

... den Effekt kannst Du billiger haben, wenn Du die Programme mit ACTGRP(*NEW) wandelst. Beim SBMJOB wird der Job beendet und damit alles automatisch abgebaut.

D*B

[BenderD]

Ich würde das etwas eingrenzen:
1. Programme, die direkt aufgerfuen werden (Menü, Submit) in benannte Aktivierungsgruppen (PGM = Aktivierungsgruppe ist m.E. eine gute Idee).
2. Trigger in Aktivierungsgruppe *CALLER wegen Commitment Steuerung
3. Service-Programme mit Insert/Update und Delete-Prozeduren in Aktivierungsgruppe *CALLER
4. Service-Programme mit universell einsetzbaren Prozeduren, z.B. Datums-Rechnung, String-Funktionen, Prüf-Routinen etc. in eine benannte Aktivierungsgruppe (z.B. Service-Programm-Name = Aktivierungsgruppe).
Warum sollten auch solche allgemeingültigen Service-Programme x und y Mal aktiviert werden?

Birgitta

... wenn wir schon ins kleingedruckte gehen, dann würde ich 4. dahingehend modifizieren, alle zustandslosen SRVPGMs (klassische Funktionen, bzw. technisch gesehen: kene globalen und keine static Variablen) alle in eine ACTGRP (ich nenne die dann NORECLAIM).

[B.Hauser]

... in der gleich Aktivierungsgruppe gibt es jeden Cursor nur einmal, was bei mehrfachen Aufrufen aus unterschiedlichen Programmen entweder dazu führt, dass das zweite Programm diesen nicht neu öffnen kann (Cursorstate not valid), oder dem ersten Prozess den Cursor zerklopft.
Beim fetch würde sich das dann so auswirken, dass wenn die Programme abwechselnd lesen, jedes Programm nur jeden zweiten Satz zu sehen bekäme.

Das zweite Programm kann den Cursor schließen und dann erneut öffnen!
Das ist aber kein spezielles Problem von SQL, das gleiche Problem hast Du auch beim Lesen über eine Schleife mit native I/O. Das zweite Programm würde einen neuen SETLL machen und einen völlig anderen Satz lesen.
Sauberes Design ist das A und O. Ansonsten hat man mit allem ein Schlamassel.

Birgitta

[BenderD]

Das zweite Programm kann den Cursor schließen und dann erneut öffnen!
Das ist aber kein spezielles Problem von SQL, das gleiche Problem hast Du auch beim Lesen über eine Schleife mit native I/O. Das zweite Programm würde einen neuen SETLL machen und einen völlig anderen Satz lesen.
Sauberes Design ist das A und O. Ansonsten hat man mit allem ein Schlamassel.

Birgitta

... drei einfache Regeln decken 99% aller Fälle ab:
- Programme in ACTGRP(ProgrammName)
- SRVPGM *CALLER
- abweichend davon ist eine Begründung erforderlich!

D*B

[Tonazzo]

... drei einfache Regeln decken 99% aller Fälle ab:
- Programme in ACTGRP(ProgrammName)
- SRVPGM *CALLER
- abweichend davon ist eine Begründung erforderlich!

D*B

OK - dann wäre eine Begründung für Programme in ACTGRP(*NEW)
ihre Anwort auf meine Anfrage nach der Beendigung der benannten
Aktivierungsgruppe mit RCLACTGRP.


Wobei für ein SBMJOB auch bei ACTGRP(ProgrammName) nach Beendigung des Jobs
alles automatisch abgebaut werden sollte. Da die Aktivierungsgruppe doch Jobbezogen ist
und dieser ja beendet ist.

[DEVJO]

Wobei für ein SBMJOB auch bei ACTGRP(ProgrammName) nach Beendigung des Jobs
alles automatisch abgebaut werden sollte. Da die Aktivierungsgruppe doch Jobbezogen ist
und dieser ja beendet ist.

Richtig.
Nochmal der Hinweis mit OVRDBF und OVRPRTF dran denken, dort gibt es einen Parameter Overscope, der MUSS auf *JOB ansonsten bekommt ihr Probleme.

[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

[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