openUTM V7.0 (de)

Mit der PTERM-Anweisung definieren Sie die Eigenschaften der physikalischen Clients und Drucker der UTM-Anwendung.

Clients sind Terminals, UPIC-Clients und Transportsystem-Anwendungen. Unter Transportsystem-Anwendungen (kurz TS-Anwendungen) versteht man alle Anwendungen, die als PTYPE=APPLI oder PTYPE=SOCKET generiert sind. Siehe dazu auch die Tabelle beim Operanden PTYPE im Abschnitt "PTERM - Eigenschaften von Clients und Druckern und Zuordnung zum LTERM-Partner festlegen" (BS2000-Systeme) bzw. im Abschnitt "PTERM - Eigenschaften von Clients und Druckern und Zuordnung zum LTERM-Partner festlegen" (Unix-, Linux- und Windows-Systeme).

Für Clients müssen Sie immer dann eine PTERM-Anweisung absetzen, wenn von der lokalen UTM-Anwendung aus eine Verbindung zum Client/Drucker aufgebaut werden soll.

Mit der PTERM-Anweisung ordnen Sie einem Client/Drucker einen LTERM-Partnern zu. Der LTERM-Partner wird in der LTERM-Anweisung definiert. Für jeden Client/Drucker ist dabei eine LTERM-Anweisung zu schreiben, siehe auch Beschreibung der LTERM-Anweisung im Abschnitt "LTERM - LTERM-Partner für Clients und Drucker definieren".

Sie können aber auch zunächst Clients/Drucker in PTERM-Anweisungen beschreiben und die Zuordnung zu LTERM-Partnern später im Betrieb per Administration vornehmen. Ausnahmen sind UPIC-Clients und TS-Anwendungen, ihnen müssen Sie sofort einen LTERM-Partner zuordnen.

Wenn keine LTERM-Pools (TPOOL-Anweisung, siehe Abschnitt "TPOOL - LTERM-Pools definieren") generiert sind, müssen Sie in mindestens einer PTERM-Anweisung im Operanden LTERM= einen Client zuweisen. Nur dann kann eine Verbindung zur Anwendung aufgebaut werden, über die Sie mit der Anwendung arbeiten können.

Von openUTM auf Windows-Systemen werden Drucker nicht unterstützt.

Adresse des Client/Druckers

Damit die Anwendung Verbindungen zum Client/Drucker aufbauen kann, müssen Sie seine Adresse angeben. Dazu dienen die Operanden

ptermname (Name/T-Selektor des Kommunikationspartners)
PRONAM (Name des Partner-Rechners)
Auf Unix-, Linux- und Windows-Systemen darf der Name des Partner-Rechners nur angegeben werden, wenn der Partner ein remote UPIC-Client (UPIC-R) oder eine TS-Anwendung (PTYPE= APPLI oder SOCKET) ist.
LISTENER-PORT (TCP/IP-Portnummer)
Auf BS2000-Systemen darf LISTENER-PORT nur bei PTYPE=APPLI und PTYPE=SOCKET angegeben werden.
Unix-, Linux- und Windows-Systeme:
Zur weiteren Definition der Partneradresse dienen auf Unix-, Linux- und Windows-Systemen folgende Operanden:
- T-PROT (Adressformat für das verwendete Transportprotokoll)
- TSEL-FORMAT (Formatindikator des T-Selektors)
Siehe dazu Abschnitt "Adressinformationen für das Transportsystem CMX bereitstellen (Unix-, Linux- und Windows-Systeme)" bzw. Abschnitt "Adressinformationen für das Transportsystem SOCKET bereitstellen (Unix-, Linux- und Windows-Systeme)".

Wird die Verbindung zu einer TS-Anwendung über die Socket-Schnittstelle mit native TCP/IP als Transportprotokoll aufgebaut, dann müssen Sie in PRONAM den Rechner angeben, an dem die TS-Anwendung abläuft, und in LISTENER-PORT die Portnummer innerhalb des Partner-Rechners, an der die TS-Anwendung auf Verbindungsaufbauwünsche aus dem Netz wartet. In BCAMAPPL müssen Sie einen Anwendungsnamen angeben, für den T-PROT=SOCKET generiert wurde (siehe auch BCAMAPPL-Anweisung im Abschnitt "BCAMAPPL - Weitere Anwendungsnamen definieren").
Mit dem Operanden MAP können Sie festlegen, ob openUTM eine Code-Konvertierung durchführen soll oder nicht.

Eindeutigkeit der Namen

Bei der Generierung der CON-, PTERM- und MUX-Anweisung ist zu beachten, dass das Namenstripel (appliname bzw. ptermname, processorname, local_appliname) innerhalb eines Generierungslaufs eindeutig sein muss.

BS2000-Systeme:
Um die Generierung einer UTM-Anwendung auf BS2000-Systemen unabhängiger vom Terminaltyp zu machen, können Sie Terminals in die Konfiguration aufnehmen, ohne ihren Typ explizit anzugeben. Dazu geben Sie im Operanden PTYPE den Wert *ANY an. openUTM übernimmt dann den Partnertyp (PTYPE) beim Verbindungsaufbau aus dem Benutzersdienstprotokoll (Connection Letter) und überprüft, ob der Typ unterstützt werden kann. Unterstützt openUTM den Typ nicht, dann wird der Verbindungswunsch abgelehnt.

