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