UDTF mit optionalen Input-Parametern

[B.Hauser]

Immer eine Frage des Releases.
Natürlich kann ich mir die Überladungen sparen, wenn ich für nicht benötigte Parameter NULL angebe. Da weiß man zumindest, was der Verwender wirklich will.

Falls Du damit auf die Antwort von Andreas anspielst, ... solltest Du Dir mal wirklich die Default-Werte, die bei Stored Procedure und User Defined (Table) Function Parametern angegeben werden können anschauen.

Bei dieser Technik können für Input-Parameter Default-Werte (und nicht nur NULL-Werte) definiert werden. Werden Input-Paramter, für die Default-Werte definiert wurden nicht übergeben, werden anstelle der Parameter die Default-Werte an die Stored Procedure oder User Defined (Table) Function übergeben.

Man kann nicht nur Parameter weglassen, man kann auch über "Argument Listen" einzelne Parameter benennen (=Named Parameters) und diesen beim Aufruf einen Wert zuweisen. Wird ein Parameter benannt, so muss der Parameter-Name, der beim Erstellen oder Registrieren der Routine definiert wurde angegeben werden. Auf den Parameter-Name muss => folgen und im Anschluss der eigentliche Parameter-Wert oder Variable (s. Beispiel von Andreas).
Werden die Input Parameter benannt, so genügt es lediglich die benötigten Parameter (bzw. die von den Default-Werten abweichenden Parameter-Werte) zu übergeben. Die Reihenfolge in der die benannten Parameter angegeben werden, spielt dabei keine Rolle.

Diese Technik wurde mit einem Technologie Refresh eingeführt und von Release 7.1 an aufwärts verfügbar.

Noch eine Erinnerung an alle diejenigen, die Release 7.1 oder älter einsetzten. Der offizielle Support von IBM für Release 7.1 endet am 30.04.2018. (für ältere Releases gibt es von IBM keinerlei Support mehr)
Die Neuerungen, die gerade auf der Common Herbst Konferenz in den USA für den nächsten Technology Refresh announced wurden (und das sind gerade im Bereich von SQL und Datenbank nicht wenige), werden nur für Release 7.2 und 7.3 bereitgestellt.

Birgitta

[Fuerchau]

Das mit den Defaults für Parameter wurde bereits oben erwähnt und manche OO-Sprachen kennen das auch.
Ich habe ja nur gesagt, dass man Funktionen/Prozeduren mit allen Parametern auch mit individuellen Defaults(=Konstanten, NULL) aufrufen kann.
Bei solchen Konstrukten (Defaults/Überladungen) bedarf es schon genauer und guter Dokumentation, damit man nicht auf die Nase fällt.
Seit Einführung der globalen SQl-Variablen (V7R1?) falle ich leider immer wieder auf die Nase, da der Compiler mir nur noch in seltenen Fällen Tippfehler als Fehler rauswirft und ich mich erst zur Laufzeit Frage, warum was nicht läuft.
Vielleicht kann man das ja zur Compilezeit irgendwie als Warnung oder mit Heruntersetzen der Bewertung anpassen damit der Compiler Fehler wieder meldet.

[BenderD]

... ich denke, dass man da noch etwas tiefer einsteigen muss:
Überladung und optionale Parameter sind zwei verschiedene Dinge, wobei Überladung der stärkere Mechanismus ist, weil bei der Verwenung bereits zur Compiletime geprüft wird und die zu übergebenden Parameter keiner Anordnungsbedingung unterliegen.
Namensparameter sind zwar sehr flexibel, was aber gerade die Prüfbarkeit zur Compilezeit einschränkt; zudem muss der Verwender mehr Wissen über die innere Implementierung haben.

Was das ursprüngliche Problem angeht (Überladung einer external (RPG) UDTF) ist es wohl am einfachsten (und damit auch am besten), die Überladung in der RPG Implementierung mit abzubilden und mehrere RPG Aufrufpunkte zu haben (1 : 1 zu den Überladungen). Hier bietet sich dann eher ein SRVPGM an. Die Verzweigung kann dann wieder in einer Implementierung münden, die den Hauptteil der Logik einthält.

D*B

[dschroeder]

Vielen Dank für alle Antworten. Ich habe viel neues erfahren. Mein eigentliches Problem war ja die Fragestellung, weshalb die im RPG erwarteten optionalen Parameter nicht rüberkamen. Auf die simple Idee, im SQL Null anzugeben, bin ich ich nicht gekommen.
Die Sache mit den benannten Parametern war mir ebenfalls nicht bewusst. Ich habe die Syntax im SQL in den neuen mitgelieferten Funktionen zwar schon ein paar Mal gesehen, aber mir war eigentlich nicht richtig klar, dass damit eine Parameterbenennung realisiert wird. Danke auch für diesen Ansatz.

Ich wünsche allen einen guten Start in die neue Woche.
Dieter

[andreaspr@aon.at]

Und falls wer meint, dass zum Compile-Zeitpunkt keine Prüfung stattfindet, bitte es einfach mal ausprobieren.
Der Fehler ist dann nämlich:

The CALL statement or function invocation includes named argument &1 which does not exist for routine &2 in schema &3.

[BenderD]

... zwischen nix prüfen und wenig prüfen können, gibt es wesentliche Unterschiede - nur so am Rande, der Präzision halber, erwähnt.

[Fuerchau]

Ich meinte ja auch die Nichtprüfung von Spaltennamen in Select und Where-Klauseln, die nun leider erst zur Laufzeit passieren, da alle nicht gefundenen Namen, die nicht explizit benötigt werden, für globale Variablen gehalten werden. Und das schlägt erst zurLaufzeit an. Da reicht schon mal das Vergessen eines Doppelpunktes.