Every developer has made the mistake of accidentally leaving temporary debug code in place when they meant to remove it after debugging is complete. The great thing about writing in ObjectScript is that there is a way to make temporary code be truly temporary and automatically self-destruct! This can also be done in such a way that the code has no change of making it into your source control stream, which can be helpful as well.

3 1
0 369

This is more for my memory that anything else but I thought I'd share it because it often comes up in comments, but is not in the InterSystems documentation.

There is a wonderful utility called ^REDEBUG that increases the level of logging going into mgr\cconsole.log.

You activate it by

a) start terminal/login

b) zn "%SYS"

c) do ^REDEBUG

6 0
0 1.1K
Article
· Oct 1, 2018 4m read
Profiling code using Caché Monitor

Not everyone knows that InterSystems Caché has a built-in tool for code profiling called Caché Monitor.

Its main purpose (obviously) is the collection of statistics for programs running in Caché. It can provide statistics by program, as well as detailed Line-by-Line statistics for each program.

Using Caché Monitor

Let’s take a look at a potential use case for Caché Monitor and its key features. So, in order to start the profiler, you need to go to the terminal and switch to the namespace that you want to monitor, then launch the %SYS.MONLBL system routine:

3 1
7 928

One of the most important features during application development is the ability to debug your code easily. Because of the asynchrnous nature, a standard Node.js application server works single-threaded by default. When you are developing applications using an IDE like Visual Studio Code, you can very easily debug your Node.js process:

First, download the free Visual Studio Code IDE (@code) and install it on your development machine.

3 0
0 2K

The article makes an attempt to demonstrate that Atelier is not just repeating the functionality of Caché Studio on a new IDE platform (Eclipse) but goes far beyond. Due to my personal experience, and challenges in former projects I picked first XSLT Debugging. Is it an ordinary task? Not at all. Who is doing XSLT every day? Probably none of us. Than why XSLT Debugging? Simply because there are solutions in our product portfolio which are using XSLT inside and those solutions require customization. Customizing XSLT without some sort of toolkit is more than challenging. The examples of such solutions starts with HealthShare IHE message, CDA vs. SDA transformations, goes through ZEN Reports, and ends by HealthShare CDA document viewer. Is that enough reason to spend time reading the whole article through not just the teaser?

4 3
0 527

This post is meant to provide a quick possible explanation for a very perplexing problem.

Scenario: You’ve just created your own administrative user in your 2014.1 (or later) instance of Caché. You gave it every possible security role (including %All), so it should in theory be able to do anything within the instance.

You’ve written a very advanced routine with a break command in it for debugging:

7 1
0 457