Re: Input inhibit following error message

Erik,

Please send me the trace file.

If possible, please tell me how to reproduce this problem on my own
system.   I'll use this to try to fix the problem.


On Mon, 21 Oct 2002, Erik Zetterberg wrote:

> Hi all,
> After having successfully set up destructive backspace, colors and keyboard
> mappings (see a previous post) for our linux based thin clients running
> xt5250 0.16.5 we suddenly ran into a show stopper...
> On a Windows PC running Client Access 5.1 the sequence of events is as
> follows:
> The user attempts to retrieve a record which is locked by another user. An
> error message is issued and is displayed according to the setting in CA. CA
> immediately goes into 'keyboard locked/input inhibited (X II)'. Following
> 'keyboard unlock' the error message is cleared and the screen refreshes.
> In xt5250 what happens is the following:
> The user attempts to retrieve a record which is locked by another user. An
> error message flashes by, to be seen only by the hawk-eyed, and the screen
> refreshes after which the input inhibit indicator goes on and the keyboard
> is locked. The user wonders why he can't get att his record and frustration
> ensues.
>
> I have made a trace file which is 500kB large just to get in, trigger the
> error and get out again. It is about 20 years since I last analyzed a block
> mode data transfer protocol (3270 BSC)so I'm a little rusty:-). Having no
> access to (or for that matter time to delve into) the protocol definition I
> will have to go on what I can see.
> In the trace file I can see the blocks of data arriving without any
> intervening user interaction
> 1 - The error message
> 2 - The error message clearing command
> 3 - The refresh screen
> I assume from the behavior in CA that the II command is set somewhere in the
> error message block. What I don't understand just now is the rationale
> behind deferring the Input Inhibit in xt5250. Please enlighten me:-)
> Any help would be appreciated. The alternative is to switch the users over
> to a Windows Terminal Services based CA solution but that is possibly 'out
> of the frying pan, into the fire' for several reasons.
>
> Please let me know if anybody wants the trace file.
>
> Best regards
> Erik Zetterberg erik_zetterberg using the services of hotmail.com (put them
> together yourself)