OPM und ILE COBOL mischen

[BenderD]

zum Start von Commit unter COBOL kann ich nix beitragen.

zu den Deadlocks muss ich was sagen:
eine Satzsperre ist ein Lock, zum Deadlock wird das erst dann, wenn zyklische Wartebedingungen auftreten, oder bei der Eskalation von Locks (eine üble DB2 Tücke), das hat mit dem Commit Scope auf ACTGRP Ebene nix zu tun. Wenn derselbe Satz in zwei voneinander unabhängigen Transaktionen angefasst wird, dann stimmt die fachliche Logik nicht!!!

Transaktionen bewegen sich innerhalb einer Datenbank und nicht mehreren und die Tabellen einer Datenbank gehören immer in einem Journal journalisiert, wer das anders macht, darf sich über Folgeprobleme nicht beklagen (bin mir nicht mal sicher, ob diese Restriktion nicht mittlerweile gelockert ist).

Der Contextswitch tritt bei meiner Empfehlung nie auf, da man zwei Commitmaster hat und die immer in verschiedenen Aktivierungsgruppen laufen.

Hier gilt wie so oft: Viele Probleme lassen sich durch gutes und einfaches Design vermeiden, Programm technische Komplexität ist oft auf Designmängel zurückzuführen.

D*B

Seit wann wird STRCMTCTL automatisch durchgeführt ?
Bisher war es so, dass der Open mit Fehler abgewiesen wurde, wenn CMTCTL nicht VOR Programmaufruf gestartet wurde.

Ansonsten ist CMTCTL auf Aktivierungsgruppe wirklich nur sinnvoll, wenn diese auf unterschiedliche Tabellen zugreifen, da es sonst innerhalb des Jobs zu Deadlocks kommen kann (o.ä.).

Beispiel:
ACTGRP(Def1) ruft PGMX mit ACTGRP(*CALLER) auf
ACTGRP(Def2) ruft PGMX mit ACTGRP(*CALLER) auf

PGMX versucht nun ggf. Daten zu ändern oder zu sperren, die von der anderen ACTGRP gesperrt sind.

Also auch ACTGRP(*CALLER) kann Probleme verursachen, wenn das Programm aus verschiedenen ACTGRP's verwendet werden kann.

Das weitere Problem ist noch das Journal selber.
Bei CMTCTL(*JOB) können nur Dateien geöffnet werden, die in dem selben Journal aufgezeichnet werden.
Bei CMTCTL(*ACTGRP) kann je ACTGRP ein anderes Journal verwendet werden.

Wichtig in diesem Zusammenhang ist vor allem, wenn man per CONNECT zu einer Remote-DB verbindet.
Wenn ein Programm sowohl lokal als auch remote arbeitet, muss mittels CONNECT ständig hin und her geschaltet werden, was drastisch auf die Performance geht.

Trennt man aber die Aufrufe in 2 verschiedene ACTGRP's, kann die lokale in ACTGRP1 mit dem lokalen Journal arbeiten und die ACTGRP2 mit dem fernen Journal und der fernen DB arbeiten.
Der CALL zwischen ACTGRP's kostet keine messbare Zeit (ist wie EXSR zu vergleichen), und der CONNECT-Wechsel entfällt.