Appendix B. HATS screen-settling reference

This information introduces you to screen-settling, settings for screen-settling, and other settings that affect screen-settling.

Screen-settling overview

Host applications can send outbound data in any number of transmissions, the number of which is not provided to the client. This situation is handled easily when using a terminal or heavy client terminal emulator, as communications remain always active and results in the client's view being updated whenever necessary. However, when using HATS to transform screen-based host applications into a HTML-based format, the client is only connected to the host (indirectly, through the HATS runtime on the application server) for the duration of each browser update requested by the client. Therefore, HATS must analyze the outbound data received during this browser update cycle, and decide when to send the current host screen to the screen recognition engine for transformation or other event processing. This process of analyzing the outbound data and deciding when to use the current host screen is called screen-settling.

The HATS runtime performs screen-settling:

After screen-settling, HATS examines the host screen (presentation space) and compares it to the set of enabled screen customizations (screen recognition) for further processing. It is important that this settled screen is the intended one.

Screen-settling procedure

HATS performs screen-settling in two distinct operations

When analyzing outbound data, HATS performs one of several strategies that analyze the outbound data, trying to determine when the host application has finished sending data. Each of these strategies is used in different cases and each has settings that customize its behavior.

When waiting for OIA flags, which is independent of the strategy used in analyzing outbound data, the session's OIA flags are examined to ensure that the host is ready for the user to send more inbound data. There are also settings that customize this behavior.

Analyzing outbound data

Depending on runtime circumstances, HATS employs one of several available strategies to determine when the host has finished sending each screen update. HATS 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 HATS runtime. For more information about tracing, see Using the functions in HATS administrative console. Each of these strategies can be customized by adding or changing connection settings. Table 25 describes the strategies and Table 26 describes the settings.

Table 25. 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. HATS 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 26 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 HATS. 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 HATS 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 26 describes customization settings for screen-to-screen transitions.

Table 26. Screen-to-screen transition settings
Setting (case-sensitive) Description Default
default.delayInterval The nominal amount of time, in milliseconds, that HATS 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 HATS 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 HATS 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.
  1. 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.
  2. 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 HATS 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 HATS 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.
  1. 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.
  2. 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 HATS 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 HATS 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 HATS 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 HATS 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 HATS 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 25.

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

Table 27. Initial screen settings
Setting (case-sensitive) Description Default
default.delayStart The nominal amount of time, in milliseconds, that HATS 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 HATS settings. It is the minimum amount of time HATS 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 HATS to transform or otherwise process, set this value to false or HATS will not consider the connection setup to be successful. true

Waiting for OIA flags

After analyzing outbound data, HATS waits for the OIA flags to indicate that the host is ready for the user to send more inbound data. In some cases, OIA flags already indicate this condition after analyzing outbound data, and waiting for OIA flags completes immediately. By default, HATS waits for up to 5 minutes for the STATE_SYS_LOCK (System Lock) and the STATE_TIME (Keyboard Inhibited) flags to be cleared. Both these conditions can be customized with the settings defined in Table 28, which apply regardless of which strategy is used to analyze outbound data.

Table 28. OIA customization settings
Setting (case-sensitive) Description Default
keyboardInhibitedWait Specifies whether to wait for the keyboard inhibited OIA flag to be cleared. If set to false, HATS only waits for the system lock OIA flag to be cleared. This setting is used to send keyboard-inhibited screens to the client. true
oiaLockMaxWait Specifies the maximum amount of time, in milliseconds, that HATS waits for the OIA flags to indicate that the user can send more data. This value can be decreased if you want to return locked screens faster. Values too low can impair screen reliability. It is recommended that if you need to return certain locked screens to the user, try using the keyboardInhibitedWait setting before changing oiaLockMaxWait. 300000 milliseconds (equals 5 minutes), unless the asynchronous update applet is enabled and running. If so, the default is the value of default.appletDelayInterval, described in Table 26.

Changing customization settings

Screen-settling customization settings can be changed using the connection editor in the HATS Toolkit. To change the settings, typically in the main.hco file for a connection named main, open the HATS Projects view, expand Connections, and select main (default).

