Re: 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