*PF-KEY = 'CLR' when *DEVICE = 'ASYNCH'

, , ,
1

We have a situation where a Natural session running as an attached (asynchronous) task under Com-plete 661 is, at some point in its processing, getting the value ‘CLR’ moved into the *PF-KEY system variable. Obviously no-one is pressing any terminal keys in an asynchronous session, and the sessions do not start with this value, so the assumption is that some programmatic process is causing this value to appear. (The session registers as an EntireX ACI broker server and responds to requests originating from the web.)

I’ve been unable to come up with any method of causing *PF-KEY to contain ‘CLR’ other than actually pressing the Clear key in a 3270 session. There doesn’t seem to be a SET CONTROL option that simulates the Clear key, nor have I found a way to use SET KEY to make this happen.

Anyone have any ideas on what could be causing this? We need to fix it but don’t even know what to look for in the code at this point.

2

Your session most likely has come accross a renegade INPUT statement. In case of INPUT you get CLEAR key returned, unless SET CONTROL ‘N’ had been specified. This is a fail-safe logic to prevent loops in situations of unexpected INPUT, most likely error situations.
Pls see docu:
chapter Asynchronous Processing
paragraph Handling Unexpected or Unwanted Input

Hope this helps

3

Thank you very much Klaus. We’ve been able to reproduce the behavior via this method although the developers haven’t yet identified where they are hitting an INPUT statement. Also, SET KEY ALL or SET KEY CLR is a pre-requisite for this behavior; without it our broker request times out.

Thanks again.