Known Bugs in x3270 3.1

  1. Not so much a bug as a problem with the 3270 protocol in general. 3270
     applications were designed to interact with people, not programs. When
     you type ahead in x3270, or use x3270 scripts, macros or complex String
     actions, a number of subtle problems may crop up.

     Once data has been sent to the host, the host must send an explicit
     command to unlock the keyboard. On real 3270 terminals (and earlier
     versions of x3270), most keystrokes were ignored while the terminal was
     waiting for this command.

     By contrast, x3270 3.1 stores keystrokes in a typeahead buffer. It is
     also capable of running macros and scripts, where potentially large
     amounts of data can queue up.

     The problem occurs in deciding when it is safe to send more data to the
     host. Unfortunately, many operating systems and applications send the
     keyboard-unlock command back almost immediately, even though they are
     not yet ready to accept new data. When you are typing interactively,
     this is rarely a problem, because you generally don't begin typing
     again until you see a prompt or a data-entry panel. However, for a
     macro or a script, which cannot "understand" what it sees on the
     screen, these "premature unlocks" can be fatal.

     x3270 attempts to address this problem in the following way. When the
     host sends a keyboard-unlock command, x3270 does not immediately resume
     the flow of data back to the host. Instead, it waits 350 msec,
     meanwhile still buffering keystrokes in the typeahead buffer. This
     smoothes over a large portion of premature unlock situations, but with
     two drawbacks. First, it won't cover all situations, since some
     interactions with the host will take more than 350 msec. Second, it
     doesn't behave consistently: if a host is unusually loaded, a macro or
     script that behaves normally every other time may suddenly not work.

     This is an area of ongoing investigation in x3270.
