[NEWSboard IBMi Forum]
  1. #1
    Registriert seit
    Sep 2004
    Beiträge
    327

    Satzsperren verteiulte Programme

    Hallo Zusammen,
    ich benötige mal einen basic Input.
    Ein Programm A ruft ein Programm B auf. Beide Programme laufen unter Commit und nutzen die selbe LF und befinden sich auch in der selben Aktivationgroup.
    Programm B bricht ab beim Chain auf die LF mit Satzsperren. Programm A hat auch einen Chain gemacht, daher ist der Satz gesperrt, aber ich dachte, dass innerhalb der selben Activation Gruppe dies kein Problem bereitet, aber tut es wohl doch. Ich habe geschaut, Programm A hat keine offene Commits.
    Noch zur Info: Das Programm B wird auch noch von anderen Programmen aufgerufen.
    Ich habe dann einen close im PGM A gemacht, das hat dann zwar funktioniert, aber die Datei wäre dann für einen Moment frei, was nicht OK ist.

    Danke schon mal.

    Gruß Klaus

  2. #2
    Registriert seit
    Jun 2001
    Beiträge
    1.973
    Satzsperre hat nicht immer mit commit zu tun.
    Ein (für Updater) gelesener Satz ist gesperrt bis das Update kommt, ein anderer Satz der gleichen Datei gelesen wird oder ein unlock gemacht wird.
    Wenn mit Commit gearbeitet wird, können mehrere Update als 'Gruppe' definiert werden und, im Fehlerfall, gemeinsam zurück gedreht werden. (Datei intern oder auch übergreifend)
    Unter commit ist ein Satz erst mit dem Commit/Rollback frei, ohne Commit beim update/unlock
    Das Notwendige steht über dem technisch machbaren.
    (klingt komisch, funktioniert aber!)

  3. #3
    Registriert seit
    Sep 2004
    Beiträge
    327
    Ja, genau, bisher hat das auch immer sehr gut funktioniert. Nur jetzt kommt das PGM B auf Satzsperren, die sich mir nicht erschließen.
    Die Commit Logik ist wie folgt:
    CL PGM: STRCMTCTL LCKLVL(*CHG) CMTSCOPE(*JOB)
    CL ruft PGM A auf unter commit
    PGM A ruft B auf unter Commit
    PGM A macht dann den Commit oder Rollback im Fehlerfall

  4. #4
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Du musst unterscheiden zwischen SQL und RLA (klassisch).
    Commit(*CHG) besagt ja nur, dass geänderte Daten bis zum Commit gesperrt bleiben.
    Beim Lesen mit SQL Select entsteht erstmal keine Sperre.
    Machst du aber per Chain/READ/READE einen Zugriff auf eine PF/LF die für Update geöffnet ist, wird weiterhin eine Sperre auf diesem Satz gesetzt.
    Dies entspricht i.Ü. auch dem "Select .... for update".
    Vorsicht ist bei einem Commit(*CS/*ALL). In diesem Fall werden alle gelesenen Sätze mit Select ebenso gesperrt.
    Für einen erfolgreichen Commit/Rollback müssen alle betroffenen Tabellen in einem Journal aufgezeichnet sein. Bei F-Bestimmungen müssen die Dateien ebenso mit "commit" gekennzeichnet werden da sonst für diese Zugriffe intern automatisch "with nc" angewendet wird.
    Dies gilt i.Ü. auch für SQL: "Update ... with nc" untergräbt eine Transaktionskontrolle.

    Nachtrag:
    Wenn du dieselbe Tabelle per F-Bestimmung sperrst wird ein anderer SQL auch im selben Job gehindert einen Update durchzuführen da SQL den Open der F-Bestimmung nicht verwendet.

    https://www.ibm.com/docs/en/i/7.1?to...mit-lock-level
    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

  5. #5
    Registriert seit
    Sep 2004
    Beiträge
    327
    Danke, aber die Definitionen sind mir bewusst, ich nutze dieses Logik schon seit Jahren, nur wieso gibt es eine Satzsperre im gleichen Aufrufstapel und in der gleichen Commit Umgebung, sprich Programm B bricht ab, weil Programm A den Satz gesperrt hat. Ich meine, dass dies schon immer funktioniert hat, kann mich aber täuschen.

  6. #6
    Registriert seit
    Jun 2001
    Beiträge
    1.973
    letzteres

    bla bla bla um auf 20 Zeichen zu kommen
    Das Notwendige steht über dem technisch machbaren.
    (klingt komisch, funktioniert aber!)

  7. #7
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Das funktioniert nur unter 1 Bedingung:
    Die PF/LF muss mit SHARE(*YES) definiert sein, dann wird der Open übergeordneter Programme übernommen.
    Aber Vorsicht:
    Wenn Programm A mit I öffnet, wird Programm B auch mit I öffnen, selbst wenn U angegeben ist.

    SQL interessiert Share jedoch nicht. Je nach Optimierung und Vergleichbarkeit einer Abfrage wird derselbe sog. ODP wieder verwendet.
    Allerdings kann es da durch Unterschiede auch hier zu mehrfachem Open kommen.
    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. #8
    Registriert seit
    Sep 2004
    Beiträge
    327
    Moin,
    das ist so. Immer share(*YES). Beide Programme haben die Datei mit update eröffnet. Es ist ja auch die selbe LF und der selbe Satz der gesperrt ist.
    Zum Hintergrund:
    PGM A soll den Satz sperren, damit zwischen PGM Aufruf A-> B kein anderes PGM den Satz sperren kann.
    PGM A macht den CHAIN und PGM B macht den CHAIN.

  9. #9
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Ja, aber dies gilt nicht, wenn du in PGM B mit SQL einen Update machen willst. Da ziehen diese Methoden nicht mehr.
    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

  10. #10
    Registriert seit
    Sep 2004
    Beiträge
    327
    Ist ja kein SQL update, ganz normaler RPG update.

  11. #11
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Dann debugge dein Programm, prüfe die offenen Dateien und wer die Sperre tatsächlich hält.
    Alles andere ist Spekulation.
    Ob ein Shared-Open stattfindet, kannst du im DSPJOB => 14 der Spalte Shr-Nr. entnehmen.
    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. Umstellung von Chain auf setll + reade - seitdem dauernd Satzsperren
    By ncc1701e in forum NEWSboard Programmierung
    Antworten: 10
    Letzter Beitrag: 15-05-18, 13:23
  2. Teildatei- Satzsperren bei SQLRPGLE obwohl Programm zu
    By ExAzubi in forum NEWSboard Programmierung
    Antworten: 14
    Letzter Beitrag: 30-01-11, 10:26
  3. Frage zum Thema "Satzsperren"
    By CrazyJoe in forum NEWSboard Programmierung
    Antworten: 6
    Letzter Beitrag: 25-08-07, 12:30
  4. Satzsperren und Java
    By mwithake in forum NEWSboard Programmierung
    Antworten: 3
    Letzter Beitrag: 14-06-06, 19:12
  5. Satzsperren in RPG
    By peter.kinne in forum IBM i Hauptforum
    Antworten: 2
    Letzter Beitrag: 18-10-04, 08:39

Berechtigungen

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