Executive limits

It is possible to limit the number of times an application can be executed on the current license.  This is done by setting a variable in the customer's license variables which defines the execution limit, and then using a license's built-in Usage Counter (also known as an Exection Counter) to keep the application from executing more than the limit allows.

The execution counter is monitored on the current license.  If the license is renewed, then the counter does not change, but is carried forward.  However, if the user gets a new license the counter is reset to 0 (zero), unless they are re-acquiring the same license.  The idea is that the user will be forced to get a new license on a regular basis if they want to keep using the software.

The counter is stored within the user's license data, but it is also sent up to the server whenever the LM client has internet connectivity.  You can see a particular license's usage counter on the Current Usage report screen in NitroAdmin. 

Note: Execution limits are currently only available on checked-out licenses.  Since floating licenses check back with the server every time they're used, they have less need of execution limits. 

Setting the limit

In NitroAdmin, there are two special variables that are used for this -- MAX_EXEC and WARN_EXEC.  Set the MAX_EXEC variable on a customer to a specific number (such as 10) to limit the executions.  The WARN_EXEC variable is optional; if you set it, when the user's execution counter reaches that point then they will receive a warning that they are approaching the limit of executions.  To work properly the WARN_EXEC value must be less than the MAX_EXEC value.

You could have different limits for different products by setting the variable values at the customer/product level rather than at the customer level.

You may need to define the two variables on your Variable Setup screen first, if they are not already set up.  They should be marked as readonly, although the License Client will prevent the values from being overridden by the user.  Use the defaults for the other variable settings.

Incrementing the counter

The incrementing of the usage counter is not automatic; it must be managed by your application.  You could increment the counter when your application starts (perhaps after validating their license), so that you're tracking each execution of the application.  Alternatively, you could increment the counter each time some action is taken (such as generating a binary file) so that you're tracking - and limiting - the number of actions they can take.

The function to increment the counter is incUsageCounter(product). You would pass it the same product code that represents your application, which should be the same as is passed to the validate() function. 

Checking the counter

There are two ways to check to see whether the user has reached their limit. 

  1. The standard validate() function will automatically check the limit if all other validations have passed.  It will return error code 39 (RESPONSE_EXCEEDED_MAX_EXEC) which is "Exceeded maximum execution limit for this license" if the MAX_EXEC limit has been passed.
  2. The checkUsageCounter() function will perform a separate check of the counter, in case you want to check the counter without doing a full validation.  You must also use this function if you want to check WARN_EXEC.  It will return the same error if the MAX_EXEC limit has passed, and it will also return error code 41 (RESPONSE_EXCEEDED_WARN_EXEC) which is "Reached the execution warning limit for this license" if the WARN_EXEC limit has passed.  If neither has occurred then it will return 0 (RESPONSE_OK) unless some other error has occurred.

The incUsageCounter() function will return those same codes as checkUsageCounter() if the limits are passed.