Marc, a slight variation on your idea, tested whether targetRtn exists or not. Thanks again!
zn "A" s currRtn=(##class(%Routine).%OpenId(rtnName)) s stream=currRtn.Read() zn "B" s targetRtn=(##class(%Routine).%OpenId(rtnName)) s sc=targetRtn.Write(stream) d targetRtn.Save()
One late addition: I just lost this debugging functionality again, looks like because my code was going into a different namespace via zn "nsp". If I put the first breakpoint AFTER this zn, the cursor does not go to it and the yellow box does not appear. However, if I put my first breakpoint AT zn, the yellow box appears at it and stays with me after the breakpoint as well. Can't say it's a feature but then what??
Losing debugging capabilities, Scenario #2. A fellow programmer also lost her debugging capabilities some time ago though for different reasons and with different symptoms. I am not dead sure what happened in her case but it looks like some unfortunate combination of User Roles and Service Settings as defined in Management Portal. We discussed it today and she tried a few things. Changing the studio login user helped as well as changing localhost in Cache Server Manager to an actual IP address. Using Remote System Access from the cube was beneficial as well.
Alright, this particular saga suddenly came to the end revealing the bug, my own one. But it is sort of educational so some details. I am implementing source control like features on and off while inheriting one of the features from a previous programmer. The latter feature which I preserved was about adding a timestamp with the compilation time to the changed routine in the overwritten source control method, OnAfterCompile. OnAfterCompile was adding this timestamp, resaving the routine directly in one of the internal routine globals, and it did NOT recompile the file again. That effectively still had the file internally marked as saved and compiled, no little cross in the Studio's routine tab, BUT that threw the .OBJ file mapping to the routine source code enough so the debug yellow box would refuse to appear and the cursor would not move from the first line. Many self eye-rolling emojis here...
How did I discover it? I need to modify this custom source control class and it was annoying to do so while the source control was on so I turned it off, moved functionality to my test routine, and observed with incredulity the long lost yellow debug box again....
P.S. On the plus side, I learned a lot about inner Cache workings due to this largely self-inflicted wound and I am happy it is over.
Everybody, thanks for your help and advice but the old-timer's advice to go the d ^%GOF route in Cache Terminal proved to be it. It was actually amazing to see how much superior this route turned out to be comparing with the much more modern Export/Import Management Portal route. Specifically:
Preparation to exclude certain globals, few dozens of them: Terminal - about 10 minutes because you can use ranges (see below and here, https://docs.intersystems.com/priordocexcerpts/prgglobalchui-41.pdf), portal - much longer because you have to uncheck each global individually
Export/Import log per global: Terminal - log provided, complete with the number of blocks per global, portal - no log
Import speed: Terminal - less than 10 minutes, portal - stuck in the middle with no error shown
Sample %GOF usage in terminal, hit Enter if no special requests, exporting: d ^%GOF Device: tmp.gof file format: ("UNW*") => Maximum media size (bytes): (No maximum) Enter a short description of the contents of this tape or file Description: All Globals? No => No Global ^S-SZ [All globals in this range, case-sensitive - AG] Global ^'STPL* [Exclude all globals that start with STPL - AG]
Real life output from my real life usage: ............... ^ZPG 182 data blocks written ^ZTEMP 1 data block written 491,337 blocks written in 10 minutes, 51 seconds -------------------- Importing was done via d ^%GIF, via terminal as well. At some point the %GIF utility asked me:
Globals with a preceding asterisk ('*') already exist in this directory What would you like to do with these globals that exist?
1. Skip inputting globals that exist in this directory 2. Merge input globals with the existing globals 3. Specify skip/merge for individual globals
It looks like code below would give me what I am looking for. Just need to figure out (or take an advice!) how to exclude, say, system classes outright.
s rs=##class(%ResultSet).%New("%Dictionary.ClassDefinitionQuery:ClassIndex") s x=rs.Execute() f { s x=rs.Next() q:'x s TimeChanged=rs.GetDataByName("TimeChanged") s ClassName=rs.GetDataByName("ClassName") s Hash1=rs.GetDataByName("Hash1") s Hash2=rs.GetDataByName("Hash2") s System=rs.GetDataByName("System") s ClassType=rs.GetDataByName("ClassType") s Size=rs.GetDataByName("Size") } P.S. Found the answer to my last question: https://cedocs.intersystems.com/latest/csp/documatic/%25CSP.Documatic.cls?PAGE=CLASS&LIBRARY=%25SYS&CLASSNAME=%25Library.RemoteResultSet
go to post
Marc, a slight variation on your idea, tested whether targetRtn exists or not. Thanks again!
s currRtn=(##class(%Routine).%OpenId(rtnName))
s stream=currRtn.Read()
zn "B"
s targetRtn=(##class(%Routine).%OpenId(rtnName))
s sc=targetRtn.Write(stream)
d targetRtn.Save()
go to post
One late addition: I just lost this debugging functionality again, looks like because my code was going into a different namespace via zn "nsp". If I put the first breakpoint AFTER this zn, the cursor does not go to it and the yellow box does not appear. However, if I put my first breakpoint AT zn, the yellow box appears at it and stays with me after the breakpoint as well. Can't say it's a feature but then what??
go to post
Losing debugging capabilities, Scenario #2.
A fellow programmer also lost her debugging capabilities some time ago though for different reasons and with different symptoms. I am not dead sure what happened in her case but it looks like some unfortunate combination of User Roles and Service Settings as defined in Management Portal. We discussed it today and she tried a few things. Changing the studio login user helped as well as changing localhost in Cache Server Manager to an actual IP address. Using Remote System Access from the cube was beneficial as well.
go to post
Alright, this particular saga suddenly came to the end revealing the bug, my own one. But it is sort of educational so some details. I am implementing source control like features on and off while inheriting one of the features from a previous programmer. The latter feature which I preserved was about adding a timestamp with the compilation time to the changed routine in the overwritten source control method, OnAfterCompile. OnAfterCompile was adding this timestamp, resaving the routine directly in one of the internal routine globals, and it did NOT recompile the file again. That effectively still had the file internally marked as saved and compiled, no little cross in the Studio's routine tab, BUT that threw the .OBJ file mapping to the routine source code enough so the debug yellow box would refuse to appear and the cursor would not move from the first line. Many self eye-rolling emojis here...
How did I discover it? I need to modify this custom source control class and it was annoying to do so while the source control was on so I turned it off, moved functionality to my test routine, and observed with incredulity the long lost yellow debug box again....
P.S. On the plus side, I learned a lot about inner Cache workings due to this largely self-inflicted wound and I am happy it is over.
go to post
Everybody, thanks for your help and advice but the old-timer's advice to go the d ^%GOF route in Cache Terminal proved to be it. It was actually amazing to see how much superior this route turned out to be comparing with the much more modern Export/Import Management Portal route. Specifically:
Sample %GOF usage in terminal, hit Enter if no special requests, exporting:
d ^%GOF
Device: tmp.gof
file format: ("UNW*") =>
Maximum media size (bytes): (No maximum)
Enter a short description of the contents of this tape or file
Description:
All Globals? No => No
Global ^S-SZ [All globals in this range, case-sensitive - AG]
Global ^'STPL* [Exclude all globals that start with STPL - AG]
Real life output from my real life usage:
...............
^ZPG 182 data blocks written
^ZTEMP 1 data block written
491,337 blocks written in 10 minutes, 51 seconds
--------------------
Importing was done via d ^%GIF, via terminal as well. At some point the %GIF utility asked me:
Globals with a preceding asterisk ('*') already exist in this directory
What would you like to do with these globals that exist?
1. Skip inputting globals that exist in this directory
2. Merge input globals with the existing globals
3. Specify skip/merge for individual globals
Your choice: 1=>
Thanks again,
Anna
go to post
It looks like code below would give me what I am looking for. Just need to figure out (or take an advice!) how to exclude, say, system classes outright.
s x=rs.Execute()
f {
s x=rs.Next() q:'x
s TimeChanged=rs.GetDataByName("TimeChanged")
s ClassName=rs.GetDataByName("ClassName")
s Hash1=rs.GetDataByName("Hash1")
s Hash2=rs.GetDataByName("Hash2")
s System=rs.GetDataByName("System")
s ClassType=rs.GetDataByName("ClassType")
s Size=rs.GetDataByName("Size")
}
P.S. Found the answer to my last question: https://cedocs.intersystems.com/latest/csp/documatic/%25CSP.Documatic.cls?PAGE=CLASS&LIBRARY=%25SYS&CLASSNAME=%25Library.RemoteResultSet