PTERM

ptermname [ ,BCAMAPPL=local_appliname ] [ ,CONNECT={ YES | NO } ] [ ,ENCRYPTION-LEVEL={ NONE | 3 | 4 | 5² | TRUSTED } ] [ ,IDLETIME=time ] [ ,LISTENER-PORT=number ] [ ,LTERM=ltermname ] [ ,MAP={ USER | SYSTEM | SYS1 | SYS2 | SYS3 | SYS4 } ] ,PRONAM={ processorname | C’processorname’| *RSO¹ } nur auf BS2000-Systemen Pflichtoperand [ ,STATUS={ ON | OFF } ] [ ,TERMN=termn_id ] [ ,USP-HDR={ NO | MSG | ALL } ]


            
              
                
                  
                    
                      
                        
                          
                            
                              
                                
                                  
                                    
                                      
                                        
                                          
                                            
                                              
                                                
                                                  
                                                    
                                                      
                                                        
                                                            
BS2000-, Unix- und Linux-spezifischer Operand 
                                                          

                                      [ ,CID=printer_id ]


            
              
                
                  
                    
                      
                        
                          
                            
                              
                                
                                  
                                    
                                      
                                        
                                          
                                            
                                              
                                                
                                                  
                                                    
                                                      
                                                        
                                                          
                                                              
BS2000-spezifische Operanden 
                                                            
[ ,PROTOCOL={ N | STATION } ]
  ,PTYPE={ partnertyp | *ANY | *RSO }
[ ,USAGE={ D | 0 } ]


            
              
                
                  
                    
                      
                        
                          
                            
                              
                                
                                  
                                    
                                      
                                        
                                          
                                            
                                              
                                                
                                                  
                                                    
                                                      
                                                        
                                                          
                                                              
Unix-, Linux- und Windows-spezifische Operanden 
                                                            
[ ,PTYPE={ partnertyp | 
                     PRINTER | ( PRINTER ,printertype [ ,class ] ) } ]
[ ,T-PROT=RFC1006 | SOCKET ] 
[ ,TSEL-FORMAT={ T | E | A } ]

¹ Dieser Operandenwert ist nur auf BS2000-Systemen erlaubt.
² Dieser Operandenwert ist nur auf Unix- und Linux-Systemen erlaubt.

ptermname

Maximal 8 Zeichen langer Name des Clients oder Druckers

Der angegebene Name muss eindeutig sein und darf keinem weiteren Objekt der Namsensklasse 3 zugeordnet sein. Siehe dazu auch Abschnitt "Eindeutigkeit der Namen und Adressen".

Folgende Fälle sind zu unterscheiden:

Socket-Anwendungen (PTYPE=SOCKET)

Wird die Verbindung von der lokalen Anwendung zum Client aufgebaut, dann kann ptermname beliebig gewählt werden. Er ist dann nur UTM-intern von Bedeutung, z.B. für die Administration.
Soll die Verbindung von außen (Initiative beim Client) aufgebaut werden, dann muss ptermname die Portnummer enthalten, über die der Client die UTM-Anwendung adressiert. Als ptermname müssen Sie dann das Präfix „PRT“ gefolgt von fünf Ziffern (eventuell mit führenden Nullen) angeben, die die Portnummer bezeichnen. Z.B. müssen Sie ptermname=PRT08050 angeben, wenn der Client die UTM-Anwendung über den Port 8050 adressieren soll.
Der Verbindungsaufbau von außen zu einem bestimmten PTERM ist jedoch nur von Partnern möglich, die ihre Portnummer bei einem Verbindungsaufbau selbst setzen. openUTM tut dies nicht, d.h. für eine ferne UTM-Anwendung, die SOCKET-Verbindungen zur lokalen Anwendung aufbauen soll, können Sie keine PTERM-Anweisung absetzen. Sie muss sich über einen LTERM-Pool anschließen.

BS2000-Systeme:
Bei RSO-Druckern (PTYPE=*RSO), muss hier der Name des Druckers angegeben werden, wie er bei RSO definiert wurde.

Unix-, Linux- und Windows-Systeme:
Bei UPIC-Clients und TS-Anwendungen mit PTYPE=APPLI müssen Sie für ptermname den T-Selektor angeben, der dem Client im fernen System zugeordnet ist, wenn Sie OPTION CHECK-RFC1006=YES setzen (siehe OPTION-Anweisung im Abschnitt "OPTION - KDCDEF-Lauf steuern").

Unix- und Linux-Systeme:
Bei Druckern wird als ptermname der Name der Spool Queue bzw. Druckergruppe angegeben, wie bei der Generierung des Unix- oder Linux-Systems festgelegt. Für die Ausgabe der Daten ruft der Druckerprozess (utmprint) das Skript utmlp auf (siehe PTYPE=PRINTER im Abschnitt " PTERM - Eigenschaften von Clients und Druckern und Zuordnung zum LTERM-Partner festlegen ").

