kc_tpool_str - LTERM-Pools der Anwendung

Für den Objekttyp KC_TPOOL ist die Datenstruktur kc_tpool_str definiert. In kc_tpool_str liefert UTM bei KC_GET_OBJECT die folgenden Informationen über einen LTERM-Pool zurück:

• Anzahl der LTERM-Partner, die zur Zeit für den LTERM-Pool zugelassen sind.

• Eigenschaften der LTERM-Partner des LTERM-Pools.

• Typ der Clients, die sich über diesen LTERM-Pool an die Anwendung anschließen können.

• Statistikdaten über die Auslastung des LTERM-Pools.

mod1	Datenstruktur kc_tpool_str
-	char lterm[8];
-	char pronam[8];
-	char ptype[8];
-	char bcamappl[8];
-	char connect_mode;
-	char max_number[10];
-	char kset[8];
-	char locale_lang_id[2]; (nur auf BS2000-Systemen)
-	char locale_terr_id[2]; (nur auf BS2000-Systemen)
-	char locale_ccsname[8]; (nur auf BS2000-Systemen)
-	char lock_code[4];
x(GP)2	char state;
x(GP)2	char state_number[10];
-	char format_attr; (nur auf BS2000-Systemen)
-	char format_name[7]; (nur auf BS2000-Systemen)
-	char qlev[5];
-	char termn[2];
-	char annoamsg; (nur auf BS2000-Systemen)
-	char netprio; (nur auf BS2000-Systemen)
-	char protocol; (nur auf BS2000-Systemen)
-	char actcon[10];
-	char maxcon[10];
-	char map;
x(GP)	char idletime[5];
-	char encryption_level;
-	char user_kset[8];
-	char usp_hdr;
-	char kerberos_dialog; (nur auf BS2000-Systemen)
-	char pronam_long[64];
-	char resolve_names;

1	Feldinhalt mit KC_MODIFY_OBJECT modifizierbar; siehe Abschnitt "obj_type=KC_TPOOL".
2	Bei KC_MODIFY_OBJECT müssen beide Felder zusammen angegeben werden.

Die Felder der Datenstruktur haben die folgende Bedeutung:

lterm
	enthält das Präfix für die Namen der LTERM-Partner des LTERM-Pools. Die Namen der LTERM-Partner setzen sich zusammen aus diesem Präfix und einer Laufnummer. Die Laufnummer geht von 1 bis zu dem Wert, der in max_number zurückgeliefert wird. Beispiel: Ist max_number='1000' und lterm='LTRM', dann heißen die LTERM-Partner des LTERM-Pools LTRM0001, LTRM0002, ..., LTRM1000.
pronam
	gibt an, auf welchem Rechner sich die Clients befinden müssen, um sich über diesen LTERM-Pool an die Anwendung anschließen zu können. Wenn für den LTERM-Pool ein Rechnername mit mehr als 8 Zeichen generiert wurde, dann kann der vollständige, bis zu 64 Zeichen lange Name dem Feld pronam_long entnommen werden. Das Feld pronam enthält in diesem Fall die ersten 8 Zeichen dieses Namens. UTM liefert entweder den symbolischen Namen zurück, unter dem der Rechner dem lokalen Transportsystem bekannt ist, oder bei einem offenen LTERM-Pool den Wert '*ANY'. '*ANY' bedeutet: Über den LTERM-Pool kann sich jeder Client an die Anwendung anmelden, der die folgenden Bedingungen erfüllt: Sein Terminaltyp stimmt mit der Angabe in ptype überein. Er wurde nicht explizit in die Konfiguration eingetragen (mit der KDCDEF-Anweisung PTERM oder dynamisch mit Objekttyp KC_PTERM). Für den Rechner, auf dem der Client residiert, und seinen Terminaltyp (ptype) existiert kein anderer LTERM-Pool.
