Lee stop try to confuse us. You are not stumped at all, you know exactly what the
problem is. You're just trying to get around it.
Universe puts the complete path into the object code. It's been this way since
at least 198.... wait I'm not really that old dammit.
Ok anyway, you have to DECATALOG to remove the code then recompile it. You're right
that trying to byte-fix the line in the code is a bad bad idea :) IMHO!
Will Johnson
Fast Forward
"Group-
I'm stumped,
System: Universe 10.1+ on Windows 2000 server.
Pick flavor
Here's the problem
We're running code that was originally compiled and cataloged with the path
in UV.ACCOUNT showing:
c:\binarystar\dist\NUCLEUS
The catalog pointer in the VOC originally pointed to
c:\binarystar\dist\NUCLEUS/SBP/SBP/CHOOSEWINDOW:
(as expected)
It ran perfectly, no problem
We moved the object code to another system where the path in UV.ACCOUNT
shows:
D:\UV\ACCOUNTS\binarystar\NUCLEUS
Pick flavor again
We modified the paths of all catalog pointers to change the path (line 2 and
9 of VOC entry) from
c:\binarystar\dist\NUCLEUS/SBP/SBP/CHOOSEWINDOW:
to what is shown in UV.ACCOUNT, and it resolves to:
D:\UV\ACCOUNTS\Binarystar\NUCLEUS/SBP/SBP/CHOOSEWINDOW:
Run the program and it worked properly, no problem
Putting a DEBUG statement in the code of a program PRIOR to a call to the
subroutine
or, if an unassigned variable or other issue occured, the application would
fall into the debugger, and an error routine would show a pointer back to:
c:\binarystar\dist\NUCLEUS/SBP/SBP.O/CHOOSEWINDOW:
Same situation if a DEBUG statement is encountered after a call to a
subroutine that was ORIGINALLY compiled from another path.
After some head scratching we find that the last line of the OBJECT pointer
in the .O section of the program source file (pointing to object code),
shows
c:\binarystar\dist\NUCLEUS/SBP/SBP/CHOOSEWINDOW:
... which isn't where the source or the object now lives.
It apparently gets the debugger confused.
My questions, are:
Is there a way to fix the last line of the OBJECT code?
I don't mind creating a utility to modify the last line of the object, but I
suspect that there is at least a CRC or byte count that might throw things
off. We tried to modify the last line in the .O code pointing to the
original path, using the editor, but that does bizarre things, like multiple
paths.
or
Is there some feature that can be turned on (or off) to prevent DEBUG from
attempting to read the object pointer shown in the last line of the .O
entry?
Help would be MOST appreciated
Thanks
Lee Bacall"
-------
u2-users mailing list
[EMAIL PROTECTED]
To unsubscribe please visit http://listserver.u2ug.org/
