On 07 Mar 2013 14:03, Thomas Garvey wrote:
<<SNIP>>
<ed: UDF DROP and CREATE: EXTERNAL NAME 'GARVEY/DATE2ISO(DATE2ISO)'>
I am trying to debug the function when it gets called by SQL, so I am
adding the Service Program (DT2ISOSRV) to my program list and setting
a break point (in DATE2ISO module).
The UDF was re-created using the qualified service program name.
Next STRSRVJOB was first issued against the job that will invoke the SQL
statement that will invoke the UDF. Then STRDBG SRVPGM(GARVEY/DATE2ISO)
[library-qualified], followed by adding a breakpoint to non-conditioned
mainline code in the module. So far so good. By any reasonable
expectation, the debugged job should cause the breakpoint to be hit.
And if not, that there is likely a defect; although in my experience,
always that remaining chance for a usage issue :-)
I know the function is getting called because my job log is
filled up with messages that the calls to CEEDATE (which is called
from within the function) are failing... <<SNIP>>
So it seems as expected even after the UDF is invoked. But... have
those errors that been verified to have been signaled to the expected
code [spooled joblog; or f1=help then F9=Additional]. Or by any chance
are those messages being signaled to some other\unexpected [version of
the] code?
The problem is that I can't get it to stop at my breakpoints.
Has any place other than the entry been chosen as a breakpoint? How
about a breakpoint on the return? While obviously too late to do much
of actual debugging, maybe it is only the entry that is not breaking.?
Similarly, any other non-conditioned or even some probable logical
branches in conditioned statements?
I suppose that I am probably setting breaks in something OTHER than
what is actually being called,
But knowing absolutely what code is being called by the SQL due to
its /function resolution/ whenever debug\addbkp is not assisting in that
endeavor, we would expect that the TRCJOB would reveal. Plus if the
processing runs long enough [e.g. the UDF is invoked enough times], then
there is also [repeated] refresh of the program stack which might reveal
what code is running; if it can be caught.
FWiW when I have had issues where breakpoints were not being hit but
the code was verified to be invoked [e.g. verified by tracing or program
stack], I would use debug and a breakpoint for a different program that
gets called _from_ my code [perhaps only as revealed by a trace] or use
ADDTRC with a small number of trace records allowed to force the
processing to stop somewhere.... then try adding that stopped
statement\instruction as a new breakpoint, or just start issuing debug
requests from that breakpoint, against the other executable. If debug
is really active and the program is really in the stack, then debug
statements [like the ADDTRC] can still be used against the active
program in the stack, even though stopped in a higher stack entry rather
than stopped where desired.
but I thought I dealt with that by dropping the function and then
CREATEing it again.
One would hope. But...
CRPence on Monday, March 04, 2013 5:38 PM wrote:
<<SNIP>> What specific version of the function being invoked is the
first thing to determine, then what that function defines to be
invoked. <<SNIP>>
Let's presume that DROP FUNCTION and CREATE FUNCTION with the
qualified reference to the Service Program suffices for the latter; i.e.
the SQL /function resolution/ is doing the right thing.
Eliminating the PATH as an issue and library-qualifying the
invocation of the function is the best means to ensure the former. Be
sure that the job performing the SQL has requested the UDF with:
GARVEY.DT2ISOSRV(arg1, arg2)
I did look at the SYSFUNCS and SYSROUTINES files and everything
looks correct.
Any thoughts?
I would guess what RBD suggests, could be a possible match. I
suppose the link that was not included in those replies by RBD, follows:
http://www.ibm.com/developerworks/forums/message.jspa?messageID=14942920
Unfortunately... that discussion divulges almost nothing from IBM.
The discussion subject and discussion topic is initially about EVAL.
The thread discusses only a SQL scalar UDF, not an External scalar UDF.
And, there is an implication that the issue with breakpoints would be
resolved by removing the SQL DECLARE EXIT HANDLER; something not apropos
of an EXTERNAL UDF. There is no mention of any APAR being opened nor
anything to track :-( and a search of APARs was not fruitful.
midrange.com
