This is best to be handled by the WRC. Please contact and provide the full cconsole.log as well as the timing of your attempted startup and details of what you deleted, how, and when.

For what it's worth, my best hypothesis based on the snippets you provided is that you have custom startup code that isn't completing (possibly due to whatever you deleted), which is blocking startup from continuing.

Calling into IRIS won't work if the instance is hung, so the only way to detect that is something external to the instance. Take a look at 'iris qlist'. You can get more information from 'iris help qlist', but here are the basics:

        iris qlist
        Quick list InterSystems IRIS registry information for all instances, in a format suitable for parsing in command scripts.

To add to this, given that you're concerned with security and want to use TLS 1.2, you should strongly consider upgrading, as 2012.1.2 has a number of security issues that have been fixed over the years.

Is the database journaled? Remote non-mirrored databases on mirrored ECP database servers can only be mounted read-write on the ECP application server (in this case the reporting async) if the database is NOT journaled on the database server. This is documented here:

"Select the database you want to access over this ECP channel from the list of remote databases. You can select both mirrored databases (databases listed as :mirror:mirror_name:mirror_DB_name) and nonmirrored databases (databases listed as :ds:DB_name); only mirrored databases remain accessible to the application server in the event of mirror failover. When the data server is a failover member, mirrored databases are added as read-write, and nonmirrored databases are added as read-only, if journaled, or read-write, if not journaled; when the data server is a DR async member, all databases are added as read-only."

This isn't enough information to answer definitively, as we don't really know whether there is a limitation on the client side or the server side. You should check IRIS' messages.log file. My best guess is that the errors may be due to running out of licenses. Either way, I think it's worth engaging the WRC on this, as a lot of setup-specific information is going to be required to get to the bottom of it.

The short answer is that you cannot restore a CBK from AIX (a big-endian system) onto Windows (a little-endian system). You would need to restore the CBK on another location on AIX (or another big-endian system), and copy the CACHE.DAT to the Windows system, where you can run the cvendian utility to convert the endianness. Note that this comes directly from that page of documentation:


This utility does not work for backup and journal files. You must restore databases on a platform of the same endian, move the restored databases to the different endian platform, and then use the cvendian utility to convert the databases.

First, when you say you "loaded" 2017.2 onto your machine, did you do an install or something else? 

It sounds like you have a corrupt Windows registry. If you didn't do a full installation and just copied files onto the machine, that would certainly have caused this.

If you did do an installation, I'd suggest contacting the WRC, as this should never happen, and we'd like to get to the bottom of it.  We'll definitely want to look at the cconsole.log and the installation log (in C:\Windows\).

There are no built-in REST APIs to call the API's, but you could easily write one.

All the methods to retrieve the list and add/remove databases from the list are documented in the Backup.General class here. As John mentioned, there is no way to freeze or thaw individual databases; it is a system-wide operation.