KDCS-Aufrufe in einem Teilprogramm haben Änderungen in den Verwaltungsdaten zur Folge. openUTM sammelt Informationen über alle Änderungen, die innerhalb einer Transaktion anfallen - also vom ersten INIT-Aufruf bis zum Transaktionsende - in einem Prozessspezifischen Speicherbereich. Auf BS2000-Systemen ist dies ein Puffer im Klasse-5-Speicher.
Bei Transaktionsende bildet openUTM bei einer UTM-S-Anwendung aus der Information in diesem Puffer einen Datensatz mit Wiederanlauf-Information und schreibt ihn in den Wiederanlaufbereich der KDCFILE. Der Datensatz beschreibt, welche Änderungen in den Verwaltungsdaten als Folge der Transaktion vorgenommen wurden. Bei einem Warmstart wird er von openUTM benutzt, um die Wirkung der Transaktion nachzuvollziehen. Die Größe des Wiederanlaufbereichs bestimmt, in welchen Zeitabständen Änderungen der Konfigurationsdaten in den Bereich Verwaltungsdaten der KDCFILE übernommen werden müssen.
In einer UTM-F-Anwendung werden nur in solchen Transaktionen Datensätze für den Wiederanlauf geschrieben, in denen Passwörter geändert oder per dynamischer Konfigurierung Änderungen an den Verwaltungsdaten vorgenommen wurden.
Die Datensätze im Wiederanlaufbereich werden von openUTM zusammengefasst, d.h. auf einer UTM-Seite dieses Bereichs haben meist mehrere Datensätze Platz.
In der KDCDEF-Generierung legt man die Größe des Puffers und des Wiederanlaufbereichs fest mit:
|
number length | Größe des Wiederanlaufbereichs pro Prozess in der KDCFILE in UTM-Seiten Größe des Puffers pro Prozess im Hauptspeicher, Angabe in Byte |
Parameter length einstellen
Mit dem Parameter length reservieren Sie für jeden Prozess im Hauptspeicher einen Speicherbereich, der length Byte groß ist. openUTM verwendet diesen Speicherbereich, um Änderungen an den Verwaltungsdaten zwischenzeitlich zu sichern, solange eine Transaktion offen und damit rücksetzbar ist.
Für length muss der Platzbedarf von Transaktionen der Anwendung im Puffer an Hand von Standardwerten ermittelt werden:
Bei einem Grundbedarf von 40 Byte pro Transaktion berücksichtigen Sie zusätzlich:
Bis zu 50 Byte pro KDCS-Aufruf, für MCOM-Aufruf aber 80 Byte.
Bis zu 300 Bytes pro ADMI-Aufruf.
Bei verteilter Verarbeitung berücksichtigen Sie außerdem:
300 Byte pro LU6.1-Kommunikationspartner
200 Byte pro OSI TP-Partner
Bei asynchroner Administration per FPUT-Aufruf ist zu beachten, dass alle Aufrufe FPUT NT aus einem Teilprogramm an den gleichen Administrations-TAC vom UTM-Administrationsprogramm in einer Transaktion bearbeitet werden. Dabei haben die einzelnen Administrationskommandos folgenden Platzbedarf im Puffer, den Sie für length berücksichtigen müssen:
0 Byte pro Administrationskommando KDCHELP und KDCINF
für jedes andere Administrationskommando
300 Byte auf BS2000-Systemen
360 Byte auf Unix-, Linux- und Windows-Systemen
Auf 64 Bit Plattformen muss mit dem doppelten Speicherbedarf gerechnet werden.
Wird RECBUF=length zu klein generiert, d.h. reicht der Puffer für eine Transaktion nicht aus, so lehnt openUTM einen KDCS-Aufruf ab oder setzt die Transaktion zurück und beendet den Vorgang abnormal.
Parameter number einstellen
Mit dem Parameter number reservieren Sie für jeden Prozess einen Speicherbereich in der KDCFILE, der number UTM-Seiten groß ist. openUTM verwendet diesen Speicherbereich, um Änderungen an den Verwaltungsdaten abgeschlossener Transaktionen zwischenzeitlich zu sichern, bis die geänderten Verwaltungsdaten beim nächsten Periodic Write in die KDCFILE geschrieben werden. Auf einer UTM-Seite haben meist mehrere Datensätze Platz, da sie im Allgemeinen nur wenig umfangreicher sind als die entsprechende Information im Puffer.
KDCDEF sorgt dafür, dass ein zu klein definierter Wert number automatisch auf den kleinstmöglichen Wert erhöht wird.
Die Verwaltungsdaten in der KDCFILE, zusammen mit den für den Wiederanlauf geschriebenen Datensätzen, repräsentieren immer den letzten gültigen Zustand der Anwendung. Rechtzeitig bevor ein Wiederanlaufbereich während einer laufenden Anwendung vollgeschrieben wird, stößt openUTM automatisch einen Update der Verwaltungsdaten in der KDCFILE an (Periodic Write). Dabei werden alle Seiten mit Verwaltungsdaten, in denen Änderungen erfolgt sind, parallel zu laufenden Transaktionen in die KDCFILE geschrieben. Dadurch werden alle bisher geschriebenen Datensätze in den Wiederanlaufbereichen bedeutungslos.
number sollte mindestens so groß sein, dass der im Wiederanlaufbereich zur Verfügung stehende Bereich ein Vielfaches des mit dem Parameter length generierten Puffers beträgt.
In einer UTM-F-Anwendung werden weit weniger Verwaltungsdaten in die KDCFILE zurückgeschrieben, beispielsweise geänderte Benutzerpasswörter und Generierungsdaten, die per dynamischer Konfigurierung geändert wurden. Für UTM-F-Anwendungen kann der Wert number daher kleiner gewählt werden.