Serviceprogramm und Speicher

[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