Yes, absolutely true, if you are not using an old version/product like Caché/Ensemble.

Windows VSS support was introduced few years ago, maybe with IRIS?

So, if your backup solution has VSS quiescence enabled, you can simply rely on it and you are good to go without any script/freeze/thaw. It's authomatic.

You can check messages.log file during backup, look for something like:

[Utility.Event] Backup.General.ExternalFreeze: Start a journal restore for this backup with journal file: e:\intersystems\iris\mgr\journal\20250210.004
[Utility.Event] Backup.General.ExternalFreeze: System suspended
[Generic.Event] VSS Writer: OnThaw
[Utility.Event] Backup.General.ExternalThaw: Resuming system
[Utility.Event] Backup.General.ExternalThaw: System resumed

Backup.Task is a system class located in %SYS, I'm not sure if creating a Backup.Task in another namespace (hopefully!!) address his issue.

To support longer then 500 lines you may use an hash instead of the actual line.

If you want/need to keep the generated .int, then:

set sts = ##class(%Routine).CompileList("*.int","/keepsource=1")

or

set sts = ##class(%Routine).CompileList("*.int","k")

Here is the corresponding (as per @Stephen Canzano post) IRIS documentation (no password required):

Version Checking (Alternative to Concurrency Argument)

Hi @Stephen Canzano, 

it's my understanding that none of the counters described in the doc page you linked is incremented using UPDATE, nor can be modified by user code/SQL.

Can you provide some more details?

What kind of object holds your received "File"?

You should never concatenate query parameters in the query text, instead use placeholders and parameters.

Like this:

 set tQuery="SELECT ProvId, AllwOpenSchYN, IsAllwSchedYN FROM "_context.EpicClaritySerMycTable_" WHERE ProvId=? AND Market=?"
 set tStatement = ##class(%SQL.Statement).%New()
 set qStatus = tStatement.%Prepare(tQuery)
 set rset = tStatement.%Execute(context.ProvId,context.Market)
 do rset.%Next()
 if rset.%SQLCODE<0 { 
    $$$TRACE("SQL Query ["_tQuery_"] FAILED")
 } else {
    set tAllwOpenSchYN = rset.AllwOpenSchYN
    set tIsAllwSchedYN = rset.IsAllwSchedYN
    set tProvId = rset.ProvId
       
 }
 

Suggested reading: Dynamic SQL Best Practices

Hi @Ashok Kumar T , you also need to use lock to properly implement ACID, something like:

LEARNING>lock +^myTracker("onSomething")
LEARNING>w ^myTracker("onSomething")
1
LEARNING>ts
 
TL1:LEARNING>s ^myTracker("onSomething")=12
TL1:LEARNING>w ^myTracker("onSomething")
12
TL1:LEARNING>trollback
LEARNING>w ^myTracker("onSomething")
1
LEARNING>lock -^myTracker("onSomething")
LEARNING>

Wow @Jeffrey Drumm !

It's amazing to see how we had the same idea/solution! 😂

Probably because it's a good idea/solution! 😊

Regarding the debug vs. assign action, maybe assign is easier and simpler to adopt because does not need to change RuleLogging setting that can "conflict" (mess) if more debug actions are used that are not required in production.
Using debug has the advantage to be able to disable the logging from portal/settings, if/when required.
It depends on the environment and requirements, soooo.....good we have to options! 😉

Having said that, it would be great if IRIS will add specific Action(s) to log info/warning/error in the event log.

As I suspected, in the DownloadFiles method the variable "fileName" is not (yet) defined when you use it.
In addition, in your catch method you have a Write command that "Write" invalid javascript code.

I'd suggest to change the catch code with:

} Catch ex {
    Set sc = ex.AsStatus()
    &js<..QuoteJS("Exception: "_ex.DisplayString());>
}

This way if an objectscript error you get an alert with the error details.

Then, change all reference to the "fileName" variable and use "fileList" instead before the line:

For i=1:1:$LISTLENGTH(fileArray)

This prevents <UNDEFINED> errors when referencing "fileName" variable.