Unexpected Application Error with Log Date 01/06/1841
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..png)
Error <INTERRUPT>ErrST+6^%ETN occurred within %ETN itself. Detailed information cannot be logged.
Comments
The "<INTERRUPT>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:
- 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].
- Consider setting up the $ZTRAP variable to handle or analyze the error before invoking %ETN. For instance:
This ensures that any errors occurring are captured and logged by %ETN [1][5].SET $ZTRAP="^%ETN"
Lastly, while dealing with unusual date entries (e.g., "01/06/1841"):
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.
Hi Steven,
As I have observed, the terminal errors do not display in the application error logs. Correct me if I am wrong.
Vachan, that depends in part on what exactly you are doing in the terminal at the time. If you are running a method or routine that includes logging an exception, that will happen in the terminal just like it would anywhere else.
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.
Thank you for the explantaion @Steven Hobbs .In the subroutine ETNMINIM, the date is retrieved solely from $H (S h=$H). Given that, why are the errors recorded under the date 01/06/1841 ($ZDH=6) in ^ERRORS instead of the actual date on which the error occurred?
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.