...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 can calculate a hash for each string and index this hash value. If use pure COS for index building, you can find duplicates earlier, just during index building, without quiering the index afterwards.

Hi Mikhail, you've done a really nice job!

I'm just curious, why:

We don’t care about output to a file.

Wasn't it easier to parse mgstat's output file?

Just a quick note: the last sample with $tr removes _all_ listed chars, so all blanks (rather than leading, trailing and repeationg) would be removed as well.

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...

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.

You can find all levels and badges at the Global Masters Advocate Hub here

This link seems to be broken.

Only the web app's home page was requested, without any attempt to log on, so it didn't write any audit record. In contrast, any attempt to connect 1972/tcp always wrote a "Logon Failure" record described as "Authentication broken" or something like this.

It's better to use CACHETEMP mapped global, e.g. ^CacheTempUserYourGlobal($job,...).

BTW there is another option: having a wrapper job, pass it an array serialized to JSON, other steps are evidient. I used it in one of my projects, and it was quicker than using of ^CacheTemp* intermediate global, while performance gain was not too sufficient (AFAIR)

The approach with a global is apparently easier, so I'd use it if performance would not of great importantance.

I remember well times when routines used to start with  KILL ^CacheTemp*($JOB)

Our developers do the same, but modern versions of OSs usually have 6 digit PIDs, so it may take several days till PIDs would re-cycle their numbers.

PPGs are used, however sometimes they are not applicable, e.g. when information is passed between processes via temp globals.

Clean-up is a good idea, but can be fully implemented when (and only when) all app classes use the same before-exit-processing code, i.e. the app is always finish through one exit point. Sometimes it's difficult to achieve, while it's worth to.

A while ago I thought about some enhancements of my purging task:

• automatic detection of too quick growing globals
• automatic detection of globals which belong to its scope, i.e. have @name@(PID) format.

 Maybe I do it when have some spare time... the priority of this work is rather medium.

Robert, 

You are quite right, but... life is life, and application can finish abnormally. In this case its temp globals are left till Caché restart, sometimes it may cause noticeable growth of CACHETEMP database. So, scheduling a nightly housekeeping task like ours makes some sense.