90 and 100 lines for serializers is quite the achievement.

At the moment I have a serializer (<glvn> to json string) and a deserializer (json string to <glvn>) of 40-60 lines of pure M COS code. Should run on any Caché version, was tested on 2012.2 and higher. Some proof that they really exist:

USER>d $system.CPU.Dump()
 
-- CPU Info for node maslov --------------------------------------------------
          Architecture: x86
                 Model: Intel(R) Core(TM) i5-4460  CPU @ 3.20GHz
< ... >
USER>d j2gSmall^zmawr

JSON2G^Wmgr Cache for Windows (x86-64) 2017.1
total time = 1.05795 avg time = .0000105795

G2JSON^Wmgr Cache for Windows (x86-64) 2017.1
total time = 1.898275 avg time = .00001898275

sJson <=> arr()? yes ; the result of conversion reversibility check

USER>zw sJson
sJson="{""BirthDate"":""1970-03-25"",""FirstName"":""Sean"",""Hobbies"":[""Photography"",""Walking"",""Football""],""LastName"":""Connelly""}"
 
USER>zw arr
arr("BirthDate")="1970-03-25"
arr("FirstName")="Sean"
arr("Hobbies",0)="Photography"
arr("Hobbies",1)="Walking"
arr("Hobbies",2)="Football"
arr("LastName")="Connelly"

This code is not my own development (while I contributed a bit), so if anybody wants it to be published I should redirect this request to main contributor(s).

BTW: Sean, was this JSON string

TestRawJson = "{""TestAllAsciiChars"":"" !\""#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]"_$c(142,143,144,145,146,147,148,149,150,151,152,153,154,157,158,159)_"...

 from your sample wrong escaped deliberately?

I don't understand the difference between this two kinds of voting :) Which solution is the best, depends on many factors: if we need turbo performance, we'd take your approach, if not - %ResultSet based one. BTW, I guess that file dirs scanning is a small part of a bigger task and those files are processed after they have been searched and the processing takes much longer than the directory search.

Last 2c for cross-platform approach: the main place where COS developer faces problems is interfacing with 3d party software. As I was told by one German colleague, "Cache is great for seamless integration".

E.g., I've recently found that forcely resetting of LD_LIBRARY_PATH by Cache for Linux may cause problems for some utilities on some Linux versions. It's better to stop here, maybe I'll write about it separately.

I'm voting for Rubens's solution as it is OS independent. Caché as a great sandbox in many cases, why not use its "middleware" capabilities? Developer's time costs much more than CPU cycles, and every piece of OS dependent code should be written and debugged separately for each OS that should be supported.

As to performance, in this very case I doubt if the recursion costs much compared to system calls. Anyway, it's not a great problem to replace it with the iteration.

If one simply gets an older storage def from VCS, how Cache internal migration facility can help? The history of schema changes will be lost. It seems that only some ad hoc global level migration code can help in this case.

So this kind of "forced" schema migration (having some populated data which you don'want to loose) would usually be a pain.

And what will happen, if one decides to revert his class def to a previous version with previous storage def state, having some data already populated using new schema?

It seems that there is no "good" choice between TS's two options, only some "bad" vs "worse", unless business logic is accurately separated from data and kept in different classes. In this case the probability of reverting data class def should be lower.

Do you think that strange name is from MultiValue stuff?
If so, not sure if it's possible to define macros in MultiValue .

Looking at the console log I can see the following which I presume implies it is using large pages?

Definetely yes.

Graham, if you feel that your question is answered please don't hesitate to mark it answered 

Question may have more than one right answer.
Several answers may add some useful info to each other.
Complicated question may even collect several competiting answers. Who will be a judge?

If you are curious, you may try to do it following John's hint, but if you didn't catch the idea, better do not.

-

Raghuram,

I wrote my answer before reading yoyr comment. In this very case it seems that it's nothing should be done with GUID.

Happy testing!

While it's easy to change GUID following John's hint (if you understood the code, you already know which global node to kill, and it will be recreated on the next call), I wonder why do you want it? It seems that your instanse have migrated to another host, hense you may want to save all its requisites (including GUID) untouched. This GUID is not used by Cache itself, but may be used in some app data fields, so you may loose app level integrity.

PS. If you didn't understand the code, or are cautious to change system globals, you'd better deinstall Cache and re-install it into the same folder. System DBs would be totally rewritten while your app DBs as well as cache.cpf would be left as is.

Neither MERGE nor ^GBLOCKCOPY move the global: they are only copy it, unless somebody KILL it's old instance after copying.

John, it seems that inquiring folks rarely accept answers, maybe because of their rare visits to this site.

With voting feature (like some sites have) it would be possible to "auto-accept" the most voted answer(s) after some reasonable time, e.g. after two weeks.

Hi, Richard.

...to have cache run as a different user to access that macro...

Running Caché for Windows using a dedicated user account (so called service account) may have some other advantages:

• Caché processes get ability to use MS network resources (shared folders), e.g. Caché Backup can be performed directly to remote folder; 
• Kerberos authentication can be used.

So long story short just going down the libre office route.

Why do you expect that libre office route would be shorter? Do you plan to use another (not $zf(-1,...)) approach?