COBOL mit Rollback und Commit

[wolfinho]

Hallo zusammen,

ich habe verschiedene Cobol-Programme mit Embedded-SQL erstellt, die ich gerne innerhalb des Programmes mit Commit und Rollback im Fehlerfall steuern würde. Die Tabellen auf die die Programme zugreifen, sind ebenfalls neu und mit SQL erstellt.

Die Cobolprogramme sind in einem CL-Programm eingebettet.

Ich habe mich mal durch die Fachbücher gelesen und nach meinem Verständnis muß ich folgendes tun :

1. CRTJRNRCV
2. CRTJRN
3. STRJRNPF (jeweils für die gewünschten DBs - Parameter Satzabbilder *BOTH)

Innerhalb des CLs jeweils zur Ausführungszeit vor dem 1. Aufruf eines Cobolprogrammes:

STRCMTCTL

Die Cobolprogramme mit dem Parameter COMMIT *CHG umwandeln.

Danach müsste ich doch in den Cobolprogrammen mit embedded SQL mit Commit und Rollback arbeiten können, oder ?


Vielleicht könnt Ihr mir kurz bescheid geben, ob ich das alles so richtig verstanden habe und was zu beachten ist.

Vorab vielen Dank für Eure Hilfe.

Viele Grüße

[Fuerchau]

Fast komplett:

I-O-CONTROL.
COMMITMENT CONTROL FOR MyFile1 [MyFile2] ...

Bei der Umwandlung ist nichts zu beachten, da die Commit-Art (*CHG) von außen durch STRCMTCTL gesteuert wird.

Wenn du allerdings mit embedded SQL arbeitest, reicht:

EXEC SQL SET OPTION COMMIT=*CHG
END-EXEC

aus.

[BenderD]

Hallo,

wenn die Bibliothek per SQL mit create schema erstellt ist, oder ein QSQJRN existiert (oder eine DTAARA mit einem passenden Eintrag) werden alle neu erstellten Dateien automatisch journalisiert, ansonsten halt CRTJRNRCV und CRTJRN und STRJRNPF.
RPG startet Commitment Controll bei SQL Programmen automatisch, ob man das bei COBOL per CL starten muss, weiß ich nicht.
Ansonsten muss man auf folgendes noch achten:
- pro Activation Group hat man eine eigene Commit Definition (entspricht Connection)
- die erste Datenänderung startet die Transaktion
- ab da werden alle Sperren gehalten
- beendet wird die Transaktion mit Commit (festschreiben) oder Rollback (April, April)
- für den Anfang reicht das bereits
- empfehlenswert ist des den Record Wait der Dateien drastisch zu verringern (eher 5 sec als die 60 default), dafür den Object wait zu erhöhen (eher > als record wait), bei den default Einstellungen von 60 und *immed müssen die in Rochester gerade Fassenacht gehabt haben!
- für die volle Nutzung aller Möglichkeiten sollte man sich später mal mit den Sperrmechanismen und solchen Dingen beschäftigen

Dieter Bender

Hallo zusammen,

ich habe verschiedene Cobol-Programme mit Embedded-SQL erstellt, die ich gerne innerhalb des Programmes mit Commit und Rollback im Fehlerfall steuern würde. Die Tabellen auf die die Programme zugreifen, sind ebenfalls neu und mit SQL erstellt.

Die Cobolprogramme sind in einem CL-Programm eingebettet.

Ich habe mich mal durch die Fachbücher gelesen und nach meinem Verständnis muß ich folgendes tun :

1. CRTJRNRCV
2. CRTJRN
3. STRJRNPF (jeweils für die gewünschten DBs - Parameter Satzabbilder *BOTH)

Innerhalb des CLs jeweils zur Ausführungszeit vor dem 1. Aufruf eines Cobolprogrammes:

STRCMTCTL

Die Cobolprogramme mit dem Parameter COMMIT *CHG umwandeln.

Danach müsste ich doch in den Cobolprogrammen mit embedded SQL mit Commit und Rollback arbeiten können, oder ?


Vielleicht könnt Ihr mir kurz bescheid geben, ob ich das alles so richtig verstanden habe und was zu beachten ist.

Vorab vielen Dank für Eure Hilfe.

Viele Grüße

[wolfinho]

Fast komplett:

I-O-CONTROL.
COMMITMENT CONTROL FOR MyFile1 [MyFile2] ...

Bei der Umwandlung ist nichts zu beachten, da die Commit-Art (*CHG) von außen durch STRCMTCTL gesteuert wird.

Wenn du allerdings mit embedded SQL arbeitest, reicht:

EXEC SQL SET OPTION COMMIT=*CHG
END-EXEC

aus.

Hallo nochmal,

vielen Dank für die Antworten. Leider bekomme ich bei der Umwandlung des COBOL-Programmes mit embedded SQL jetzt den folgenden Fehler:

SQL0084: Position 14 SQL-Anweisung nicht zulässig.

In der Hilfe habe ich folgendes gefunden:

-- Die Anweisung SET OPTION ist nur in REXX, in einem vorkompilierten Programm oder in SQL-Routinen zulässig. In einem vorkompilierten Programm ist sie nur als erste SQL-Anweisung in dem Programm zulässig.

Die SET-Option Anweisung habe ich aber bereits gleich zu Beginn meines Programmes:

PROCEDURE DIVISION.
STEUERUNG SECTION.
STEUERUNG-01.
EXEC SQL
SET OPTION COMMIT=*CHG
END-EXEC
IF SQLCODE NOT = ZERO
PERFORM UP-SQL-ERROR
END-IF
EXEC SQL
WHENEVER SQLERROR GOTO UP-SQL-ERROR
END-EXEC
PERFORM VORLAUF
PERFORM VERARBEITUNG
PERFORM NACHLAUF
PERFORM UP-PGM-ENDE.
STEUERUNG-99.
EXIT.


?????????

Kann es an der Definition der Cursor

EXEC SQL
DECLARE CDPI018 CURSOR FOR
SELECT
*
FROM
TADWI018
ORDER BY
RZBK,
DATABGESCH,
NRKONTO
END-EXEC.

oder an der Definition der SQLCA

EXEC SQL
INCLUDE SQLCA
END-EXEC.

in der Working-Storage Section liegen


?????

[wolfinho]

Hallo die 2te,

habe das Problem gefunden. Ich dachte innerhalb des Programmablaufes muß das SQL SET OPTION zuerst aufgerufen werden.

Da der SQL-Precompiler aber nicht den Programmablauf kennt, muß ich das Statement in die Working-Storage Section als Erstes definieren (vor Cursor und SQLCA)

viele grüße und ein schönes Wochenende