Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Verhalten bei gesperrten Speicherbereichen (TLS, ULS und GSSB)

Wenn mehrere UTM-Transaktionen konkurrierend auf GSSB-, TLS- oder ULS-Bereiche zugreifen wollen, übernimmt openUTM die Synchronisation dieser Zugriffe.

Jeder Zugriff (Lesen, Schreiben oder Löschen) auf einen TLS, ULS oder GSSB hat zur Folge, dass openUTM diesen Bereich für Zugriffe anderer Transaktionen sperrt, und zwar

  • bis zum nächsten Sicherungspunkt (PGWT CM, PEND RE, FI, SP oder FC) oder

  • bis zur nächsten Rücksetzoperation (PGWT RB, RSET, PEND RS oder PEND ER/FR) oder

  • bis zu einer Freigabe mit dem UNLK-Aufruf, falls aus dem Bereich nur gelesen wurde.

Eine Transaktion, die auf den gesperrten Bereich zugreifen möchte, wird von openUTM so lange in einen Wartezustand versetzt, bis

  • die Sperre aufgehoben wurde

  • oder die maximale Wartezeit abgelaufen ist.

  • oder die Transaktion, durch die der Bereich gesperrt ist, sich mit PEND KP oder PEND PA/PR mit TAC-Klassenwechsel oder Warten auf DGET-Nachricht oder mit PGWT KP/PR/CM in einen Wartezustand unbestimmter Länge versetzt.

Dabei bleibt der Prozess blockiert und kann während der Wartezeit keine anderen Aufgaben übernehmen.

Diese maximale Wartezeit wird festgelegt mit dem Wert time1 des Operanden RESWAIT der KDCDEF-Anweisung MAX (Standard: 60 Sekunden, siehe auch openUTM-Handbuch „Anwendungen generieren“). Wartet eine Transaktion länger als die mit RESWAIT (time1) festgelegte Zeit, so lehnt openUTM den Zugriffsversuch mit dem Returncode KCRCCC = 40Z und KCRCDC = K810 ab.

openUTM lehnt einen solchen Zugriffsversuch in folgenden Fällen sofort ab,

  • wenn der Bereich durch eine andere Transaktion gesperrt ist, die sich gerade mit PEND KP oder PEND PA/PR mit TAC-Klassenwechsel oder Warten auf DGET-Nachricht oder mit PGWT KP/PR in einen Wartezustand unbestimmter Länge versetzt hat (mit KCRCCC = 40Z und KCRCDC = K810), oder

  • wenn das Warten zu einem Deadlock führen würde, so weit GSSB-, TLS- und ULS-Bereiche betroffen sind (mit KCRCCC = 40Z und KCRCDC = K820).
    Unix-, Linux- und Windows-Systeme
    In UTM-Cluster-Anwendungen muss dazu die Deadlock-Erkennung explizit eingeschaltet werden (siehe auch KDCDEF-Anweisung CLUSTER Parameter DEADLOCK-PREVENTION im openUTM-Handbuch „Anwendungen generieren“).

Greift eine Transaktion auf einen GSSB, ULS oder TLS nur lesend zu, so ist zu empfehlen, diesen Bereich möglichst schnell wieder freizugeben - insbesondere vor Datenbank-Aufrufen, vor PEND KP oder PEND PA/PR mit TAC-Klassenwechsel oder Warten auf DGET-Nachricht oder vor PGWT KP/PR - um die Wartezeiten anderer Transaktionen zu verkürzen.

Beim Zugriff auf LSSBs können solche Sperren nicht auftreten, da auf LSSBs nicht Vorgangs-übergreifend zugegriffen werden kann.