-
*INLR vs. RCLRSC / Aktivierungsgruppen?
Hallo zusammen!
Wir sind gerade dabei unsere alten RPG III Programme nach ILE RPG zu konvertieren und daher arbeite ich mich gerade in die Thematik mit den Aktivierungsgruppen ein. Habe mir dazu auch schon die entsprechenden Threads in diesem Forum durchgelesen. Dabei hab ich mich gefragt was der *INLR genau macht!?
Beim Starten eines OPM Programms wird ja im ersten Schritt der Speicher in der Default Activation Group eingerichtet (Variablen, Datenpfade, PEP ausführen, ...). Ist am Ende des Programms ein MOVE '1' *INLR werden diese wieder freigegeben/geschlossen. Ist jetzt ein Unterschied (in Hinblick auf den verwendeten/freigegebenen Speicher) ob ich den Speicher mittels '1' in *INLR oder mit RCLRSC freigebe?
Und die nächste Frage ist was passiert in einem ILE RPG Programm bei *INLR wenn es
a) in der Standard-Aktivierungsgruppe
b) in einer benannten Aktivierungsgruppe
läuft?
Der Grund warum ich frage ist das fast alle unsere RPG III Programme den MOVE '1' *INLR haben. Mein "Plan" wär im ersten Schritt alle konvertierten Programme mit Aktivierungsgruppe *CALLER zu wandeln. Gleichzeitig kriegt die Menü-Applikation von der aus alle Programme aufgerufen werden eine benannte Aktivierungsgruppe. Einige Anzeige-Programme die die Möglichkeit zum rekursivem Aufruf haben werden mit Aktivierungsgruppe *NEW gewandelt.
Mir ist klar das dann im Zuge der Neuentwicklung einzelner Anwendungen auf das Thema Aktivierungsgruppen noch stärker eingegangen werden sollte aber für den ersten Schritt der Umstellung denk ich ist das ok. Oder seht ihr hier vielleicht noch Probleme die auf mich zukommen könnten?
MfG
Martin Stöberl
-
*INLR = *ON deaktiviert das Programm und entfernt es aus dem Speicher, so dass der nächste Aufruf *INZSR auslöst.
*INLR = *OFF läßt das Programm im Speicher, alle Dateien, Variablen behalten ihren aktuellen Zustand.
RCLRSC entfernt alle aktiven OPM-Programme, die mit *INLR = *OFF noch aktiv sind.
ILE-Programme mit *INLR = *OFF werden NICHT entfernt !!!
Um eine Aktivierungsgruppe zu löschen wird RCLACTGRP benötigt. Dieses löscht die Aktivierungsgruppe und somit auch alle ILE's die mit *INLR = *OFF aktiv sind.
-
 Zitat von Fuerchau
*INLR = *ON deaktiviert das Programm und entfernt es aus dem Speicher, so dass der nächste Aufruf *INZSR auslöst.
*INLR = *OFF läßt das Programm im Speicher, alle Dateien, Variablen behalten ihren aktuellen Zustand.
RCLRSC entfernt alle aktiven OPM-Programme, die mit *INLR = *OFF noch aktiv sind.
ILE-Programme mit *INLR = *OFF werden NICHT entfernt !!!
Um eine Aktivierungsgruppe zu löschen wird RCLACTGRP benötigt. Dieses löscht die Aktivierungsgruppe und somit auch alle ILE's die mit *INLR = *OFF aktiv sind.
ILE-Programme mit Aktivierungs-Gruppe *CALLER, die von OPM-Programmen aufgerufen werden bzw. Programmen, die in der Default-Aktivierungs-Gruppe laufen, werden weder mit RCLRSC noch mit RCLACTGRP freigegeben. Beim erneuten Aufruf werden nur die Variablen initialisiert und *INSR ausgeführt. Default-Aktivierungs-Gruppen werden nur durch das Job-Ende (normal oder abnormal) beendet.
Am einfachsten ist:
1. Alle Programme, die aus einem Menü, von der Befehls-Zeile aufgerufen oder submittet werden erhalten eine benannte Aktivierungs-Gruppe (Aktivierungs-Gruppe = Programm-Name) evt. auch Aktivierungs-Gruppe *New
2. Alle Programme, die nur aus anderen Programmen aufgerufen werden erhalten die Aktivierungs-Gruppe *CALLER.
(Diese Module sollten dann nicht als Programme, sondern Service-Programme erstellt werden).
Birgitta
-
 Zitat von B.Hauser