ptype
	Typ der Clients, die sich über diesen LTERM-Pool an die Anwendung anschließen dürfen. Die Bedeutung der Werte, die UTM in ptype zurückliefert, entnehmen Sie bitte den Tabellen für BS2000-Systeme und für Unix-, Linux- und "Windows-Systeme  im Abschnitt "kc_pterm_str - Clients und Drucker". Nur auf BS2000-Systemen: Ist ptype='*ANY', dann handelt es sich um einen offenen LTERM-Pool. An den LTERM-Pool können sich alle Clients anschließen, die sich auf bzw. an dem Rechner pronam befinden und für die Folgendes gilt: Der Client wurde nicht explizit in die Konfiguration eingetragen. Für den Rechner in pronam existiert kein LTERM-Pool, für den in ptype der Typ des Client gesetzt ist.
bcamappl
	Name der lokalen UTM-Anwendung (BCAMAPPL-Name), über den die Verbindung zwischen Client und UTM-Anwendung aufgebaut wird. Diesen Namen muss der Client angeben, wenn er eine Verbindung zur lokalen Anwendung aufbauen will.
connect_mode
	legt fest, ob sich ein Client mehrfach unter demselben Namen über den LTERM-Pool an die UTM-Anwendung anschließen kann.
	'S'	Jeder Client kann sich nur einmal unter demselben Namen an den LTERM-Pool anschließen.
	'M'	Ein UPIC-Client (ptype='UPIC-R' oder 'UPIC-L') bzw. eine TS-Anwendung ( ='APPLI' oder 'SOCKET'), der/die mehrfach auf demselben Rechner abläuft, kann sich mehrfach unter demselben Namen über den LTERM-Pool an die UTM-Anwendung anschließen. Es muss nicht für jede Verbindung ein neuer Name erzeugt werden. Der UPIC-Client bzw. die TS-Anwendung kann sich maximal so oft an den LTERM-Pool anschließen wie LTERM-Partner für den LTERM-Pool zugelassen sind. Der Name des jeweiligen Pool-LTERM-Partners wird in diesem Fall beim Verbindungsaufbau mit dem Namen des Client/der TS-Anwendung gleichgesetzt, d.h. die Anwendung identifiziert den Partner über das Tripel (Name des LTERM-Partners, pronam und bcamappl). Der UPIC-Client bzw. die TS-Anwendung ist nicht unter seinem lokalen Namen oder seinem Anwendungsnamen in der UTM-Anwendung bekannt.
max_number
	gibt an, wieviele Clients sich maximal gleichzeitig über diesen LTERM-Pool anschließen dürfen. D.h. max_number gibt an, wieviele LTERM-Partner in diesem LTERM-Pool zusammengefasst sind.
kset	enthält den Namen des Keysets, das dem LTERM-Pool zugeordnet ist. Das Keyset legt fest, welche Transaktionscodes die Clients aufrufen dürfen, die sich über diesen LTERM-Pool an die Anwendung anschließen. Die Clients dürfen einen Transaktionscode nur starten, wenn das Keyset einen Keycode enthält, der im Zahlenwert mit dem Lockcode des Transaktionscodes übereinstimmt, oder der Transaktionscode nicht zugriffsgesichert ist, d.h. keinen Lockcode besitzt. Ist dem LTERM-Pool kein Keyset zugeordnet, dann ist kset mit Leerzeichen belegt. Bei ptype='UPIC-...', 'APPLI' oder 'SOCKET' gilt Folgendes: kset legt die maximalen Zugriffsrechte eines Clients fest, der sich über diesen LTERM-Pool anschließt. kset wird immer wirksam, wenn der Client beim Session-/Conversationaufbau eine echte Benutzkennung an UTM übergibt. Die Zugriffsrechte ergeben sich dann aus der Menge der Keycodes, die sowohl in dem Keyset der Benutzerkennung als auch in kset enthalten sind. Übergibt der Client für die Session/Conversation keine echte Benutzerkennung an openUTM, dann ergeben sich seine Zugriffsrechte aus der Schnittmenge der Keycodes in kset und user_kset (minimale Zugriffsrechte).
locale_lang_id, locale_terr_id, locale_ccsname (nur auf BS2000-Systemen)
	enthalten die drei Komponenten des Locale, das dem LTERM-Pool zugeordnet ist. Das Locale definiert die Sprachumgebung der Clients, die sich über diesen LTERM-Pool an die Anwendung anschließen (siehe auch openUTM-Handbuch „Anwendungen generieren“). locale_lang_id enthält das bis zu 2 Zeichen lange Sprachkennzeichen. locale_terr_id  enthält ein bis zu 2 Zeichen langes Territorialkennzeichen. locale_ccsname  (coded character set name) enthält den bis zu 8 Zeichen langen Namen eines erweiterten Zeichensatzes (CCS-Name; siehe auch Benutzerhandbuch zu XHCS).
