Also, if you bring up an NT task list, and do not see WinAppxD.exe in the list, that is an indication that it has already stopped (either you stopped it, or it ran into an error condition and ended itself), and needs to be restarted.

Once again, restarting WinAppxD without a reboot is not guaranteed to work, due to NT TCP/IP implementation. The existence of "Stop" and "Start" buttons in the Services Control panel applet does not mean that these functions work 100% of the time.

7. My WinAppxD gets stuck regularly. As you say above, sometimes I can restart it without a reboot, and sometimes I can't. I don't have time for reboots in the middle of the day. What can I do?

Many customers have increased the availability of WinAppxD by installing multiple WinAppxD services (WinAppxD as originally installed, plus nearly exact copies of it as WinAppxD2, WinAppxD3, etc.). These differ only in the port used by each one. For example, WinAppxD may listen on port 8060. WinAppxD2 may listen on port 8061. WinAppxD3 on port 8062. Once you have set up multiple WinAppxD services, you can instruct your users to change their "Server Port" (in the login dialog) to one of the alternate port numbers, if they experience difficulty connecting to the default port number.

You may wish to copy WinAppxD.exe to names like Appx8060.exe, Appx8061.exe, etc., in order to keep them grouped together under NT Server's Task Manager.

In any case, we recommend that you run multiple APPX/Servers, due to the increased level of fault tolerance it provides. Instructions on setting up WinAppxD services are in the APPX Presentation Client/Server Installation Guide.

Multiple WinAppxD services on different ports invoked from batch files is also a way of changing the main environment variables for, for example, running two versions and data sets in parallel, or using a different APPX_KEYMAP when attaching from another device type such as handheld RF scanners through a telnet session via a LINUX box.

II. APPX Client/Server session management

1. A user has just called me to say that they are hung. What should I do?

First, have the user tell you the number that appears in their APPX Client title bar. This is the NT PID (process ID) of the SERVER process to which they are connected. Go to your server, and verify that there is an APPX.EXE process with that PID on your system in the task list.

If there is no process listed in your server's task list with that number, double-check with the user that you're looking for the right one. Once you are sure that it isn't there, you have a situation in which the client process exists and the server process doesn't. Instruct the user to "End Task" on his APPX Client session via the Windows Task Manager. It may pop another box up, saying that the process is not responding. Instruct them user to click "End Task" on that box as well.

If the server-side process does appear in your server's task list, then you have more sleuthing to do.

Find out what the user was doing. Do they see any error messages on their screen? What process are they in? How long have they been waiting for a response from the system?

Try to find out if they are doing anything that requires locking a record (they probably are). (The user himself may not know the answer to this. Refer to your application for the final word.) If so, try to find out if that record is likely to be held by another interactive user, or perhaps a JOB that is batch updating a series of records. In many instances, even if the user does not receive a message to the screen, the culprit of these hangs is that their process is trying to access a record held by someone else. (If, for example, the INPUT calls an UPDATE as an automatic process, and that UPDATE runs into a locked record, it will silently wait for that record to become available, without advising the user.)

If it is possible that they are waiting for a lock, check with other uses and see if you can discover (and then eliminate) the source of the lock conflict.

BJUtils (mentioned in item II.7 below) contains a couple of methods for determining who has which files open. While it cannot tell you who has which records locked in which files due to NT O/S design limitations, it can point you in the right direction.

Remember also that the system might just be slow. Check to see what system performance is like, before assuming that their process is actually paused, as opposed to just running slowly.

If you were unable to narrow the situation down to lock contention, and solve it, and are also certain that the process is not just running slowly, it is time to look at killing the process.

2. The user process is hung, and I haven't been able to resolve the problem, so I need to kill that client/server session. How do I do that?

First, have the user try again to END and CANCEL out of their process, to make sure that it is not possible to resolve this any other way.

Have the user tell you the number which appears in their APPX Client title bar (they've presumably done this already, but in case they haven't, now's the time to ask). That is the NT PID (process ID) of the SERVER process to which this client is connected.

Once you have the PID, but not before, instruct the user to bring up their Windows Task List, and select the APPX process, then click on "End Task". It may pop another box up, saying that the process is not responding. Instruct the user to click "End Task" on that box as well.

Wait a minute or two for an orderly shutdown of the server-side process connected to the client. APPX should detect that the client has disappeared, and end the server process.

If after waiting several minutes, you still see the server-side process ID in your NT server's task list, you will need to manually kill the server-side process.

3. How do I manually kill an APPX server process?

In many instances, an APPX server process may be killed by doing the following: