Announcement

Collapse
No announcement yet.

RDI Debug

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • RDI Debug

    When I run a program in debug it does not stop on every line, it skips around. Almost like the source and the object are not lined up. I tried to recompile just to see if that was the case. Anyone else run into this?

  • #2
    Re: RDI Debug

    I debug with service entry points in RDi all the time and it always works great. Stepping through line by line works as it should, plus of course you can "step over" lines such as procedure calls, etc. (which still execute, but you don't have to step into them). But yes of course your source has to match the program object you're running.

    Comment


    • #3
      Re: RDI Debug

      Yea, I have used it extensively and the only time I have seen anything similar was when the source doesn't match the object. But the re compile should have fixed that.

      Comment


      • #4
        Re: RDI Debug

        Was the program's activation group reclaimed? (Is it in the default activation group?) Is it being run in a new session?
        Tom

        There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

        Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?

        Comment


        • #5
          Re: RDI Debug

          Should be running in the default activation group and I did log off and log on to make sure. FWIW it is a trigger program so I am actually calling it by running a sql insert from an interactive session.

          Comment


          • #6
            Re: RDI Debug

            Never used the optimize keyword before but apparently that will move your code around and make using debug tough. Commented it out, compiled, and everyone is happy.

            Comment


            • #7
              Re: RDI Debug

              Rearrangement of the generated low-level code can be a major part of "optimization". When the process includes debug info embedded in the generated code, the rearrangement can connect internal marks back out to the original external source statements in surprising sequences. The basic idea is that debugging should be done before optimization is useful.

              In an ideal sense, optimization is for after logic bugs are eliminated and when the code is ready for production. The rearrangement into more 'optimal' code sequences is one reason why. It can be confusing, eh?
              Tom

              There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

              Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?

              Comment


              • #8
                Re: RDI Debug

                I understand most of it and I understand now why you do optimization after. It caught me because I had never used it at my previous shop and I was just trying to follow program logic, was not really debugging anything. Makes it much easier if you can just run it in debug instead of trying to follow it through on a paper.

                Comment


                • #9
                  Re: RDI Debug

                  You can also change the optimization without recompiling via CHGPGM (or CHGSRVPGM).

                  Comment

                  Working...
                  X