Debugging an SQL UDF

["Peter Dow" <pcdow@xxxxxxxxx>]

Hi Buck,

I wrote a procedure called FMTBIGINT in an RPGLE service program named
FORMAT, compiled it, did the CREATE FUNCTION in SQL, then did a SELECT to
try it out.  It didn't work the first time, so I wanted to debug it.  From
the interactive job where I'd done the STRSQL, I did STRDBG UPDPROD(*YES)
SRVPGM(FORMAT), then ran the SELECT, and got lots of "Breakpoint received in
secondary thread." messages.

At that point I checked the archives and found that a year and a week ago,
you'd run into the same problem, and I'd responded with some stuff from the
Info Center, and you replied you needed to do more research, and you'd post
the results. I didn't see any further posts on it, so my additional research
consisted of hitting the F1 key on one of those "Breakpoint received..."
messages and reading the following:

Recovery  . . . :   To debug this breakpoint, this job must be debugged from
a
  servicing job. First, do End Debug (ENDDBG) in this job. Next, do Start
  Service Job (STRSRVJOB JOB(352249/CC_PGMPCD/PDOWS2)). Finally, do Start
  Debug (STRDBG) from where the STRSRVJOB was done.

I copied & pasted the STRSRVJOB stuff into a second interactive job on the
same box, followed by the STRDBG UPDPROD(*YES) SRVPGM(FORMAT), went back to
the first session and restarted the SELECT, and voila! my 2nd interactive
session stopped at the breakpoint I'd set.  A lot simpler than the Info
Center made it sound.

Hope that helps anyone trying to do the same.

Peter Dow
Dow Software Services, Inc.
909 425-0194 voice
909 425-0196 fax



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com