MCH3601

[HPKahn]

Hallo AS400-Gemeinde,

folgendes Problem stellt sich.

Aufruf einer SQL-SP aus einem CL
CALL PGM(ISBANILV/PROTIBLOG) PARM(&MSGTEXT +
'LOADPRJDAT' '10:12:12' 0 '00000')
Hier wird nur eine Protokollierung vorgenommen (Einfügen eines Datensatzes mit den übergebenen Parametern)

hier bekomme ich den Fehler MCH3601

Dieser Aufruf nicht aus einem CL sondern ebenfalls aus einer SP (Fehlerbehandlung)

/************************************************** ********** FEHLER ************************************************** *********************************/
DECLARE EXIT HANDLER FOR SQLEXCEPTION
BEGIN

GET DIAGNOSTICS EXCEPTION 1 V_MESSAGETEXT = MESSAGE_TEXT ;

CALL ISBANILV.PROTIBLOG(V_MESSAGETEXT, V_PROCNAME, T_STARTTIME, SQLCODE , SQLSTATE);

RESIGNAL ;
SET PRETVAL = 0 ;
RETURN ( 0 ) ;

END ;


funktioniert dagegen

Wo liegt der Fehler im CL.

Danke im voraus und schöne Feiertage


Grüße HP

[Fuerchau]

Schau dir deinen Aufruf an sowie genau die Felddeklaration die erwartet wird:

CALL PGM(ISBANILV/PROTIBLOG) PARM(&MSGTEXT +
'LOADPRJDAT' '10:12:12' 0 '00000')

Die 0 wird als Packed(15,5) übergeben !

Ich würde die Paramter im CLP genauso wie sie erwartet werden als Felder deklarieren und dann übergeben.
Dann bist du auf der sicheren Seite.

[B.Hauser]

Wie sind die Parameter in der Stored Procedure definiert?
Ich vermute, dass Parameter 4 und 5 (SQLCODE und SQLSTATE) als INOUT-Parameter definiert wurden.

CL übergibt jedoch Konstanten, also Input only-Parameter.
In dem Moment, in dem in der Stored Procedure eine Änderung dieser Felder erfolgen soll, stürzt die Prozedur ab.

Beim Aufruf aus SQL werden keine Konstanten, sondern Variablen für die Parameter 4 und 5 verwendet.

Du musst also, wie Fuerchau bereits vorgeschlagen hat Variablen definieren und übergeben. Dabei ist zu beachten, dass SQLCODE als small integer definiert ist, was in CL entweder einer Definition von 2 Byte Integer (ab Release V5R3) oder 2A (vor Release V5R2) entspricht. SQLSTATE ist als 5A definiert

Birgitta

[Fuerchau]

@Birgitta:
Seit wann übergibt CLP Konstanten ?

Ein CLP-CALL ist immer ein CALL-BY-REFERENCE.
Werden Konstanten übergeben, werden diese intern in Default-Größen (schon mehrfach besprochen, CHAR(32), PKD(15,5)) überführt und die Adresse ans Programm übergeben.
Das Programm kann diese dann auch ändern ohne Absturz, nur das CLP kriegt dann nichts mit.

Der MCH deutet auf falsche Ausprägung des Parameters hin (Typ/Länge).

[B.Hauser]

@Fuerchau,

hab' ich gepennt! Man sollte die Posts genau durchlesen bevor man seinen Senf dazugibt.

Wie Du schon sagst, übergibt CL nur Pointer. Die Länge ist dabei fast uninteressant! Das Programm übernimmt die Adressen und die Anzahl an Byte, die in dem aufgerufenen Programm erwartet werden.

Allerdings bedeutet MCH3601 nicht falsche Ausprägung von Parametern sondern:
Zeiger für angegebene Position nicht gesetzt.

Der Grund für den Abbruch liegt einfach darin, dass Stored Procedures aus einem SQL-Interface (z.B. embedded oder interaktives SQL, ODBC, JDBC usw.) aufgerufen werden müssen! Und CL unterstützt kein embedded SQL!

