The user needs to have a separate local or domain Windows account to SSH in to the server prior to logging in to Caché

Any SSH server you might try (OpenSSH, etc) would act this way: to start command shell, you need to log in Windows.

It all sounds like a software provider in maintenance for its customers.

In such a case it is usually easier to map that global from the separated database and distribute its updated copy among the customers.

 "mirroring is unavailable for the current license" 

It seems that they have a single server license, so ECP is probably not an option as well.
Otherwise, it's difficult to imagine the scenario when ECP remote (single!) database would not be better than duplicating the data in two databases. Just two cases come to mind:

• slow internet connection
• need to dedicate a whole server for some heavy data processing.

Anna, if you tell us more about your task, we'd likely advise you better.

This quick solution, alas, will not survive the upgrade to IRIS as %Library.RemoteResultSet class was excluded from IRIS.

Julius, I enjoy your $tr solution.

As to $zdth, you've just missed dformat argument, so it should be:

set tmp=$e(datetime,1,8)_" "_$e(datetime,9,10)_":"_$e(datetime,11,12)_":00" write $zdt($zdth(tmp,8,3),8,3)

<ILLEGAL VALUE> occurs otherwise.

It is more likely 2020-10-01 10:00.

Nick,
May I ask you: where did this magic number (201772B865) come from?

Whenever I return "useful" value from a method I regret it afterward. E.g.

set square=##class(mathCls).squareTriangle(a, b, c)

What if something went wrong, e.g. actual parameters (a, b, c) are invalid? I need some sign of it, so I'm forced to add some kind of status code. Let it be of %Status type. So, the caller's code is getting more complex:

set square=##class(mathCls).squareTriangle(a, b, c, .sc) if $$$ISERR(sc) $$$ThrowStatus(sc)

In contrast, when the status code is returned, it is not getting significantly complex:

$$$TOE(sc,##class(mathCls).squareTriangle(a, b, c, .square))

Besides, if each method returns status (even when it is always $$$OK), the whole code is looking more consistent and does not need modification if some of its methods get new behavior and able to return some error status as well. 

Doing finalization like this you are rejecting your previous point to use $$$qoe(...).