Another thing you could do now that I think about it if you're coding in
PARAMETER STYLE JAVA.

Write a JAVA application that calls your UDF method DIRECTLY and passes
in different values.  So long as both are compiled in debug mode, you
should just be able to start up the application under the debugger and
have at it.

For instance (pseudocode):

public static void main(string argv[])
{
    for (i < number of times you want to execute the UDF)
    {
        value = yourclassname.yourmethodname(firstarg[i],
                        secondarg[i], ...);
        System.out.println(value);
    }
}

This is essentially what DB2 would do if you're calling the UDF within a
 SELECT query, where <number of times you ant to execute the UDF> is
the number of rows returned by the query.

However, this is useless if you're using PARAMETER STYLE DB2GENERAL due
to how the processing for that style ties back into the DB2 architecture
through the inherited UDF class.  In that case what you're doing is
probably the best way to do it.

Hmmm, maybe I was too hasty in taking those System.exit() calls out of my
UDFs....

I was doing a System.exit() within the catch logic for each of the three
methods that work with the log file; createFile(), writeFile() and
closeFile(). Here are all three methods:

  static public BufferedWriter createFile(String path, String fileName) {

       /* Define the buffered writer. */
       BufferedWriter bufferedWriter = null;

       try {
           /*
            * See if the output directory exists; if it doesn't, create it
and
            * any needed parent directories.
            */
           File outputPath = new File(path);
           System.out.println("outputPath=" + outputPath);
           if (!outputPath.exists()) {
               outputPath.mkdirs();
           }

           /* See if the output file exists; if it doesn't, create it. */
           outputFile = new File(outputPath, fileName);
           System.out.println("outputFile=" + outputFile);
           if (!outputFile.exists()) {
               outputFile.createNewFile();
           }

           /* Create the file, indicating that we will be appending to it.
*/
           FileWriter fileWriter = new FileWriter(path + File.separator +
fileName, true);
           bufferedWriter = new BufferedWriter(fileWriter);
       } catch (SecurityException s_excp) {
           System.out.println("SecurityException encountered. Message: " +
s_excp.getMessage());
           s_excp.printStackTrace();
           System.exit(16);
       } catch (IOException io_excp) {
           System.out.println("IOException encountered. Message: " +
io_excp.getMessage());
           io_excp.printStackTrace();
           System.exit(16);
       }

       return (bufferedWriter);
   }

   static public void writeToFile(BufferedWriter outputFile, String
oneLine) {

    try {
     outputFile.write(oneLine);
     outputFile.newLine();
     }
    catch (IOException io_excp) {
     System.out.println("IOException encountered while writing line '" +
oneLine +
      "' to file " + outputFile + ".\nMessage: " + io_excp);
     io_excp.printStackTrace();
     System.exit(16);
     }

   }

   static public void closeFile(BufferedWriter outputFile) {

    try {
     outputFile.flush();
     outputFile.close();
     }
    catch (IOException io_excp) {
     System.err.println("IOException encountered while closing file " +
      outputFile + ".\nMessage: " + io_excp);
     io_excp.printStackTrace();
     System.exit(16);
     }
   }

I deliberately specified the path to the log file as being on drive Z: of my
Windows XP machine - I don't have a drive Z: - and ran the code exactly as
you see here to see how it would respond to the error. Strangely enough, it
got all the way through the createFile() method without a hiccup but crashed
on a NullPointerException in the writeFile() method; the stacktrace was
written to db2diag.log. I got an SQL4302 in the first statement that tried
to invoke the UDF. I got SQL4301 Reason Code 4 on each subsequent invocation
of the function.

When I followed your advice and removed the System.exit() calls from the
catch logic of each method, I got an SQL0440N (No such function) at each
invocation of the function. That is nonsense because I had just finished
generating the function again and got green lights on every step. Nothing
was written to db2diag.log either.

I like the behaviour of the function a LOT better when the System.exit(16)
was in each catch block!

Do you have any idea how to this is working? I'm baffled by why the
createFile() method is working and that bothers me; it should have failed.
But aside from that, I'm getting behaviour I can live with when I leave the
System.exit() in the catch blocks. The behaviour when I omit them is not
tolerable to me because it is very misleading.

Mind you, I'd prefer different behaviour altogether if I could figure out
how to get it: I'd like to get a specific message that says something like
"I/O Error in function foo(): Couldn't open log file because Drive Z: does
not exist." But If I can't get that, I'll take SQL4302 with a stacktrace in
db2diag.log over a bogus SQL0440N any time ;-)

Any ideas?

Rhino