New post
Article
· May 11, 2016 1m read

ZZPRINT a handy way to view routine lines from the command line

#Object Data Model #Caché

Often when debugging COS code you get an error message such as '<UNDEFINED>test^routine *test' so the first thing you want to do is to take a look at this code and see what it is doing. From the command line you can:

ZLOAD routine ZPRINT test

Which means splitting the $zerror information into the routine name and the line and adding the zload/zprint commands. Also you often want to view the lines above the one where the error happened as this gives you some context of how you got to this line, using ZPRINT you could 'ZPRINT +1:test' but that may display hundreds of lines.

Since 2013.1 you can use ZZPRINT as follows:

ZZPRINT "test^routine":10

Which will print the 10 lines before the 'test^routine' line, so here you can cut/paste the line reference directly into the command and you can specify the number of lines before or after using this syntax where both the before or after can be blank:

ZZPRINT "<entry+offset^routine>":<before lines>:<after lines>

Also since 2015.2 you can display the current $zerror line with and the ten lines before with:

ZZPRINT "$ze":10

Also if you are in the command line debugger then you can display the current break point location with:

ZZPRINT "*":5:5

Will display the current location and 5 lines previous and 5 lines after.

Discussion (6)2
Log in or sign up to continue
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.

4 0
Mark Hanson · May 12, 2016

The use of ZZW was a mistake and we removed this in the next release after it was introduced.

I did not see any documentation that said that 'ZZ' was reserved for any particular use and the examples in the documentation show functions that do not use 'ZZ' as part of their name so I was trying to avoid user extensions in naming the item 'ZZPRINT' by assuming we can use 'ZZ' and customers will use 'Z<something else>'. I apologize if this caused a problem for you, that was the opposite of my intension.

1 0
Alexey Maslov · May 12, 2016

It seems that George James Software (like some other M houses) followed MSM traditions where all command and function users' extensions names could started with 'ZZ' only.

We at SP.ARM have some command extensions as well, and all of them are named as 'ZZ*'. E.g., ZZU - CHUI based namespace navigator, which was originally written for MSM many years ago (when 'U' meant 'UCI') and ported to Cache among first handy tools we used those days (y2k +/-1).

This old ZZ-rule was rather convenient as it naturally separated users' extensions (ZZ*) from system ones (Z<not Z>*).

0 0
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().

1 0