· Apr 27, 2022 3m read

Who or what is consuming my licenses?

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"



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. In these cases, we usually see the following the "License Limit exceeded xxxx times" message in the messages.log:

Catching the problem on time

For the first scenario, where we see the problem happening, we have some alternatives: 

  • If we can log in to the System Management Portal, go to the License section and examine what is using what. 
  • Connect via terminal using the -B parameter (a regular connection is impossible because all the licenses are used). The -B parameter is used for administrator emergency login if logins are disabled or licenses are exhausted.
iris session <instance> -B
  • Once you connect, run the License DumpLocalAll method to dump all the licenses and examine what is consuming every slot. This file will contain something like this:

After the licenses are dumped and examined, most customers don't require our help to find out what is happening. They can identify the machines, users, or applications consuming more licenses than expected.

See the documentation for more details on how to connect to iris and about the License class: 


After the problem happened

We have some alternatives for the second scenario, where we see the problem after it happened and can't catch it. 

1) Monitor the messages.log for the License alert message (and others) to catch the problem on time.

If we are alerted when the problem happens, we can connect and work on the first scenario with the previous tips. 

An easy way to monitor level 2 messages is using the super fantastic tool  ^MONMGR (System monitor). You will receive an email once the system gets any alert with level 2 (like the licenses). You will be alerted immediately, so you can connect to the system and check the license usage using the System Management Portal (License sections) or from the terminal. 

2) Log license usage into the messages.log.

You can enable the tracking of license usage into the messages.log. When tracing is on, every license login or logout is traced to messages.log, identifying the process, action (Login or Logout), role (User, CSP, Diagnostic), and success or failure (non zero connection count or zero for failure).  
The result field for logins contains the new connection count. The result field for logouts should always have 1, indicating success:
These are the commands to enable/disable the tracing:
Do traceon^%SYS.LICENSE   // turns license tracing on. 

Do traceoff^%SYS.LICENSE  // turns license tracing off.
Note this will create a lot of "noise" in the messages.log on busy systems. So the previous approach can be better in some cases. Don't forget to disable the tracing once you find the problem!



As I said, once you are able to catch the problem on time and see the output of the license dump, it will be very easy to determine what is consuming the licenses. If there is something unusual, you will need to fix it, if not, you may need to buy more licenses, but that's another story and you can get more help from the WRC and Sales colleagues




Discussion (1)1
Log in or sign up to continue

When we've had license problems in the past, the WRC have supplied us with a routine that watches for the limit warnings and then does a one-off dump of what processes are running for later investigation. We also wrote our own code to do a snapshot of license usage to a file, which is called by the Caché task manager at regular intervals so that we can analyze license usage over time. Helps when trying to see if the site needs more, or sometimes less, licenses. There's nothing like a good graph to prove your point. :-)