<HTML>
<TITLE>Known Bugs in x3270 3.1</TITLE>
<H1>Known Bugs in x3270 3.1</H1>
<OL>
<LI>
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.
<P>
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.
<P>
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.
<P>
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.
<P>
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.
<P>
This is an area of ongoing investigation in x3270.
</OL>
