I'm not sure I totally follow your architecture and why looking at the arbiter vs a failover member would be better. It would probably be good to discuss the details with your sales engineer (I'm guessing you're already speaking to them about this). Is the VIP not being handled automatically by the mirror? I saw you commented on some ZMIRROR related posts; I think that would be a good way for your mirror to kick off those non-IRIS failover items automatically on failover, rather than needing to poll.

I would encourage you to review the loss of connectivity scenarios covered in our documentation. The arbiter disconnecting from both sides is not enough to trigger a hang.

https://docs.intersystems.com/irisforhealth20223/csp/docbook/Doc.View.cls?KEY=GHA_mirror_set

A hang suggests a total loss of network connection between failover members and the arbiter simultaneously. In general, the arbiter is a supplement to the communication between the two failover members, and not necessarily the first place to look for an issue.

ex. If the arbiter connections to the failover members were first lost, the primary and failover member would remain in contact via their own ISCAgents. Then, if the two members lost contact with each other, the primary would have continued to operate.

What would be the benefit of querying the arbiter (I'm not sure this is possible) for mirror status vs querying one of the failover members? I also wasn't sure what you meant by non IRIS related.

Would it be possible to shrink your transaction? I think that would be preferable. If you aren't concerned about data consistency then what is the role of the transaction?

Hi Norman,

I'm not sure I follow exactly what you are trying to do but I think the object concurrency options can provide what you are looking for. Yes - you can avoid locks even when using objects.

I didn't find an option for this but the release note says that as of 2019.3 IRIS queries run in the background.

https://docs.intersystems.com/irisforhealth20222/csp/docbook/DocBook.UI.Page.cls?KEY=HXIHRN_new20201#HXIHRN_new20201_sql

Definitely reach out to the WRC - another "educated" guess from me on potential causes would be filesystem fragmentation. I've seen that cause databases to fail to expand in the past.

Can Nessus tell you what in particular is allowing the use of those ssl ciphers? Are you sure it's HealthShare that's causing the issue? Where in HealthShare did you disable the lower TLS version?

HealthShare ATNA auditing would be named HSAUDIT by default, where IRISAUDIT is for IRIS level auditing.

Looks like you're experiencing the same thing as this person: https://community.intersystems.com/post/deleting-cleanup-sql-cleanup-index-task

My answer's the same - this is a bug, and should be fixed in the future.

I would go straight to support for this to be honest! They can look at the contents of IRISTEMP with you to help figure out why there's leftover data there.

How are you trying to access the ftp link? I tested and it should be publicly available. Try pasting the link into your file explorer on Windows, for example.

Howdy all,

Iain is right that you can get the ODBC driver from the WRC site directly if you are a customer of ours, but the new spot InterSystems hosts drivers for ODBC and so on is here:

https://intersystems-community.github.io/iris-driver-distribution/

edit: I realized this was asking for Cache, not IRIS drivers, so my answer doesn't address it.

Hi Rochdi,

There's no built-in way to do this, but WRC can help you stop the process if needed.