User Defined Function in SQL, Datumsübergabe an Serviceprogramm

[BenderD]

Was ich halt meinte, dass man die Aufrufart einer RPG-Prozedur nicht mischen sollte.
Durch "parameter style General" kann ich die Prozedur via SQL oder eben auch native via CALLP verwenden was eben zu verhindern gilt.

... Einspruch: grundsätzlich gilt, dass eine Funktionalität auch nur eine Implementierung hat. Wenn man aus irgendeinem Grund, sei es technische Restriktion (wie hier), oder auch Bequemlichkeit, oder Lesbarkeit mehrere Varianten für die Parameterschnittstelle braucht, so bieten moderne Programmiersprachen (=> RPG ist keine davon) hierfür die Möglichkeit der Überladung.
Bei überladenen Funktionen ist es gängige Praxis, dass es hier nur eine Impelmentierung gibt und die anderen als Adapter fungieren, sprich: Parameterschnittstelle anpassen und die eigentliche Implementierung aufrufen.
Das Problem in diesem Fall ist rein hausgemacht: man hat 2 unsinnige Standards (alle Datumsfelder *EUR und nur eine exportierte Funktion pro SRVPGM) die beide zusammen zu Aufwand führen. Der saubere Weg wäre:
- beide Standards ändern und alle betroffenen Funtionen einfrieren (deprecated), d.h. ist Änderung in der Funktion erforderlich wird die *ISO Schnittstelle im selben Modul zugefügt und die Implementierung dorthin verschoben, die *EUR Schnittstelle wird zum Adapter. Kommt eine Aufruf hinzu, wird die *ISO Variante verwendet und gegebenen Falls eingefügt. Bei neuen Funtionen wird gleich *ISO angelegt.

D*B

[Fuerchau]

Dem kann ich nur zustimmen.
Allerdings finde ich persönlich eben "Parameter style General" eben bedenklich, da man nicht mit NULL und Fehlermeldungen (Diagnose) umgehen kann.
Der "SQL-Aufruf" ist dann wieder zu komplex bzw. lästig. Da kann ich ja dann auch wieder einen Wrapper drumrum stricken.

[BenderD]

... einfach eine 2. procedure mit auf iso angepasster Schnittstelle aus demselben modul exportieren, die den Aufruf an die bereits implementierte durchreicht und fertig ist. Da RPG (leider) nicht überladen kann, muss die halt einen anderen Namen haben (suffix iso).
Ansonsten gehören die Aufrufe der function ohnehin im vie layer gekapselt, sodass ein cast von date nach alfa im Aufruf auch kein drama wäre.
D*B

[dschroeder]

... einfach eine 2. procedure mit auf iso angepasster Schnittstelle aus demselben modul exportieren, die den Aufruf an die bereits implementierte durchreicht und fertig ist. Da RPG (leider) nicht überladen kann, muss die halt einen anderen Namen haben (suffix iso).
Ansonsten gehören die Aufrufe der function ohnehin im vie layer gekapselt, sodass ein cast von date nach alfa im Aufruf auch kein drama wäre.
D*B

Vielen Dank.
Genau das Prinzip verfolgen wir ja im Moment. Wir schreiben einen Adapter, der das Datum umwandelt und dann die eigentliche Procedure aufruft. Ich finde das nur sehr lästig. Ich habe 2 Sprachen (SQL und RPG) und in beiden habe ich Datumsfelder. Es wäre natürlich schön, wenn die beiden Sprachen ihr Parameter dann auch untereinander aushandeln könnten.

Dieter

[BenderD]

Deshalb behelfen wir uns immer damit, ein zusätzliches RPG-Serviceprogramm zu erstellen

...dazu brauchts kein weiteres SRVPGM, diese procedure gehört in das Modul mit der Implementierung!!!

[dschroeder]

Beide Procedures in einem Serviceprogramm fände ich in diesem Fall auch besser. Geht aber bei uns wegen unseres Toolings (im Moment) nicht.