-904 bei Stored Procedure Aufruf im Batch

Hallo Alex,

wir werden jetzt prüfen, ob wir tatsächlich result sets verwenden (wollten wir eigentlich nicht bei diesem Aufruf 🙂 ).

Sobald ich mehr herausbekommen habe melde ich mich nochmal.

Besten Dank schon mal für Deinen Hinweis

Gruß Klaus

Hallo zusammen,

wir haben die Sache nochmal geprüft.

Die Definition der SP beinhaltet ein result set wie man hier sehen kann:

CREATE PROCEDURE XXXX.OTTO
( IN I_PARAM1 CLOB (1 M)
, IN I_PARAM2 CLOB (1 M)
, IN I_PARAM3 CLOB (1 M)
, IN I_PARAM4 CLOB (32 K)
, IN I_PARAM5 CLOB (32 K)
, OUT O_PARAM1 CLOB (1 M)
, OUT O_PARAM2 CLOB (15 M)
, OUT O_PARAM3 CLOB (15 M)
, OUT O_PARAM4 CLOB (15 M)
, OUT O_PARAM5 CLOB (32 K)
, OUT O_PARAM6 CLOB (32 K)
)
LANGUAGE COBOL
PARAMETER STYLE GENERAL
MODIFIES SQL DATA
EXTERNAL NAME OTTO
RESULT SETS 1
RUN OPTIONS ‚MSGFILE(SYSOUT,,,,ENQ)‘
;

Da die SP jedoch bei unserem Aufruf diesen Cursor nicht öffnet, verstehen wir nicht warum wir den Fehler bekommen.

Wir haben durch DISPLAYs sichergestellt, dass der einzige CURSOR, der WITH RETURN definiert ist, nicht genutzt wird. Die DISPLAYs sind vor und nach den entsprechenden DECLARE + PREPAREs + OPEN etc. positioniert.

Wo könnte der Fehler stecken?
Was können wir noch prüfen?

Besten Dank im voraus

Gruß Klaus

Hallo Ulrich,

genau das war unsere Befürchtung.

Man kann also eine SP nicht im BATCH-Umfeld intensiv nutzen (mehr als 2000 Aufrufe (Default V8 )bzw. mehr als 32000 Aufrufe (fixer Wert in V7)), ohne COMMIT-Logik.

Und das bedeutet für uns, dass wir in das BATCH-PGM eine CHECKPOINT-RESTART-LOGIK einbauen müssen.

Leider.

Ich möchte nicht bestreiten, dass CHECK-POINT-RESTART-Logik bei Massenverarbeitung sinnvoll ist.

Es ist aber trotzdem schöner wenn man selber entscheiden kann, wann man so etwas nutzt und es nicht von DB2 auferlegt bekommt. (wie in unserem Fall)

Bei normalen COBOL-CALLs auf ein UPRO gibt es die Restriktion auch nicht.

Warum muß dass dann bei

EXEC SQL

CALL OTTO etc.

END-EXEC

so sein?

Gruß Klaus

Hallo zusammen,

ich wollte euch mal von unseren frustrierenden Erfahrungen berichten.

Wir haben jetzt COMMITs nach jedem Aufruf der SPs eingebaut. Wir hatten damit gehofft den -904 endgültig loszuwerden.

Nach ca 20 Minuten Batchlaufzeit bekommen wir immer noch den ursprünglichen -904.

Der Parameter MAX STORED PROCS steht auf 2000.
Der Parameter MAX OPEN CURSORS steht auf 500.

Mit OMEGAMON DB2 haben wir das Trauerspiel beobachtet. Kurz vor dem -904 zeigt die SQL-Ãœbersicht:

COMMIT 680
OPEN CURSOR 5278
CLOSE CURSOR 5278
SET HOST VAR 11061
SELECT 153452
FETCH 320948
UPDATE 2196
PREPARE 4942
HOLD LOCATOR 0
Assoc Locator 0

SQL CALL Statements 5024 (Sollte eigentlich mit MAX STORED PROCS korrespondieren)
Stored Proc SQL Reqs 507145 (SQLs innerhalb von SPs)

Unsere DBAs suchen noch nach dem Fehler.

Im Installation guide V8 habe ich noch folgende Aussage gefunden:

MAX STORED PROCS

Specify the maximum number of stored procedures per thread. If an application attempts to call a stored procedure after the maximum is reached,
the statement will fail.

In a data sharing group, this parameter has member scope.

Hier steht ja nichts von COMMIT sondern nur von THREAD.
Das würde bedeuten das Batchverarbeitung mit SPs grundsätzlich nicht möglich ist. Den THREAD kann ich ja nicht beenden, bevor mein Batch-PGM beendet ist.

Sagt mir bitte dass das so nicht stimmt.

Für jeden Hinweis woran das hier liegen könnte bin ich dankbar.

Macht jemand von euch Massenverarbeitung mit SPs?

Gruß Klaus

Hallo Ulrich,

PGM-Struktur ist ungefähr wie folgt:

Batch-PGM ruft SP1

Schleife-Anfang:

Batch-PGM ruft SP2 ==>
SP2 ruft ==> SP3
SP3 ruft (3-4mal) => SP1

<==============================
INSERT in T1 ==> TRIGGER auf T1 ruft ==> SP4

COMMIT
Schleife-Ende

Darum machen wir ca. alle 8 SP-Calls einen Commit.

Result-Cursor (with hold with return) machen wir auch nicht auf.

Gruß Klaus