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!

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?

Sagun, this code would fail with <WRITE> error as after opening the file for reading:

 ..o resfile:"RSK\CP874\"

it tries to write into it:

 ...w $g(^ztonEDI("TXT","OUT-DATA",ind,fileno,"SEQ",seq))_$c(13),$c(10)

What this code needs as the first remedy is a change of the Open command to:

..o resfile:"NWK\CP874\"

It's better to use stream wrappers instead of open/use directly

Just because of higher abstraction level of streams; nothing special inside: just the same Open/Use/etc COS commands. So, choosing one or another way of working with files can't be the source of errors itself.

By the way, `open file:("NWK\table\")` is a proven and documented way of translation table setting. AFAIK, its only limitation is that it works with Open command only rather than with Use command.

Eduard, can you explain the main difference between Sagun's method of translation table setting:

 open file:"RSK\CP874\"

and yours in this very case? The latter is a piece of code of  %Stream.FileCharacter.cls which actually sets a table:

 If (table'=0) && (i%CurrFile'="") {
   Set io=$io
   Use i%CurrFile
   $$$SETIO(table) ; -> Do $zutil(96,18,2,table)
   Use io
 }

It seems that it's some other problem, perhaps a bug.

Sagun, if you provide us with a small piece of your code where you open the file, use it, and write it, it would be easier to say something.

Looks like, do you use integration in Studio?

Yes, I do.

...maybe it working so long, and you did not wait for the result. 

Not too long, just a few seconds. It provided an empty report, and AFAIR there was some record in its internal log that no problems were found.

I've tried it with Cache 2017.1.0. The first impressions are:
- It completely ignored all "blockers" in the class with 300+ methods, while there was a many of them it should not pass by: 'not procedureblock', legacy flow control, etc; maybe some internal limit was exceeded.

- On the smaller class it popped rather funny messages, e.g. 

  1 blocker
        1 Method declared as "ProcedureBlock = 0"
User.test.cls(+6): ClassMethod RestVars(zzzzzzsource As %String, bOref As %Boolean) As %Status [ ProcedureBlock = 0 ]
  2 major
       2 Usage of QUIT to exit a method
User.test.cls(+24): quit $$$OK
User.test.cls(+28): quit $$$ERROR($$$CacheError, $ze)

Well, 'ProcedureBlock = 0' can be considered not a good style, but what if I need it in some special case? This very method restores local variables stored in a global, so it would loose all its sense be it 'procedureblock'. IMHO, there should be a facility to protect such special case methods.

'Usage of QUIT to exit a method': QUIT is standardized command to exit methods/routines/etc. IMHO it's better than RETURN as it prevents coders to exit their methods from inside the loops and try/catches constructs, so it encourages the modular coding: each module (method) should have one enter and one exit.

So, many of such rules seem to be subjective. Without a facility to customize the rules this linter seems to be no more than a demo of some commercial product.

P.S. As I noticed later, it never clears 'mgr/Temp/' sub-folders it creates.

I just wanted to add that some occurrences of `quit:$quit value  quit` idiom was probably inherited from legacy coding practices, as Caché allows calling methods/functions using DO command (thus ignoring the value being returned).

From the other hand, using of `quit:$quit ""  quit` construct looks like an attempt to amend erroneous $$ calls of methods/routines, which did not return any value by their initial design. One might say that such design was initially wrong, as any method should return something, at least %Status which is always $$$OK.

It may depend on local coding traditions. Just for example, quick search using Studio's <Ctrl-F> through one of our apps (comprised 1000+ classes) showed: 

 q:$q <lvn> q            ; Found 4501 occurrence/s in 90 file/s
 quit:$quit <lvn> quit   ; Found 126 occurrence/s in 28 file/s.
 if $quit                ; Not found.

So, it turned that about 10% of our classes used $QUIT. Not too many, but not negligible few.