Maybe worth adding that the two MS packages can be run with command line options suitable for unattended use, e.g.

vcredist_x86.exe /passive /norestart

For a dialog box showing all the command line options:

vcredist_x86.exe /help

or

vcredist_x86.exe /?

I wish an unattended install of Cache would install these runtime prerequisites automatically for us. I think it does that when doing an interactive install, which would imply that the vcredist_x*.exe kits are already bundled inside the cache*.exe installer.

Adding to the other answers, I notice the OP wrote "I need my globals unreadable if other process is in critical area".

This means you will need to obtain LOCKs before referencing (reading) the globals. But in this case you might opt to request shared LOCKs, e.g.

LOCK +(^A#"S",^B#"S",^C#"S")
WRITE !,"^A=",^A,!,"^B=",^B,!,"^C=",^C,!
LOCK -(^A#"S",^B#"S",^C#"S")

The use of shared locks will allow multiple concurrent reader processes, while still blocking all readers if a writer holds conflicting locks. A would-be writer will also be blocked while any readers still hold conflicting locks.

When processing the two pieces of a timestamp such as $ZTS it is safer to assign the timestamp once to a variable, then operate on that variable, e.g.  instead of

W (+$ZTS-47117*86400) + $J($P($ZTS,",",2),0,0)

use

S zts=$ZTS W (+zts-47117*86400) + $J($P(zts,",",2),0,0)

This avoids the edge case in the original code, where the first evaluation of $ZTS happens just before the midnight rollover and the second evaluation at or just after it.

This continues to happen with 2017.1.1 when doing an unattended install. I have opened ticket 886059 with WRC about it. Turns out I had overlooked this note in the doc:

Important:

Before using the Caché unattended installation utility, you must download and install the Visual C++ Redistributable Packages for Visual Studio 2013 from Microsoft (https://www.microsoft.com/en-us/download/details.aspx?id=40784). If you are installing on a 64-bit system, you must install both the vcredist_x86.exe file and the vcredist_x64.exe file.

Eric, to mark your question as "answered" on Developer Community, please click the checkmark alongside the answer you (as author of the question) accept.

I'd also like to draw your attention to DC's facility for commenting on an answer (which is what I'm doing here). It's probably not obvious enough, meaning that you response to Alexander displays as a second answer to your original question.

It's a very long time since I used GBLOCKCOPY on a Cache 5.0 system, but I think you may be able to simplify your steps.

1. Create a new temporary database via Configuration Manager. You probably don't need a new namespace as well.

2. Use GBLOCKCOPY to copy your old database contents into your new database.

3. Dismount your old database and your new one. Or just shut down Cache completely.

4. Rename your old database (the big one), e.g. to CACHE.oldDAT

5. Move the temporary database's CACHE.DAT file to where the old one was.

6. Mount your database (or start Cache).

7. Use Configuration Manager to delete the temporary database you defined in step 1.

8 Check everything is working.

9. Delete the renamed big database file you preserved in step 4.

10. Come back to DC, tell us how it went, and set the checkmark against one of the answers to show you have accepted it.

Expanding on the earlier answers by Eduard and Robert:

A process will not be able to switch to a namespace (e.g. with Do $ZU(5,ns) or ZNAMESPACE ns or Set $NAMESPACE=ns or via Do ^%CD) unless the user holds the Read privilege on the database resource of the default globals database associated with that namespace.

To read about this, see the "Namespaces" subsection of this doc section.