Analyzing outbound data

Depending on runtime circumstances, ZIETrans employs one of several available strategies to determine when the host has finished sending each screen update. ZIETrans uses a strategy based on multiple factors, including the host connection type, connection state, and various user-configurable settings.

If you need to see which strategy your connection is using, you can trace the ZIETrans runtime. For more information about tracing, see Using the functions in ZIETrans administrative console. Each of these strategies can be customized by adding or changing connection settings. Table 1 describes the strategies and Table 2 describes the settings.

Table 1. Available strategies
Strategy	Java™ Class Name	Description and Usage
Timing	TimingNextScreenBean	A starting value is used as a wait time. Based on the arrival of the host's outbound data transmissions, the wait might include additional intervals, set to half of the starting value, to ensure that all presentation space data has been received. ZIETrans waits an additional interval when presentation space data has been received in the second half of a wait interval. This strategy is used when the host type is TN5250, TN3270, and when the host type is TN3270E and contention resolution is not used.
Fast 3270E	Fast3270ENSB	This strategy allows improved communication over the TN3270E protocol provided by contention resolution to better determine when the outbound data has completely arrived. This strategy does no additional timing of outbound data arrival, therefore the default.delayInterval and default.appletDelayInterval settings described in Table 2 are ignored. This strategy is used when the host type is TN3270E and the contention resolution feature is used on the connection. Contention resolution must be activated on the Telnet server, and negotiated by the Telnet protocol when the connection starts, to be used by ZIETrans. See Contention resolution (TN3270E only) for more information. This strategy is also used for host types TN3270 and TN3270E, when the SNA side of the host session is currently connected to a system services control point (SSCP), because ZIETrans can depend on the TN3270E protocol to quickly determine outbound data arrival.
Fast 5250	Fast5250NSB	This strategy is based on the Timing strategy, but also tries to shortcut the nominal wait, if possible. The shortcut is taken, and the nominal wait ended, when both the OIA System Lock flag is cleared and a non-empty Presentation Space update (that is, containing characters other than blanks) has been received from the host. This strategy is used by default for the host type TN5250.

Table 2 describes customization settings for screen-to-screen transitions.

Table 2. Screen-to-screen transition settings
Setting (case-sensitive)	Description	Default
default.delayInterval	The nominal amount of time, in milliseconds, that ZIETrans waits while analyzing outbound data using screen-settling strategies. The actual time might be more or less than this setting, depending on the screen-settling strategy, such as the Timing strategy adding additional intervals, or the Fast 5250 strategy taking its shortcut. A higher value increases the reliability of screen transformations, in case of delays at the host due to long processing time or network delays. However, increasing this value lengthens response time, especially when using the Timing strategy and this value is the minimum screen-to-screen delay. Note: The Fast3270E strategy does not use this setting.	1200 milliseconds
default.appletDelayInterval	The nominal amount of time, in milliseconds, that ZIETrans waits while analyzing outbound data using screen-settling strategies, instead of using default.delayInterval if the asynchronous update applet is enabled and is running for that client. The actual wait might be more or less depending on the screen-settling strategy, such as the Timing strategy adding additional intervals, or the Fast 5250 strategy taking its shortcut. See Automatic refresh for more information. Note: The Fast3270E strategy does not use this setting.	400
fast3270E.minimumWait	The minimum amount of time, in milliseconds, that ZIETrans waits while analyzing outbound data using the Fast 3270E strategy with negotiated contention resolution. This setting, which is 250 milliseconds by default, is useful in two cases where using a small minimum wait enables more dependable screen-settling. Depending on the timing of received outbound data, the Fast 3270E strategy can complete screen-settling before all of the related events are processed at the Telnet client. If the host application sends short-duration transient screens that aren't intended to be transformed, you might need to use this setting to ensure ZIETrans waits for the transient screen to be updated with the intended screen. Take care with regard to user response time when modifying this value, as a minimum wait specified with this setting is used for settling all screens.	250
fast5250.minimumWait	The minimum amount of time, in milliseconds, that ZIETrans waits while analyzing outbound data using the Fast 5250 strategy. This optional setting can be useful in two general cases where using a small minimum wait allows for more dependable screen-settling. Depending on the timing of received outbound data, the Fast 5250 strategy can complete screen-settling before all of the related events are processed at the Telnet client. If the host application sends short-duration transient screens that aren't intended to be transformed, you might need to use this setting to ensure ZIETrans waits for the transient screen to be updated with the intended screen. Take care with regard to user response time when modifying this value, as a minimum wait specified with this setting is used for settling all screens.	0 (no minimum)
default.nonHostKeyWait	Specifies the time, in milliseconds, that ZIETrans waits after processing one of a set of pseudo-AID keys that does not require an actual screen-settling step, such as [fldext], [field+], or [eraseeof]. Modifying this setting is not recommended.	100
nextScreenClass	Allows overriding of the strategy used while analyzing outbound data, by specifying the fully qualified Java class name of the alternate strategy, instead of the strategy that ZIETrans would use. For tuning 5250 applications, this setting is sometimes used to increase reliability if the host application sends 5250 outbound data in a way that results in ZIETrans transforming and displaying partial or incorrect host screens. In this special case, the setting forces analysis of outbound data to use the Timing strategy instead of the Fast5250 strategy, by using a value of com.ibm.hats.runtime.TimingNextScreenBean. The Java package name for ZIETrans strategies is com.ibm.hats.runtime. Using this setting is not recommended with host types of TN3270 or TN3270E.	Depends on the host type and other factors described in Table 1.

Table 3 describes customization settings for the initial screen, which apply to all strategies.

Table 3. Initial screen settings
Setting (case-sensitive)	Description	Default
default.delayStart	The nominal amount of time, in milliseconds, that ZIETrans waits while analyzing outbound data, but only for the initial host screen. Since the connection setup process already waits for a usable screen before proceeding, this value is not an additional delay. See connecttimeout in Related ZIETrans settings. It is the minimum amount of time ZIETrans takes, from the time communications are initiated with the host until trying to recognize an initial screen. For fast networks, this value can be decreased to improve initial screen response time.	2000
ignoreBlankStartupPS	Whether a totally blank presentation space can be used as a successful first screen, after connecting to the host. Most host connections result in a MSG10 screen or other logon screen. If a completely blank screen can be a valid first screen for ZIETrans to transform or otherwise process, set this value to false or ZIETrans will not consider the connection setup to be successful.	true