Frage zur Commitmentsteuerung

[JonnyRico]

Hi,

ich habe jetzt zum ersten Mail eine Tabelle die in einem Journal aufgezeichnet wird und in die ich schreiben muss. Da wollte ich dann natürlich auch Commit nutzen. Wie schreibe ich die Daten denn dann aber fest? Jetzt ist es so das wenn ich den Insert mache und danach in die Tabelle schaue der neue Satz da ist. Wenn ich dann aber meinen Job beende, dann ist er wieder raus. Kann mir jemand vielleicht erklären wieso das so ist und was ich tun mus?? Vielen Dank im Voraus.

Gruß

Sascha

[Fuerchau]

Vor dem Programm auf jeden Fall STRCMTCTL *CHG
Im Programm einfach COMMIT bzw. ROLLBACK kodieren.

Allerdings ist im Rollback-Fall folgendes zu beachten:
Arbeitest du mit normallen SETLL/READ/READE usw. wird nach einem Rollback der aktuelle Satzzeiger für Input-Dateien wieder auf den Stand seit letztem Commit zurückgesetzt !!

Wenn also ein PGM z.B. bei einer Fehlerbedingung einen Rollback setzt, kann es sein dass das PGM kreist, da ja der Satzzeiger des READ zurückgesetzt wird und somit der Fehler aller Wahrscheinlichkeit wieder auftaucht.

Also:
Nach einem Rollback sollte man auf jeden Fall den Satzzeiger per SETLL wieder neu setzen.

Dies gilt allerdings nur, wenn die LF auch im Journal aufgezeichnet wird.

[kuempi von stein]

.......
Dies gilt allerdings nur, wenn die LF auch im Journal aufgezeichnet wird.

räusper...







.

[Fuerchau]

Satzzeiger-Probleme betreffen ausschliesslich aufgezeichnete PF's, LF's !

Noch was:
Solange kein Commit erfolgt ist, ist JEDER geänderte oder eingefügte Satz für andere Job's gegen Veränderung GESPERRT ! Gelesen werden kann er aber trotzdem (mit ggf. ungeahnten Konsequenzen).

Commit-Level:
*CHG: nur veränderte Daten sind gesperrt
*CS: auch eine aktuell gelesener Satz wird gesperrt und zwar auch dann wenn man READ(N) bzw. CHAIN(N) verwendet !
*ALL: alle zugegriffene Sätze, also auch nur gelesene, bleiben bis zum Commit gesperrt

Man sollte auch bedenken, dass sog. offene Commit's (also gesperrte Daten) nicht durch den Bediener-Dialog verängert werden (Kaffee-Problematik) !

[Fuerchau]

@kuempi

Die ganz vorsichtigen, die dann aber auch nix verstanden haben.
Dann kann ich mir das Commit auch sparen, da die Aufzeichnung ja bereits reicht.

[JonnyRico]

Hi ihr beiden,

danke für die aufklärenden Worte. Mensch da hat sich das zur Arbeit kommen heut morgen doch schon wieder richtig gelohnt.
Danke nochmals

Gruß

Sascha

[BenderD]

Hallo,

das mit dem automatischen Rollback von offenen Transaktionen ist ja gerade der Clou an der Commit Steuerung. Egal was immer passieren mag, es bleiben keine inkompletten Transaktionen in der Datenbank drin.

@Baldur:
Zum überlesen gesperrter Sätze, die sich in einer Transaktion befinden ist die Sperrstufe commited read vorgesehen.

Die Kaffepausen Problematik ist gerade mit Commit einfach und sicher zu lösen: Commit (oder gegebenen Falls ROLLBACK) vor jedem EXFMT oder anderem READ auf einen Bildschirm.

mfg

Dieter Bender

Satzzeiger-Probleme betreffen ausschliesslich aufgezeichnete PF's, LF's !

Noch was:
Solange kein Commit erfolgt ist, ist JEDER geänderte oder eingefügte Satz für andere Job's gegen Veränderung GESPERRT ! Gelesen werden kann er aber trotzdem (mit ggf. ungeahnten Konsequenzen).

Commit-Level:
*CHG: nur veränderte Daten sind gesperrt
*CS: auch eine aktuell gelesener Satz wird gesperrt und zwar auch dann wenn man READ(N) bzw. CHAIN(N) verwendet !
*ALL: alle zugegriffene Sätze, also auch nur gelesene, bleiben bis zum Commit gesperrt

Man sollte auch bedenken, dass sog. offene Commit's (also gesperrte Daten) nicht durch den Bediener-Dialog verängert werden (Kaffee-Problematik) !

