This has probably to do with underscores ( _ ) in variable/method names. (not allowed in object script, but used with callbacks in the (deprecated) product VISM (or also called Cache Direct, hence the CD and CalBk in the error)
I get a similar error when doing :

%SYS>set _abc=1
 
<FUNCTION>SetProp+2^%CDCalBk
%SYS 3d1>

From the documentation :

Invalid Names

A local variable name that does not follow the above naming conventions generates a error. There is one exception: if an invalid variable name begins with an underscore character followed by a letter, the system generates a <_CALLBACK SYNTAX> error. (Note the underscore character within the error name.) For example, SET _abc = 123 or SET x = _abc. This is because Caché identifies these names as VISM control names, rather than local variable names.

Do you use CSP pages or REST (through portal or other applications) ? It uses a grace period that can hold a license slot longer than the actual login time.

You can look at the license usage in the Management Portal :
- Click on View System Dashboard, in Licensing tab :

You can click on Current License Use, and click on the bottom of the page on 'Click here for more details' to go to the License Usage page (also accessible via System Operation -> License Usage)

You can view the same figures in terminal by using Do $system.License.ShowSummary()
(Look at Do $system.License.Help() for other methods to show license stats.

Hi Daniel, did you do a zwrite output ? It is an array, so if output=2 there should be more data in it.

(usually output is empty when the command was executed successfully)
I like using using OPEN because any shell output message is captured and can be logged.
e.g.

do ##class(Image.Utils).Convert("a.jpg","-resize 10X10", .output)
zwrite output
output=2
output(1)="convert: UnableToOpenBlob 'a.jpg': No such file or directory @ error/blob.c/OpenBlob/3109."
output(2)="convert: MissingAnImageFilename `10X10' @ error/convert.c/ConvertImageCommand/3272."

I am using read queue to be able to monitor the output from Image like this :
 

 Parameter INSTALLDIR = "c:\ImageMagick\";

/// Do ##class(Image.Utils).Resize(file, newFile500, "500X500", .msg)
ClassMethod Resize(fileOrig As %String, fileNew As %String, newSize As %String, ByRef output as %String) As %Boolean
{
  Quit ..Convert(fileOrig, "-resize "_newSize_"^> """_fileNew_"""", .output)
}

ClassMethod Convert(file, options, ByRef output as %String) As %Boolean
{
  Do ..Cmd("convert """_file_""" "_options, .output)
  Quit 1
}

ClassMethod Cmd(command As %String, ByRef outputStr As %String)
{
  Kill outputStr
  Try {
    Set cmd=..#INSTALLDIR_command
    Open cmd:("RQ")
    For {
      Use cmd Read line If $ZEOF=-1 Quit
      Set outputStr($i(outputStr))=line
    }
catch {
  }
  Close cmd
}

Hi Hansel,

Temp should only grow because of use of temporary globals. (^IRIS.temp, ^mtemp, or any other global explicitly mapped to IRISTEMP)
In my experience, sudden growth of temp is mostly due to an SQL query that is doing a join or order of non-indexed columns.
When you restart Iris, you could delete the iristemp (it will recreate it), you can also set a param to truncate it automatically at startup:
https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls...
 

You should not always rely that all data is in cache and processing of the data can be done before a timeout occurs. (data will grow, more users can use the system, ...)
For REST queries that have the risk of running too long,  you can do as follows :
- the api responds immediately with a queryId (some sequential number),
- the query continues to run in the background, and the response of the query will be stored in some table/global/...  with the queryId as the key
- a separate api call is used by the client (with the queryId) to get the response (or a 'not ready' status when the query is still running).
It is a little more work on the client to call once to launch the query, and a second.. time to get the results, but you are safe when your systems  grows with data or users