%SYSTEM. How to end the corresponding lock process after WorkManager reports an error

If Work Queue Manager reports an error and you see many locks, the main points are:

• Worker code in %SYSTEM.WorkMgr must clean up completely after itself, including locks. Any logic called by the worker must leave no locks or other artifacts behind, because the same worker process can later be reused for different work items. [1]
• If multiple work items change the same global, you must use a locking strategy, but the code must not include unLOCKs that interfere with the framework. [1]
• It is normally required to call Sync() or WaitForComplete() so the framework can collect worker errors and reach a synchronization point where all work has completed. [2][1]
• One reported case of WorkMgr error 7802 was caused by a lock instruction inside the queued routine; removing that lock made the problem go away. [3]

So, to deal with the locks:

1. Check the code being run by WorkMgr.Queue(), especially any LOCK usage. A lock inside the worker routine may be the direct cause of the WorkMgr failure. [3]
2. Make sure each work item cleans up all variables, locks, and process-private globals before it finishes. [1]
3. Use Sync() or WaitForComplete() after queueing work so errors are reported properly and completion is coordinated. [2][1]
4. If a deadlock has already occurred, resolve it using the Management Portal or the ^LOCKTAB routine. [4]

If your goal is to end the process that is holding the lock, the retrieved material only says that deadlocks can be resolved through the Management Portal or ^LOCKTAB; it does not provide a documented step here for killing a specific worker process directly. [4]

[!NOTE]

The %SYSTEM.WorkMgr class supports more complex workflows with the methods described in other topics. [1]

Sources: