Glad you found that interesting! One warning I can add is that if you do decide to add a "no-integrity" type purge and if you've never run one, depending on how many messages you have you may trigger a very large purge (and a lot of journaling activity as a result). Often times when making significant purge changes, it can be safer to increment the time period you are purging bit by bit to make sure you're not asking too much of a single purge.

ex. If you run daily message purges then every day you are purging 1 day's worth. If you have "expired" messages going back a few years and decide to purge them all of a sudden, that might be a surprising number.

I would generally caution against killing IRIS jobs from outside IRIS, as under rare conditions this could lead to IRIS hanging. If this is a concern I would suggest reaching out to WRC who can help you confirm that a process is safe to terminate.

The journal does not contain the line of code (imagine needing to log that information for every single global modification), so to find the relevant code would require the type of cross referencing I suggested. The other option I would suggest would be to go through the program in the debugger. Especially if you have a general sense of where the relevant change would be made. But again, maybe the best option depends on why you are looking for this specific global set.

Most likely more context on what you are trying to look up would be helpful to understand how best to approach this request. What occurs to me immediately is this might be a good case for involving the WRC to help investigate.

If you want to look into it yourself I think you would want to read through the journals to find the global set in question and what is being done around that set, then tracking from the process to what else it was doing at the time. You may need to have a SystemCheck / irisstat running in order to correlate the process to whatever routine it was running.

Hi Cristiano, it is not recommended to use transparent huge pages:

https://docs.intersystems.com/irisforhealth20241/csp/docbook/DocBook.UI.Page.cls?KEY=ARES#ARES_memory_plan_pages_linux

Failing somebody who has run into this before, I would suggest opening a WRC ticket so somebody from InterSystems can look at the relevant code and see what (if anything) can be done to avoid this behavior. Once you get that reply I'm sure there would be no problem sharing with the class here 😉

Hi Scott, just to double check that this setting is per namespace. If that isn't working, I'd suggest opening a WRC case.

I'm guessing you're running into this limitation "The ObjectScript method used by DTL transformations, GetValueAt, truncates HL7 segment fields at 3.6MB."

Docs cover how to work around this.

https://docs.intersystems.com/irisforhealth20233/csp/docbook/DocBook.UI.Page.cls?KEY=EHL72_transformation#EHL72_transformation_longsegments

Hi Wayne,

Please try scrolling to the right. If it still doesn't work I'd contact InterSystems support to see what the issue is. There may be a network security issue preventing parts of the web page from loading.

To piggyback off this, the initial way to run IRIS under a certain user is to use setserviceusername:

https://docs.intersystems.com/iris20232/csp/docbook/DocBook.UI.Page.cls?KEY=GSA_using_windows#GSA_using_windows_nonadminperm_change

As far as I know you can then update the credentials from services as suggested above, but you may want to keep in mind using setserviceusername if you run into other credentials / Windows permission style issues.

Mark, thanks. I've reported this internally.

Agreed with Alex. If you're seeing inexplicable issues when you think the data should be arriving correctly, I'd suggest looking at a network trace to get the details on how data is coming across.