Bei lokalen Terminals und Pseudoterminals muss in jeder PTERM- Anweisung für ptermname das Ergebnis des Kommandos basename ` tty ` angegeben werden, damit die UTM-Generierung mit der Generierung der Terminals auf dem Unix- oder Linux-System übereinstimmt.

Es kann auf Unix- und Linux-Systemen vorkommen, dass die Standardzuordnung von ptermname durch openUTM nicht eindeutig ist. Abhängig von der Art der Netze, an die das System angeschlossen ist, können zwei oder mehr Pseudoterminals existieren, die sich in dem letzten Term des tty (hinter dem letzten Schrägstrich) nicht unterscheiden. Nur ein Terminal kann dann mit diesem ptermname die Verbindung zur Anwendung aufbauen. Die Verbindungsanforderung des zweiten Terminals wird von openUTM zurückgewiesen.

Beispiel
Es können gleichzeitig die ttys /dev/pts/12 und /dev/inet/12 existieren. Fordert das Terminal /dev/pts/12 die Verbindung zur Anwendung mit ptermname 12 zu einem Zeitpunkt an, zu dem das Terminal /dev/inet/12 bereits mit der Anwendung verbunden ist, dann wird die Verbindungsanforderung von /dev/pts/12 abgelehnt. Als ptermname werden die letzten beiden Teile der Ausgabe des tty-Kommandos angegeben; z.B. statt PTERM 12 die Anweisungen PTERM pts/12 und PTERM inet/12.

Stattdessen können Sie auch einen LTERM-Pool mit PTYPE=TTY generieren.

Windows-Systeme:
Bei Terminals kann ein beliebiger ptermname angegeben werden.

BCAMAPPL=

local_appliname

Name der lokalen UTM-Anwendung, wie er mit MAX ...,APPLINAME= oder mit der BCAMAPPL-Anweisung festgelegt wurde, siehe auch Abschnitt "BCAMAPPL - Weitere Anwendungsnamen definieren". Beim Verbindungsaufbau zwischen Client/Drucker und UTM-Anwendung muss local_appliname als Partnername angegeben werden.

Bei Terminals und Druckern darf hier nur der in MAX ...,APPLINAME= definierte Name verwendet werden.

Für PTERMs mit PTYPE=SOCKET müssen Sie in local_appliname einen Namen angeben, der mit BCAMAPPL ... T-PROT=SOCKET generiert ist.

Unix-, Linux- und Windows-Systeme:
Der in der CLUSTER-Anweisung angegebene BCAMAPPL-Name ist hier nicht erlaubt.

Standardwert:
Wert aus MAX APPLINAME= (primärer Name der UTM-Anwendung)

Der Standardwert wird angenommen, wenn BCAMAPPL= nicht angegeben wird oder für BCAMAPPL= Leerzeichen angegeben werden.

CID=

printer_id

Dieser Operand gilt nur für BS2000-, Unix- und Linux-Systeme.

gilt nur für Drucker, die einem Druckersteuer-LTERM zugeordnet werden. Über printer_id werden die Drucker am Druckersteuer-LTERM identifiziert. printer_id kann maximal 8 Zeichen lang sein.

Über das Druckersteuer-LTERM werden die Drucker, Drucker Queues und Druckaufträge administriert.

Wird dem Drucker ein LTERM-Partner zugeordnet, für den mit LTERM ...,CTERM=ltermname2 ein Druckersteuer-LTERM definiert wurde, dann ist dieser Drucker ebenfalls dem Druckersteuer-LTERM zugeordnet. Dabei muss die Kombination aus ltermname2 des Druckersteuer-LTERMs und CID eindeutig sein.

Standard: Dem Drucker wird keine CID zugeordnet.

CONNECT=

gibt an, ob openUTM beim Anwendungsstart automatisch eine Verbindung zum Client bzw. Drucker aufbaut.

Auf BS2000-Systemen ist CONNECT= nur relevant für TS-Anwendungen, Terminals und Drucker.
Auf Unix- und Linux-Systemen ist CONNECT= nur relevant für TS-Anwendungen und Drucker.
Auf Windows-Systemen ist CONNECT= nur relevant für TS-Anwendungen.

YES

openUTM versucht, beim Start der Anwendung automatisch eine Verbindung aufzubauen.

Bei Druckern, die mit LTERM ...,PLEV > 0 generiert sind, versucht openUTM, die logische Verbindung erst aufzubauen, wenn der PLEV-Wert überschritten ist.

Kann die Verbindung zu einem Drucker oder einer TS-Anwendung nicht aufgebaut werden, versucht openUTM, die Verbindung in dem Zeitabstand aufzubauen, der in MAX ...,CONRTIME angegeben ist.

BS2000-Systeme:
Lässt sich die Verbindung zu einem Terminal nicht aufbauen, kann der Benutzer zu einem späteren Zeitpunkt die logische Verbindung aufbauen.

Unix- und Linux-Systeme:
Für Drucker erzeugt openUTM beim Start der Anwendung automatisch einen ptermname zugeordneten Druckerprozess, der Druckaufträge bearbeiten kann.