lock_code
	enthält den Lockcode, der den LTERM-Partnern des LTERM-Pools zugeordnet ist (Zugriffsschutz). Nur Benutzer/Clients, die den entsprechenden Keycode besitzen, dürfen sich über diesen LTERM-Pool anschließen.  lock_code kann eine Zahl zwischen '0' und '4000' enthalten. '0' bedeutet, dass der LTERM-Pool nicht durch einen Lockcode geschützt ist.
state, state_number
	Bei der KDCDEF-Generierung des LTERM-Pools wird die Anzahl der LTERM-Partner festgelegt, die in diesem LTERM-Pool zusammengefasst sind (siehe max_number). Die Anzahl der LTERM-Partner, über die sich Clients an die Anwendung anschließen können, kann jedoch im Betrieb durch die Administration auf einen kleineren Wert gesetzt werden. Der Rest der LTERM-Partner wird dadurch gesperrt. In den Feldern state und state_number gibt UTM an, wieviele LTERM-Partner des LTERM-Pools zur Zeit zugelassen, d.h. nicht gesperrt sind. Die Anzahl der zugelassenen LTERM-Partner bestimmt, wieviele Clients sich gleichzeitig über diesen LTERM-Pool an die Anwendung binden können. Enthält state den Wert 'Y', wird der Pool für die Anzahl an Kommunikationspartnern zugelassen, die in state_number angegeben ist (ON). Enthält state den Wert 'N', wird der Pool für die Anzahl an Kommunikationspartnern gesperrt, die in state_number angegeben ist (OFF). Sind alle LTERM-Partner des LTERM-Pools gesperrt, dann enthält state den Wert 'Y' und state_number den Wert '0'.
format_attr, format_name (nur auf BS2000-Systemen)
	definieren das Startformat für Benutzer an Terminals, die sich über den LTERM-Pool anschließen. Nach dem Aufbau der Verbindung zwischen Terminal und Anwendung wird das in format_attr und format_name beschriebene Format am Terminal ausgegeben, sofern kein Terminal-spezifischer Wiederanlauf durchgeführt wird. format_attr  enthält das Formatkennzeichen:
	'A'	(Formatattribut ATTR) Das Startformat ist ein Format mit Benutzerattributen. Die Eigenschaften der Formatfelder können vom KDCS-Teilprogramm verändert werden. Der Formatname an der Programmschnittstelle KDCS ist +formatname.
	'N'	(Formatattribut NOATTR) Das Startformat ist ein Format ohne Benutzerattribute. Weder Feld- noch Formateigenschaften können von KDCS-Teilprogrammen verändert werden. Der Formatname an der Programmschnittstelle KDCS ist *formatname.
	'E'	(Formatattribut EXTEND) Das Startformat ist ein Format mit erweiterten Benutzerattributen. Es können sowohl die Eigenschaften der Formatfelder als auch globale Formateigenschaften von KDCS-Teilprogrammen verändert werden. Der Formatname an der Programmschnittstelle KDCS ist #formatname.
	format_name  enthält den Namen des Startformats. Der Name kann bis zu 7 Zeichen lang sein und enthält nur alphanumerische Zeichen.
