Improve Debug Tool Interrupt Capabilities

Interrupt Capabilities: Debug Tool needs the capability to stop after x number of calls to Debug Tool, and ask the user if they want to continue. Some languages offer the abiltiy to stop using the Attention key. However, this does not always work. Introducing tracing may exasperate the problem of long running debugging sessions, without the capability of breaking out of them. Let's define a new variable, such as Debug_calls, to a default value of something like 10,000. Provide the capability to modify this value. If any of the Debug Tool invocations exceed this value, pause the debug session, and ask the user if they want to continue, stop, or modify the Debug_calls variable and continue. This allows for a "governor" of run-away debugging sessions. This function is also helpful with the AT CHANGE command when using Debug Tool, when every statement is interrogated to see of storage changed. A value of zero will not stop.

Instead of using the number of times Debug Tool is called, a better approach may be a timer, which would be more intuitive than a count of calls to DT. It's not always obvious to a user when DT gets called. Something like:
SET INTERRUPT 60 (if no breakpoints are hit after 60 wall-clock seconds since the last user interaction, then stop the next time DT gets called)

For the interrupt feature, a timer might be more intuitive than a count of calls to DT. It's not always obvious to a user when DT gets called. Something like:
SET INTERRUPT 60 (if no breakpoints are hit after 60 wall-clock seconds since the last user interaction, then stop the next time DT gets called)

The development organization may decide the best technically feasible approach.

Doug Stout indicated he is asked about the interrupt capabilities quite frequently. This requirement is linked to requirement MR0907103332. It is best to have an interrupt capabilitiy before trace improvements are made.