There is also ^$LOCK, which is a "structured system variable." It's been in the language for a long time. So instead of setting tMyGlobalLocked and checking it, the code could use ^$LOCK like this:

    // Cleanup: locks
    If $data(^$LOCK("^MyGlobal(42)") {
         Lock -^MyGlobal(42)
    }  

This is a very good article. I have 2 comments:

1. Why do you need the while loop and tInitLevel at all? I think that code that uses transactions must balance each tstart with either a tcommit or trollback 1. So the difference between $tlevel and tInitTLevel should always be 1. And no code should ever use trollback without the 1. Your code should roll back your transaction and no one else's.
2. When tstart/tcommit was first added to the language, best practice was placing the tstart and tcommitat the beginning of the code that is about to change globals, keeping it isolated as much as possible from anything else. I’d suggest moving the tstarts in your examples lower in the code block, right before the “do the important stuff” code.

Would you please try adding ReturnResultSets to your original method and let us know? This works for me.

ClassMethod Get(pId As %String) As %String [ SqlName = GetMsg, SqlProc,  ReturnResultSets]

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