I'm running an old Arev 2.12 system converted to Arev32. While going through the converted system and debugging, I've noticed that the debugger never "breaks" to the line where the debug actually is.. it's usually 6-10 lines later. The programs have a lot of labeled commons; and the interesting thing is, some of the labeled common variables (mostly stored file variables) end up whacked in the debugger. And some of the Non-common variables also seem to have values that should belong to other variables.

Does anyone know of a workaround? Does Arev32 have a problem interpreting the symbol table of a program?

A usual problem, the Debug in Arev32 is refering to the OI Precompiled Source code, not your source code.

So, in Environment Settings you should find in Arev32 Settings: Save Precompiled Source

I always ATTACHTABLE that table and use it to see the actual source code when needed. It expands the $INSERT records, for example.

I believe they are named by your source code table * source code record

Just examine the entire table.

I've found also that the /variable references in Arev32 become misaligned, too. Thus /ZZX shows the contents of /ZZW sometimes.

Dave

If I recall, AREV used to let you compile with the "forget line numbers" option.

Back in the day, it was enough to know that AREV was somewhere in the building. The program name and line number were irrelevant. As was the application. And the server.

In fact, sadly, I don't remember a time that I ever knew what I was doing.

So I'm basically hosed when it comes to debugging my program? How do I "realign" the variable names?

Please forgive my ignorance..

Dave,

Ok, I found the precompiled code, and I can see where the debugger is getting it's reported line #'s. But the issue with the variable references is a serious one. How on earth can I debug my program like this? Something that worked fine in Arev 2.12 is broken in Arev32. Is there a way to realign the variable references??

Michael

Yes, a big, unresolved pain in Arev32.

I have resorted to either:

Using ArevDOS when I can, for the debug.

or, CALL MSG(

Dave

Dave,

Is there a good technique for going back and forth to ArevDOS for debugging? I had a dog of a time just getting the programs converted to Arev32 the first time!

Michael

My ArevDOS is 3.12 so the source is identical to Arev32.

I just copy the source to a temporary file in Arev32, close Arev32.

Then attach that temporary file in ArevDOS, copy it in and compile it.

If you have changed any $INSERT references, then they must also be copied.

Dave

The problem is, the code is not identical anymore. Arev32 doesn't use the same serial communication routines, and I've had to make substantial changes. If I change anything in ArevDOS while debugging and copy the record back in, I have to recompile and then I'm still hosed.

Dave,

Any changes that I make will need to be recompiled in Arev32. Even if I make the changes in ArevDOS, won't things still get scrambled in Arev32?

Do you think the common variables might be hosing things up? I wonder if I copy the code from OI_Precompiled_Code if the variables will still scramble.

I Have to make this work.. it's a show-stopper if I don't.

Thanks,

Michael

Dave,

Any changes that I make will need to be recompiled in Arev32. Even if I make the changes in ArevDOS, won't things still get scrambled in Arev32?

Do you think the common variables might be hosing things up? I wonder if I copy the code from OI_Precompiled_Code if the variables will still scramble.

I Have to make this work.. it's a show-stopper if I don't.

Thanks,

Michael

p.s. Sorry I was logged in with my client's Works sub

The source (A3.1.2) is completely compatible between versions. So, when I identify and fix the problem in the ArevDOS version, I copy the source back to the transfer file, open it in Arev32, copy it and then recompile it. What's to scramble?

I use name and unnamed common variables in ArevDOS, Arev32 and OI and don't see any incompatibilities.

Dave

Ok, I copied the one program's code from OI_Precompiled_Code back to BP and recompiled. No more scrambled variables! It's still a pain in the butt, but it's manageable.

I guess the problem is really with all the common blocks.

Thanks for your help, Dave!

Ok, I copied the one program's code from OI_Precompiled_Code back to BP and recompiled. No more scrambled variables! It's still a pain in the butt, but it's manageable.

I guess the problem is really with all the common blocks.

Thanks for your help, Dave!

Actually, I change the standard source, not the precompiled code. The view of precompiled code was just to see the line referenced by the debug.

Glad it's working for you.

Dave

Well it did address the line # issue, but it also cleared up the variable reference. Which leads me to think the problem has to do with common blocks.

Trial and error!

Michael

View this thread on the forum...