>>> I'm trying to debug a simple Java UDF written in the DB2General style
>>> within Eclipse.
[quoted text clipped - 16 lines]
>>> characaters of a String works fine but it is written in style "Java" and
>>> is therefore missing the set() method.
---------------------------------------------------------------------------------------------------------------------
>>> public void leftmost(String input, int size, String output) throws
>>> Exception {
[quoted text clipped - 5 lines]
>>> set(3, leftmost);
>>> }
---------------------------------------------------------------------------------------------------------------------
>> How did you register the function in your database, i.e. what's the exact
>> CREATE FUNCTION statement?
[quoted text clipped - 44 lines]
> source code for leftmost(), as written for parameter style Java, stripped
> to its bare bones:
---------------------------------------------------------------------------------------------------------------------
> public static String leftmost(String input, int size) throws
> SQLException {
[quoted text clipped - 8 lines]
> "38600");
> }
---------------------------------------------------------------------------------------------------------------------
> However, when I use the code shown in the first post of this thread and I
> replace the definition of the leftmost() function with this:
[quoted text clipped - 5 lines]
> SPECIFIC leftmost
> EXTERNAL NAME 'TextUDFs_DB2General:com.foo.db2general.TextUDFs.leftmost'
You're using a JAR file here. Have you packaged your Java code into such a
JAR file and used the SQLJ.INSTALL_JAR procedure to load it into the
database?
> LANGUAGE JAVA
> PARAMETER STYLE DB2GENERAL
[quoted text clipped - 13 lines]
> of the method during debugging in Eclipse. The function still works just
> fine from the command line.
You mean that you can call the SQL function in a SQL statement executed on
the command line? And it fails if you debug it through Eclipse?
> Do you have any idea what I need to change in order to be able to debug my
> function in Eclipse and step through all of the statements, _including_
> the set()?
I don't know for sure. One guess might be that you don't have all the
necessary files/directories in the CLASSPATH.
> I can always write diagnostic lines to a logging file if I have to for
> debugging purposes but I'd rather just use Eclipse if that is possible. It
> is considerably less cumbersome to simply step through the real code with
> a good debugger than it is to add diagnostic code to my program.
Debugging UDFs and procedures is, unfortunately, not a straight forward task
due to the complex environments. I've done this quite often for C/C++ code
but not yet for Java.
What you could also do is to write a "main" function wrapper in Java that
calls your routine directly, taking DB2 out of the picture.