[Fuerchau]

@Dieter

Leider gibts da zwischen LowLevel-Commit (RPG) und SQL einen kleinen Unterschied.
Im STRCMTCTL kann ich dies nicht angeben, so dass RecordlevelAccess grundsätzlich "schmutzige" Daten lesen kann.
Im SQL kann ich per "set option commit=*rr" das so angeben, dass ich keine Schmutzdaten bekomme.

Und was die Kaffeepause angeht, so ist das zwar mit dem Commit/Rollback klar, aber das Design der Anwendung muss passen, sonst committe ich eben doch unvollständige Daten.
Bisherige Anwendungen erlauben auch eine Kaffeepause, da sie häufig eigene Sperr-/Recovery-Methoden entwickelt haben.
Unter Commit sieht die Welt leider häufig anders aus, insbesonders wenn gemeinsame Daten (Stammdaten) geändert werden.

Nicht umsonst hat sich SAP dieser Problematik mit dem BatchInput elegant aus der Affäre gezogen.

[BenderD]

@Baldur: read committed ist das was as400 auch *CS nennt und das geht bei STRCMTCTL - was dann mit Rekord Löffel Ekzem passiert habe ich nicht verifiziert. (RR ist der mit den Lesesperren)

Nochmal zur Kaffeepause: wer da Dummfug programmiert, dem ist nicht zu helfen. alles was da ohne Commit drumherum gefummelt worden ist, geht mit Commit haar genauso und ohne Commit werden ohnehin unvollstäändige Transaktionen festgeschrieben, da wird mit einem kleinen Commit vor dem EXFMT nix schlechter - und man kann keine Sperre vergessen.

mfg

Dieter

@Dieter

Leider gibts da zwischen LowLevel-Commit (RPG) und SQL einen kleinen Unterschied.
Im STRCMTCTL kann ich dies nicht angeben, so dass RecordlevelAccess grundsätzlich "schmutzige" Daten lesen kann.
Im SQL kann ich per "set option commit=*rr" das so angeben, dass ich keine Schmutzdaten bekomme.

Und was die Kaffeepause angeht, so ist das zwar mit dem Commit/Rollback klar, aber das Design der Anwendung muss passen, sonst committe ich eben doch unvollständige Daten.
Bisherige Anwendungen erlauben auch eine Kaffeepause, da sie häufig eigene Sperr-/Recovery-Methoden entwickelt haben.
Unter Commit sieht die Welt leider häufig anders aus, insbesonders wenn gemeinsame Daten (Stammdaten) geändert werden.

Nicht umsonst hat sich SAP dieser Problematik mit dem BatchInput elegant aus der Affäre gezogen.

[kuempi von stein]

Hi,

ich habe jetzt zum ersten Mail eine Tabelle die in einem Journal aufgezeichnet wird und in die ich schreiben muss. Da wollte ich dann natürlich auch Commit nutzen. Wie schreibe ich die Daten denn dann aber fest? Jetzt ist es so das wenn ich den Insert mache und danach in die Tabelle schaue der neue Satz da ist. Wenn ich dann aber meinen Job beende, dann ist er wieder raus. Kann mir jemand vielleicht erklären wieso das so ist und was ich tun mus?? Vielen Dank im Voraus.

Gruß

Sascha

hello,

wenn Du mit commitment arbeitest, legst Du sozusagen gedanklich erst mal sogen. Transaktionsgrenzen fest.
Mal ein Beispiel wo es nicht um Kopfdatei und Positionen geht:
Es muss ein neuer Mitarbeiter angelegt werden, und dazu muss ausserdem in einer Urlaubstabelle und in einer Kaffepausentabelle etwas hinzugefügt werden.
Wenn Du jetzt unterwegs abschmieren würdest, könnte es sein, dass nicht alle notwendigen Sätze geschrieben wurden und der hinzugefügte Mitarbeiter keinen Urlaub oder keine Kaffeepause machen darf, weil er da nicht drin steht.
Wenn dass jetzt unter commit gelaufen wäre, würde der Rollback dafür sorgen, dass gar kein Satz geschrieben wurde bzw. im Positivfall durch den Commit am Ende die drei Sätze in den drei Dateien "gefixt" werden.
Man hat ergo mehr Sicherheit wenn solche Zusammenhänge benötigt werden.
Im Extremfall kann man aber auch nach jedem write/update ein commit absetzen...
das sind dann die ganz vorsichtigen...

kuempi