MCH3601

[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.