#Debugging

Hi developers, 

We've incorporated VS Code's support for multiple concurrent debug sessions and consoles into the latest release of Serenji. 

So if you're working with processes that relate or are dependent on each other, you can now debug them together. Just launch a second Serenji debug session (F5) whilst the first one is still active. 

This short video below shows how it works. We hope you find this feature useful! 

Laurel 

Hi developers, 

Serenji 3.2.0, the latest version from George James Software, was released last week and our current users have been enjoying trying out the new features (which you can find more about here). 

If you're thinking about trying Serenji for the first time, we've made it easier to get set up by adding a walkthrough on the VS Code Welcome page. It takes you through: 

• Setting up the server components.
• Selecting a server namespace.
• Saving and extending your workspace.
• Requesting a debug license (don't forget we offer a free 30 day trial!) 

We've also added prompts and guidance throughout VS Code to open and add Serenji folders to your workspace and when going to run and debug code. 

This is just one of the ways we've enhanced the Serenji debugger to make straightforward and easy to use - so all you need to do is focus on your code. 

gj :: locate was the entry from George James Software for the Developer Tools competition back in April 2021. When an ObjectScript error is reported, gj :: locate takes the .int line location and navigates you directly to the line in the source file where the error originated. Over the past few months we've found it a very useful tool when it comes to debugging, especially when used alongside the Serenji debugger in Visual Studio Code.

Our first update, version 1.1.0, now includes support for multi-root workspaces. This enables gj :: locate to be used with every workspace folder. If your VS Code workspace has more than one root level folder, connecting to different namespaces or perhaps different servers, then gj :: locate will determine which workspace folder is current and locate the source code in that folder. If your workspace doesn't have any files open then gj :: locate will prompt you to select a folder from a pick-list.

This will particularly benefit VS Code power users who have workspaces with simultaneous connections to multiple namespaces, on multiple different IRIS and Caché servers.

If you would like to try it out then you can download it from the VS Code marketplace. Or if you’re already a user, then gj :: locate will automatically update. Let us know how you're getting on with it!

Hi,

I'm getting thousands of errors like the ones below:

2021-05-03 14:11:44 [SQLCODE: <-400>:<Ocorreu um erro fatal>] [Cache Error: <<READ>Dispatch+14^%SYS.BINDSRV>] [Location: <ServerLoop>] [Client info: <Username: KIORAS, Node Name: 3IK0VLS5UU, IP Address: 192.168.1.223, Executable Name: EXTRService.exe, Internal Function: B0>] [%protocol: <52>] $Id: //ce/2018.1.2/kernel/common/src/aclass.c#1 $ 23468 104

You may think it isn’t too difficult to get from label+offset^routine to the actual source line responsible for the error. For an expert it isn't that hard... most of the time. But there are enough oddities and special rules that even an expert can get it wrong, whilst spending a lot of time trying to get there.

gj :: locate is the latest tool from George James Software – it debugs any error, class or routine by converting the location of an error in compiled .int code to the corresponding location in your source, and then taking you right there.

Image this scenario…

I have multiple projects that I utilize when debugging in Cache Studio. One of my projects suddenly lost the ability to step through commands with the yellow box and the cursor moving though code lines. The cursor just sits at the entry line while variables apparently do change. Interestingly enough, if I change the project and the debug target, the "yellow box" ability is still there. Apparently losing this functionality is by project/debug target/whatever. The goal is, of course to return it back but how?

Someone may have asked this before but is there a way to return the TRACE statements that we have placed in the Data transformation within the DTL Editor Testing Tool (EnsPortal.Dialog.TestTransform.cls)? Is this something we can get in an Enhancement request in for?

It would save sometime in troubleshooting where an error might be in the DTL.

Just wondering...

Thanks

Scott

I come from Visual Studio and now I use mostly Cache 2017 Studio. One debugging functionality I miss dearly is current local variables automatically appearing in the Watch Variables window together with their values. Yes, I can hover or type them myself but both actions take extra time which is especially noticeable when debugging unfamiliar code across many routines. Any Cache settings or plugins to that effect? If not then why not? And if nothing else is there in Cache, what are the alternatives or hacks in this respect?

Anna

You might have encountered this and not known how to prevent it, or perhaps not even noticed it...

Running Cache 2017.2.2.

I'm trying to make a REST API call in JSON format. When using the example in the class reference documentation the getJSON method in the %Net.Http class throws the error <METHOD DOES NOT EXIST> on a %Clone() method in the %LIbrary.DynamicObject class. I even changed the parameter to a JSON string to no avail. The code will then fail on the %Compose method (examples below). My workaround is to use the %Net.HttpRequest functionality. Is there another workaround to this?

Hi everyone,

I have an existing application on HealthShare 2015 and decide to move it to HealthShare 2018 to make use of Atelier support. I am using Eclipse Photon with Atelier Plugin 1.3.

Most of things are working better on Atelier comparing with Built-in studio of HealthShare. However, when I tried debugging CSP file with Atelier I encounter 2 problems:

1.

So, I was doing a debug test on a routine, and tried to open a file (yes, it does exist) as so:

s file=##class(%File).%Open($$$airfile,"R")

   try{
        ....
        ....
        ....

        Set tSC = method_invocation()

        If $$$ISERR(tSC) {
            Quit tSC
        }

        ....
        ....
        ....

}

On compiling the above, I get an error saying "QUIT argument not allowed : 'tSC' ".

Hello,

I am reading in an X12 document into my production that needs to be processed and returned as a CSV file. I have created a record map to support the fields I want to extract with a batch class to store headers. I have a DTL mapping the data to the appropriate fields in the record map and am sending the record map to a EnsLib.RecordMap.Operation.BatchFileOperation.