UDF mit ServiceProgramm und *null-parameter

[roko]

Hallo Leute,

Habe inzwischen alle diesbezügliche Beiträge gelesen und werden daraus nicht schlau. Ich habe ein *SRVPGM mit mehreren Functions, eine davon möchte ich als UDF verwenden, dabei soll ein Parameter wahlweise sein. Dir PI sieht so aus:
GETSVK PI like(AS4VP$)
$a22 like(sa1a22)
$nl like(nl1nl)
$date 8p 0
$eus 2 0 options(*nopass: *omit)
$ind 5i 0 dim(5) options(*nopass)

wobei $ind der übergabe-indikator ist (sein soll).
Die UDF habe ich so erstellt:

CREATE FUNCTION XX/GETxxx (
PARA22 DEC(5, 0),
PARNL DEC(3, 0),
PARDAT DEC(8, 0),
PAREUS NUMERIC(2, 0))
RETURNS DEC(11, 2)
LANGUAGE RPGLE

DETERMINISTIC
NO SQL
RETURNS NULL ON NULL INPUT
EXTERNAL ACTION
NOT FENCED
EXTERNAL NAME 'XX/GETVKP(GETSVK)'
PARAMETER STYLE GENERAL WITH NULLS

Wenn ich die UDF mit allen 4 Parametern aufrufe dann funktioniert das einwandfrei, versuche ich aber auf den letzten zu verzichten, dann bekomme ich die Fehlermeldung:
GETXXX der Art *N in *LIBL nicht gefunden.

Dabei muss ich sagen, dass die Problematik von einem anderen Beitrag, dass %PARMS immer den Wert -1 liefert bei mir ebenfalls besteht (vielleicht ist das ein Hinweis).
Ich hoffe, ich habe alle notwendigen Infos geliefert, sonst bitte kurz mailen bzw. posten
vielen Dank schon im Voraus
Roman

[Fuerchau]

Das funktioniert so leider nicht.
Je Variante musst du eine eigene SQL-UDF definieren.
Da sich dann auch die Parameterlisten verschieben, benötigst du auch wiederum je eine eigene Service-Prozedur.
Diese können dann jeweils die originale Prozedur mit z.B. Default's aufrufen.
Omit und nopass sind dann auch nicht erforderlich und vereinfachen dann das Verfahren.

[Fuerchau]

Nachtrag:

Deine Prozedurdeklaration für die UDF ist auch falsch!!!
Die NULL-Anzeiger werden nicht als Array sondern als einzelne Parameter, dadurch verschieben sich natürlich auch die Adressen der Parameter, insbesonders des Return-Wertes und dazugehörigen NULL-Anzeigers.

Der Aufruf funktioniert nur deshalb, da in ILERPG die Anzahl Parameter beim Aufruf nicht mehr geprüft werden. Es können zwischen 0 und 255 Parameter übergeben werden.

[B.Hauser]

Hallo,

SQL kennt keine optionalen Paramter, dafür können Prozeduren und User Defined Functions überladen werden, d.h. die gleiche Prozedur oder Funktion kann mehrfach in der gleichen Bibliothek, jedoch mit unterschiedlicher Parameter-Definition existieren.

Wenn eine RPG-Prozedur oder Funktion mit optionalen Parametern registiert werden soll, müssen die optionalen Parameter mit OPTIONS(*NOPASS: *OMIT) definiert werden und entsprechend geprüft werden.

Für jede Parameter-Kombination muss dann die Funktion mit dem gleichen Namen registriert werden. (Es ist NICHT erforderlich für jede Parameter-Kombination eine eigene RPG-Funktion zu erstellen.)

Für die optionalen Parameter werden beim Aufruf der Funktion als UDF NULL-Pointer übergeben. Deshalb ist die Definition mit *OMIT und die Prüfung der optionalen Parameter auf *NULL erforderlich.

Die Indikator-Variablen können beim Parameter Style GENERAL WITH NULLS oder SQL wahlweise als eigene Parameter oder als Feldgruppe mit einem Element pro Parameter definiert werden. Die Parameterübergabe wird korrekt gehandelt.

Birgitta

[roko]

Hallo,
Vielen Dank für die Tipps, ich habe anscheinend die alten Beiträge falsch verstanden. Allerdings macht mich der Wert von %PARMS beim Aufruf über UDF immer noch stützig. Habe auch gehört, dass beim Aufruf von CGI auch irgendwas mit der Anzahl der Parameter nicht stimmt. Bug oder Feature?

Noch mal vielen Dank
Roman

[B.Hauser]

Hallo,
Vielen Dank für die Tipps, ich habe anscheinend die alten Beiträge falsch verstanden. Allerdings macht mich der Wert von %PARMS beim Aufruf über UDF immer noch stützig. Habe auch gehört, dass beim Aufruf von CGI auch irgendwas mit der Anzahl der Parameter nicht stimmt. Bug oder Feature?

Noch mal vielen Dank
Roman

Bei SQL lässt sich die Geschichte mit %PARMS zumindest so erklären, dass SQL einen Wrapper um die eigentliche Funktion bildet, d.h. ein C-Service-Programm, in dem die eigentliche Funktion aufgerufen wird. Bedingt durch die unterschiedlichen Parameter-Styles werden eine Reihe von zusätzlichen Parametern definiert und ggf. als Null-Pointer an die RPG-Funktion übergeben. Da die Anzahl der übergebenen Parameter mit der normalerweise in der RPG-Funktion empfangenen Parameter nichtmehr übereinstimmt, wird um weitere/zusätzliche Verwirrung zu vermeiden, %PARMS auf -1 gesetzt.

Deshalb ist es auch erforderlich die optionalen Parameter mit Options(*NoPass: *Omit) zu definieren und auf NULL-Pointer zu prüfen.

Birgitta