Hi John and Roman,

Although the answer is accepted, it seems that JOBEXAM can only help recognize that DBREST is still running, so the initial question about the completion time expectations would hardly be answered this way.

Roman, only your previous experience can help answering your question. BTW, "weakness" of your host as you described it can't be a reason of slow DB restoration as DBREST is single-threaded utility and mostly i/o bound one. The reasons for slowing DBREST down are usually: slow disk subsystem and/or slow LAN connection to network resource where .cbk files are stored.

Entry level SAS RAID and 1000BaseT LAN usually provide 40-50MB/s speed on DB restoration.

...and spread over documentation

...Or undocumented, as it is in cases #3 and #4. 

It seems that it's possible to form a simple rule whether you can use a private variable: if you can consider its name to be evaluated at compile time, you can, otherwise - no:

1) Indirection: variable names (or expression that contains them) are evaluated at runtime.

2) Xecute: similar to #1. In contrast, $xecute() arguments names can be evaluated at compile time.

3) Child process's symbol table filled with switch#2=1: runtime.  In contrast, job's entry arguments names can be evaluated at compile time.

4) %SYS.ProcessQuery is dynamically querying other process's symbol table, so, run time only.

Hi Robert,

There are at least two additional exceptions:

3. JOB command with passing the symbol table to the spawned job

See http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...

When switch#2=1, only public variables of parent process are passed to its child.

4.  Class %SYS.ProcessQuery, query VariableByPid() (or $zutil(88,2,Pid,Variable) for old schoolers)

Only public variables of another process can be queried.

$ ccontrol qlist

CACHE1^/opt/cache1^2015.1.4.803.0.16768^running, since Fri Sep 15 18:44:33 2017^cache.cpf^1972^57772^62972^ok^
CACHE2^/opt/cache2^2015.1.4.803.0.16768^running, since Mon Jul 24 08:43:47 2017^cache.cpf^56773^57773^62973^ok^
CACHE3^/opt/cache3^2015.1.4.803.0.16768^down, last used Thu Jul 27 18:02:03 2017^cache.cpf^56774^57774^62974^^

Windows analogue exists as well.

It depends.

If you don't care about uniqueness of this hash, you can use any algorithm (the quicker the better, MD5Hash or even CRC32) and store your index like normal non-unique one. On calculated hash match to already stored (indexed) hash value you just compare the correspondent strings to separate real matches from the collisions. Maybe it's worth to use whole string as an index for reasonably short strings.

You may need to make the CACHELIB database R/W to save the edit to %ZSTART

No, because %Z* routines are stored in CACHESYS database. The only exception is `%ZEN.*`. You may want to check `do SHOW^%NSP` output:

Routine name/Range        Type      Dirset              Target directory
-------------------------------------------------------------------------------
   ...
   [%SYS/:%Z)             INT                           c:\intersystems\cache\mgr\cachelib\
   [%Z:%ZEN.)             INT                           c:\intersystems\cache\mgr\
   [%ZEN.:%ZEN/)          INT                           c:\intersystems\cache\mgr\cachelib\
   ...

===============================================================================
               ... a square bracket [] means that
               left or right margin is inclusive, while a parenthesis
               means that the margin is exclusive...

Yet another variant of quotes duplicator (pure Mumps): 

dupP(str)
  quit:str'[$c(34) str
  new strdup,set strdup="" for j=1:1:$length(str,$char(34))-1 set strdup=strdup_$piece(str,$char(34),j)_$char(34,34)
  quit strdup_$piece(str,$char(34),j+1)

Quick testing showed that the quickest variant is my initial $$dupquote(), $$dupocc() is very close (5-15%  slower), $$dupP() took 3d place (2 times slower), $$QT() is the slowest (not surprise as it uses recursion).

It was interesting to find that the good quality of $replace() implementation allowed it to beat $zutil(144,) "system" function. While I'll keep using it, analyzing Vitaliy's code I've found the error in my own $$dupP().

Both had the need to pass along data by references as memory was very limited
and processors were incredible slow (compared to today).

Robert, thank you for this quick historical excursion!

Just adding 2c: it seems that the reasons to introduce pointers were deeper than just resources saving:

  • it was the reasonable way to pass arrays back and forth,
  • it was the reasonable way to return several values from functions/subroutines.