Novell Netware 5.0 ssp2. Wks 98SE. NWclient 3.1.0.0. Using LH.nlm All files SRW. Have used various netware logins. Netware rights have been verified.

Wks #1 accesses OI app, no problem.

Wks #2 accesses OI app. App logon screen displayed. Enter User ID, Password and press OK. System "hangs". According to novell console monitor, wks#2 is waiting on a lock. Monitor shows no file/record locks. NLM_Stats shows no record locks for any files or records. The app will eventually "timeout" and let you in. Works as normal.

Ran a OIEngine Log for wks #2. Waited until the app timed out and let me in. Stopped the OIengine log. The stack of functions follows:

Get_app_info HPMS

Bchecklegaluser HPMS HPMS 0

Swap_database HPMS

Set_appid HPMS

Get_sysinfo

Repository execute our entry point window.

The Swap_database took about 4 minutes to complete, which is about how long the app takes before it timed out and lets me in.

However, if I start the app on WKS #2 first, WKS #1 can go in no problem. We have resolved differences between WKS#1 and #2 to make them look identical, without completely rebuilding WKS#2. If we rebuild it and it works, I would never be able to determine what was wrong. I have about three workstations that behave like WKS#1, they access the app no matter who is in it. About fifteen workstations that behave as wks#2, wait and eventually timeout, some never timeout, and have to be Cntrl Alt Del and End task and occasionally warm booted.

Scott,

If you switch the network driver (NETDRV.EXE) to Byte-Range locking, does the same behaviour occur?

Is the same behavior evident when logging into the SYSPROG application? Give that a shot if you haven't.

Also, when you say "times out", what exactly does that mean? It seems as though you are saying that the workstation gives up on obtaining the phantom lock, and then immediately logs in normally?

-Stephen

Byte range locking produces the same result.

Sysprog produces same result.

"Times out" means the application waits for some amount of time and finally will let you in a process normally. The waiting point is right after you click OK on the User login screen.

Scott,

The latest Client32 for 3.21 is Windows95/98. Give that a try for now. I'm assuming that all of these workstations are Win98SE, and I've heard of some strange problems with 98SE. Perhaps there are some patches on Microsoft's site that might help?

I'm looking into this in the meantime and trying to reproduce if possible.

-Stephen

Scott, It is our understanding that this issue has been resolved.

Could you please confirm this? Thanks, Susan Noyes

Scott, Have you checked the protocol stack on the problem PC's. BTW I had major problems with a few Win98 SE PCs / Novell 5.0 sp3 + Client32 3.100. PCs would lock if left for some time. Identical PC's were oK. In the end turned off watchdog solved this problem.

Yes. The lock delay in the Client 32 advanced settings needs to be a 1 in a 100 megabit ethernet environment. We were using our standard setting of 18 for a 10 megabit environment to reduce network traffic.

View this thread on the Works forum...