This is mentioned here in docs here: https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KE…

From what I can tell this occurs in the operation rather than the service (so if doing something in a process it would still have spaces) and though sort of implies that this occurs when using format codes like %f it will do this even if you specified an exact name like "Chart Note.pdf". There's no control over it that I can tell as an unconditional $TR of occurs right away in Ens.Util.File:CreateTimestamp which is what ends up being executed during file/SFTP operations. You would need to use a custom EnsLib.File.PassthroughOperation with updates to the two Set tFilename calls in OnMessage to use your own version of CreateTimestamp. There is actually one call directly to that but the other goes to the EnsLib.File.OutboundAdapter's CreateFilename method which calls CreateTimestamp. So might also need a custom adapter, referred to by the PassthroughOperation, but can probably get around that if going to this much trouble!

I haven't noticed a tool specifically for that but the information appears to be stored in the global ^EnsPortal.SavedSearchD so you can use your favorite global export/import tool to copy them wherever needed.

Wonderful! That always bothered me more than is logical, but after digging around at one point and not quite figuring it out I begrudgingly moved on. Glad I saw this!

Initially I couldn't get the change to take effect using "en" though. I needed to use "en-us" instead. That worked fine and makes sense given my locale of "enuw". Curiously though most digging around in globals seemed to indicate "en" and I'm not sure what actually indicates that "en-us" is the correct node to be used as everywhere I looked seemed to come up "en".

^CacheMsg("Arial,Tahoma,Verdana")="en"
                       "Confirm")pointer
               "EDIDocumentView")="en"
                           "Ens")pointer
                      "EnsAlert")pointer
                        "EnsBPL")="en"
                    "EnsColumns")="en"
                      "EnsDICOM")="en"
                       "EnsDemo")pointer
                        "EnsEDI")pointer
                 "EnsEDIEDIFACT")pointer
                     "EnsEDIHL7")pointer
                     "EnsEDISEF")pointer
                     "EnsEDIX12")pointer
                        "EnsEnt")pointer
          "EnsPushNotifications")pointer
                  "EnsRecordMap")="en"
                        "EnsSAP")="en"
                "EnsSearchTable")pointer
                         "EnsWf")pointer
                      "EnsXPATH")pointer
                      "EnsebXML")pointer
                      "Ensemble")="en"
                           "ITK")="en"
                    "RuleEditor")="en"
                      "Workflow")pointer
                "tahoma,verdana")="en"
 

^%SYS("LANGUAGE","CURRENT")="en"
^%SYS("LOCALE","CURRENT")="enuw"
 

w $mvv(58)
en

Maybe something to do with %SYS.NLS.Locale.cls or %SYS.NLS.int, and the exact details aren't really a big concern, but good to know if you find setting the global using "en" doesn't seem to work.

Thanks!

Aric

Related to this and alerting in general - in my organization and I'm sure many others you may want to send these type of alerts as pages or text messages. This of course can be done by adding a recipient email of something like 2065551234@txt.att.net. One drawback though is that when glancing over a list of emails like this it can be difficult to tell who a particular number is actually associated with (or even with normal emails that might be short or otherwise ambiguous). One thing that I found can be helpful is that you can enter emails in the format of: "Aric West" <2065551234@txt.att.net> with quotes around the name and angle brackets around the actual email, just as is often seen in email clients. This format works well in "to", "from", "reply to", etc fields in ^MONMGR, ^%SYSMONMGR, task manager, Ensemble's EnsLib.EMail.AlertOperation, etc throughout Cache and Ensemble.