Record 367461 member PARTMASTER already locked to this job.

[harkne]

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

[mk]

Hi,

chain mit Update ist da ein beliebtes Instrument..............
gruß
Michael

[Fuerchau]

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.

[harkne]

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.

[Fuerchau]

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

[harkne]

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

[Fuerchau]

Dann prüfe, ob die Datei mit SHARE(*YES) geöffnet wurde (DSPJOB, Offene Dateien, Spalte SHARE, Anzahl Open).

[harkne]

Ich ergebe mich. Jetzt lockt er auf einmal.

[BenderD]

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

[Fuerchau]

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.

[BenderD]

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.

... da gibt es ein paar ganz einfache Grundregeln:
- Commit Master hat eine named ACTGRP und nur der darf commit/rollback machen
- commit slaves haben ACTGRP *CALLER
- wenn die Transaktion komplett ist, beendet der commit master die transaktion mit commit, wenn alles geklappt hat, hat etwas nicht geklappt (auch bei einer Satzsperre einer konkurrierenden Transaktion) mit rollback und alle Sperren werden freigegeben.

man muss das nur wollen!!!

D*B

PS: das ist übrigens Stand der Technik - und alles andere ist nach europäischem Produkthaftungsgesetz fehlerhaft.