Signature
Knut Stolze
DB2 Information Integration Development
IBM Germany
Rhino - 07 May 2006 18:25 GMT
>>>> I'm trying to debug a simple Java UDF written in the DB2General style
>>>> within Eclipse.
[quoted text clipped - 135 lines]
> You mean that you can call the SQL function in a SQL statement executed on
> the command line? And it fails if you debug it through Eclipse?
Sorry for the delay in responding. I checked for a reply from you several
times over the days after I last posted to this thread but after several
attempts there was no reply so I thought the thread had died. I finally
checked again a minute ago and now I see that you must have replied just
after I gave up on hearing from you. I'm not sure if you'll see this reply;
you've probably given up on ME by now!
Okay, now back to the problem. Yes, I can call the SQL function in an SQL
statement executed on the command line but it fails on the set() method if I
debug it through Eclipse.
>> Do you have any idea what I need to change in order to be able to debug
>> my
[quoted text clipped - 3 lines]
> I don't know for sure. One guess might be that you don't have all the
> necessary files/directories in the CLASSPATH.
Do you have any idea what files/directories need to be on the CLASSPATH for
this to work? UnsatisfiedLinkError suggests a missing DLL but I have no idea
what DLL it is looking for; whoever did the error handling code for this
class didn't see fit to identify whatever was missing in the error message.
>> I can always write diagnostic lines to a logging file if I have to for
>> debugging purposes but I'd rather just use Eclipse if that is possible.
[quoted text clipped - 10 lines]
> What you could also do is to write a "main" function wrapper in Java that
> calls your routine directly, taking DB2 out of the picture.
Actually, that's what I was trying to do when I encountered this problem.
I've tried a couple of times over the years to get the IBM Distributed
Debugger to work with stored procedures - I assume it works with UDFs too
but I'm not sure - but I could never get it to work. When I posted to this
newsgroup about the problems I was having, the responses I got never helped
me enough to get that debugger working.
On March 1 2005, I posted about something I'd seen in the manuals which
suggested a way to debug a UDF with a driver program; I asked for details on
what that driver would need to contain. After getting some general remarks,
I posted my best guess on what the driver needed and you jumped in to
suggest a much simpler driver.
Two weeks ago, I had an offline enquiry from someone who'd seen that thread
and wondered if I ever got Eclipse to debug my UDF successfully. Frankly,
I'd forgotten about the whole matter so I started looking at my code from
last year and reviewed the thread and your reply.
I found that I could debug Parameter Style Java UDFs fine but got the
UnsatisfiedLinkError when I got to the set() method in the Parameter Style
DB2General UDFs. So I started this thread to see if I could get some help to
figure out the problem.
Here are the relevant parts of the Driver program. (I'm running DB2 V8.2.1
these days, not V7.2):
---------------------------------------------------------------------------------------------------------------------
import java.sql.SQLException;
public class UdfDriverV8 {
public static void main(String[] args) {
new UdfDriverV8();
}
public UdfDriverV8(); {
testLeftmost_Java();
testLeftmost_DB2General();
}
public void testLeftmost_Java() {
System.out.println("\nUDF: leftmost()");
String input = "abcdefghijk";
System.out.println(" Input String: " + input);
int size = 3;
System.out.println(" Characters to return: " + size);
String output = null;
try {
output = com.foo.db2v8.udf.java.TextUDFs.leftmost(input, size);
} catch (SQLException sql_excp) {
System.err.println("UdfDriverV8 caught SQLException. Message: "
+ sql_excp.getMessage());
sql_excp.printStackTrace();
}
System.out.println(" Output String: " + output);
}
public void testLeftmost_DB2General() {
System.out.println("\nUDF: leftmost()");
String input = "abcdefghijk";
System.out.println(" Input String: " + input);
int size = 3;
System.out.println(" Characters to return: " + size);
String output = null;
try {
com.foo.db2v8.db2general.TextUDFs textUDFs = new
com.foo.db2v8.db2general.TextUDFs();
textUDFs.leftmost(input, size, output);
} catch (Exception excp) {
System.err.println("UdfDriverV8 caught Exception. Message: " +
excp.getMessage());
excp.printStackTrace();
}
System.out.println(" Output String: " + output);
}
}
---------------------------------------------------------------------------------------------------------------------
This is the code for the Parameter Style Java version of the UDF, which
works fine and can be debugged in Eclipse:
---------------------------------------------------------------------------------------------------------------------
package com.foo.db2v8.udf.java;
public class TextUDFs extends UDF {
public static String leftmost(String input, int size) throws
SQLException {
try {
String trimmedInput = input.trim();
if (trimmedInput.length() < size) size = trimmedInput.length();
String output = trimmedInput.substring(0, size);
return (output);
} catch (Exception excp) {
throw new SQLException("leftmost() - " + excp.getMessage(),
"38600");
}
}
}
---------------------------------------------------------------------------------------------------------------------
This is the code for the Parameter Style DB2General version of the UDF,
which works fine and can ALMOST be debugged in Eclipse, except that I get
UnsatisfiedLinkError when I step onto the set() method:
---------------------------------------------------------------------------------------------------------------------
package come.foo.db2v8.udf.db2general;
public class TextUDFs extends UDF {
public void leftmost(String input, int size, String output) throws
Exception {
String trimmedInput = input.trim();
if (trimmedInput.length() < size) size = trimmedInput.length();
String leftmost = trimmedInput.substring(0, size);
set(3, leftmost); //UnsatisfiedLinkError on this line
}
}
---------------------------------------------------------------------------------------------------------------------
Important: All of the source code for both the driver and both versions of
the UDF compiles without any problems so Eclipse can clearly 'see'
everything it needs to compile. I only run into trouble when debugging the
DB2GENERAL UDF.
This is the CREATE FUNCTION statement for the Parameter Style Java version
of the UDF:
---------------------------------------------------------------------------------------------------------------------
CREATE FUNCTION leftmost (varchar(4000), int)
RETURNS varchar(4000)
SPECIFIC leftmost
EXTERNAL NAME 'TextUDFs_Java:com.foo.db2v8.udf.java.TextUDFs.leftmost'
LANGUAGE JAVA
PARAMETER STYLE JAVA
DETERMINISTIC
NO EXTERNAL ACTION
FENCED
RETURNS NULL ON NULL INPUT
ALLOW PARALLEL
NO DBINFO
NO SQL
NO SCRATCHPAD
NO FINAL CALL;
---------------------------------------------------------------------------------------------------------------------
This is the CREATE FUNCTION statement for the Parameter Style DB2General
version of the UDF:
---------------------------------------------------------------------------------------------------------------------
CREATE FUNCTION leftmost (varchar(4000), int)
RETURNS varchar(4000)
SPECIFIC leftmost
EXTERNAL NAME
'TextUDFs_DB2General:com.foo.db2v8.udf.db2general.TextUDFs.leftmost'
LANGUAGE JAVA
PARAMETER STYLE DB2GENERAL
DETERMINISTIC
NO EXTERNAL ACTION
FENCED
RETURNS NULL ON NULL INPUT
ALLOW PARALLEL
NO DBINFO
NO SQL
NO SCRATCHPAD
NO FINAL CALL;
---------------------------------------------------------------------------------------------------------------------
Is there any other information I can provide that would help you or anyone
else figure out how to solve my UnsatisfiedLinkError?
I'm completely baffled by this problem. I have no idea what Java thinks it
is missing so I don't know how to make the missing resource available to
Eclipse. Everything compiles fine so everything Eclipse needs seems to be
available yet I get this runtime error.
--
Rhino
Knut Stolze - 10 May 2006 11:26 GMT
> Do you have any idea what files/directories need to be on the CLASSPATH
> for this to work? UnsatisfiedLinkError suggests a missing DLL but I have
> no idea what DLL it is looking for; whoever did the error handling code
> for this class didn't see fit to identify whatever was missing in the
> error message.
The good news is that I can reproduce the problem in Eclipse. After all,
the issue is completely unrelated to DB2, except that you try to call a
method in the UDF class.
The bad news is this: The various "set" methods (and a bunch of others) are
native Java methods. When DB2 starts a JVM, it takes care to register the
C/C++ functions that correspond to the Java methods using the proper calls
to RegisterNatives() (in the C side).
I don't know if and how you could do the registration from the Java side.
If it is possible, you still have to figure out the respective mapping.
The native implementations for the "set" methods can be found in the
"libdb2jext" library. This has to be loaded and then the method "set(int,
String)" maps to the C function sqlejNMudf_setString, for example.
This is all rather cumbersome, and my suggestion would be to not use the DB2
classes COM.ibm.db2.app.* for your purposes but rather implement your own
variations as some sort of dummy driver. Then you can write some log
information once such a method is invoked and, at the same time, you avoid
the UnsatisfiedLinkException originating from the missing library/native
function linkage.
p.s: Note that another problem is that DB2 will verify that the methods in
the UDF class are only called when a UDF invocation is underway.
Otherwise, an exception is thrown. If this would apply to your debug
scenario. I do not know for sure.

