Re: RDP Debug when STRDBG active

On 3/5/2013 11:24 AM, Anderson, Kurt wrote:

While I love RDP, I haven't moved from STRDBG over to debugging from within RDP. I have a program issue and I thought I'd give RDP's debug a try.

We have test jobs setup that automatically run STRDBG to prevent updating of production libraries. Using StrDbg, when it hits that line I get an error I can ignore. Now, when I set the SEP in a RPG source, which is a program called by the CL that executes STRDBG (among other things), the debug view is never coming up. I tried adding a SEP to the CL before the STRDBG gets hit, and when that happens, I get an error and can hit ignore, but for some reason it's not entering the RPG code for me to debug. In the RPG program I set the breakpoint at the very beginning to make sure I wasn't running into an issue where the statement I put a breakpoint on wasn't getting called. I just now set a breakpoint in the CL after the STRDBG statement, and it doesn't break.

This would never have occurred to me. It's a last resort sort of thing
intended to catch the odd 'oops!' when setting up the library list for
testing, right? I never tried debugging a program that another process
has put into debug before but I can confirm your observation here on RDp
8.5.1, IBM i 7.1.

If I start a SEP on an RPGLE program and call it from the green screen,
RDp pops up the debugger view and positions the cursor on the first line
of code. No need to set breakpoints in advance. Let that run to
completion, then call a CL program that has a STRDBG UPDPROD(*NO) just
before the CALL to my RPGLE program and call the CLP on the green
screen. It processes without stepping into RDp. Again, leaving RDp
as-is, CALL the RPGLE from green screen and it breaks into debug as
expected.

I've now spent about 45min on this and feel like I've had no success. I know our method of testing (using a mix of production and test libraries) isn't going to change. Are there any other suggestions as to what I might try?

I think you're stuck if you're really locked in to the current
methodology. Personally, I use a test user profile which has no
authority to update the production files. That way I can't accidentally
commit an 'oops!' when setting up my test environment say with SQL.

We can set UPDPROD(*NO) in RDp but that won't get you going until you
delete the STRDBG from your CLP. Then you'd be worried about the green
screen debugging being done by your colleagues. I'd write (if so
forced!) a new command that uses the Retrieve Debug Attribute
(QteRetrieveDebugAttribute) API. If already in debug, don't do a
STRDBG, else issue one. Could also check to see if in UPDPROD(*NO) or not.

Hope this starts the discussion.
--buck