Hello CM,

What OS is this? What user are you logged into the OS as before starting the terminal/csession?

<PROTECT> errors can sometimes be caused by OS-level permissions on the CACHE.DAT. I recommend to make sure this user has permissions on the CACHE.DAT file and directory. It could be working through SMP because that process will run as the same user as other background processes, which could be a different user than your terminal process.

Hi Dave,

You could try editing the database definition on the data server, and assign a custom resource for that database. Then, on the app server, create a resource with the same name (System Administration -> Security -> Resources). You could either make it so that the resource has public R-only permissions for users on the app server, or you could make it so there are no public permissions at all. If there are public read permissions for the resource, all users can read from that database but cannot write to it unless you explicitly assign them to a role with RW permissions on that resource, or if they are assigned to the %All role.

You can add this line to the iscagent.conf to enable logging to the iscagent_console.log:

mirroring.console_logging_enabled=true

You will have to restart the ISCAgent for it to take effect.

If you are rebooting the primary machine then it makes sense for there to be a communication error between the arbiter and the primary which is likely why you see a "message read failed" error. The ISCAgent console logging may not give you any more information in this case, but can be useful with debugging problems in general.

For reference, this section of the tutorial can be accessed here:

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GSTD_Start#GSTD_zen_form