I agree with Lorenzo and Pietro as well! Since I believe you're looking to run tasks/code that has to do with your mirror failing over, I suppose it might be worth taking a higher level look at the scenarios you are hoping to address. Probably most of the things you want to do can be put in your ZMIRROR so that when your new primary takes over it can do whatever miscellaneous non-IRIS failover tasks you want.

What procedures do you need to be concerned about in a clean failover via shutting down the instance (triggering ZSTOP) vs in an unclean failover for whatever reason, in which case you would only expect your ZMIRROR to run?

Hi Mohammed,

This is a fairly common issue with Windows permissions. How are you opening terminal? Are you opening a Windows admin command prompt before entering the IRIS shell? Have you set a service user with the appropriate permissions to run Perfmon, if you are launching terminal from the cube?


Basically, this message is informing you that the user running the terminal (and trying to run SystemPerformance) is trying to open Perfmon and can't. The above are a few things to check.

I would investigate the certs and keys and make sure they are valid for connecting to your end point. You could check things like making sure you have the full certificate chain. I'm afraid IRIS can't really tell you more about why the certificate is being rejected, this is a TLS problem.

My other note would be that TLS 1.1 is deprecated as of 2021 so I would avoid it, and SSL v3 is extremely deprecated so I would avoid it even more strongly.

Hi Scott, that doc is here:

Improving Restarts for Productions with Large Queues

That being said - I thought the move from suspended back to the queue was automatic generally, and wouldn't require a manual resubmit?

"By default, when a production is stopped, any asynchronous messages on the ^Ens.Queue global queue are moved to the ^Ens.Suspended queue. When the production is restarted, they are moved back."

Hi Elmahdi,

I saw you commented on another post where I (like Anastasia) pointed to WRC distributions. You are looking for Cache 2017.2.2 which actually is not currently available - that's because InterSystems only freely makes available versions of our software with the latest security improvements. If you need an older kit that isn't currently available on the WRC page, you'll need to either find a copy your organization has on file somewhere, or you can make a special request through InterSystems support.

Back of the napkin here, but I'm guessing that Eduard's dynamic object implementation wasn't available in 2014. 3.5mb seems suspicious as a string size limit so I would suggest trying to read the data into a stream explicitly. ex. from the latest IRIS documentation which I believe may still be pertinent to your use case.

Accessing the HTTP Response

set request=##class(%Net.HttpRequest).%New()
 set request.Server="tools.ietf.org"
 set request.Https=1
 set request.SSLConfiguration="TEST"
 set status=request.Get("/html/rfc7158")
 if $$$ISERR(status) {
         do $system.OBJ.DisplayError()
 } else {
         set response=request.HttpResponse
 Set file=##class(%FileCharacterStream).%New()
 set file.Filename="c:/temp/rfc7158.html"
 set status=file.CopyFrom(response.Data)
 if $$$ISERR(status) {
         do $system.OBJ.DisplayError()
 do file.%Close()

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.


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.