Hello Mark,

That's a HealthShare Information Exchange / Unified Care Record specific task. The "standard" mirroring docs don't cover it for that reason. As you gleaned from its code, it makes sure the HealthShare mirror agent is running. To be honest, I don't know all the details of what that agent does.

I'd suggest reaching out to the WRC to investigate what happened to cause the task to fail, and they can probably give more details on what the task does. While you're at it, you could also ask why it isn't documented, and poke on why it's listed as a user type task - though I see that many of the HealthShare-specific tasks are "user"-typed, so perhaps that is intended.

It's been a while since I looked at SNMP but I believe that you can monitor database free space by setting up the Caché SNMP agent (perhaps you already have some of this configured.)

At a higher level - I would consider how much database space you are using. Does the database actually fill up (or get close to filling) between each purge? if so, then you're not really so "safe" and may need more disk space. If the databases don't completely fill up and are only so large because of an unusual event in the past, then maybe you can free up some disk space by upgrading to a version where you can safely compact/truncate, and then you have meaningful alerting based on OS free space.

What do you expect your database growth to look like in the future? Maybe you're within the bounds now, but if your activity grows in the future or spikes abruptly due to an unexpected load, will that cause a problem?

Hope that helps.

Aside from Robert's reply of viewing in the portal, there is also ^%FREECNT.


In terms of the risks of letting the disk space fill up, that's hard to say. If everything happening is inside a database with free space, your disk wouldn't be filling up more. It's that other activity that may run into or cause a problem. I would say to consider compacting/truncating, though your $zv is really old so it may not be safe to do so.

I totally agree with Warlin that it really depends on what you are trying to do and your current setup. My interpretation of your question is that you are trying to migrate your data / user settings to a new server / instance?

I would say to use the server migration guide as a starting point - but definitely test the process since you're crossing versions also which is beyond the scope of that documentation.

What format are you using for your key/cert? Generally, our docs are fairly clear about which format to use - though not always! We're working on it and if you notice something missing, please report that using the "Feedback" button on the right side of the docs page.)


In this case, the example we give is in pem format, not pkcs12. 

It's tough to say without knowing your config and what exactly was done. For the second error at least it seems reasonably clear what could be causing it, maybe that will help to resolve the first error as well? I'm not an Apache expert so take my personal advice with a grain of salt, I just know that many people have found Mark's article to be helpful.


Hi Scott,

Did you look at Web Servers for UNIX, Linux, and macOS? That page explains how to configure Apache to serve CSP files.

I'm not sure what you mean by calls to the management portal. If you have the standalone Apache / gateway set up appropriately, you can serve the portal through (presumably default) port 80, ex. go to http://<hostname>:80/csp/sys/UtilHome.csp, rather than attempting to use your private web server port.

Really the independent Apache is the main piece, you can consider the standalone web gateway to be a module on that Apache web server.

Hope that helps.