Proceduraufruf auf variable ?

[Robi]

Hi *all
wenn ich einen Programmnamen zur Laufzeit erst zusammenbaue, und trotzdem mit callb arbeite, geht das mit
eval call = %Paddr(variable)
callb call parm ...

Was muß ich machen um eine Procedur aufzurufen

eval prc = %paddr(variable)
eval wert = prc(x:y:z)

so geht es leider nicht

geht das überhaubt
Danke Robi

[B.Hauser]

Hi *all
wenn ich einen Programmnamen zur Laufzeit erst zusammenbaue, und trotzdem mit callb arbeite, geht das mit
eval call = %Paddr(variable)
callb call parm ...

Was muß ich machen um eine Procedur aufzurufen

eval prc = %paddr(variable)
eval wert = prc(x:y:z)

so geht es leider nicht

geht das überhaubt
Danke Robi

Hallo Robi,

wie sieht den Dein Prototyp aus?

In dem folgenden Beispiel gibt es 3 Prozeduren (Wochentag auf Deutsch, Englisch, Französisch). Jede dieser Prozeduren hat einen eigenen Prototypen.

Um diese Prozeduren variabel aufrufen zu können, musst Du einen zusätzlichen Prototypen generieren mit dem Schlüssel-Wort ExtProc und einer Variablen für den Procedure Pointer.

Der Aufruf erfolgt dann mit diesem Prototypen.

D DayWeekPP       PR            10A   varying extproc(MyProcPtr)
D  DayNum                        3U 0 const 

Der Aufruf sieht dann wie folgt aus:

D MyProcPtr       S               *   ProcPtr  
D DayDeutsch      C                   %PAddr('DAYWEEKD') 
 *---------------------------------------------------------
 /Free
   Select;                                    
   when MyFld = 'F';               
        MyProcPtr = %PAddr('DAYWEEKF');        
   when MyFld = 'E';               
        MyProcPtr = %PAddr('DAYWEEKE');
   other;               
        MyProcPtr = DayDeutsch;
   EndSL;

   Ergebnis = DayWeekPP(MyParm); 
 /End-Free 

Birgitta

[Robi]

Suuuper, danke
das mit dem extProc hatte ich nicht
Danke
Robi

[BenderD]

Hallo,

wobei bei dieser Variante für die %PADDR BIF ein Literal verwendet werden muss und die entsprechenden Prozeduren zur Compile Time gebunden werden.
Eleganter geht das, wenn man sich die Procedure Pointer per API holt, dann braucht man zur Laufzeit nur den Namen der Prozedur, den Namen des Serviceprogramms und einen passenden Prototyp wie im obigen Beispiel.
Ein ServiceProgramm, das per API zur Laufzeit bindet ist auf meiner Open Source Seite zu finden.
Weiter Vorteile des dynamischen Bindens zur Laufzeit sind, dass man erst bindet, wenn die Prozedur das erste mal benötigt wird und man kann auch nach einem RCLACTGRP ohne Probleme erneut Binden.


mfg

Dieter Bender

Hallo Robi,

wie sieht den Dein Prototyp aus?

In dem folgenden Beispiel gibt es 3 Prozeduren (Wochentag auf Deutsch, Englisch, Französisch). Jede dieser Prozeduren hat einen eigenen Prototypen.

Um diese Prozeduren variabel aufrufen zu können, musst Du einen zusätzlichen Prototypen generieren mit dem Schlüssel-Wort ExtProc und einer Variablen für den Procedure Pointer.

Der Aufruf erfolgt dann mit diesem Prototypen.

D DayWeekPP       PR            10A   varying extproc(MyProcPtr)
D  DayNum                        3U 0 const 

Der Aufruf sieht dann wie folgt aus:

D MyProcPtr       S               *   ProcPtr  
D DayDeutsch      C                   %PAddr('DAYWEEKD') 
 *---------------------------------------------------------
 /Free
   Select;                                    
   when MyFld = 'F';               
        MyProcPtr = %PAddr('DAYWEEKF');        
   when MyFld = 'E';               
        MyProcPtr = %PAddr('DAYWEEKE');
   other;               
        MyProcPtr = DayDeutsch;
   EndSL;

   Ergebnis = DayWeekPP(MyParm); 
 /End-Free 

Birgitta

[Robi]

Hallo Dieter,
Du hast (leider) Recht,
wir haben drei Variablen die z.B. mit 'M' 'DT' 'TT' gefüllt werden. Daraus ergibt sich ein Procedurname CLC_MDTTT
und ein coding : eval wert = procedurname(feld1:feld2)
Das geht so nicht, es sei denn ich weiß alle möglichen Inhalte und kombinationen der drei variablen und erfasse eine Select Gruppe wie es bei Brigittas beispiel ist. Da uns das zu Starr ist werden wir mal auf deiner Freeware Seite wildern. Bei erfolg werde ich mich auf jedenfall noch mal melden.

