pmattes
commented
1 year ago Would it be possible for you to turn on data stream tracing and reproduce the problem?
Open Russell-May opened 1 year ago
pmattes
commented
1 year ago Would it be possible for you to turn on data stream tracing and reproduce the problem?
Russell-May
commented
1 year ago Sure, how do I go about enabling it?
pmattes
commented
1 year ago To turn it on: Set(trace,on)
To turn it off: Set(trace,off)
Trace file will be in /tmp/x3trc.
Russell-May
commented
1 year ago Attached below. Let me know if you need anything else.
pmattes
commented
1 year ago This is an interesting scenario.
I ran your trace file back through x3270 here, and it does exactly what you report -- after reconnecting, the screen is mis-formatted. The interesting part is that if I run x3270 as a model 3 instead of a model 5, the screen is formatted correctly. That is, the host is sending the screen image assuming that the screen has 32 rows and 80 columns.
The 3270 data stream protocol specifies screen locations using offsets rather than rows and columns. The upper-left corner is offset 0, and for an 80-column terminal, the first column of the second row is offset 80. The number of columns is assumed to be agreed upon by both sides, because there is no way in the Write message for the host to specify a row or column.
For example, in your trace, the host is writing the text 'Option' starting at offset 241. With an 80-column terminal, that's row 4, column 2. On a 132-column Model 5, that's row 2, column 110 (and looks terrible).
This is very strange, because when you reconnected, the host sent BIND-IMAGE messages that clearly indicate that it knows it is talking to a Model 5. The messages say that the alternate screen size is 27 rows and 132 columns. Then it went ahead later and painted the screen assuming it was talking to a Model 3.
One additional clue is that in the first part of your trace, the host sends a Query message; the reply from the terminal indicates how many rows and columns it has. But in the second part, after reconnecting, the host does not send a Query. My guess is that the layer on the host that does the BIND-IMAGE is passing screen size information to the layer that does the Query; it is this second layer that ultimately controls the screen dimensions that are assumed for the Primary Option Menu. The second layer appears to be remembering the Query reply from the earlier connection and is not refreshing its data with a new Query when you reconnect.
A possible workaround for this would be to recognize the 'LOGON RECONNECT SUCCESSFUL' message coming from the host, and to do an explicit logout as soon as you can rather than proceeding with the session. The other is not to change screen sizes in s3270, but I assume you have good reason for doing this in the first place.
Hi Team,
I recently ran into what appears to be a bug with the formatting of the screen data after reconnecting to a session with a different resolution. This results in an unreadable screen in some cases. I was able to replicate this behavior with both wx3270 and also directly with actions calling s3270. I am providing a screen shot of what it looks like in the wx3270 when this happens as well as the actions/output that create the same effect directly with s3270.
Steps to replicate with wx3270:
Actions/Responses replicating directly with the s3270:
Actions/Responses when connecting with model 5 but not reconnecting to an existing session opened with a different model on s3270 (correct/expected formatting of the data):
Please let me know if you need any additional information or if there is any workaround apart from logging off of the current session and creating a new one. Thanks!