View Full Version : MCH3601
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
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.
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
@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).
@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:
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.
Man führt den CALL-Befehl in CL über die QSH aus.
Beispiel:
QSH CMD('db2 "Call MySchema.MyStrProc('ParAlpha', 123)"')
Birgitta
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.
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
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.
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
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.