Thank you, John, for this reminder, while I prefer to deliberately enable auditing of all events for the simple reason: a few added-on disk IOPS, as well as 1GB+ of disk space for audit database (even on high loaded Caché instances) do not seem to be a great price for an ability to trace not predicted cases in production.

We even met a prospect's requirement that any audit database write failure should be dealt as a critical error with a notification of admins by all means, even with shutting the Caché down!

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.

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.

My point was if the compiler will go as far as protecting the developer from this type of quit misshap

It seems that this kind of checkup would be difficult to implement because of variety of methods how the code could be branched depending on its call type. E.g. 

 if $quit {
     ...
     quit rc
 } else {
     ...
     quit
 }

or 

 quit:$quit rc
 ...
 ...
 quit

Of course, both code fragments demonstrate not very good coding style, but they are semantically correct. If one gets many false positives from a (hypothetical) code checker, he would likely drop it.

... studio will complain when you try and quit a for loop with a value

QUIT from inside a loop is considered quitting a loop rather then a function, so it should always be without a value.

...but it wont complain when you try and quit with nothing on the method

According to language definition, each function can be called as a function (set x=$$function(...)) or as a routine (do function(...)). The call type can be recognized inside the function using a construct:

   quit:$quit ReturnValue quit  ; $quit=1 if called as a $$function()

Methods are compiled to functions and behave the same way.

Thank you, Ray.

Most production sites wouldn't plan their backups this way because it means that the only operation you can do on the backup image is restore the whole thing and start Caché.

Another reason of doing so can be the number of articles, docs, learning materials which taught us _always_ perform ExternalFreeze accompanied with ExternalThaw on every external snapshot making.

 support staff can't access the System Management Portal

Your support staff may want to keep one open session with SMP for troubleshooting. 

if you need to start an ECP data server in a mode that prevents application servers from connecting to it

For such cases we implemented a facility which stops all users' sessions and disables new logons ECP-wide (on application level). Our aim was to prevent extra Caché restarts on data servers by any price, as each restart means loosing the global cache and slowing down of many app functions for ~1 hour or even longer.

Without this facility maybe I'd choose to temporarily stop %Service_ECP.

Don't you think that naming the file "1.xml.gz" would be more clear?