The solution I've found is rather simple than smart: to start a dejournalizer as a JOB with an 'answer file' specified as a principal-input device. The code prototype looks like this:  

 set fin=$zu(12)_"Temp\fin.txt"
 set fout=$zu(12)_"Temp\fout.txt"
 open fin:("NW"):1 if '$t {write "not opened!",! quit}
 use fin write "N",!,"N",!,"Y",! close fin
 job jrnrest^ztestFF("20180614.006"):(::fin:fout):1 if '$t { w "not started!" q}

Its execution resulted in "fout.txt" file like this: 

20180614.006 to 20180614.006; c:\intersystems\cache\mgr\user\ => c:\intersystems\cache\mgr\test\

Do you want to rename your journal filter? o
Do you want to delete your journal filter? o


c:\intersystems\cache\mgr\journal\20180614.006
   8.88%  14.29%  15.26%  16.79%  18.08%  19.31%  20.35%  21.32%  ....
***Journal file finished at 16:39:36
Do you want to rename your journal filter? es
Journal filter ZJRNFILT renamed to XJRNFILT


[journal operation completed]

"o" and "es" were provided by the auto-completion of "N" and "Y" answers.

Cons of this approach is that ISC can change the ^JRNRESTO dialog in some future version.
Pros: no need in reverse engineering of ^JRNREST stuff to derive a non-interactive journal restore utility.

Hope my writing will be useful for somebody besides myself. Happy coding!

Hi Joan,

It seems that the right way to perform this task would be using MemberStatusList query of the class SYS.Mirror. See Documatic for details.

HTH.

Yes, I did.
It did not seem working, STOP / START of the System Monitor didn't help.
I lost my interest to Callback functionality because of its absence in newer Caché version, so I would not investigate it anymore.

We have a TASKMGR's task that purges such kind of globals daily. (Sub)globals are cleaned using the following criteria:

  • Global has a structure of @name@(PID)
  • Global is listed in predefined "known globals" list
  • Caché process identified with PID is not running.

If +value=value

This classic code is good for checking if the value is canonical number, while the term number can be interpreted in some other ways, e.g. a number in scientific format, double precision number, etc. Caché has a set of out-of-the-box functions to perform some of these checks, e.g. $isvalidnum, $isvaliddouble, $number, $normalize.

So, the answer depends on topic starter's conditions.

E.g., if I need to check if a number is a numlit (scientific numbers and numbers with starting zeroes are allowed), I'd use `$isvalidnum(x)`. Addition check on being integer (an intlit) can look like: `$isvalidnum(x)&&(+x\1=+x)`. Here are some testing results: 

USER> w !,?6,"Is number?",?20,"Is integer?",?35,"Is canonic?"
USER> for x="001a","002",0,1,"-1.2","+1.3","1E3" w !,x,?10," ",$isvalidnum(x),?20," ",$isvalidnum(x)&&(+x\1=+x),?35,x=+x
 
      Is number?    Is integer?    Is canonic?
001a       0         0             0
002        1         1             0
0          1         1             1
1          1         1             1
-1.2       1         0             1
+1.3       1         0             0
1E3        1         1             0

In other conditions I'd write another code. There is no universal answer to topic starter's question.

P.S. As to "Annotated MUMPS Standard" (http://71.174.62.16/Demo/AnnoStd):
An intlit is not necessarily a canonic representation of a number.

numlit is not necessarily a canonic representation of a number.

The reduction to a canonical numeric representation involves (colloquially) the removal of any redundant leading and trailing zeroes, the conversion of exponentionential notation to "mantissa only" notation, and the reduction of any leading plus (+) and minus (-) signs to at most one leading minus sign (see also Numeric interpretation of data).

During Cache backup it appears that all the available memory on the server is being used.

It's usually not a problem as the more memory is used for buffering the quicker file i/o operates. Only free memory is used for this purpose, so memory allocated by users' or system processes should not be swapped. Please add more details, why it turned to be a problem in your case?

PS. Double check in console log whether Cache allocates its shared memory segment using large pages as it guaranties that it is totally allocated at Cache startup and will neither be expanded nor swapped afterwards.

RTFM, should I say to myself. <Database> tag is required, according to documentation:

<Database>

  Required; within <Configuration>. Defines one or more databases used in the namespace. 

Taking in account that there was no need in any database [re]configuration, the problematic fragment was scaled down to: 

<!-- Configure the database that should exist upto this step: we don't need it, but the tag is required -->
 <Database Name="${MainDB}"
 Create="no"
/>

And it was enough to make it working. Despite of nasty message logged:

2017-04-03 12:32:18 1 CreateDatabase: Creating database USER1 in D:\InterSystems\Cache10\mgr\ with resource 

nothing bad happened neither with CACHESYS, nor with USER1 databases.

I agree, it's elegant, but not memory efficient design: the sorted array is built only to pick up its top node. Of course, arg lists are rarely long and yet another small array doesn't mean much, but in more generic case of searching the max element in array of sufficient size the following code should be twice more memory efficient and maybe a bit faster:

ClassMethod max(args...) {
  max=$g(args(1)),im=1 for i=2:1:args s:max<$g(args(i)) max=args(i),im=i
  $lb(max,im)
}

P.S. I was curious if my variant was really faster and ran some tests. Here are the results that were collected using an array filled with random whole numbers. An array was refilled on each test run. 

In the table below:
 min - the lower limit of numbers values in the array
 max- the upper limit of numbers values in the array
 n - the quantity of numbers in the array
 var - # of variant (1 - original, 2 - mine)
 dt - average run time (in seconds)
 dtfill - avg time of filling the array; just for info.

min       max       n         var  dt        dtfill
-10000000 10000000  10        1    0.000005  0.000002
-10000000 10000000  10        2    0.000001  0.000002
-10000000 10000000  100       1    0.000047  0.000012
-10000000 10000000  100       2    0.000004  0.000012
-10000000 10000000  1000      1    0.000425  0.000115
-10000000 10000000  1000      2    0.000031  0.000115
-10000000 10000000  10000     1    0.005828  0.002949
-10000000 10000000  10000     2    0.000554  0.002949
-10000000 10000000  100000    1    0.074641  0.031128
-10000000 10000000  100000    2    0.006824  0.031128
-10000000 10000000  1000000   1    1.194625  0.313878
-10000000 10000000  1000000   2    0.069191  0.313878