Disabling an Ensemble Production

I'm not saying that this is in anyway "best practices," but I'm in a peculiar situation where I need to restrict users from starting a "retired" Ensemble Production in a namespace that's been renamed. It's still an "Ensemble-activated" namespace; we need to keep it available for Ensemble Message Viewer access ... fortunately, only for a little while.

It's a bit of a hack ...

Open the Production class in Studio and add the following classmethod:

ClassMethod OnStart() As %Status
{
    Return $system.Status.Error(5001,"THIS PRODUCTION IS DISABLED.")
}

A Production won't start if its OnStart() callback returns an error. And that's exactly what this OnStart() method does laugh

Of course, if there are better ways to accomplish the same thing, I'm all ears!

Comments

That's a great suggestion, Eduard, and far simpler than my code-based solution. My only concern is that I will be extracting the messages from the retired Ensemble message database so that it can be deleted, and I'm not sure whether the task I've written to do this will require any temporary, behind-the-scenes global storage on the database itself. Easy enough to test, though, as I have two other environments with the same configuration (Dev and QA).

Just a quick follow-up ... no issues at all with making the database R/O. Works just as well as I'd hoped!

 Second followup: R/O mode did something bad to the "Update SQL query statistics" task that comes standard with Caché. Caused it to dump millions of <PROTECT> records into the Audit database, which ballooned in size and ran the application directory out of disk space. Terminating  and restarting the job had the same effect. Not sure what's going on, have a ticket open with the WRC now.

If you don't need statistics, this should help

kill ^rINDEXSQL("sqlidx")

or with macros

kill $$$SQLIndexRoot

Untested but should help.

Maybe backup the global just in case.

Apparently there's a patch for the task so that it doesn't pollute the audit database when the <PROTECT> error occurs on a R/O database, but I don't think it's available for 2017.2.1.

I've been told dev key MAK5003 in Caché/Ensemble 2018.1.2+ is the solution, but the next upgrade will be to IRIS, which should also have that fix.