Signature
Knut Stolze
DB2 Information Integration Development
IBM Germany
Rhino - 10 May 2006 14:48 GMT
>> Do you have any idea what files/directories need to be on the CLASSPATH
>> for this to work? UnsatisfiedLinkError suggests a missing DLL but I have
[quoted text clipped - 5 lines]
> the issue is completely unrelated to DB2, except that you try to call a
> method in the UDF class.
I'm glad to hear that you duplicated my problem; at least the nature of my
problem is now clear.
> The bad news is this: The various "set" methods (and a bunch of others)
> are
[quoted text clipped - 20 lines]
> Otherwise, an exception is thrown. If this would apply to your debug
> scenario. I do not know for sure.
Thank you for all your efforts in understanding and explaining why this
approach is so problematic!
It is very disappointing that this approach will not work nearly as easily
as it first appeared but at least I have an idea on how it can be done now.
I doubt that I will take either approach - doing my own registrations of the
native functions or writing dummy drivers - but at least these are options
if I really get stuck on debugging my UDFs. Registering the native functions
myself looks like it will take considerable time and will require me to buy
an expensive C/C++ compiler. Writing dummy functions to prevent the link
error is likely to be a lot of work too since there are many functions.
It's easier to stay with my old approach of writing lines to a simple log
file and debuggng my UDFs and stored procedures that way. It's not as slick
as using a modern debugger but it works fine without having to do all the
work implied by registering all those functions or writing dummy functions.
Or maybe I'll try once again to get the IBM Distributed Debugger to run
correctly for me, although that would be a lot more tempting if I could
actually get free support for it somewhere.
I wish I knew how to persuade IBM to provide friendlier ways of debugging
UDFs and stored procedures in modern debuggers!
Again, thanks for your help with this, Knut!
--
Rhino