Plätze in den Objekttabellen der KDCFILE reservieren

Die Konfigurationsdaten einer UTM-Anwendung werden in den Objekttabellen der KDCFILE abgelegt, die bei der KDCDEF-Generierung der Anwendung erzeugt wird. Diese Objekttabellen sind nur in dem Maße dynamisch erweiterbar, wie freie Tabellenplätze vorhanden sind. Deshalb müssen Sie für Objekte, die Sie erst im laufenden Betrieb in die Konfiguration der Anwendung aufnehmen wollen, schon bei der Generierung mit der KDCDEF-Anweisung RESERVE freie Tabellenplätze reservieren. Sie können für folgende UTM-Objekte Tabellenplätze reservieren:

UTM-Objekt	Objekttyp
Benutzerkennungen	USER
TS-Anwendungen, UPIC-Clients, Terminals und Drucker	PTERM
LTERM-Partner	LTERM
Teilprogramme und VORGANG-Exits	PROGRAM
Transaktionscodes und TAC-Queues	TAC
Transportverbindungen zu LU6.1-Partner-Anwendungen	CON
LU6.1-Sessionnamen	LSES
Keysets	KSET
lokale Servicenamen für ferne Anwendungen	LTAC

Mit der RESERVE-Anweisung im Abschnitt "RESERVE - Tabellenplätze für UTM-Objekte reservieren" legen Sie fest, wieviele leere Tabellenplätze für einen Objekttyp angelegt werden sollen. Dies entspricht der Anzahl der Einzelobjekte des jeweiligen Objekttyps, die dynamisch konfiguriert werden können.

Die Anzahl der Tabellenplätze, die pro Objekttyp angelegt werden können, ist begrenzt durch die Anzahl der generierbaren Namen. Sehen Sie dazu die Tabelle im Abschnitt "Anzahl der Namen".

Die leeren Tabellenplätze in den Objekttabellen werden Objekttyp-spezifisch reserviert, d.h. ein Tabellenplatz, den Sie beispielsweise für einen LTERM-Partner reserviert haben, kann nicht von einem Transaktionscode belegt werden etc.

Während des Anwendungslaufs können Sie genau so viele Objekte eines Typs dynamisch konfigurieren wie leere Tabellenplätze mit KDCDEF reserviert wurden. Durch das Löschen eines anderen Objekts vom gleichen Typ wird nicht unmittelbar ein Tabellenplatz für ein neues Objekt frei.

Eine Ausnahme bilden hier die Benutzerkennungen. Benutzerkennungen können Sie auf zwei Arten löschen, „verzögert“ oder „sofort“. Wird eine Benutzerkennung „verzögert“ gelöscht, dann bleibt der Tabellenplatz belegt (wie bei den anderen Objekttypen). Wird die Benutzerkennung durch „sofortiges“ Löschen aus der Konfiguration herausgenommen, dann wird ihr Tabellenplatz freigegeben. Er kann sofort wieder für eine neue Benutzerkennung verwendet werden.

Bei der Reservierung der Tabellenplätze mit RESERVE ist Folgendes zu beachten: Für jeden UPIC-Client und für jede TS-Anwendung, die Sie dynamisch in die Konfiguration eintragen, erzeugt openUTM intern eine Benutzerkennung. In UTM-Anwendungen, die mit Benutzerkennungen generiert sind (die KDCDEF-Generierung enthält mindestens eine USER-Anweisung), muss deshalb für jeden dynamisch einzutragenden Client vom Typ APPLI, SOCKET, UPIC-R oder UPIC-L zusätzlich ein Tabellenplatz für Benutzerkennungen reserviert werden. Diese Tabellenplätze werden beim Löschen der Clients nicht freigegeben (entspricht dem „verzögerten“ Löschen). In Anwendungen ohne Benutzerkennungen werden diese Tabellenplätze von openUTM intern reserviert.

Beispiele

RESERVE OBJECT=LTERM, NUMBER=100

Das bedeutet, es können bis zu 100 LTERM-Partner dynamisch in die Konfiguration eingetragen werden.

RESERVE OBJECT=LTERM, PERCENT=200

In diesem Fall wurde die Anzahl der reservierten Tabellenplätze relativ zur Anzahl der statisch generierten LTERM-Partner festgelegt. Es können dynamisch doppelt (200%) so viele LTERM-Partner erzeugt werden, wie bei der KDCDEF-Generierung statisch eingetragen wurden. Wurden bei der KDCDEF-Generierung 50 LTERM-Partner eingetragen, dann können nochmals 100 LTERM-Partner dynamisch eingetragen werden.

RESERVE OBJECT=ALL, NUMBER=100

Das bedeutet, es können für jeden Objekttyp jeweils 100 Objekte dynamisch eingetragen werden, also 100 Benutzerkennungen, 100 LTERM-Partner usw.

RESERVE OBJECT=USER, NUMBER=0

Diese Anweisung bewirkt, dass die Anzahl der Objekte des angegebenen Typs (hier USER) dynamisch bis auf den maximal generierbaren Wert erhöht werden kann.

Wegen des hohen Platzbedarfs der Tabellen ist es sinnvoll, einen Wert != 0 für NUMBER anzugeben, um den Speicherverbrauch der Anwendung zu reduzieren.