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 >>> firstname.lastname@example.org 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
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.