RCLRSC Verständnisproblem

[EFueloep]

Ich vermute das System "vergißt" den Aufruf von Pgm R2 wenn R1 beendet wird. Obwohl R1 ja weiterhin "aktiv" ist weil es ohne LR beendet worden ist.
Aber die "current invocation" von R1 wurde beendet.

Daher funktioniert ein RCLRSC beim zweiten Aufruf von R1 nicht weil in diesem zweiten Aufruf R2 noch nicht aufgerufen worden ist. Daher "weiß" das System (oder ignoriert es) nicht mehr, dass eigentlich R2 auch schon vorher von R1 aufgerufen worden ist.

So klingt es für mich zumindest mit dem Helptext plausibel.

Wenn Dich dies weiterhin stört hiflt wohl nur mehr ein Anruf beim IBM Helpdesk und eine Eröffnung eines PMR um dieses Problem näher zu analyisieren.

[emax]

Wie ist den das mit der 'current invocation'. Ich glaube, wenn ich dazu etwas Genaueres finden könnte, käme ich ein Stück weiter.

Mal heisst das in der Dokumentation 'current-invocation' dann finde ich 'run-level', dann wieder 'stack'. Da ich nun in Erinnerung habe, dass von RCLRSC alle 'höheren run-level' betroffen sind, scheint mir der Schlüssel zum Problem in diesem Wert zu liegen.

hat jemand dazu vielleicht einen Hinweis oder Link?



PS: Nur mal zur Erläuterung: Wir implementieren hier etwas, was die RCLRSC Funktionalität nachbilden soll, deshalb möchte ich es so genau wissen.

[Fuerchau]

RCLRSC nachbilden?
Vergiss es, da gehört eigentlich ziemlich viel dazu.
Ausserdem gibts ja auch noch den RCLACTGRP!

[emax]

Vergiss es

Bei einem im achten Jahr laufenden Projekt ist das keine gute Option.

Ausserdem gibts ja auch noch den RCLACTGRP!

Sie oben: Nur OPM.

[Fuerchau]

Wie Dieter nun sagen würde, Fehler im Design.

Wenn du sicher sein willst, dass der folgende Aufruf eines OPM's immer mit *INZSR beginnt, verwende eben die "FREE"-Anweisung.
Diese entfernt das Programm nach dem CALL.

[Fuerchau]

Ich habe noch mal in die RPG-Handbücher geschaut. Die FREE-Anweisung ist da irgendwie verschwunden!

Also:

CALL 'MYPGM'
FREE 'MYPGM'

oder

CALL VARPGM
FREE VARPGM

[emax]

Wie Dieter nun sagen würde, Fehler im Design.

Inwiefern?

Wenn du sicher sein willst, dass der folgende Aufruf eines OPM's immer mit *INZSR beginnt, verwende eben die "FREE"-Anweisung.

Das weiss ich ja. Aber dass das und wie das auf einer AS400 funktioniert ist ja nicht das Problem. Außerdem ist FREE nicht dasselbe wie RCLRSC, weil FREE (nach meiner Kenntnis) die Files nicht schließt.

Aber vielleicht sollte ich mal ein bisschen aus dem Nähkästchen plaudern, weil sonst das Problem schlecht nachvollziehbar ist.

Wie arbeiten an einer RPG und CL Konvertierung in C++. Der Kunde hat ca.30 Millionen Lines of Code in RPG, davon können wir aktuell knapp 90 Prozent umsetzen. Wichtig ist: Es geht hier (fast) ausschließlich um das OPM.

Nun ist es eine der wesentlichen Eigenschaften von RPG (bzw. der AS400), dass Programme nach dem verlassen ihren Status behalten, sofern man nicht LR setzt. Das ist natürlich ein kolossal wichtiges Feature, welches wir auch sehr präzise unterstützen.

Für eine korrekte CL-Umsetzung müssen wir nun natürlich genau verstehen, was RCLRSC tut. Es tut übrigens, weil das oben kurz erwähnt wurde, im Prinzip exakt das gleiche wie RCLACTGRP, nur das man eben im ILE die Activation Groups benennen kann, und im OPM immer die default Activation Group gilt. Somit ist ILE sehr viel flexibler, und weil das reine RCLRSC Konzept das nicht hergibt, hat man damals für die erweiterten ILE-Möglichkeiten eben RCLACTGRP geschaffen.

Aber soviel nur am Rande, es ja um das OPM.

Mit dieser Information ist es sicher einleuchtend, dass mir alternative Wege, die ich auf einer AS400 beschreiten könnte, nicht so viel nützen. Ich muss einfach nur verstehen, wie RCLRSC exakt funktioniert.

[Fuerchau]

Die Anweisung FREE gibt das aufgerufene Programm frei und schließt auch alle Dateien dieses Programmes.

Hinter FREE und Return mit *INLR = *ON verbirgt sich die selbe MI-Anweisung zur Deaktivierung der Instanz, wobei im Programm selber ggf. noch Puffer von O-Dateien weggeschrieben werden.
Free macht das nicht, sondern alle Ressourcen des Programmes werden freigegeben.
Allerdings betrifft das nur diesen Aufruf, Ressourcen, die durch weitere Unterprogramme belegt wurden werden natürlich nicht freigegeben, hier hilft tatsächlich nur RCLRSC.

Call-Stack und Aktivierung sind leider zwei verschiedene Dinge.
Beim 1. Aufruf wird ein Programm aktiviert und bekommt intern halt eine Aktivierungs-ID.
Danach erfolgt der Aufruf, so dass das Programm nun im Callstack steht und nach Return wieder verschwindet.

[emax]

Die Anweisung FREE gibt das aufgerufene Programm frei und schließt auch alle Dateien dieses Programmes.

Aus dem RPG-Handbuch, FREE Opcode, IBM c0918170, Seite 259:

"The FREE operation removes a program from the list of activated programs, frees static storage, and ensures program initialization (first cycle processing) the next
time the program is called. It does not close files or unlock data areas.

[Fuerchau]

Ich glaube auch die IBM weiß nicht was da läuft.
"removes a program from the list of activated programs"

Wenn also das Programm deaktiviert ist, versucht es beim nächsten Aufruf auch wieder die Open, die dann auf die nase fallen würden.
Aber ich probier das einfach mal aus .

[emax]

Tja die IBM Doku ist zwar sehr umfangreich, aber in vielen Fällen schlicht 'fuzzi'. Ich konnte eine Menge Dinge im Projekt nur aufgrund meiner Berufserfahrung designen, erklären konnte ich es den Kollegen nicht: "Das war schon immer so"

Ich nehme an, dass die offenen Dateien für ODPs sind, also gemeinsame File Pointer. Aber siehe oben: 'ich nehme an' ;-)

Danke fürs Probieren!

[Fuerchau]

ODPS gelten für tatsächlich gemeinsame Open (SHARE *YES), die man naturgemäß vermeiden sollte.
Einzig SQL verwaltet diese ODP's meistens korrekt.
Ein Notclose (FREE/RCLRSC) zählt dann halt die Anzahl Open zurück und schließt den ODP wenn der Zähler auf 0 geht und killt Locks.

Ressourcen, die auf anderem Wege gehalten werden (z.B. C-Funktionen open() oder ähnliches) sind davon leider nicht betroffen. Die schafft mit unter auch nicht der RCLRSC. Diese weden erst bei Auflösung der ACTGRP freigegeben, was bei der Default-ACTGRP leider erst bei Jobende möglich ist.