Join The Works program to have access to the most current content, and to be able to ask questions and get answers from Revelation staff and the Revelation community

At 10 MAR 2023 11:33:37AM John Bowen wrote:

After upgrading from OI 9.4 to 10.2 the Arev debugger is no longer displaying variables. We have Arev set up to use the OI debugger.

If a main program is run from TCL using just the program name (using VOC settings) the variables are not displayed in debugger.

If a main program is run from TCL using the RUN command the variables are displayed in debugger. But, if the program is re-compiled, we need to log out of Arev and back in to get the variables to show.

A subroutine called from a window or a main program will not display variables in the debugger.

Is this a bug in 10.2, or am I missing a setting somewhere?


At 13 MAR 2023 10:47AM bshumsky wrote:

Hi, John. I just started up an AREV64 session in OI 10.2, with the 'startup' and 'shutdown' flags set to '1' in the CFG_CTO record, and tried the following steps:

- F5 to TCL;

- RTI_SET_DEBUGGER 1 (which tells AREV64 to use the OI debugger);

- EDIT SYSPROCS DTEST, with the following lines:

 X = "HELLO"
 Y = "WORLD"
 Z = 123
 DEBUG
 PRINT X:Y

- Shift+F9 to compile;

- Exit the editor;

- DTEST ⇒ breaks to the OI debugger, shows X/Y/Z variables

After dismissing the OI debugger, I found I had to again RTI_SET_DEBUGGER 1 if I wanted to do the following tests:

RUN SYSPROCS DTEST ⇒ breaks to the OI debugger, shows X/Y/Z variables

CATALOG SYSPROCS DTEST, then DTEST ⇒ breaks to the OI debugger, shows X/Y/Z variables

I then created DTEST1, which had the following code:

SUBROUTINE DTEST1(A,B,C)

D = "ANOTHER"

E= "TEST"

DEBUG

RETURN

Shift+F9 to compile it, and changed DTEST so that it now had:

 X = "HELLO"
 Y = "WORLD"
 Z = 123
 CALL DTEST1(A,B,C)
 PRINT X:Y

Shift+F9 to compile it, DTEST ⇒ A,B,C,D and E variables all show up and are populated correctly.

If you follow these steps, do you get the same results? If so, in what way(s) are your test different?

Thanks,

- Bryan Shumsky

Revelation Software, Inc.


At 13 MAR 2023 12:28PM John Bowen wrote:

Bryan,

When I create the programs in Sysprocs and run the programs just using the name of the program from TCL the variables show in the debugger properly.

I get an error when I try to use the "RUN" command from TCL. "$DTEST" cannot be found. When I try to edit Sysprocs $DTEST, the compiled code can't be found.

When I create a program with similar logic in another source table and compile the code. I can only use the "RUN" command from TCL to get the variables to show in the debugger. All of our Arev programs are created in other tables and not created in the Sysprocs table.

In version 9.4, there were records in Sysprocs tables for each of our Arev programs. For example, if I created DTEST in the SOURCE table and compiled it, there would be a SOURCE:DTEST*RELO record in the Sysprocs table. I don't see these records in Sysprocs in 10.2.


At 13 MAR 2023 03:20PM bshumsky wrote:

Hi, John.

When you tried to use the RUN command with your item in SYSPROCS, did you type in RUN SYSPROCS DTEST (rather than RUN DTEST, or RUN SYSPROCS $DTEST)? That is exactly what I did.

There is not normally object code ("$xxx" ) in the SYSPROCS table - in OpenInsight, object code is stored in SYSOBJ. So if for some reason you wanted to look at the object code, you would look at SYSOBJ $DTEST.

I'm afraid I can't recall why OI 9.x would have created SOURCE items in SYSPROCS from another source table; however, in OI 10.x there would not be copies of the source item stored in SYSPROCS if you have created them in another table (like BP or SOURCE). There MIGHT be a copy of the "post-processed" source item stored in the OI_PRECOMPILED_CODE table, however.

The only other reason I can think of for the source, or object, to be moved is if you have an MFS on the source table (which I understand was common in AREV) - for example, the object code ("$xxx" ) might be moved to an object table after compilation.

Finally, if you DO have source in SYSPROCS or another table, and you want it inVOCable (ha ha) directly, you can use CATALOG <TABLE> <PROGID> to make a VOC catalog pointer. This is what I did with my DTEST program in SYSPROCS - after compilation, I issued the command CATALOG SYSPROCS DTEST and a VOC item named DTEST was then created.

Hope that helps,

- Bryan Shumsky

Revelation Software, Inc.


At 13 MAR 2023 04:00PM John Bowen wrote:

Bryan,

I used the RUN command with Sysprocs. I'll send email with screen shot.

We have a MFS on the source tables that we're using. The MFS makes a backup copy of the Source before it's changed to a History table. The object code is not moved or changed with the MFS.

Is there still an option in Arev64 to save the variable table? It's been a while since I've messed with that.

I would rather continue running are programs from the existing source code tables they are in. We just need to debugger to show the variables when running for those tables.

John

View this thread on the Works forum...

  • third_party_content/community/commentary/forums_works/b09fd2e139db9149a365db76971be603.txt
  • Last modified: 2024/05/23 12:38
  • by 127.0.0.1