Well, you can debug it the old-school way too (I shudder).
Let's say you have to emulator sessions up, let's call them session A &
session B. To debug it you'd do:
1) on session A, DSPJOB and note down job number, user & name
2) on session B, STRSRVJOB <noted job number>/<noted job user>/<noted job
3) on session B, STRDBG <UDF library>/<UDF external name, generated by IBM
compile of your SQL source code>
4) on session B, set a breakpoint at the start of the generated C source
code. Entry point for C code is usually a "main" routine, but in case of
this service program there will be only one function, so set a breakpoint
there. Once you set the breakpoint hit F12.
5) on session A, STRSQL & invoke your UDF as you've been doing
6) session B will break when your UDF is invoked in session A. Debug from
this point on to figure out why it's returning a NULL.
NOTE: debugging OS generated C code is NOT fun and I'm primarily a C
Lobby your boss for beefier PC and load latest V5R4 iNav service pack on
your box. I'll talk to your boss if you need support :)
2007 System i Fall Technical Conference | Orlando | November 4-7
Celebrating 10-Years of SQL Performance Excellence on IBM i5/OS and OS/400
Subject: RE: First SQL UDF
Yes, I'm positive about the UDF.
I even changed the name and added it again.
I don't have iNav's debugger (at least one that works). My navigator never
worked. I complained and was told to wait for the new System i.
This mailing list archive is Copyright 1997-2019 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