View Full Version : Record 367461 member PARTMASTER already locked to this job.
Hallo zusammen,
ich habe im Dump die im Titel genannte Nachricht erhalten.
Kann mir jemand einen Tipp geben wie ich es hin bekomme, dass der eigene Job eine Satzsperre auf sich selbst macht
Danke
Viele Grüße Harkne
Hi,
chain mit Update ist da ein beliebtes Instrument..............
gruß
Michael
Da "im Normalfall" jedes Programm seine Dateien selber öffnet, kann eben jedes Programm seine eigenen Satzsperren festhalten.
Wenn das Programm dann noch mit *INLR = *OFF verlassen wird bleiben die Sperren bestehen.
Häufiger Fehler bei der Programmierung ist der Mandantenwechsel oder Gruppenwechsel.
Wenn ich mit READE Daten lese, wird EOF gemeldet wenn kein Schlüssel mehr passt.
Mache ich aber einen READ mit anschließender IF-Abfrage um die Verarbeitung zu beenden, bleibt der letzte Satz bei einer U-Datei gesperrt!
In diesem Fall sollte ich dann einen UNLCK kodieren um die Satzsperren aufzueben (CHAIN(N) geht natürlich auch).
SHARE(*YES) ist dann auch keine Lösung, da mir aufgerufene Programme meine Dateizeiger verbiegen können.
Das kann doch aber kein Problem sein wenn ich in Programm 1 einen chain mit update mache dann aus diesem Programm 2 aufrufe und der ebenfalls auf den gleichen Satz ein chain und update macht. Das mache ich häufiger.
Doch genau das ist das Problem:
PGM1 (Open Update)
CHAIN DATEI SATZ 1
CALL PGM2 (Open Update)
CHAIN DATEI SATZ 1
=> Lock
Da jedes Programm seinen eigenen Open hat ist das das selbe wie der Open in 2 Jobs.
PGM1 (Open Update)
CHAIN DATEI SATZ 1
UPDATE
CALL PGM2 (Open Update)
CHAIN DATEI SATZ 1
UPDATE
=> Kein Lock
Also was hier beschrieben ist funktioniert ohne Probleme. 1. Programm macht einen chain (Datei ist update eröffnet) und macht keinen update da ja sonst der lock weg ist und anschließend call programm 2 (von Programm 1 aus) (Datei ist ebenfalls update eröffnet) chain auf den gleichen Satz. Kein Problem. Ich denke innerhalb oder unterhalb in einem Callstack gibt es keine Probleme. Ich gebe Ihnen recht wenn Programm 1 aufgerufen wird was sperrt und anschließend Programm 2 aber nicht von Programm 1 aus
Dann prüfe, ob die Datei mit SHARE(*YES) geöffnet wurde (DSPJOB, Offene Dateien, Spalte SHARE, Anzahl Open).
Ich ergebe mich. Jetzt lockt er auf einmal.
Da "im Normalfall" jedes Programm seine Dateien selber öffnet, kann eben jedes Programm seine eigenen Satzsperren festhalten.
Wenn das Programm dann noch mit *INLR = *OFF verlassen wird bleiben die Sperren bestehen.
Häufiger Fehler bei der Programmierung ist der Mandantenwechsel oder Gruppenwechsel.
Wenn ich mit READE Daten lese, wird EOF gemeldet wenn kein Schlüssel mehr passt.
Mache ich aber einen READ mit anschließender IF-Abfrage um die Verarbeitung zu beenden, bleibt der letzte Satz bei einer U-Datei gesperrt!
In diesem Fall sollte ich dann einen UNLCK kodieren um die Satzsperren aufzueben (CHAIN(N) geht natürlich auch).
SHARE(*YES) ist dann auch keine Lösung, da mir aufgerufene Programme meine Dateizeiger verbiegen können.
... würde man SQL und commit verwenden, wäre das alles viel einfacher...
D*B
Auch bei SQL erlebt man schon sein blaues Wunder.
Vergessen wird da gerne, dass jede ACTGRP seine eigene Commitdefinition haben kann da der Default für STRCMTCTL wiederum CMTSCOPE(*ACTGRP) ist.
Serviceprogramme werden da auch schon mal gerne in eigene ACTGRP's gesteckt.
Hier wird es dann schon mal mit den Commit-Grenzen (Transaktionen) schwierig und zu Satzsperren (ACTGRP1 und ACTGRP2) und Deadlocks kommt es da mitunter auch.