Beim Aufruf über den SQL-CALL werden eine Reihe zusätzlicher Parameter übergeben und während der Ausführung der Stored Procedure gesetzt! Diese fehlen beim Aufruf über den CL-Befehl. Deshalb auch der Abbruch mit MCH3601.

Ob man allerdings eine Stored Procedure aus CL aufrufen kann, wenn man alle erwarteten Parameter übergibt, hab' ich nicht ausprobiert.

Um das Problem zu lösen gibt es zwei Möglichkeiten:

1. Man schreibt ein Wrapper-Programm/Prozedur in einer Programmiersprache bei der embedded SQL unterstützt wird (z.B. RPG). In dieser Prozedur wird nur der SQL-CALL abgesetzt.
2. Man führt den CALL-Befehl in CL über die QSH aus.

Beispiel:

QSH        CMD('db2 "Call MySchema.MyStrProc('ParAlpha', 123)"') 

Birgitta

[Fuerchau]

Wenn man weiß, welche Parameter erwartet werden, dann klappt auch der Aufruf aus CLP.

Allerdings weiß ich nicht, ob SQL-Prozeduren einen Connect durchführen, falls noch keine Verbindung besteht.
Allerdings codiere ich ja auch keinen Connect im SQLRPG, da verbindet sich die DB von selber.

Ich denke aber, dass das genauso klappt wie bei externen SQL-Prozeduren, die ja auch keinen Connect enthalten.

[HPKahn]

Hallo AS400-Gemeinde,

folgendes Problem stellt sich.

Aufruf einer SQL-SP aus einem CL
CALL PGM(ISBANILV/PROTIBLOG) PARM(&MSGTEXT +
'LOADPRJDAT' '10:12:12' 0 '00000')
Hier wird nur eine Protokollierung vorgenommen (Einfügen eines Datensatzes mit den übergebenen Parametern)

hier bekomme ich den Fehler MCH3601

Dieser Aufruf nicht aus einem CL sondern ebenfalls aus einer SP (Fehlerbehandlung)

/************************************************** ********** FEHLER ************************************************** *********************************/
DECLARE EXIT HANDLER FOR SQLEXCEPTION
BEGIN

GET DIAGNOSTICS EXCEPTION 1 V_MESSAGETEXT = MESSAGE_TEXT ;

CALL ISBANILV.PROTIBLOG(V_MESSAGETEXT, V_PROCNAME, T_STARTTIME, SQLCODE , SQLSTATE);

RESIGNAL ;
SET PRETVAL = 0 ;
RETURN ( 0 ) ;

END ;


funktioniert dagegen

Wo liegt der Fehler im CL.

Danke im voraus und schöne Feiertage


Grüße HP

Hallo,

laut IBM-Hotline ist es generell nicht möglich eine SQL-SP mit Parametern aus einem CL aufzurufen (ohne Parameter kein Problem).

Hier muß der Umweg über ein C- oder RPG-Programm gemacht werden.


Grüße HP Kahn

[Fuerchau]

Nun, das halte ich für ein Gerücht.
Wenn ich ein Programm aus RPG aufrufen kann, dann gehts auch aus CLP. Statt RPGLE ist es eben CLLE. In beiden Fällen muss ich die Parameter als Felder deklarieren und dann beim Call übergeben.
Aus CLP/CLLE sollten besser Variablen statt Konstanten verwendet werden.

[HPKahn]

Hallo Fuerchau,

ich habe vor Weihnachten einen entsprechenden Call bei IBM aufgemacht und bekam die schon erwähnte Antwort.

hier nochmals eines kleines Beispiel, der Paramter RETVAL wird mit 0 übergeben, sowohl als Konstante als auch als Variable bricht das Programm mit dem Fehler ab.

