× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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)



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.