Five of the settings can be changed on the Screen Handling tab of the connection editor:

All of the settings described above can be configured on the Source tab. In the <classSettings> tag, the screen-settling settings are in the com.ibm.hats.common.NextScreenSettings class.

You can add or modify the settings as needed to configure screen-settling performance. The default connection settings are:

<classSettings>
    ...
   <class name="com.ibm.hats.common.NextScreenSettings">
      <setting name="default.delayInterval" value="1200"/>
      <setting name="default.appletDelayInterval" value="400"/>
      <setting name="default.blankScreen" value="timeout"/>
      <setting name="default.delayStart" value="2000"/>
   </class>
</classSettings>

The following example updates one setting and adds another: 

<classSettings>
    ...
   <class name="com.ibm.hats.common.NextScreenSettings">
      <setting name="default.delayInterval" value="1200"/>
      <setting name="default.appletDelayInterval" value="400"/>
      <setting name="default.blankScreen" value="timeout"/>
      <setting name="default.delayStart" value="1500"/>
      <setting name="nextScreenClass"
              value="com.ibm.hats.runtime.TimingNextScreenBean"/>
   </class>
</classSettings>

Determining which strategy HATS is using

Follow these steps to determine the strategy being used by HATS:

  1. Turn on traces for HOD Transport and for HATS Runtime. For more information about tracing, see Using the functions in HATS administrative console. In the runtime.properties file, the settings are: 
    trace.HOD.TRANSPORT=2
