Menu
▾
▴
#27 3270 datastream not rendered correctly
If the last position of the screen has a 3270 attribute and the first position contains data the data shold be displayed according to the attribute in the last position of the screen. This does not happen, the screen seems to be cleared (unprotected, blank). The attribute in the last position should wrap to the first position.
Can you tell me which version of x3270 you are running? And would it be possible for you to capture a data stream trace when this is happening? Turning on the trace will generate a snapshot I can use for debugging.
I was using "the latest", both x3270/c3270 downloaded vid "apt install..."
(yesterday) in ubuntu 20.x and wx3270 downloaded (yesterday) from a link i
found in the wiki, all with the same behaviour.
The windows file used for installation was "wx3270-1.0ga9-setup.exe", I
don't have access to the ubuntu computer at this moment.
Attached is a trace taken with wc3270.
Best regards,
Torbjörn Svensson
Den tors 28 apr. 2022 kl 17:47 skrev Paul Mattes pmattes@users.sourceforge.net:
Related
Bugs: #27
Interesting issue!
The problem isn't that wx3270 isn't implementing field wrap correctly. The host is sending a BIND-IMAGE that specifies both the default and alternate screen sizes as 24x80 (see trace, line 167), then later it is sending a 3270-DATA EraseWriteAlternate command that refers to screen locations outside of the 24x80 buffer (see trace, line 334). Since that is illegal, the EraseWriteAlternate is ignored.
I suspect that other 3270 emulators might have similar issues with this host.
An immediate workaround would be to configure wx3270 to use a 3270 model 2 (24x80) instead of a model 4.
Another workaround is to specify the 'N:' option on the hostname (x3270, c3270, wc3270) or to un-check the 'Accept TN3270E' option in the wx3270 Connection Editor. This will force the session to use TN3270 mode instead of TN3270E mode. In TN3270 mode, there is no BIND-IMAGE message, so this conflict cannot occur.
x3270 also has an option to ignore the screen sizes in the BIND-IMAGE. It is controlled by the bindLimit resource (set to 'false' to ignore the sizes). Unfortunately, there is no way to set that option in wx3270. But it can be used with x3270, c3270 and wc3270.
I will make the necessary changes to b3270 4.2 / wx3270 1.1 to make bindLimit settable from wx3270. I will also make sure that when b3270 encounters this error, it sends the appropriate error back to the host. That would not apply in this case, however, because the host sends the EraseWriteAlternate with a NO-RESPONSE flag (see trace, line 330), so it is not expecting anything back from the emulator. I could consider a pop-up error in this case, so you are not wondering why the screen is incomplete.
Hi,
Sorry for the delay, has been busy with other stuff.
From the trace:
20220429.184339.223 Host socket read complete nr=33
< 0x0 030000000031010303b190308000008787000002800000000018502b507e00ff
< 0x20 ef
20220429.184339.224 RCVD TN3270E(BIND-IMAGE NO-RESPONSE 0)
< BIND PLU-name '' MaxSec-RU 1024 MaxPri-RU 1024 Rows-Cols Default 24x80 Al
...
... ternate 24x80
18502b50 are the screen sizes.24x80 and 43x80.
BUT when printed it becomes 24x80 and 24x80.
I think that's where the problem is.
Best regards,
Torbjörn
Den lör 30 apr. 2022 kl 02:44 skrev Paul Mattes pmattes@users.sourceforge.net:
Related
Bugs: #27
I agree that the BIND image the host sent has the 24x80 and 43x80 screen sizes, but the issue is with the byte that follows. In the trace, that's X'7E'. According to https://www.ibm.com/docs/en/zos/2.1.0?topic=image-bind-area-format-dsect, X'7E' is BINPSFX, which is defined as 'Presentation space is a fixed size as defined by default values'. I interpret that as meaning there is no alternate size.
x3270 does not look at the alternate sizes in the BIND response unless that byte is X'7F'. That's BINPSZRC, 'Presentation space has both default and alternate sizes as defined in the DEFAULT and ALTERNATE fields.'
This is the first time that anyone has complained about this behavior in x3270, and the code has worked this way for many years, so I am hesitant to change this interpretation.
What OS is your host running? I'm wondering what generated the X'7E' instead of X'7F'.
Hi,
This comes from InterSession, a session manager that has been around since
the late 1980s. It runs on "all" IBM os'es, zOS, zVSE and zVM.
We have our own tn3270(e) server that was added about 15 years ago. There
is no VTAM session between the terminal and the session manager, just
tn3270(e). The bind image we provide over tn3270e when asked for it is the
image we construct.
I agree the BINPRESZ byte should probably be set to X'7F' instead. I
suspect no other tn3270 emulator looks at this byte. We have not seen this
problem on any of the tn3270 emulators we have tested over the years.
I will change the value and do some testing and come back with results.
/torbjörn
<#m_-1862713439171016057_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
Den ons 4 maj 2022 kl 17:43 skrev Paul Mattes <pmattes@users.sourceforge.net
Related
Bugs: #27
Hi - I am having problems with ws3270 with model 5 rendering 132cols against an IBM i (V7R4). I also get it on V7R3 and V7R5 OS levels.
Not sure if it is the same problem as being described here so apologies if not.
I have attached a trace plus screenshots showing what is coming back from ASCII1() and what it should look like (tn5250)
Thanks.
Forgot the trace...
This should be opened as a separate bug report, because it is not related to Torbjörn Svensson's issue, but I can respond here anyway.
From the trace, I can see that your iSeries host is not happy with ws3270 reporting itself as a 3279 model 5. It is not negotiating 3270 mode, instead leaving the terminal in NVT mode, where ws3270 is emulating an xterm, rather than a 3270.
Furthermore, the host does not understand that a 3270 model 5 has 132 columns, so it is generating output that assumes that the terminal has 80 columns. The formatting issues come from the host assuming that the terminal will wrap after column 80, but ws3270 will not do that until column 132.
If you run ws3270 with a different model number (2 is the likeliest to work, but 3 or 4 might also), you will see one of two different things happening. First, the host may accept the model negotiation and proceed with proper 3270 mode negotiation. Otherwise, if the host still insists on staying in NVT mode, at least ws3270 will be emulating an 80-column terminal and will wrap as the host expects.
If you want to stick with model 5, one other thing to try is the following command-line option on ws3270:
-tn IBM-3278-5-E
The host might like that better than the default 3279-5, which is a nonexistent model number.
Last edit: Paul Mattes 2022-11-24
Thanks for replying. Unfortunately that didn't work. I have tried all sorts of combinations and none of them give a 132col screen on IBM i. I'll have to manually test 132col screens rather than using ws3270. Thanks.