So, you checked your server and saw that IRISTEMP is growing too much. There's no need to panic. Let’s investigate the issue before your storage runs out.

Step 1: Confirm the IRISTEMP Growth Issue

Before assuming IRISTEMP is the problem, let’s check its actual size.

Check the Free Space

Run the following command in the IRIS terminal:

%SYS>do ^%FREECNT

When prompted, enter:

Database directory to show free space for (*=All)? /<your_iris_directory>/mgr/iristemp/

If the output shows very low free space, IRISTEMP is filling up your storage like an overstuffed closet. But if the free space is fine, yet

Note: ********* The following is just a guideline! Every customer is different and will have different points ***************

Through our experience in Support helping customers, we have seen a lot of cases where not having a reasonable upgrade plan (documented) leads to unexpected problems with a Crisis priority. In some cases, we can fix the problem during the upgrade window, but not always, as some situations may require further investigation that can take days or even months!

It is essential to document the upgrade process, covering the steps to do before, during and after the upgrade, even

From time to time, we get the previous question in support, something or someone is using more licenses than expected, and we need to find what. 

We have two scenarios. The first scenario is when we realize that the licenses are exhausted when the application does not work or when we try to connect through the terminal and get the "lovely"

<LICENSE LIMIT EXCEEDED> message: 

The second scenario is when the end-user complains they could not use the application at some time, and we are late to see the problem when it is happening.

Working in support, I usually get asked how many days I should keep journals. Should it be two days or after two backups? More? Less? Why two?

The correct answer (for most of the environments) is that you should keep the journals since the last validated Backup. I.e., until you don't check if a Backup is valid (restoring the file and checking with the Integrity utility), you can't be sure there is a good copy of your data and can't purge the journals safely.

For example, imagine you need to restore your system after a hardware failure that corrupted some databases.

Hi, 

I know there are several alternatives, but I would like to find the easiest & simpler ones to store data coming in Json format from post requests and also allowing me to do SQL queries. 

I want to have a property called favouriteColors. I want to store a few colors, and I want to be able to do queries to get top favorite colors, etc... so not handling the list of colors as just a fixed string or fixed object. 

If I want to store this information, I have several alternatives, like %DynamicArray, list of %String o maybe just %String, but I  want to find the best way to store the property in

Hi, 

If you like to play and test with mirroring, now you can do it very easily with dockers and these simple mirror scripts.

• The docker-compose.yml will create 2 containers with the preferred version. 
• The installer.sh script will start the ISCAgent, load the Installer.cls class into Iris and call it. 
• The interesting part is inside the Installer.cls class, you will find some methods to create a mirror,  join and create databases in mirror.  The scripts are quite simple and you can borrow them to create your own mirrors.

Note that this script is just valid for 2019.3 and newer, if you