if you DB is expected to be big, I would invest on optimizing the storage in classes/globals:
- use proper datatype in classes (e.g. save dates as +$H not string "yyyy-mm-dd")
- if there are relationships, plan them carefully, with proper indices.
 - if there are repeated string, use referential tables, do not store them "flat" in the main table
- if there are array/list properties, mane the storage sub-global name very short
All those will reduce I/O, gives a better use of cache buffers, smaller storage footprint and will result in overall performance improvement.  

One of the main considerations is I/O - usually disks in cloud are relatively slow that what you have in-prem.
1. Segregate the IRIS databases, journals, WIJ to different disks to improve I/O performance.
2. Use mirroring for a fail-over pair for HA and for read-only mirrored instances for improving performance
3. Some cloud providers allow you to have a constrained cps VMs --> more memory per core for larger "cache buffers" usage, good if you have a cores incense for IRIS.

Lite terminal inside VS-Code is similar to the web based terminal (web-terminal). Both are using sockets which does not have a principal device. Some of the old known utilities were designed for telnet and will not work in those two.

Hello,

The #call returns a null by default is an expected behavior of CSP hyper event framework.

The main difference between sync (#server) and a-sync (#call) is that the 1st act like a DO command while the 2nd act like a JOB command. 

TBH, I don't see a good reason to get a "direct" response from the #call when the code is meant to be executed in the background. When there is a need to monitor progress of a job launched by a #call from a CSP page, the approach I always did was to have this (jobbed) code to update some global (with a %sessionId as a key, to avoid  parallel jobs to override each other) then have a timmed JS function in the page to #server another function on that page to monitor the global status (started, in progress which % done, finished etc.)

The Backup.Task is deliberately not registered as an SQL table, despite what the autogenerated documentation header says.

If you run the following SQL (in %SYS, using $system.SQL.shell) you get 0 results:
SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'Backup'

You can however work with this table in COS objects

The lookup read code seems ok. the error suggests that the table Ens.Util.LookupTable doesn't exist in SQL DB.
Are you sure that table you can successfully call from the portal is not local in IRIS?

Very good article @Dmitry Maslennikov 

The $LIST framework was created alongside classes in Caché as a replacement for the older $PIECE function. With $PIECE, you must predefine a delimiter that cannot occur in the data, while $LIST avoids this constraint entirely.

AI bot answer is not relevant to the question.

You say that code/data is in the same DB that is mirrored. 2025 and 2022 are using different version of journaling, but 2025 is capable of de-journaling journals from previous version (but not the vice versa).

1. When you upgraded the failover to 2025 (the one which is the new primary) did you had any issues with journal files? (might be that some files were dropped in the upgrade and not processed).
2. is that "missing rule" mapped to another DB that is not in mirror?

The Quit command is quitting the if statement therefore no value is allowed.

Clean code is not to have multiple places that quit with value, in long code it is difficult to track. Therefore a nice structure could be:
Ser result=1
If [condition] { ... set result=0 }
else { ... set result=1 }
Quit result 

WIJ (write image journal) is used for data before it is saved to the database. This is used to keep the data consistency (block level in database) and avoid database degradation. If IRIS (or the OS) crash, WIJ will have "dirty blocks" (not written to databases) that will be weritten during the next IRIS startup.

Journal files (or mirror journal, in case you have mirroring) are used after data saved to the database. This will help for transactions rollback and also to ensure a good restore point up to the "current time" along with the latest backup restore.

The sequence is:
1. Read a block was changed from the database
2. Write the modified block to WIJ
3. Write the modified block to the database
4. Write the global SETS and KILLS (and also transaction start/stop) to the journal file

Thank you so much for your recognition (!)

to feed any monitoring system best is to use: /api/monitor/metrics
if you enable interoperability monitoring, you should have: "iris_interop_hosts" which will have "status" (ok, Inactive etc.) per any host in any production.
you may also look into the property "Enabled" in class: Ens_Config.Item
if this is not enough, and you need your own code, than do a "user defined metric" than can be added to the /api/monitor/metrics results

when you have 2 applications, with the same namespace, and difference path you need to set "Package Name" to some (different) values for both applications. When "Package Name" is not set, the default prefix is "csp"

As InterSystems Technology is not an open source, it is not fair, in my opinion to compare the community open-source library of tools and examples to others (e.g. Linux, Apache etc.) since its not possible to use them without a valid license of a product (IRIS, Cache). As such its InterSystems motivation and also a rational should be to support this library, similar to their (massive) support for the community.

Norman,
If terminal is ok for you, but studio isn't, maybe you should try the VSCODE Lite terminal.

I'm using: IRIS for Windows (x86-64) 2024.1.4 (Build 516_1U) Sat May 31 2025 13:15:40 EDT
I get the same in Terminal (Telnet) and also in VS-Code Lite terminal:
MSCEME>write $ascii("♥") 
9829
 

HTTP 401 means "Unauthorized" check that the web application /terminal has the correct credentials and correct authentication methods (password, LDAP etc.)
(the /terminalsocket should be always unauthenticated, its the default)
to help you resolve this, you may use auditing, to see if there is a "login failure" when you try to access.

I would day that the bot answer is not relevant to what you asked.

there is no directive to do looping in macro definitions, however, you could look at a directive called #execute where you should be able to execute any valid COS code, but there are some limitations:
#execute | ObjectScript Reference | InterSystems IRIS Data Platform 2025.2
 

for sure direct global access, especially looping on indexes is faster than SQL. It seems that the index global you used: ^PatientD("Date",FromDate)) should be: ^PatientI("Date",FromDate)) 

Using queue manager (for each "FromDate") will do this in parallel which will speed things much more!

The is a core process called GARCOL which is used to handle large global kills.
Securing Caché, Ensemble, And Operating System Resources | Caché & Ensemble 2018.1.0-2018.1.3
 

I would consider, replacing the lock + and lock - with setting/killing a (temporary) global, which can be mapped to IRISTEMP for better performance, and avoid journaling. It might be easy to implement such in parallel to the current lock mechanism (add those while keep the old in place) then migrate the management page in the application to loop on this global instead of the entries in lock table. The new approach can also have the timestamp for the lock and then have a function that will auto-retain locks (kill) based on a time interval.

look at Ens_Config.Item there is a property called "Enabled"

try to change:
<Route Url="/{id:[0-9]+}" Method="GET" Call="NewsGetItem"/>

try to open developer tools (shift-ctrl-P) then search for "developer tools" - check in console if there are any errors