This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- FlexNet Publisher
- :
- FlexNet Publisher Knowledge Base
- :
- Why does setting LM_A_VENDOR_ID_DECLARE after a checkout fail with a -5 error?
Subscribe
- Mark as New
- Mark as Read
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
Why does setting LM_A_VENDOR_ID_DECLARE after a checkout fail with a -5 error?
Why does setting LM_A_VENDOR_ID_DECLARE after a checkout fail with a -5 error?
Summary
Why does setting LM_A_VENDOR_ID_DECLARE after a checkout fail with a -5 error?Question
Why does setting LM_A_VENDOR_ID_DECLARE after a checkout fail with a -5 error?Answer
The job license refresh is part of LM_A_VENDOR_ID_DECLARE and a few other attribute (e.g. LM_A_DISABLE_ENV).If test checkout is moved after LM_A_VENDOR_ID_DECLARE attribute setting both checkouts are successful
(LM_A_VENDOR_ID_DECLARE is being set. test checkout out of f1 ... SUCCESS. f1 checked out...)
The failure is not limited to test checkout alone and it holds good with any checkout
(f1 checked out...LM_A_VENDOR_ID_DECLARE is being set., (-5, 414) error).
To avoid this, set LM_A_VENDOR_ID_DECLARE before doing any checkouts.
Additional Information
For example:lmflex (LM_A_VENDOR_ID_DECLARE is not set)
1.Test_checkout (f1)
<<<=== connection is made here, job has a valid socket, job->daemon->server is populated in connection)
2.// lc_set_attr(LM_A_VENDOR_ID_DECLARE)
<<<==== this attribute is not set
3.Regular checkout (f1)
<<<=== Uses the same connection from first checkout because server conf->server and job->daemon->server (populated in connection) are same.
4.So, subsequent checkouts are successful.
Lmflex 1 ==> (LM_A_VENDOR_ID_DECLARE is SET)
1.Test_checkout (f1)
<<<=== connection is made here, job has a valid socket, job->daemon->server is populated in connection)
2.lc_set_attr(LM_A_VENDOR_ID_DECLARE)
<<<=== this attribute is set
<<<=== the attribute makes the job license to be refreshed so job->daemon->socket is released as part of this
<<<=== the job->socket is still retained
3.Regular checkout ()
<<<=== Since conf->server and job->daemon->server (is null now) are not same, try to attempt a new connection but this job already has a valid connection the connection routine fails with -5.
No ratings