%OnNew() must return a %Status to %New(). But the code that calls %New() also needs the %Status. I think a "best practice" is simply to add an Output  %Status argument to %OnNew() that will therefore be returned to %New(). So the %Status is being returned using return (for %New()) and by using a pass-by-reference argument (for the code that calls %New()).

/// constructor
Method %OnNew(name As %String = "", phone As %String = "", dob as %Date, Output st As %Status) As %Status [Private]
{
    set st = $$$OK
    set ..Name = name
    set ..Phone = phone
    set ..DOB = dob
    set st = ..%ValidateObject() // validate the new object
    return st
}

Since transactions can be nested, and TROLLBACK rolls back all transactions, it's best practice to pair each TSTART with TROLLBACK 1, which will rollback only the currenct transaction.

In the example for READ UNCOMMITTED, after the second (right-hand) Terminal session sets ^t(1)=2, when the first (left-hand) Terminal session writes ^t(1), the example shows/states that a "3" appears, but that's wrong; it should be a "2".

I started as an M guy, abbreviating everything, for many years. Once extra spaces were allowed in ObjectScript, I re-trained myself to use extra spaces and fully spelled out commands and $functions. When I'm writing code for myself in the Terminal, I don't always spell everything out. But any code I write that others will see, I spell everything out.

Some folks in this thread talk about abbreviating some commands but not others, or some $functions and not others. Imagine code at one company written by 10 programmers, all of whom choose their own way of abbreviating or not abbreviating. A new programmer joining the company will see a mess. Then imagine trying to come up with an agreed upon set of standards at the company ("you can abbreviate these commands but not those, and you can abbreviate these functions but not those") so that the code appears (at least) consistent. A new programmer joining the company will still see a messy standards document that they'll have to keep checking until they have it memorized.

Compare that to: "spell everything out, spaces around all operators, a space after every comma" (what I do) or something similar. I think the end result justifies the extra typing.

Why are you using NoExtent here?

James, for this one, there is no easy answer. But first, here are some corrections FYI:

• Since what you're passing in to execute contains quotes ("SYSTEM"), surround that with single quotes instead of double quotes
• Since the Security.System class is in %SYS, specify the namespace in your command.

So it's this:

csession TEST -U %SYS '##class(Security.System).AutheEnabledGetStored("SYSTEM")'

But the problem is that this expression doesn't output its value, and you can't include "write" at the beginning. You should probably describe exactly what you're trying to do in more detail, and someone here will make a suggestion.

Also note:

• InterSystems IRIS v2019.1 also provides direct access to globals, using a feature called the Native API for .Net. Check the doc for it here. 
• The Native API for .Net can connect to InterSystems IRIS on the same machine or another machine. On the same machine, the connection speed between .Net and InterSystems IRIS is even faster than with Caché, through the use of a shared memory connection. Read more about it here.

Great post! I have a followup question: How did you load the Finam data? Was it "over the wire" all at once? Or were you reading from one or more csv files?

It sounds like you want to do pattern matching, but for some reason you don't want to use ObjectScript pattern match syntax for your mask. So you've decided that you want to use * for "any number of any character" and ? for "a single character" which are pretty common.

Remember that ObjectScript also has the $match Regex function. So your match() method could use that syntax for the search mask and you wouldn't have to write any code to change * into .E and ? into 1E and you'd get the benefit of additional options offered by $match.

This is not quite an answer to your question. Just some clarifications:

• Your example is a %Query class query, where you write ObjectScript code for the query rather than using SQL. I haven't written one of those for a while. I'm assuming that ROWSPEC and CONTAINID are required for these types of class queries, but I'm not 100% sure.
• A "newer" way to write a custom ObjectScript-based class query, using the class %SQL.CustomResultSet, doesn't require ROWSPEC either. Sample.CustomResultSet is an example of this technique.
• For a %SQLQuery class query, written using SQL, ROWSPEC and CONTAINID have not been required for a loooong time. They are dynamically created from the query itself.

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.

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.

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