I am modifying a program in my test VRC and I'm observing inconsistant behavior. The live version of this same program is in shared memory. My VRC structure derives test from live VRC, live is derived from baan standard.

For example, I copy program from live to test VRC a compile in debug mode making no changes.

I log off and log back into the system and the debugger comes up when I execute the code. I hit continue and then quit closing out the session and the program.

Then I execute the same code again and the debugger does not present itself.

Why? Am I running the same code? Am I running the object from live?

Are you sure you are not connected to Live VRC when you logged in back? If this program is not compiled with debugger in Live VRC, and you connected at Live VRC, you will not see debugger.

My VRC is test for sure because the user is not authorized to develop in live VRC.

Just wondering if on the second run it is pulling the version from shared memory. When it runs normally and not the debug version can you tell the difference? I would add a message line to the program to print at startup time just to see if I got the message every time - in debug and normal mode. Not sure if this is helpful since I really do not have any experience with shared memory.

Mark

Have you tried to check is you object stays in memory after you hit "Continue"? If so, the debugger won't show up again because you already hit "Continue" ....

One thing you can do:
1. Open your "Option Dialog" and start a shell
2. type "ps" and see if your object is still in memory
3. if your object is still in memory, type debug <processid> and your object will show up in debug mode next time you try to run it ....

Joy,

Refer to the links -

check.executing.object() (http://www.baanboard.com/baanboard/showthread.php?s=&postid=35359#post35359)

CODE: Show which session a user is running (http://www.baanboard.com/baanboard/showthread.php?s=&threadid=1936)

I see that you are on the HP-UX so you can use the shell script to check if a session/script/library is Currently in Shared Memory.

You can Print the Session Information to get the exact path from where the object is being executed.

Another problem could be the earlier obejct's permission at Unix level, may not have write permission for others.

-- Avinash