View Full Version : ODBC und Journaling
Hallo!
Beim CREATE der Tabellen auf der AS/400 (ich schicke SQL-Befehle per ODBC-Treiber an die AS/400) meckert die AS/400, dass die Tabellen nicht aufgezeichnet werden können. Eigentlich will ich das ja auch gar nicht. Aber ok, habe ich also wie im Joblog beschrieben einen Journalempfänger und ein Journal mit dem vorgeschriebenen Namen QSQJRN erstellt. Jetzt lief der CREATE ohne Infomeldung einwandfrei ab. Die AS/400 hat die erstellten Tabellen nun in der Aufzeichung des Journals QSQJRN (offenbar hat der CREATE automatisch STRJRNPF ausgeführt). Ich kann nun munter in die Tabellen mit INSERT reinschreiben. Sobald die Windows-Anwendung (COBOL) durch ist (keinerlei Fehlermeldungen im Joblog zu erkennen), wird jedoch ein automatischer ROLLBACK auf der AS/400 durchgeführt. Während dieses ROLLBACK's sieht man im Joblog folgende Einträge:
Abrechnungsdaten für 136875/QUSER/QZDASOINIT nicht protokolliert; Ursache:
1.
Druckereinheit PRT01 nicht gefunden.
Abrechnungsdaten für 136875/QUSER/QZDASOINIT nicht protokolliert; Ursache:
1.
Druckereinheit PRT01 nicht gefunden.
Fehler im Befehl CHGJOB für Job 136875/QUSER/QZDASOINIT.
0 DDM-Dialoge beendet, 0 bleiben aktiv.
Hier noch die Info zur "Ursache 1":
Nachrichten-ID . . . . : CPF1301 Bewertung . . . . . . : 30
Nachrichtenart . . . . : Information
Sendedatum . . . . . . : 07.07.05 Sendezeit . . . . . . : 18:09:33
Nachricht . . . : Abrechnungsdaten für 136875/QUSER/QZDASOINIT nicht
protokolliert; Ursache: 1.
Ursache . . . . . : Job-Daten für die Abrechnung von Ressourcen für Job
136875/QUSER/QZDASOINIT wurden nicht in das Abrechnungsjournal des Systems
(QSYS/QACGJRN) protokolliert.
-- Die Ursachencodes haben folgende Bedeutung:
-- 1-Der Wert der Berechnungsebene (QACGLVL) gibt an, daß die Ebene der
Abrechnung von Ressourcen nicht gültig war, als der Job eingegeben wurde.
Das ist zu hoch für mich. Was mache ich falsch? Was bedeutet das alles?
Warum muss ich überhaupt protokollieren / journalisieren? Ich will eigentlich keine ROLLBACK-Funktionalität.
Gruß
Neptun
Wenn du im ODBC ohne Commit arbeitest (Verbindungsfolge CMT=0, bzw. ODBC-Konfig: Commit *NONE) ist ein Commit/Rollback nicht erforderlich.
Dass beim CREATE TABLE eine Warnung kommt, hat nichts zu bedeuten, da sie nur eine Warnung ist.
Ansonsten muss per ConnectObj.Begintrans /ConnectObj.Committrans die Operation "bestätigt" werden.
Die anderen Nachrichten kann man vernachlässigen, wenn kein Accounting durchgeführt wird.
Hallo!
Erstmal danke für die Antwort, aber irgendwie hilft mir die noch nicht weiter.
Ich benutze ein Tool als Zwischenstück von COBOL zu ODBC. Darum kann ich leider keine Calls auf API-Funktionen machen wie z.B. SQLSetConnectAttr um den AUTOCOMMIT einzuschalten oder ähnliches. In der DSN für die Verbindung per CA-ODBC steht alles auf Standard, also auch COMMIT *NONE.
Ich habe nun die Tabellen auf der AS/400 erstellt über ein weiteres Tool und das Warning, dass die Aufzeichnung nicht gestartet werden kann erstmal ignoriert.
Wenn ich jetzt einen INSERT mache, kommt folgende Meldung:
OdbcOneInfo: State: S1000, Native Error: -7008
'[IBM][Client Access Express ODBC-Treiber (32-Bit)][DB2/400 SQL]SQL7008 - TSTTABLE in TSTLIB für Operation ungültig.'
Ich kriege nix in die Tabellen hineingeschrieben. Im Joblog steht der Hinweis, ich soll ein Journal einrichten etc.
Aber genau das will ich ja nicht! Wie kann ich dieses verflixte Journaling ausschalten, abhängen, umgehen?
Gruß
Neptun
Tja, da würde ich mich mal an den Toolhersteller wenden, denn bei der Verbindung kann das Commit natürlich wieder eingeschaltet werden.
Ausserdem gibt es einen Ursachencode der genauere Angaben liefert.
Ich würde mal in der ODBC-Config den Debug einschalten.
Mittels WRKOBJLCK USER *USRPRF findest du dann den QZDA-Job und kannst dann mal ins Joblog schauen was denn ggf. der tatsächliche Grund ist.
Hallo!
Das besagte Tool "dreht" tatsächlich an den Connect-Options herum. Unter anderem auch am AUTOCOMMIT ... Wenn ich das Protokoll richtig deute, wird AUTOCOMMIT-OFF auf 0 gesetzt. Also doppelte Verneinung -> es wird kein Commit durchgeführt, was ja eigentlich der Einstellung im Treiber COMMIT *NONE entspricht !?
Hmm, alles etwas mysteriös. Wenn ich das Ganze über ODBCTE32.EXE mache, kann ich AUTOCOMMIT setzen wie ich will, es funktioniert immer ohne Probleme!?!?
Neben dem AUTOCOMMIT wird noch an der TXN_ISOLATION "geschraubt" ...
Es ist zum Haare ausraufen ...
Gruß
Neptun
Autocommit hat nichts damit zu tun. Dies ist nur für die Funktion, dass jede Aktion eben automatisch einen Commit auslöst.
TXN_ISOLATION deutet auf Transaktionssteuerung hin. Im ODBC heisst das auch ISOLATION LEVEL.
Die Einstellung für COMMIT *NONE ist hier XACTCHAOS oder ähnlich.
Schau mal was du zur Transaktionssteuerung findest:
CHAOS
COMMITED READ
usw. sind die Einstellungen.
Vielleicht gibts bei deinem COBOL-Compiler ja auch Umwandlungsoptionen wie auf der AS/400:
/EXEC SQL
set option commit=*none
/END-EXEC
Hallo!
Mir ist immer noch nicht klar, wer hier wo das Journaling einschaltet. Wenn ich die Journale auf der AS/400 abhänge, kann ich keine Daten hineinschreiben.
Im CA ODBC-Treiber ist COMMIT *NONE eingestellt.
Hier das ODBC-Log vom Connect (bevor der erste Tabellen-Zugriff erfolgt):
cblconfi dbload a74-a78 ENTER SQLAllocEnv
HENV * 6060EC14
cblconfi dbload a74-a78 EXIT SQLAllocEnv with return code 0 (SQL_SUCCESS)
HENV * 0x6060EC14 ( 0x01281540)
cblconfi dbload a74-a78 ENTER SQLAllocConnect
HENV 01281540
HDBC * 001283F8
cblconfi dbload a74-a78 EXIT SQLAllocConnect with return code 0 (SQL_SUCCESS)
HENV 01281540
HDBC * 0x001283F8 ( 0x012815e8)
cblconfi dbload a74-a78 ENTER SQLConnectW
HDBC 012815E8
WCHAR * 0x012816F0 [ -3] "catst\ 0"
SWORD -3
WCHAR * 0x1F7A9D2C [ -3] "******\ 0"
SWORD -3
WCHAR * 0x1F7A9D2C [ -3] "******\ 0"
SWORD -3
cblconfi dbload a74-a78 EXIT SQLConnectW with return code 0 (SQL_SUCCESS)
HDBC 012815E8
WCHAR * 0x012816F0 [ -3] "catst\ 0"
SWORD -3
WCHAR * 0x1F7A9D2C [ -3] "******\ 0"
SWORD -3
WCHAR * 0x1F7A9D2C [ -3] "******\ 0"
SWORD -3
cblconfi dbload a74-a78 ENTER SQLGetInfoW
HDBC 012815E8
UWORD 6 <SQL_DRIVER_NAME>
PTR 0x01281DD0
SWORD 510
SWORD * 0x00128278
cblconfi dbload a74-a78 EXIT SQLGetInfoW with return code 0 (SQL_SUCCESS)
HDBC 012815E8
UWORD 6 <SQL_DRIVER_NAME>
PTR 0x01281DD0 [ 22] "CWBODBC.DLL"
SWORD 510
SWORD * 0x00128278 (22)
cblconfi dbload a74-a78 ENTER SQLGetInfoW
HDBC 012815E8
UWORD 7 <SQL_DRIVER_VER>
PTR 0x01281FE0
SWORD 510
SWORD * 0x00128278
cblconfi dbload a74-a78 EXIT SQLGetInfoW with return code 0 (SQL_SUCCESS)
HDBC 012815E8
UWORD 7 <SQL_DRIVER_VER>
PTR 0x01281FE0 [ 16] "04.05.00"
SWORD 510
SWORD * 0x00128278 (16)
cblconfi dbload a74-a78 ENTER SQLGetInfoW
HDBC 012815E8
UWORD 10 <SQL_ODBC_VER>
PTR 0x01281DD0
SWORD 510
SWORD * 0x00128278
cblconfi dbload a74-a78 EXIT SQLGetInfoW with return code 0 (SQL_SUCCESS)
HDBC 012815E8
UWORD 10 <SQL_ODBC_VER>
PTR 0x01281DD0 [ 20] "03.52.0000"
SWORD 510
SWORD * 0x00128278 (20)
cblconfi dbload a74-a78 ENTER SQLGetInfoW
HDBC 012815E8
UWORD 17 <SQL_DBMS_NAME>
PTR 0x01281DD0
SWORD 510
SWORD * 0x00128278
cblconfi dbload a74-a78 EXIT SQLGetInfoW with return code 0 (SQL_SUCCESS)
HDBC 012815E8
UWORD 17 <SQL_DBMS_NAME>
PTR 0x01281DD0 [ 22] "DB2/400 SQL"
SWORD 510
SWORD * 0x00128278 (22)
cblconfi dbload a74-a78 ENTER SQLGetInfoW
HDBC 012815E8
UWORD 18 <SQL_DBMS_VER>
PTR 0x01281FE0
SWORD 510
SWORD * 0x00128278
cblconfi dbload a74-a78 EXIT SQLGetInfoW with return code 0 (SQL_SUCCESS)
HDBC 012815E8
UWORD 18 <SQL_DBMS_VER>
PTR 0x01281FE0 [ 20] "04.03.0002"
SWORD 510
SWORD * 0x00128278 (20)
cblconfi dbload a74-a78 ENTER SQLGetFunctions
HDBC 012815E8
UWORD 40
UWORD * 0x00128274
cblconfi dbload a74-a78 EXIT SQLGetFunctions with return code 0 (SQL_SUCCESS)
HDBC 012815E8
UWORD 40
UWORD * 0x00128274 (1)
cblconfi dbload a74-a78 ENTER SQLGetFunctions
HDBC 012815E8
UWORD 54
UWORD * 0x00128274
cblconfi dbload a74-a78 EXIT SQLGetFunctions with return code 0 (SQL_SUCCESS)
HDBC 012815E8
UWORD 54
UWORD * 0x00128274 (1)
cblconfi dbload a74-a78 ENTER SQLGetFunctions
HDBC 012815E8
UWORD 50
UWORD * 0x00128274
cblconfi dbload a74-a78 EXIT SQLGetFunctions with return code 0 (SQL_SUCCESS)
HDBC 012815E8
UWORD 50
UWORD * 0x00128274 (1)
cblconfi dbload a74-a78 ENTER SQLSetConnectOption
HDBC 012815E8
SQLINTEGER 102 <SQL_AUTOCOMMIT>
SQLPOINTER 0x00000000
cblconfi dbload a74-a78 EXIT SQLSetConnectOption with return code 0 (SQL_SUCCESS)
HDBC 012815E8
SQLINTEGER 102 <SQL_AUTOCOMMIT>
SQLPOINTER 0x00000000
cblconfi dbload a74-a78 ENTER SQLGetInfoW
HDBC 012815E8
UWORD 72 <SQL_TXN_ISOLATION_OPTION>
PTR 0012827C
SWORD 4
SWORD * 0x00128278
cblconfi dbload a74-a78 EXIT SQLGetInfoW with return code 0 (SQL_SUCCESS)
HDBC 012815E8
UWORD 72 <SQL_TXN_ISOLATION_OPTION>
PTR 0012827C
SWORD 4
SWORD * 0x00128278 (4)
cblconfi dbload a74-a78 ENTER SQLSetConnectOption
HDBC 012815E8
SQLINTEGER 108 <SQL_TXN_ISOLATION>
SQLPOINTER 0x00000001
cblconfi dbload a74-a78 EXIT SQLSetConnectOption with return code 0 (SQL_SUCCESS)
HDBC 012815E8
SQLINTEGER 108 <SQL_TXN_ISOLATION>
SQLPOINTER 0x00000001 (BADMEM)
cblconfi dbload a74-a78 ENTER SQLGetInfoW
HDBC 012815E8
UWORD 15 <SQL_ODBC_SQL_CONFORMANCE>
PTR 0x0012827A
SWORD 2
SWORD * 0x00128278
cblconfi dbload a74-a78 EXIT SQLGetInfoW with return code 0 (SQL_SUCCESS)
HDBC 012815E8
UWORD 15 <SQL_ODBC_SQL_CONFORMANCE>
PTR 0x0012827A (1)
SWORD 2
SWORD * 0x00128278 (2)
Wenn es der SQL_AUTOCOMMIT nicht sein soll, dann kann es doch nur noch die SQL_TXN_ISOLATION_OPTION sein, oder?
Die Doku meines Tools schweigt sich zu den COMMIT-Einstellungen leider aus ...
Kann man das nicht irgendwie auf der AS/400 grundsätzlich abhängen für eine Bibliothek oder so, dieses nicht gewollte ODBC-Journaling?
Gruß
Neptun
Nein kann man nicht.
Einzig und allein die Anwendung entscheidet über das Journal.
Sonst könnte ich ja bei jeder Anwendung das Journal einfach abstellen und die Fehler wären bereits produziert (Commit wäre ja nicht so schlimm, aber ROLLBACK würd nicht mehr gehen und das wäre ganz schlimm).
Solange du deinem COBOL-Programm nicht beibringen kannst, ohne Commit zu arbeiten, kannst du das Journal nicht abstellen.
Wende dich an den Hersteller des COBOL-Compilers bzw. SQL-Precompilers.
Nein kann man nicht.
Einzig und allein die Anwendung entscheidet über das Journal.
Sonst könnte ich ja bei jeder Anwendung das Journal einfach abstellen und die Fehler wären bereits produziert (Commit wäre ja nicht so schlimm, aber ROLLBACK würd nicht mehr gehen und das wäre ganz schlimm).
Solange du deinem COBOL-Programm nicht beibringen kannst, ohne Commit zu arbeiten, kannst du das Journal nicht abstellen.
Wende dich an den Hersteller des COBOL-Compilers bzw. SQL-Precompilers.
Ok, die Quelle des Übels ist somit ganz klar eingekreist. Danke!
Mal sehen was der Tool-Hersteller sagt :)
Gruß
Neptun
Hallo!
Der SQL-Befehl lautet
'SET TRANSACTION ISOLATION LEVEL NO COMMIT'
So weit so gut. Wenn ich im ODBCTE32.EXE einen anderen Level angebe, kann ich grundsätzlich nicht in die AS/400-Tabellen schreiben (wenn die Datei nicht im Journal aufgezeichnet wird).
Von einer IBM-Seite:
SET TRANSACTION---------------------------------------------->
(1)
>----ISOLATION LEVEL--+-NO COMMIT--------------------------+---><
| (2) |
+-READ UNCOMMITTED , READ WRITE------+
| (3) |
+-READ COMMITTED---------------------+
| (4) |
+-REPEATABLE READ--------------------+
| (5) |
'-SERIALIZABLE-----------------------'
Wenn man nun SQL_TXN_ISOLATION per ODBC-Treiber setzen möchte, fehlt aber die hier von IBM aufgeführte erste Option "NO COMMIT" !!!
Wie kann ich diese Option über ODBC setzen? Oder anders gefragt: Welcher ODBC-Befehl entspricht 'SET TRANSACTION ISOLATION LEVEL NO COMMIT' ?
Gruß
Neptun