The INTR.KEY in the VOC is not the only thing controlling breaking behaviour.
It specifies the maximum level of ability, not the minimum, it can be 
overridden.

However, please type PTERM DISPLAY at TCL and post the results for us to review.
That is your first step, before we get more technical.


 

 

 

-----Original Message-----
From: George Gallen <ggal...@wyanokegroup.com>
To: U2 Users List <u2-users@listserver.u2ug.org>
Sent: Wed, Oct 2, 2013 10:20 am
Subject: Re: [U2] Interesting....


Yes...

The only time I've not had the "D" option, is when I break from a VOC 
Which is expected, since you can't debug a VOC.

So, why would the D option not appear when you break from a basic program?
When....it does when you break from an input
........it does when another program is in a loop
........just this program in this loop it did not appear

And it wasn't executing a SELECT that was taking a long time or something, then
  That would be like breaking out of a VOC

George

-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] 
On Behalf Of Wjhonson
Sent: Wednesday, October 02, 2013 1:16 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] Interesting....

You mean if you break out at a BASIC input ?
If you break from a VOC you don't get the debug option, because you cannot 
debug 
VOC entries

 

 

 

-----Original Message-----
From: George Gallen <ggal...@wyanokegroup.com>
To: U2 Users List <u2-users@listserver.u2ug.org>
Sent: Wed, Oct 2, 2013 10:08 am
Subject: Re: [U2] Interesting....


Both accounts (my login and the active one) have the D in INTR.KEY

I now if I break out of a VOC, then the D is not an option
And if I break out of that same program at an input, or when it's not stuck in 
a 

loop - the D was an option
And when I wrote the test program below - and broke out of that loop - the D 
was 

an option.

So my question still is, why would one program's loop not give the D option, 
whereas others do?

Putting in the debug statements were probably faster than running port.status 
50 

or 100 times :)
I just used a binary sort method to hone in on where in the program it was near 
- then looking
   At the source code - I was able to spot the problem. Fairly quick.

-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] 

On Behalf Of Ladd, Ryan
Sent: Wednesday, October 02, 2013 12:13 PM
To: U2 Users List
Subject: Re: [U2] Interesting....

The "INTR.KEY" entry in the VOC determines what options are given when a user 
"breaks" out of a program.  The "D" is for the debug option.
             INTR.KEY
        001 X-type - Define options available when INTR key is hit
        002 ACLQD
        >
One thing to note...  The options defined in INTR.KEY are read in when you 
first 

enter Universe and are NOT re-read when you log between accounts.  Whatever 
options are defined in the first account you log into will be the available 
options for your entire session.


As a side note, you mention that you were trying to figure out where you were 
"getting stuck".

  The use of PORT.STATUS using the "PID" option and "LAYER.STACK" (>PORT.STATUS 
PID 123456 LAYER.STACK) over and over again can show you what hex address in 
the 

program your process is at.  I suggest calling this 50 or 100 times in a row 
and 

inspecting the output.  Once you have the hex addresses, use "VLIST" to figure 
out what line in the program each address represents.

Ryan



-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] 

On Behalf Of George Gallen
Sent: Wednesday, October 02, 2013 9:07 AM
To: U2 Users
Subject: [U2] Interesting....

LOOP
   IF (1=1) THEN CONTINUE
REPEAT
END

Run this program (yes, I know - it's an endless loop).
Then Control C to break out

D is one of the debug options (and lets you know what line your on).

However, when I had something like this in my program, when it got stuck
D wasn't one of the options - I had to start putting debug lines throughout the 
program
   To isolate what area I was getting stuck at.

What would cause that to be missing?   (I wasn't calling or executing anything 
at the time)


As a side note: the above had me thinking....
First we execute a program, then if it's doesn't die, we kill it!

George
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Note: The information contained in this message may be privileged and 
confidential and protected from disclosure. If the reader of this message is 
not 

the intended recipient, or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any 
dissemination, distribution or copying of this communication is strictly 
prohibited. If you have received this communication in error, please notify us 
immediately by replying to the message and deleting it from your computer.
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

 
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

 
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Reply via email to