Skip to main content
Forgive me if this question has already been asked/answered but I couldn't find a way to search for this on the forum for Universe only.

When debbugging a Universe program by putting DEBUG, or multiple DEBUG statements, in the program, then running the program.  Sometimes the program will break on the first DEBUG statement hit but then will not break on any other DEBUG statements and finish running the program.  To resolve this I've had to put input statements in the program and then CTRL-BREAK to get into the debugger.  This is very annoying.  

Has anyone else run across this issue or know how to fix the issue?

Thanks,
Harry

------------------------------
Harry Hambrick
Senior Software Developer
Rooms To Go Inc
Seffner FL US
------------------------------
Forgive me if this question has already been asked/answered but I couldn't find a way to search for this on the forum for Universe only.

When debbugging a Universe program by putting DEBUG, or multiple DEBUG statements, in the program, then running the program.  Sometimes the program will break on the first DEBUG statement hit but then will not break on any other DEBUG statements and finish running the program.  To resolve this I've had to put input statements in the program and then CTRL-BREAK to get into the debugger.  This is very annoying.  

Has anyone else run across this issue or know how to fix the issue?

Thanks,
Harry

------------------------------
Harry Hambrick
Senior Software Developer
Rooms To Go Inc
Seffner FL US
------------------------------
Hi

I do not expriment the behavior, but... 

After the first stop/debug do you use : 
- C to continue the prog or
- R to run the prog or
- G to go next... 
Perhaps there is a bypass of next debug regarding the lettre used C or G or R ? 


I'll suggest you use RAID file prog or RUN file prog (D to enter the program at line 1, then set break point or watch point. 

If you use debug, at first stop set you next break point / watch var. 

I hope this help.

------------------------------
Manu Fernandes
------------------------------
Hi

I do not expriment the behavior, but... 

After the first stop/debug do you use : 
- C to continue the prog or
- R to run the prog or
- G to go next... 
Perhaps there is a bypass of next debug regarding the lettre used C or G or R ? 


I'll suggest you use RAID file prog or RUN file prog (D to enter the program at line 1, then set break point or watch point. 

If you use debug, at first stop set you next break point / watch var. 

I hope this help.

------------------------------
Manu Fernandes
------------------------------
I have always used the G when debugging.  I've been doing that on different Universe systems for years and this is the only system that I've ever seen this issue on.   Watches don't seem to work well on this system either. I have not used the RAID FILE PROG before I'll give that an attempt and see how it works.  This is a wrapper program that calls a subroutine and the DEBUG statements are in the sub so I'm assuming if I use RAID on the calling program that it will follow into the sub.  Thanks for the suggestion!

------------------------------
Harry Hambrick
Senior Software Developer
Rooms To Go Inc
Seffner FL US
------------------------------
I have always used the G when debugging.  I've been doing that on different Universe systems for years and this is the only system that I've ever seen this issue on.   Watches don't seem to work well on this system either. I have not used the RAID FILE PROG before I'll give that an attempt and see how it works.  This is a wrapper program that calls a subroutine and the DEBUG statements are in the sub so I'm assuming if I use RAID on the calling program that it will follow into the sub.  Thanks for the suggestion!

------------------------------
Harry Hambrick
Senior Software Developer
Rooms To Go Inc
Seffner FL US
------------------------------
Okay

Another sugg, is the subr in a HUSH or CAPTURING or any OFF user-interface  situation ? 

Good luck.

------------------------------
Manu Fernandes
------------------------------
Okay

Another sugg, is the subr in a HUSH or CAPTURING or any OFF user-interface  situation ? 

Good luck.

------------------------------
Manu Fernandes
------------------------------
Harry,

Have your checked PTERM DISPLAY?  How about the account-VOC's X-types?

------------------------------
Tyrel Marak
Technical Support Manager
Aptron Corporation
Florham Park NJ US
------------------------------
Okay

Another sugg, is the subr in a HUSH or CAPTURING or any OFF user-interface  situation ? 

Good luck.

------------------------------
Manu Fernandes
------------------------------
No HUSH, CAPTURING or OFF in the sub.

------------------------------
Harry Hambrick
Senior Software Developer
Rooms To Go Inc
Seffner FL US
------------------------------
Okay

Another sugg, is the subr in a HUSH or CAPTURING or any OFF user-interface  situation ? 

Good luck.

