... C# ist nicht meine Heimatbaustelle, aber das ist ja ziemlich analog zu Java.
- DFTACTGRP ist OPM und das lässt man besser bleiben - Altlasten.
Fangen wir mal an mit *PGM und *SRVPGM:
- beides Klassen, *PGM mit Main, *SRVPGM ohne main.
- im Gegensatz zu C# und Java, hat RPG/COBOL keinen new Operator, die "Erzeugung", die man auf der AS/400 "Aktivierung" nennt, geschieht automatisch bei der ersten Verwendung.
- erzeugt werden Objekte pro ACTGRP
- ACTGRP *NEW sind Einmalobjekte, die abgeräumt werden, sobald man die zuerst aufgerufene Procdure (= Methode) verlässt.
- alle anderen ACTGRPs existieren, bis jemand das beendet - spätestens wenn der JOb endet, ist Schluss. Beendet wird mit CL Befehl RCLACTGRP (Vorsicht, hier waren Deppen am Werk - offene Transaktionen werden per default committed).

- Jetzt gibt es schon ein paar Schlussfolgerungen:
- ACTGRP *new sind ex und hopp Objekte
- named ACTGRP kann es nur 1 Objekt geben (sind also alle class Variablen faktisch static!!!=
- ACTGRP *CALLER kann es mehrere Objekte zur Laufzeit geben, ist aber kaum steuerbar.

Jetzt komen noch ein paar nette Fallstricke:
- mit embedded SQL darf man nicht connecten, das geht auch automatisch, also wieder nur einmal pro Objekt.
- Ebene des Connects ist die ACTGRP, alles, was in eine Transaktion gehört, muss also in derselben ACTGRP stattfinden.
- mit RCLACTGRP wird alles im Callstack drunter abgeräumt, alles was oben drüber war, geht bei der nächsten Verwendung schief (Pointerfehler).

Bevor man das wirklich verarbeitet und verinnerlicht hat (manche lernen's nie und spielen trotzdem damit rum!), sollte man sich auf ein paar wenige Dinge beschränken:
- SRVPGM *CALLER
- Programme ACTGRP(Programmname)
- kein OPM ILE mix
- kein OVRDBF und OVRPRTF (falls Du das nicht kennst, bleibe dabei!)

D*B