Host Interface Features

The following section describes how CIC's host interface functionality is scalable, flexible, and robust.

Scalability

CIC's host tools use a multi-threaded, three-tier architecture, and were designed with scalability in mind. Scalability features include the following:

• Establishing and maintaining up to 1,000 concurrent terminal emulation sessions (physical connections).

• Caching connections to allow multiple handlers to share a single connection.

• Executing multiple field lookups or updates into a single toolstep in a handler.

• Reducing overhead. CIC's host connectivity libraries interpret the 3270 and 5250 data streams directly; the result is a significant reduction of overhead when compared with HLLAPI/EHLLAPI solutions.

• Optimizing navigation. By using dynamic recording of screen transitions, Interaction Host Recorder enables a much more optimal host navigation compared to traditional snapshot approaches that tend to make heavy use of sleeps to try to ensure stability. These sleeps can add a significant amount of fixed overhead to each transaction. With CIC's optimizations, your terminal emulations only sleep if the number of ready-to-send (RTS) events is different from that which was recorded during the development phase – which is rare.

Reliability

CIC uses an external process (Host Server) to service requests from the handlers and the host. This process was coded defensively from the start, making heavy use of exception handling, internal heartbeat checks, and redundancy. However, in the unlikely event that this process fails, no other critical CIC subsystems (like Interaction Processor) are affected. If a problem occurs, CIC's service manager detects it and automatically restarts Host Server in seconds.

Configurable Logging

Host Server has extensive logging capabilities that enable quick problem diagnosis. For example, if a move to screen operation fails, the exact reason it failed is logged to a file, along with a snapshot of the current screen. Internal errors and very serious host errors are also logged to the Windows event log. You can configure the level of detail that is written to the logs.

Optimal and Robust Host Navigation

CIC's host connectivity strategy offers optimal performance. However, the nature of host navigation makes it impossible to achieve optimal navigation under all circumstances – there will be variances in the number of RTS events, host response times, and so on. In addition, unforeseen conditions can result in unexpected (and often unknown) screens.

CIC accommodates failures on harmless anomalies (like fewer RTSs than expected), and is designed to fail gracefully and return meaningful error information when bigger problems occur (like not detecting an expected screen).

At the heart of CIC's robust strategy are the runtime screen validation rules. You can define validation rules in the Interaction Host Recorder based on the following elements:

• Screen ID

  An ID that is generated based on a proprietary algorithm that is designed to uniquely identify a screen under many (but not all) conditions

• Screen Type

  The number of unprotected fields

• Text Match

  Look for a particular string at a particular location

• Cursor Position

  Look for the cursor at a unique position

We recommend using several validation rules together to ensure that a screen is in fact the one you are expecting. All validation checks can be performed immediately, or performed with a wait timeout to allow a slow screen to finish loading. All of this is explained in the extensive Interaction Host Recorder help.

Flexible Field Definitions

Screen fields are areas of a screen where you can read and write strings to and from handlers.

Note:
The fields you define do not depend on the fields programmed in the terminal screen.

Using Interaction Host Recorder you can define screen fields in many ways. The types of screen fields you can define include:

• Absolute coordinates

  The field begins in row X, column Y, and ends at row X1, column Y1.

• Relative offsets from the current cursor position

  The field begins X spaces after the current cursor position. This is very useful for repeating and tabular data.

• Ordinal field value

  The field begins at X spaces after the beginning of the Yth protected or unprotected field.

• Relative to a search anchor string

  The field begins relative to the location of a string you specify.

• Relative to a pair of delimiting strings

  The field is the space between the Xth occurrence of string A and the Yth occurrence of string B.

For example, to define a field relative to two delimiting search strings, you would perform the following procedure:

1. Highlight the left/top search anchor string.

2. Right-click to display a popup menu.

3. Select Add User Defined Field, and then select Selection as Left Delimiter from the menu that appears.

   

   After step 3, a dialog appears allowing you to configure your definition, including specifying the right delimiting string: