I am trying to use the BSYM file to map where variables exist and get
set in a program. However, the generation of the data into the BSYM
file is not 100% accurate. I am finding that the line number goes out
of sync. As the after the compile the variables at the end of the
program are being reported on line number past the end of the actual
program.

Is far as I can tell the line number gets increased by 1 for about
every 200 or so lines of code.

Does anybody out there now what the quirk is??? I'd like to be able to
rely on the BSYM file to be accurate for the tracking where the
variable exist with in the program source code. If I need to run a
little fix-it program against the BSYM to ensure accuracy that would be
okay as well.

Thanks for your help in advance!!

Regards,

Dale

Do you have any INCLUDE statements?

Patrick, <;=)

Dale wrote:

"Dale" <dale_benedict (AT) flightcraft (DOT) ca> wrote

First off, full and frank disclosure: I haven't ever used BSYM so I'm
theorising here. If any of this is relevant great. If not, please accept
my apologies in advance - I'm just thinking out loud here.

Three things immediately spring to mind.

In no particular order:

Have you taken account of any "INCLUDE" or "$INCLUDE" statements within the
code? One line of code (for the include statement) but many lines of code
to compile. How is this being handled by the BSYM file? Could that explain
your "line numbers beyond the end of the program" problem?

Next, I remember a conversation where casing of variables caused a problem
(e.g. var, Var and VAR). I recall the "fix" is to make sure that the
d-pointer for BSYM doesn't have the "S" option included.

Last, when compiling the code, is it possible to use the "il" options
(lower-case "I" and "L") and capture the output writing that to a file
somewhere else. The line numbers produced there should, all things being
equal, match those being reported in BSYM. At least then you can
cross-reference the compiled line to the actual line? Alternatively, the
included lines have a "+" appended, so you might be able to calculate the
off-set depending on how important this is and how often you're going to
have to do it.

As I said above, not sure how relevant any of this is. Hope some of it is
useful.

With Kindest Regards

Mike Wooding

Yes!!! But for on particulare program I'm looking at...

The program has 7 include statements, and the first 190 lines the
symbols in the BSYM file all line up. Line 191's variable are reported
as being on line 192, and then at line 291's variables are reported on
line 293, and then line 388's variables are being reported on 391.

If it were consistent or triggered by a particular line of code, I
could either restructure the code or write a small program to do the
adjustments but there doesn't seem to be a definate pattern. I even
check the object code to see if the difference in the line number was
triggered by the change of a frame, but that thought brought no fruit.

So... Spill the beams 'winky', waddaya know about BYSM and includes!

Regards,

Dale

The programs has the first 190 lines all the line number s
latimerp wrote:

Hi
Did you expand the code on compile so that all the lines in your includes
were actually physically in the final version that BSYM used? We always
used to map code in Reality days but I am afraid I have not used it for some
time as I automatically Initialise everything. I suppose I should have a
look again.
Peter McMurray
"Dale" <dale_benedict (AT) flightcraft (DOT) ca> wrote

"Dale" wrote:
Dale, I don't believe the area you're looking at is included in the
normal targets for RD QA testing. (And since they got rid of the QA
department it's likely to never be tested again.) It's entirely
possible that you've found a bug. If you can figure out exactly what
the pattern is then you can code around it (post-generation mods to
BSYM). Whether you do or don't find the cause, I'll recommend you
report it to RD, but that's entirely up to you.
Have I said I don't care recently?

Seriously, good luck bud.
T

MMMMmmmmm, can't u just smell the pus? LOL

Ix-nay on the us-pay.

Ed-ay

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

Dale

I've used the BSYM file for years... I use it to find unreferenced
variables before testing a program. Building some good dict items, you
can make a select statement that will return any variables that are
only referenced once. Although I haven't seen your problem, I usually
just search for the variable.

I usually find that I spelled something wrong. Of course, if you spell
it wrong twice, you're out of luck.

I'm glad to find someone else using this tool. It recalls my short
career as a COBOL programmer, where every compile would return such a
list.

Anyway, I'm rambling, and I have to get back to my clique...

just taking a stab, but there may be an artificial statement inserted
when the object code crosses a frame-boundary (perhaps as a
word-alignment optimization), which is erroneously being registered as
a "new line" rather than merely being registered an additional
statement ("internal").

have you tried using the basic debugger on the above? i'd be curious
about what line number it is reporting.


Dale wrote:

I use BSYM regularly, havent noticed any lines out of step but I'm
running under XP.
I wonder if you get any control char items for the subroutine calls,
like I've had in the following thread.
http://groups.google.co.nz/group/com...7 39f01bfc0af
Apart from that I've found the cross referencing doesnt detect a lot of
assignments (doesnt set the BSYM ID to *variablename). Its still easier
than eye-balling the code to find mispellings of variables.

Jeremy Thomson

Dale wrote: