[NEWSboard IBMi Forum]
Seite 3 von 4 Erste ... 2 3 4 Letzte
  1. #25
    Registriert seit
    Feb 2001
    Beiträge
    20.370
    Generelles zu commit und Transaktionen:

    Transaktionen sind immer in einem Kontext zu sehen, d.h., alles was zu einem Kontext gehört muss in einer Transaktion abgeschlossen sein.
    Randbedingung: eine Transaktion darf nie durch eine Userinteraktion unterbrochen werden, also z.B. auf eine Bildschirmeingabe warten.

    Transaktionen laufen grundsätzlich nur innerhalb einer ACTGRP.
    Durch entsprechende Aufrufdefinitionen *CALLER muss also dafür gesorgt werden, dass diese im Kontext in einer ACTGRP passieren.

    Wenn man ILERPG/ILECOBOL/CLLE/CLE verwendet, ist ein STRCMTCTL grundsätzlich nicht mehr erforderlich, das erledigt die SQL-Runtime für uns. Dabei wird immer eine Commit-Gruppe der ACTGRP erstellt.

    Commit beenden die Transaktion und alle Daten bleiben erhalten. Dies passiert ausschließlich innerhalb der ACTGRP.

    Im Job gibt es mehrere Standard-ACTGRP's:
    *DEFAULT 1: System-ACTGRP
    *DEFAULT 2: User ACTGRP
    QILE: 1. automatische ACTGRP für ILE-Programme
    "Benannte": durch Programme benannte ACTGRP
    *NEW: temporäre ACTGRP

    Alle Update/Insert Daten bleiben bei einer aktiven Transaktion gesperrt.
    Delete wird ja sofort ausgeführt und ist daher bereits weg.
    Bei einem "Select .... for Update" wird beim Lesen beeits gesperrt.
    *CHG: Jede Veränderung wird gesperrt.
    *CS: Jeder gelesene Satz wird zusätzlich gesperrt
    *ALL: Alle gelesenen Sätze werden zusätzlich gesperrt, also Vorsicht!

    Ein Commit ist sehr schnell, weil die Commit-Definition geschlossen wird und alle Sperren aufgehoben werden.
    Ein Rollback liest nun rückwärts die Daten wieder aus dem Journal und stellt die Daten wieder her.
    Danach wird wie beim commit die Commit-Definition geschlossen und alle Sperren aufgehoben.
    Ein IDENTITY-Counter wird nie zurückgesetzt.

    Zu deiner Frage:
    Wenn also alle Programme mit *CALLER erstellt werden, läuft alles in der selben ACTGRP, allerdings mit einer Ausnahme: Jedes Programm muss ILE können!

    Wird z.B. ein CLP oder RPGIV aufgerufen, also ein OPM Programm, läuft dieses immer in *DEFAULT 2, hat also eine andere Commit-Ebene.

    Hat nun ein Programm oder Service-Programm eine eigene ACTGRP werden hier getrennte Transaktionen durchgeführt. Beim Auflösen der ACTGRP (verlassen der obersten Ebene) wird automatisch ein ROLLBACK gemacht.
    Somit kann also ein Service z.B. Protokollsätze schreiben, die auch durch einen Rollback nicht verschwinden. Oder eben eine eigene Transaktion über mehrere Aktionen erstellen.

    Trigger:
    Es ist per Definition nicht erlaubt, dass ein Trigger eine Transaktion abschließt.
    Dies gilt auch für aus dem Trigger aufgerufenen Programme innerhalb derselben Transaktion.
    Wenn ein Trigger eine andere ACTGRP aufruft, kann diese wiederum eigene Transaktionen durchführen.
    Achtung vor Rekursion:
    Standard ILERPG ist nicht rekursionsfähig. Um eine Rekursion zu ermöglichen, muss das Programm über eine MAIN-Funktion verfügen und hat dann keinen Zyklus.
    Eine endlose Rekursion gibt es nicht, da stirbt dann die ACTGRP.

    Deadlocks:
    Durch die ACTGRP's kann es auch innerhalb eines Jobs bereits zu Deadlocks kommen, also nicht nur jobübergreifend.

    So, für einen groben Überblick sollte das reichen.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  2. #26
    Registriert seit
    Sep 2004
    Beiträge
    336
    Zitat Zitat von B.Hauser Beitrag anzeigen
    Vielleicht sieh ich das mal wieder zu einfach!
    Ich würde einfach den CL-Befehl STMCMTCL ausführen. Wenn er klappt, war Commitment Steuerung nicht aktiv, dann beende ich die Commitemnt Control wieder.
    Ist die Commitment Control aktiv, geht STMCMTCL schief.
    So habe ich es jetzt auch gemacht.
    Aber es bleibt noch eine Unschärfe, die mich interessiert, wie das so in der Praxis umgesetzt wird.

    STRCMTL ist gemacht
    PGM A hat mehrere Dateien unter Commit, aber nicht die Datei, wo der Trigger hängt
    durch eine Dateioperation wird der Trigger ausgelöst
    Das Trigger Programm würde vermutlich abbrechen, weil der STRCMTL aktiv ist, aber nicht die Datei des Triggers unter commit läuft

    Prinzipiell könnte man dies auch als Programmfehler abstempeln, aber ausschließen kann ich es halt auch nicht.

    Man müsste erkennen, ob die Datei in dem Trigger Programm unter Commit läuft. Den API's vertraue ich da nicht wirklich.

  3. #27
    Registriert seit
    Sep 2004
    Beiträge
    336
    Zitat Zitat von Fuerchau Beitrag anzeigen
    Generelles zu commit und Transaktionen:

    Transaktionen sind immer in einem Kontext zu sehen, d.h., alles was zu einem Kontext gehört muss in einer Transaktion abgeschlossen sein.
    Randbedingung: eine Transaktion darf nie durch eine Userinteraktion unterbrochen werden, also z.B. auf eine Bildschirmeingabe warten.

    Transaktionen laufen grundsätzlich nur innerhalb einer ACTGRP.
    Durch entsprechende Aufrufdefinitionen *CALLER muss also dafür gesorgt werden, dass diese im Kontext in einer ACTGRP passieren.

    Wenn man ILERPG/ILECOBOL/CLLE/CLE verwendet, ist ein STRCMTCTL grundsätzlich nicht mehr erforderlich, das erledigt die SQL-Runtime für uns. Dabei wird immer eine Commit-Gruppe der ACTGRP erstellt.

    Commit beenden die Transaktion und alle Daten bleiben erhalten. Dies passiert ausschließlich innerhalb der ACTGRP.

    Im Job gibt es mehrere Standard-ACTGRP's:
    *DEFAULT 1: System-ACTGRP
    *DEFAULT 2: User ACTGRP
    QILE: 1. automatische ACTGRP für ILE-Programme
    "Benannte": durch Programme benannte ACTGRP
    *NEW: temporäre ACTGRP

    Alle Update/Insert Daten bleiben bei einer aktiven Transaktion gesperrt.
    Delete wird ja sofort ausgeführt und ist daher bereits weg.
    Bei einem "Select .... for Update" wird beim Lesen beeits gesperrt.
    *CHG: Jede Veränderung wird gesperrt.
    *CS: Jeder gelesene Satz wird zusätzlich gesperrt
    *ALL: Alle gelesenen Sätze werden zusätzlich gesperrt, also Vorsicht!

    Ein Commit ist sehr schnell, weil die Commit-Definition geschlossen wird und alle Sperren aufgehoben werden.
    Ein Rollback liest nun rückwärts die Daten wieder aus dem Journal und stellt die Daten wieder her.
    Danach wird wie beim commit die Commit-Definition geschlossen und alle Sperren aufgehoben.
    Ein IDENTITY-Counter wird nie zurückgesetzt.

    Zu deiner Frage:
    Wenn also alle Programme mit *CALLER erstellt werden, läuft alles in der selben ACTGRP, allerdings mit einer Ausnahme: Jedes Programm muss ILE können!

    Wird z.B. ein CLP oder RPGIV aufgerufen, also ein OPM Programm, läuft dieses immer in *DEFAULT 2, hat also eine andere Commit-Ebene.

    Hat nun ein Programm oder Service-Programm eine eigene ACTGRP werden hier getrennte Transaktionen durchgeführt. Beim Auflösen der ACTGRP (verlassen der obersten Ebene) wird automatisch ein ROLLBACK gemacht.
    Somit kann also ein Service z.B. Protokollsätze schreiben, die auch durch einen Rollback nicht verschwinden. Oder eben eine eigene Transaktion über mehrere Aktionen erstellen.

    Trigger:
    Es ist per Definition nicht erlaubt, dass ein Trigger eine Transaktion abschließt.
    Dies gilt auch für aus dem Trigger aufgerufenen Programme innerhalb derselben Transaktion.
    Wenn ein Trigger eine andere ACTGRP aufruft, kann diese wiederum eigene Transaktionen durchführen.
    Achtung vor Rekursion:
    Standard ILERPG ist nicht rekursionsfähig. Um eine Rekursion zu ermöglichen, muss das Programm über eine MAIN-Funktion verfügen und hat dann keinen Zyklus.
    Eine endlose Rekursion gibt es nicht, da stirbt dann die ACTGRP.

    Deadlocks:
    Durch die ACTGRP's kann es auch innerhalb eines Jobs bereits zu Deadlocks kommen, also nicht nur jobübergreifend.

    So, für einen groben Überblick sollte das reichen.
    Danke Dir für die ausführliche Beschreibung.

  4. #28
    Registriert seit
    Mar 2002
    Beiträge
    5.309
    Zitat Zitat von itec01 Beitrag anzeigen
    So habe ich es jetzt auch gemacht.
    Aber es bleibt noch eine Unschärfe, die mich interessiert, wie das so in der Praxis umgesetzt wird.

    STRCMTL ist gemacht
    PGM A hat mehrere Dateien unter Commit, aber nicht die Datei, wo der Trigger hängt
    durch eine Dateioperation wird der Trigger ausgelöst
    Das Trigger Programm würde vermutlich abbrechen, weil der STRCMTL aktiv ist, aber nicht die Datei des Triggers unter commit läuft

    Prinzipiell könnte man dies auch als Programmfehler abstempeln, aber ausschließen kann ich es halt auch nicht.

    Man müsste erkennen, ob die Datei in dem Trigger Programm unter Commit läuft. Den API's vertraue ich da nicht wirklich.
    ... wer hat denn diesen Verhau angerichtet? Jetzt wundert es mich auch nicht mehr, dass weder der Trigger Buffer, noch QTNRCMTI die passende Information liefert. Dasselbe Programm läuft mal unter commit, mal nicht und wenn es unter commit läuft, dann wird eine Datei mal mit, mal ohne commit geöffnet und dann hänge ich noch einen Trigger an diese Datei, der damit zurecht kommen soll.
    Warum nehmt ihr das Feld für den User nicht einfach in die Datei auf und lasst es von der Datenbank pflegen?

    D*B

    PS: Sauberer wäre es allerdings diesen Huddel zu bereinigen!
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  5. #29
    Registriert seit
    Feb 2001
    Beiträge
    20.370
    Ja und dann auch nicht die Fälle vergessen, bei denen am SQL noch ein "with nc" hängt.
    Z.B. "insert into table bla values(.....) with nc".
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  6. #30
    Registriert seit
    Sep 2004
    Beiträge
    336
    Zitat Zitat von BenderD Beitrag anzeigen
    ... wer hat denn diesen Verhau angerichtet? Jetzt wundert es mich auch nicht mehr, dass weder der Trigger Buffer, noch QTNRCMTI die passende Information liefert. Dasselbe Programm läuft mal unter commit, mal nicht und wenn es unter commit läuft, dann wird eine Datei mal mit, mal ohne commit geöffnet und dann hänge ich noch einen Trigger an diese Datei, der damit zurecht kommen soll.
    Warum nehmt ihr das Feld für den User nicht einfach in die Datei auf und lasst es von der Datenbank pflegen?

    D*B

    PS: Sauberer wäre es allerdings diesen Huddel zu bereinigen!
    Genau das haben wir ja, ein User Feld in der DB, die durch den Trigger gefüllt wird. Hatte ich ganz am Anfang geschrieben.
    Ich hatte mein Beispiel zuvor ja als Fehler abgestempelt (wir haben das so nicht programmiert), aber dennoch wollte ich nur wissen, ob man im RPG erkennt, ob eine Datei gerade unter commit läuft.
    Aber auf jeden Fall ist mit den Triggern unter commit nicht zu spaßen, ganz besonders wenn mal so (SQL commit) oder so (RPG commit) gemacht wurde.

  7. #31
    Registriert seit
    Feb 2001
    Beiträge
    20.370
    Ob per SQL oder per RPG gibts tatsächlich einen Unterschied.
    Wenn STRCMTCTL nicht gestartet ist, gibts beim RPG-Commit eine Abbruchmeldung.
    Beim exec sql commit gibts nur einen SQLSTATE bzw. SQLCODE.

    Wenn man einen Before-Update/Insert Trigger macht, braucht man ja nur den Datenpuffer zu ändern und sich um Commit nicht kümmern, was per Definition ja sowieso nicht erlaubt ist.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  8. #32
    Registriert seit
    Mar 2002
    Beiträge
    5.309
    Zitat Zitat von itec01 Beitrag anzeigen
    Genau das haben wir ja, ein User Feld in der DB, die durch den Trigger gefüllt wird. Hatte ich ganz am Anfang geschrieben.
    Ich hatte mein Beispiel zuvor ja als Fehler abgestempelt (wir haben das so nicht programmiert), aber dennoch wollte ich nur wissen, ob man im RPG erkennt, ob eine Datei gerade unter commit läuft.
    Aber auf jeden Fall ist mit den Triggern unter commit nicht zu spaßen, ganz besonders wenn mal so (SQL commit) oder so (RPG commit) gemacht wurde.
    ... für ein Feld in der selben Datei reicht es aus with default(user) bei der Erstellung anzugeben und das Feld in Ruhe zu lassen, dann steht der Inhalt des special register USER beim insert und update drin und beim ROLLBACK wird das zurückgesetzt auf den vorherigen Wert. Da braucht es keine Dateioperation im Trigger, die ACTGRP ist dann Wurscht und das Sperrlevel des Triggers ist ebenfalls egal.

    D*B
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  9. #33
    Registriert seit
    Sep 2004
    Beiträge
    336
    Zitat Zitat von BenderD Beitrag anzeigen
    ... für ein Feld in der selben Datei reicht es aus with default(user) bei der Erstellung anzugeben und das Feld in Ruhe zu lassen, dann steht der Inhalt des special register USER beim insert und update drin und beim ROLLBACK wird das zurückgesetzt auf den vorherigen Wert. Da braucht es keine Dateioperation im Trigger, die ACTGRP ist dann Wurscht und das Sperrlevel des Triggers ist ebenfalls egal.

    D*B
    Danke Dir, ja ich weiß, aber funktioniert bei uns nicht, weil im Falle von Barcode Prozessen mit Handscannern ein 4stelliger User stehen muss. Daher die Idee mit dem Trigger.

  10. #34
    Registriert seit
    Feb 2001
    Beiträge
    20.370
    Das ist ja auch legitim, aber wofür muss der Trigger wissen, ob Commit an oder aus ist?
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  11. #35
    Registriert seit
    Sep 2004
    Beiträge
    336
    Zitat Zitat von Fuerchau Beitrag anzeigen
    Das ist ja auch legitim, aber wofür muss der Trigger wissen, ob Commit an oder aus ist?
    Ich hatte es doch versucht zu erklären. Wenn das Trigger Programm es nicht weiß, dann bricht es mir ab, je nachdem ob der STRCMTL aktiv ist oder nicht. Ich möchte auf keinen Fall mit dem trigger Programm etwas festschreiben, was im Falles eines mögliches Rollbacks dann stehen bleibt.
    Das Trigger Programm hat in den F-Bestimmungen den commit unter Bezugszahl. Die Bezugszahl setze ich aktuell auf 1 oder 0, je nachdem ob der STRCMTL aktiv ist oder nicht.

  12. #36
    Registriert seit
    Feb 2001
    Beiträge
    20.370
    Da hilft dann nichts anderes, als den Open in eine Monitor-Gruppe zu stellen und den Open mit Commit zuerst zu versuchen.
    Genauso musst du die Dateien aber auch sofort wieder schließen, da beim nächsten Mal der Status ein anderer sein kann.
    Performant wird das sicher nicht, da Dateien im Trigger ja durchaus offen bleiben könnten.

    Aber noch mal auf Anfang zurück:
    "und im Trigger Programm einen chain und update gemacht."

    Warum machst du keinen Before-Trigger, hatte ich oben schon mal gefragt?
    Dann ergänzt du die Daten nur im Datenpuffer "Before-Image" und der Write erfolgt dann nach dem Trigger.
    Beim ADDPFTRG muss dann ALWREPCHG(*YES) gesetzt werden um Pufferänderungen zu erlauben.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

Similar Threads

  1. Antworten: 1
    Letzter Beitrag: 22-03-19, 16:52
  2. Journal auswerten
    By rr2001 in forum IBM i Hauptforum
    Antworten: 10
    Letzter Beitrag: 03-09-15, 07:37
  3. Journal Receiver
    By KingofKning in forum IBM i Hauptforum
    Antworten: 14
    Letzter Beitrag: 10-03-15, 14:29
  4. Journal abhängen
    By Mädele in forum IBM i Hauptforum
    Antworten: 1
    Letzter Beitrag: 26-12-05, 09:43
  5. Backup über Journal ?
    By Wirnitzer in forum IBM i Hauptforum
    Antworten: 4
    Letzter Beitrag: 17-10-01, 10:13

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •