Loops are also relatively easy to recognize. When one inspects the collective status of all threads in the system, one thread will be in 'run' status, (if an SMP, one on each processor) and it is likely that many more threads are ready. If the priority of the thread is normal, an application may loop for a long time without the user being aware of the loop, although system performance may suffer somewhat.
To analyse a loop, follow one iteration of it. This is much easier to do with an interactive debugger than it is in a dump.
If the priority of the 'run'ning is in the time-critical class, the dispatcher is designed to prevent OS/2 from dispatching other threads. The looping thread is the cause of the problem, unless the loop is the correct response to another problem. In this case, contact the developer to find out why the thread must be such a high priority, and while you are talking, ask what could cause it to enter a non-ending loop. To diagnose a loop, use an interactive debugger to step through the loop, and try to understand what each conditional jump is really trying to accomplish. You can use an interactive debugger to lower the priority of an offending thread, and 'observe the results'. Recognise that this is quite legitimate, but that the application's integrity may actually depend on the behaviour you have just altered.