First thing that comes to mind is disabling TLS 1.1 as that is deprecated. For TLS 1.3 (if that's required) you'll need to migrate to IRIS ( being on Cache 2017 probably has other security implications that would be remedied by upgrading at least to Cache latest.)

You might be able to find out more about this issue using ^REDEBUG as discussed in another post on the community, else support can probably help look into what the issue is. It's been a bit since I've worked on something like this myself.

Hi Giannis,

That's just a generic login error, what is the situation you are encountering? If none of your users can login maybe you can try getting in with emergency access mode and checking the audit log / user settings.

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.