obj_type = KC_PTERM

Um einen Drucker oder Client (d.h. ein Terminal, einen UPIC-Client oder eine TS-Anwendung) in die Konfiguration aufzunehmen, müssen Sie die Datenstruktur kc_pterm_str über den Datenbereich legen. In kc_pterm_str übergeben Sie Namen, Adresse und Eigenschaften des Client bzw. Druckers an UTM. Der folgenden Tabelle können Sie entnehmen, wie die Felder der Struktur zu versorgen sind. 

openUTM auf Windows-Systemen unterstützt keine Drucker.

	Feldname1	Bedeutung
m	pt_name[8]	Name des Client bzw. Druckers. Der Name darf bis zu 8 Zeichen lang sein. In pt_name ist der symbolische Name anzugeben, unter dem der Client/Drucker dem Transportsystem bekannt ist. Zum Format des Namens und zur Eindeutigkeit siehe im Abschnitt „Format und Eindeutigkeit der Objektnamen". Namen von zuvor gelöschten Objekten, die zu derselben Namensklasse gehören, dürfen nicht verwendet werden. Wenn Ihre Anwendung einen LTERM-Pool mit connect_mode='M' (Multi) enthält, dann darf das Tripel (pt_name, pronam, bcamappl) nicht mit einem Namenstripel des LTERM-Pools übereinstimmen (= Tripel aus dem Namen eines Pool-LTERM-Partners, dem Rechnernamen des Pool-Client und dem BCAMAPPL-Namen der Anwendung, über den die Verbindung vom Client aufgebaut wird). Es kann sich sonst kein Client mehr über diesen LTERM-Pool anschließen.
		Besonderheiten bei der Kommunikation über die Socket-Schnittstelle: Soll die Verbindung zwischen Kommunikationspartner und UTM-Anwendung über die Socket-Schnittstelle (SOCKET) erfolgen und soll der Partner beim Verbindungsaufbau eine bestimmte Portnummer verwenden, dann müssen Sie für pt_name den Wert PRTnnnnn angeben. Dabei ist nnnnn die Portnummer im fernen System, über die der Partner die Verbindung aufbaut. Ist der Partner eine UTM-Anwendung, dann ist die Angabe der Portnummer nicht möglich, da UTM die Portnummer nicht selbst setzt. Wird die Verbindung nicht von der Partner-Anwendung aufgebaut, sondern nur von der lokalen Anwendung aus, dann wird der Name nur intern gebraucht, z.B. für die Administration.
(m)	pronam_long[64]	Name des Rechners, auf/an dem sich der Client/Drucker befindet.
		Angegeben werden muss der vollständige Rechnername (FQDN), unter dem der Rechner im DNS bekannt ist. Der Name darf maximal 64 Zeichen lang sein. Anstelle eines bis zu 64 Zeichen langen FQDN-Namens kann weiterhin ein kurzer, maximal 8 Zeichen langer lokaler Name (im BS2000-System: BCAM-Name) des Partnerrechners angegeben werden. In diesem Fall muss der lokale Name unter Zuhilfenahme von externer Zusatzinformation (im BS2000-System: FQDN-Datei, im Unix-/Linux-/Windows-System: hosts-Datei) vom Transportsystem auf einen FQDN-Namen bzw. eine IP-Adresse abbildbar sein.
		Ist auf BS2000-Systemen ptype='*RSO', dann muss pronam_long='*RSO' angegeben werden.
		Wird die Verbindung zum Partner über die Socket-Schnittstelle aufgebaut, dann müssen Sie für pronam_long die symbolische Adresse bzw. den realen Hostnamen des Rechners angeben.
		Auf Unix-, Linux- und Windows-Systemen ist die Angabe von pronam_long nur für ptype='UPIC-R', 'APPLI' oder 'SOCKET' erlaubt. Bei Terminals und Druckern setzt openUTM den Standardwert (Leerzeichen) ein.
o	bcamappl[8]	Name der UTM-Anwendung, über den die Verbindungen zwischen UTM-Anwendung und Client/Drucker aufgebaut werden sollen. Der Anwendungsname muss bei der KDCDEF-Generierung in MAX APPLINAME oder mit einer BCAMAPPL-Anweisung statisch generiert worden sein.
		Soll die Verbindung zum Kommunikationspartner über das Protokoll SOCKET aufgebaut werden, dann müssen Sie einen BCAMAPPL-Namen angeben, für den t_prot='T' generiert ist.
		Nur auf BS2000-Systemen: Bei ptype ungleich 'APPLI', 'SOCKET' oder 'UPIC-R' darf für bcamappl nur der in MAX APPLINAME generierte Anwendungsname (Standardwert) angegeben werden.
