View Full Version : Aufruf einer SQL Stored Procedure in SQLRPGLE
... ich verstehe zwar warum argv[2] NULL ist (wo nur ein Parameter ist, kann nur einer nicht Null sein), ich verstehe aber nicht, warum das RPG compilierbar sein soll - ich finde nämlich keine Deklaration von InpMit?!
=> InpMit8 = %subst(InpMit: 1: 8) ;
D*B
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 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 ???
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).
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.
Dieser ist ein *ENTRY-PARAMETER (im Debug gefüllt)
und natürlich auch definiert.
d InpMit s 12
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.
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).
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.
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)