Working with Grace Licenses

A grace period enabled RMS license is used like any other network license. When a user obtains such a license on the network, the grace licensing information is automatically stored on the local system without any need for user interaction.

NOTE   To allow use of grace licensing, the application must have successfully obtained the license at least once over the network.

After this, whenever the application is launched and a license token is not available on any License Manager within the same subnet, the locally installed grace license is requested successfully. If a grace enabled network license of same feature is available on any License Manager, the use of grace license would be denied and error VLS_NO_SUCH_FEATURE returned.

Once the grace license is in use, the grace period countdown begins only from the first usage in the disconnected state (the calendar days are not measured in absolute manner). Then onward, the application can be used for the given number of hours (seconds) within the calendar days specified. Once the grace period is redeemed, the application can be used till the grace period days or hours limit is reached. On the next successful network license request, the grace period is reset.

NOTE   For a grace enabled license, the contact License Manager sets switches from standalone (no-net) to network mode and vice versa, depending on how the license token is obtained. For example, when the license has already switched to a grace license, the contact License Manager will be set as "no-net". This is because the license token is now obtained from the local system.

Figure 1: Using a Grace License

An Example

>John uses the application on his laptop on a Friday during office hours, after obtaining a license from the network License Manager.

>He launches the application again at home on Saturday. The application executes because the license has the following grace period associated with it:

>Maximum days = 2

>Maximum hours = 4

As a result, he can successfully run the application altogether for 4 hours up to the end of Monday. Later when John launches the application on the office network, the application grace period is reset.

Network License Restoration During the Grace Period

A grace license is meant to provide continued application access in cases such as network downtime. Meanwhile, it is possible to check whether the network license is restored or not on any License Manager within the subnet. If a license token is available, the application seamlessly switches from grace to network license. If the license is not obtained, the application continues to run till the end of the grace period.

NOTE   Prior to v8.4.0, when a grace license was under use, no check was made for license token availability on the network while the grace period lasted. Now, you can alter this behavior so that a periodic check is made for license token availability.

This can be done by calling the LSUpdate API in the following manner. Its second parameter, which was unused till v8.4.0, is replaced by ulGraceSwitchToNetworkTm. Using this new parameter, you can configure a time interval after which the LSUpdate call will look for a license token on the network. If a license token is obtained, the application switches from grace to network license. Refer to the Sentinel RMS API Reference Guide for more details about using the API.

If you are not calling the LSUpdate API (or sntl_licensing_refresh_attr Unified API), the default auto-update mechanism in your application automatically contacts the License Manager after every 10 minutes (for license renewal purpose). The license, if available, will be restored in this process.

NOTE   Starting RMS v9.2.0, the client can switch from grace license to the corresponding network license (through LSUpdate) even in the case of IPv6 environment (when the client License Manager communication is set to be in IPv6 format only).

Ignoring Grace License in Standalone Environment

Prior to RMS v8.4.0, the application looked for a grace license even when no-net was explicitly set (either in the VLSsetContactServer API/SNTL_ATTR_APPCONTEXT_CONTACT_SERVER attribute of the sntl_licensing_app_context_new Unified API, or via LSHOST or LSFORCEHOST environment variables).

However, with RMS v8.4.0 (and later), the libraries include a new API (VLSsetGraceRequestFlag) that you can use to enforce search for a standalone license. The Unified API based licensing implementations can use the SNTL_ATTR_APPCONTEXT_REQUEST_GRACE attribute of the sntl_licensing_app_context_new API to enforce search for a standalone license.

If a license is not found on the standalone system, error 18 (SNTL_NO_SUCH_FEATURE) is returned without resorting to the grace period. Though in network mode, the grace license would be available for such a license.

Another API, VLSgetGraceRequestFlag, obtains the status if the grace license request is enabled or not when the contact License Manager has been set to standalone mode (no-net). The Unified API based licensing implementations can get this information using the (requestGrace field included in the) appContextInfo query type of the sntl_licensing_get_info API. Refer to the Sentinel RMS API Reference Guide for more details about using the API.

Suppressing Network Broadcast for Network License Restoration

If required, you can prevent the broadcast calls looking for a License Manager in the subnet. This is helpful when you want to avoid the extra overhead of looking for a grace license using network broadcast. The application continues to run using the grace license until the next update call or auto-update operation to renew the license (once the license is renewed successfully, the application switches from grace to network license).

To do so, the following options are provided:

>Using the Traditional API: The new additional value (VLS_DISABLE_GRACE_BROADCAST) can be used to pass the ‘special_flag’ parameter of the VLSrequestExt2 API.

>Using the Unified API: The SNTL_ATTR_LOGIN_DISABLE_GRACE_BROADCAST key of the sntl_licensing_login_attr API.