Catching WorkQueue Errors

Question

Question

I'm trying to catch some WorkQueue errors that are happening on 2019 but not on more recent versions.

I'm getting an error when trying to call a class method via a workQueue. It functions properly in 2024.1. When calling the method, it immediately errors. I have logging at the top of the method that never gets set.

The error being returned by Iris is simply an "ERROR #5039: An error occurred while calling function s %sc=##class(|"NS"|Path.To.Class).ClassMethod(.%p1,.%p2)"

The parameter counts match and are appropriate for the method.

When I catch the full stack, it's erroring on the WorkQueue compiled routine, somewhere around startWork+233^%WorkQueueMgr. The error stack mentions a few lines, all in startWork. Looking at what, I think is, the associated inc file (occWorkQueue.inc), there's some mention of turning on logging by setting ^%SYS("WQM","EnableWorkLogging"). If that's true, it will set the error being passed in into the ^%ISCLOG global. However, even when I do set ^%SYS("WQM","EnableWorkLogging") to 1, and ^ISCLOG to 4 (or higher), I never see the logs I'd expect to. I know there are logs within the routine that set values and errors to $$$WorkSysLog at levels 2 and 3, so setting ^ISCLOG to 4 should catch those errors.

How can I view the errors being thrown by the compiled routine? Does the value of "EnableWorkLogging" only matter at some stage I can't set?

Product version: IRIS 2019.1

Discussion (7)3

Log in or sign up to continue

Enrico Parisi · Aug 25

I don't think that ##class(|"NS"|Path.To.Class).ClassMethod() is a valid syntax.

I believe the "|NS|" makes it a syntax error.

0 0

score 0 · Answer 1 · 2025-08-25T13:20:23-04:00

s %sc=##class(|"NS"|Path.To.Class).ClassMethod(..%p1,%p2)

Is this really contained in the error message? Is that your code?

To me |"NS"| and ..%p1 look strange.

score 0 · Answer 2 · 2025-08-25T13:51:38-04:00

They absolutely do and I agree that it's odd. I did a small typo, the parameters are "(.%p1, .%p2)". Obviously the namespace and class/method names are fake, but the syntax remains.

score 0 · Answer 3 · 2025-08-25T18:37:01-04:00

I think it might be some internal syntax. When looking at processes, the %objlasterr value often has errors in that syntax:

I edited out the namespace and classname for privacy. But the first and third marks are the namespace, the 2nd and 4th are the class.

Also, to make clear, no this isn't my code, it's in the error message being returned by the HS Compiled Routine. I imagine it's part of the internal workings. But I'm really trying to figure out how to get that ^%ISCLOG part to actually log.

score 0 · Answer 4 · 2025-08-26T05:14:43-04:00

This is very confusing, I understand editing names for privacy reasons, but you are changing the actual format, not only names. I've never seen "##class(|"NS"|Path.To.Class)" in errors.

Can you reproduce the issue with a simple sample code using generic names? This way you can post your code so we can understand what's going on and how to fix/log the problem.

score 0 · Answer 5 · 2025-08-26T02:21:55-04:00

Correct! |"NS"| is not allowed as a Class reference.
BUT: It is a valid syntax for .INT/.MAC Rooutine do label^|"NS"|routine
And %objlasterror never shows the class, but the generated .int or .obj you run.
It's rather a comfort of the COS compiler that your class name matches the .int

score 0 · Answer 6 · 2025-08-26T09:05:11-04:00

So that makes sense, as the error is coming from the compiled routine code.

But back to my original question: how do I enable the ^%ISCLOG that's described in the %occWorkMgr.int code?