-
Can't Restart x3270
It is possible for x3270 to get into a state where it cannot be restarted.
This can happen with window managers such as twm, whose
MaxWindowSize variable is enforced at client start-up time, but not
when a client changes its own window size.
Thus, it is possible for an x3270 menu option such as Options->Screen
Size to resize the x3270 main window so that it exceeds the
MaxWindowSize (with no objection from twm).
If the x3270 configuration is then saved, (either via the File->Save
Changes Options in File menu option, or by an external command that uses
the WM_SAVE_YOURSELF message to get x3270 to update its command line and
then saves that command line in a start-up file), then the next time x3270 is
invoked it will not be able to run.
The best recommendation in this case is to not set MaxWindowSize in your .twmrc file.
-
Host Session Hangs
Several users have reported a problem where the session hangs during
initialization -- immediately after x3270 has sent a Query Reply. I need
more information about this problem in order to debug it.
The best information would be a TCP packet trace of a successful session
with a different emulator. Help!
-
User Area Too Small
A problem has been reported where a host application reports:
000A1 You cannot use PM30 on terminal BG18 user area is too
small.
This problem does not occur with other emulators. If anyone can shed
any light on this problem, I would appreciate it.
-
Premature Keyboard Unlocking
This is 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.2 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.