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. With the STRDBG we might infer that
only the SBREAK was used, the effective equivalent to Service Entry
Point (SEP) debug breakpoint. Yet also to infer it worked differently
than SEP debug... apparently because the debug started with STRDBG
apparently /broke/ upon each new invocation regardless those after the
first were reentry vs new activations? But in most instructions I have
read, either F6=Add Breakpoint or BREAK line-number is an additional
action when using green-screen debug; those would be in addition to just
SBREAK, and could cause a breakpoint event upon each new invocation
across the different types open\fetch\close. In both cases, we should
presume that the Start Service Job (STRSRVJOB) was utilized; not only is
that the way the feature is presented, but also because the ability of
breakpoints in STRDBG to function properly against a UDF is inhibited by
the use of multithreading by the database query\SQL to implement UDFs.
Rather than an activation nuance however, perhaps the SBREAK
documentation covers the situation. Was use of the SBREAK what\how the
breakpoint was apparently functional or "handled" as expected? Anyhow,
for the SBREAK, "The breakpoint is only signaled when the job within
which the service entry point was hit is not currently under debug." See:
<
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rbam6/dbpgm.htm>
IBM i 7.1 Information Center -> Programming -> Control language ->
Debugging CL programs and procedures -> Debugging ILE programs
_Debug commands_
"...
Table 1. ILE source debugger commands
_Debug command_ Description
... ...
_BREAK_ Permits you to enter either an unconditional or
conditional breakpoint at a position in the program being tested. Use
BREAK position WHEN expression to enter a conditional breakpoint.
_SBREAK_ Permits you to enter a service entry point at a
position in the program being tested. A service entry point is a type of
breakpoint established in a program to facilitate the system debugger in
gaining control of a spawned job. The breakpoint is only signaled when
the job within which the service entry point was hit is not currently
under debug.
... ...
..."
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. ..."
FWiW, somewhat unrelated, but of possible interest to avoid another
issue with debug of a SQL UDF [table or scalar]:
http://archive.midrange.com/midrange-l/201303/threads.html#00080
Subject: Help with debugging external UDF
http://archive.midrange.com/midrange-l/201303/msg00782.html
"For debugging an SQL UDF (nothing to do with external UDFs) I will
guess you are looking for SE54951 that has test PTF SI49512 released."
<
http://www-01.ibm.com/support/docview.wss?uid=nas22cc63e8d5a6873f586257b19004246dc>
"APAR SE54951 ... PTF R710 SI49512 3298 "
midrange.com