ILE-Programme mit Aktivierungs-Gruppe *CALLER, die von OPM-Programmen aufgerufen werden bzw. Programmen, die in der Default-Aktivierungs-Gruppe laufen, werden weder mit RCLRSC noch mit RCLACTGRP freigegeben. Beim erneuten Aufruf werden nur die Variablen initialisiert und *INSR ausgeführt. Default-Aktivierungs-Gruppen werden nur durch das Job-Ende (normal oder abnormal) beendet.
Birgitta
Gehst du jetzt davon aus das die ILE-Programme *INLR = *OFF haben? Falls ja: Ich dachte die Variablen werden beim erneuten Aufruf nicht initialisiert?
Ausserdem, wenn ich mir das Beispiel aus dem Redbook ILE Concepts (V5R2M0) auf Seite 96-97 ansehe sieht es schon so aus als ob die Resourcen eines ILE-RPG Programms das in der Standard-Aktivierungsgruppe läuft nach einem RCLRSC wieder freigegeben werden.
Zum Testen: Wie krieg ich raus ob von einem Programm noch Teile im Speicher sind (z.B. Variablen,...). Kann man sich das irgendwo anzeigen lassen?
MfG
Martin Stöberl
-
Testen kannst du das konkret mittels STRDBG, indem du z.B. eine *INZSR-Routine einbaust und dort einen Breakpoint setzt (alternativ ein DSPLY in der *INZSR).
Bei Neu-/Aktivierung wird *INZSR ausgeführt, ansonsten nicht.
-
Wenn ein Modul mit *INLR = *ON verlassen wird, wird IMMER die *INZSR ausgeführt bzw. die Variablen intitialisiert, unabhängig davon, ob eine Aktivierung stattgefunden hat oder nicht.
Wird eine Modul mit Return verlassen, wird die *INZSR nur beim ersten Aufruf ausgeführt bzw. immer dann, wenn eine neue Aktivierung stattgefunden hat. Hat also das rufende Programm die Aktivierungsgruppe *New wird bei dem aufgerufenden Programm die *INZSR jedes Mal ausgeführt.
Wäre dies nicht so, hatte es für manch einen nach der Konvertierung von RPGIII zu RPGIV ein böses Erwachen gegeben.
Prozeduren unterliegen nicht mehr dem Zyklus und sind daher von *INLR und Return unabhängig und können rekursiv aufgerufen werden. Return muss sogar nur angegeben werden, wenn ein Rückgabe-Wert ausgegeben werden muss. Prozeduren erhalten für jeden Aufruf ein neues initialisiertes Variablen Set.
Birgitta
-
OK, ich denke soweit hab ich's begriffen.
Wie sieht es eigentlich bei der Performance (= Zeit zum Initialisieren/Einrichten des Speichers für das Programm) beim ersten Aufruf aus? Macht es da einen Unterschied ob ich das Programm in der Standardaktivierungsgruppe, einer benannten Aktivierungsgruppe oder der Aktivierungsgruppe *NEW laufen lasse?
cu
Martin
-
 Zitat von B.Hauser
ILE-Programme mit Aktivierungs-Gruppe *CALLER, die von OPM-Programmen aufgerufen werden bzw. Programmen, die in der Default-Aktivierungs-Gruppe laufen, werden weder mit RCLRSC noch mit RCLACTGRP freigegeben. Beim erneuten Aufruf werden nur die Variablen initialisiert und *INSR ausgeführt. Default-Aktivierungs-Gruppen werden nur durch das Job-Ende (normal oder abnormal) beendet.
Birgitta
Hast Recht, hab's gerade in ILE Concepts gefunden:
Reclaim Resources Command for ILE Programs
For ILE programs that are created by the CRTBNDxxx command with
DFTACTGRP(*YES) specified, the RCLRSC command frees static storage just as it
does for OPM programs. For ILE programs that are not created by the
CRTBNDxxx command with DFTACTGRP(*YES) specified, the RCLRSC command
reinitializes any activations that have been created in the default activation group
but does not free static storage. ILE programs that use large amounts of static
storage should be activated in an ILE activation group. Deleting the activation
group returns this storage to the system. The RCLRSC command closes files
opened by service programs or ILE programs running in the default activation
group. The RCLRSC command does not reinitialize static storage of service
programs and does not affect nondefault activation groups.
cu
Martin
Similar Threads
-
By shorty in forum NEWSboard Drucker
Antworten: 7
Letzter Beitrag: 20-12-06, 16:11
-
By Beffe in forum NEWSboard Programmierung
Antworten: 6
Letzter Beitrag: 08-11-06, 15:43
-
By y-richy in forum IBM i Hauptforum
Antworten: 1
Letzter Beitrag: 10-08-06, 13:59
-
By Stoeberl in forum NEWSboard Server Software
Antworten: 1
Letzter Beitrag: 29-06-06, 14:56
-
By Andreas.Meyer in forum IBM i Hauptforum
Antworten: 6
Letzter Beitrag: 11-06-06, 09:08
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks