|
Standardwert:
n : 4 / m : 1 | |
n | Maximale Anzahl der gleichzeitig offenen Transaktionen, zugleich maximale Anzahl der Anwendertasks (einschließlich openUTM-Tasks), die gleichzeitig mit dem DBH verbunden sein können. n = 1..225 Für UDS-D |
m | maximale Anzahl sekundärer Teiltransaktionen, die der DBH gleichzeitig bearbeiten kann. m = 1..n und m <= n Der Wert für sekundäre Teiltransaktionen wirkt nur, wenn der UDS-D-Betrieb gestartet ist. |
PP TRANSACTION bestimmt
die Anzahl der Transaktionskanäle (Mainrefs) im DBH und damit die maximale Anzahl von Transaktionen, die im DBH gleichzeitig abgewickelt werden können,
die Anzahl der Task-Verwaltungs-Einträge des DBH und damit die maximale Anzahl von Anwendertasks, die dem DBH gleichzeitig bekannt sein dürfen,
bei UDS-D die maximale Anzahl der sekundären Teiltransaktionen, die dieser DBH für entfernte Anwenderprogramme gleichzeitig bearbeiten kann.
Eine Teilnehmer-Anwendertask ist dem DBH bekannt
ab dem Start eines UDS/SQL-Programms (bei COBOL-DML und SQL) bzw. vom ersten READYC-Aufruf (bei CALL-DML)
bis zum Ende des UDS/SQL-Programms
Im UDS/SQL-openUTM-Betrieb ist dem DBH jede openUTM-Task
vom Start bis zum Ende der Tasks bekannt.
Beim linked-in DBH ist der Wert des Ladeparameters PP TRANSACTION auf 1 fest eingestellt.
Die DBH-Ladeparameter PP DISDB, PP MAXDB und PP TRANSACTION wirken sich auf die Größe des Communication Pools und des Distribution Pools aus. Es ist nicht sinnvoll, bei allen diesen drei DBH-Ladeparametern den Maximalwert zu wählen, da dadurch die Memory Pools sehr groß werden und es abhängig von der Adressraumsituation unterhalb 16 Mbyte zu einem Speicherengpass kommen kann.
Es empfiehlt sich, den Wert für die maximale Anzahl sekundärer Teiltransaktionen geringfügig höher zu wählen als die voraussichtlich benötigte Anzahl sekundärer Teiltransaktionen. Wird nämlich zum Beispiel die primäre Teiltransaktion asynchron zurückgesetzt (z.B. wegen Deadlocks oder durch den Administrator), so werden die Konfigurationen der sekundären Teiltransaktionen darüber nicht sofort informiert, sondern erst im Rahmen der Transaktionsüberwachung (siehe Abschnitt „Zeitgesteuertes Überwachen von Verbindungen und Transaktionen“). Die Ressourcen der sekundären Teiltransaktionen bleiben in einem solchen Fall noch über den Zeitpunkt des Rücksetzens der primären Teiltransaktion hinaus belegt, sodass sie nach dem Rücksetzen der primären Teiltransaktion bis zum Anlaufen der Transaktionsüberwachung nicht von neuen sekundären Teiltransaktionen verwendet werden können. Kann eine sekundäre Teiltransaktion wegen eines Ressourcenengpasses nicht eröffnet werden, so erhält das Anwenderprogramm den Statuscode 122.