Hi Mark,

Several years ago we faced the similar problem. External system needed to pull new requests from our Caché DB and to push back the responses. We maintained a transition table in Caché where we placed new requests, external system polled the table each N seconds fetching the requests from the table and placing the responses back. Communication was implemented via ODBC.

You can do something like this filling transition table on remote Caché side using triggers associated with the "main" table.

If you prefer to code global size calculation by yourself rather than amend ^%GSIZE, the feasible option is to call

set bSize=$$AllocatedSize^%GSIZE(global)

which returns size in bytes for a global mapped to the current namespace. It recognizes the database the global is mapped from, so you don't need to do it yourself. The only thing you need is a global list for the namespace, which can be fetched in several ways, e.g. using $Order(^$G(global)). It can be used on per database basis as well. Pros of this approach:
- speed, as it neither runs query nor instantiates %SYS.GlobalQuery objects;
- AFAIR, there was an error in global size calculation with %SYS.GlobalQuery::Size() query in old Caché versions, up to 2015.1;
- starting from 2015.1, it can be used with subglobals.

Cons:
- this $$-function is not documented;
- not sure if it existed in 2010.1.

Agree, it's trivial in most cases, except that one, when there is a series of commands depending on previous ones, e.g. (not from the production code))):

set rc=$zf(-1,"[ -f /etc/environment ] && . /etc/environment && export TZ")

$zf(-1) allows to execute such series at the whole, while $zf(-100) needs to split it into parts, moving checkup logic to COS code. It's trivial as well, but ruins the idea of (semi-)formal substitution of $zf(-1) calls with $zf(-100) ones.

It seems that the docs is ambiguous here as it's not clear when one can use "" as a <null> value: in comma separated options list only, or in options array as well.

As to possible ways to exploit $zf(-1), there is some clue in ISC's announcement. It can be compromised if its arguments come from user input. Similar vulnerabilities are usually associated with dynamic SQL, not only in Caché. Other (Caché specific)  samples: Xecute, $Xecute, argument indirection. This stuff is well-known, is it a secret for anybody?
It seems that if we never use such coding style, we are safe enough. As to our company's code base, we rarely use $zf(-1), and all its usage is encapsulated in a couple of class methods.

We'll follow ISC's security recommendations, as we always do, while I don't feel myself comfortable when I don't understand the reasons of doing something. "Don't repair, if it works", as it was said by some wise man. Does it need any comment?

Using a comma-delimited list of arguments works fine, even with a null arg

Null arg is not the same as an empty string arg (""), as usual in COS. Therefore the settings of

set options(1)=""

made your first argument an empty string, and the whole command behaved as

dir "" e:\nbupg\webserver\

Didn't check your *nix version, just noticed that "NUL" should be spelled as "/dev/null".

P.S. May I ask you in turn :):

Why did you undertake this task, changing of $zf(-1) to $zf(-100), at all? Do you clearly understand the kind of treat you try to eliminate?

As a remedy, you can process compilation in a separated job, something like this:

- Create environment { }

- JOB ImportAndCompileStuff

- Wait for the job completion

- Destroy environment { }

Hi Joan,

It seems that the right way to perform this task would be using MemberStatusList query of the class SYS.Mirror. See Documatic for details.

HTH.