hi,
kindly our network consists of the following ( 9500 commserver + 93 device 7530 teklogix terminals (tekterm emulation tess session) + motorolla Moto mesh duo infrastructure + Navis sparcs application)
during real operation we usually face a big problem that affect our buisness directly
some of terminals give (Lock-H) messages for a long time causing delay
i try to invistigate to know if the problem is a network problem or something else
i start a ping session to the sparcs server while the lock-h message still appear but the ping usually give good response with no request time out !
what are the suggested tests to know the reason of this problem
please help
Hello, the fact that you have a lock H means the terminals have connectivity to the controller. So it seems the issue is on the host side. Is this a random daily event? As in random time of day and random terminals that go into lock H?
Hi! I encounter this problem when there is a difference between configuration in Navis and inside the Tekterm.
In Sparcs, you must set and ID and screen size (along with other parameters) for each terminal.
In Tekterm, you need to set up the same ID (unique per terminal) and the font size, or screen size in old versions.
The problem occurred after a resume (but not always happened). Basically, when the terminal is trying to retrieve the information of the session when it wakes up, this incompatibility prevent the terminal to access the host and therefore showing you the Lock-H message.
Hopes it helps...
hi John,
thank you for fast response
yes it is random event,random time of the day,random terminals. you can expect LOCK-H any time any place and on any terminal !
it seems to me that the network has no problems
what is other investigations that i can do to solve this strange problem
i can follow with you step by step
thanks again for response
hi leonardo,
thank you for fast response.
i would like to tell you that LOCK-H Messages usually appear for a period of time then the session resumed again automatic, but the lock-h time cause delay for my business may exceed 2-3 minutes
i already configure sparcs with ID's (for each hand held terminal i configure a unique ID) and the same i did for terminals also (all of TEKTERM configured with it's dedicated ID),
IS There other tests that i can do ?
your help is highly appreciated
thanks
Hello,
You should ping the IP address of the 9500 and not the sparcs from the terminal. Unless both have the same IP.
Is it possible the sparcs is slow. Do you use TekHTML or the Navis 9010 plugin ? But since you get LockH and not LockB it seems the controller waits for a reply of the sparks.
With a packet sniffer you can log how fast the sparcs reply to controller requests.
Also some debug on the 9500 is possible. Please contact your Psion Teklogix helpdesk for more info.
Sascha Schickler
hi Sascha,
many thanks for your weighted information
controller and sparcs on different servers , different ip addresses.
we use 9010t to connect from terminal to the host ( ican understand from your talk that it is a navis application method? is that right ?
you say a packet sniffer ? like what please - can you recommend a one ? and how i can use it?
is debug on controller can give events about its response and sparcs response ?
your help to me is highly appreciated
I'm going to take a different route and add one more thing to pay attention to. Backbone is Moto (Mesh).
Do you know the ratio of Root AP's (wired) to wireless AP's?
How many hops are required between RFT and host (this may change drastically as you move about)?
Can you force association to a root/wired AP and test?
Once you get baseline from root you can start working outward monitoring hops/lock-h and see if this reveals anything interesting???
Karl
Hello nadd200,
I highly recommend you call your local Help Desk and get their assistance in capturing some debug from both the controller and the handheld. It is difficult to track down Lock-H issues without this level of detail. The problem can be that the 9500 is waiting for a response from the host or it can be that the 9500 has received the response from the host but the transmission to the terminal has failed for some reason. The only certain diagnosis is with the debugs.
However, since your pings are getting through without delay from the terminal to the controller, we can ASSUME the problem is with your connection between the 9500 and the host OR in the controller itself. The most simple test is to start a continuous ping from the 9500 to the host and see if problems show up. Let this run for a time. Ideally you would have this ping running and when a terminal goes into Lock-H you could see if there is packet loss. If there is loss, this would indicate network problems between the 9500 and host. I have seen broadcast storms from failing hardware (NICs or switch ports) that will cause this.
If there is no loss, it is probably best to try to run some debug.
Good luck
Hi, Did you managed to resolve this issue and what was the exact outcome. What exactly you did to resolve this issue.