Troubleshooting and FAQs

Question: Is it necessary to generate alerts?

It is recommended to generate alerts because it acts as an aid for your customers. A timely alert also helps them in managing their licensing decisions better.

Question: Is it possible to reuse a volume transaction license?

A volume transaction license can be reused even if the maximum allowable limit is exhausted, provided the application resets the limit count in the volume transaction license database. This can be done by using the VLSsetConsumeLimit API along with the VLS_RESET operation type.

Question: Does a standalone application need to call the sntl_persistence_create API function to initialize the volume transaction database persistence?

Answer: Yes. A standalone application needs to call the sntl_persistence_create API function to initialize the volume transaction database persistence on a system. The API can be called when the application is installed. Refer to the Sentinel RMS API Reference Guide for more details about the sntl_persistence_create API function.

Question: What will happen if a new exclusive license with a different alert level or overdraft level is installed?

You need to again retrieve the new policy for this license using the VLsgetLicenseInfo API function. Further, use this new information in your application. For Unified API based licensing implementations, use the licenseInfo query type of sntl_licensing_get_info API to retrieve this information.

Question: What will happen if another additive license of similar feature/version with a different alert level or overdraft level is installed?

The initial call to the VLSsetConsumeLimit API function creates a record using the license hash of the highest priority license (that is, the first indexed license for a particular feature-version). In such scenarios, you need to keep a track of the particular volume limit and policy enforced using the VLSgetLicenseInfo API function.For Unified APIbased licensing implementations, use the licenseInfo query type of sntl_licensing_get_info API. Such a software vendor specific identifier helps to identify the license and corresponding volume limit/information.

Let us Consider the following scenario:

Two standalone additive licenses of same feature version (F1, V1) combination are added/loaded in the following order:

1.License #1 (hash = D8DE00BA35C6D3EF) - F1, V1, expiry date 31 October 2008, and the private vendor information as V:500:50:100.

2.License #2 (hash = 66BA0C0951CE1F69) - F1, V1, expiry date 31 December 2008, and the private vendor information as V:1500:100:200.

Since both these licenses are additive, together they form the feature node in the license table. So, license #2 has higher priority due to the later expiration date. However, only private vendor information of License #1 (that is, V:500:50:100) is obtained when:

•Unified API: The featureInfo query type of the sntl_licensing_get_info Unified API is called.

•Traditional API: The VLSgetFeatureInfo API function is called.

The sequence of operations can be as follows:

1.The application needs to call the VLSgetLicenseInfo API function and use input parameter license_index to enumerate all the licenses for feature F1, V1. For Unified API based licensing implementations, use the licenseInfo query type of the sntl_licensing_get_info Unified API.

2.Identify the license which has the correct volume information/policy which should be enforced.

3.Request the license and obtain a handle.

4.Call the VLSgetConsumeLimit API function using the handle obtained in step #3. As no record yet exists in the volume transaction database, the API returns failure.

5.Perform some business logic using the currently enforced policy.

6.Call the VLSsetConsumeLimit API function (using the requested handle) to set the consume limit value in the volume transaction database. This API function creates a record using the license hash of license #2 (that is, 66BA0C0951CE1F69).

Question: Can asynchronization problems occur when multiple clients are concurrently accessing the volume transaction database of a standalone application (for example, via terminal clients)?

Yes. You can counter these issues by implementing synchronization through the context data field (of the VLSsetContextData and VLSgetContextData API functions). For example, a client can set certain “lock” context in the context data field. Once set, the client can perform further updates to the counters, and so on. Other clients should wait until the “lock” is cleared before setting other fields. To strengthen this solution against failures (for an application crash where the client would not know if the lock is obtained or not), you can maintain a temporary file such as a temporary lock file, file.lck, which indicates if the lock is set or cleared.