I suspect that the database has 2 KB block size. It would be mountable in 2008, but not in 2014. If you still have access to the 2008 system, you can run GBLOCKCOPY to convert the database to 8 KB blocks.

You should definitely contact the WRC about this. We will definitely want to look at your cconsole.log file. My best guess without much information is that a Caché process died abnormally (was killed at the OS level, or some other way that it wouldn't go through Caché halt codes) while holding onto the resource that controls access to the PID table. This basically prevents any new processes from being created. 

You'll likely need to run 'ccontrol force cache' to get the system down, but please collect a CacheHung report beforehand (a script in the /bin directory of the instance) to provide to the WRC.

These messages generally mean that a process is trying to run a routine as it is re-compiled, and the kernel realizes that the routine has changed out from under it. They don't necessarily indicate a problem, hence the informational 'level-0' message.

You want to use the condition parameter of zbreak. Take a look at this code:

zTestDebug
s x(1,2,3) = -2
s x(1,2,3) = 1
s x(1,2,3) = 3

If I do the following with zbreak:

zb *x:"B":"$g(x(1,2,3))>0"

This just breaks if x(1,2,3) is greater than 0. Then execute the routine, this is what happens:

%SYS>d ^zTestDebug
 s x(1,2,3) = 1
 ^
<BREAK>zTestDebug+2^zTestDebug
%SYS 2d0>g
 s x(1,2,3) = 3
 ^
<BREAK>zTestDebug+3^zTestDebug
%SYS 2d0>g
%SYS>

You can add an argument to $zf(-2) such that the child PID is returned in $ZCHILD. This is documented here. For reference:

s rc=$zf(-2,"program","","",1) 
s childpid=$ZCHILD 

I'm a bit confused by this question. When a failover happens, all the connections to the instance will be forcibly shut down, since the instance will be forced down. 

If you want to do anything to start things up at a specific point in the process of the other node becoming primary, you can put code in ZMIRROR.

Anything launched by $zf(-1) is going to run as the user that is running the original process. In the case of a Caché terminal session, that will just run as whatever user is running the terminal, and there's no way to get around that. 

If you were to use another method to run the $zf command, such as a Telnet connection, or running it via the Caché task manager, the process would instead run as the user who owns the Caché Controller services. So, if you REALLY need to be able to run cmd as an administrator, the best way would be to make the user who owns Caché  the system administrator user, and then run this code via the task manager (you could use a RunLegacyTask).

All that said, I have to agree with Rubens, this is not an ideal setup for security reasons, why can't you just make it such that your executable will run without the need for administrator access? Is there a particular reason why it requires administrator rights?

If you are using the Cube's terminal, you can define a connection (Preferred Server -> Add/Edit) that points to the VIP (assuming that the 2 mirrored instances are using all the same ports). You could then make that the preferred server (Preferred Server -> click on that connection). Then the default behavior for that cube's terminal would be to connect to the VIP address.

However, if you are trying to run scripts on only the primary server, you may want to look into using task manager. You can define tasks to run only on the primary mirror member. You could have the task call out to the script on both instances, and it will simply not run the task if the instance isn't primary.

The concept of a relay server was something built into the original design for mirroring. It was never fully implemented, hence the lack of documentation. There is no way to use a relay server.

I strongly suspect that the code we don't see (from running the routines executed within the task) kills the 'Status' variable. Take a look at this documentation.

I wasn't able to find 'database read test' anywhere in the Caché source code. Are you sure this isn't something custom being logged by your application? Try searching your source in Studio to see if you can find it.