Set $ET to "B" instead of "" in XUP

Bug #415049 reported by Jon Tai on 2009-08-17
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenVista/GT.M Integration
Low
Unassigned

Bug Description

This bug is being filed on behalf of Sam Habiel.

Whenever I execute XUP, it sets the error trap to something (by default the empty string), and once it set it, $ZT becomes blank. However, that's a problem when debugging with GT.M. Whenever an error happens, GT.M remains silent, giving an impression that everything went well.

Here's an example routine called test1, that does a classic error (div by zero).
test1 W 6/0

See what happens in a clean WV instance in which the parameter XUS-XUP SET ERROR TRAP is not initialized:
GTM>d ^XUP

Setting up programmer environment
This is a TEST account.

Access Code: *********
Terminal Type set to: C-VT100

You have 46 new messages.
Select OPTION NAME:
GTM>w $ET

GTM>w $ZT

GTM>zed "test1"

GTM>zl

GTM>d ^test1

GTM>w $EC
,M9,Z150373210,
GTM>w $ZE
Unprocessed $ZERROR, see $ZSTATUS
GTM>w $ZS
150373210,test1^test1,%GTM-E-DIVZERO, Attempt to divide by zero
GTM>

This situation always dogs WV programmers, who keep wondering why their program doesn't crash. Can we get this fixed? Perhaps by setting $ET="B" in XUP? in the 3rd line instead of setting it to $ET=""?

Jon Tai (jontai) on 2009-08-17
Changed in openvista-gtm-integration:
importance: Undecided → Low
milestone: none → 0.8.6
Jon Tai (jontai) wrote :

Trade with bug 446635

Changed in openvista-gtm-integration:
milestone: 0.8.6 → 0.8.7
Jon Tai (jontai) wrote :

I researched this a little further, and it appears that there's already a setting that allows you to turn error trapping on in XUP:

GTM>D ^XUP

Setting up programmer environment
 Terminal Type set to: C-VT102

Select MENU OPTION: EVE// XPAR EDIT PARAMETER Edit Parameter Values
Edit Parameter Values
                         --- Edit Parameter Values ---

Select PARAMETER DEFINITION NAME: XUS-XUP SET ERROR TRAP Set error trap in X
UP

XUS-XUP SET ERROR TRAP may be set for the following:

     1 User USR [choose from NEW PERSON]
     2 System SYS [VISTA.GOLD.MEDSPHERE.COM]

Enter selection: 2 System VISTA.GOLD.MEDSPHERE.COM

---- Setting XUS-XUP SET ERROR TRAP for System: VISTA.GOLD.MEDSPHERE.COM ----
Value: YES

XUS-XUP SET ERROR TRAP may be set for the following:

     1 User USR [choose from NEW PERSON]
     2 System SYS [VISTA.GOLD.MEDSPHERE.COM]

Enter selection:
-------------------------------------------------------------------------------

Select PARAMETER DEFINITION NAME:

TRAIN>W $ET
D ERR^XUP
TRAIN>W $ZT

TRAIN>D ^TEST1

$ECODE=,M9,Z150373210, $STACK=2

Want to record the error: No// Y
TRAIN>D ^XTER

In response to the DATE prompt you can enter:
     'S' to specify text to be matched in error or routine name

1 error logged on 12/22/2009
  1) <(DIVZERO)>TEST1^TEST1 13:28:00 [TRAIN] MANAGER:

Which error? >

Changed in openvista-gtm-integration:
status: New → Invalid
Jon Tai (jontai) wrote :

Actually, I'm setting this back to New because we shouldn't just ignore errors even if the XPAR is set to NO. The suggestion to just set $ET="B" in XUP+3 doesn't work though, so another way to set $ET or $ZT will need to be found.

Changed in openvista-gtm-integration:
status: Invalid → New
Jon Tai (jontai) wrote :

Two more thoughts -- Cache doesn't ignore the error, even if $ET and $ZT are set to "". Also, setting $ET="B" at XUP+3 results in $ZT set to "G OPNERR^%ZIS4" after doing a D ^XUP, then halting.

Jon Tai (jontai) wrote :

In the interest of getting the 0.8.7 release out the door before the VistA Community Meeting this week, I'm going to punt this one again. Hopefully we can make some progress on it working together in person at the VCM.

Changed in openvista-gtm-integration:
milestone: 0.8.7 → none
Jon Tai (jontai) on 2010-01-22
Changed in openvista-gtm-integration:
milestone: none → 0.8.8
Jon Tai (jontai) on 2010-02-11
Changed in openvista-gtm-integration:
milestone: 0.8.8 → 0.8.9

"Also, setting $ET="B" at XUP+3 results in $ZT set to "G OPNERR^%ZIS4" after doing a D ^XUP, then halting."

Jon, that's probably a bug in OpenVistA.

As far as Cache, yes, it behaves differently. However, it behaves no differently if you use $ET to B

Jon Tai (jontai) on 2010-05-27
Changed in openvista-gtm-integration:
milestone: 0.8.9 → 0.8.10
Jon Tai (jontai) on 2010-09-22
Changed in openvista-gtm-integration:
milestone: 0.8.10 → none
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers