Ben,

Thanks for prompt response.

I didn't see any guarantees that a previous non-Ubuntu installs would be upgradable (in fact I would be surprised if they were)

In contrast, I was surprised that one supported platform (2015.1/SUSE on Ubuntu) is not clearly upgradable to another supported one (2017.2/Ubuntu). Direct upgrade from 2015.1 to 2017.2 was promised somewhere in Caché Installation Guide.

I suggest you contact the WRC for final confirmation

Thank you again, while I don't feel that this is a real problem worth disturbing WRC, meanwhile it seems that my solution is feasible.

Moving all the stuff from old 2015.1 to fresh 2017.2 instance was not a problem in my case, but it could cause some caveats, e.g. one should not forget to move all security settings, task manager tasks, etc. Anyway, there is (potentially) much more work to do than to change a couple of lines in parameters.isc file.

Any cons?

A bypass that was quickly found:

- Being a root, save a copy of <installation dir>/paramaters.isc file

- Change two lines of the original file from 

platform_selection.platform: lnxsusex64
platform_selection.platform_family: lnxsusex64

to

platform_selection.platform: lnxubuntux64
platform_selection.platform_family: lnxubuntux64

After that the upgrade installation proceeds without any problem, a few system and application functions which I've managed to try are OK as well.

I've published my question here because:

- I was not quite sure if my soultion was right.

- If it was right, could installation script be smart enough to recognize SUSE version installed on Ubuntu?

David, thank you for sharing your experience. 

Both tools take significant resources and should rarely be used on a live system

According to my rough estimate, PERFMON provides about of 20% performance penalty when collecting the default metrics. But sometimes we need to evaluate the live system's busiest processes activity in details, e.g. get process stack, process variables, current state, GREF/s, etc.

%SYS.ProcessQuery class methods are evident way to go, while there are some documented notices about possible performance impact.

The question is: which per process metrics can be collected on a live system without significant performance penalty and what is the right way to collect them?

Hi, Nikita,
I'm a new WebTerminal user, just installed v.4.7.3.

JOBEXAM has problems with it, and it seems that it's %X364 support again. Here is an excerpt from my session: 

CWTv4.7.3 ...

...

USER > zn "%SYS"

%SYS > d ^JOBEXAM

<NOLINE>^%X364

╠%X364 ; BINDING FOR ANSI X3.64 NAMESPACE, NOV/92 ; LRS952 06/07/05

%SYS > w $zv

Cache for Windows (x86-64) 2017.2 (Build 744U) Fri Sep 29 2017 10:58:27 EDT

I've checked %X364 source, it has got correct DAQ() code with this Caché version.

Waiting for your help and advice.

Just 2c to add. If a "national" locale is effective, e.g.

%SYS>zw ^%SYS("LOCALE","CURRENT")
^%SYS("LOCALE","CURRENT")="yruw"

and the setting was done before Caché restart:

%SYS>set ^SYS("NLS","Config","LocaleFormat")=1

you will get your national day name if don't forget to set localeopt=0, e.g.

USER>f localeopt=0,1 w localeopt," ",$ZD($h,12,,,,,,,,localeopt),!
0 Среда
1 Wednesday

It's also possible to achieve the same overriding format defaults for the current process (see $ZDATE description for details). I emphasized the need in Caché restart just because didn't find it in docs.

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.