NO

Beim Start der Anwendung versucht openUTM nicht eine Verbindung aufzubauen.

Für Clients mit PTYPE=UPIC-R und UPIC-L ist nur die Angabe CONNECT=NO erlaubt.

Standard: NO

Unix- und Linux-Systeme:
Für Drucker wird bei CONNECT=NO kein Druckerprozess erzeugt. Der Druckerprozess wird erst durch das Administrationskommando KDCPTERM ACT=C (oder KDCLTERM für den zugeordneten LTERM-Partner) eingerichtet. Dieser kann von den Workprozessen Druckaufträge entgegennehmen, die für die entsprechende Spool Queue bestimmt sind.

ENCRYPTION-LEVEL=

Nur relevant für UPIC-Clients, 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 dem Client fest. Sie geben an, ob die UTM-Anwendung auf der Verbindung zum Client die Verschlüsselung der Nachrichten fordern soll oder nicht. Sie können den Client aber auch als „trusted“ Client definieren. Zur Verschlüsselung siehe auch Abschnitt "Nachrichten-Verschlüsselung auf Verbindungen zu Clients".

Für die Verschlüsselung der Daten auf Verbindungen zum Client muss der Client ein openUTM-Client mit Trägersystem UPIC sein und mit Verschlüsselungsfunktionen ablaufen.

Standardwerte:

TRUSTED ist der Standardwert für:

HTTP-Clients und USP-Socket-Anwendungen, die sich über einen Transportsystemzugriffspunkt (BCAMAPPL) anschließen, der mit T-PROT=(..., SECURE) generiert ist.
Lokale UPIC-Clients (PTYPE=UPIC-L) auf Unix-, Linux- und Windows-Systemen

Andere Werte für diese Partner werden von KDCDEF ohne Meldung in TRUSTED geändert.

NONE ist der Standardwert für

alle andere Partnertypen.

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.

BS2000-Systeme:
VTSU-B >= V12.0C ist Voraussetzung für den Einsatz der Verschlüsselung auf Verbindungen zwischen openUTM und Terminal-Emulationen.

Folgende Angaben sind möglich:

NONE

Die Verschlüsselung der Nachrichten, die zwischen dem Client und der UTM-Anwendung ausgetauscht werden, wird von openUTM nicht standardmäßig 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 ENCRYPTION-LEVEL in der TAC-Anweisung im Abschnitt "TAC - Eigenschaften von Transaktionscodes und TAC-Queues festlegen"), können von diesem Client nur gestartet werden, wenn der Client beim Conversation- bzw. Verbindungsaufbau die Verschlüsselung aushandelt.

3 | 4 | 5

Die Verschlüsselung der Nachrichten, die zwischen dem Client und der UTM-Anwendung ausgetauscht werden, wird von openUTM standardmäßig angefordert. Der Wert gibt die Verschlüsselungsebene an. Der Client kann sich nur anschließen, wenn er mindestens diese Verschlüsselungsebene unterstützt. Andernfalls lehnt openUTM den Verbindungsaufbau zum Client ab.

Die Werte haben folgende Bedeutung:

3

Passworte und Ein-/Ausgabe-Nachrichten werden mit dem AES-CBC Algorithmus verschlüsselt. Zum Austausch des AES-Schlüssels wird ein RSA-Schlüssel mit einer Schlüssellänge von 1024 Bits verwendet.

4

Passworte und Ein-/Ausgabe-Nachrichten werden mit dem AES-CBC Algorithmus verschlüsselt. Zum Austausch des AES-Schlüssels wird ein RSA-Schlüssel mit einer Schlüssellänge von 2048 Bits verwendet.

5

Ein-/Ausgabe-Nachrichten werden mit dem 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üssel ein RSA-Schlüssel mit einer Schlüssellänge von 2048 Bits verwendet.

Der Level 5 wird von openUTM z.Zt. nur für Únix-, Linux- und Windows-Systeme unterstützt.

BS2000-Systeme:
Für VTSU-Partner wird die Verschlüsselung von VTSU durchgeführt. (siehe Handbuch "Security Handbook for Systems Support")

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

Der Client ist ein vertrauenswürdiger „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 TAC ENCRYPTION-LEVEL= 2 | 5).

TRUSTED sollte nur gewählt werden, wenn die Kommunikation zum Client über eine sichere Verbindung abgewickelt wird.

IDLETIME=

time

Darf nur für Dialog-Partner angegeben werden.
In time geben Sie die Zeit in Sekunden an, 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)
Maximalwert: 32767
Minimalwert: 60

Geben Sie einen Wert an, der kleiner als der Minimalwert ist, dann ersetzt KDCDEF den Wert durch den Minimalwert.

LISTENER-PORT=

number

Portnummer für den Aufbau von TCP/IP-Verbindungen.

Bei Socket-Anwendungen (T-PROT=SOCKET) ist LISTENER-PORT= Pflichtoperand.

Es sind alle Portnummern zwischen 1 und 65535 erlaubt.