CALL PGM(ISBANILV/GETPRJ) PARM (&RETVAL)
IF COND(&RETVAL = '0') THEN(DO)
CHGVAR VAR(&MSGTEXT) VALUE('Es hat einen Fehler beim Import der Projekte aus dem +
Projektmanager gegeben.')



Grüße HP Kahn

[Fuerchau]

Irgendwo gibt es doch die Prozedurdeklaration, ggf. in SYSPARMS mal nachschauen.
Deine Parameter musst du nun identisch deklarieren und die zusätzlichen Parameter wie SQLCOD, SQLSTATE mit übergeben.
Im SQL-Reference steht beschrieben, wie die Parameter in welcher Folge, ob mit/ohne NULL-Indikator usw. abhängig vom Prozedurtyp an Prozeduren übergeben werden.

Im Zweifel läßt man sich die Prozedur noch mal erstellen und schaut sich die generierte C-Quelle an (Spoolfile).

Dann steht einem Aufruf aber wirklich nichts im Wege.

[BenderD]

edit
mal so einen kleinen Test gemacht, sieht nicht so Hoffnungslos aus, pro Parameter, der auch rein gehen kann, wird eine short ergänzt (Null Bite vermutlich), beim Aufruf passiert noch was seltsames mit Parameterlängen, könnte aber heilbar sein.

Was dennoch dagegen spräche: das ist undokumentiert!!!
end of edit

naja, das könnte auch schief gehen

- die SQL Runtime weiß, dass das originär eine SQL Procedure war
- das Parameter mapping zwischen runtime und generiertem C Programm ist SQL spezifisch (zusätzliche Parameter)
- C kann im Parameter Handling mehr als CL (und auch RPG)
- nicht jede C Procedure muss aus CL aufrufbar sein
- nicht alles was die Datenbank in der Runtime hat, haben andere Programme auch

mfg

Dieter Bender,

der nicht unbedingt glaubt, dass es die zusätzlichen Parameter sind, wie man in anderen Foren lesen kann

Irgendwo gibt es doch die Prozedurdeklaration, ggf. in SYSPARMS mal nachschauen.
Deine Parameter musst du nun identisch deklarieren und die zusätzlichen Parameter wie SQLCOD, SQLSTATE mit übergeben.
Im SQL-Reference steht beschrieben, wie die Parameter in welcher Folge, ob mit/ohne NULL-Indikator usw. abhängig vom Prozedurtyp an Prozeduren übergeben werden.

Im Zweifel läßt man sich die Prozedur noch mal erstellen und schaut sich die generierte C-Quelle an (Spoolfile).

Dann steht einem Aufruf aber wirklich nichts im Wege.

[HPKahn]

Hallo zusammen,

da ich Rückgabeparameter aus meiner SQL-SP erwarte und es auch partout nicht funktioniert ein CL mit Parametern aufzurufen(weiß der Geier warum) habe ich den Umweg über eine RPG-Programm gemacht (mein allererstes ;-)) und das funktioniert prima.

d main PR extpgm('CALLSQLSP')
d pspname 10A
d pretval N
*-----------------------------------------------------------
d main PI
d pspname 10A
d pretval N
*-----------------------------------------------------------
/free
select;
when pspname = 'GETPRJNTZ';
exsr callGetNtz;
when pspname = 'GETPRJ';
exsr callGetPRJ;
when pspname = 'GETTIME';
exsr callGetTime;
when pspname = 'MKPREPPRJ';
exsr callPrepPrj;
WHEN pspname = 'GETIBPKOST';
exsr callSTDSTZ;
when pspname = 'CRT_IBRHG';
exsr callCrtRhg;
endsl;
return;
/end-free

C callGetNtz begsr
* Aufruf der stored procedure
C/exec sql
C+ call GETPRJNTZ (retval)
C/end-exec
C endsr

C callGetPrj begsr
* Aufruf der stored procedure
C/exec sql
C+ call GETPRJ (retval)
C/end-exec
...

hier stellt sich jetzt ein neues Problem.
Eine Prozedur benötigt einen weiteren Parameter (Monatserster des Vormonats) diesen will ich im gleichen RPG-Programm ermitteln, nur weiss ich nicht richtig wie?

Hat hier jemand einn Tipp?

PS: Ein ausgesprochenes Lob an das Forum, hier können sich andere Foren eine Scheibe abschneiden.


Grüße HP Kahn