s3270 no longer waits/blocks for the host

[lojic]

I have an application that has been working flawlessly on version v3.3.10ga4 on Linux since roughly 2010. It also works flawlessly on version v3.3.11ga6 on Mac OSX.

I recently setup a new Amazon EC2 serve, and I installed version v3.6ga4, and my application is now failing. Initially it was failing due to a self-signed SSL cert on the host, but disabling verification fixed that.

Now, it appears to not be waiting for the host. The first few commands are as follows:

ascii string "CICSCRP\n" ascii

When I run that in the shell using s3270, it works fine and I get a page of output w/ the ascii command. With my program, I get a blank screen. After spending hours debugging this, I finally had my program sleep for a couple seconds between the string and ascii commands, and that worked, so some behavior has changed where before it would block until the output was ready, but now it allows me to continue to the ascii command before the output is ready.

I'm reluctant to simply install an older version of s3270, but any help with the current version would be much appreciated!

[dhdasilva]

I'm having the exactly same problem, except that I've never used an older version, so my script never worked properly with s3270 (just with c3270, that is much slower).

Have you got news about it?

[rbarbosatoro]

I had this exact problem and the way I fixed it was to use the -httpd parameter and send http requests to see if the connection could be established. At the end, it's almost the same as waiting a couple seconds for the terminal to connect to the server...

[pmattes]

My apologies for taking so long to see this (I wasn't watching these conversations).

Are you still seeing this issue? s3270 blocking until the host finishes is quite fundamental behavior, and is definitely not broken now.

[lojic]

@pmattes when you say it's definitely not broken now, which version are you referring to? I still have the sleep in my code since I haven't updated s3270, nor Linux, I don't expect any change in behavior.

[pmattes]

I am referring to s3270 3.6ga11 (stable) and 4.0alpha6 (alpha).

Putting sleeps in screen-scraping code is usually a recipe for unnecessary slowness and intermittent disasters, so it's important to make sure this works right in the emulator.

[lojic]

Thanks for the clarification. Do you happen to know which commit(s) fixed this behavior after v3.3.11ga6 ?

[pmattes]

It's been too long, I'm afraid. I would need to do a binary search to find where it broke and where it got fixed. (Which might be a fun exercise...)

3.3.11ga6 was released over 9.5 years ago. It's exquisitely frustrating how long it takes to get things updated in various distros.

[pmattes]

Let me correct myself.

I just built copies of s3270 3.3.10ga4 and 3.3.11ga6, and ran them against a simple trace file from a host session. Blocking behavior for AID actions works as expected for both of them.

If you could send me a trace of an s3270 that is misbehaving, I would very much appreciate it.

[lojic]

Yes, those two versions worked for me also. It was when I used v3.6ga4 that it failed.

[pmattes]

Now I see what's going on.

Here is the change that bit you (it's in the release notes for 3.6alpha1):

Changes in version 3.6alpha1, 8. March 2017 [all] Fixed the unlockDelay resource, which was inadvertently ignored (effectively aways on) for several releases. The value is now false for s3270, ws3270 and tcl3270, and true elsewhere.

What happened in 3.6 was that the default value for unlockDelay was effectively changed from true to false for s3270. (It still defaults to true elsewhere.) That change is still present in 3.6ga11 and 4.0. This was a response to years of complaints from people who wondered why their s3270-based apps were so slow, due to the 350ms delay after each host keyboard unlock.

You can restore the old behavior with the following command-line option: s3270 -xrm 's3270.unlockDelay: true' In 4.0, you can also run this action: Set(unlockDelay, true)

[lojic]

Ah, right. That sounded familiar, so I searched my email. We discussed it via email outside of github back in March 2019 :) My solution (unlikely to be of much use given I program in Racket :) ) was:

(subprocess #f #f #f "/usr/local/bin/s3270" "-xrm" "s3270.unlockDelay: true" "Y:L:ssl3270.example.org:2023")

[pmattes]

So to clarify, s3270 is still waiting for the host to unlock the keyboard. But now it no longer waits an extra 350ms after the host unlocks the keyboard, to deal with hosts that unlock the keyboard before they are actually finished -- unless you explicitly ask it to.

Without knowing exactly what your host is sending in this case, this may be a silly suggestion, but you might want to try adding Wait(inputfield) after sending your AID in this case, rather than just adding an explicit or implicit 350ms delay.