Michael - thanks for the article.  It would be really helpful if you could add a paragraph at the top explaining what the Ensemble scheduler is and what it's main use-cases are so that people can tell quickly whether or not this is something which they would want to learn more about.  Perhaps as an Intro?

Assuming you are a supported customer, you can download this from the Distributions page in the WRC application.

This is not a Caché utility - it must be supplied by your application partner.  Also, the AP must be storing their own users at the application level because if they were using Caché users there would be no way to create a utility that shows Caché users' passwords (see Patrick's answer below).

I suggest you reach out to your application partner with this question (or if it is an inhouse development, speak with the development team)

Sorry - I missed that.

Getting the "When" is easy - there is a timestamp in the header of the generated .INT code showing when the source was last compiled.  E.g:

 ;Sample.Address.1
 ;(C)InterSystems, generated for class Sample.Address. Do NOT edit. 10/27/2016 09:12:38AM
 ;;7A2F686C;Sample.Address
 ;
However the "Who" might prove to be more challenging. You might be able to accomplish this with a Method Generator that records the $Username and timestamp for access via a method or parameter?  See http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...

Excellent idea to post this John - this isn't necessarily common knowledge but it is really useful to know!

Anyone who doesn't need to support 2016.1 code should just use the new syntax.  This is intended as a 'bridge' solution to allow a code-base to run on both versions, and then after the code no longer needs to run on 2016.1 the macros should be removed when it is convenient.  

I think I better understand now - you want 'other' tabs to dynamically update (without the user hitting Refresh) if the user changed namespaces in a separate tab, is that correct?

I think there are probably Javascript events that fire when a tab comes back into focus (you'd have to check) and you could use those to trigger a call to the server to see if the namespace has changed - if it has then redraw the tab to show the context of the proper namespace.  It would have more moving parts but it should be possible if you really want to do it.

Good luck!

Playing around with it a little bit, I came to the following conclusions:

- *some* pages rely on the $Namespace url parameter in order to initialize what namespace it is pulling data from

- this doesn't appear to be stored in the session (and therefore it isn't shared between tab); I think it is only effective in the url

- there are some pages which don't honor the $Namespace url parameter (e.g. they still show %SYS even if $Namespace is defined to a different value); this is probably because those pages don't act on any namespace-specific data (or they act on data which lives ONLY in %SYS)

It sounds like if you want to keep your tabs in sync, you should put something in the session, and switch namespaces in your page logic.  Probably in OnPreHttp (although you'd need to test to make sure that the namespace sticks for the OnPage method as well)