(Continued from page 2)
In a Native Mode MPE stack trace such as this the current point of execution in the program is usually the top line, labelled NM 0. In this case we're sitting in the "block_current_process" routine. A few lines below that at NM 5 we see "impede_process". This is definitely an impeded process, but we knew that already!
Our main point of interest is to see what our program is doing, or trying to do. Most of this stack trace, everything from line NM 12 and above, happens to be system code, or operating system procedures. Line NM 12 tells us that the program called the COMMAND intrinsic, and asked the OS to execute an MPE command.
But due to the fact that Glance can't see the internal symbols of our program, it therefore can't show us the procedure names, and we still don't know what our program is doing. We could certainly narrow it down by checking the source code for all the locations where we call the COMMAND intrinsic, but there could be many, and we don't like guessing games. So we were prepared to guide Steve through a somewhat tricky procedure that would allow him to produce a stack trace that included our program's internal procedure names.
Before we got to that, however, a couple of eagle-eyed members of our tech support team noticed the "hxtellop" procedure buried in the middle of the stack trace (at line NM b). This indicated to us that our program had passed a TELLOP command to the COMMAND intrinsic, and was trying to display some data to the system CONSOLE.
But what could cause a simple TELLOP message to become impeded? The only answer which makes sense is that the CONSOLE itself was hung in some fashion, and was not able to display messages. Therefore, any process that attempted to write to the CONSOLE also became "hung".
We asked Steve to check his physical CONSOLE. Perhaps someone had halted a listing with Ctrl-S and left it like that; or perhaps they had started typing a command and didn't finish. Steve hit RETURN at the CONSOLE and saw a flood of queued messages fly by. The system at once returned to normal, and all impeded processes cleared up, including our program. It wasn't our fault after all!
The root cause of the problem is that the MPE CONSOLE has a buffer of limited size. When the CONSOLE, for whatever reason, is prevented from displaying messages, the buffer can fill, which ultimately leads to impeding any subsequent processes that attempt to write to it. The moral of the story is that every MPE shop should include CONSOLE health as part of its standard operating procedures.