Dmitrii,
Your ideas sound interesting, while I have some doubts. One usually needs speed for scientific calculations. Skipping the discussion how good ObjectScript as interpretated language fits this need, if we place upon our (even small) additional interpreter, nobody would envy our calculation speed.

Your most infamous errors list can be appended with many others, such as "DO I=1.3" error which destroyed some satellite. Besides, missing The International Date Line example is merely logical error that derives from "common" inaccurate development practice.  Alas, such development errors list is sadly long, and I doubt if physical measures mismatch has the highest rate among others.

Jeffrey, thank you for the info.

Do you already know that the Supported Platforms document link is broken? (404)

Does anyone use this in production?

We tried; our intention was rather modest: just to run Caché system utilities. Alas, even JOBEXAM failed. The issue was discussed with the author, and it turned to be difficult to amend by design.

Just a quick note: when errors are processed consistently, e.g. each %Status have been returned is processed with $$$TOE or $$$ThrowOnError  or $$$ThrowStatus macro, this approach seems to be excessive, and `set sc=ex.AsStatus()` is just enough. E.g. 

ClassMethod GetDBProp(pDBname, ByRef pProp, pDivide = 1) As %Status{
  try {
   new $namespace set $namespace="%SYS"
   set sc=1/pDivide ;potential <DIVIDE>
   $$$TOE(sc, ##Class(Config.Databases).Get(pDBname,.pProp))
  } catch ex {
   set sc=ex.AsStatus()
  }
  quit sc}

For me, unexpected %objlasterror is no more than a sign of inaccurate coding, when some %Status values are not processed.

Eduard, thank you for a very good webinar.

You mentioned that IAM can be helpful even if there is "service-mix": some services are IRIS based, others - not. How can IAM help with non-IRIS services? Can any Target Object be non-IRIS base?

Thank you, Udo!

Just 2c to add.

Quotes are not needed in the following lines, due to the syntax of iris start/stop commands. They should look like:

ExecStart=<iris-inst-dir>/bin/iris start <instance>
ExecStop=<iris-inst-dir>/bin/iris stop <instance> quietly

After changing the iris.service file one should perform:

# systemctl daemon-reload

Sergey, it's great that you are writing articles for newbies, nevertheless you don't explicitly mark it. Just a quick note on your samples: ZWRITE command never returns <UNDEFINED> in IRIS, so to check the global existence one should use something like

 if '$data(^A) { write "Global ^A is UNDEFINED",! }

I'm sure that you are aware of it; just thinking of novices that should not be confused.

Stephen, agree with you, those %% can be nasty, while it's possible to avoid them in this very case:

..\bin\cache -s. -U"%SYS" <Routine/ClassMethod call>

making the command syntax very similar to Linux one. In most other cases %% are inevitable; take a look at a small brief from real CMD script: 

 call :CheckNameSpace %%%%SYS
 if %sc% equ 0 goto :help
 ...
:CheckNameSpace
 set sc=1
 If "%1" == "" goto :NameSpaceNotSet
 ...

You may want to use some kind of print spooling to avoid the situations of monopolization such a device as printer. Take a look at CUPS; there is a brief notes how to use lp or lpr commands in Caché/IRIS: Using Pipes to Communicate with Processes.

On Windows we just used OS printer name for opening the device in Caché, and it was enough to spool the jobs to printer queue; no other tricks were needed.

To get more reliable figures on performance, we usually take the following approach (# 1):

 set nTop=1000000 // number of test repetitions
 for each test_j {
   init_counters
   for i=1:1:nTop {
      run_test_j
   }
   save_counters_for_test_j(nTop)
 }

because it introduces less extra payload and provides more precise measuring than alternative approach (#2):

 set nTop=1000000
 for i=1:1:nTop {
  for each test_j {
    init_counters
    run_test_j
    save_counters_for_test_j
  }
 }
 for each test_j {
   aggregate_counters_for_test_j(nTop)
 }

Jeffrey,

I'd try to define namespace global mapping, something like this:

[Map.YOURNSP]
...
Global_Ens*=YOURNSPDB,,YOURNSP-LOCKS
...

where

YOURNSP - your namespace
YOURNSPDB - database where ^Ens* globals are stored (mirrored one)
YOURNSP-LOCKS - database ^Ens* globals locks will be associated with (local one, RO or RW, it doesn't matter).

The similar definitions should exist for each global groups that can be locked.

Disclaimer: I didn't try this trick myself with mirrored DBs. It might help to bypass the locking problem, while not guarantee against other suprises one can face with running something on Mirror Backup member. Consulting with WRC might be of use...