My point was if the compiler will go as far as protecting the developer from this type of quit misshap

It seems that this kind of checkup would be difficult to implement because of variety of methods how the code could be branched depending on its call type. E.g. 

 if $quit {
     ...
     quit rc
 } else {
     ...
     quit
 }

or 

 quit:$quit rc
 ...
 ...
 quit

Of course, both code fragments demonstrate not very good coding style, but they are semantically correct. If one gets many false positives from a (hypothetical) code checker, he would likely drop it.

... studio will complain when you try and quit a for loop with a value

QUIT from inside a loop is considered quitting a loop rather then a function, so it should always be without a value.

...but it wont complain when you try and quit with nothing on the method

According to language definition, each function can be called as a function (set x=$$function(...)) or as a routine (do function(...)). The call type can be recognized inside the function using a construct:

   quit:$quit ReturnValue quit  ; $quit=1 if called as a $$function()

Methods are compiled to functions and behave the same way.

 support staff can't access the System Management Portal

Your support staff may want to keep one open session with SMP for troubleshooting. 

if you need to start an ECP data server in a mode that prevents application servers from connecting to it

For such cases we implemented a facility which stops all users' sessions and disables new logons ECP-wide (on application level). Our aim was to prevent extra Caché restarts on data servers by any price, as each restart means loosing the global cache and slowing down of many app functions for ~1 hour or even longer.

Without this facility maybe I'd choose to temporarily stop %Service_ECP.

Thanks, Dmitry and Luca.

Meanwhile I read some docs and interviewed colleagues who had more experience with Docker than me (while w/o Caché inside). What I've got out of it: Docker doesn't fit well to this very case of mine, which is mostly associated with deployment of already developed app rather than with new development. The reasons are:

- Only one containerized app at the client's server (our case) doesn't mean so many benefits as if it would be several ones;

- Windows issues which Luca already mentioned;

- I completely agree that "data should reside on a host volume..." with only one remark: most likely that all this stuff will be maintained at the client's site by not very well skilled IT personal. It seems that in case of Doker/host volume/etc its configuring will be more complex than rolling up Cache for Windows installation with all possible settings prepared by %Installer based class.

AFAIK, docker encourages to implement microservices. What about classic Cache based app deployment, can docker be useful in this case? By classic I mean the system accessible via several services (ActiveX, TCP sockets, SOAP and REST), multi-tasking, etc with initial 1-2 GB database inside. At the moment I'm to choose a solution to roll up several dozen of rather small systems of such kind. Should I look at docker technology in this very case?

I am bound to ver. 2015.1.4. Host OS most likely will be Windows 2008/2012, while I'd prefer to deploy our system on Linux, that's why I am searching a light solution how to virtualize or containerize it. Thank you!

Mark, may I ask your for some clarification? You wrote:

As a result THP are not used for shared memory, and are only used for each individual process. 

What's a problem here? Shared memory can use "normal" huge pages, meanwhile individual processes - THP. The memory layout on our developers' serber shows that it's possible.

# uname -a

Linux ubtst 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

# cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

# tail -11 /proc/meminfo
AnonHugePages:    131072 kB
CmaTotal:              0 kB
CmaFree:               0 kB
HugePages_Total:    1890
HugePages_Free:     1546
HugePages_Rsvd:      898
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:      243808 kB
DirectMap2M:    19580928 kB
DirectMap1G:    49283072 kB

# ccontrol list

Configuration 'CACHE1'
        directory: /opt/cache1
        versionid: 2015.1.4.803.0.16768
        ...
# cat /opt/cache1/mgr/cconsole.log | grep Allocated
...
01/27/17-16:41:57:276 (1425) 0 Allocated 1242MB shared memory using Huge Pages: 1024MB global buffers, 64MB routine buffers

# grep -e AnonHugePages  /proc/*/smaps | awk  '{ if($2>4) print $0} ' |  awk -F "/"  '{print $0; system("ps -fp " $3)} '
...
/proc/165553/smaps:AnonHugePages:      2048 kB
UID         PID   PPID  C STIME TTY          TIME CMD
cacheusr 165553   1524  0 фев07 ?     00:00:00 cache -s/opt/cache1/mgr -cj -p18 SuperServer^%SYS.SERVER
...

You can get an output from a Caché routine provided it do some output to its principal device (= stdout), e.g. (approach #1):

$ csession CACHE "##class(%SYSTEM.License).CKEY()"

Cache Key display:
Based on the active key file '/vol/cachesys/mgr/cache.key'

     LicenseCapacity =   Cache 2017.1 Enterpriser - Concurrent Users:1000000, Anything You Need
     CustomerName =      ZAO XX.XXX
     OrderNumber =       9876543210
     ExpirationDate =    10/15/2114
     AuthorizationKey =  3141592653592718281828662607004081
     MachineID =

     currently available =    9997
     minimum   available =      97
     maximum   available = 1000000
$

as there is no way to pass an arbitrary text from COS routine to OS directly. To bypass it, just incorporate into your shell script a calling sequence like this (approach #2):

#!/bin/bash
csession CACHE <<EOF >output.txt 
write ##class(%SYS.System).InstanceGUID()
halt
EOF

After calling it, you will get output.txt like this:

Node: tdb01.xxxxx.com, Instance: CACHE

USER>
8BCD407E-EE5E-11E4-B9C2-2EAEB3D6024F
USER>

(Missing 'halt' command causes an error). All you have to do is to parse an output. To avoid this, you may want to write a small wrapper in COS that will provide an output as you need it, than you'll be able to follow an approach #1.

HTH.

Thank you, Timur and other CPM contributors, you are doing the great job.

Freedom and independence are 2 greatest values which you can not buy for money. And you should keep it as long as possible.

This great slogan should be set in stone and cast in steel! Meanwhile, your (potential) target audience could be wider prefer you building FOSS product keeping proprietary COS/Caché features usage minimized and localized as much as possible.

While we at SP.ARM would hardly drop our home-brewed PM as it is pretty well integrated with our flagship product (qMS), personally I appreciate emerging of CPM and wonder why it is not CMPM?