Hi Timur! Your short answer is funny, and your longer answer makes sense (even though my preferences are different). 

This is nice. The only thing I'm wondering about is why there are #dim statements for regular variables? @Timur.Safin, why did you include the #dim statements? In my opinion, #dim statements for variables that are not object references are misleading:

1. #dim gives developers that are new to ObjectScript the impression that you must declare all variables like in some other languages. Declaring variables like this is not necessary in ObjectScript.
2. #dim's main purpose is to help Atelier/Studio provide code completion for variables that are object references. If you write this code #dim i as %Integer, and then on the next line you type do i. ,  after the period Atelier/Studio will suggest methods from the %Integer class. If you happen to accept one of the suggestions, the resulting code will not compile. This is because our datatype classes (like %String and %Integer) are not object classes.

Yes, Track Variables in Studio is great! But I don't see any value in Option Explicit, which forces #dim, which leads to the issues in my original comment.

Both running VMs and containers allow multiple processes inside. I'm not asking you for a deep dive, but can you explain if the mechanism that allows this is the same or similar between VMs and containers, or if they use completely different mechanisms.

I would do it this way to avoid Else:

Open <some device>:"R":0 If '$test { Write "could not open device" Quit }

Danny and Robert, of course I understand what you are saying (we are the same generation!). Also, I am not trying to be the Developer Community police.

In posts that are asking "what's the recommended way to do this?" we should answer that question. There's no point in mentioning old syntax in that context. Saying "don't do this, but you might see it someday" helps the subset of people that might work with old code, but doesn't help and may confuse the people that are working with new code. It doesn't belong.

On the other hand, if there's a post asking "what are some older/confusing syntaxes I might encounter when working with M or ObjectScript?" we should answer that question. We all have examples of that.

C'mon, let's stop mentioning old features like argumentless Do and legacy ELSE

There's just no point in doing so.

The legacy versions of If and For commands don't use curly braces. But there are no legacy versions of While and Do/While, which require curly braces. So rather than trying to remember which commands use or don't use curly braces, just use curly braces all the time for these, as well as Try/Catch.

Regarding post-conditionals, it's a good habit to put parentheses around the condition, which allows you to put spaces in the condition.

This is valid syntax: set:a=4 y=10

This is valid syntax and more readable: set:(a = 4) y = 10

This is invalid syntax: set:a = 4 y = 10

Slightly improved syntax would be something like this:

if ($zdh(date1,8)<$zdh(value,8)) && ($zdh(value,8)<$zdh(date2,8)) { return 1 } 
else { return 0 }

No. I have a feeling that some versions of M that ran on VMS added the $, and some versions of M that ran on UNIX added the !. So we support both.

And don't forget about using ! or $ to load the interactive sub-shell.

load interactive subshell

It's like using $zf(-1). You can do !pwd or $dir, for example.

One clarification that might help you: the "Ensemble Controller" Service is not an Ensemble process, so the user assigned to that Service doesn't affect what you're asking about. The "Caché/Ensemble Controller" Service is simply something that allows you to start/stop the local Caché or Ensemble. It's just like start/stop on the Launcher (the cube or the E).

Does this work with character streams also?