The PTERM control statement allows you to define the properties of a physical client or printer of the UTM application.
Clients are terminals, UPIC clients and transport system applications. Transport system applications (for short TS application) are understood to be all applications that are generated as PTYPE=APPLI or PTYPE=SOCKET. See also the PTYPE operand in the table in section "PTERM - define the properties of a client/printer and assign an LTERM partner" (BS2000 systems) or "PTERM - define the properties of a client/printer and assign an LTERM partner" (Unix, Linux and Windows systems).
You must always issue a PTERM statement for clients when connections to the client or printer are to be established from the local UTM application.
The PTERM statement allows you to assign an LTERM partner defined using the LTERM statement to the client/printer. A separate LTERM statement must be written for each client or printer (see also "LTERM - define an LTERM partner for a client or printer" for more information on this subject).
If desired, you can first define the client/printer in a PTERM statement and then assign it to an LTERM partner later on during operation by means of dynamic administration. Exceptions are UPIC clients and TS applications. You need to assign an LTERM partner to these immediately.
If LTERM pools have not been generated (TPOOL statement, see "TPOOL - define an LTERM pool"), you must assign a client in the LTERM= operand of at least one PTERM statement. Only then can a connection be established in order to access the application.
Printers are not supported by openUTM on Windows systems.
Address of the client or printer
For the application to be able to establish connections to the partner application, you must specify the partner address. The following operands are used to do this:
ptermname (name/T-selector of the communication partner)
PRONAM (name of the host partner)
On Unix, Linux and Windows systems, the name of the partner processor may only be specified if the partner is a remote UPIC client (UPIC-R) or a TS application (PTYPE= APPLI or SOCKET).LISTENER-PORT (TCP/IP port number).
On BS2000 systems, LISTENER-PORT may only be specified with PTYPE=APPLI and PTYPE=SOCKET.
The following operands are used for further definition of the partner address on Unix, Linux and Windows systems:
T-PROT (address format for the transport protocol used)
TSEL-FORMAT (format identifier of the T-selector)
See section "Providing address information for the CMX transport system (Unix, Linux and Windows systems)" for more information or section "Providing address information for the SOCKET transport system (Unix, Linux and Windows systems)".
If the connection to a TS application is to be established via the socket interface with native TCP/IP as the transport protocol, then you must specify the computer on which the TS application will run in PRONAM and the port number on the host partner on which the TS application waits for requests to establish a connection from the network in LISTENER-PORT. You must specify an application name that was generated for T-PROT=SOCKET in BCAMAPPL (see also "BCAMAPPL - define additional application names").
You can specify whether or not openUTM is to handle code conversion in the MAP operand.
Uniqueness of names
When generating the CON, PTERM and MUX statements, please note that the name triplet (appliname or ptermname, processorname, local_appliname) must be unique within the generation run.
|
BS2000, Unix and Linux system specific operand
BS2000 specific operands
|
1This operand value is only permitted on BS2000 systems
2 These operand values are only permitted on Unix, Linux, and Windows systems
ptermname | Name of the client or printer up to 8 characters in length The specified name must be unique and must not be assigned to any other object in name class 3. See also section "Uniqueness of names and addresses" The following cases can arise: Socket applications (PTYPE=SOCKET)
BS2000 systems: Unix, Linux or Windows systems: In the case of printers, ptermname is the name of the spool queue or printer group as defined during generation of the Unix or Linux system. To output the data, the printer process (utmprint) calls the utmlp script (see PTYPE=PRINTER on "PTERM - define the properties of a client/printer and assign an LTERM partner"). In the case of local terminals and pseudo terminals, the result of the command On Unix and Linux systems, the default ptermname assigned by openUTM may not be unique. Depending on the type of network to which the system is connected, it is possible to have two or more pseudo terminals for which the last term of the tty (after the last slash) is identical. Only one terminal can use this ptermname to establish a connection with the application. The connection request from the second terminal will be rejected by openUTM. Example The system contains the ttys You can also generate an LTERM pool with PTYPE=TTY instead. Windows systems: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
BCAMAPPL= | local_appliname Name of the local UTM application as defined in MAX ...,APPLINAME= or the BCAMAPPL statement (see also "BCAMAPPL - define additional application names"). When establishing a connection between the client/printer and the UTM application, local_appliname must be specified as the partner name. In the case of terminals and printers, the name defined in MAX ...,APPLINAME= must be used here. For PTERMs with PTYPE=SOCKET you must specify a name in local_appliname that is generated using BCAMAPPL ... T-PROT=SOCKET. The BCAMAPPL name specified in the CLUSTER statement is not permitted here. Default value: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
CID= | printer_id This operand is only supported on BS2000, Unix and Linux systems. This applies only for printers assigned to a printer control LTERM. printer_id is used to identify the printers at the printer control LTERM, and can be up to eight characters in length. The printer control LTERM is used to manage printers, printer queues and print jobs. If the printer is assigned an LTERM partner for which a printer control LTERM has been defined using LTERM ...,CTERM=ltermname2, the printer itself is also assigned to this printer control LTERM. The combination of ltermname2 of the printer control LTERM and CID must be unique. Default: A CID is not assigned to the printer | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
CONNECT= | Specifies whether or not openUTM establishes a connection to the client or printer when starting the application.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
YES | When starting the application, openUTM automatically attempts to establish a connection. In the case of printers generated with LTERM ...,PLEV > 0, openUTM does not attempt to establish the logical connection until the PLEV value is exceeded. If a connection cannot be established to a printer or TS application, openUTM makes repeated attempts to establish the connection at intervals defined in MAX ...,CONRTIME. BS2000 systems: Unix and Linux systems: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
NO | When starting the application, openUTM does not attempt to establish a connection. CONNECT=NO must be specified for clients with PTYPE=UPIC-R and UPIC-L. Default: NO Unix and Linux systems: A printer process is not created for ptermname. This can only be achieved by issuing the administration command KDCPTERM ACT=C (or KDCLTERM for the assigned LTERM partner). The printer process can then accept print jobs from work processes, which are directed to the appropriate spool queue. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ENCRYPTION-LEVEL= | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Only relevant for UPIC clients that support encryption and on BS2000 systems for some terminal emulations that support encryption also. In ENCRYPTION-LEVEL you set the minimum encryption level for the communication with the client. The client must be a openUTM-Client with the UPIC carrier system and with encryption functions to be able to encrypt data on the connection to the client. Default values: TRUSTED is the default value for:
Other values for these partners are changed to TRUSTED by KDCDEF without issuing a message. NONE is the default value for
For partners with PTYPE different from UPIC-R, and on BS2000 different from T9763, the values 3, 4, 5 are changed to NONE by KDCDEF without issuing a message. BS2000 systems: You can specify the following: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
NONE | Encryption of the messages exchanged between the client and the UTM application is not requested by openUTM by default. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
3 | 4 | 5 | Encryption of the messages exchanged between the client and the UTM application is requested by openUTM by default. The value specifies the encryption level. The client cannot connect unless it supports at least this encryption level. Otherwise openUTM rejects connection setup. The values have the following meaning: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
3 | Passwords and input/output messages are encrypted using the AES-CBC algorithm. An RSA key with a key length of 1024 bits is used to exchange the AES key. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
4 | Passwords and input/output messages are encrypted using the AES-CBC algorithm. An RSA key with a key length of 2048 bits is used to exchange the AES key. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
5 | Input/output messages are encrypted using the AES-GCM algorithm. The AES key is agreed using the Ephemeral Elliptic Curve Diffie-Hellman method (ECDHE). An RSA key with a key length of 2048 bits is used to sign the public server key. Level 5 is currently only supported by openUTM for LUW platforms. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
BS2000 systems: If the application is generated with OPTION GEN-RSA-KEYS=NO, no RSA keys are created in the KDCDEF run. In order to use the encryption functions, you must create the required keys using administration facilities (KC_ENCRYPT or WinAdmin or WebAdmin) or transfer them from an old KDCFILE using KDCUPD. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
TRUSTED | The client is a "trusted" client. TRUSTED should only be selected if the client communication is conducted through a secure connection. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
IDLETIME= | time May only be specified for dialog partners. This function serves to improve data security: If a user forgets to sign off from the terminal when taking a break or when finishing his or her work on the terminal, then the connection to the terminal or client is automatically cleared down after the wait time has run out. This reduces the chance of someone gaining unauthorized access to the system. Default: 0 (= no wait time limit) If you specify a value that is greater than zero and smaller than the minimum value, KDCDEF replaces the value with the minimum value. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
LISTENER-PORT= | number Port number for establishing TCP/IP connections With socket applications (T-PROT=SOCKET) the LISTENER-PORT= is a mandatory operand. All port numbers between 1 and 65535 are allowed. BS2000 systems: For number you must specify the port number on which the partner application waits for requests to establish a connection, i.e. the port number on the host partner through which the partner application is addressed. A port number that is not equal to 0 may only be specified if the local application specified in the parameter BCAMAPPL is not generated with T-PROT=NEA. Default: 0 (i.e. no port number) Unix, Linux and Windows systems: The LISTENER-PORT is used with T-PROT=SOCKET to specify the port number used to address the partner. No other addressing information is necessary. Default: 0 (no port numbers) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
LTERM= | ltermname Name of the LTERM partner assigned to the client/printer ptermname. This name is used by the client/printer to sign on to the UTM application, and can be up to eight characters in length. The LTERM operand is mandatory for clients with PTYPE=SOCKET, APPLI and UPIC-R. The LTERM partner assigned to a client/printer can be changed during runtime using the KDCSWTCH administration command, e.g. if the printer fails. However, it is not possible to assign a dialog LTERM partner (LTERM USAGE=D) to a printer. For the printer pool function, you must issue several PTERM statements with the same ltermname. A printer pool consists of numerous printers assigned to a single LTERM partner (see also section "Generating printer pools"). openUTM then distributes print jobs cyclically to the various printers in the pool. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
MAP= | Controls the code conversion (EBCDIC <-> ASCII) for user messages exchanged between communication partners. User messages are passed in the message area on the KDCS interface in the message handling calls (MPUT/MGET/FPUT/DPUT/FGET). | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
USER | openUTM does not convert the data of the message area, i.e. the messages are transferred between the partner applications unchanged. Default: USER | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SYSTEM | SYS1 | SYS2 | SYS3 | SYS4 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
This parameter is only permitted for the following partners: BS2000 systems: partners with PTYPE=SOCKET Unix, Linux and Windows systems: partners with PTYPE=SOCKET or APPLI UTM converts the user messages based on the conversion tables provided for the code conversion (see section "Code conversion"), i.e.: Prior to sending, the code is converted from ASCII to EBCDIC on Unix, Linux and Windows systems and from EBCDIC to ASCII on BS2000 systems. After receipt, the code is converted from EBCDIC to ASCII on Unix, Linux and Windows systems and from ASCII to EBCDIC on BS2000 systems. The specifications SYSTEM and SYS1 are synonymous. UTM assumes that the messages contain only printable characters. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
PRONAM= | { processorname | C’processorname’ } Name of the partner computer. The complete name (FQDN) by which the computer is known in the DNS must be specified. The name can be up to 64 characters long. If processorname contains special characters it must be entered as a character string using C’...’. BS2000 systems: This name is defined during generation of the network. Please consult your network administrator. The assignment of ptermname to processorname must be unique. If a TS application is described with which the UTM application communicates via the socket interface, then you must specify the symbolic address of the host partner for processorname. The association of the symbolic address to the real IP address must be entered in the name service of the local system (in the RDF file). You must not specify an alias of the host. When defining an RSO printer (PTYPE=*RSO), you must specify *RSO here. In the case of clients connecting directly via OMNIS, i.e without mulitplex connection, you must specify PRONAM=omnis-host where omnis-host is the host on which OMNIS is loaded. This is a mandatory operand. PRONAM need not be specified if a default value for this operand is defined beforehand using the DEFAULT statement. Unix, Linux and Windows systems: On Unix, Linux and Windows systems PRONAM= is permitted only for remote UPIC clients (PTYPE=UPIC-R) and TS applications (PTYPE=SOCKET or APPLI). For processorname, you enter the real host name under which the IP address of the partner computer is entered in the name service of the local system (e.g. the hosts file) see "Specifying computer names in KDCDEF generation". You must not specify alias names of the computer. No distinction is made between uppercase and lowercase notation; KDCDEF always converts the name of the partner computer into uppercase. processorname is a mandatory operand for PTYPE=APPLI, SOCKET or UPIC-R. Default for PTYPE=TTY, UPIC-L or PRINTER: blanks | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
PROTOCOL= | User services protocol used on connections between the UTM application and the client/printer | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
N | A user services protocol is not used between the UTM application and the client/printer. PROTOCOL=N must be set for UPIC clients (PTYPE=UPIC-R), TS applications (PTYPE=SOCKET or APPLI) that communicate with the UTM application via the socket interface (native TCP/IP) and for printers accessed via RSO (PTYPE=*RSO). Clients with PROTOCOL=N cannot sign on to the UTM application via a multiplex connection (MUX statement). PROTOCOL=N must be specified for clients connecting directly via ONMIS (i.e. without multiplex connection). If you specify PTYPE=*ANY, openUTM ignores the entry PROTOCOL=N and automatically sets PROTOCOL=STATION. Default with PTYPE=SOCKET, APPLI, UPIC-R or *RSO. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
STATION | The user services protocol (NEABT) is used between the UTM application and the client/printer. PROTOCOL=STATION must be specified for clients generated with PTYPE=*ANY. In this case, openUTM requires the user services protocol (NEABT) to determine the device type of the client or printer. For UPIC clients (PTYPE=UPIC-R), TS applications (PTYPE=APPLI or SOCKET) or printers that are addressed via RSO (PTYPE=*RSO), you are only permitted to specify PROTOCOL=N. If you specify PROTOCOL=STATION it will be ignored. Default with PTYPE | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
PTYPE= | Type of communication partner | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| PTYPE on BS2000 systems: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| This is a mandatory operand on BS2000 systems. For PTYPE you must specify the partner type partnertyp of the client or | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
partnertyp | Type of communication partner, i.e. type of client or printer. The value specified in partnertyp must match to the type that has been set in the terminal emulation used, for example. The partner type must be entered either in the PTYPE parameter here, or using a DEFAULT statement. The following partner types are supported:
1)The PTYPEs T9748 and T9750 refer to the same terminal type. 2)The PTYPEs T9755 and T9756 refer to the same terminal type. The VTSU version in which the individual terminals are supported can be found in the respective DCAM, FHS and TIAM manuals. If a terminal is not supported by VTSU, openUTM rejects connection requests from this terminal and outputs UTM messages K064 and K107. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
*ANY | A PTYPE=*ANY entry generates a VTSU client. The client/printer is incorporated in the configuration without precise information on the device type. During connection setup, openUTM takes the device type from the user services protocol. Only then can it be determined whether or not the partner type is supported. The advantage of PTYPE=*ANY is that it allows you to include clients in the configuration without having to know how their type. The configuration is also easier to maintain, because even if the type is modified in the terminal emulation, for example, this client can still sign on to the application without having to modify the KDCDEF generation. If terminal mnemonics (TERMN operand) are not explicitly generated for clients defined with PTYPE=*ANY, the default terminal mnemonic of the partner type is used for connection setup. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
*RSO | If PTYPE=*RSO, support is provided for printers via RSO. Instead of establishing a transport connection, openUTM reserves the printer in RSO and transfers the message to be printed to RSO. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| PTYPE on Unix, Linux and Windows systems: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
partnertyp | Type of communication partner, i.e. type of client or printer. For partnertyp you can specify the following:
Default: TTY | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
PRINTER | Printer without additional parameters. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(PRINTER, printertype,[class]) (only on Unix and Linux systems) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Printer with extended parameters. printertype class Information on the utmlp script: The utmlp script is also supplied with openUTM. You will find it in the $UTMPATH/shsc directory. The parameters which are transferred to the script utmlp dependent on the PTERM statement are documented in the script itself. The script is accessed at runtime using the $PATH variable. You can edit the script to modify the message before printing or print it over the network, for example. If printing was successful, the script returns exit code 0 (null). If the script returns an exit code other than 0, then the connection to the printer process is cleared and another attempt is made to output the data once the connection has be reestablished. With clients of type APPLI,SOCKET or UPIC-R, it may appear to openUTM that a connection to the client still exists, even though the client is no longer actually linked to the application and therefore attempts to reestablish the connection. For this purpose, the client sends a connection request to openUTM, which causes openUTM to shut down the “existing” connection. With clients of type APPLI or SOCKET, openUTM then automatically initiates the setup of a new connection.For UPIC clients, the initiation to establish a new connection must be made by the UPIC client. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
STATUS= | Status (locked or unlocked) of the client/printer when the application is started. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ON | The client or printer is unlocked. If the LTERM partner used by the client/printer to sign on to the UTM application is not locked, connections can be establish or may already be in place. Default: ON | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
OFF | The client or printer is locked. Connections cannot be established between the client/printer and the local application. The client/printer can be released by the administrator. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
TERMN= | termn_id Identifier up to two characters in length, which indicates the type of client. openUTM provides this identifier to the application program in the KCTERMN field of the KB header. termn_id is not queried by openUTM, but can be used by the user for analysis purposes. Default values: If this operand is not specified, openUTM sets the KCTERMN field to the default ID of the partner type specified in the PTYPE operand. However, the user can select other values if desired. BS2000 systems: Unix, Linux and Windows systems: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
T-PROT= | This operand is only supported on Unix, Linux and Windows systems. The address format with which the OSI TP partner signs on to the transport system. Is only relevant for PTYPE=SOCKET, APPLI and UPIC-R. Information on the following address formats can be found in the section "PCMX documentation" (openUTM documentation). | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
RFC1006 | Address format RFC1006 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SOCKET | Communication is conducted via the socket interface. The default value for T-PROT depends on the PTYPE specification: T-PROT=RFC1006 when PTYPE=APPLI or UPIC-R | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
TSEL-FORMAT= | This operand is only supported on Unix, Linux and Windows systems. The format identifier of the T-selector in the transport address of the client. The format identifier specifies the coding of the T-selector in the transport | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
T | TRANSDATA format | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
E | EBCDIC format | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
A | ASCII format It is recommended to explicitly specify a value for TSEL-FORMAT for operation via RFC1006. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
USAGE= | This specifies whether the communication partner is a dialog partner or purely an output medium. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
D | The client is a dialog partner. Messages can be exchanged between the client and the local application in both directions. UPIC clients (PTYPE=UPIC-R) are always dialog partners. An LTERM partner with USAGE=D must not be assigned to a client with USAGE=O. This is the default value if PTYPE=SOCKET, APPLI, UPIC-R, and for terminals. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| O | The communication partner is a printer. Messages can only be sent from the application to the printer. Default: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
USP-HDR= | This parameter is used to control the output messages for which openUTM is to establish a UTM socket protocol header on this connection. This parameter is only relevant for PTERMs with PTYPE=SOCKET. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
NO | openUTM does not create a UTM socket protocol header for any of the output messages. Default. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
MSG | Only when outputting K messages does openUTM create and prefix the message with a UTM socket protocol header. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ALL | openUTM creates and prefixes all output messages (dialog, asynchronous, K messages) with a UTM socket protocol header. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||