Question
· Jul 21

Unexpected Application Error with Log Date 01/06/1841

#Error Handling #Terminal #InterSystems IRIS #InterSystems IRIS for Health

Hello Community
I was running code in the terminal and attempted to interrupt its execution. During that process, I encountered an application error with a log entry dated 01/06/1841, the date seems unusual.

Error <INTERRUPT>ErrST+6^%ETN occurred within %ETN itself. Detailed information cannot be logged.

Product version: IRIS 2025.1
$ZV: IRIS for Windows (x86-64) 2025.1 (Build 223U) Tue Mar 11 2025 18:18:59 EDT
Discussion (6)4
Log in or sign up to continue
DC AI Bot · Jul 21

The "ErrST+6^%ETN" error message you encountered within %ETN suggests that the application encountered an error during the execution of the error trap utility %ETN. The utility is designed to save information about an error, including the execution stack, job state, and variable values, to the application error log. However, since the error occurred within %ETN itself, detailed error logging was not possible in this instance [1][2][3].

To address errors encountered during the use of %ETN:
1. You can view the application error logs using either the Management Portal or the ^%ERN utility to examine other related logs. This may provide additional clues about the failure [1][4].
2. Consider setting up the $ZTRAP variable to handle or analyze the error before invoking %ETN. For instance:
ObjectScript
SET $ZTRAP="^%ETN"
This ensures that any errors occurring are captured and logged by %ETN [1][5].

Lastly, while dealing with unusual date entries (e.g., "01/06/1841"):
- Review and filter error logs using the Management Portal or ^%ERN, specifically searching by date or error substrings [4][6].
- Check if any system or user inputs inadvertently set such dates during logging or processing activities, as they may be erroneous.

Sources:

0 0
Steven Hobbs · Jul 21

The zero date for the ObjectScript built-in $HOROLOG variable (aka $H) is 12/31/1840 so the date, 01/06,1841, you are seeing is date number 0 plus 7 days.  Now the $H day number in your Error Details, 67407,  is 07/21/2025 (i.e., today) and the $H time number (67118 seconds) is 06:38:38PM local time.

It looks like <INTERRUPT> was signaled while %ETN was generating the error log.  The <INTERRUPT> signal usually means someone typed control-C on the terminal.  The control-C may have interrupted %ETN before it had dumped all the date/time information of the original error.  The $H string in your Error Details, "67407,67118" is probably the date/time when the control-C was typed.

0 0
Steven Hobbs · 11 hr ago

If an <INTERRUPT> occurs outside of the ^%ETN routine then ^%ETN ignores the interrupt and THROWs it back to the application code.

In this case the <INTERRUPT> occurs inside the ^%ETN routine while it is processing an earlier error signal.  At the line in question, ErrST+6, the ^%ETN is executing the
    Merge ^ERRORS(date,errnum)=^mtemp(State)
command which is merging the error state (in ^mtemp(State)) into the ^ERRORS(date,errnum) log variable.  That could mean that ^ERRORS(date,errnum) is only partially created so it would contain corrupted information about the error trap sent to ^%ETN.

It looks like that Merge got held up for some reason allowing the user time to signal <INTERRUPT> with a ctrl-C, or some other <INTERRUPT> signal.  That would cause ^%ETN to KILL  ^mtemp(state) and then ^%ETN executes the following local routine which generates a minimum entry in the ^ERROR log global entry describing the error that aborted ^%ETN.

ETNMINIM
 N h,d,i
 S h=$H,d=$E(h,"^",1),i=$I(^ERRORS(d))
 S ^ERRORS(d,i,"*COM")=h_","_$ZE_"; log entry lost."
 S ^ERRORS(d,i,"*STACK",0,"V","$H")=h,^("$I")=$I,^("$J")=$J
 Q

This mimimum ^ERRORS(date,count) entry describing the signal that interrupted ^%ETN should just follow the ^ERROR(date,count-1) entry that was only partially generated.

0 0