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:
  • A Please wait or other in-progress message
  • Blank screens, containing only blank characters, generated by screen-clearing commands that might be issued by the host while moving within an application, or from one application or logon screen to another.
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 ZIETrans receives a transient screen, this can sometimes result in causing ZIETrans 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 ZIETrans 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, ZIETrans 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 ZIETrans performs after processing a screen customization action list, this results in ZIETrans 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.

ZIETrans 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 ZIETrans 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.