trace.RUNTIME=7
  2. View the trace file (typically contained within the logs directory of the HATS.ear file and has a file name starting with trace.
  3. Look for entries similar to these when HATS performs screen-settling: 
    Text        RUNTIME      runtime.NextScreenBean.getInstance()
	  oiaStatusFlags/isSSCP=x7 false

	Text        RUNTIME      runtime.Fast3270ENSB.<init>()                          
	  Create: Fast3270E: initialConnect=false, ttwOriginal=1200, tStartedWaiting=0, 
                       tLastPSEvent=0, keyToSend=[enter], minimumWait=250
    The key text, highlighted in bold, is the method name of the first example entry runtime.NextScreenBean.getInstance(), which begins a screen-settling process. The resulting object created in the entry begins with Create:. The strategy object created in this example has its name (Fast3270E) and its Java class name (Fast3270ENSB) on the second example trace entry, highlighted in italics.

Contention resolution (TN3270E only)

Contention resolution, as defined in the latest draft of the Internet Engineering Task Force (IETF) TN3270E protocol standard (RFC2355), and available on many TN3270E servers, helps overcome limitations in the conversion of the SNA protocol of the host to the Telnet protocol of the clients. Using contention resolution improves the performance of TN3270E clients, including HATS.

The use of contention resolution is negotiated during connection setup, between the Telnet client in HATS (the HACL Telnet client) and the TN3270E server. If HATS successfully negotiates contention resolution with the TN3270E server, communication is more efficient, resulting in fewer delays interacting with host systems. By default, HATS attempts to negotiate contention resolution with any 3270-based host system defined with the TN3270E host type.

Contention resolution using z/OS Communications Server

Starting with z/OS® 1.2, IBM implemented contention resolution in z/OS Communications Server , including VTAM®. However, the original implementation in z/OS 1.2, 1.3, and 1.4 did not precisely match the emerging standard. Consequently, HATS might have difficulty communicating with these original releases of z/OS Communications Server. To address the problem, IBM issued patches (PTFs) and published an informational APAR (technical note) listing the recommended patches.

Ask your z Systems administrator to refer to APAR II13135, entitled "Common Telnet Problems Under z/OS". APAR II13135 lists the recommended PTFs that enable HATS to take advantage of contention resolution. For example, for z/OS 1.4, the APARs PQ71574 and PQ72265 apply, and are corrected by PTF UQ76065. Without the proper fixes, HATS might experience random hangs. HATS developers observed this problem as a clocked screen in the HATS Toolkit terminal window (a screen frozen with a clock icon displayed at the bottom).

If your z Systems administrator cannot immediately install the II13135 patches, use the negotiateCResolution setting described in Related HATS settings and specify a value of false. This setting with a value of false causes HATS to skip contention resolution negotiation, reverting to the earlier TN3270E specification. Disabling contention resolution can degrade HATS performance by lengthening 3270 response time, but otherwise has no negative consequences.

This contention resolution negotiation problem does not occur when HATS connects through a front end 3270 communications gateway instead of directly to the affected z/OS host system. These gateways might or might not support contention resolution, or might require additional service to be applied to support contention resolution.

Contention resolution using other Communications Servers

Recent releases of IBM® Communications Server for AIX®, Linux, Linux on zSeries, and Windows also properly support contention resolution. If it is not possible to upgrade to z/OS Communications Server 1.2 (with patches), or later, these alternative platform versions of Communications Server can provide HATS with the faster response benefits of contention resolution. IBM Communications Server might also prove useful for host systems running versions of VM, VSE, or TPF that do not support contention resolution.

In these instances, HATS connects through TN3270E, optionally with SSL or TLS, to IBM Communications Server running on AIX, Linux, Linux on zSeries, or Windows. IBM Communications Server connects to the host system using an SNA connection, either a traditional SNA connection or Enterprise Extender (SNA traffic flowing over an Internet protocol network). System administrators can manage TN3270E LUs on IBM Communications Server rather than on the host system.

Performance impact of using contention resolution

Using default settings in HATS, contention resolution can reduce 3270 screen-to-screen transmission delays by approximately 800 milliseconds (in IBM, testing on an unconstrained, fast network). While this delay might be tolerable for casual Web users, contention resolution can prove beneficial for certain high velocity users and for high performance Web services.

Contention resolution has no direct impact on the HATS server processor capacity requirements for any given workload.

Determining contention resolution status

You can determine whether HATS successfully negotiates contention resolution for a particular TN3270E connection. To examine a HATS trace to see the results of the negotiation, follow these steps:

  1. Turn on traces for HOD transport and for HATS runtime. For more information about tracing, see Using the functions in HATS administrative console. In the runtime.properties file, the settings are: 
    trace.HOD.TRANSPORT=2
trace.RUNTIME=7
  2. View the trace file (typically contained within the logs directory of the HATS.ear file with a file name starting with trace).
  3. Look for entries together in the trace file, similar to these, when the connection was started: 
    Text        HOD          HOD.()
	  Correlator: HodConn:localhost:localhost:server1:HATS.ear#1
	  trcmsg: -->TN3270 : Negotiate     CMD = DO      OPT = TN3270-E

	Text        HOD          HOD.()
	  Correlator: HodConn:localhost:localhost:server1:HATS.ear#1
	  trcmsg: <--TN3270 : Response      CMD = WILL    OPT = TN3270-E
    The key text, highlighted in bold, is CMD = DO and CMD = WILL when OPT = TN3270-E also appears (shown here in bold). If both CMD = DO and CMD = WILL appear, HATS successfully negotiated TN3270E for that particular host connection, and can request contention resolution. If CMD = WONT, CMD = DONT, or both appear, it is likely that the host does not support TN3270E, and HATS cannot request contention resolution.
  4. Look for an entry similar to this one when the connection was started: 
    Text        HOD          HOD.()
	  Correlator: HodConn:localhost:localhost:server1:HATS.ear#1
	  trcmsg: <--TN3270 : FUNCTION_STATUS: CR REQUESTED
    The key text, highlighted in bold, is FUNCTION_STATUS: CR REQUESTED. If this text appears, HATS has requested contention resolution for that particular host connection.
  5. Look for an entry similar to this one when the connection was started: 
    Text        HOD          HOD.()
	  Correlator: HodConn:localhost:localhost:server1:HATS.ear#1
	  trcmsg: <--TN3270E: FUNCTION_STATUS: CR ENABLED
    The key text, highlighted in bold, is FUNCTION_STATUS: CR ENABLED. If this text appears, HATS has successfully negotiated contention resolution for that particular host connection.
  6. Look for entries together similar to these two when HATS performs screen-settling: 
    Text        RUNTIME      runtime.NextScreenBean.getInstance()                   
	  isEnhancedTNServer=true

	Text        RUNTIME      runtime.Fast3270ENSB.<init>()                          
	  Create: Fast3270E: initialConnect=false, ttwOriginal=1200, 
                                           tStartedWaiting=0,tLastPSEvent=0, 
                                           keyToSend=[enter], minimumWait=250
    The key text, highlighted in bold, is EnhancedTNServer=true and Create: Fast3270E. If these appear, HATS has successfully negotiated contention resolution and is responding by using the Fast3270E strategy for analyzing outbound data.

Automatic refresh

HATS provides both client pull and server push functions for updating the client browser with asynchronous outbound data. See Automatic Disconnect and Refresh  Web-only  for details about these functions.

Use of these functions is another way to tune the HATS screen-settling process. Whether you use these functions can be based on:

Using either of these functions can enhance performance by enabling screen-settling times to be reduced, since missed updates can be refreshed on the client when they are received at the application server. Several default screen-settling settings are changed when the server push (applet) function is configured and running on a client. See Table 26 and Table 28 for more information about these settings.

Transient screen handling

A transient screen is a host screen that is intended (by the host that sent it) to be displayed to the client for a very minimal amount of time, before showing an application screen for the user to respond to (the intended screen). Two examples of transient screens include:

Note:
For information about handling transient screens in macros, see Handling transient screens.

A user running a standard emulator might not notice a transient screen that appears momentarily, and is replaced by the intended screen. When HATS receives a transient screen, this can sometimes result in causing HATS to prematurely decide that the host has finished sending data. The transient screen is compared to the list of enabled screen customizations and in most cases rendered by the default transformation and shown on the client browser. The host sends the intended screen to replace the transient screen, but HATS has already completed screen-settling for that browser update and is not waiting for, or processing, host screen updates. If the user, upon seeing the unintended transient screen transformed, clicks Refresh, HATS synchronizes with the current host screen and the client browser is properly updated. This is not the intended overall result, and can typically be avoided by tuning screen-settling delays or by enabling either of the automatic refresh functions in some cases.

An alternate approach to eliminating this undesirable scenario is to create one or more screen customizations to specifically match the transient screens, and no other screens, and take the appropriate action. This action can include nothing, which can be implemented using a Play Macro action of a simple macro that only contains a short <pause> element. Combined with the screen-settling action that HATS performs after processing a screen customization action list, this results in HATS waiting until receiving the intended screen to respond to the browser update request. You must create the recognition criteria for the screen customizations with care, to not match screens you intend for the user to see.

HATS provides additional screen-settling settings, which enable easier customization of blank screen handling, without creating screen customizations and macros. These customization settings, for simpler blank screen handling, enable you to specify the action to take when HATS settles on a blank screen. An action can be waiting, sending a certain host key, or proceeding with screen recognition processing.

For blank screen handling on the initial screen, two additional screen-settling connection settings are available. See Screen Handling in Managing connections for details on configuring initial blank screen handling.

Initial blank screen handling settings

Table 29 describes the initial screen handling settings for blank screens.

Table 29. Blank screen handling settings
Setting Description Values Default
default.blankScreen The system waits for a non-blank screen for the period of time specified in the connect timeout on the Advanced tab. The default.blankScreen setting specifies what to do when the connect timeout expires, if there is still only a blank screen. Valid values are:
timeout
Issue an error message. This is the default value.
normal
Display the blank screen. You can also specify a lower connect timeout if you expect a blank screen as the initial screen.
sendkeys
Send the host key defined on the default.blankScreen.keys setting. You can also specify a lower connect timeout if you expect a blank screen as the initial screen.
timeout, normal, or sendkeys timeout
default.blankScreen.keys Specifies the host key to send when default.blankScreen is set to sendkeys. A valid host key none

For blank screen handling after the initial screen, HATS uses a defined application event. See the section titled "Blank screens" under Application events in Working with screen events for details of this application event.

Related HATS settings

The following settings do not directly configure HATS screen-settling, but they have an impact on screen-settling, therefore they are listed here for reference:

Name Setting Location Description
negotiateCResolution You can add this connection property to the table of advanced connection settings on the Advanced tab of the connection editor in HATS Toolkit.

In the source of the .hco file, this becomes an entry in the <otherParameters> tag.

 Tells the Telnet client (HACL) used by HATS whether to negotiate for Contention Resolution on the TN3270E connection. The default is true.

Setting this parameter to false causes HATS not to request contention resolution from the Telnet server. It is not used, therefore it causes the HATS screen-settling for this host to use the Timing strategy.

See Contention resolution (TN3270E only) for more information about this function and why you might want to disable it.

The same effect on HATS screen-settling occurs as a side effect of changing the host type to TN3270 instead of TN3270E, since contention resolution is only requested when the host type is TN3270E.
connecttimeout This connection property on the Basic of the HATS connection editor, is labeled as Abandon attempt to connect after specified number of seconds.

In the source of the .hco file, this is the connecttimeout attribute of the <hodconnection> tag.

Note:
This is NOT the connectionTimeout parameter seen on the drop-down list when you add advanced connection properties in the connection editor. This is a new property, which is exposed to HATS by the Host On-Demand product, when HATS requests a list of available properties. It is not related to the HATS parameter or HATS screen-settling.
 Specifies the time, in seconds, that the server waits until a connection is available, either from the connection pool, if pooling is enabled, or from a new connection. The default is 120 seconds. A new connection is available when communications are started with the host and a usable host screen is received. Completely blank screens are not considered usable unless the ignoreBlankStartupPS screen-settling flag is set to false.
  • ignorepauseforenhancedtn
  • ignorepauseoverrideforenhancedtn
  • delayifnotenhancedtn
 These macro properties are specified in the source view of a macro. See Actions, Part 2: Timing issues in the Advanced Macro Guide for more information. Macros encounter the same situations as screen-settling regarding when the host has finished sending data, therefore these properties and their descriptions in the Advanced Macro Guide are referred to here.

These macro properties address problems that the macro developer encounters when trying to support a single version of a macro to run on both contention resolution and non-contention resolution environments. They control how <pause> elements of the macro, which are needed for non-contention resolution environments, are performed in a contention resolution environment.

The <HAScript> property ignorepauseforenhancedtn has a default of false, meaning that <pause> elements are always processed. When changed to true, the <pause> elements are ignored when contention resolution is used.

The <pause> property ignorepauseoverrideforenhancedtn, when set to true causes the <pause> element to be performed always, not skipped, even in a contention-resolution environment when ignorepauseforenhancedtn is set to true in the<HAScript> element.

The <HAScript> property delayifnotenhancedtn should be used whenever ignorepauseforenhancedtn is true, to enable contention resolution performance benefits, and the macro might also be used in a non-contention resolution environment. The property specifies the delay, in milliseconds, to incur when the OIA changes, and its default is 0.

See Actions, Part 2: Timing issues in the Advanced Macro Guide for more information about these properties.

Tuning HATS screen-settling

You might be able to tune HATS 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 HATS 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 26.
What happens when a delay like default.delayInterval is set too small?
The HATS 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 HATS 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:
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.

References

The references in this section also might be helpful in tuning screen-settling.

Contention resolution information

RFC2355 extensions (March, 2003, Draft)
http://www.ietf.org/proceedings/03mar/I-D/draft-ietf-tn3270e-extensions-04.txt
Informational APAR II13135
http://www.ibm.com/support/docview.wss?uid=isg1II13135
z/OS Communications Server
Refer to the z/OS Knowledge Center at http://www-01.ibm.com/support/knowledgecenter/SSLTBW_1.12.0/com.ibm.zos.r12/zosr12home.html and search on the tern SNAEXT.
IBM Communications Server for Linux, Linux on zSeries, AIX, and Windows
http://www.ibm.com/software/network/commserver

Advanced Macro Guide

See Actions, Part 2: Timing issues in the Advanced Macro Guide for a discussion of timing issues during macro play that are affected by macro design parameters and options, and screen-settling issues from the macro point of view.