View Full Version : Serviceprogramm und Speicher
OK dann habe ich H. Bender missverstanden....
Also Trigger und Serviceprogramme alle in *CALLER
Und die entsprechenden Hauptprogramme, die verschiedene Serviceprogramme etc. benutzen in
benannte Activation Group.. PgmName = Name der Activation Group.
Das sollte es dann aber gewesen sein.... Alles nicht so einfach ;-)
Also Trigger und Serviceprogramme alle in *CALLER
Und die entsprechenden Hauptprogramme, die verschiedene Serviceprogramme etc. benutzen in
benannte Activation Group.. PgmName = Name der Activation Group.
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
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.
Ist es sinnvoll nach Beendigung der Hauptprogramme (Menü, Submit) die benannte
Aktivierungsgruppe mit RCLACTGRP auch zu beenden oder riskiere ich damit enventuell irgendwelche
Datenverluste.
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.
... 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
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).
Vielen Dank an alle Beteiligten für die gute und schnelle Unterstützung.
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
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