Managing Multiple Licenses

This section explains how multiple licenses for the same feature-version or for different versions are managed on a system.

Loading Licenses

The License Manager loads the licenses from the following:

1.Licenses in the license file - The licenses in the license file are loaded into the License Manager memory (License Table) on License Manager startup.

2.Licenses added dynamically - The licenses added during the License Manager run-time, using tools like lslic and WlmAdmin or API functions (VLSaddFeature and VLSaddFeatureToFile), can be added into the file or just into memory. For Unified API-based implementations, use the sntl_licensing_install_license API to add licenses dynamically.

NOTE Licenses in the license file persist even after reboot (unless removed from the file). The licenses existing only in memory are not available next time when the License Manager is restarted.

The License Table

The license table is an arrangement of active licenses for the various feature-version combinations. The license requests are served from the license table. The various licenses for a feature-version are arranged as shown in the diagram below:

The License Table and Related Nodes

Where,

1.Fn - refers to a feature name, Vn - refers to a feature version, Ln - refers to a license

2.Feature and Version Names - See the feature-version combinations (F1-V1 and so on)—for which licenses are available in the license table. They are arranged depending on the order of their addition—the recently added features are placed lowest in the license table and vice-versa. Also note that the version upgrades are treated differently—such as, F1-V1 is different from F1-V2.

NOTE The maximum number of feature-version pairs that can be loaded concurrently is 2000.

3.Licenses Loaded - The right part of the diagram shows the various licenses loaded for a feature-version. All the licenses available for a feature-version are loaded except those having unmatched locking codes.

4.License Table - The license table is formed using the active license only. The remaining licenses are arranged according to rules described in the next section. For example, for F2-V1, L4, L5, and L6 licenses are loaded; however, only L4 license is used for servicing client requests.

NOTE The maximum number of active licenses that can be loaded concurrently under one feature-version node is 256.

The following sections explain how a particular license is chosen to be the active license and how various other licenses are arranged.

Rules for Prioritizing Licenses

The licenses are sorted according to the following rules:

NOTE The rules mentioned below are shown in order of diminishing importance. The type of license, whether normal or trial, is the most important principle, followed by the exclusive or aggregate or additive property, and so on. Therefore, a normal unlocked license is preferred over a trial locked license.

Trial Licenses vs Normal Licenses

A normal license has a higher priority over a trial license, except when the trial license has precedence set to minus one (-1).

The trial licenses have precedence associated with them, which decides their priority for usage. To learn more about the trial license precedence values, refer to Trial License Precedence . Note that normal licenses do not have any precedence associated with them.

Exclusive, Aggregate, and Additive Licenses

An exclusive license is preferred over aggregate license and aggregate over an additive license.

Signing Key Index

Higher signing key index gets higher priority irrespective of the license version.

Current Date Aggregate Licenses vs Future Date Aggregate Licenses

Since v8.5.0, future date aggregate licenses can also be loaded in the License Manager memory. So, an aggregate license whose start date has reached and expiry date (end date) is yet to reach will be preferred over future date and expired licenses. Among expired and future date aggregate licenses, the latter have higher priority. Similarly, the future date aggregate licenses are sorted on the basis of the start date—licenses with earlier start date are preferred.

Locked Licenses vs Unlocked Licenses

A locked license has a higher priority over an unlocked license.

NOTE The License Manager never loads the locked licenses with unmatched locking codes.

For standalone licenses, only the client-locking is matched and for network licenses server-locking is matched. Also note that client-locking is considered at par with server-locking.

Last In, First Out

When all of the above criteria match, the most recently added license has a higher priority over older licenses.

NOTE The exhausted licenses and expired licenses are placed in the extreme right-end of the license table (when multiple licenses exist for the feature-version)—but are never issued. If such licenses are the only licenses available for the feature-version, then they would even become the active licenses on the feature node. If desired, these licenses can be deleted from the license table.

Loading Specific License Models

Specific licenses, such as commuter, grace or repository, are loaded as follows.

1.Redundant licenses
A redundant license has the highest priority, even higher than a trial license of -1 precedence. This is true even if the redundant license has expired. Therefore, non-redundant licenses are always placed after the redundant licenses. Amongst redundant licenses, aggregate overrides additive and exclusive overrides aggregate.

2.Commuter licenses
The commuter licenses properties are normal, exclusive and locked. These properties are used to decide their arrangement in the license table.

3.Repository licenses
Like commuter licenses, repository licenses are normal, exclusive, and locked. These properties are used to decide their arrangement in the license table.

