Why a breakpoint is used while debugging?

195 pts.
AS/400 debugging
Is/are there any better alternative(s)?

Software/Hardware used:

Answer Wiki

Thanks. We'll let you know when a new response is added.

The reason for adding a break point to to speed up debugging. Let’s say you have a 10,000 line program to debug. The problem is somewhere near the end of the process but you are not sure. Would you want to step through 7,500 lines of code, one at a time, to get there or be able to tell the debugger to stop at a specific area of the program? Also break points can come in handy when you are tracking a variable in the program. Add one everywhere it is used and you can follow all the update to the variable.

Discuss This Question: 6  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • GregManzo
    or you can use a 'WATCH' to have the debugger stop every time a variable changes. :-)
    2,970 pointsBadges:
  • ToddN2000
    Not sure if it still exists but you could put a TRACE on the program. Then you would dump the trace data and you could see what was going on. The TRACE and WATCH methods are a lot more work.
    136,490 pointsBadges:
  • Subhendu Sen
    142,670 pointsBadges:
  • rajeshece

    It will help us to confirm

    1. the program is coded as expected

    2. Easy to validate the values without introducing temporary variables

    3. We can use WATCH also

    1,230 pointsBadges:
  • ToddN2000
    Another plus is we can change variables on the fly to see the correct values will produce the results we want.
    136,490 pointsBadges:
  • TheRealRaven
    Breakpoints are used because the programs run millions of times faster than you could possibly keep track of. Without breakpoints, the result of debugging would be exactly the same as running programs normally.

    Alternatives depend on what you need to accomplish. I had to do debugging on a product program that ran in batch on a remote customer system. The program might run for days handling many thousands of transactions and fail at an unpredictable time of day in an unpredictable statement.

    For that, breakpoints were useless. A "trace" had to be used instead, so I had to supply a trace function for the customer to apply. The resulting trace file had many hundreds of thousands of lines, and it took a couple days to find where things were going wrong.

    But it's hard to say if it was a "better alternative". It certainly was more work for me. OTOH, the underlying problem (system problem that required IBM creating a PTF) was fixed.
    37,035 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: