SQL UDF erstellen - Best practices

[BenderD]

Anfangs haben wir bei Webservices auch angenommen, dass es reicht, wenige MB (mit RPG) zurückzugeben. Für Listen mit mehr Daten haben wir dann Paging eingebaut. Wir haben aber das Problem, dass wir einige Business-Objekte haben (z.B. Versicherungsverträge), die so komplex sind, dass das 2 oder 3 MB nicht reichen, um ein Objekt zu beschreiben. Wird müssten dann unsere Business-Objekte in kleinere logische Objekte aufspalten oder wird müssten unsere großen Objekte als Byteketten betrachten und dass dann im Paging herausgeben oder wir müssten die Speichergrenze mittels SQL umgehen. Und das ist im Moment der Ansatz, den wir verfolgen.

... das hört sich für mich alles nach Gebastel an. Einen Versicherungsvertrag in ein SQL Statement zu packen oder per SQL Programm zusammen zu klappern halte ich für ein anspruchsvolles Unterfangen. Wenn ich mir das noch in einer Architektur von Services vorstelle, wird mir flau im Magen dabei.
Das mit dem Debug ist doch nur die halbe Wahrheit, wie will ich denn da Fehlersituationen im richtigen Leben beikommen? m. E. geht da nichts an einem ausgeklügelten logging vorbei, das ich für Analysezwecke feinkörnig steuern kann (log4j oder gleichwertiges lässt grüßen). SQL ist da als Programmiersprache völlig ungeeignet.

D*B

[Fuerchau]

Mit dem Einsatz von BLOB/CLOB/DBCLOB kann ein Dokument 2GB groß werden und auch von RPG mit SQL-Substr bearbeitet werden. Sicherlich kein einfaches Unterfangen aber konzeptionell machbar.
Auch die SQL-Treiber unterstützen LOB's um sie mit anderen Sprachen dann abgreifen zu können.
Ich lese via SQL Dateien aus dem IFS auch als CLOB / BLOB ohne Probleme.

[B.Hauser]

1. Kann man in einer SQL-Funktion eigentlich festlegen, wie der Name des zugehörigen Programms ist?
2. Die SQL-Funktion kann ja einen längeren Namen als 10 Zeichen haben. Es würde sich vielleicht anbieten, den Namen des C-Programm dann so zu nennen, wie der Sourcemember der SQL-Funktion heißt, damit man wieder 10 Zeichen hat. Das würde dann aber bedeuten, dass man nicht 2 SQL-Funktionen in einem Source haben sollte?
3. Gibt es bessere Möglichkeiten des Debuggings? Z.B. per VSCode oder so?
4. Wie handhabt ihr das?

@1/2: Sowohl beim CREATE PROCEDURE als auch beim CREATE FUNCTION kann man den (Service-)Programm-Namen (mit Option PROGRAM_NAME) angeben. Den (Service-)Programm-Namen kann man (selber) festlegen und ist auf 10 Stellen beschränkt.
In der Bedienerführung im ACS kann diese Option nicht ausgewählt werden. Wäre eine "IBM idea", die m.W. noch nicht vorgeschlagen wurde.
Der Programm-Name kann unabhängig von dem SPECIFIC NAME festgelegt werden. Der SPECIFIC Name dient in erster Linie dazu, die aufgerufene Funktion/Prozedur (bei Überladungen) eindeutig zu lokalisieren.
Der Source Code ist beim CREATE OR REPLACE Statement hinterlegt, d.h. jedes CREATE Statement generiert ein eigenes Objekt. Wenn man mehrere CREATE Statements in der gleichen Quelle hat, werden eben mehrere Objekte/Programme/Service-Programme mit einer exportierten Funktion generiert.

@3: Debug: Wenn in der Stored Procedure bzw. UDF die OPTION DBGVIEW = *SOURCE angegeben ist, kann man mit dem ACS-Debugger den SQL Code debuggen. Ohne diese Option lediglich den C-Code.
Der ACS-Debugger lässt zwar zu wünschen übrig, ist aber aktuell die einzige Möglichkeit (mit Bordmitteln) SQL-Source-Code zu debuggen.

@4: Ich arbeite mit dem ACS-Debugger (und SET OPTION DBGVIEW = *SOURCE)

[Fuerchau]

Der Greenscreen Debugger funktioniert hier genauso gut, wie oben beschrieben. Ins besonders wenn man remote (Homeoffice) arbeitet, ist der ACS-Debugger einfach unzuverlässig und laaangsaaaaam.

[dschroeder]

