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.

[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

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

[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