Re: RDP Debug when STRDBG active

Mark,

In the logic I provided, if CHGDBG fails, it will STRDBG. If it succeeds, it will not call STRDBG. Your suggestion seems to leave STRDBG to always be called, which is what the issue presumably is. The way I have it now is actually nice when I do an interactive STRDBG in green screen - no longer errors on STRDBG as already being in debug mode.

Jim: Yep, all ILE here.

-----Original Message-----
From: wdsci-l-bounces@xxxxxxxxxxxx [mailto:wdsci-l-bounces@xxxxxxxxxxxx] On Behalf Of Mark S Waterbury
Sent: Tuesday, March 05, 2013 11:41 AM
To: Rational Developer for IBM i / Websphere Development Studio Client for System i & iSeries
Subject: Re: [WDSCI-L] RDP Debug when STRDBG active

Kurt:

I think this logic is flawed, because the CHGDBG will "work" and not throw an exception if you are debugging this program via RDp (an SEP), so "debug" is "active". =-O

Instead, try this:

Just remove the CHGDBG through the DEBUG: label and, immediately after your STRDBG statement, insert this:

MONMSG MSGID(CPF0000) EXEC(DO)
CHGDBG UPDPROD(*NO)
ENDDO

That way, if "debug is already active", you issue CHGDBG to ensure you have UPDPROD(*NO) specified.

I think that will accomplish your goal.

HTH,

Mark S. Waterbury

> On 3/5/2013 12:23 PM, Anderson, Kurt wrote:

Seemed like a good idea. Unfortunately this doesn't seem to work.

The first statement in my CL was changed to CHGDBG. In RDP I created a SEP for that program with a breakpoint on the CHGDBG statement. Unfortunately the statement ran w/o the breakpoint stopping on it. (In RDP I see the little blue square next to the line number after setting the breakpoint.)

Here is the debug code modified to use ChgDbg.
CHGDBG
MONMSG MSGID(CPF0000) EXEC(GOTO DEBUG)
GOTO CMDLBL(SKIPDEBUG)
Debug:
STRDBG PGM(TST_EDIT) UPDPROD(*NO)
SkipDebug:

The SEP brings up the CL and stops on the PGM line. I click resume (f8) and doesn't stop on the breakpoint. When I start the program and do Step Over, I see that it does execute CHGDBG, so I don't know why it's not breaking there. CHGDBG fails so it continues to STRDBG.

Well, I guess I've put enough time into this for today. I have a program issue to resolve...

Thanks for the feedback,
Kurt

-----Original Message-----
From: wdsci-l-bounces@xxxxxxxxxxxx
[mailto:wdsci-l-bounces@xxxxxxxxxxxx] On Behalf Of Dave Shaw
Sent: Tuesday, March 05, 2013 10:52 AM
To: Rational Developer for IBM i / Websphere Development Studio Client
for System i & iSeries
Subject: Re: [WDSCI-L] RDP Debug when STRDBG active

Are you allowed to change the CL? If so, you could condition the STRDBG so that it doesn't execute if the job is already in debug. I think a CHGDBG with no parameters will throw an error that you can monitor for to condition the STRDBG.

Dave Shaw
Mohawk Industries



----- Original Message ----
From: "Anderson, Kurt" <KAnderson@xxxxxxxxxxxx>
To: "Rational Developer for IBM i / Websphere Development Studio
Client for System i & iSeries (wdsci-l@xxxxxxxxxxxx)"
<wdsci-l@xxxxxxxxxxxx>
Sent: Tue, March 5, 2013 11:25:01 AM
Subject: [WDSCI-L] RDP Debug when STRDBG active

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.

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?

--
This is the Rational Developer for IBM i / Websphere Development
Studio Client for System i & iSeries (WDSCI-L) mailing list To post a
message email: WDSCI-L@xxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit: http://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/wdsci-l.

--
This is the Rational Developer for IBM i / Websphere Development Studio Client for System i & iSeries (WDSCI-L) mailing list To post a message email: WDSCI-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at http://archive.midrange.com/wdsci-l.