Serviceprogramm und Speicher

[DEVJO]

Ich würde das etwas eingrenzen:
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

Schon richtig, aber wenn man beginnt mit Activation Groups zu arbeiten, finde ich persönlich, kann man auf die paar Millisekunden und das doppelte laden durchaus hinweg sehen. Sollte man an dieser Stelle Fehler machen, kann am Ende das ganze Projekt scheitern. Erst mal Erfahrungen sammeln und dann die Services identifizieren, die "Zustandslos" sein können und dann diese in eine benannte Group packen.... macht die Sache gerade am Anfang einen Tick leichte.

[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.

[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]

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).

[Tonazzo]

Vielen Dank an alle Beteiligten für die gute und schnelle Unterstützung.

[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]

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

[Fuerchau]

ACTGRP(*NEW) wird automatisch aufgelöst, wenn das oberste Programm returniert. Dabei ist es unerheblich, ob *INLR *on oder *off ist.
*New ist ggf. erforderlich wenn man Programme (ohne nomain) rekursiv aufruft und eigene Commit-Grenzen braucht.
Der Nachteil sind sicherlich die getrennten Commit-Definitionen, da hat jede ACTGRP seine Eigene.
Wird *NEW z.B. aufgelöst, wird automatisch ein Rollback durchgeführt.
Trigger in eigene ACTGRP's zu stellen macht manchmal schon Sinn, liegt aber halt an der Aufgabenstellung zumal diese ja im Rollbackfall auch wieder aufgerufen werden.

Eine eigene ACTGRP lohnt sich z.B. für einen "Sperrservice" der über mehrere Commit-Grenzen bestehen bleiben muss. Dies geht mit dann mit diversen Satzsperren die mit MyLock(Key)/MyUnlock(Key) aufgerufen werden können und automatisch bei Jobende rausfliegen (war irgendwann mal Dieters Vorschlag).

Diverse benannte ACTGRP's machen also durchaus Sinn.

Es gibt z.B. auch 2 DFTACTGRP's, die 1. ist für Systemprogramme, die 2. für eigene Programme. Da nützt auch *CALLER nichts, die 1. ist einfach tabu.

[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.

[BenderD]

ACTGRP(*NEW) wird automatisch aufgelöst, wenn das oberste Programm returniert. Dabei ist es unerheblich, ob *INLR *on oder *off ist.
*New ist ggf. erforderlich wenn man Programme (ohne nomain) rekursiv aufruft und eigene Commit-Grenzen braucht.
Der Nachteil sind sicherlich die getrennten Commit-Definitionen, da hat jede ACTGRP seine Eigene.
Wird *NEW z.B. aufgelöst, wird automatisch ein Rollback durchgeführt.
Trigger in eigene ACTGRP's zu stellen macht manchmal schon Sinn, liegt aber halt an der Aufgabenstellung zumal diese ja im Rollbackfall auch wieder aufgerufen werden.

Eine eigene ACTGRP lohnt sich z.B. für einen "Sperrservice" der über mehrere Commit-Grenzen bestehen bleiben muss. Dies geht mit dann mit diversen Satzsperren die mit MyLock(Key)/MyUnlock(Key) aufgerufen werden können und automatisch bei Jobende rausfliegen (war irgendwann mal Dieters Vorschlag).

Diverse benannte ACTGRP's machen also durchaus Sinn.

Es gibt z.B. auch 2 DFTACTGRP's, die 1. ist für Systemprogramme, die 2. für eigene Programme. Da nützt auch *CALLER nichts, die 1. ist einfach tabu.

... jetzt kommen wir ins kleingedruckte:
@ commit und endactgrp: RCLACTGRP schickt bei offenen Transaktionen im default ein commit hinterher (da haben ein paar Entwickler nix verstanden und gemeinsam intensiv an Dummfug gedacht. Fred Feuerstein hätte da gesagt: "di hatten wohl nicht alle Steine auf der Schleuder")

@ Sperrservice: ursprünglich haben wir das in einem Projekt für Jobsteuerung (wechselseitige Ausschlüsse und warten auf Jobende anderer Jobs) benutzt. Das ist aber kein Regelfall und da gibt es noch ein paar Dinge zu beachten (wg. Deadlocks etc.)

D*B

[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.