You can see this schema/table in management portal if you tick the "System" checkbox to display Caché system tables. Queries against this table will work even if the table doesn't appear in the list.

Brendan's post is a related issue, but it's important to note that what he describes only applies if you want to update the value of a specific field when that field contains > 32K of data.  The total size of the message isn't an issue.

As an example: if you have an ORU message with a 10 MB PDF stored in OBX:5, you will still be able to update fields in the PID segment using standard DTL functions. But if you want to update OBX:5 you will need to use the functions that Brendan mentioned.

%ZEN.Auxiliary.jsonProvider can make use of %ZEN.proxyObject to represent the JSON. This wouldn't require a formal class definition for your objects.

Here's a sample for creating a proxy object and outputting it as JSON:

Set tProxy = ##class(%ZEN.proxyObject).%New()
Set tProxy.Property1 = "Some value 1"
Set tProxy.Property2 = "Some value 2"
Set tSC=##class(%ZEN.Auxiliary.jsonProvider).%WriteJSONStreamFromObject(.tStream,.tProxy)
Write "Result (blank means no error):",$System.Status.GetErrorText(tSC),!
Write "JSON output:",!
Do tStream.OutputToDevice()

This produces the following output:

Result (blank means no error):
JSON output:
{
        "Property1":"Some value 1",
        "Property2":"Some value 2"
}

Here's a quick example that returns a custom HL7 message back to the upstream system instead of a standard ACK.

Example

Gertjan, can you add your solution to this topic as a new "Answer"?
Thanks,
Marc

Thanks Lorraine.

At this point it would be best to open a WRC ticket so a support rep can help look into this in more detail.

I just read Dave Loveluck's suggestion below and that sounds like a much better option.

The method signature for OnMessage usually only has two parameters: the inbound request and a response to return.
In your method you have three parameters and two of them seem to be inbound requests. Can you clarify?

Method OnMessage(pREs As TestingEnvironment.ECGTrace.TEST.FSMREQ, pRequest As Ens.StreamContainer, Output pResponse As %Persistent) As %Status

Here's an example of what Carlos is suggesting with XECUTE:

ClassMethod CompareValues(val1, val2, operator) as %Boolean {
    set testStatement="set testResult=(val1 "_operator_" val2)"
    XECUTE testStatement
    quit testResult
}

[edited code to fix a typo]

Joao, just wanted to check with you... did it work after adding quotation marks?

In the case of moving from AIX to Windows, you're not just changing the OS but also changing the platform (IBM Power to Intel).

As Dmitry said, there's no relation to the OS but there is an important issue when changing platforms: endianness. AIX on Power is big-endian while Windows/Linux/etc. on Intel are little-endian.

The upshot is: when moving a cache.dat from AIX to Windows you'll need to run an included utility to convert it from big-endian to little-endian.

For a discussion on JDBC batch handling, see this post.