Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

SRCDBG LSTDBG

137 views
Skip to first unread message

Jeff Carey

unread,
Aug 31, 1998, 3:00:00 AM8/31/98
to
Does anyone have any experience with the performance overhead associated
with running OPM programs (in our case COBOL and CL) that are compiled
with the SRCDBG or LSTDBG options? We are at V3R7 and planning o go to
V4R2 in the near future.


Jan Willem de Lange

unread,
Sep 1, 1998, 3:00:00 AM9/1/98
to
At my opion there is no, or very very little, performance overhead at
runtime. Only the compile itself will take longer. But try it out with the
performance monitor started.
Jan Willem

Jeff Carey heeft geschreven in bericht <35EAD065...@usa.net>...

Phil Coulthard

unread,
Sep 2, 1998, 3:00:00 AM9/2/98
to
Jeff Carey wrote in message <35EAD065...@usa.net>...

>Does anyone have any experience with the performance overhead associated
>with running OPM programs (in our case COBOL and CL) that are compiled
>with the SRCDBG or LSTDBG options? We are at V3R7 and planning o go to
>V4R2 in the near future.
>

FYI, *SRCDBG and *LSTDBG are for enabling source level debugging. They were
originally added to OPM RPG, COBOL and
CL CRTxxxPGM commands for CODE/400 (IBM's Windows based versions of SEU,
SDA, PDM, RLU and the system debugger). Specifically, they enabled the
remote debugger (runs on Windows debugging a program running on AS/400) to
show the source of your program while debugging it. So, versus regular
debuggable programs, they simply store a pointer to the source member for
*SRCDBG and attach a compressed copy of the listing for *LSTDBG (so you can
step through the listing versus the source -> good for SQL or /COPY
members), so there should only be minimal runtime overhead. Note that the
system debugger itself now uses this information as well, as of V3R7 I
think, to offer its own source level debugging for OPM programs.

Also, one other side affect of this option is that it creates an "event
file" in your target library (xxxx/EVFEVENT *FILE I think) which contains a
member with the same name as the source member being compiled, and contains
a simple list of all the compiler error messages. This is used by CODE/400
to show compile errors in a simple list window on Windows, from which you
can double click to be positioned in the source member (using CODE's editor)
at the line in error. If you do not use CODE/400, you may want to
occassionally delete this file -> although if your compiles are always clean
it should be pretty small! Note that in ILE this side affect was moved to
its own option: *EVENTF.

Hope this helps. PS: code/400 info can be found at
www.software.ibm.com/ad/varpg.

Phil Coulthard
IBM Toronto Lab (but posting this as an ordinary citizen!)

0 new messages