Common Connection Settings

These options are common to all supported host types.

Connect at startup

By default, sessions are configured to connect to the host automatically when you create or open a session. However, you can set up a session so that it doesn't automatically connect to the host. Choose NO to manually connect to the host.
Reconnect when host terminates connection

When set to Yes, Host Access for the Cloud attempts to reconnect as soon as the host connection terminates.
Protocol

From the drop down list, select the protocol you want to use to communicate with the host. To establish a host connection, both the web client and the host computer must use the same network protocol. The available values are dependent on the host to which you are connecting. They are:

Protocol	Description
TN3270	TN3270 is a form of the Telnet protocol, which is a set of specifications for general communication between desktop and host systems. It uses TCP/IP as the transport between desktop computers and IBM mainframes.
TN3270E	TN3270E or Telnet Extended is for users of TCP/IP who connect to their IBM mainframe through a Telnet gateway that implements RFC 1647. The TN3270E protocol allows you to specify the connection device name (also known as LU name), and provides support for the ATTN key, the SYSREQ key, and SNA response handling. If you try to use Telnet Extended to connect to a gateway that doesn’t support this protocol, standard TN3270 will be used instead.
TN5250	TN5250 is a form of the Telnet protocol, which is a set of specifications for general communication between desktop and host systems. It uses TCP/IP as the transport between desktop computers and AS/400 computers.
Secure Shell (VT)	You can configure SSH connections when you need secure, encrypted communications between a trusted VT host and your computer over an insecure network. SSH connections ensure that both the client user and the host computer are authenticated; and that all data is encrypted. Two authentication options are available: Keyboard Interactive - You can use this authentication method to implement different types of authentication mechanisms. Any currently supported authentication method that requires only the user's input can be performed with Keyboard Interactive. Password - This option prompts the client for a password to the host after a host connection is made. The password is sent to the host through the encrypted channel.
Telnet (VT)	Telnet is a protocol in the TCP/IP suite of open protocols. As a character stream protocol, Telnet transmits user input from character mode applications over the network to the host one character at a time, where it is processed and echoed back over the network.
INT1 (UTS)	Provides access to Unisys 1100/1200 hosts using the TCP/IP network protocol.
TCPA (T27)	Use this protocol to connect to Unisys ClearPath NX/LX series or A Series hosts. TCPA Authentication is the process of verifying user login information. When properly configured, you can request a security credential from your application's credential server and send the credential back to the server. If the credential is valid, your application will be logged in; you do not have to enter a user ID or password. If the credential is not valid however, you will be prompted for a user ID and a password.
MATIP (ALC)	Mapping of Airline Traffic Over Internet Protocol (MATIP) uses TCP/IP for airline reservation, ticketing, and messaging traffic.

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.

Tip

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.

The following options are available:

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. It is highly recommended that you enable host name verification for all sessions.
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. It is highly recommended that you enable host name verification for all sessions.

Note

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

Enable emulation tracing

You can choose to generate host traces for a session. No is the default. Select Yes to create a new emulation host trace each time the session is launched. The trace file is stored in <install directory>/sessionserver/logs/hosttraces/<date(yyyymmdd>/<trace-file>.

Using Terminal ID Manager

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 and 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 with 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.

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 must have IDs provisioned for tidm-setup. You can override the default name with one of your own by modifying the `&ltinstall-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 - When selected, the session does not attempt to connect when an ID is not allocated.
Allow connection attempt - When selected, the session attempts 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.

Test Terminal ID Manager Criteria

The Terminal ID Manager provides IDs to client applications at runtime. To confirm that Terminal ID Manager can provide an ID using the criteria and value selections you selected use this test option.

Criteria for the current session are specified on the Connection panel after selecting Use Terminal ID Manager from either the Device Name (3270, 5250 host types), the Terminal ID (UTS) field, or the Station ID (T27) field. By default, the selected criteria for the current session are displayed.

Click Test to confirm that Terminal ID Manager can provide an ID matching the configured criterion and value selections. The test returns the name of an available ID that satisfies the selected attribute values.

Testing for other criteria and values

You can also use this panel to test criteria different from those associated with the current session.

Select any of the session types from the Session type list, and select the criteria you want to test. You can test alternate values that you want to use in a sample Terminal ID Manager request.
Click Test to confirm that Terminal ID Manager can provide an ID matching the criterion and value selections. The test returns the name of an available ID that satisfies the selected values.