BS2000-Systeme:
Auf BS2000-Systemen darf LISTENER-PORT= nur für Partner mit PTYPE=APPLI oder PTYPE=SOCKET angegeben werden. Bei PTYPE=SOCKET ist LISTENER-PORT Pflichtoperand.

Für number ist die Portnummer anzugeben, an der die Partner-Anwendung auf Verbindungsaufbauwünsche wartet, d.h. die Portnummer innerhalb des Partner-Rechners, über die die Partner-Anwendung adressiert wird.

Eine Portnummer ungleich null darf nur angegeben werden, wenn die im Parameter BCAMAPPL= angegebene lokale Anwendung nicht mit T-PROT=NEA generiert ist.

Standard: 0 (d.h. keine Portnummer)
In diesem Fall verwendet das Transportsystem den Standardport 102.

Unix-, Linux- und Windows-Systeme:
LISTENER-PORT ist nur relevant für TS-Anwendungen (PTYPE=SOCKET oder APPLI).

Der LISTENER-PORT wird bei T-PROT=SOCKET verwendet, um festzulegen, mit welcher Portnummer der Partner adressiert wird. Weitere Adressierungsinformationen sind unnötig.

Standard: 0 (keine Portnummer)

Bei OPTION CHECK-RFC1006=YES muss für PTERMs mit PTYPE=APPLI bei LISTENER-PORT eine Portnummer angegeben werden.

LTERM=

ltermname

Name des LTERM-Partners, der dem Client/Drucker ptermname zugeordnet wird und über den sich der Client/Drucker an die UTM-Anwendung anschließt. ltermname ist max. 8 Zeichen lang.

Bei Clients vom Partnertyp PTYPE=SOCKET, APPLI oder UPIC-R muss der Operand LTERM= versorgt werden!

Die Zuordnung zwischen Client/Drucker und LTERM-Partner kann per Administrationskommando KDCSWTCH im Betrieb geändert werden, z.B. beim Ausfall eines Druckers. Es ist aber nicht möglich einem Drucker beispielsweise einen Dialog-LTERM-Partner (LTERM USAGE=D) zuzuordnen.

BS2000-, Unix- und Linux-Systeme:
Für die Funktion Druckerbündel schreiben Sie mehrere PTERM-Anweisungen mit demselben ltermname. Ein Druckerbündel besteht damit aus mehreren Druckern, die einem LTERM-Partner zugeordnet sind (siehe auch Abschnitt "Druckerbündel generieren (BS2000-, Unix- und Linux-Systeme)"). openUTM verteilt die Druckaufträge dabei zyklisch an die Drucker des Bündels.

MAP=

steuert die Code-Konvertierung (EBCDIC <-> ASCII) für die Benutzer-Nachrichten, die zwischen den Kommunikationspartnern ausgetauscht werden.
Benutzer-Nachrichten werden an der KDCS-Schnittstelle bei den Aufrufen zur Nachrichtenbehandlung (MPUT/MGET/FPUT/DPUT) im Nachrichtenbereich übergeben.

USER

UTM konvertiert die Daten des Nachrichtenbereichs nicht, d.h. die Nachrichten werden unverändert zwischen den Kommunikationspartnern übertragen.
Dabei ist zu beachten, dass bei TS-Anwendungen (Partner mit PTYPE=SOCKET oder APPLI) der Transaktionscode in der Benutzer-Nachricht enthalten ist. Er muss so kodiert sein wie ihn die UTM-Anwendung erwartet, d.h. auf BS2000-Systemen in EBCDIC und auf Unix-, Linux- und Windows-Systemen in ASCII.

Standard: USER

SYSTEM | SYS1 | SYS2 | SYS3 | SYS4

Diese Parameter sind nur für folgende Partner zulässig:

BS2000-Systeme: Partner mit PTYPE=SOCKET.
Unix-, Linux- und Windows-Systeme: Partner mit PTYPE=SOCKET oder APPLI.

UTM konvertiert die Benutzer-Nachrichten gemäß den für die Code- Konvertierung bereitgestellten Konvertierungstabellen (siehe Abschnitt "Code-Konvertierung"), 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 SYSTEM und SYS1 sind synonym.

Dabei geht UTM davon aus, dass die Nachrichten nur abdruckbare Zeichen enthalten.

PRONAM=

