Satzsperren verteiulte Programme

[itec01]

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.

[Robi]

letzteres

bla bla bla um auf 20 Zeichen zu kommen

[Fuerchau]

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.

[itec01]

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.

[Fuerchau]

Ja, aber dies gilt nicht, wenn du in PGM B mit SQL einen Update machen willst. Da ziehen diese Methoden nicht mehr.

[itec01]

Ist ja kein SQL update, ganz normaler RPG update.

[Fuerchau]

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.