cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

License return failed as licenses are DUP_VENDOR enabled

License return failed as licenses are DUP_VENDOR enabled

Symptoms:

User cannot return borrowed license early even though ls_borrow_return_early has set to 1 in lsvendor.c file. 

Diagnosis:

Try to find if the client code has been set dup_code = LM_DUP_VENDOR and then getting the following error when returning a borrowed license early, shows the error

"lmborrow: Error, borrowed license doesn't match any known server license. (-128,595)"

Also in the vendor daemon logs :

14:12:36 (test) OUT: "f1" root@revenera

14:13:05 (test) Warning : License return failed as licenses are DUP_VENDOR enabled

Solution:

This is a known limitation of FNP, and you can find the document which we have added the warning in "FNP_11.17.0_ReleaseNotes.pdf" under page#4

DUP_VENDOR with Borrow Return:-
Added “Warning: License return failed as licenses are DUP_VENDOR enabled” in the server log when borrowed DUP_VENDOR enabled license return fails.

The reason that this feature is not supported in any release is because of the potential for both license leakage and license loss if allowing dup_grouping with borrow return.

License Loss:
The same job handle can check out the same feature twice with different vendor data, say f1 + VD1 & f1 + VD2. This will result in a count of two licenses being deducted from the server. If we were to allow an early return, then when f1 + VD1 is returned, the client loses f1 + VD2 too, but the server increments back only one license.

License leakage:
If two clients from different machines check out f1 + VD1, then on the server just one license is consumed. If the client1 does an early return, client2 still has f1 checked out.

This is why FNP does not allow early return when using LM_DUP_VENDOR.

Also worth check the KB: (-128,595)

Was this article helpful? Yes No
No ratings
Version history
Last update:
‎Jan 13, 2022 01:59 AM
Updated by:
Contributors