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.

[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

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