This section contains discussions of how to manage your licenses with RLM and how to troubleshoot common licensing problems.
Heartbeats are messages sent from a licensed application to the license server while the application has one or more licenses checked out from the server. The license server acknowledges the receipt of each heartbeat by sending a message back to the application. In this way, each side can know that the other side is up, running, and healthy, or take appropriate action if the other side is not healthy.
Step-by-step instructions on how to upgrade RLM from a demo version or from an older version.
The IBM® Platform™ LSF® Family of products has been recently updated and now includes comprehensive support for the Reprise License Manager (RLM).
Reprise Software is pleased to announce that JTB World has added support for RLM into its suite of license usage reporting tools.
These tools can be used by you or by your customers to monitor historical usage for departmental charge backs or usage-based pricing models.
You can find out more here:
https://blog.jtbworld.com/2014/04/jtb-flexreport-80-adds-reprise-license.html
Please contact JTB World directly for more information.
This question often comes up. The general question is, how is backward compatibility handled in RLM?
On the license server side, the rules we have always followed (and we expect to always follow in the future), are these:
So, for example, let’s say you have an application that is built with RLM v7.0. This application will work with any of these combinations of servers:
There is one caveat to this general rule, and it applies to ISVs who ship server settings files rather than server binaries. A server settings file allows the ISV to specify the newest and/or oldest version of RLM with which it will operate. By default, they operate within the rules outlined above, but the individual ISV can override this. So the instructions from your ISV (if they use settings files) will always override these general rules.
What this means, in practice, is that if you have a multiple-ISV RLM installation, you can always take the newer copy of rlm and ISV server from one of your ISVs and use it with the older ISV server from your other ISV(s). However, if you use the command-line RLM utilities (instead of the preferred web interface), we only guarantee that the version of the RLM utilities corresponding to the oldest ISV server will work.
On Windows, RLM sometimes fails to start the ISV server with a select(), getsockname() or “communications (socket) problems” error. This is a very uncommon problem, but the simple fix described below will correct it.
Reprise has had reports on a very limited number of systems that RLM fails to start the ISV server, with errors similar to the following written to the debug log (note: the ISV name will be your ISV name, not “demo”):
03/16 04:12 (demo) select() failure: Unknown error
03/16 04:12 (demo) Out of file descriptors: Cannot clone communications handle: Unknown error0
3/16 04:12 (demo) Too many errors on main socket, exiting
This error sometimes results in debug log output similar to the following:
01/06 10:11 (rlm) Starting ISV demo
01/06 10:11 (rlm) Error in getsockname() call 13
01/06 10:11 (rlm) … demo on port 57809
01/06 10:11 (rlm) New thread created to watch ISV demo
01/06 10:11 (rlm) demo initialization error: 1, not restarting
Or the following:
01/05 12:50 (rlm) Starting ISV servers:
01/05 12:50 (rlm) … demo on port 1088
01/05 12:50 (rlm) New thread created to watch ISV demo
01/05 12:50 (rlm) demo – communication (socket) problems
This problem is caused by a registry corruption (not induced by RLM) that affects some network operations. The fix is to open a command window and type the command:
$ netsh winsock reset
Should the above “netsh” command not solve the problem, Microsoft has published the following article on how to correct the registry when this occurs. Note that the error message indicating the problem is different in the article than the RLM error message indicating the problem, but the underlying cause is the same.
https://support.microsoft.com/default.aspx?scid=kb;en-us;817571
Sometimes it is desirable for the RLM server to be behind a firewall. RLM supports this, but there is a small amount of configuration that you will have to do to use RLM across a firewall.
If you have a firewall installed on the server node which is not allowing your application to access either the rlm port, or the port of the ISV server you must first configure your firewall to allow access to both the main rlm port, as well as the ISV server port. To do this, perform the following steps:
ISV isvname port=isv-port# (if you have RLM v9.0 or later), or
ISV isvname isv-binary isv-options-file isv-port# (if you have pre-v9 RLM)
Note: you can find this information in the RLM License Administration Manual on the Reprise Website.
On Windows, RLM stores persistent data in the “system_drive:”\Documents & Settings\All Users\Reprise directory.
If your system is set up such that permission to this directory is denied for non-admin users, then non-admin users will not be able to create (or use) rehostable licenses.
If this is the case, login to the system as an administrator and set the permissions so that all users can read and write to this directory.
Note that you might see a similar error when using a roaming license or when attempting to start the license server.
Also note that deleting, copying, or otherwise modifying this directory will lead to problems later.
Whenever this happens, it is because someone is used to the way that FLEXlm configures redundant servers.
The reality is this – RLM and FLEXlm work differently with respect to server failover, and the RLM method is easier for the end-user to configure, while providing the same amount of server redundancy. In a FLEXlm redundant-server configuration, a little-known fact is this:
the third server can never serve licenses
This is because, in FLEXlm, 2 of the 3 servers must be running to have the system operate. So, either servers 1 and 2, 2 and 3, or 1 and 3 must be running. And FLEXlm (at least until version 10.?) always picks the server whose name is first in an alphabetical sort (we know, we wrote the code). So the server with the last name, alphabetically, will never serve licenses.
By contrast, with RLM, you pick a primary license server, and a failover server. If the primary goes down, the failover takes over. There is no 3rd server to configure. There is no situation where 3 FLEXlm servers would serve licenses that RLM will not serve licenses (assuming RLM is configured on 2 of the 3 FLEXlm servers). In other words:
adding a 3rd RLM server buys you nothing, other than extra administrative overhead