4.Grace licenses
Grace licenses are not loaded in the license table if any other license for that feature-version already exists. In other words, a grace license will be loaded if that is the only license available for that feature-version. Subsequently, if any other license is added for that feature-version, the grace license will be unloaded. However, if the new license added is found invalid, the grace license will remain functional.

5.Upgrade licenses
Capacity or version upgrade licenses can be added only at the time of License Manager startup. When applied, these form a new node in the license table representing a new feature-version combination, where the feature name is same as before and only the version is different. Compare the 3rd row with the 5th row in the diagram shown earlier. For feature 3 (F3) and its higher version F3-V2, a new node is added in the license table (with licenses L7 to L9).

Use Case Scenarios for License Loading

Below are few use-case scenarios:

Scenario	Outcome
On a system where the following licenses are available: 1. L1 - Trial, exclusive 2.L2 - Normal, additive, unlocked 3.L3 - Grace license 4.L4 - Normal, Aggregate, unlocked	The licenses will be arranged in this order: L4->L2 -> L1 The grace license will not be loaded in presence of a normal/trial license.
In the standalone mode (no-net) system where only a grace license is present.	The grace license will be loaded.
A licensed application adds a standalone license (L1), when a grace license (L3) is already present.	The grace license will be unloaded and L1 will be added.
On a system where the following licenses are available: 1. L1 - Additive, redundant 2.L2 - Trial (default precedence, i.e. one), additive 3.L3 - Normal, exclusive 4.L4- Normal, aggregate	The licenses will be arranged in this order: L1 -> L3 ->L4-> L2
On a system where the following licenses are available: 1. L1 - Unlocked, normal 2.L2 - Server-locked license that matches with the system locking information, trial 3.L3 - Server-locked license whose locking information does not match with that of the system, normal	The licenses will be arranged in this order: L1 -> L2 L3 will not be loaded because of unmatched locking information.
On a system where the following licenses are available: 1. L1 - Trial license with usage exhausted, additive 2.L2 - Normal, expired, exclusive 3.L3 - Normal, exclusive	The licenses will be arranged in this order: L3 -> L2 ->L1
On a system where the following licenses are available: 1.For F1-V1 - L1 and L2 are available 2.An upgrade license for L1 is provided that upgrades V1 to V2	The licenses will be arranged in this order: 1.For F1-V1 -> L2 will be the active license 2.For F1-V2 -> L1 will be the active license

Scenario

Outcome

On a system where the following licenses are available:

1. L1 - Trial, exclusive

2.L2 - Normal, additive, unlocked

3.L3 - Grace license

4.L4 - Normal, Aggregate, unlocked

The licenses will be arranged in this order:

L4->L2 -> L1

The grace license will not be loaded in presence of a normal/trial license.

In the standalone mode (no-net) system where only a grace license is present.

The grace license will be loaded.

A licensed application adds a standalone license (L1), when a grace license (L3) is already present.

The grace license will be unloaded and L1 will be added.

On a system where the following licenses are available:

1. L1 - Additive, redundant

2.L2 - Trial (default precedence, i.e. one), additive

3.L3 - Normal, exclusive

4.L4- Normal, aggregate

The licenses will be arranged in this order:

L1 -> L3 ->L4-> L2

On a system where the following licenses are available:

1. L1 - Unlocked, normal

2.L2 - Server-locked license that matches with the system locking information, trial

3.L3 - Server-locked license whose locking information does not match with that of the system, normal

The licenses will be arranged in this order:

L1 -> L2

L3 will not be loaded because of unmatched locking information.

On a system where the following licenses are available:

1. L1 - Trial license with usage exhausted, additive

2.L2 - Normal, expired, exclusive

3.L3 - Normal, exclusive

The licenses will be arranged in this order:

L3 -> L2 ->L1

On a system where the following licenses are available:

1.For F1-V1 - L1 and L2 are available

2.An upgrade license for L1 is provided that upgrades V1 to V2

The licenses will be arranged in this order:

1.For F1-V1 -> L2 will be the active license

2.For F1-V2 -> L1 will be the active license

Reforming the Loaded License Table

There are three ways to reform the default license arrangement in a table:

1.Modify the trial license precedence

2.Seamless automatic switchover

3.Delete the currently active license

Modifying the Trial License Precedence

In general, the higher the precedence of a trial license, the higher it will be placed with respect to other licenses. A trial license with -1 precedence will be placed even before normal licenses. You can set the precedence of a trial license using the VLSsetLicensePrecedence API function. Your system administrators can modify the precedence using lslic.

NOTE The precedence setting is applied immediately.