(m)	ptype[8]	Typ des Client/Druckers. Eine Liste der möglichen Angaben finden Sie im Abschnitt "kc_pterm_str - Clients und Drucker"f. Bei ptype='APPLI', 'SOCKET' oder 'UPIC-R' muss lterm spezifiziert werden.
		Die Angabe von ptype ist in UTM-Anwendungen auf BS2000-Systemen Pflicht.
		Auf Windows-Systemen ist die Angabe von ptype='PRINTER' nicht erlaubt.
o	ptype_fotyp[8]	Ist nur bei Druckern auf Unix- und Linux-Systemen relevant (ptype='PRINTER'). In ptype_fotyp geben Sie den Druckertyp (printertype) an.
o	ptype_class[40]	Ist nur bei Druckern auf Unix- und Linux-Systemen relevant (ptype='PRINTER'). In ptype_class geben Sie den Namen der Druckergruppe (printer class) an, zu der der Drucker gehört. Die Druckergruppe wird bei der Generierung auf Unix- und Linux-Systemen festgelegt.
(m)	lterm[8]	Name des LTERM-Partners, der diesem Client/Drucker zugeordnet werden soll. Bei Terminals und Druckern ist die Angabe optional. Ihnen kann zu einem späteren Zeitpunkt durch die Administration ein LTERM-Partner zugeordnet werden. Wird in lterm der Name eines LTERM-Partners angegeben, dann muss er vor dem Terminal/Drucker statisch oder dynamisch in die Konfiguration eingetragen worden sein.
		Bei UPIC-Clients und TS-Anwendungen (ptype= 'UPIC-L', 'UPIC-R', 'APPLI' oder 'SOCKET') ist lterm Pflichtparameter. Der angegebene LTERM-Partner muss in derselben Transaktion wie der Client erzeugt werden. Siehe dazu Kapitel „Konfiguration dynamisch ändern".
o	auto_connect	Legt fest, ob die Verbindung zu dem Client/Drucker beim Start der Anwendung automatisch aufgebaut wird:
		'Y'	Bei jedem Start der Anwendung soll UTM versuchen, die Verbindung zum Client/Drucker aufzubauen.
		'N'	Es soll kein automatischer Verbindungsaufbau durchgeführt werden.
		Für UPIC-Clients ist nur auto_connect='N' erlaubt.
o	state	Legt fest, ob der Client/Drucker nach dem Eintragen zunächst gesperrt sein soll oder nicht.
		'Y'	Der Client/Drucker soll nicht gesperrt werden. (ON)
		'N'	Der Client/Drucker soll gesperrt werden. (OFF)
o	cid[8]	Ist nur für Drucker auf BS2000-, Unix- und Linux-Systemen relevant. In cid geben Sie die Drucker-Id (CID) an. Die CID darf maximal 8 Zeichen lang sein. Die CID wird benötigt, wenn der Drucker über ein Druckersteuer-LTERM administriert werden soll. Das Druckersteuer-LTERM identifiziert den Drucker über die CID. Die CID muss im Bereich des Druckersteuer-LTERMs eindeutig sein.
o	map	Nur relevant bei TS-Anwendungen (ptype='APPLI') oder SOCKET-USP-Anwendungen.
		In map legen Sie fest, ob UTM eine Code-Konvertierung (EBCDIC<->ASCII) für die Benutzer-Nachrichten, die zwischen den Kommunikationspartnern ausgetauscht werden, durchführen soll oder nicht. Benutzer-Nachrichten werden an der KDCS-Schnittstelle bei den Aufrufen zur Nachrichtenbehandlung (MPUT/FPUT/DPUT) im Nachrichtenbereich übergeben.
		'U' (USER) UTM konvertiert die Daten des Nachrichtenbereichs nicht, d.h. die Nachrichten werden unverändert zwischen den Kommunikationspartnern übertragen.
		'S' , '1' , '2', '3', '4' ist nur für folgende TS-Anwendungen erlaubt: BS2000-Systeme: ptype='SOCKET' Unix-, Linux- oder Windows-Systeme: ptype='APPLI' oder 'SOCKET' Geben Sie einen der obigen Werte an, dann konvertiert UTM 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. Die Angaben 'S' und '1 sind dabei synonym. Dabei geht UTM davon aus, dass die Nachrichten nur abdruckbare Zeichen enthalten. Weitere Informationen zur Code-Konvertierung finden Sie im openUTM-Handbuch „Anwendungen programmieren mit KDCS“, Abschnitt "Code-Konvertierung".
