View Full Version : lc_borrow_return issues

04-27-2009, 11:28 AM
I'm currently using FlexNet 11.6.

I cannot return borrowed licenses back to a server. I try to do so through both LMTools and through my application, and the licenses are not relinquished.

I attempt to return licenses in my application via:

lc_borrow_return(job, featureName, NULL)

What exactly is the third argument, this display argument? And why aren't the licenses being returned? Am I missing something?

Any help would be appreciated.

04-27-2009, 12:50 PM
What is the return code from lc_borrow_return? For a sanity check, the first thing to verify is that the vendor daemon was built to support early return (with ls_borrow_return_early in lsvendor.c); by default it's not enabled.

(The display is one of the three client identifiers a checkout reports: the user name, host name, and display. On Windows clients it's the same as the host name. FuncRef-c.pdf and ProgRef-LF.pdf have a bit more information.)


04-27-2009, 01:24 PM
The return code on lc_borrow_return is 0.

I just updated to 11.6 recently and, well, the toolkit has been cleaned and built. This issue has been long with standing for some time, even with the previous versions of FlexNet. I must be missing something....

The following files were modified to support returning borrowed licenses early:

int ls_borrow_return_early = 1; /* Set to 1 to allow users to return borrowed licenses early */

#define LM_BORROW_OK 1

04-27-2009, 02:57 PM
How are you initiating the borrow? Using lmborrow, for example? Does the server debug log give any response?

04-28-2009, 10:01 AM
Through my application I am calling:

lc_set_attr(job, LM_A_BORROW_EXPIRE, dateString);

(Where dateString is some date specified by the user).


lc_checkout(job, featureName, version, 1, LM_CO_NOWAIT, &code, LM_DUP_HOST)

LMTools says there is a license borrowed after performing this in my application. I can disconnect that computing node from the server and the license will last until the borrow expires.

When connecting that node back with the server and attempting to interact with LMTools or calling lc_borrow_return from my application, LMTools never returns the borrowed license.

I do not use the lmborrow.exe utility.

04-28-2009, 02:06 PM
As a test, does a hard-coded date, etc., work? In a copy of lmflex.c, I use this to initiate the borrow:
char borrowexpire[] = "29-apr-2009:13:00";

/* license is---

SERVER this_host ANY
INCREMENT B1 demo 1.0 1-jan-2010 10 VENDOR_STRING="Greetings from B1 \
version 1.0!" BORROW SIGN=... */

(void)lc_set_attr(lm_job, LM_A_BORROW_EXPIRE, (LM_A_VAL_TYPE)borrowexpire);

if (lc_checkout(lm_job, "B1", "1.0", 1, LM_CO_NOWAIT, &code, LM_DUP_HOST))
{ /* etc. */ }
and this for return:
lc_borrow_return(lm_job, "B1", NULL);and all seems to work...


04-29-2009, 10:38 AM
One problem that I had was that my date/time picker was in civilian time, so borrowing after 12 noon was not possible.

Borrowing works, however, there are just some peculiar elements of the borrowing process I'm not particular fond of...

For instance: When I borrow from my application, the server (LMTools) rarely reports the correct information back when clicking on the Borrowing tab->'List Currently Borrowed Features' button.

Let me ask this though...if I return a license early...the license is returned to the license pool, but does that mean the application is still usable until the borrow expires?

04-29-2009, 10:59 AM
If the borrowed license is returned early, the heartbeat functionality in the app will check the license back out from the server (after two minutes or so, by default); if the server becomes unavailable, after the retry-count number of missed heartbeats (by default 5), the application will report an error such as error -13, LM_NO_SERVER_IN_FILE, "Lost license, cannot re-connect..."


04-29-2009, 04:01 PM
Seems like every time I call lc_borrow_return after checking out a license...I always get the following error codes (in this order) after each lc_borrow_return call:

-7 No socket connection to license server manager service.
0 ???
-124 Error returning borrowed license.

Then the application thinks that the license available is a node-locked license until the borrow date is reached. Also, any attempt to connect to the license server after the borrow...config will only return licenses that are node-locked. It's really weird and frustrating.

Any thoughts?

04-30-2009, 10:23 AM
In what way does the application think the borrowed license is a node-locked license? And how are you trying to connect to the server again after the borrow?

Not that it should matter, but is lmgrd/lmadmin running as a service? If so, does it make any difference if you run it manually (which is how I ran my test)?

04-30-2009, 12:01 PM
After a borrow, I'll close down the application. I will then start the application up again, and everything works fine. Even when I disconnect from the network. The license is borrowed.

If I connect to the network and attempt to register a new license, and say, I specify the same server that I borrowed the license from...config->lc_from_server will return 0 every time I attempt a checkout. It will do so until the borrow time expires.

If I return the borrowed license early...and attempt to get a license from the same server I borrowed from...config->lc_from_server will return 0 every time I attempt a checkout. It will continue to do this until the borrow time expires. Also, the license is returned back to the server...it's just that the client is acting funky. I don't know why I was getting weird error codes earlier.

Also, I am not running lmgrd as a service. I'm starting it up from LMTools.

When lc_borrow_return returns a status of 0...does that mean it was successful?

04-30-2009, 01:55 PM
A borrowed license is node-locked, in a sense; perhaps check config->borrow_flags to see if it's borrowed? A quick test shows config->lc_from_server being 1 when the license is first checked out to trigger the actual borrow operation, and 0 for subsequent checkouts during the borrow period; but config->borrow_flags being 1 in both cases.

But yes, lc_borrow_return returning 0 is supposed to indicate success...

06-02-2009, 11:37 AM
Here is the issue I'm still seeing:

When returning a borrowed license from my application back to the license server, lc_borrow_return returns 0. That's good as it means the borrowed license was returned successfully. Checking the license server status, it seems as if the borrowed license was, in fact, returned.

The problem is that the application still believes it has a borrowed license. I attempt to restart the application, but every time it gets a valid borrowed license even if the client isn't connected to the network.

When I investigate config->borrow_flags, it is 1 until the expiration date expires.

Is there anything else I could investigate?

06-03-2009, 02:33 PM
I've found that you need to create a new lm_job to return the key. Then back on your original job you need to do an lc_checkin.
Doing a return from the same job that did a checkout never seems to work correctly.

06-04-2009, 09:32 AM
I've found that you need to create a new lm_job to return the key. Then back on your original job you need to do an lc_checkin.
Doing a return from the same job that did a checkout never seems to work correctly.

I cannot confirm this suggestion. It seems like the lc_borrow_return is successful on the new job, but the lc_checkin does not relinquish the license when called from the job that did the checkout. The client machines still thinks it has a node-locked license.

Thanks for the tip though, but it did not work for me. Perhaps I'm doing something wrong?

06-05-2009, 08:36 AM
I've also found that you can't actually return from the same job that did the initial borrowing. So in my case if I exit my application and restart it (so that my lm_job gets a borrowed key) then the return and checkin will do the right thing.

11-08-2011, 08:51 AM
I realise this thread is a couple of years old but I thought I'd add my findings after my recent pain with borrow.

I've been developing an application to support borrow with FlexNet Publisher v10.8.7.0 and v10.8.10. v10.8.10 is meant to be the same as v11.8 functionally.

Several problems I found (some of which are documented in various Release Notes) are:

Before v10.8.8.0, registry borrow keys weren't always null terminated, so early borrow return would fail in an application or when using the lmborrow -return command line

I wouldn't get a crash if I returned licenses in a particular order with lmborrow, starting with ones with the shortest feature name (6 letters)
I would clean up my registry after I perform early borrow return to remove any leftover registry borrow keys from my product
I would also clean up keys before I borrow my product, in case keys were left behind from an expired borrow
I won't have to do this when I'm only using v10.8.10 or newer, I hope.

You must sleep or wait for at least 5 seconds (varies from system to system) after setting your borrow expiry date if set via the LM_BORROW environment variable so the Flex libraries borrow the first license you checkout, instead of treating it like a normal license.
Each job handle apparently generates a unique borrow key (which I think is part of the borrow registry key name) unless when the FNP library is built, -bfixed is specified for lmnewgen generating the lm_new.o object file.
One application cannot lc_borrow_return the license feature checked out by another application, probably because of the unique borrow key in the previous point.