Aufruf einer SQL Stored Procedure in SQLRPGLE

[BenderD]

InpMit8 ist der Übergabeparameter aus dem SQLRPGLE an die SQL-Procedure.

Der obige C-Code ist der "Precompilercode" der SQL-Procedure, welche beim Debugen der Procedure (nach Aufruf im ebenfalls gedebuggten SQLRPGLE-Programme) angezeigt wird.

Zuletzt erzeugt per "Green Screen" mit:
RUNSQLSTM SRCFILE(WITAAXE0/QSQLSRC) SRCMBR(SP_DEMO) COMMIT(*NONE) NAMING(*
SQL) MARGINS(100) DBGVIEW(*SOURCE)

InpMit8 ist ja auch deklariert, aber InpMit ???

[Fuerchau]

SQL-Body-Programme sollten eigentlich generell den Parameter Style SQL haben.
Hier sind die Parameter wie folgt:

- Alle Aufrufparameter
- Returnwert (falls vorhanden)
Je Aufrufparameter und Return-Wert einen NULL-Anzeiger
Dann SQLState, Function-Nme, Specific-Name, Diag-Message

Somit ergibt sich:
arg[0] = Parameter
arg[1] = NULL-Anzeiger dazu
arg[2] = SQLState

Und aus Irgendwelchen Gründen wird die Prozedur wohl nicht im Style SQL aufgerufen.
Dies ist die Ursache für denn MCH3601 (arg[2] = NULL).

[Fuerchau]

D*B hat recht.
Wieso kann das RPGLE umgewandelt werden wo doch die Variable "InpMit" ohne Deklaration verwendet wird?
Zaubert der SQL-Precompiler die Variablen ggf. in den Code?

Allerdings dürfte das den SQL-Aufruf selber nicht tangieren.
Aber wer weiß, was der Compiler draus macht.

[Witaseck]

Dieser ist ein *ENTRY-PARAMETER (im Debug gefüllt)
und natürlich auch definiert.

d InpMit          s             12

[Witaseck]

Aufrufe im RPG-Programm:

• bisher:
  exec SQL CALL WITAAXE0.SP$MUBHBST(:InpMit8) ;
• beim select in Embeded-SQL schon für NULL-Indikator genutzt:
  (:InpMit8 :InpMit8_NI)
• bedeutet dies nun
  exec SQL CALL WITAAXE0.SP$MUBHBST(:InpMit8 :InpMit8_NI :RETURN) ;
  
  Wenn ja, wie wird RETURN deklariert?

Vielen Dank für eure Unterstützung. Ich hatte mir diese Thematik etwas einfacher vorgestellt.

[Fuerchau]

Dann bleibt dir wohl nur eine Meldung an IBM oder die Prozedur ebenso in ILERPG zu schreiben (empfehlenswert, da wärst du schon längst fertig incl. 10 weiterer).

[Witaseck]

Zur Ergänzung aus dem Debug:

 8 SQLP_IND = (short int *)argv[2];                           
 9 CUSA_MUB_HAUPTBETRIEBSSTAETTE_TEST.SQLP_I1 = *(SQLP_IND+0);

argv = SPP:F332EA40290017C0
SQLP_IND = SPP:*NULL


Mal sehen, was IBM dazu sagt.

[BenderD]

Aufrufe im RPG-Programm:

• bisher:
  exec SQL CALL WITAAXE0.SP$MUBHBST(:InpMit8) ;
• beim select in Embeded-SQL schon für NULL-Indikator genutzt:
  (:InpMit8 :InpMit8_NI)
• bedeutet dies nun
  exec SQL CALL WITAAXE0.SP$MUBHBST(:InpMit8 :InpMit8_NI :RETURN) ;
  
  Wenn ja, wie wird RETURN deklariert?

Vielen Dank für eure Unterstützung. Ich hatte mir diese Thematik etwas einfacher vorgestellt.

... zu beachten sind bei Procedures die Deklaration eines Parameters als:
IN
INOUT
OUT
Rückgaben beim return gehen nur bei functions

D*B

PS: es gibt da auch ein relativ neues Redbook (das allerdings auch wg. Fehlern, insbesondere beim Errorhandling, nix taugt)

[Fuerchau]

Theoretisch und auch praktisch ist das auch einfach.
Ich verstehe ja nicht, wieso das mit dem iNavigator funktionieren soll.

Was den Null-Anzeiger angeht, so kann man diese natürlich bei jeder Variable in SQL angeben:

call MyProc(: Param1 : Param1_Null [, ....]);

Hier ist ggf. der Compiler etwas schwachbrüstig um hier Zusätze bereitzustellen oder Fehler zu melden.
Wenn man per ODBC (wie der iNavigator auch) mit SQL arbeitet generieren die Treiber automatisch zu jeder Variable NULL-Anzeiger.
Vielleicht musst du hier in dem Call deinen NULL-Anzeiger selber mit übergeben, was zu probieren wäre.

Eine Prozedur mit Return ist eine Function, die wird wiederum wie ein Feld verwendet:

select MyFunc(P1, P2, ..., Pn) from MyTable
set : MyReturn = MyFunc(: P1, : P2, ...);

Und mit Null-Anzeigern dann:

set : MyReturn : NullRet = MyFunc(: P1 : P1Null, : P2 : P2Null, ...);