------------------------------
Manu Fernandes
------------------------------
No HUSH, CAPTURE or OFF in the sub.

------------------------------
Harry Hambrick
Senior Software Developer
Rooms To Go Inc
Seffner FL US
------------------------------
Harry,

Have your checked PTERM DISPLAY?  How about the account-VOC's X-types?

------------------------------
Tyrel Marak
Technical Support Manager
Aptron Corporation
Florham Park NJ US
------------------------------
No on the PTERM DISPLAY.  I'll check into that.  What X-type VOC's are you referring to? 

Thanks!

------------------------------
Harry Hambrick
Senior Software Developer
Rooms To Go Inc
Seffner FL US
------------------------------
No HUSH, CAPTURE or OFF in the sub.

------------------------------
Harry Hambrick
Senior Software Developer
Rooms To Go Inc
Seffner FL US
------------------------------
I was thinking specifically of INTR.KEY, QUIT.KEY, SUSP.KEY.  Depending on how those are set, some options will not be available.  I'm not positive, but that might interfere with debugging.

------------------------------
Tyrel Marak
Technical Support Manager
Aptron Corporation
Florham Park NJ US
------------------------------
I was thinking specifically of INTR.KEY, QUIT.KEY, SUSP.KEY.  Depending on how those are set, some options will not be available.  I'm not positive, but that might interfere with debugging.

------------------------------
Tyrel Marak
Technical Support Manager
Aptron Corporation
Florham Park NJ US
------------------------------
Those appear to be set correctly.  What's odd is I have a DEBUG just before GOSUB XYZ, run the program and it will hit the DEBUG and break every iteration.  I move the DEBUG to immediately after the GOSUB XYZ and it will hit the DEBUG and break only on the first iteration and will not break on any other iterations.

------------------------------
Harry Hambrick
Senior Software Developer
Rooms To Go Inc
Seffner FL US
------------------------------
I have always used the G when debugging.  I've been doing that on different Universe systems for years and this is the only system that I've ever seen this issue on.   Watches don't seem to work well on this system either. I have not used the RAID FILE PROG before I'll give that an attempt and see how it works.  This is a wrapper program that calls a subroutine and the DEBUG statements are in the sub so I'm assuming if I use RAID on the calling program that it will follow into the sub.  Thanks for the suggestion!

------------------------------
Harry Hambrick
Senior Software Developer
Rooms To Go Inc
Seffner FL US
------------------------------
Harry,

Can you let us know if a simple test is working?

i.e.
>CT BP BTEST

BTEST
0001 DEBUG
0002 PRINT "A"
0003 DEBUG
0004 PRINT "B"
0005 DEBUG
0006 PRINT "C"

>RUN BP BTEST
BTEST: 2: PRINT "A"
:: G
A
BTEST: 4: PRINT "B"
:: G
B
BTEST: 6: PRINT "C"
:: G
C


------------------------------
Mike Rajkowski
support
Rocket Internal - All Brands
DENVER CO US
------------------------------
Harry,

Can you let us know if a simple test is working?

i.e.
>CT BP BTEST

BTEST
0001 DEBUG
0002 PRINT "A"
0003 DEBUG
0004 PRINT "B"
0005 DEBUG
0006 PRINT "C"

>RUN BP BTEST
BTEST: 2: PRINT "A"
:: G
A
BTEST: 4: PRINT "B"
:: G
B
BTEST: 6: PRINT "C"
:: G
C


------------------------------
Mike Rajkowski
support
Rocket Internal - All Brands
DENVER CO US
------------------------------
Yes that program works fine.  I also did a program like the following:
0001: DEBUG
0002: PRINT "A"
0003: FOR LPA=1 TO 10
0004: DEBUG
0005: GOSUB CRT.VAL
0006: DEBUG
0007: NEXT LPA
0008: DEBUG
0009: STOP
0010: CRT.VAL:
0011: CRT LPA
0012: RETURN

And that works fine also.  We have been having this issue for a long while now and I personally typically see the issue on larger programs.  For example the one that finally prompted me to ask about it on the forum is 6654 lines and 258483 bytes.  It seems to me sometimes to depend on the placement of the DEBUG statement as to whether it works correctly or not.  This is the first time I've seen this issue on any of the Universe machines I've ever worked on so it's odd to me.

------------------------------
Harry Hambrick
Senior Software Developer
Rooms To Go Inc
Seffner FL US
------------------------------