To add a printer or client (i.e. a terminal, an UPIC client or a TS application) to the configuration, you must place the data structure kc_pterm_str in the data area in which you will pass the name, address and properties of the client or printer to UTM. The table below shows you how to supply the fields of the structure with data.
openUTM on Windows systems does not support any printers.
Field name 1 | Meaning | ||
m | pt_name[8]
| Name of the client or printer. The name may be up to 8 characters long. | |
Special features of communication via the socket interface: | |||
(m) | pronam_long[64]
| Name of the computer on which the client/printer is located. | |
The complete host name (FQDN) under which the host is known in the DNS has to be specified. The name can be up to 64 characters long. Instead of a 64 character FQDN name, a short local name (on BS2000 systems: BCAM name) of the partner computer may be used (max. 8 characters). In this case, it must be possible for the transport system to map the local name to an FQDN name or an IP address using external additional information (in BS2000 systems: FQDN file, in Unix, Linux or Windows systems: hosts file). | |||
If ptype='*RSO' on BS2000 systems, then pronam_long='*RSO' must be specified. | |||
If the connection to the partner is established through the socket interface (TCP-IP-APPLI, t_prot='T' protocol) you must specify the system’s symbolic address or the real host name in pronam_long. | |||
On Unix, Linux and Windows systems pronam_long may be specified only with ptype='UPIC-R', 'APPLI' or 'SOCKET'. openUTM uses the default value (blanks) for terminals and printers. | |||
o | bcamappl[8] | Name of the UTM application through which the connection between the UTM application and the client/printer is to be established. The application name must have been statically generated using a BCAMAPPL command or during the KDCDEF generation by defining it in MAX APPLINAME. | |
If the connection to the communication partner is to be established vie the SOCKET protocol, you must specify a BCAMAPPL name with t_prot='T'. | |||
Only on BS2000 systems: | |||
(m) | ptype[8] | Type of client/printer | |
The specification of a ptype is mandatory for UTM applications on BS2000 systems. | |||
It is not permissible to specify ptype='PRINTER' on Windows systems. | |||
o | ptype_fotyp[8] | Only relevant for printers (ptype = 'PRINTER') on Unix and Linux systems. | |
o | ptype_class[40]
| Only relevant for printers (ptype = 'PRINTER') on Unix and Linux systems. | |
(m) | lterm[8] | Name of the LTERM partner to be assigned to this client/printer. | |
For UPIC clients and TS applications (ptype = 'UPIC-R', 'APPLI' or 'SOCKET') lterm is a mandatory parameter. The LTERM partner specified must be created in the same transaction as the client. See "Changing the configuration dynamically" for more information. | |||
o | auto_connect | Specifies if the connection to the client/printer is to be established automatically when the application is started: | |
'Y' | UTM is to try to establish a connection to the client/printer every time the application is started. | ||
'N' | UTM is not to try automatically to establish the connection. | ||
For UPIC clients, only auto_connect='N' is allowed. | |||
o | state | Specifies if the client/printer is to be disabled at first after being added. | |
'Y' | The client/printer is not be disabled (ON). | ||
'N' | The client/printer is to be disabled (OFF). | ||
o | cid[8] | Only relevant for printers on BS2000, Unix and Linux systems. | |
o | map | Only relevant for TS applications (ptype = 'APPLI') or SOCKET-USP applications | |
In map you specify whether or not UTM is to perform a code conversion (EBCDIC <-> ASCII) for the user messages exchanged between the communication partners. User messages are transferred at the KDCS interface with the calls for message handling (MPUT/FPUT/DPUT) in the message area. | |||
'U' (USER) | |||
'S', '1' , '2', '3', '4'
If you specify one of these values, UTM converts the user messages according to the code tables provided for the code conversion, see the "Code conversion" section in the openUTM manual "Generating Applications", i.e.:
openUTM assumes that the messages contain only printable characters.In this case, the specifications 'S' and 'S1' are synonymous. For more information on code conversion, please refer to the openUTM manual „Programming Applications with KDCS”; keyword „code conversion“. | |||
o | termn[2]
| Code for the type of client/printer (terminal mnemonic). The code is a maximum of 2 characters long. Default values for termn can be found in the table in chapter "kc_pterm_str - Clients and printers" (section "BS2000 systems" or "Unix, Linux and Windows systems"). | |
o | protocol | Only on BS2000 systems: | |
'N' (NO): Do not use NEABT. | |||
'S' (STATION): Use NEABT. | |||
For clients connected through a multiplex connection, you must set protocol = 'S'. | |||
For UPIC clients, RSO printers and TS applications connected via the socket interface, you must set protocol = 'N'. In these cases, protocol = 'N' is ignored. | |||
o | usage_type | Only on BS2000 systems: | |
'D' for a dialog partner | |||
o | listener_port[5]
| You specify in listener_port the port number in the remote system at which the partner application awaits requests for connection establishment from outside. | |
On BS2000 systems, listener_port is only allowed in the case of ptype='APPLI' or 'SOCKET'. | |||
On Unix, Linux and Windows systems, listener_port is only relevant for t_prot='T' and 'R'. | |||
o | t_prot | Only relevant for clients of the type pttype='APPLI', 'SOCKET' or 'UPIC-R' on Unix, Linux and Windows systems. You specify the address format of the client’s transport address. Possible values are: | |
'R' | RFC1006, ISO transport protocol class 0 using TCP/IP and the | ||
'T' | Native TCP-IP transport protocol for communication via the socket interface (SOCKET) | ||
o | tsel_format
| Only relevant for clients of the type pttype='APPLI', 'SOCKET' or 'UPIC-R' on Unix, Linux and Windows systems. You specify the format of the T-selector for the client address. Possible values are: | |
'T': TRANSDATA format | |||
o | idletime[5] | May only be specified for dialog partners. | |
The purpose of this function is to improve data protection: | |||
Maximum value: '32767' | |||
In the case of an invalid value, UTM sets idletime to the lowest value allowed and issues the return code KC_MC_OK with the subcode KC_SC_ INVALID_IDLETIME. | |||
o | encryption_level | Only relevant for UPIC clients and also for some terminal emulations on BS2000 systems. | |
In encryption_level you define the lowest encryption level for communication with a client,
Possible values are: | |||
'N' | (NONE) | ||
'3' | (LEVEL 3) | ||
'4' | (LEVEL 4) | ||
'5' | (LEVEL 5) Level 5 is only supported in openUTM on Unix, Linux, and Windows systems. | ||
Establishment of a connection to the client is rejected by UTM if the client does not support at least the specified encryption level (3, 4 or 5). | |||
'T' | (TRUSTED) | ||
The following applies for the individual client types with regard to the encryption level:
| |||
For data to be encrypted on a connection to the client the corresponding RSA keys must be available. | |||
o | usp_hdr | This parameter is only significant for PTERMs with ptype='SOCKET'. | |
'A' | UTM creates a UTM socket protocol header for all output messages (dialog, asynchronous, K messages) and precedes the message with it. | ||
'M' | UTM creates a UTM socket protocol header for the output of K messages only and precedes the message with this. | ||
'N' | UTM does not create a UTM socket protocol header for any output message. |
1 | All fields in the data structure kc_pterm_str that are not listed and all fields that are not relevant to the operating system you are using are to be set to binary zero. The data structure is described in full in chapter "kc_pterm_str - Clients and printers". |