Proceduraufruf auf variable ?

[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.