Mit der TPOOL-Anweisung definieren Sie einen LTERM-Pool und legen dessen Eigenschaften fest. Über einen LTERM-Pool können sich unterschiedliche Clients mit gleichen technischen Eigenschaften (Partner- und Prozessortyp) über LTERM-Partner an eine UTM-Anwendung anschließen. Drucker werden dabei nicht unterstützt. In der TPOOL-Anweisung wird nur der Typ (PTYPE=) und der Rechnername (PRONAM=) für den Client angegeben. Die Zuordnung LTERM-Partner zu Client erfolgt dynamisch beim Verbindungsaufbau durch den UTM-Systemcode, und zwar über den in der TPOOL-Anweisung definierten Namen des LTERM-Partners und den Namen des Clients. Die Zuordnung besteht nur für die Dauer einer Session, es besteht keine statische Zuordnung wie im Anweisungspaar LTERM / PTERM. Bei einem LTERM-Pool müssen die Clients nicht explizit in der Anwendung konfiguriert sein (keine Definition eines PTERM). Es können sich gleichzeitig soviele Clients anschließen, wie LTERM-Partner im LTERM-Pool generiert sind.
Bei Clients, die sich über einen LTERM-Pool anschließen (d.h. die nicht explizit generiert sind), kann der Verbindungsaufbau nur „von außen“ angestoßen werden, d.h. vom Client selbst. Der Verbindungsaufbau über UTM- Administrationskommandos ist also nicht möglich.
Auf BS2000-Systemen ist auch der Verbindungsaufbau über BCAM-Administrationskommandos oder durch vordefinierte BCAM-Verbindungen nicht möglich.
Sie können mit der TPOOL-Anweisung LTERM-Pools mit verschiedenen Freiheitsgraden für den Verbindungsaufbau definieren:
Mit PRONAM=processorname und PTYPE=partnertyp wird ein LTERM-Pool so generiert, dass nur Clients gleichen Typs, die sich auf dem angegebenen Rechner befinden, über diesen LTERM-Pool Verbindungen zu der UTM-Anwendung aufbauen.
Mit PRONAM=*ANY können sich alle Clients eines Typs an die UTM-Anwendung anschließen, unabhängig davon, auf welchem Rechner sie sich befinden.
Mit PTYPE=*ANY definieren Sie auf BS2000-Systemen einen LTERM-Pool ohne spezifischen Clienttyp.
Über einen solchen LTERM-Pool können Clients beliebigen Typs, die sich auf dem angegebenen Rechner befinden, Verbindungen zu der UTM-Anwendung aufbauen.Mit PRONAM=*ANY und PTYPE=*ANY können sich beliebige Clients auf beliebigen Rechnern an eine UTM-Anwendung unter einem BS2000-System anschließen (offener LTERM-Pool).
Sie können mehrere LTERM-Pools definieren, d.h. mehrere TPOOL-Anweisungen pro KDCDEF-Lauf angeben. Es ist jedoch Folgendes zu beachten:
BS2000-Systeme:
Für LTERM-Pools, für die mit PROTOCOL=STATION das Benutzerprotokoll NEABT vereinbart wurde, muss die Kombination PRONAM / PTYPE / BCAMAPPL eindeutig sein. Bei LTERM-Pools mit PROTOCOL=NO muss die Kombination PRONAM / BCAMAPPL eindeutig sein.
Der Client muss immer das Benutzerdienstprotokoll unterstützen, das in der TPOOL-Anweisung angegeben wurde. Für Clients mit PTYPE=APPLI, PTYPE=SOCKET oder PTYPE=UPIC-R wird stets PROTOCOL=NO generiert. Für LTERM-Pools, die mit PTYPE=*ANY generiert sind, muss immer PROTOCOL=STATION angegeben werden.
Beim Verbindungsaufbau übernimmt openUTM den Typ (PTYPE) des Clients, der mit PTYPE=*ANY generiert ist, aus dem Benutzerdienstprotokoll (Connection Letter). openUTM überprüft, ob der Typ unterstützt werden kann. Unterstützt openUTM den Typ nicht, dann wird der Verbindungswunsch abgelehnt.
Unix-, Linux- und Windows-Systeme:
Für LTERM-Pools muss die Kombination PRONAM/PTYPE/BCAMAPPL eindeutig sein.
Für LTERM-Pools muss die maximale Anzahl von Verbindungen berücksichtigt werden, die über einen Transportsystem-Zugriffspunkt zu einer Zeit aufgebaut werden können.
Die LTERM-Partner eines LTERM-Pools werden mit LTERM ...,RESTART=NO generiert. Beim Verbindungsaufbau werden daher alle asynchronen Nachrichten gelöscht, die in der Message Queue der LTERM-Partner des LTERM-Pools zwischengespeichert sind. In Anwendungen, die ohne Benutzerkennungen generiert sind, kann für Clients, die über einen LTERM-Pool mit der Anwendung verbunden sind, nach einem Verbindungsabbau und nachfolgendem Verbindungswiederaufbau kein Vorgangswiederanlauf durchgeführt werden.
Für einen LTERM-Pool können Sie Zugriffsrechte festlegen (Operand KSET), die die über den LTERM-Pool angeschlossenen Clients ausüben können. In Anwendungen mit Benutzerkennungen können Sie für LTERM-Pools, die zum Anschluss von UPIC-Clients oder TS-Anwendungen generiert werden, die mit KSET festgelegten Zugriffsrechte mit dem Operanden USER-KSET einschränken. Die Zugriffsrechte in KSET beziehen sich dann auf Clients, die bei der Anmeldung explizit eine Benutzerkennung angeben. Die eingeschränkten Zugriffsrechte in USER-KSET werden wirksam, wenn der Client bei der Anmeldung keine Benutzerkennung übergibt, d.h. die „Verbindungs-Benutzerkennung“ aktiv ist.
Auf BS2000-Systemen können Sie für jeden LTERM-Pool mit dem Operanden LOCALE eine clientspezifische Sprachumgebung definieren.
|
|
1 nur auf BS2000-Systemen
2 nur auf Unix-, Linux- und Windows-Systemen
3 nur auf BS2000-Systemen Pflichtoperand
ANNOAMSG= | (announce asynchronous message) Dieser Operand gilt nur für BS2000-Systeme. | ||||||
Y | Asynchrone Nachrichten sollen angekündigt werden. Der Benutzer muss die Nachricht mit dem Kommando KDCOUT anfordern. Standard: Y | ||||||
N | Asynchrone Nachrichten werden ohne Ankündigung gesendet. | ||||||
BCAMAPPL= | local_appliname Name der lokalen UTM-Anwendung, über den die Verbindung zwischen Client und UTM-Anwendung aufgebaut wird. local_appliname wird entweder mit MAX ...,APPLINAME= oder in der BCAMAPPL-Anweisung festgelegt, siehe hierzu auch die Beschreibung der BCAMAPPL-Anweisung im Abschnitt "BCAMAPPL - Weitere Anwendungsnamen definieren". Wird beim Operanden PTYPE= ein Wert ungleich APPLI, SOCKET oder UPIC-R angegeben, dann kann für local_appliname nur der mit MAX ...,APPLINAME=appliname definierte Name angegeben werden. Standard: appliname, der bei MAX ...,APPLINAME= angegeben wurde. BS2000-Systeme: Der Client muss i.A., wenn er eine Verbindung zu der UTM-Anwendung aufbauen will, local_appliname als Partnernamen angeben. Eine Ausnahme bilden LTERM-Pools, die mit PTYPE=SOCKET generiert sind. In diesem Fall müssen die Clients, die sich über den LTERM-Pool anschließen, die Portnummer kennen, an der die UTM-Anwendung „horcht“. Diese Portnummer wird in BCAMAPPL LISTENER-PORT= festgelegt. Unix-, Linux- und Windows-Systeme: | ||||||
CONNECT-MODE= | legt fest, ob ein Client sich mehrfach unter demselben Namen über den LTERM-Pool an die UTM-Anwendung anschließen kann. | ||||||
SINGLE | Jeder Client kann sich nur einmal unter demselben Namen an den LTERM-Pool anschließen. Standard: SINGLE | ||||||
MULTI | Nur zulässig für LTERM-Pools, über die sich UPIC-Partner oder TS-Anwendungen anschließen. Eine UPIC-Client- bzw. TS-Anwendung kann sich maximal number1-mal an den LTERM-Pool anschließen (siehe NUMBER=number1, Abschnitt "TPOOL - LTERM-Pools definieren"). Im Fall CONNECT-MODE=MULTI identifiziert die UTM-Anwendung den Kommunikationspartner bzw. die Verbindung zum Partner nicht (wie gewöhnlich) über den Partner-Namen, den der Partner beim Verbindungsaufbau angibt. Der Partner ist der UTM-Anwendung unter seinem Anwendungsnamen nicht bekannt. Die Identifikation erfolgt stattdessen über den Namen des Pool-LTERM-Partners (ltermname), über den er angeschlossen ist. Damit openUTM den Partner eindeutig identifizieren kann, darf das Tripel aus ltermname des LTERM-Pools, processorname und local_appliname in keiner PTERM-, CON- oder OSI-CON-Anweisung explizit generiert sein. Darüber hinaus darf der Name, den der Partner beim Verbindungsaufbauwunsch angibt, mit keinem LTERM-Namen des LTERM-Pools übereinstimmen. | ||||||
ENCRYPTION-LEVEL= | |||||||
Nur relevant für UPIC-Clients, die die Verschlüsselung unterstützen, und auf BS2000-Systemen zusätzlich für einige Terminalemulationen, die Verschlüsselung unterstützen. In ENCRYPTION-LEVEL legen Sie die minimale Verschlüsselungsebene für die Kommunikation mit Clients fest, die sich über diesen LTERM-Pool an die Anwendung anschließen. Standardwerte: TRUSTED ist der Standardwert für:
Andere Werte für diese Partner werden von KDCDEF ohne Meldung in TRUSTED geändert. NONE ist der Standardwert für
Für Partner mit PTYPE ungleich UPIC-R und im BS2000 ungleich T9763, werden die Werte 3, 4, 5 von openUTM ohne Meldung in NONE geändert. Folgende Angaben sind möglich: | |||||||
NONE | Die Verschlüsselung der Nachrichten, die zwischen Client und UTM-Anwendung ausgetauscht werden, wird von openUTM nicht erzwungen. Standard: NONE | ||||||
3 | 4 | 5 | Nachrichten, die zwischen dem Client und der UTM-Anwendung ausgetauscht werden, werden von openUTM standardmäßig verschlüsselt. Der Wert gibt die Verschlüsselungsebene an. Es können sich nur Clients über diesen LTERM-Pool anschließen, die mindestens diese Verschlüsselungsebene unterstützen. Unterstützt ein Client die angegebene Verschlüsselungsebene nicht, lehnt openUTM den Verbindungsaufbau zum Client ab. Die Werte haben folgende Bedeutung:
BS2000-Systeme: Falls die Anwendung mit OPTION GEN-RSA-KEYS=NO generiert ist, dann werden beim KDCDEF-Lauf keine RSA-Schlüssel erzeugt. Um die Verschlüsselungsfunktionen nutzen zu können, müssen Sie die benötigten Schlüssel per Administration erzeugen (KC_ENCRYPT oder WinAdmin bzw. WebAdmin) oder per KDCUPD aus einer alten KDCFILE übertragen. | ||||||
TRUSTED | Nachrichten zwischen Client und Anwendung werden nicht verschlüsselt. Ein Client, der sich über diesen LTERM-Pool an die Anwendung anschließt, kann aber trotzdem Vorgänge starten, deren Vorgangs-TACs Verschlüsselung erfordern (generiert mit TAC ENCRYPTION-LEVEL=2 | 5). D.h. jeder Client, der sich über diesen LTERM-Pool anschließt, wird als „trusted Client“ betrachtet. TRUSTED sollten Sie nur dann für einen LTERM-Pool generieren, wenn alle die Kommunikation mit den Clients über eine sichere Verbindung läuft. | ||||||
FORMAT= | Dieser Operand gilt nur für BS2000-Systeme. Standard: Kein Startformat. | ||||||
IDLETIME= | time legt die Zeit in Sekunden fest, die openUTM außerhalb einer Transaktion, d.h. nach dem Ende einer Transaktion oder nach dem Anmelden, maximal auf eine Eingabe vom Client wartet. Bei Zeitüberschreitung baut openUTM die Verbindung zum Client ab. Ist der Client ein Terminal, dann wird vor dem Verbindungsabbau die Meldung K021 ausgegeben. Diese Funktion dient dazu den Datenschutz zu verbessern: Vergisst ein Benutzer bei einer Unterbrechung oder der Beendigung seiner Arbeit am Terminal, sich abzumelden, dann wird die Verbindung zum Terminal bzw. zum Client nach Ablauf der Wartezeit automatisch abgebaut. Damit wird die Wahrscheinlichkeit für einen unberechtigten Zugang verringert. Standard: 0 (= Warten ohne Zeitbegrenzung). Für TPOOLs, an die sich HTTP-Clients anschließen können, beträgt der Standardwert 180 Sekunden. Geben Sie einen Wert an, der größer als 0 und kleiner als der Minimalwert ist, dann ersetzt KDCDEF den Wert durch den Minimalwert. | ||||||
| KERBEROS-DIALOG= | Dieser Operand gilt nur für BS2000-Systeme. | ||||||
| Y | Beim Verbindungsaufbau wird für Terminals, die Kerberos unterstützen und die sich direkt (nicht über OMNIS) über diesen Terminalpool an die Anwendung anschließen, ein Kerberos-Dialog durchgeführt. openUTM speichert die Kerberos-Information in der Länge ab, die sich aus dem Maximum der bei MAX PRINCIPAL-LTH und MAX CARDLTH generierten Längen ergibt. Wenn die Kerberos-Information länger ist, wird sie auf diese Länge verkürzt abgespeichert. Mit dem KDCS-Aufruf INFO (KCOM=CD) kann ein Teilprogrammlauf diese Information lesen. | ||||||
N | Es wird kein Kerberos-Dialog durchgeführt. Standard. | ||||||
KSET= | keysetname1 Name eines Keysets, das diesem LTERM-Pool zugeordnet wird. Das Keyset muss mit einer KSET-Anweisung definiert werden. Es legt die Zugriffsrechte der LTERM-Partner dieses LTERM-Pools für die Nutzung von Services der Anwendung und von entfernten Services (LTAC) fest, die in dieser Anwendung generiert wurden. Über einen LTERM-Partner dieses LTERM-Pools können mit Lockcode bzw. Access-List geschützte Services der Anwendung nur gestartet bzw. mit Lockcode bzw. Access-List geschützte entfernte Services nur adressiert werden, wenn Folgendes zutrifft: Sowohl im zugeordneten Keyset des LTERM-Partners als auch im KSET der UTM-Benutzerkennung, unter der die Anmeldung über diesen LTERM-Partner erfolgte, ist der zum Lockcode bzw. der Access-List passende Key- bzw. Zugangscode enthalten. Bei PTYPE=APPLI, SOCKET, UPIC-R, UPIC-L gilt bezüglich des Keysets der Benutzerkennung zusätzlich Folgendes:
| ||||||
LOCALE= | (lang_id,terr_id,ccsname) Dieser Operand gilt nur für BS2000-Systeme. | ||||||
lang_id | Max. 2 Zeichen langes Sprachkennzeichen für die Clients des LTERM-Pools. Das Sprachkennzeichen ist frei wählbar. Das Sprachkennzeichen kann von den Teilprogrammen der Anwendung abgefragt werden, so dass es Nachrichten an die Terminals in der Landessprache des Clients übertragen kann. | ||||||
terr_id | Max. 2 Zeichen langes Territorialkennzeichen der Clients des LTERM-Pools. Das Territorialkennzeichen ist frei wählbar. Das Territorialkennzeichen kann von den Teilprogrammen der Anwendung abgefragt werden. So können in Nachrichten die territorialen Besonderheiten in der Landessprache des Clients berücksichtigt werden. | ||||||
ccsname | (coded character set name)
Standard: Wird TPOOL ...,LOCALE nicht angegeben, dann wird das in der MAX-Anweisung definierte Locale der Anwendung verwendet. | ||||||
LOCK= | lockcode Zugriffsschutz des LTERM-Pools. Lockcode, der den LTERM-Partnern des LTERM-Pools zugeordnet wird. lockcode ist ein Zahlenwert zwischen 1 und dem in der Anwendung erlaubten Maximalwert (MAX ...,KEYVALUE=). An einen LTERM-Partner dieses LTERM-Pools können Sie sich an die Anwendung nur unter einer UTM-Benutzerkennung (USER) anmelden, für die ein Keyset mit einem Keycode generiert wurde, der mit dem Lockcode des LTERM-Pools übereinstimmt.´ Standard: 0 (LTERM-Pool ist nicht durch Lockcode geschützt) | ||||||
LTERM= | ltermprefix Präfix für die Namen der LTERM-Partner des LTERM-Pools. Die LTERM-Namen sind 8 Zeichen lang und setzen sich zusammen aus dem hier angegebenen Präfix und einer Laufnummer. Die Laufnummer geht von 1 bis zu dem Wert, den Sie mit NUMBER=number1 angeben. Die maximale Länge von ltermprefix hängt davon ab, wieviele Dezimalstellen number1 besitzt. D.h. die Anzahl der Zeichen von ltermprefix plus die Anzahl der Dezimalstellen von number1 darf nicht größer als 8 sein. Bei der Angabe von ltermprefix und number1 ist zu beachten, dass die Namen der LTERM-Partner innerhalb einer Anwendung eindeutig sein müssen. Dies gilt für die mit TPOOL ...,LTERM= erzeugten Namen (in allen TPOOL-Anweisungen) und die mit LTERM-Anweisungen fest definierten Namen. Diese Namen dürfen in keiner LTERM-Anweisung angegeben werden! Zusätzlich dürfen die LTERM-Namen keinem weiteren Objekt der Namensklasse 1 zugeordnet sein. Siehe dazu auch Abschnitt "Eindeutigkeit der Namen und Adressen". | ||||||
MAP= | steuert die Code-Konvertierung (EBCDIC <-> ASCII) für die Benutzer-Nachrichten, die zwischen den Kommunikationspartnern ausgetauscht werden. | ||||||
USER | UTM konvertiert die Daten des Nachrichtenbereichs nicht, d.h. die Nachrichten werden unverändert zwischen den Kommunikationspartnern übertragen. Für TPOOLs, an die sich ausschließlich HTTP-Clients anschließen können, darf für den Parameter MAP nur der Standardwert USER angegeben werden. Auf BS2000-Systemen kann eine Code-Konvertierung für HTTP-Clients mittels der Anweisungen CHAR-SET und HTTP-DESCRIPTOR konfiguriert werden; siehe hierzu die Beschreibungen in den Abschnitten "CHAR-SET- Namen für Code-Tabellen vergeben (BS2000-Systeme)" und "HTTP-DESCRIPTOR - HTTP Descriptor definieren". Standard: USER | ||||||
SYSTEM | SYS1 | SYS2 | SYS3 | SYS4 | |||||||
Diese Parameter sind nur für folgende Partner zulässig:
UTM konvertiert die Benutzer-Nachrichten gemäß den für die Code- Konvertierung bereitgestellten Konvertierungstabellen (siehe Abschnitt "Code-Konvertierung"), d.h.:
Die Angaben SYSTEM und SYS1 sind synonym. | |||||||
NETPRIO= | Dieser Operand gilt nur für BS2000-Systeme. NETPRIO hat keine Bedeutung, wenn die Verbindung von der Partner- Anwendung über die Socket-Schnittstelle aufgebaut wird (PTYPE=SOCKET). Standard: MEDIUM | ||||||
NUMBER= | number1 number1 definiert die Anzahl der LTERM-Partner für diesen LTERM-Pool, d.h. es können sich maximal number1 Clients über den LTERM-Pool an die Anwendung anschließen. Der zulässige Maximalwert für number1 hängt von der Anzahl der Namen ab, die in der UTM-Anwendung generiert wurden (siehe Abschnitt "Anzahl der Namen"). Minimalwert: 1 | ||||||
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. Unix-, Linux und Windows-Systeme:
BS2000-Systeme:
| ||||||
{ processorname | C’processorname’ } | |||||||
Name des Partner-Rechners. Angegeben werden muss der vollständige Rechnername (FQDN), unter dem der Rechner im DNS bekannt ist. Der Name darf maximal 64 Zeichen lang sein. Nur Clients, die sich auf diesem Rechner befinden, können sich über diesen LTERM-Pool an die Anwendung anmelden. Enthält processorname Sonderzeichen, muss er als Zeichenkette mit C’...’ angegeben werden. Statt des Namen des Partner-Rechners können Sie auch den mapped name einer SUBNET-Anweisung angeben. Diese Namen beginnen mit einem "*". An einen so generierten TPOOL können sich alle Clients anschließen, die zu dem Subnetz gehören, das mit dieser SUBNET-Anweisung definiert ist. Beachten Sie bitte, dass Sie in diesem Fall beim Operanden BCAMAPPL den lokalen Anwendungsnamen der zugehörigen SUBNET-Anweisung angeben müssen. | |||||||
*ANY | Über den LTERM-Pool kann sich jeder Client an die Anwendung anmelden, der die folgenden Bedingungen erfüllt:
| ||||||
PROTOCOL= | Dieser Operand gilt nur für BS2000-Systeme. | ||||||
N | Es wird durch openUTM kein Benutzerdienstprotokoll gefahren. Haben Sie PTYPE=*ANY angegeben, dann ignoriert openUTM die Angabe PROTOCOL=NO. | ||||||
STATION | Zwischen der UTM-Anwendung und den über diesen LTERM-Pool angeschlossenen Clients wird das Benutzerdienstprotokoll (NEABT) gefahren. Bei PTYPE=*ANY muss PROTOCOL=STATION angegeben werden. openUTM benötigt in diesem Fall das Benutzerdienstprotokoll (NEABT) zur Bestimmung des Partnertyps, wenn der Typ bei der Generierung nicht explizit angeben wurde (PTYPE=*ANY). Standard: | ||||||
PTYPE= | Typ des Clients, der sich über diesen LTERM-Pool an die Anwendung anschließen kann. Haben Sie in BCAMAPPL= einen Anwendungsnamen angegeben, der für die Kommunikation über die Socket-Schnittstelle generiert ist (BCAMAPPL-Anweisung mit T-PROT=SOCKET), dann müssen Sie PTYPE=SOCKET setzen. Pflichtoperand | ||||||
partnertyp | gibt explizit den Typ des Clients an. Eine Liste der unterstützten Partnertypen finden Sie bei der Beschreibung der Steueranweisung PTERM im Abschnitt "PTERM - Eigenschaften von Clients und Druckern und Zuordnung zum LTERM-Partner festlegen". | ||||||
*ANY | Nur auf BS2000-Systemen erlaubt. In diesem Fall nimmt openUTM den Typ des Partners beim Verbindungsaufbau aus dem Benutzerdienstprotokoll. Erst dann wird entschieden, ob der Partnertyp unterstützt wird. Der Vorteil von PTYPE=*ANY ist, dass Sie Clients in die Konfiguration aufnehmen können, ohne ihren Typ zu kennen. Darüber hinaus wird die Pflege der Konfiguration erleichtert, denn auch wenn der Typ z.B. in der Terminalemulation geändert wird, kann dieser Client weiterhin eine Verbindung zu der Anwendung aufbauen, ohne dass Sie die KDCDEF-Generierung ändern müssen. | ||||||
QLEV= | queue_level_number (queue level) Standard: 32767 Wird ein Wert angegeben, der größer als der Maximalwert ist, dann wird im KDCDEF-Lauf ohne Meldung der Standardwert gesetzt. | ||||||
STATUS= | Mit NUMBER=number1 legen Sie die Anzahl der LTERM-Partner für den LTERM-Pool fest. Mit STATUS=number2 geben Sie an, wie viele Clients beim Start der Anwendung für den LTERM-Pool zugelassen (ON) bzw. gesperrt (OFF) sind. Während des Betriebs der Anwendung kann number2 per Administration geändert werden. Standard: STATUS=(OFF , 0), d.h. alle Clients des LTERM-Pools sind zugelassen. | ||||||
ON | Es werden number2 Clients zugelassen. | ||||||
OFF | Es werden number2 Clients gesperrt. | ||||||
number2 | Anzahl der Clients, und damit Anzahl der LTERM-Partner des LTERM-Pools, die beim Anwendungsstart zugelassen oder gesperrt sind. | ||||||
TERMN= | termn_id Kennzeichen für die Art des Clients, das openUTM dem Anwendungsprogramm im Feld KCTERMN des KB-Kopfes zur Verfügung stellt. termn_id ist max. 2 Zeichen lang. termn_id wird nicht von openUTM abgefragt, es kann vom Benutzer zur Auswertung verwendet werden. Standardwerte: Wird der Operand nicht angegeben, so trägt openUTM in KCTERMN das Standard-Kennzeichen für den Partnertyp ein, der beim Operanden PTYPE angegeben wird. Der Benutzer kann jedoch auch andere Werte wählen. Die Standardwerte sind der Partnertyp-Tabelle der PTERM-Anweisung, Operand PTYPE im Abschnitt "PTERM - Eigenschaften von Clients und Druckern und Zuordnung zum LTERM-Partner festlegen" zu entnehmen. BS2000-Systeme: | ||||||
USER-KSET= | keysetname2 nur erlaubt, wenn die Anwendung mit Benutzerkennungen generiert wird und PTYPE=APPLI, SOCKET, UPIC-R oder UPIC-L angegeben wird. USER-KSET= dürfen Sie nur zusammen mit KSET= setzen. Für ksetname2 ist der Name eines Keyset anzugeben. Das Keyset muss mit einer KSET-Anweisung definiert werden. Mit USER-KSET= legen Sie die minimalen Zugriffsrechte fest, die ein über diesen LTERM-Pool verbundener Client ausüben kann. ksetname2 wird wirksam, wenn der Client unter der Verbindungs-Benutzerkennung angemeldet ist. Seine Zugriffsrechte ergeben sich aus der Menge der Keycodes, die sowohl in dem mit KSET= als auch in dem mit USER-KSET= generierten Keyset enthalten sind (Schnittmenge). Aus diesem Grund sollten alle Keycodes, die USER-KSET=ksetname2 enthält, auch in KSET=ksetname1 enthalten sein. Standard: kein Keyset | ||||||
USP-HDR= | Legt fest, für welche Ausgabe-Nachrichten openUTM auf den mit dieser Anweisung generierten Verbindungen einen UTM-Socket-Protokoll-Header aufbauen soll. Ein Wert ungleich NO darf nur bei LTERM-Pools angegeben werden, die für die Kommunikation über Socket-Verbindungen konfiguriert sind (PTYPE=SOCKET). Eine Beschreibung des USP-Headers finden Sie im openUTM-Handbuch „Anwendungen programmieren mit KDCS“. Für TPOOLs, an die sich ausschließlich HTTP-Clients anschließen können, darf für den Parameter USP-HDR nur der Standardwert NO angegeben werden. | ||||||
ALL | Bei allen Ausgabe-Nachrichten (Dialog, Asynchron, K-Meldungen) erzeugt openUTM einen UTM-Socket-Protokoll-Header und stellt diesen der Nachricht voran. | ||||||
MSG | Nur bei der Ausgabe von K-Meldungen erzeugt openUTM einen UTM-Socket-Protokoll-Header und stellt diesen der Nachricht voran. | ||||||
NO | Es werden keine UTM-Socket-Protokoll-Header erzeugt. Standard: NO | ||||||