o	termn[2]	Kennzeichen für die Art des Client/Druckers (Terminalmnemonic). Das Kennzeichen ist maximal 2 Zeichen lang. Die Standardwerte für termn finden Sie in der Tabelle im Abschnitt "kc_pterm_str - Clients und Drucker" ("BS2000-Systeme" bzw. "Unix-, Linux- und Windows-Systeme").
o	protocol	Nur auf BS2000-Systemen: Legt fest, ob auf Verbindungen zu dem Client/Drucker mit dem Benutzerdienstprotokoll NEABT gearbeitet werden soll.
		'N' (NO): Es wird ohne NEABT gearbeitet.
		'S' (STATION): Es wird mit NEABT gearbeitet.
		Für Clients, die sich über einen Multiplexanschluss anschließen sollen, muss protocol='S' angegeben werden.
		Für UPIC-Clients, RSO-Drucker und TS-Anwendungen, mit denen über die Socket-Schnittstelle kommuniziert werden soll, müssen Sie protocol='N' angeben. Die Angabe von protocol='S' wird in diesen Fällen ignoriert.
o	usage_type	Nur auf BS2000-Systemen: Legt fest, ob ein Dialog-Partner oder ein Ausgabemedium konfiguriert wird. Folgendes können Sie angeben:
		'D' für einen Dialog-Partner 'O' für ein Ausgabemedium (z.B. Drucker)
o	listener_port[5]	Bei listener_port geben Sie an, an welcher Portnummer im fernen System die Partner-Anwendung auf Verbindungsaufbauwünsche von außen wartet. Es sind alle Portnummern erlaubt.
		Auf BS2000-Systemen ist die Angabe von listener_port nur bei ptype='APPLI' oder 'SOCKET' erlaubt. Bei ptype='SOCKET' ist die Angabe Pflicht. Eine Portnummer ungleich 0 darf nur angegeben werden, wenn die bei bcamappl angegebene lokale Anwendung nicht mit T-PROT=NEA generiert ist.
		Auf Unix-, Linux und Windows-Systemen ist listener-port nur für t_prot='T' und 'R' relevant.
o	t_prot	nur relevant bei Clients vom Typ ptype='APPLI', 'SOCKET' oder 'UPIC-R' auf Unix-, Linux- und Windows-Systemen: In t_prot geben Sie das Adressformat der Transportadresse des Client an. Mögliche Werte sind:
		'R'	RFC1006, ISO-Transportprotokoll Klasse 0 über TCP/IP und Konvergenzprotokoll RFC1006 (APPLI, UPIC-R)
		'T'	native TCP-IP-Transportprotokoll für die Kommunikation über die Socket-Schnittstelle (SOCKET)
o	tsel_format	nur relevant bei Clients vom Typ ptype='APPLI', 'SOCKET' oder 'UPIC-R' auf Unix-, Linux- und Windows-Systemen: In tsel_format geben Sie das Format des T-Selektors der Client-Adresse an. Mögliche Werte sind:
		'T' für das TRANSDATA-Format 'E' für das EBCDIC-Zeichenformat 'A' für das ASCII-Zeichenformat
o	idletime[5]	Darf nur für Dialog-Partner angegeben werden. In idletime legen Sie die Zeit in Sekunden fest, 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 für idletime angegebene Wert darf nicht kleiner sein als die Timerangaben in kc_timer_par_str.termwait_in_ta_sec und kc_timer_par_str.pgwttime_sec (siehe im Abschnitt "kc_timer_par_str - Timer-Einstellungen" (pgwttime_sec)).
		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 nach Ablauf der Wartezeit automatisch abgebaut. Damit wird die Wahrscheinlichkeit für einen unberechtigten Zugang verringert.
		Maximalwert: '32767' Minimalwert: '60' Der Wert 0 bedeutet Warten ohne Zeitbegrenzung. Bei Werten ungleich 0 und kleiner als 60 wird der Wert 60 verwendet.
		Bei einem ungültigen Wert setzt UTM idletime auf den kleinsten zulässigen Wert und liefert den Returncode KC_MC_OK mit Subcode KC_SC_INVALID_IDLETIME zurück.