{ 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.

Enthält processorname Sonderzeichen, muss er als Zeichenkette mit C’...’ angegeben werden.

BS2000-Systeme:
Wenn ein RSO-Drucker beschrieben wird (PTYPE=*RSO), muss als Rechnername *RSO angegeben werden.

Für Clients, die sich über OMNIS direkt anschließen, d.h. ohne Multiplex-Verbindung, müssen Sie PRONAM=omnis-host angeben wobei omnis-host der Rechner ist, auf dem OMNIS geladen ist.

Pflichtoperand.

Unix-, Linux- und Windows-Systeme:
Auf Unix-, Linux- und Windows-Systemen darf PRONAM nur für remote UPIC-Clients (PTYPE=UPIC-R) und TS-Anwendungen (PTYPE=SOCKET oder APPLI) angegeben werden.

Es wird nicht zwischen Groß- und Kleinschreibung unterschieden; KDCDEF setzt den Namen des Partner-Rechners immer in Großbuchstaben um.

Die Angabe von processorname ist Pflicht für PTYPE=APPLI, SOCKET oder UPIC-R.

Standardwert für PTYPE=TTY, UPIC-L oder PRINTER: Leerzeichen

PROTOCOL=

Dieser Operand gilt nur für BS2000-Systeme.

Benutzerdienstprotokoll, das auf den Verbindungen zwischen der UTM-Anwendung und dem Client/Drucker gefahren werden soll.

N

Zwischen der UTM-Anwendung und dem Client/Drucker wird ohne Benutzerdienstprotokoll gearbeitet.

Für UPIC-Clients (PTYPE=UPIC-R), TS-Anwendungen (PTYPE=SOCKET oder APPLI) oder Drucker, die über RSO angesprochen werden (PTYPE=*RSO), muss PROTOCOL=N gesetzt werden.

Clients mit PROTOCOL=N können sich nicht über eine Multiplexverbindung
(MUX-Anweisung) an die UTM-Anwendung anschließen.

Für Clients, die sich über OMNIS direkt anschließen, d.h. ohne Multiplex-Verbindung, muss PROTOCOL=N generiert werden.

Haben Sie PTYPE=*ANY angegeben, dann ignoriert openUTM die Angabe PROTOCOL=N. openUTM setzt automatisch PROTOCOL=STATION ein.

Standard: bei PTYPE=SOCKET, APPLI, UPIC-R oder *RSO

STATION

Zwischen der UTM-Anwendung und dem Client/Drucker wird mit dem Benutzerdienstprotokoll (NEABT) gearbeitet.

Für Clients, die mit PTYPE=*ANY generiert sind, ist nur die Angabe PROTOCOL=STATION erlaubt. openUTM benötigt in diesem Fall das Benutzerdienstprotokoll (NEABT) zur Bestimmung des Gerätetyps des Clients oder Druckers.

Für UPIC-Clients (PTYPE=UPIC-R), TS-Anwendungen (PTYPE=APPLI oder SOCKET) oder Drucker, die über RSO angesprochen werden (PTYPE=*RSO), ist nur die Angabe PROTOCOL=N erlaubt. Die Angabe von PROTOCOL=STATION wird ignoriert.

Standard: STATION bei PTYPE!=SOCKET, APPLI, UPIC-R oder *RSO

PTYPE=

Typ des Kommunikationspartners

PTYPE auf BS2000-Systemen:

partnertyp

Pflichtoperand auf BS2000-Systemen

Für PTYPE müssen Sie entweder den Partnertyp partnertyp des Clients/Druckers oder den Wert *ANY oder den Wert *RSO für RSO-Drucker angeben.

partnertyp gibt explizit den Typ des Kommunikationspartners, d.h. des Clients oder Druckers, an. Der in partnertyp angegebene Wert muss mit dem Typ übereinstimmen wie er z.B. in der verwendeten Terminalemulation eingestellt wurde. Der Parameter PTYPE muss entweder hier angegeben oder in der DEFAULT-Anweisung explizit mit einem Wert vrsorgt werden. Die unterstützten Partnertypen entnehmen Sie der folgenden Tabelle:

https://edsys.g02.fujitsu.local:8443/pages/editpage.action?pageId=58909895#

Partner	PTYPE	TERMN
DSS 9748	T9748 ¹	FE
DSS 9749	T9749	FE
DSS 9750	T9750¹	FE
DSS 9751	T9751	FE
DSS 9752	T9752	FF
DSS 9753	T9753	FE
DSS 9754	T9754	FI
DSS 9755	T9755²	FG
DSS 9756	T9756²	FG
DSS 9763	T9763	FH
DSS 9770	T9770	FK
DSS 9770R	T9770R	FK
FHS-DOORS-Frontend	DSS-FE	FH
DSS 3270 (IBM)	T3270	FL
DSS X28 (TELETYPE)	THCTX28	C5
DSS X28 (VIDEO)	TVDTX28	C6
Datenstation PT80	TPT80	C4
Drucker 9001	T9001	C7
Drucker 9002	T9002	FA
Drucker 9003	T9003	F9
Drucker 9004	T9004	FD
Drucker 9001-3	T9001-3	CA
Drucker 9001-893	T9001-893	CB
Drucker 9011-18	T9011-18	CC
Drucker 9011-19	T9011-19	CD
Drucker 9012	T9012	CE
Drucker 9013	T9013	C9
Drucker 9021	T9021	CH
Drucker 9022	T9022	CF
Drucker 3287	T3287	CG
Transportsystem-Anwendung, die keine Socket-Anwendung ist, z.B. DCAM-, CMX- oder UTM-Anwendung	APPLI	A1
Inteligente Datenstation	THOST	A3
UPIC-Client	UPIC-R	A5
USP Socket-Anwendung	SOCKET	A7
HTTP-Client	SOCKET	A8
Secure USP Socket-Anwendung	SOCKET	A9
HTTPS-Client	SOCKET	AA

¹ Die PTYPEs T9748 und T9750 bezeichnen den gleichen Terminaltyp.

² Die PTYPEs T9755 und T9756 bezeichnen den gleichen Terminaltyp.

In welcher VTSU-Version die einzelnen Terminals unterstützt werden, ist dem DCAM-, FHS- bzw. TIAM-Handbuch zu entnehmen. Wird ein Terminal von VTSU nicht unterstützt, so weist openUTM einen Verbindungsaufbau von diesem Terminal zurück. openUTM erzeugt die Meldungen K064 und K107.

*ANY

Durch die Angabe von PTYPE=*ANY wird ein VTSU-Client generiert. Der Client/Drucker wird ohne genaue Angabe des Gerätetyps in die Konfiguration aufgenommen. openUTM nimmt den Gerätetyp des Clients/Druckers 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.

Wenn für Clients, die mit PTYPE=*ANY definiert wurden, explizit keine Terminalmnemonics generiert werden (Operand TERMN), wird beim Verbindungsaufbau die Standard-Terminalmnemonic des Partnertyps genommen.

*RSO

Mit PTYPE=*RSO können Drucker über RSO unterstützt werden. Anstatt eine Transportverbindung aufzubauen, reserviert openUTM den Drucker bei RSO und übergibt die zu druckende Nachricht an RSO.

PTYPE auf Unix-, Linux- und Windows-Systemen:

partnertyp

gibt explizit den Typ des Kommunikationspartners an, d.h. des Clients oder Druckers. Für partnertyp können Sie folgende Werte angeben:

Partner	PTYPE	TERMN
Terminal	TTY	F1
PRINTER (nur Unix- und Linux-Systeme)	PRINTER	F2
PRINTER, printertype, class (nur Unix- und Linux- Systeme)	PRINTER	F3
Transportsystem-Anwendung, die nicht die Socket-Schnittstelle benutzt (z.B. UTM-, CMX-, DCAM- Anwendung).	APPLI	A1
lokaler UPIC-Client	UPIC-L	A2
ferner (remote) UPIC-Client	UPIC-R	A5
USP-Socket-Anwendung	SOCKET	A7
HTTP-Client	SOCKET	A8
Secure USP Socket-Anwendung	SOCKET	A9
Secure HTTP-Client	SOCKET	AA

Standard: TTY

PRINTER

Drucker ohne Zusatzparameter.
Für die Ausgabe der Daten ruft der Druckerprozess (utmprint) das Skript utmlp auf. Beim Aufruf werden zusätzlich zu den auszudruckenden Daten Parameter an utmlp übergeben. utmlp übergibt dann standardmäßig die Daten an das Kommando lp, siehe Hinweise zum Skript utmlp im Abschnitt "PTERM - Eigenschaften von Clients und Druckern und Zuordnung zum LTERM-Partner festlegen".

(PRINTER, printertype,[class]) (nur auf Unix- und Linux-Systemen)

Drucker mit erweiterten Parametern.
Für die Ausgabe der Daten ruft der Druckerprozess (utmprint) das Skript utmlp auf. Beim Aufruf werden zusätzlich zu den auszudruckenden Daten die erweiterten Parameter an utmlp übergeben. utmlp übergibt die Daten mit dem Wert von class als destination an das Kommando lp (Hinweise zum Skript utmlp siehe unten).

printertype
bezeichnet den Druckertyp, für den Druckausgaben bestimmt sind. Sind Sonderzeichen im Parameterwert von printertype enthalten, müssen Sie den Wert in einfache Hochkommata einschließen.
Maximale Länge von printertype: 8 Zeichen

class
Name der Druckergruppe (printer class). Enthält der Name der Druckergruppe Sonderzeichen, müssen Sie den Wert in einfache Hochkommata einschließen.
Maximale Länge: 40 Zeichen
Standardwert: Wert von ptermname

Hinweise zum Skript utmlp:

Das Skript utmlp wird mit openUTM ausgeliefert. Sie finden es im Verzeichnis $UTMPATH/shsc.
Die Parameter, die abhängig von der PTERM-Anweisung an das Skript utmlp übergeben werden, sind im Skript selbst dokumentiert.
Der Zugriff auf das Skript erfolgt zur Laufzeit über $PATH.
Sie können das Skript editieren, um z.B. die Nachricht vor dem Ausdrucken anzupassen oder über das Netzwerk zu drucken.
Bei erfolgreicher Verarbeitung liefert das Skript den Exitcode 0 (Null).Bei einem Exitcode ungleich 0 wird die Verbindung zum Druckerprozess beendet und nach einem erneuten Verbindungsaufbau die Ausgabe wiederholt.
Alle Systeme:
Bei Clients vom Typ APPLI, SOCKET oder UPIC-R kann es vorkommen, dass eine Verbindung zu einem Client aus Sicht von openUTM noch besteht, der Client aber keine Verbindung mehr zur Anwendung hat und deshalb versucht, sie neu aufzubauen. Dazu sendet er einen Connection Request an openUTM. openUTM baut daraufhin die „bestehende“ Verbindung ab.
Für Clients vom Typ APPLI oder SOCKET initiiert openUTM anschließend automatisch den Aufbau einer neuen Verbindung. Für UPIC-Clients muss die Initiative zum Aufbau einer neuen Verbindung vom UPIC-Client ausgehen.

STATUS=

gibt an, ob der Client/Drucker beim Anwendungsstart gesperrt ist.

ON

Der Client oder Drucker ist nicht gesperrt. Sofern der LTERM-Partner, über den sich der Client/Drucker an die UTM-Anwendung anschließt, nicht gesperrt ist, können Verbindungen aufgebaut werden oder es bestehen bereits Verbindungen.

Standard: ON

OFF

Der Client oder Drucker ist gesperrt. Es können keine Verbindungen zwischen Client/Drucker und lokaler Anwendung aufgebaut werden. Der Administrator kann den Client/Drucker freigeben.

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 Standard-Kennzeichen sind der Partnertyp-Tabelle beim Operanden PTYPE im Abschnitt "PTERM - Eigenschaften von Clients und Druckern und Zuordnung zum LTERM-Partner festlegen" zu entnehmen.

BS2000-Systeme:
Wird TERMN bei Clients, die mit PTYPE=*ANY generiert sind, nicht explizit angegeben, dann trägt openUTM das Kennzeichen für die Terminalmnemonic erst beim Aufbau der Verbindung in KCTERMN ein. Es wird die Standard-Terminalmnemonic des Typs eingetragen, der im Benutzerdienstprotokoll der Verbindungsanforderung enthalten ist.

T-PROT=

Dieser Operand gilt nur für Unix-, Linux- und Windows-Systeme.

Adressformat, mit dem sich der Client beim Transportsystem anmeldet. Ist nur relevant bei PTYPE=SOCKET, APPLI und UPIC-R.

Informationen zu den folgenden Adressformaten siehe Abschnitt "Dokumentation zu PCMX" (openUTM-Dokumentation).

RFC1006

Adressformat RFC1006

SOCKET

Die Kommunikation erfolgt über die Socket-Schnittstelle.
SOCKET darf nur angegeben werden, wenn der Name der lokalen UTM-Anwendung, den Sie in BCAMAPPL angeben, mit T-PROT=SOCKET generiert ist.
Die Angabe einer Portnummer im Operanden LISTENER-PORT ist Pflicht.

Der Standardwert für T-PROT ist abhängig von der Angabe bei PTYPE:

T-PROT=RFC1006, falls PTYPE=APPLI oder UPIC-R
T-PROT=SOCKET, falls PTYPE=SOCKET

TSEL-FORMAT=

Dieser Operand gilt nur für Unix-, Linux- und Windows-Systeme.

Formatindikator des T-Selektors in der Transportadresse des Client.
Ist nur relevant bei PTYPE=SOCKET, APPLI oder UPIC-R.

Der Formatindikator gibt die Codierung des T-Selektors im Transportprotokoll an. Nähere Informationen siehe Abschnitt "Dokumentation zu PCMX" (openUTM-Dokumentation).

T

TRANSDATA-Format

E

EBCDIC-Zeichenformat

A

ASCII-Zeichenformat

Für den Betrieb über RFC1006 wird empfohlen, explizit einen Wert für TSEL-FORMAT anzugeben.

USAGE=

Dieser Operand gilt nur für BS2000-Systeme.

gibt an, ob der Kommunikationspartner ein Dialog-Partner oder ein reines Ausgabemedium ist.

D

Der Client ist ein Dialog-Partner. Auf den Verbindungen zwischen Client und lokaler Anwendung kann sowohl die Anwendung als auch der Client Nachrichten senden.

UPIC-Clients (PTYPE=UPIC-R) sind immer Dialog-Partner.

Ein LTERM-Partner mit USAGE=D darf nicht einem Client mit USAGE=O zugewiesen werden.

Standard: bei PTYPE=SOCKET, APPLI, UPIC-R oder einem Terminal.

O

Der Kommunikationspartner ist ein Drucker. Es können nur Nachrichten von der Anwendung zum Drucker gesendet werden.

Standard:
Für Partner, die mit PTYPE=*RSO generiert sind, darf nur USAGE=O generiert werden.

USP-HDR=

Mit diesem Parameter wird gesteuert, für welche Ausgabe-Nachrichten openUTM auf dieser Verbindung einen UTM-Socket-Protokoll-Header aufbauen soll.
Eine Beschreibung des USP-Headers finden Sie im openUTM-Handbuch „Anwendungen programmieren mit KDCS“.

Dieser Parameter ist nur von Bedeutung für PTERMs mit PTYPE=SOCKET.

NO

openUTM erzeugt für keine Ausgabe-Nachricht einen UTM-Socket-Protokoll-Header.

Standard.

MSG

Nur bei der Ausgabe von K-Meldungen erzeugt openUTM einen UTM-Socket-Protokoll-Header und stellt diesen der Nachricht voran.

ALL

Bei allen Ausgabe-Nachrichten (Dialog, Asynchron, K-Meldungen) erzeugt openUTM einen UTM-Socket-Protokoll-Header und stellt diesen der Nachricht voran.

Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly

PTERM - Eigenschaften von Clients und Druckern und Zuordnung zum LTERM-Partner festlegen