This is a problem reported by one of our customers who are still running AREV 3.1. Our product is entitled WMS. Any suggestions?

We've been experiencing problems over the last several months where WMS will lockup if you ALT+TAB to another application and ALT+TAB back only a few minutes later.

This problem is not specific to a user or server. If anything it may be related to certain PCs. In the past we had problems with users running WMS on PCs that have CD/DVD drives. The solution for these people was to run WinFrame (even though they are located in the same office that WMS is located.)

We also have had problems with the Novell 3.3 client. We've had to create a batch file that Maps drive J: to the sys volume prior to running Arev, (even though J: is already mapped to sys.) This appeared to solve the problem for most Novell 3.3 users, but not all.

When we are completely stumped we move the user to WinFrame. The problem with that is we are moving more and more people to WinFrame. It seems like we will eventually have everyone running WinFrame — that's certainly not preferred.

Do you know of any patches for Arev (3.12) or the Arev NLM (1.5) that would help us? Anything else you can think of?

One potential:

Make sure that in the shortcut to your WMS application, on the "Misc" tab, that the "always suspend" checkbox is UNCHECKED.

Hank,

We experienced a similiar problem in a Novell environment with the NLM. We solved the problem was setting a parameter in the revparam file. The parameter in question slips my mind but what it does is controls how long the NLM with wait for the AREV app before it assumes that it has gone away and drops the connection. The result looks like the AREV system has locked up. Sprezzatura has a nice little utility for managing the Revparam file.

Can you look up what this setting was. The only one I can find in the manual is GroupLockTimeOut which doesn't seem to be what you are describing.

Thanks,

View this thread on the Works forum...