Problem running STRDBG

[Bruce Duty]

I'm re-learning the AS/400 after a hiatus of 4 years. I can't get some of
those things I used to do all the time to work now.
Case in point is STRDBG. I used to use this frequently but am now unable to
get it to work.

I ran:

STRDBG PGM(CL_EXER10B) TRCFULL(*WRAP) UPDPROD(*YES) OPMSRC(*YES)

and the following displays:
======================================================================
Display Module Source

Program: CL_EXER10B Library: BDUTYS
1 /* PROGRAM: CL_EXER10B
*
2 /*
*
3 /* PURPOSE: COPY DATA IN A COMPILE TIME ARRAY TO A PHYSICAL FILE
*
4 /*
*
5 /* PROGRAMMER: BRUCE B DUTY
*
6 /* DATE : 12/24/02
*
7
8 PGM
9 /*
*
10 CLRPFM FILE(BDUTYS/ADDR_FILE)
11 /************OVRDBF FILE(ADDRFILE) TOFILE(BDUTYS/ADDR_FILE) */
12 CALL PGM(BDUTYS/EXER10B) PARM(7.00000)
13 /*
*
14 ENDPGM

Bottom
Debug . . .

F3=End program F6=Add/Clear breakpoint F10=Step F11=Display variable
F12=Resume F17=Watch variable F18=Work with watch F24=More keys
======================================================================

Then I used F14 to add EXER10B to the debug session. When I hit F10 to step
through the CL program, it brings me back to the ready prompt.

I compiled the CL program with OPTION(*SRCDBG) and the RPG4 program with
OPTION(*SRCSTMT)

Any help appreciated.

Bruce Duty

[Steve Landess]

Bruce:

Debugging a program using STRDBG is a two-step process. Using your example:

1) Use STRDBG to place the program CL_EXER10B into debug mode. After using
F14 to add EXER10B to the debug session, place a '5' beside the EXER10B
module to view the module source for this program. While viewing the
"Display Module Source" screen for EXER10B, place the cursor on a line where
you want the program to break, and press F6 to set a breakpoint. Now press
F3 to exit the debugger, and go back to the command line. You are _still_
in debug mode.

I would also like to note at this point that if you _don't_ need to do any
debugging in CL_EXER10B, you _don't_ need to put it into debug mode. Simply
execute the command STRDBG PGM(EXER10B) TRCFULL(*WRAP) UPDPROD(*YES)
OPMSRC(*YES). When "Display Module Source" screen is displayed, place the
cursor on a line where you want the RPG program to break and press F6 to set
a breakpoint.

2) Now, on the command line, type CALL PGM(CL_EXER10B) (passing any
necessary parameters). The debugger will stop at the breakpoint that you
set in EXER10B. Now you can now use F10 to step through the RPG program.

HTH

Steve Landess
Austin, Texas
(512) 423-0935

"Bruce Duty" <bdu...@worldnet.att.net> wrote in message
news:bNOP9.19572$p_6.1...@bgtnsc04-news.ops.worldnet.att.net...

[Sivaprasad]

I guess you want the debugger to enter program EXER10B from the
calling CL program. Use F20 function key to step into the program
EXER10B {compiled with DBGVIEW(*SOURCE)}.

Siva

"Bruce Duty" <bdu...@worldnet.att.net> wrote in message news:<bNOP9.19572$p_6.1...@bgtnsc04-news.ops.worldnet.att.net>...

[Jonathan Ball]

Implied in the replies from Steve and Siva, but not
clearly stated, is that when you are FIRST in debug,
adding breakpoints and possibly other modules, the
program has NOT yet begun executing. If you press F10
from the initial DSPMODSRC display, you are simply
going to return to the command entry line from which
you initially ran STRDBG.

Two things to note:

1. If you don't add a breakpoint in one of your
modules while in the DSPMODSRC display, you'll
never get a chance to step through the programs.

2. You'll need at least one breakpoint in the called
program EXER10B if you want to step through in in
addition to stepping through the CL program.

That is, assume you have set a breakpoint at line 10 of
the CL program (CLRPFM). Then, you press F10, and the
program stops at line 12 (the call to EXER10B). If you
didn't add a breakpoint in EXER10B, and you press F10
again while stopped at the CALL, the next stopping
point will be line 14, the ENDPGM.

In fact, if you want to step through all of EXER10B,
you'll have to set a breakpoint at the first executable
line in it. If you set the first breakpoint in it at a
subsequent point, then, after pressing F10 when stopped
at line 12 in CL_EXER10B, you won't stop again until
hitting the breakpoint in EXER10B.

[Sivaprasad]

I do not agree with the point 2 raised by Jonathan. There is no need
to add a breakpoint in program EXER10B if you want to step through it.
If EXER10B is an RPGIII program it should be compiled with Option
*SRCDBG. If it as an RPGIV program then it should be compiled with
Debug View (*SOURCE)

Then give :

STRDBG PGM(CL_EXER10B) TRCFULL(*WRAP) UPDPROD(*YES) OPMSRC(*YES)

Set a breakpint in CL_EXER10B before the call to EXER10B. Call the
program CL_EXER10B and step through using F10. After stepping through
the CLRPFM statement, use F22(Step Into) function key. This will cause
the debugger to automatically add the program EXER10B into the view
list and display the program. You can step through this using F10.

Hope this is clear.

Siva

Jonathan Ball <jon...@whitehouse.net> wrote in message news:<3E145C55...@whitehouse.net>...

[Jonathan Ball]

Sivaprasad wrote:
> I do not agree with the point 2 raised by Jonathan. There is no need
> to add a breakpoint in program EXER10B if you want to step through it.

I tried it immediately before posting my reply, and I
just reverified it. The only difference was I had an
RPG module that called a CL module. I set a breakpoint
at the CALL to the CL module, and pressed F10. It
immediately proceeded to the next executable statement
in the RPG module; it did not step through the called
module.

[Jonathan Ball]

Sivaprasad wrote:
> I do not agree with the point 2 raised by Jonathan. There is no need
> to add a breakpoint in program EXER10B if you want to step through it.

Here is my code:

C* RPG module TEST2
C Eval SaveLocation = 60
C Callp Opds023c(SaveLocation)
C Write Stuff
C Eval *inlr = *on

I set a breakpoint on the Callp line in TEST2. It
broke at that line. I pressed F10, and it did NOT step
through Opds023c; instead, it stopped on the Write
line. That is just as I described it.

When I added a breakpoint in Opds023c, and pressed F10,
it stopped at the breakpoint; subsequent issues of F10
stepped through Opds023c, until returning to the Write
line of Test2.

[Sivaprasad]

Jonathan,

The reason why the debugger didn't step through Opds023c is that F10
was used. F10 cannot be used to step into another program. Use F22
(Step Into) function key of the ILE debugger. This will cause the
debugger to start debugging Opds023c from the first executable
statement. You don't need to have any breakpoint in the called
program.

Siva

Jonathan Ball <jon...@whitehouse.net> wrote in message news:<3E152A86...@whitehouse.net>...

[Jonathan Ball]

Sivaprasad wrote:
> Jonathan,
>
> The reason why the debugger didn't step through Opds023c is that F10
> was used. F10 cannot be used to step into another program. Use F22
> (Step Into) function key of the ILE debugger. This will cause the
> debugger to start debugging Opds023c from the first executable
> statement. You don't need to have any breakpoint in the called
> program.

Thanks for the tip.