There are several issues to be aware of when debugging your FLEXlm integrated application. Some of these are described in this chapter.
If you are experiencing problems on only one platform (or if you run on only a single platform), please check the appropriate platform-specific notes in Chapter 14, “UNIX and VMS Platform-Specific Notes,” or Chapter 15, “Windows, Win32s, and Windows NT.”
FLEXlm makes use of, and depends on, the UNIX standard I/O library and system calls. If you redefine any of the section 2 or section 3 calls, you will get unpredictable results.
The sleep(3), pclose(3), and system(3) calls do not work with FLEXlm's default use of SIGALRM. If you must use these calls, disable FLEXlm timers with LM_A_CHECK_INTERNAL set to -1, and call lc_timer() periodically.
FLEXlm installs a handler for SIGPIPE and SIGALRM. If your application uses FLEXlm timers and forks/execs another process, these signals must be restored to the default before the fork/exec, and then re-restored in the parent process. See signal(3) for details. If you fail to do this, the child process will fail with a segmentation violation, since the signal handler will not exist in the child process. This is due to the fact that the child inherits the signal handler setting of the timer, but it does not inherit the signal handler code.
FLEXlm, by default, uses SIGALRM to check the health of the connection. This cannot be tolerated by certain applications (for example, applications that use SUNVIEW or XView). These applications should set the LM_A_CHECK_INTERVAL and LM_A_RETRY_INTERVAL attributes to -1 with lc_set_attr(). After checking out a license, the application must periodically call lc_timer() to keep checking the health of the connection.
Applications that use Sunview should call notify_no_dispatch() before calling lc_checkout() and lc_timer(), and call notify_do_dispatch() after the call to lc_checkout() and lc_timer(). This is due to the fact that the SUN notifier substitutes incompatible read() and select() calls while the notifier is being used.
Applications that use XVIEW cannot tolerate the use of setitimer() or signal() calls. These applications should use the LM_A_SETITIMER and LM_A_SIGNAL attributes to install the XVIEW compatible routines in their place.
Occasionally, the time stamps in the daemon log might appear to be incorrect. This can be caused by running lmgrd in the startup script before the timezone command is executed.
If the daemon log file is missing, be sure that you are using bourne shell syntax in the startup file. In particular, do not use csh-style redirection >& in one of the rc startup files.
If the FLEXlm timers are used to perform checking and/or reconnection, non-reentrant routines can possibly be called in the C run-time library. We have verified that the routines called by the timers are free of malloc/free reentrancy problems, since these are detectable by Purify, but there may be other, especially I/O or system routines which are not reentrant, but called by FLEXlm. The only way to be certain to avoid this problem would be to disable the FLEXlm timers and call lc_timer() directly.
“License server does not support this feature”
Prior to FLEXlm v2.61, client and server could read different license files, and the actual contents of the FEATURE line (other than the feature name) was of little consequence. However, after v2.61, both the client and server need to be reading the SAME license file, since the client passes the license key from the FEATURE line to the vendor daemon. The feature name and license key must both match for the vendor daemon to hand out a license.
“Encryption code in license file is inconsistent”:
FLEXlm will report the error “encryption code in license file is inconsistent” (LM_BADCODE, -8) in a number of situations.
In general, the LM_BADCODE error occurs when:
Some data in the license file which factors into the license key (encryption code) (server hostid, feature name, feature version, expiration date, # licenses, vendor string, or encryption seed) has been changed, or
The encryption seeds in your application, vendor daemon, and license creation program differ.
If you are beginning to integrate your application with FLEXlm, this error is usually the result of not building all the software components with the same encryption seeds. Check create_lic.c, lmcrypter.c, ls_vendor.c, and your application code carefully to insure that they are all built with the same vendor code. If this is the case, you simply need to make sure that your application,
create_license, lmcrypter, and your vendor daemon have all been re-built since the last time that you changed lm_code.h, and that there is only one lm_code.h file.
The case where your software has been shipping and you encounter this error at a customer site is a little harder to diagnose. The problem in this case is usually a bad license file.
You can test to see if the LM_BADCODE return is a result of the license file or some other machine failure by running your application with the license file on two different computers, if you are using a floating license. Since the client routines in FLEXlm verify the code before attempting to connect to the server, the error message that your client reports will help to isolate the problem. Note that this test does not require the daemons to be running, so you can perform the test at your site, even if the machine specified in the SERVER line does not exist on your network.
Check the following:
Verify that the code used in the vendor daemon, your application, create_license and lmcypter are consistent.
Verify that you are not running an old copy of any of the three programs in (1).
Verify that your create_license and lmcrypter programs can re-create the license file in question.
Verify that the encryption seeds in all three programs in (1) are the codes that are in lm_code.h.
If you are using your own encryption function, make sure that there are no machine dependencies.