Tuning ZIETrans screen-settling

You might be able to tune ZIETrans screen-settling in several different ways to improve reliability, performance, or both. Following are some decisions that you might need to make:

Use Contention Resolution to improve performance and reliability?

If ZIETrans successfully negotiates contention resolution, communication is more efficient, resulting in fewer delays interacting with host systems. See Contention resolution (TN3270E only) for more information.

Tune strategy delays?

You might want to change the value of default.delayInterval to improve response time or to allow for reliable performance in applications or environments where response time is longer. Some host systems repeatedly have a long response time latency before sending certain screens. The delay might be at a host step that requires considerable processing, or it might involve a network resource that is in heavy demand from time-to-time. In these cases, increasing the delayInterval value might result in more reliable screen-settling. You should accommodate not only the average time for host response, but also the typical longest variation. Choose a value that accommodates your typical operating conditions. Similarly, the default.delayStart, default.appletDelayInterval, fast3270E.minimumWait, and fast5250.minimumWait settings control delays in various cases. See the descriptions for the settings in Table 2.

What happens when a delay like default.delayInterval is set too small?

The ZIETrans runtime can decide the screen is complete and the host is finished sending data. Some examples of the symptoms that can happen in that case are:

• The ZIETrans screen is blank, and clicking Refresh corrects this.
• A screen appears to be partially (incompletely) rendered, and clicking Refresh corrects this.
• The wrong screen customization event is called, which can result in the wrong custom transformation being shown, because the screen recognition criteria cannot examine the incomplete screen properly.

What happens when a delay is set too large?

The user might experience long response times, and in the worst cases, stop waiting for the screen. Application tuning requires operational judgment regarding the application and the network environment in which it is being used, and there is a balance to be struck.

Correct other problem scenarios?

There are situations that appear similar to those solved by tuning strategy delays but have different solutions:

• Enabling applications to process inhibited screens. Use the waiting for OIA flags customization settings keyboardInhibitedWait and oiaLockMaxWait.
• ZIETrans screen update for 5250 connections is unsuccessful in some cases, even after tuning strategy delays. You might need to turn off the Fast5250 strategy by using the nextScreenClass setting.

Use automatic refresh?

Based on your network environment and requirements, using automatic refresh might be useful for improving user response time. See Automatic refresh for more information.