qlev (queue level)
	gibt an, wieviele Asynchron-Nachrichten UTM maximal gleichzeitig in der Message Queue eines LTERM-Partners des Pools zur Bearbeitung zwischenspeichert. Wird der Schwellwert für einen LTERM-Partner des LTERM-Pools überschritten, dann weist UTM weitere Asynchron-Aufträge an diesen LTERM-Partner ab. Der Schwellwert wird bei der KDCDEF-Generierung festgelegt.
termn (terminal mnemonic)
	enthält das Kennzeichen für die Art der Clients, die sich über diesen LTERM-Pool anschließen können. Das Kennzeichen stellt UTM KDCS-Teilprogrammen beim Ablauf im Feld KCTERMN des KB-Kopfes zur Verfügung, die über den LTERM-Pool gestartet werden. Das Kennzeichen ist maximal 2 Zeichen lang. Die Standardwerte für termn können Sie der Tabelle bei ptype im Abschnitt "kc_pterm_str - Clients und Drucker" ("BS2000-Systeme, Unix-, Linux-" und "Windows-Systeme") entnehmen.
annoamsg (announce asynchronous message, nur auf BS2000-Systemen))
	gibt an, ob UTM Asynchron-Nachrichten vor der Ausgabe am Terminal durch eine Meldung in der Systemzeile ankündigt.
	'Y'	UTM kündigt jede Asynchron-Nachricht an das Terminal mit der Meldung K012 in der Systemzeile an. Der Benutzer muss die Asynchron-Nachricht dann explizit mit dem Kommando KDCOUT anfordern.
	'N'	Asynchron-Nachrichten an das Terminal werden sofort, ohne Ankündigung gesendet. Bei annoamsg='N' ist der Verbindungsaufbau zu diesem LTERM-Pool über eine Multiplexverbindung erst ab OMNIS V7.0 möglich.
netprio (nur auf BS2000-Systemen)
	gibt die Transportpriorität an, die auf Transportverbindungen zwischen der Anwendung und den Clients benutzt wird, die sich über diesen LTERM-Pool anschließen.
	'M'	Transportpriorität „Medium“
	'L'	Transportpriorität „Low“
protocol (nur auf BS2000-Systemen)
	gibt an, ob auf Verbindungen zwischen der UTM-Anwendung und einem Client, der sich über diesen LTERM-Pool anschließt, mit dem Benutzerdienstprotokoll NEABT gearbeitet wird.
	'N'	Zwischen der UTM-Anwendung und dem Client wird ohne Benutzerdienstprotokoll gearbeitet. Für UPIC-Clients (ptype='UPIC-R') und TS-Anwendungen (ptype='APPLI' oder 'SOCKET') wird immer protocol='N' ausgegeben. Zu einem LTERM-Pool mit protocol='N' können keine Verbindungen über einen Multiplexanschluss aufgebaut werden.
	'S'	(STATION) Zwischen der UTM-Anwendung und dem Client wird mit dem Benutzerdienstprotokoll (NEABT) gearbeitet. UTM verwendet das Benutzerdienstprotokoll NEABT bei LTERM-Pools mit ptype='*ANY' z.B. zur Bestimmung des Typs (ptype) eines Clients. In diesem Fall wird immer mit NEABT gearbeitet.
actcon
	gibt an, wieviele Clients zur Zeit über diesen LTERM-Pool mit der Anwendung verbunden sind.
maxcon
	enthält die maximale Anzahl der Clients, die im aktuellen Anwendungslauf gleichzeitig über diesen LTERM-Pool mit der Anwendung verbunden waren. Der Zähler wird bei jedem Start der Anwendung auf 0 zurückgesetzt.
