This seems to have been addressed in Atelier 1.2. Using build 118 from the beta repo I get the following when testing a connection to a server installed with Minimal security (which somewhat surprisingly is still an option when installing IRIS 2018.1.1)

To resolve this I must enable another authentication method (e.g. Password) on the /api/atelier web app:

Probably a good idea to deselect Unauthenticated. Even though Atelier doesn't seem to allow anonymous connection to /api/atelier REST service I guess it'd be possible to do this directly.

Where are you running the GBLOCKCOPY? If on your 2014 environment I think you'll be having the same problem as when you just tried to mount the database there. GBLOCKCOPY needs to mount it before it can copy block from it to your new database.

Most likely, your original database has 2KB blocks. Your problem then is, 2014 can't mount any databases with 2KB blocks. The last version supporting 2KB block databases was 2011.1. See here.

The TROLLBACK command doesn't automatically release LOCKs that were acquired within the transaction. The TROLLBACK documentation is a bit confusing in this regard. At one point it says this:

Then later on the same page this text seems to say that both TROLLBACK and TCOMMIT do release locks.

Jordi, in your example:

TSTART

Do ##class(MyTable).%OpenId(<TableID>, 4) (This internally is creating a Lock +^User.MyTable(<TableID>)

TROLLBACK (This action removes the previous lock)

I don't think it's the TROLLBACK that's releasing the lock, but rather the destruction of the oref that the %OpenId method created. Indeed, if tested exactly as you wrote it that oref doesn't even get stored in a local variable, so ceases to exist as soon as the method call completes.

The old Google group isn't owned or managed by InterSystems, and previous attempts to get whoever does manage it to do anything to tackle the potential confusion etc have been unsuccessful. There are several other  posts here on DC about this. For example:

https://community.intersystems.com/post/automatic-crossposting-developer-community-google-group-user-intersystemsdc

For others, search DC for the term "Google".

That's the doc for the %SYS.Task package. One row above it in the Documatic explorer panel you'll find the link to the %SYS.Task class. Here's a link to the online copy for 2017.1

http://docs.intersystems.com/cache20171/csp/documatic/%25CSP.Documatic.cls?PAGE=CLASS&LIBRARY=%25SYS&CLASSNAME=%25SYS.Task

I'm seeing ExportTasks and ImportTasks methods, both inherited from %SYS.TaskSuper

I disagree with your assertion that you can't call at a tag in a way that you can call from the top:

USER>zp
YJM      w !,"Runs in ",$namespace,! q
         ;
SUB      ; A subroutine tag
         w !,"SUB^YJM runs in ",$namespace,!
         q
 
 
USER>zn "samples"
 
SAMPLES>d SUB^|"USER"|YJM
 
SUB^YJM runs in SAMPLES
 
SAMPLES>

I find it confusing that you talk about calling a routine in a namespace. As I see it you're fetching it from another namespace (i.e. the one the routine lives it), but you're running it in your current namespace.

You also need to be aware of what happens if the code you fetch from the other namespace makes its own calls to other code. Here's an illustration:

USER>zp
YJM      w !,"Runs in ",$namespace,! q
         ;
SUB      ; A subroutine tag
         w !,"SUB^YJM runs in ",$namespace,!
         q
         ;
Test1    ;
         w !,"About to call local line label YJM",!
         d YJM
         q
         ;
Test2    ;
         w !,"About to call a line label in a specific routine",!
         d SUB^YJM
         q
 
USER>d Test1^YJM
 
About to call local line label YJM
 
Runs in USER
 
USER>d Test2^YJM
 
About to call a line label in a specific routine
 
SUB^YJM runs in USER
 
USER>zn "SAMPLES"
 
SAMPLES>d Test1^|"USER"|YJM
 
About to call local line label YJM
 
Runs in SAMPLES
 
SAMPLES>d Test2^|"USER"|YJM
 
About to call a line label in a specific routine
 
 d SUB^YJM
 ^
<NOROUTINE>Test2+2^YJM *YJM
SAMPLES 2d0>
 
SAMPLES 2d0>q
 
SAMPLES>