Debug is simple, right?

[EDIguru]

I am trying to run an ILE CL program in debug mode on one of our test boxes. I have run debug zillions of times, no problem. But something very strange is occuring, and what makes this even more odd is that I had this program successfully running in debug yesterday morning on the test box. It will run on our development box in debug, my co-worker can run it in debug on the test box. But for some reason, it will no longer run for me. Here is what happens: When I issue the command, STRDBG PGM(MYLIB/MYCLPGM) UPDPROD(*YES), all is well. The module source displays. Until I hit f10 and then issue the command to run the program: CALL PGM(MYLIB/MYCLPGM) PARM('9999'). Instead of going into the source and allowing me to step thru the code, the program takes off and runs. I still have to do an ENDDBG also before I attempt to put it back into debug mode again after this. If anyone has ever seen this occur before, information would be greatly appreciated.

[RingerSoftware]

I would *guess* you had the pgm in debug with *INLR=*OFF (still in memory), recompiled it and now the previous object is in the QRPLOBJ library, still active. And then you debug the newer object, which the job ignores on the CALL since the old object is still in memory. Does the problem go away if you signoff/signon and debug again? Chris

[EDIguru]

This code has not been re-compiled on the test box (not even possible to do on our test boxes). It was compiled on the Development box using Implementer with DBGVIEW = *ALL and installed to the test box. The problem does not go away if I signoff, which is what is totally frustrating about this issue.

[RingerSoftware]

Forgive me for asking, but did you set a breakpoint (F6) on the first line of code before CALL-ing it? Chris

[EDIguru]

Actually I did try that, but normally I can call any program without pre-setting a break point in it and still step through it. However, this will not go into the source code by either method.