map
	gibt an, ob UTM für Benutzer-Nachrichten, die zwischen den Partner-Anwendungen ausgetauscht werden, eine Code-Konvertierung (ASCII <-> EBCDIC) durchführt. Benutzer-Nachrichten werden an der KDCS-Schnittstelle bei den Aufrufen zur Nachrichtenbehandlung (MPUT/FPUT/DPUT) im Nachrichtenbereich übergeben.
	'U'	(USER) UTM konvertiert die Benutzer-Nachrichten nicht, d.h. die Nachrichten werden unverändert zwischen den Partner-Anwendungen übertragen.
	'1', '2', '3', '4' (SYS1 | SYS2 | SYS3 | SYS4)
		ist nur für folgende TS-Anwendungen erlaubt: BS2000-Systeme: ptype='SOCKET' Unix-, Linux- oder Windows-Systeme: ptype='APPLI' oder 'SOCKET' UTM konvertiert die Benutzernachrichten gemäß den für die Code-Konvertierung bereitgestellten Konvertierungstabellen, siehe Abschnitt „Code-Konvertierung“ im openUTM-Handbuch „Anwendungen generieren“, d.h.: Vor dem Senden wird auf Unix-, Linux- und Windows-Systemen von ASCII nach EBCDIC und auf BS2000-Systemen von EBCDIC nach ASCII konvertiert. Nach dem Empfangen wird auf Unix-, Linux- und Windows-Systemen von EBCDIC nach ASCII und auf BS2000-Systemen von ASCII nach EBCDIC konvertiert. Dabei geht UTM davon aus, dass die Nachricht nur abdruckbare Zeichen enthält. Weitere Informationen zur Code-Konvertierung finden Sie im openUTM-Handbuch „Anwendungen programmieren mit KDCS“, Abschnitt "Code-Konvertierung".
idletime
	Zeit in Sekunden, die UTM nach dem Ende einer Transaktion oder nach dem Anmelden (KDCSIGN) maximal auf eine Eingabe vom Client wartet. Bei Zeitüberschreitung wird die Verbindung zum Client abgebaut. Ist der Client ein Terminal, dann wird vor dem Verbindungsabbau die Meldung K021 ausgegeben. Der Wert 0 bedeutet Warten ohne Zeitbegrenzung.
encryption_level
	nur relevant für UPIC-Clients und auf BS2000-Systemen für einige Terminalemulationen. encryption_level gibt an, ob die UTM-Anwendung auf der Verbindung zum Client, der sich über den LTERM-Pool an die Anwendung anschließen will, die Verschlüsselung der Nachrichten standardmäßig anfordert oder nicht, welche Verschlüsselungsebene dabei gefordert wird, oder ob die Clients „trusted“ Clients sind. Folgende Werte sind möglich:
	'N'	(NONE) UTM fordert keine Verschlüsselung der Nachrichten an. Services, für die die Verschlüsselung generiert wurde (siehe kc_tac_str.encryption_level im Abschnitt "kc_tac_str - Transaktionscodes lokaler Services"), können von einem Client, der sich über diesen Pool anschließt, nur gestartet werden, wenn der Client beim Verbindungsaufbau die Verschlüsselung auswählt. Passworte werden verschlüsselt übertragen, sofern beide Partner Verschlüsselung unterstützen.
	'3'	(LEVEL 3) UTM fordert von jedem Client die Verschlüsselung der Nachrichten mit der Verschlüsselungsebene 3 an, d.h. die Nachrichten werden mit dem AES-CBC Algorithmus verschlüsselt und zum Austausch des AES-Schlüssels wird ein RSA-Schlüssel mit einer Schlüssellänge von 1024 bit verwendet. Der Verbindungsaufbau zu dem Client wird von UTM abgelehnt, wenn der Client nicht mindestens diese Verschlüsselungsebene unterstützt.
	'4'	(LEVEL 4) UTM fordert von jedem Client die Verschlüsselung der Nachrichten mit der Verschlüsselungsebene 4 an, d.h. die Nachrichten werden mit dem AES-CBC Algorithmus verschlüsselt und zum Austausch des AES-Schlüssels wird ein RSA-Schlüssel mit einer Schlüssellänge von 2048 bit verwendet. Der Verbindungsaufbau zu dem Client wird von UTM abgelehnt, wenn der Client nicht mindestens diese Verschlüsselungsebene unterstützt.
	'5'	(LEVEL 5) nur auf Unix-, Linux- und Windows-Systemen Schlüssellänge wie bei LEVEL 4. Zur Vereinbarung des Session-Keys wird das auf Elliptic Curves basierende Diffie-Hellman Verfahren verwendet und Ein-/Ausgabe-Nachrichten werden mit dem AES-GCM Algorithmus verschlüsselt. Der Verbindungsaufbau zu dem Client wird von UTM abgelehnt, wenn der Client nicht mindestens diese Verschlüsselungsebene unterstützt
	'T'	(TRUSTED) Die Clients sind „trusted Clients“. Nachrichten und Passworte zwischen einem Client und einer Anwendung werden nicht verschlüsselt. Ein „trusted Client“ kann auch Vorgänge starten, deren Vorgangs-TACs Verschlüsselung erfordern (generiert mit kc_tac_str.encryption_level = '2' oder '5'; siehe Abschnitt "kc_tac_str - Transaktionscodes lokaler Services"). Verbindungen, die über einen Transportsystemendpunkt (BCAMAPPL) aufgebaut werden, der mit T-PROT=(..., SECURE) generiert ist, werden von UTM immer als trusted eingestuft.
