Evgeny,
Is it a question: try/catch (or another way of error handling) or %Status? If we try to follow some solid design principles, each method should perform only one function, have only one way to exit from, and should inform the caller whether it succeded. So, we should use both. Extending your sample: 

ClassMethod solid1(parameter, ...) as %Status
{
  set sc=$$$OK
  try {
     $$$TOE(sc,##class(x.y).a())
     $$$TOE(sc,##class(x.y).b())
     ...
     $$$TOE(sc,obj.NormalMethod(parameter))
     ...
  } catch e {
     // error handling
     set sc=e.AsStatus()
  }
  // finally... common finalization for both (good or bad) cases
  return sc
}

One could write it in another fashion, e.g.

ClassMethod solid2(parameter, ...) as %Status
{
  set sc=$$$OK
  new $estack,$etrap
  set $etrap="if $estack=0 goto errProc"
  set sc=##class(x.y).a()) if 'sc goto solid2Q
  set sc=##class(x.y).b()) if 'sc goto solid2Q
  ...
  set sc=obj.NormalMethod(parameter) if 'sc goto solid2Q
  ...
solid2Q
  // finally... common finalization for both (good or bad) cases
  return sc

errProc // common error handler
  // error handling
  set sc=$$$ERROR(5001,"solid2 failed: "_$ze)
  goto solid2Q
}

Which version is better? If we don't need individual error handling of ##class(x.y).a(), ##class(x.y).b(), etc calls, I'd prefer solid1. Otherwise, solid2 seems to be more flexible: it's easy to add some extra processing of each call return. To achieve the same flexibility in solid1, we are to cover each call in an individual try-catch pair, making the coding style too heavy.

Daniel,
Not talking about whether $zerror/$ztrap is good or bad, false positives and negatives can be avoided if use it right way. The well-known pattern is as follows:

rouA
  set $ze="",$zt="rouAerr"
  ...
  set sc=$$funB() if 'sc quit sc
  ...
  quit sc
rouAerr
  set $zt="" ; that's of great importance!
  set sc=$$$ERROR(5002,$ze) ; just a sample of processing $ze...
  quit sc

funB()
  set $ze="",$zt="funBerr" ; while not neccessary, local $ztrap can be defined
  ...
  quit sc
funBerr
  set $zt=""
  set sc=$$$ERROR(5002,$ze)
  quit sc

I am not putting my hopes on GBLOCKCOPY  due to its limitations

This precaution sounds strange in your context: if you are simply copying a set of globals that are actively being modified, you will get an unpredictable result nevertheless the utility you choose. To make a consistent copy, one should apply journal records or (if copying to another Cache instance) use some cross-system technique, such as Mirroring or Shadowing, while both require Multi-Server cache.key.

If you tell us more about the task you are trying to solve, we'd advise you better.

Public recognition by developer level

Other vendors from your list have some kind of developer certification as well. E.g., https://docs.microsoft.com/en-us/learn/certifications/
Or you meant something else, didn't you?

Yes, it's possible. You can use %SYS.Task for a Task API. Its methods and properties are well documented in its superclass %SYS.TaskSuper.

Yone,

if you really moving the files every day, you don't need to check the date: there are no old files in your in-folders, because they have been deleted with mv  (move) command. Most pieces of software which does the similar tasks (e-mail clients and servers, SMS processors, etc) do it this way, moving files rather than just copying them. The simpler the better, isn't it? 

Eduard,

If you are still interested: Application licensing doesn't support distributed license accounting; it was the stopper for us as our largest customer is running Cache based application (SP.ARM's HIS qMS) in distributed environment.
 

Hi James,

A colleague of mine developed JDBC based solution in question which works with Oracle, mySQL and Caché a while ago.
It's based on the following classes:

   %Net.Remote.Java.JavaGateway
   %Net.Remote.Java.JDBCGateway (This class is used internally by Caché. You should not make direct use of it within your applications.)

Despite the last remark, InterSystems follows the similar approach in its Ensemble / IRIS outbound adapters.
Our solution is compatible with actual versions of Caché and IRIS. Regretfully, it's too bound to our app, so I'm not sure whether it is the best source of sample code at the moment.
 

Another possible approach:

• copy global stream to file
• process it using external OS call; in Linux we use its native zip/unzip utilities, in Windows - console version of popular free 7-zip tool. 

Just adding 2c to Kevin's reply.

Most hosts that support TCP also support TCP Keepalive  

Besides, server application should support it. 3 hours keepalivetime setting is not typical; it sounds like your server app not tuned for keepalive support or doesn't support it at all.

In case of IRIS/Caché, you should explicitly set some options on connected server socket, e.g.:

start(port)// start port listener  s io="|TCP|"_porto io:(:port:"APSTE"):20 e  quit  while 1 {   u io r x   u $p// connection is accepted: fork child process   j child:(:5:io:io)  }
 
child  use $p:(:/KEEPALIVE=60:/POLLDISCON)
  ...

/KEEPALIVE=60 to set keepalivetime to 60 seconds
/POLLDISCON to switch on TCP probes.

Stuart,

Unless you publish the failing code fragment, it would be difficult to help you.

Congrats!

Can we expect publishing your code aimed "...to simulate NYSE data processing (Order/Fill)..." as an Open Exchange App?