Seamless Automatic Switchover to the Next Available Licenses

Under certain circumstances, automatic switchover takes place to the next available license, providing seamless access to your application. Such switchover is typical to additive licenses (trial and normal) whenever the first request/update call is made after 00:00 hours. The specific automatic switchover conditions are described below.

Automatic Switchover Allowed

1.When an active additive or aggregate license (trial or normal) expires.

2.When the trial period of an active license is exhausted.

3.When the precedence of a trial license is set to -1, it will become active.

4.When the precedence of an active trial license (L1) is set lower than the next available trial license (L2). Then, L2 will become active.

Automatic Switchover Not Allowed

1.The active license (trial or normal) is exclusive.

2.The active license (trial or normal) is aggregate and the next available license is additive.

3.When the next available license is expired.

4.When the trial period of the next available license is exhausted.

5.The redundant licenses do not allow automatic switchover.

Deleting the Currently Active Licenses from the License Table

You can delete the currently active license from the list to overcome these conditions:

> The automatic switchover is not possible.

>The precedence cannot be modified.

>Valid licenses are available for use.

You can do so by calling the VLSdeleteLicenseFromFile (or sntl_licensing_uninstall for Unified API-based implementations) and VLSdeleteLicenseFromFileExt API functions.

NOTE The license will not be deleted if it is currently in use.

For example, by default automatic switchover is not possible for exclusive and redundant licenses. The request and update API functions return an error when such licenses expire. In such a case, you should delete the expired license and add a valid license using the API functions.

The following code snippet illustrates how automatic switchover can be provided for an exclusive license:

int main ()
{
  ............
  ............
  /* Error on request because the exclusive license expired */ 
status = LSRequest(...);
  /* Delete the individual exclusive license */
  status = VLSdeleteLicenseFromFile(...);	
  /* Success on subsequent request. The valid license need not be added using an API function */
  status = LSRequest(...);
  ............
  ............
  return 0;
   }

The following code snippet illustrates how automatic switchover can be provided for a redundant license:

int main ()
{
  ............
  ............
  /* Error on request because the redundant license expired */
status = LSRequest(...);
  /* To delete the redundant license, the entire feature-version node	needs to be removed */		
status = VLSdeleteFeature (...);
  /* Recreate the feature-version node by adding a valid license */ 
  status = VLSaddFeatureToFile ();  
  /* Success on subsequent request */
  status = LSRequest(...);
  ............
  ............
  
  return 0;
  }

Tip:

The system administrators can delete licenses using WlmAdmin and lslic.

License Table API Functions

This section describes the license table-related API functions. Refer to Chapter 1 - Sentinel RMS Client API of the Sentinel RMS API Reference Guide for more information about the API functions.

Functions for Obtaining the Feature and License Information

1.You can obtain information about a feature-version in the license table using the VLSgetFeatureInfo API function. For Unified API-based licensing implementations, use the featureInfo query type of the sntl_licensing_get_info API.

2.You can obtain information about individual licenses for a feature-version using the VLSgetLicenseInfo API function. The function provides information such as the license model, license start date, end date, locking information, sharing information and so on. For Unified API-based licensing implementation, use the licenseInfo query type of sntl_licensing_get_info API to obtain information regarding licenses.

3.You can obtain information about the clients running the applications using the VLSgetClientInfo API function. The function provides information such as, the user name, host information, group reservation information and so on (whatever applicable). For Unified API-based licensing implementation, use the clientInfo query type of sntl_licensing_get_info API to enumerate all the licenses.

Functions for Adding Features/Licenses

1.You can add licenses for a feature dynamically (at run-time) in the License Manager table using the VLSaddFeature API function.

NOTE Upgrade Licenses (ulservrc) cannot be added dynamically to the license table. Information related to license upgrade is applied at the time of License Manager startup only.

2.You can add a license to the memory (as well as the license file) using the VLSaddFeatureToFile API function. For Unified API-based implementations, use the sntl_licensing_install_license API to add licenses dynamically.

Functions for Deleting Features/Licenses

1.You can delete a feature and its associated licenses from the memory using the VLSdeleteFeature API function.

2.You can delete a license from the memory (as well as the license file) using the VLSdeleteLicenseFromFile API function (or sntl_licensing_uninstall API for Unified API-based implementations).

3.You can delete a capacity license from the memory (as well as the license file) using the VLSdeleteLicenseFromFileExt API function.

NOTE A redundant license cannot be deleted dynamically using the VLSdeleteLicenseFromFile API function. You can call the VLSdeleteFeature API function to delete a redundant license from the License Manager's memory.