Ati stuck with keylock

[orkeilius]

Hi, I'm trying tnz for testing 3270 screens.
I'm new to the mainframe, so it could be my fault.

Description

When I open an app, ATI is keylocked and never unlock.
That's strange because when using the emulator, the screen unlock normally

For context, the script login, open an environment, and open an app.

The app seems to be open correctly (scrhas is working fine, but I can't write anything).

Other Info

For security reasons, I can't share too much detail. But basically the log says "rc = '0' "

I tried with another app in another environment, and no problem.

So is there a bug, or am I missing something?

[najohnsn]

I think you may need to describe more what "open an environment" and "open an app" means.
Maybe the script is missing code to wait for the keyboard to be unlocked?

ati.wait(lambda: ati.value("KEYLOCK") == "0")

But that's really just a shot in the dark with this level of detail.

[orkeilius]

Oh sorry. Basically the script is like this:

Ati.wait(lambda: ati.scrhas("login") and Ati.value("keylock") == "0")
Ati.send("user[enter]")
Ati.send("password[enter]")

# env screen
Ati.wait(lambda: ati.scrhas("env menu") and Ati.value("keylock") == "0")
Ati.send(" s envName[enter]")


# app menu screen
Ati.wait(lambda: ati.scrhas("select app") and Ati.value("keylock") == "0")
Ati.send(" appName[enter]")

# app (keylocked here)
Ati.wait(lambda: ati.scrhas("app name") and Ati.value("keylock") == "0")
Ati.send("anything")

[najohnsn]

where are you stuck?

[najohnsn]

where are you stuck?

Oh, now I see "keylocked here" in the comment.
Your earlier comment about writing might imply that you got past that wait and got to the Ati.send("anything"). That would say that the keyboard did get unlocked and maybe the application positioned your cursor on a protected field?

[orkeilius]

When i remove the keylock conditions or when i add a timeout in the "wait", the send print a warning 12: excessive keyboard lock

Any additional send print a warning 12: Session lost or undefined and "wait" throw a similar AtiError

To be clear in the emulator, the screen unlocks pretty much instantly (and don't drop the session)

[orkeilius]

Also, the cursor is in the intended field (at least that's what ati.currow/curcol says).

Adding the position in the send doesn't help either.

But since the screen app doesn't unlock in the first place, I don't think the last send could be the problem.

[orkeilius]

That odd, i tested other apps and the one i want to test is the only one with this problem .

[najohnsn]

Yeah, this is strange. I've never heard of anything like this before. The only thing I can think of that would be a difference between the script and interacting manually with zti is timing. So, it would be interesting to see if this change for starting the app changes anything:

Ati.wait(lambda: ati.scrhas("select app") and Ati.value("keylock") == "0")
Ati.wait(1)  # <- add this to change timing
Ati.send(" appName[enter]")

With some more debug information, I might be able to see what is going on. Copy https://github.com/IBM/tnz/blob/main/tnz/logging.json into a logging.json in your directory. Edit that file and change WARN to DEBUG. Then set TNZ_LOGGING=logging.json to point to that file. Then run your script. You may need to sanitize the resulting tnz.log. But, if you can share the tnz.log from the point where s envName is entered, I'd be happy to try to piece together what is happening. You may want to also do it manually through zti so that the two results can be compared.

[orkeilius]

Hi, sorry for the late response

there is an altered version of the log

Also, the app is actually a CICS transaction (I tried another transaction without getting this error)

[najohnsn]

Thanks for your patience. This fell off of my radar.
Unfortunately, there is too much cut out of the log for me to get much from it.
But I did noticed that your python code doesn't seem to me to match what is in the log

2025-09-19 10:23:59,451 1- 30: scrhas('**transactionName**')
2025-09-19 10:23:59,451        >>> HITROW = '1'
2025-09-19 10:23:59,451        >>> HITCOL = '18'
2025-09-19 10:23:59,451        >>> HITSTR = '**transactionName**'
2025-09-19 10:23:59,451        >>> RC = '0'
2025-09-19 10:23:59,451        >>> RC = '1'
2025-09-19 10:23:59.452 1- 31: send('test',)

I imagine that the scrhas('**transactionName**') should match up with your python code ati.scrhas("select app") and the the send('test',) should match up with your python code Ati.send(" appName[enter]").

But I don't see any evidence that Ati.value("keylock") == "0") is being done. I don't see any evidence of Ati.wait(1) either, but that may just mean you weren't trying to change timing in that run.

Then again, I don't know why that would matter since it just impacts if the wait() times out or the send() times out.

I see this:

2025-09-19 10:23:59,442 A WCC 0x40 for_mdt=False

That WCC value of 0x40 means to reset partition. That does not include restoring/unlocking the keyboard. But maybe other WCC values were received but cut from the log? Bit 6 (mask 0x02) is what triggers restoring/unlock the keyboard.

[orkeilius]

Hi,

Thanks for the response. (No worries about the delay. This is just a side project, so I work on it whenever I have time.)
For the log/code mismatch, i probably made some small change.

But i found something else.

Why explaining the big to a colleague, he tries, and it worked ??
After some test it seems that it related to the header (the added line with cursor position, keyboard lock...). When running the program in a small terminal the header don't show, and the program work. But when show or running in background I get the keyboard lock thing

keylock ❌	keylock ❌	no keylock ✅
	*running in background or with pytest *

I’ll run more tests when I have time.
In the meantime, is there a way to disable the header so I can properly test this ?

[najohnsn]

Interesting. The header depends on the relationship between the 3270 terminal size and the hosting terminal size. Maybe it is more of a size thing? You can probably eliminate the header with environment variable SESSION_PS_SIZE=FULL. You can also use that variable to set it to any arbitrary size, e.g. 43x80.

[v1gnesh]

On a related note, I size my session 50x160 (not 62x160) so that I see the header and the session selector on the right.
Without the header, you won't see the keylock, as you've found.

[orkeilius]

You can probably eliminate the header with environment variable SESSION_PS_SIZE=FULL.

I try using 'ati.set()', setting it in terminal or directly in window's user env, but it doesn't seem to do anything ?? (header still visible)

For context i'm on win11 using powershell or cmd.

[najohnsn]

3270 screens have 2 sizes - the "primary" one and the alternate one. The "primary" one is always 24x80. The alternate one is controlled by SESSION_PS_SIZE (and/or ascii terminal screen size). When you say that SESSON_PS_SIZE has no effect, maybe your application is only using the "primary" size? In my experience, z/VM logon screens use the alternate size and z/OS logon screens use 24x80 until logon is successful (at which point, the alternate screen size is used). But I wouldn't be surprised if system configuration could make that work different.

My best guess is that your application is doing something weird depending on the screen size. I wouldn't suggest you use SESSION_PS_SIZE=24x80 to eliminate any "varying" sizes.