o	encryption_level	nur relevant für UPIC-Clients und auf BS2000-Systemen zusätzlich für einige Terminalemulationen.
		In encryption_level legen Sie die minimale Verschlüsselungsebene für die Kommunikation mit dem Client fest, ob die Verschlüsselung der Nachrichten standardmäßig angefordert wird oder nicht, welche Verschlüsselungsebene dabei gefordert wird, oder ob der Client ein „trusted“ Client ist. Folgende Angaben sind möglich:
		'N'	(NONE) Die Verschlüsselung der Nachrichten wird von UTM nicht angefordert. Passworte werden verschlüsselt übertragen, sofern beide Partner Verschlüsselung unterstützen. Vorgänge, für deren Vorgangs-TACs Verschlüsselung generiert wurde (siehe kc_tac_str.encryption_level im Abschnitt "kc_tac_str - Transaktionscodes lokaler Services"), können von diesem Client nur gestartet werden, wenn der Client die Verschlüsselung aushandelt.
		'3'	(LEVEL 3) UTM fordert die Verschlüsselung der Nachrichten mit der Verschlüsselungsebene 3 an, d.h. die Nachrichten und Passworte 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.
		'4'	(LEVEL 4) UTM fordert die Verschlüsselung der Nachrichten mit der Verschlüsselungsebene 4 an, d.h. die Nachrichten und Passworte 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.
		'5'	(LEVEL 5) UTM fordert die Verschlüsselung der Nachrichten mit der Verschlüsselungsebene 5 an, d.h. die Nachrichten werden mit AES-GCM Algorithmus verschlüsselt. Die Vereinbarung des AES-Schlüssels erfolgt über das Ephemeral Elliptic Curve Diffie-Hellman Verfahren (ECDHE). Dabei wird zur Signatur des öffentlichen Server-Schlüssels ein RSA Schlüssel mit einer Schlüssellänge von 2048 Bits verwendet. Der Level 5 wird von openUTM nur für Unix-, Linux- und Windows-Systeme unterstützt.
			Der Verbindungsaufbau zu dem Client wird von UTM abgelehnt, wenn der Client nicht mindestens die angegebene Verschlüsselungsebene ( 3, 4 oder 5) unterstützt. encryption_level=3 ... 5 ist nur sinnvoll, wenn an Ihrem System die Verschlüsselungsfunktionen  zur Verfügung stehen. Andernfalls kann sich der Client nicht anschließen.
		'T'	(TRUSTED) Der Client ist ein „trusted Client“. Nachrichten zwischen Client und 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 "kc_tac_str - Transaktionscodes lokaler Services"). Dieser Wert sollte nur gewählt werden, wenn der Client nicht für jedermann zugänglich ist und die Kommunikation über eine sichere Verbindung läuft.
		Für die einzelnen Client-Typen gilt bezüglich der Verschlüsselungsebene: Für remote UPIC-Clients (PTYPE=UPIC-R) sind Verschlüsselungsebenen 3 bis 5 sinnvoll. Bei lokalen UPIC-Clients (PTYPE=UPIC-L) einer Anwendung auf Unix-, Linux- und Windows-Systemen wird 3, 4 oder 5 von UTM durch TRUSTED ersetzt. Für HTTP-Clients, die sich über einen Transportsystemendpunkt (BCAMAPPL) an die Anwendung anschließen, der mit T-PROT=(..., SECURE) generiert ist, wird von UTM als Encryption Level immer TRUSTED gesetzt. Wird 3 ... 5 für einen Partner eines anderen Typs angegeben, dann wird der Wert von UTM durch in NONE ersetzt.
		Voraussetzung für die Verschlüsselung der Daten auf Verbindungen zum Client ist, dass entsprechende RSA-Schlüssel verfügbar sind. Falls die Anwendung mit OPTION GEN-RSA-KEYS=NO generiert ist, dann erzeugt KDCDEF keine RSA-Schlüssel, d.h. es sind standardmäßig keine RSA-Schlüssel verfügbar. Es ist jedoch möglich, RSA-Schlüssel per KDCUPD zu übertragen oder mit KC_ENCRYPT zu erzeugen. Diese können dann von den neu erzeugten Objekten benutzt werden.
o	usp_hdr	Dieser Parameter ist nur für PTERMs mit ptype='SOCKET' von Bedeutung. Er legt fest, für welche Ausgabe-Nachrichten UTM auf dieser Verbindung einen UTM-Socket-Protokoll-Header aufbaut. Mögliche Werte sind:
		'A'	Bei allen Ausgabe-Nachrichten (Dialog, Asynchron, K-Meldungen) erzeugt UTM einen UTM-Socket-Protokoll-Header und stellt diesen der Nachricht voran.
		'M'	Nur bei Ausgabe von K-Meldungen erzeugt UTM einen UTM-Socket-Protokoll-Header und stellt diesen der Nachricht voran.
		'N'	UTM erzeugt für keine Ausgabe-Nachricht einen UTM-Socket-Protokoll-Header.

1	Alle nicht aufgeführten Felder der Datenstruktur kc_pterm_str und alle für das verwendete Betriebssystem nicht relevanten Felder sind mit binär null zu versorgen. Die Datenstruktur ist im Abschnitt "kc_pterm_str - Clients und Drucker" vollständig beschrieben.