On 25-Jun-2016 01:52 -0500, John R. Smith, Jr. wrote:
I was stepping through the code and found my problem. When I hit F3
to end the debugging,
Presumably the OP refers to the source debugger, and the function
defined as F3=End Program; i.e. not F3="end the debugging".?
The help text for F3=End Program in the Display Module Source
(DSPMODSRC) suggests a caveat, that [emphasis mine] "If this function
key is used for a program running in a job being serviced, the program
is *not ended*. The debugger returns to the previous menu or display."
However I am not too clear on the implication for the meaning of the
"returns to …", but…
it instead did a "resume", stopping on a later
break point. I hit F3 again and it did the same thing.
Using the green-screen debugger, while servicing another job [per
Start Service Job (STRSRVJOB)], I have seen the /same effect/ for use of
the F3 within DSPMODSRC; i.e. the effect from having pressed F3 is
indistinguishable from the effect of F12=Resume.
When I tried to do a SysReq 2 to end it, it told me it couldn't
(forget the exact message).
In my case, the ENDRQS would fail with msg CPF7121 F/QTECCNRQ
T/QMNSYSRQ "End request is not allowed."
This was a "production support" profile and not my normal developer
profile. Since my developer profile works correctly, what option have
they set on the production support profile that prevents this from
working and why would you ever want an F3 in a debugging session to
resume instead of exiting?
The effect is presumably the same as what I have seen, whereby the
issue arises per an environment of servicing another job, rather than
arising per an attribute of the user profile. That is to suggest, that
the F3=Exit Program works as-expected, at least intuitively, while
debugging within an interactive job, but does not function /similarly/
when servicing another [interactive] job. And frustratingly, does not
function as one might expect, but probably, ironically, because the
effect of End Program in the serviced job was deemed an /unfriendly/ effect.
I am not sure, but I think the described effect occurs only when the
debugger had presented the DSPMODSRC via an event for the serviced job
hitting the statement with the breakpoint.
I am also unsure, if the issue may _not_ occur when, if instead, I
had left my debugging job on the Display Module Source panel when that
event occurred; i.e. the effect did not require first opening the
DspModSrc panel group QGTEPDBG. But in that case, I also have seen an
effect of msg CPF1907 F/QTECCNRQ "Last request at level &1 ended." and
even worse consequences whereby the debugged job will /hang/ on that
breakpoint; the recovery from that is either to end the serviced job or
have the other interactive job issue the ENDRQS :-(
Anyhow, I typically get past the issue of the F3 not exiting, by
[first] removing all of the breakpoints [and\]or ending debug for the
module, thus allowing the serviced job continue without any breakpoints:
F13=Work With Module Breakpoints -- within DSPMODSRC
4=Clear -- against all break points
Enter -- to effect the clear of all
F12=Resume -- returns to command-line
ENDDBG
Removing the module from debug and\or by ending debug is probably
simpler; no need to know\list break points nor select an action against
them from a list:
F14=Work With Module List -- shows what is being debugged
4=Remove Program -- against the module\pgm being debugged
Enter -- CPF9C26 "Program &1 removed from source debugger."
F12=Cancel [or F3=Exit] -- returns to empty source listing
F12=Resume [or F3=End Program] -- returns to command-line
ENDDBG
midrange.com