user_kset
	nur relevant für ptype='UPIC-...', 'APPLI' oder 'SOCKET'. user_kset enthält den Namen des Keyset, das die minimalen Zugriffsrechte des Client in der lokalen Anwendung festlegt. Das in user_kset angegebene Keyset wird dann wirksam, wenn der Client unter der Verbindungs-Benutzerkennung angemeldet ist (siehe auch kset). Es gelten immer die Zugriffsrechte in kset.
usp_hdr
	zeigt an, für welche Ausgabe-Nachrichten UTM auf dieser Verbindung einen UTM-Socket-Protokoll-Header aufbaut. Mögliche Werte sind:
	'A'	(ALL) Bei allen Ausgabe-Nachrichten (Dialog, Asynchron, K-Meldungen) erzeugt UTM einen UTM-Socket-Protokoll-Header und stellt diesen der Nachricht voran.
	'M'	(MSG) Nur bei Ausgabe von K-Meldungen erzeugt UTM einen UTM-Socket-Protokoll-Header und stellt diesen der Nachricht voran.
	'N'	(NO) UTM erzeugt für keine Ausgabe-Nachricht einen UTM-Socket-Protokoll-Header.
	Die Werte 'A' und 'M' können nur bei LTERM-Pools vorkommen, die für die Kommunikation über Socket-Verbindungen konfiguriert sind (ptype='SOCKET').
kerberos_dialog (nur auf BS2000-Systemen)
	'Y'	Beim Verbindungsaufbau wird für Clients, die Kerberos unterstützen und die sich direkt (nicht über OMNIS) über diesen Terminal-Pool an die Anwendung anschließen, ein Kerberos-Dialog durchgeführt.
	'N'	Es wird kein Kerberos-Dialog durchgeführt.
	Detaillierte Information dazu entnehmen Sie dem openUTM-Handbuch „Anwendungen generieren“.
pronam_long
	gibt an, auf welchem Rechner sich die Clients befinden müssen, um sich über diesen LTERM-Pool an die Anwendung anschließen zu können. UTM liefert entweder den symbolischen Namen zurück, unter dem der Rechner dem lokalen Transportsystem bekannt ist, oder bei einem offenen LTERM-Pool den Wert '*ANY'. '*ANY' bedeutet, dass sich jeder Client über den LTERM-Pool an die Anwendung anmelden kann, der die folgenden Bedingungen erfüllt: Sein Typ stimmt mit der Angabe in ptype überein. Er wurde nicht explizit in die Konfiguration eingetragen (mit der KDCDEF-Anweisung PTERM oder dynamisch mit dem Objekttyp KC_PTERM). Für den Rechner, auf dem der Client residiert, und seinen Terminaltyp (ptype) existiert kein anderer LTERM-Pool.
resolve_names
	gibt an, ob nach einem Verbindungsaufbau eine Namensauflösung per DNS stattfinden soll oder nicht. Siehe KDCDEF-Anweisung SUBNET.