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 (7)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.

1 0
Steven Hobbs · Jul 22

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
Steven Hobbs · Jul 24

ETNMINIM makes a very small ^ERRORS log with just 4 entries:  As *COM comment line, a *STACK,0,V,$H line containing the $HOROLOG system variable, a *STACK,0,V,$I line containing the $IO system variable, and a *STACK,0,V,$J line containing the $JOB system variable.  Normal ^ERROR logs created by ^%ETN usually contain 100s of entries, including many other entries other than *COM and *STACK..  Your Error Details displays Expression Value entries for the $H, $I and $J variables. and they all seem correct including a $H value of  67407,67118 which is a date of 07/21/2025 and a local time of  06:38:38PM.

The Error Details also displays a Process box containing "39452 01/06/1841 18 38-38 No: 82".  The job number (39452), time (18:38:38 ) and the Error ID (82) all seem correct but the Error Details seem to have incorrectly used the number 7 as the date value.

I have no experience with the Error Details display generated by the SMP web page.  Possibly that web page is decoding a *STACK entry (or some other *XXX entry) for the date that was not generated by ETNMINIM.  Since the %ETN logging failure was reported by error id 82 and there seems to exist an error id 81, it is possible that some useful information can be found by executing ZWRITE ^ERRORS(67407,81) in the LEARNING namespace.  Remember this particular ^ERRORS log entry was generated by a MERGE command that did not complete.

0 0