Der Vorteil, das die Procedur nicht zum Programmaufruf geladen wird, ist genial. So kann ein Trigger Proceduren verwenden, und bricht auch nicht ab, wenn er aus neutraler Umgebung aufgerufen wird(SQL-Upd ohne gute Lib.list)

Erstmal vielen Dank
Robi

[Fuerchau]

Da würde ich mich eher fragen, was diese Prozeduren denn so geniales treiben ?
Sieht mir irgendwie nach Datumskonvertierungen aus, die mit RPGLE auch direkt gehen.

[Robi]

Hi,
fast richtig,
der Benutzer(EDV-Leiter) erfasst in einer Formeldatei <feldname>xx mit xx = TT für Tag, mm für Monat ... bis zm für Zeitmarke. eine Formel sieht dann z.b. so aus :
TT = &Heute - <feld1>DT - <feld3>tt
Ein Pgm ermittelt die Feldwerte und bedient sich der Dynamischen Servicepgmme.
Die rechnen und geben einen Wert und eine definierte Einheit zurück.
erst clc_mdtdt, (rückgabe = TT)
dann CLC_mtttt, (rückgabe TT)
(Klammern würden berücksichtigt)

Das Ergebnis der Formel kann im Subfile angezeigt werden oder auf Listen gedruckt. Bei der Erfassung wird die Existenz des Servicepgm's geprüft und die Formel ggf. abgewiesen. Neue Ideen erfordern nur neue Servicepgmme. (umrechnung von Durchmesser nach Laufmeter ...)

was immer auch kommt, wir können es ...
Gruß
Robi

[Robi]

Grade, aus der Praxis, eine neue Anforderung.
TV für Tage unter Berücksichtigung des Versandkalenders

Bsp. Lieferdatum - Liefertage unter Berücksichtigung des Versandkalenders = abfahrtsdatum ( ergänzbar um anliefeungszeit, beladezeit ...)

Wenn das Pgm steht, braucht nur ein Srvpgm nachgeliefert werden.
Robi

[Fuerchau]

Dann würde ich empfehlen, die Funktionen als eigenständige Programme aufzurufen anstatt Serviceprogramme zu verwenden.
Vorteile:
- Kein Binden von Serviceprogrammen
- Aufruf mit Variable
Die Performance ist weiterhin gut, da nur der 1. Aufruf eines Programmes etwas dauert.

[Robi]

Haben die Definitionen von Dieter kopiert und integriert.
funktioniert Prima. ist auch schnell genug
Danke Dieter und Brigitta

@Fuerchau
So hätten wir es früher gemacht. Die halbe Software arbeitet so. (siehe fragestellung oben) Dies ist mal was neues. und irgendwie sexy

Wenn ich alles richtig verstanden habe, müßte ich, wenn ich Proceduren immer so rufe, diese jederzeit im laufenden Betrieb tauschen können, da die PRC immer neu geöffnet / ermittelt wird. Hört sich langsam an, is aber ok

Gruß
Robi

[BenderD]

Hallo,

wenn man die bereits geladenen Procedures cached, dann ist das genauso schnell, wie statisch gebunden. Wenn man die nicht cached, macht auch nicht soviel aus, weil die Aktiviwerung erhalten bleibt solange die Activation Group lebt.
Diese Technik des dynamischen bindens ist inter anderem im Einsatz in einem Ladeprozess für ein Datawarehouse mit Millionen von Transaktionen, wo es in erster Linie auf optimale Performance und erst in zweiter Hinsicht auf Flexibilität ankommt.

mfg

Dieter Bender

Haben die Definitionen von Dieter kopiert und integriert.
funktioniert Prima. ist auch schnell genug
Danke Dieter und Brigitta

@Fuerchau
So hätten wir es früher gemacht. Die halbe Software arbeitet so. (siehe fragestellung oben) Dies ist mal was neues. und irgendwie sexy

Wenn ich alles richtig verstanden habe, müßte ich, wenn ich Proceduren immer so rufe, diese jederzeit im laufenden Betrieb tauschen können, da die PRC immer neu geöffnet / ermittelt wird. Hört sich langsam an, is aber ok

Gruß
Robi

[BenderD]

@Baldur: Das ist doch gerade der Witz an der Sache mit dem API, dass kein statisches Binden erforderlich ist. Den Hauptvorteil bei der Verwendung von Procedures versus Programme sehe ich in:
- Langnamen möglich
- Call by Value möglich
- Rückgabe Variablen möglich
- multi entrante Serviceprogramme
Dass die Performance optimal ist, ist nur ein Nebeneffekt, der feinstkörnige Modularisierung ermöglicht.
Ein anderer Nebeneffekt ist, dass die Schwächen des originalen Aktivierungsprozesses überwunden werden; beim RCLACTGRP kann ich im Errorhandler einfach nachbinden.

mfg

Dieter

Dann würde ich empfehlen, die Funktionen als eigenständige Programme aufzurufen anstatt Serviceprogramme zu verwenden.
Vorteile:
- Kein Binden von Serviceprogrammen
- Aufruf mit Variable
Die Performance ist weiterhin gut, da nur der 1. Aufruf eines Programmes etwas dauert.