Robert,
you are absolutely correct in your guess: I've just called it from terminal :)
Another option is to put agg into the PublicList of the caller method. I still like it more than passing by reference as it looks clearer.

P.S. Correct caller was added to my sample code. THX Robert.

Just a small fix that makes the PublicList unnecessary:

ClassMethod Flatten(reference, Output flat)
{
    For {
        Set reference = $query(@reference)
        Quit:reference=""
        Set value = $listbuild(@reference)
        For i=1:1:$qlength(reference) {
            Set value = value_$listbuild($qsubscript(reference,i))
        }
        Set flat($i(flat)) = value
    }
}

The fixed method should be called in a slightly different way:

Method SomeMethod(...) [ PublicList = agg ]
{
  ...
  Do ..Flatten($name(agg),.summary)
  ...
}

Just adding 2c:

• mapping your class to pseudo_namespace %ALL makes it available to all other namespaces except %SYS

...it would be available to all namespaces including %SYS.

Now I've got an idea... It was not our case as it was a new instance of IRIS to create. We were just choosing the simplest way of passing databases and some other stuff (localization, Task Manager's tasks, etc) from Caché to IRIS. Installation of an old version of OS just for Caché's sake seems to be overkill, doesn't it?

@Robert Cemper

Agree with you, "in-place conversion" is not of great aid in real cases. Its pathos name sounds a bit confusing, isn't it?

During my first tries to transfer our Caché APP to IRIS I took an approach similar to yours, although I preferred not to use ECP as it was possible to avoid running both instances concurrently.

The funny thing I noticed: if one creates a database in Caché, renames it to IRIS.DAT, stops Caché, and starts IRIS, it will be mountable, but the reverse is wrong: renaming IRIS.DAT has been created in IRIS to CACHE.DAT doesn't make it compatible with Caché.

This is a first version with Frozen Plans

The first, but not the last one, so still not getting the idea of having this intermediate upgrade point.

...Cache/IRIS never runs on unsupported OS. Do you have a case with WRC on this topic?

Sorry, on which topic? Everyone knows that Cache/IRIS never runs on an unsupported OS.

upgrade to 2016.2

What is the reason of this step? If OP's Cache version allows direct upgrade to 2018.1, it can be easily omitted.

OS Compatibility can be a stop factor for in-place conversion. E.g., preparing IRIS instance for a prospect, we faced a small problem with it: Cache 2017.2 (our App's supported version) turned to be incompatible with Ubuntu 18, which was chosen as on OS for IRIS.

This limit of 256 characters is a known problem with command pipes in Cache, and it seems that yet in IRIS. Agree with Dmitriy: $zf(-100) would be OK.

Hi Yuri,
Your feature table is great. Just a quick note: AWS Hosting, like any other kind of hosting, is mostly a hosting feature rather than ODBMS one.

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.