@1/2: Sowohl beim CREATE PROCEDURE als auch beim CREATE FUNCTION kann man den (Service-)Programm-Namen (mit Option PROGRAM_NAME) angeben. Den (Service-)Programm-Namen kann man (selber) festlegen und ist auf 10 Stellen beschränkt.
...Der Programm-Name kann unabhängig von dem SPECIFIC NAME festgelegt werden. Der SPECIFIC Name dient in erster Linie dazu, die aufgerufene Funktion/Prozedur (bei Überladungen) eindeutig zu lokalisieren.
Der Source Code ist beim CREATE OR REPLACE Statement hinterlegt, d.h. jedes CREATE Statement generiert ein eigenes Objekt. Wenn man mehrere CREATE Statements in der gleichen Quelle hat, werden eben mehrere Objekte/Programme/Service-Programme mit einer exportierten Funktion generiert.

Hallo Birgitta,
vielen Dank für deine Infos. Genau das Schlüsselwort PROGRAM_NAME kannte ich bisher nicht. SPECIFIC_NAME habe ich bisher auch bei Überladungen eingesetzt.

Ist es eigentlich eine gute Idee, das C-Programm mit PROGRAM_NAME selbst zu benennen? Ich dachte, es wäre eine gute Idee. Aber jetzt kamen bei uns Bedenken auf, dass das auch eine riskante Fehleroption sein kann: Wenn jemand eine UDF (also den Source) kopiert und eine neue Funktion schreibt und dabei vergisst, den PROGRAM_NAME anzupassen, wird die neue Funktion ja wahrscheinlich erstellt, aber das bestehende C-Programm wird fälschlicherweise überschrieben.

Siehts du oder seht ihr das auch als Problem?

Wir liebäugeln deshalb zur Zeit doch mit der Lösung, den C-Programmnamen automatisch generieren zu lassen und uns für die Debugzwecke das C-Programm manuell (z.B. mit SQL) heraus zu suchen.

[BenderD]

... das generieren lassen ist selten eine gute Idee, insbesondere wenn die generierten Namen von der Reihenfolge der Erstellung von Programmen abhängen und man mehrer Umgebungen hat - noch verschärft, wenn man kein automatisches Deployment und change management hat.

D*B

[Fuerchau]

Das kann dir auch bei RPG passieren, wenn man den Namen im Programm vergeben hat, was allerdings eher selten gemacht wird.
Die COBOL-Programmierer kennen das aber, da ist der Name in der Source ja Pflicht;-).

[dschroeder]

... das generieren lassen ist selten eine gute Idee, insbesondere wenn die generierten Namen von der Reihenfolge der Erstellung von Programmen abhängen und man mehrer Umgebungen hat - noch verschärft, wenn man kein automatisches Deployment und change management hat.
D*B

Das ist richtig. Danke für den Hinweis.

Ich habe noch ein wenig weiter probiert. Bei mir klappt die Angabe des Programmnamens nur, wenn ich das Schlüsselwort "specific" verwende. PROGRAMM_NAME oder "specific name" funktioniert nicht.
Oder wie soll das genau gehen?

Wegen des Überschreibens von generierten Programmen bin jetzt auch etwas beruhigter:
Wenn man einmal einen "specific" Programmnamen festgelegt hat, kann man den gar nicht so einfach von einer anderen Funktion aus überschreiben. Es gibt dann die Meldung, dass der Name bereits verwendet wird.

[Andreas_Prouza]

Wegen des Überschreibens von generierten Programmen bin jetzt auch etwas beruhigter:
Wenn man einmal einen "specific" Programmnamen festgelegt hat, kann man den gar nicht so einfach von einer anderen Funktion aus überschreiben. Es gibt dann die Meldung, dass der Name bereits verwendet wird.

Naja, ich verwende das CREATE OR REPLACE.
Da ich automatisierte Builds verwende, muss die bestehende Funktion vorher gelöscht werden, falls diese bereits vorhanden ist.
Da ich das nicht jedes mal manuell machen möchte (was ja auch wieder fehleranfällig ist) muss man entweder in der Source vorher ein DROP FUNCTION oder eben das OR REPLACE verwenden.

[dschroeder]

Wir verwenden ebenfalls nur create or replace.

Ich finde es ja supergut, dass man den specific Name nicht einfach von einer anderen Funktion aus nochmal benutzen kann. Diese Gefahr ist durch die Warnung gebannt.

[dschroeder]

Bevor jemand den Unsinn, den ich geschrieben habe, für bare Münze nimmt, hier nochmal eine Richtigstellung:

Ich habe inzwischen herausgefunden, dass es doch das Schlüsselwort "program name" gibt. (Mein RDi erkennt das allerdings nicht als Schlüsselwort, aber es lässt sich ausführen.)

Das heißt:

• Mit program name kann ich selbst den Namen des C-Programms festlegen
• Mit specific lege ich den eindeutigen Funktionsnamen fest. Z.B. wenn ich die selbe Funktion mit unterschiedlichen Parametern haben möchte.