4.1.2 3270 and 5250 connection settings

In addition to the common configuration settings, 3270 and 5250 host types require these specific settings.

Terminal model

Specify the terminal model (also known as a display station) you want Host Access for the Cloud to emulate. There are different terminal models available depending on the host type.

If you choose Custom Model, you can set the number of columns and rows to customize the terminal model.
Use Kerberos automatic sign-on (5250 only) When set to Yes the user does not have to enter sign-on credentials. Kerberos automatic sign-on is configured in the MSS Administrative Console > Host Access for the Cloud. In configuring HACloud to use the Kerberos authentication protocol there are terms that you should understand and prerequisites to adhere to in advance of configuring this option. These options are explained in detail in the MSS Administrative Console > Host Access for the Cloud panel documentation, available from the Help button. See Set Up Kerberos for AS/400 Single Sign-on for more information.
Terminal ID (3270 only)

When Host Access for the Cloud connects to a Telnet host, the Telnet protocol and the host negotiate a terminal ID to use during the initial Telnet connection. In general, this negotiation will result in the use of the correct terminal ID, and so you should leave this box empty.

TLS Security

TLS protocols allow a client and server to establish a secure, encrypted connection over a public network. When you connect using TLS, Host Access for the Cloud authenticates the server before opening a session, and all data passed between and the host is encrypted using the selected encryption level. The following options are available:

Table 4-2 TLS Descriptions

Security options	Description
None	No secure connection is required.
TLS 1.3 - 1.0	Allow connection through TLS 1.3, TLS 1.2, TLS 1.1, TLS 1.0 depending on the capabilities of the host or server to which you are connecting. When Verify server identity is set to Yes, the client checks the server or host name against the name on the server certificate.
TLS 1.3	Connect using TLS 1.3. When Verify server identity is set to Yes, the client checks the server or host name against the name on the server certificate.
TLS 1.2	Connect using TLS 1.2. When Verify server identity is set to Yes, the client checks the server or host name against the name on the server certificate.

NOTE:See the section on Secure connections for information on adding trusted certificates, key stores, using SSH, and other advanced security information.

Verify server identity

When TLS security is set to TLS 1.3, TLS 1.2 or TLS 1.3-1.0, you have the option to verify the host name against the name on the server certificate. It is highly recommended that you enable host name verification for all sessions.

Device name

If you selected TN3270, TN3270E, or TN5250 as the protocol, specify the device name to use when the session connects to the host. The device name is also known as the host LU or pool. You can also choose to:

Generate a unique device name An unique device name will be automatically generated.
Use Terminal ID Manager which displays additional settings to complete.
Always Prompt the User for ID When you select this option the end user will be prompted for the device ID each time a connection is attempted.
Prompt the User if ID not Specified The end user will be prompted the first time a connection is attempted after which the value is saved. The saved value will continue to be used without additional prompting.

If you do not specify a device name for the session, the host dynamically assigns one to the session. A device name that is set within a macro will override this setting.

To use Terminal ID Manager, you must have a Terminal ID Manager server configured. See Set Up the Terminal ID Manager.

If you selected Terminal ID Manager you can use it to provide IDs to client applications at runtime. You can use the Terminal ID Manager to manage pooled IDs for different host types. An ID is connection data that is unique for an individual host session.

If you decide to use Terminal ID Manager and have configured the Terminal ID Manager server, then you can select from the options below to configure the criteria for acquiring an ID. All criteria must be met in order for an ID to be returned.

NOTE:Keep in mind that by specifying a criterion, you are indicating that the ID should be allocated only when an ID that has that specific value is found. The set of criteria selected here must be an exact match of the set of criteria specified on at least one Pool of IDs in Terminal ID Manager before the ID request can succeed.

Table 4-3 Terminal ID Manager Criteria

Criterion	Description
Pool name	Include this attribute and enter the name of the pool to limit the ID search to a specified pool.
Client IP address	The IP address of the client machine will be included as part of the request for an ID.
Host address	The address of the host configured for this session will be included as part of the request for an ID.
Host port	The port for the host configured for this session will be included as part of the request for an ID.
Session name	When selected, requires that the ID is configured to be used by this session exclusively.
Session type	The session type (for example, IBM 3270, IBM 5250, UTS, ALC or T27) is always included as part of any request for an ID.
User name	Use this criterion to ensure that only IDs created for exclusive use by specific users will be allocated. The current user’s name, which must be found on an ID before it can be allocated, is the name of the user that the session is allocated to at runtime. To configure a session based on user names, a default place holder user name is available: tidm-setup. For the administrator to configure sessions using tidm-setup, the Terminal ID Manager needs to have IDs provisioned for tidm-setup. You can override the default name with one of your own by modifying the <install-dir>/sessionserver/conf/container.properties file as follows: id.manager.user.name=custom-username Where custom-username is replaced by the name you want to use.
Application name (UTS)	The name of the host application will be used as part of the request for an ID.

To determine the connection attempt behavior if Terminal ID Manager does not successfully allocate an ID to this session, use If ID is not allocated:

Fail connection attempt -If selected, the session will not attempt to connect when an ID is not allocated.
Allow connection attempt -If selected, the session will attempt to connect when an ID is not allocated. The attempt may be rejected by the host. There are some host types that permit a user to connect without an ID.

To confirm that Terminal ID Manager can provide an ID using the criterion and value selections you have made, click Test.

Send keep alive packets - Use this setting to provide a constant check between your session and the host so that you become aware of connection problems as they occur. Choose from the following types of keep alive packets:

This option	Does this....
None	The default. No packets are sent.
System	The TCP/IP stack keeps track of the host connection and sends keep alive packets infrequently. This option uses fewer system resources than the Send NOP Packets or Send Timing Mark Packets options.
Send NOP packets	Periodically a No Operation (NOP) command is sent to the host. The host is not required to respond to these commands, but the TCP/IP stack can detect if there is a problem delivering the packet.
Send timing mark packets	Periodically a Timing Mark Command is sent to the host to determine if the connection is still active. The host should respond to these commands. If a response is not received or there is an error sending the packet, the connection shuts down.

Keep alive timeout (seconds) - If you choose to use either the Send NOP packets or the Send timing mark packets option, select the interval between the keep alive requests set. The values range from 1 to 36000 seconds (1 hour); the default is 600 seconds.