User bio
404 bio not found
Member since Feb 2, 2016
Replies:

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.

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.

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.

Certifications & Credly badges:
Steven has no Certifications & Credly badges yet.
Global Masters badges:
Steven has no Global Masters badges yet.
Followers:
Following:
Steven has not followed anybody yet.