Example: Add logMsg() to the sample UDF

As one method of a debugging, this example uses logMsg() to validate that a certain area of the sample function customername is reached. The new code is shown in bold:

virtual ReturnValue evaluate()
{
    StringArg *str; // 3
    str = stringArg(0); // 4

    int lengths = str->length; // 6
    char *datas = str->data; // 7

    int32 retval = 1;

if (lengths >= 10)
       if (memcmp("Customer A",datas,10) == 0)
         {
          logMsg(LOG_DEBUG, "Found a match of length %d\n", lengths);
                  // 14
          retval = 1;
         }
    NZ_UDX_RETURN_INT32(retval); // 17
}

After you change a UDX to add logMsg() calls, you must recompile and re-register it. To recompile the function:

nzudxcompile customername.cpp –o customername.o

To re-register the function:

CREATE OR REPLACE FUNCTION CustomerName(varchar(64000))
RETURNS int4 LANGUAGE cpp PARAMETER STYLE npsgeneric
EXTERNAL CLASS NAME 'CCustomerName'
EXTERNAL HOST OBJECT '/home/nz/myfirstudx/customername.o_x86'
EXTERNAL SPU OBJECT '/home/nz/myfirstudx/customername.o_spu10';

After you re-register the function, you set the log verbosity for the function by altering the function by using Netezza Performance Server SQL commands:

ALTER FUNCTION CustomerName(varchar(64000)) LOGMASK DEBUG,TRACE;

The values for LOGMASK can be NONE, DEBUG, TRACE, or both DEBUG, TRACE. The value NONE disables output; DEBUG outputs any calls to logMsg() that contain LOG_DEBUG; TRACE outputs any messages with LOG_TRACE as the flag; DEBUG, TRACE outputs messages that have either or both DEBUG and TRACE flags.

If you use the --file argument of the nzudxdbg command, the output messages are written to the standard log files. Log the messages to files to help with debugging and comparisons of the output messages after the test runs.

After you enable the LOGMASK, if you want the message output from the UDX to display in your terminal or shell window, you must stop and restart the database. To stop and restart the Netezza Performance Server database without disconnecting any Netezza Performance Server processes:

nzstop
nzstart -i

You do not have to restart the database after each time you change the function, only after the first time that you enable message logging in that specific terminal window.

Use the nzudxdbg command to enable message logging:

nzudxdbg --user admin --pw password -–on --file

Then, run the query again as follows:

select * from customers where CustomerName(b) = 1;

You see log messages like the following in the sysmgr.log log file and optionally the shell window in which you ran nzstart –i:

(event002.1001) [d,udx ] Found a match of length 12
(event002.1003) [d,udx ] Found a match of length 10

The (event002.1001) identifies where the function was run. It means that it was in process event002 on the SPU with hardware ID 1001 (or 1003 in the second message).

To see the log message output for the function when it runs on the host, run the query:

select x.*, customername(x.b) from customers x, customers y;

The log messages are similar to the following messages:

07-24-07 16:29:07 (dbos.24072) [d,udx ] Found a match of length 10
07-24-07 16:29:07 (dbos.24072) [d,udx ] Found a match of length 10
07-24-07 16:29:07 (dbos.24072) [d,udx ] Found a match of length 10
07-24-07 16:29:07 (dbos.24072) [d,udx ] Found a match of length 12
07-24-07 16:29:07 (dbos.24072) [d,udx ] Found a match of length 12
07-24-07 16:29:07 (dbos.24072) [d,udx ] Found a match of length 12
07-24-07 16:29:07 (dbos.24072) [d,udx ] Found a match of length 12

The (dbos.24072) value indicates that the message occurred in the dbos process with process ID (pid) 24072.