|
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)
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.