Robert, it sounds strange, but... Setting the Time Zone

You can use $ZTIMEZONE to set the time zone used by the current InterSystems IRIS process. Setting $ZTIMEZONE does not change the default InterSystems IRIS time zone or your computer’s time zone setting.

IMHO, $ztimezone setting is dangerous not for its system-wide effect (which it hasn't) but mostly due to its exclusions and anomalies, despite they are accurately listed in docs.

When I inserted your sample call of %apiOBJ nothing bad happened with the parser, maybe the update would help yours. Meanwhile, more standard way of doing the same:

  do $system.Status.DecomposeStatus(sc,.err,"-d")

is apparently better supported with VS Code: pop-up help and parameters prompting are rather handy, aren't they?

Hello Stefan,

Thanks for the reference, while I'm still not sure about the step #2 as ^JRNRESTO provides the  (defaulted) option to disable journaling of updates during the restore to make the operation faster, see the step #10 of Restore Globals From Journal Files Using ^JRNRESTO. Besides, this is the only option compatible with parallel dejournaling. So the idea to switch off journaling system-wide looks excessive.

Regards,
Alexey

I've succeeded with the code: 

%SYS>s P("Globals")="%DEFAULTDB"
%SYS>s P("Library")="IRISLIB"
%SYS>s P("Routines")="%DEFAULTDB"
%SYS>s P("SysGlobals")="IRISSYS"
%SYS>s P("SysRoutines")="IRISSYS"
%SYS>s P("TempGlobals")="IRISTEMP"
%SYS>Set tSC=##class(Config.Namespaces).Create("%All",.P) zw tSC
tSC=1
%SYS>w $zv
IRIS for UNIX (Ubuntu Server LTS for x86-64) 2021.1 (Build 215) Wed Jun 9 2021 09:48:30 EDT

...to brand new server with iris2020.1

It's up to you, but why not install brand new IRIS on your brand new server? As you may notice, InterSystems is actively develop IRIS and usually doesn't release minor updated versions as it was in the case of Cache (e.g. IRIS 2020.1.1 vs Cache 2018.1.5). Choosing 2020.1, you are going to install the version which is near the end of its support cycle, see Minimum Supported Version Rules.

If you can't access Portal, you can edit cache.cpf with some text editor. SystemStart parameter is to be changed.

This (getFiles) method is marked as internal in Cache, and yes, it's typical internal as it's usage is relied on the strong internals knowledge :). Besides, it's hidden in IRIS, and its caller should be rewritten to achieve DBMS independence:

 ClassMethod ListDir2(path = "", wildchar = "*", recursive As %String(VALUELIST=",y,n") = "y", ByRef dirlist)
{
 s pExtension=1
 s pExtension(1)=wildchar

#if $zversion["IRIS"
 s temp=$name(^IRIS.Temp)
#else
 s temp=$name(^CacheTemp)
#endif
 
 s pTempNode=$i(@temp)
 k @temp@(pTempNode)
   
 d ##class(%SQL.Util.Import).getFiles(path,.pExtension,pTempNode,recursive="y")
 m dirlist=@temp@(pTempNode)
 k @temp@(pTempNode)  ;zw dirlist
}

Methods how these macros are defined are quite different: $$$ISWINDOWS is calculated using system call and always 1 on Windows platform, in contrast $$$WindowsCacheClient is defined manually, so it and can be easily set to 0 if needed.

Many years ago I faced a problem with LDAP which was solved this way (I didn't change ISC code, it was my own "fork"). Don't remember other details, only the fact.

Converting the file name to UTF8 usually helps. E.g.

USER>s file=$zcvt("/home/qms/Müller_Jörg.txt","o","UTF8") w $zf(-100,"","touch",file)
0

qms@testhost:~$ ls -l Müller_Jörg.txt
-rw-rw-r-- 1 qms cacheusr 0 May 15 18:39 Müller_Jörg.txt

Besides mapping ^ERRORS to a non-journaled database, you may want to tune the ErrorPurge configuration parameter that resides under  System > Configuration > Startup Settings in SMP. As its default (30 days) is usually too big, it can be easily reduced to 7 days.

Yes, it's possible. You can use %SYS.Task for a Task API. Its methods and properties are well documented in its superclass %SYS.TaskSuper.

Yone,

if you really moving the files every day, you don't need to check the date: there are no old files in your in-folders, because they have been deleted with mv  (move) command. Most pieces of software which does the similar tasks (e-mail clients and servers, SMS processors, etc) do it this way, moving files rather than just copying them. The simpler the better, isn't it? 

It depends.

Switch 10 which inhibits all global/routine access except by the process that sets this switch should meet, while setting it can interfere with your _own_ activity.
Switch 12 which disables logins can be insufficient for disabling web access, which is easier to restrict by stopping web server.

I didn't personally experiment with those switches as we have no such problem because our application utilizes its own "disable logins" flag by locking the variable.

Another possible approach:

• copy global stream to file
• process it using external OS call; in Linux we use its native zip/unzip utilities, in Windows - console version of popular free 7-zip tool. 

Just adding 2c to Kevin's reply.

Most hosts that support TCP also support TCP Keepalive  

Besides, server application should support it. 3 hours keepalive time setting is not typical; it sounds like your server app not tuned for keepalive support or doesn't support it at all.

In case of IRIS/Caché, you should explicitly set some options on connected server socket, e.g.:

start(port) // start port listener
  s io="|TCP|"_port o io:(:port:"APSTE"):20 e  quit
  while 1 {
   u io r x
   u $p // connection is accepted: fork child process
   j child:(:5:io:io)
  }
 
child
  use $p:(:/KEEPALIVE=60:/POLLDISCON)
  ...

/KEEPALIVE=60 to set keepalive time to 60 seconds
/POLLDISCON to switch on TCP probes.

Paul's warning sounded like this setting changed after the instance re-installation, while it unlikely could, as even in IRIS, according to docs:

System-Wide Security Parameters
Allow multiple security domains ... [Default is a single domain]

After re-reading excellent articles referenced above, it seemed that:
1) Too low QoS value can be incompatible with VM Stun time.
2) Too high value can be inappropriate as well for some other reasons. E.g., it can postpone a failover when it's of real need when Primary crashed or isolated.
So, why not stop bothering about QoS value, and just Set No Failover during snapshot phase? Documentation describes how to do it manually, while it should be possible programmatically as well.

 ...^MSU has been replaced by ^DATABASE for a long time.

At least in 2017.2 it is still available, despite its deprecation ages ago. I still prefer to call it as there are less characters to type.