If you have just a few breaks, one of the possible solutions has been given by Robert Cemper. In case, you have tons of those breaks, you could execute the unit test in background:
job^performUnitTest
assumed, your unittest can work in background and all the output goes, for example, in a file.
The solution for the case you let run the unittest in a terminal session, could be something like this
do turnOffBreaks, performUnitTest, turnOnBreaks
The only problem is, to turn breaks off (or on), you need one view command, one $view() function and one $zutil() function (to get the right address for the view-s). Unfortunatelly, the use of the above tools is discouraged, so your best bet is, to ask WRC for a help.
That's one of the very good reasons, do not work together on the same server. So, yeah, the best way to go is to use your own instance, so, no one will break your tests excepts you
It might be easier just to always make your BREAK commands conditional like (Robert Cemper suggests above). Do it like:
BREAK:$GET(^|"USER"|MyNameBreakAppEnable)
Use your own name for "MyName".
Then you do SET ^|"USER"|MyNameBreakAppEnable=1 to enable break points and KILL ^|"USER"|MyNameBreakAppEnable to turn break points off.
Change the name of "App" to conditionalize break points for use in different applications. And "USER" is a scratch namespace available on all the instances you plan to do debugging on.
Discourage the use of hard coded breaks in the first place! There are alternatives.
Use ZBREAK Tag+OffSet^Routine to set a break point just for the current process
Use the debugger in Cache´ Studio (under the Debug menu and attach to a process)
George James has a decent debugger in Serenjii
Put something in your processes to remove hard coded break points when you promote code through the development cycle (you can automate this if you try)
Use BREAK with a postcondition depending on Username
or some other personal switch (eg. PPG)
If you have just a few breaks, one of the possible solutions has been given by Robert Cemper. In case, you have tons of those breaks, you could execute the unit test in background:
job ^performUnitTest
assumed, your unittest can work in background and all the output goes, for example, in a file.
The solution for the case you let run the unittest in a terminal session, could be something like this
do turnOffBreaks, performUnitTest, turnOnBreaks
The only problem is, to turn breaks off (or on), you need one view command, one $view() function and one $zutil() function (to get the right address for the view-s). Unfortunatelly, the use of the above tools is discouraged, so your best bet is, to ask WRC for a help.
That's one of the very good reasons, do not work together on the same server. So, yeah, the best way to go is to use your own instance, so, no one will break your tests excepts you
Disable breaks for a current process by calling $system.Process.BreakMode(0). Docs.
To disable breaks system-wide set the BreakMode property in the Config.Miscellaneous class.
That has eluded me (so far). Thank you for the hint.
It might be easier just to always make your BREAK commands conditional like (Robert Cemper suggests above). Do it like:
BREAK:$GET(^|"USER"|MyNameBreakAppEnable)
Use your own name for "MyName".
Then you do SET ^|"USER"|MyNameBreakAppEnable=1 to enable break points and
KILL ^|"USER"|MyNameBreakAppEnable to turn break points off.
Change the name of "App" to conditionalize break points for use in different applications. And "USER" is a scratch namespace available on all the instances you plan to do debugging on.
Discourage the use of hard coded breaks in the first place! There are alternatives.
Social networks
InterSystems resources
Log in or sign up
Log in or create a new account to continue
Log in or sign up
Log in or create a new account to continue
Log in or sign up
Log in or create a new account to continue