Re: Help with debugging external UDF

Makes no sense to me.
Mine is an RPGLE UDF for which debug breakpoints appear on one machine but not on others for exactly the same *SRVPGM.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of RBD
Sent: Saturday, 9 March 2013 5:39 a.m.
To: Midrange Systems Technical Discussion
Subject: Re: Help with debugging external UDF

http://www.ibm.com/developerworks/forums/thread.jspa?threadID=471738&tstart=0

Here's the link to this issue on the IBM website. They basically said that there is a bug, but then pretty much just dropped it.

Sent from my iPhone

On Mar 8, 2013, at 8:20 AM, CRPence <CRPbottle@xxxxxxxxx> wrote:

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=149429
20

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.

--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.

#####################################################################################

This correspondence is for the named person's use only. It may contain confidential
or legally privileged information, or both. No confidentiality or privilege is waived
or lost by any mistransmission. If you receive this correspondence in error, please
immediately delete it from your system and notify the sender. You must not disclose,
copy or rely on any part of this correspondence if you are not the intended recipient.
Any views expressed in this message are those of the individual sender, except where
the sender expressly, and with authority, states them to be the views of Veda.
If you need assistance, please contact Veda on either :-
Australia 1300-762-207 or New Zealand +64 9 367 6200
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.