Re: Debugging an SQL UDF

Peter,

That is timely, last week Midrange Server ran a tip on
debugging UDFs and stored procedures Here is
a link to that tip:

http://www.midrangeserver.com/guruo/mgo012502-story01.html

David Morris

>>> pcdow@yahoo.com 01/30/02 07:05PM >>>
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