Serviceprogramm und Speicher

[BenderD]

Ein Service-Programm kann auch ACTGRP(*CALLER) haben. Dann wird das Programm eben zusammen mit der ACTGRP des Aufrufers rausgeschmissen.
Das hat auch den Effekt, dass das Programm mehrfach, eben je ACTGRP, im Speicher liegen kann.
Zu bedenken ist, dass Serviceprogramme ja von verschiedenen Hauptprogrammen aufgerufen werden und somit SQL-Cursor vom Einen durch Andere zerstört werden können.

Ein RCLACTGRP ACTGRP(*ELIGIBLE) hat ggf. bei Triggerprogrammen in eigenen ACTGRP's die Auswirkung, dass der Job beendet werden muss.
Die weitere Ausführung der Trigger ist nicht mehr möglich. Dies könnte jedoch releaseabhängig und durch PTFs behoben sein.

Datenbankmodule, wie vom OP angeführt, müssen ACTGRP(*CALLER), was üblicherweise default ist, haben, sonst wären sie nicht Transaktionsfähig (commit) und der Transaktionsmaster muss eine eigenen benannte ACTGRP oder *NEW haben - dann funzt das auch mit Cursor etc. wie gewollt.

Bei den Trigger Programmen ist das ähnlich: ein Triggerprogramm in einer eigenen ACTGRP ist ein Kunstfehler, die müssen immer *CALLER haben - trotzdestonichts ist das beschrieben Verhalten für den abstrusen Fall (es gibt immer wieder Leute, die es gerne kompliziert haben) als Bug anzusehen.

D*B

[Tonazzo]

Unsere Serviceprogramme laufen alle unter der Aktivierungsgruppe *CALLER.
Wir haben auch keine explizite Beendigung einer Aktivierungsgruppe.

Klassischer Fall:
Programme werden aus Menüs aufgerufen, benutzen die Serviceprogramme und werden beendet.
Es sollte doch dann alles unter der Aktivierungsgruppe QILE und entsprechend unter Job Scope laufen oder?

Zugriffe von anderen Hauptprogrammen und der verschiedenen Benutzer sollten sich doch somit nicht in die Quere kommen - oder habe ich da was missverstanden. Oder verhält sich das Serviceprogramm (inklusive Daten) wie ein Singleton in Java ?!?

[BenderD]

Unsere Serviceprogramme laufen alle unter der Aktivierungsgruppe *CALLER.
Wir haben auch keine explizite Beendigung einer Aktivierungsgruppe.

Klassischer Fall:
Programme werden aus Menüs aufgerufen, benutzen die Serviceprogramme und werden beendet.
Es sollte doch dann alles unter der Aktivierungsgruppe QILE und entsprechend unter Job Scope laufen oder?

Zugriffe von anderen Hauptprogrammen und der verschiedenen Benutzer sollten sich doch somit nicht in die Quere kommen - oder habe ich da was missverstanden. Oder verhält sich das Serviceprogramm wie ein Singleton in Java ?!?

... alles in QILE laufen zu lassen ist nicht sinnvoll, damit ist nicht sichergestellt, dass zwei Programme im Callstack sich gegenseitig den einen Cursor, den sie haben kaputt machen. Besser ist m.E. Name der ACTGRP = Programmname, dann ist jedes Programm für seine abhängigen Cursor selber verantwortlich. Falls über Verzweigungen rekursiv aufgerufen werden könnte, ist *NEW erforderlich.

Ein wesentlicher Unterschied zwischen der ILE runtime und Java ist, dass sich in Java mehrere Benutzer eine JVM teilen, also gemeinsame Ressourcen (shared Memory) haben, Bei ILE hat jeder Job seine eigene abgeschottete Umgebung, mehrere Jobs haben (aus Benutzersicht) kein shared memory.
Ein weiterer wesentlicher Unterschied ist, dass ich in Java die Lebensdauer aller Objekte selber kontrolliere, in ILE ist das nur sehr eingeschränkt möglich (erkennt man daran, dass es kein new gibt und die Erzeugung von (runtime) Objekten automatisch passiert (also immer nur eines pro ACTGRP, oder nur kurzlebige := ACTGRP(*NEW)) zudem muss das alles schon zur compiletime festgelegt werden.

D*B