Re: RDi 9.0.1 How to debug UDTF with SEP?

It's really pretty simple. STRDBG doesn't terminate the debug session
whereas RDi (by default) will end it when the program completes. (As
pointed out, this can be overridden with the 'Terminate debug session when
program completes' setting.)

In the default (where the debug session is terminated), the communication
can't be quick enough while RDi shuts down the debugging, etc. to be ready
to start another debug session when the SEP is hit again. i.e., The
program is called too quickly the second time. There are a whole slew of
things that happen when the debug session ends. If a job is already being
serviced, you can't start servicing it again (STRSRVJOB). The developers
had to choose to either terminate the debug session or leave it active.
They made the good choice of what fits for most cases. But they also were
wise enough and kind enough to give us the control to change that behavior
when we need it. When you uncheck the 'Terminate debug....' setting, the
session remains active so the program will break the next time it is
called.

STRDBG (green screen) you always have to terminate the servicing of the
job. (i.e., You have to enter the ENDSRVJOB command yourself.)

Way too wordy. I've got to get better at it, but I hope that clarifies
the problem.

wdsci-l-bounces@xxxxxxxxxxxx wrote on 01/28/2014 01:00:03 PM:

----- Message from Buck Calabro <kc2hiz@xxxxxxxxx> on Tue, 28 Jan
2014 10:27:15 -0500 -----

To:

wdsci-l@xxxxxxxxxxxx

Subject:

Re: [WDSCI-L] RDi 9.0.1 How to debug UDTF with SEP?

On 1/28/2014 12:54 AM, CRPence wrote:

On 27-Jan-2014 14:36 -0800, Buck Calabro wrote:

On 1/27/2014 4:43 PM, Charles Wilt wrote:

On 27-Jan-2014 12:30 -0800, Buck Calabro wrote:

<<SNIP>> The RPG program runs, fires the SEP debugger, and I can
step through the 'open' section with no problem. The RPG does the
return (as expected) and then the SEP debugger reports that the
program terminated and the results show up in the SQL Navigator
window! I expected that the SEP debugger would go through at
least one each of 'open', 'fetch' and 'close', since the program
itself did, but that doesn't happen.

Recap: The UDTF works fine. It does get called multiple times
and the program code physically executes, as I can see the
results. The SEP debugger only stops during the first pass
through the program. The green screen debugger STRDBG works as
expected (stopping during every invocation of the program).

Isn't that a limitation of OS itself?

AFAIK, you've never been able to set the SEP on a called program if
that called program is called multiple times with simple RETURN
between calls....

I can't seem to find the documentation for it...but I know I've
seen it (and experienced it! )

The implication being, I suppose, could be that the program is not
_activated_ on those later invocations. The path through the LIC AI
Activation\Invocation processing would be different between a new
activation of the program and reentry to a program that was not
previously deactivated. However I suggest an alternate possibility
below [see: for the SBREAK], unrelated to return without deactivation.

Ah, I never thought of that. I wonder why STRDBG can handle it...
Glad I posted here rather than opening a PMR.

Just some thoughts... feel welcome to just ignore; I have no
experience using SEP from RDi and very little experience using SBREAK.

Not sure what "STRDBG can handle it" means, because we do not know
what was done with Start Debug.

In the interest of clarity for the archives, I didn't use SBREAK, only
simple stepping through the code via F10. When the first CALL reaches
the end of main procedure, the RPG program returns to the DB manager
(for lack of better vocabulary). The DB checks the SQLSTATE in the
parameter list, and seeing that it is set to 'normal', then CALLs the
RPG program again - this time with 'call type' set to 'fetch' (0). It
is at this point the behaviours of STRDBG and SEP diverge. With STRDBG,
the debug window pops up as one might expect and I continue stepping
through the code. With SEP, the program never pops up - it runs to true
termination (LR on) with the debug never being effected again.

The program being debugged is not a service program; it's a main cycle
program.

Another possible nuance is that the SEP registration may have been

in

effect only for the primary thread. And it is possible the "open"
feature of the UDTF ran in the initial thread, but the other actions

of

"fetch" and "close" performed in secondary thread(s).
<

http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/apis/xtepseph.htm>

_Service Entry Point Stop Handler Exit Program_
"... Threads debugging is supported if a service job is used to debug

a

job that was spawned by native threads support. For nonthreaded
applications, the thread ID passed will always be that of the initial
job thread. ..."

An interesting line of thought. I tried it with and without
thread(*serialize), but SEP did not break on the second and subsequent
CALLs.

Mark A posted the solution: Preferences > Run/Debug > IBM i Debug,
uncheck 'Terminate debug session on program completion'.

--buck