New post
AllAccepted answers
John Murray · May 12, 2016

Thanks for your explanation Mark.

Interesting to know that the ZZW command was removed, leaving only the full-form ZZWRITE one. Our Command Line Extensions implemented ZZW and ZZWRITE as synonymous. Your ZZWRITE implementation takes precedence over our ZZWRITE but at least our implementation remains accessible via ZZW.

Ideally you guys would establish a policy one way or another, document it, then stick to it going forward, applying the rule consistently to commands, functions and system variables. In the past you've typically added Z* things but not ZZ* things, for example $ZCLASSMETHOD().

John Murray · May 12, 2016

Yes, a useful command but I think it's inconsiderate of InterSystems to be annexing the ZZ* command-space. The facility for sites to extend the language with their own commands by writing a %ZLANGC00 routine (see here) has been useful and we at George James Software have for many years offered a free download called Caché Command Line Extensions. We deliberately made all our commands begin with ZZ in an effort not to clash with future InterSystems extensions, but our ZZW extension was subsequently overridden by the ZZW command InterSystems added in 2013.1. It seems it's only a matter of time before you sequester other commands from us.

John Murray · May 3, 2016

Travis, are you aware of our well-established native Caché/Ensemble/HealthShare source code management and deployment tool? Previously known as VC/m, it's now called Deltanji.

As well as dealing with code versioning Deltanji also handles deployment. It integrates with Atelier, Studio and Portal.

Some members of this Developer Community may be willing to share their experiences of using our tool.

Perhaps you have specific reasons for wanting to go with Git, but it might be worthwhile considering Deltanji as an alternative route.

John Murray
George James Software

John Murray · May 3, 2016

Maybe your code at someLabel^someRoutine in OTHERNAMESPACE calls another routine that exists only in OTHERNAMESPACE. In that case, the <NOROUTINE> error will occur when the call is made. That's because when you d someLabel^|”OTHERNAMESPACE”|someRoutine(inputVar,.resultByReference) you are fetching the routine someRoutine from the database of the OTHERNAMESPACE namespace, but you are executing that code in your current namespace.

This is not the same as swapping to OTHERNAMESPACE, running the code, and then swapping back. For example, if someRoutine accesses globals it will do that from whichever namespace is current.

To see an example of this, try the following:

SAMPLES>w $zv
Cache for Windows (x86-64) 2016.2 (Build 636U) Wed Apr 13 2016 20:58:35 EDT
SAMPLES>d main^lookup
 
Lookup: 1-jan-2016...finding birthday...no matches
Lookup:
SAMPLES>zn "user"
 
USER>d main^|"SAMPLES"|lookup
 
Lookup: 1-jan-2016
<NOROUTINE>main+27^lookup *datent
USER 4d1>
 
USER 4d1>q
 
USER>

The code in main^lookup in the SAMPLES namespace calls $$validDOB^datent. When this is attempted from the USER namespace we get a <NOROUTINE> error. Notice that the extended information in the error tells us that the routine it can't find is datent.