× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.