AFAIK only the owner of the class (set using the Owner keyword on the class, defaulting to _SYSTEM) has automatic rights to invoke all of the SQL stored procedures that the class implements (as classmethods with the SqlProc keyword). Anyone else who needs to be able to invoke them will need the right granting to them, either directly or via a role.

That's interesting to know. It means that my experiment can become:

USER>s oResult=##class(%Library.File).FileSetFunc("c:\s\","*.txt")
 
USER>while oResult.%Next() {w !,oResult.%Get("Name")}

...

And now static code analysis that detects classmethod references can spot the use of the secret FileSetFunc method within the class that implements the query I'm using.

One caveat about transferring globals between namespaces / instances using XML format is that by default when you load the XML into the target namespace the global(s) in your XML file will be pre-killed. In other words, it's a "replace" operation rather than a "merge" one. This may be exactly what you want in many situations, but if you've been used to using other utilities to export and import globals then it's different.

To override this behaviour, add the "/mergeglobal=1" qualifier during your import, for example as the second argument (qspec) to $system.OBJ.Load(), which is of course the Load classmethod of %SYSTEM.OBJ.

See more qualifier documentation here.