View Full Version : Parameter des aurufenden Programms ermitteln
Hallo zusammen!
Seit 2 Tagen schlage ich mich mit folgendem Problem rum. Aus einem ILERPG-Programm rufe ich eine Prototyped-Procedure auf. In dieser Procedure möchte ich auf die Parameter des aufrufenden Programms zugreifen.
Mittlerweile habe ich herausgefunden, das mir die API QWVRCSTK Informationen über das aufrufende Programm geben kann. Aber weiter komme ich an der Stelle nicht.
Desweiteren habe ich festgestellt, dass die Offsets zu den Parameter immer 32Bit auseinander liegen. Wenn das generell so ist, würde es mir ja reichen die Adresse des ersten Parameters zu übergeben. Aber ist das auch wirklich immer so?
Vielen Dank schon mal im voraus.
Auf Adressen des rufenden Programmes zuzugreifen ergibt meistens MCH-Fehler.
Die Parameter lassen sich auch nicht ermitteln, da Parameterlisten ganz anders übergeben werden als z.B. in C/C++.
Wozu soll das ausserdem gut sein ?
Programme/Funktionen bekommen ihre Parameter immer übergeben, die sie benötigen !
Der Hintergund ist folgender:
Diverse Programme werden durch ein übergeordnetes Programm steuernd aufgerufen. Dabei könne die Programm sowohl parallel als auch sequentiell abgearbeitet werden. Das steuernde Programm muss nun wissen, wann sich die einzelnen Programme beenden um weitere Aktionen auszuführen.
Dazu habe ich ein Modul erstellt, welches entsprechende Einträge in einer Tabelle vornimmt. Dieses Modul benötigt nun die selben Parameter wie das aufgerufene Programm.
Ich möchte jetzt lediglich die "Tipparbeit" für den Modul-Aufruf klein halten.
Anstelle von
LogOff(#MAND:#ID:#STEP:#TASK) fände ich es angenehmer nur
LogOff() eingeben zu müssen.
Frank Hildebrandt
28-03-07, 14:48
Definiere den Prototyp folgendermaßen.
d pr logoff
d 10a options(*nopass)
d 10a options(*nopass)
d 10a options(*nopass)
d 10a options(*nopass)
In der Prozedur "logoff" kannst dann folgendes abfragen.
if %parms = 0, wenn logoff folgendermaßen aufgerufen wurde LogOff()
if %parms = 4, wenn logoff folgendermaßen aufgerufen wurde LogOff(#MAND:#ID:#STEP:#TASK)
Hallo,
erst mal der guten Ordnung halber: parallel läuft im RPG in einem Job nix, das geht immer sequentiell.
Den Informations Übergang könnte man auch durch Variablen Export/Import lösen, das ist aber vom Design her eher schlechtallerdings immer noch besser als dein (wohl nicht Ziel führender) Versuch.
mfg
Dieter Bender
Der Hintergund ist folgender:
Diverse Programme werden durch ein übergeordnetes Programm steuernd aufgerufen. Dabei könne die Programm sowohl parallel als auch sequentiell abgearbeitet werden. Das steuernde Programm muss nun wissen, wann sich die einzelnen Programme beenden um weitere Aktionen auszuführen.
Dazu habe ich ein Modul erstellt, welches entsprechende Einträge in einer Tabelle vornimmt. Dieses Modul benötigt nun die selben Parameter wie das aufgerufene Programm.
Ich möchte jetzt lediglich die "Tipparbeit" für den Modul-Aufruf klein halten.
Anstelle von
LogOff(#MAND:#ID:#STEP:#TASK) fände ich es angenehmer nur
LogOff() eingeben zu müssen.
Da du ILERPG benennst, kann ich Dieter nur zustimmen.
Parallelverarbeitung gibts da nicht.
Entweder die Funktion/das Programm ist aktiv, oder das rufende Programm ist aktiv.
Falls du C-Funktionen für Threads verwendest, dann lass die Finger davon, da RPG/ILERPG nicht threadsave ist (automatic/static Storage).
Definiere den Prototyp folgendermaßen.
d pr logoff
d 10a options(*nopass)
d 10a options(*nopass)
d 10a options(*nopass)
d 10a options(*nopass)
In der Prozedur "logoff" kannst dann folgendes abfragen.
if %parms = 0, wenn logoff folgendermaßen aufgerufen wurde LogOff()
if %parms = 4, wenn logoff folgendermaßen aufgerufen wurde LogOff(#MAND:#ID:#STEP:#TASK)
Das bringt mich nicht weiter, da ich in dem Modul die Parameter benötige.
erst mal der guten Ordnung halber: parallel läuft im RPG in einem Job nix, das geht immer sequentiell.
Mein steuerndes Programm ruft die "Unterprogramme" per SBMJOB auf. Das meinte ich mit parallel.
Ich habe es jetzt erstmal so gelöst, dass ich meine Parameter in eine Datenstruktur packe und den Zeiger auf die Datenstruktur übergebe. Somit habe ich nur einen (konstanten) Parameter den ich übergeben muss. Damit habeich dann auch die Tipperei ein wenig eingeschränkt. ;)
Trotzdem vielen Dank für euer Bemühen.
jo, datenstruktur issn plan.
schreibs in die *LDA
die wird beim sbmjob ja mitgegeben.
und du hast keine komischen dtaaras auf platte rumliegen, die du nacher wieder aufräumen musst.
dann brauchst du eigentlich gar keine parameter fürs logoff()
Hallo,
das geht auch einfacher: du brauchst nur die Datenstruktur als Parameter übergeben, das macht bereits dasselbe ohne Pointer.
Ich würde zur Kommunikation der Tochterprozesse mit dem steuernden Prozess DataQs oder Messages vorziehen.
Anzumerken hätte ich noch, dass ein sterbender Prozess, normalerweise nix einträgt (lässt sich mit CEE4RAGE weitest gehend verhindern) und damit kriegst du eine nicht auflösbare Wartebedingung. Zuweilen ist es auch ganz gut, wenn man so einen Tochterprozess einen Lock auf einen Monitor machen lässt (DTAARA dxxxxxx mit xxxxxx = Jobnummer), oder einen Recordlock auf einen Eintrag in einer Spertable, dann kann man bequem warten, bis der fertig ist, oder feststellen ob der noch lebt.
mfg
Dieter Bender
Das bringt mich nicht weiter, da ich in dem Modul die Parameter benötige.
Mein steuerndes Programm ruft die "Unterprogramme" per SBMJOB auf. Das meinte ich mit parallel.
Ich habe es jetzt erstmal so gelöst, dass ich meine Parameter in eine Datenstruktur packe und den Zeiger auf die Datenstruktur übergebe. Somit habe ich nur einen (konstanten) Parameter den ich übergeben muss. Damit habeich dann auch die Tipperei ein wenig eingeschränkt. ;)
Trotzdem vielen Dank für euer Bemühen.
@angelone. Danke!
Das ist genau die Lösung, nach der ich gesucht habe.
@BenderD: Mit DataQueues arbeiten wir mittlerweile auch an anderer Stelle. Aber diese "Prozesssteuerung" ist mittlerweile so "alt" gewachsen, dass ich die sehr ungerne komplett umstellen möchte.
Den sterben Prozess fange ich im steuernden Programm mit einer maximalen Laufzeit ab, die ich dem Unterprozess zu Verfügung stelle. Dein Vorschlag würde den Tod natürlich schneller feststellen.