The IBM® Platform™ LSF® Family of products has been recently updated and now includes comprehensive support for the Reprise License Manager (RLM).
JTB World adds RLM support to its Usage Reporting Tools
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:
Please contact JTB World directly for more information.
RLM Backwards Compatibility: Is RLM v10 backward compatible with RLM v8.0?
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:
- You can always use a newer version of rlm with an older ISV server
- You can always use a newer version of license server (both rlm and the ISV server) with an older client (application)
- You can, of course, always use the same version of application and license server.
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:
- rlm v10.0 and ISV server v7.0 thru v10.0
- rlm v9.0 and ISV server v7.0 thru v9.0
- rlm v8.0 and ISV server v7.0 thru v8.0
- rlm v7.0 and ISV server v7.0
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.
Sometimes RLM Roaming won’t work on a Windows system.
We now have a facebook page that we are using for hints and tips for all users of RLM-based products. We will post new hints there first and may not post them here any longer.
The facebook page is at:
If you like the page, you’ll get updates when we post. We are aiming to post something new about once/week.
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.
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:
- In your license file, look at the SERVER (or HOST) and ISV lines:
- SERVER server-hostname server-hostid main-rlm-server-port# (Note: the keyword HOST is equivalent to SERVER)
- ISV isvname
- Add the desired port # to the ISV line as follows:
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)
- Next, configure your firewall to allow access to both isv-port# and main-rlm-server-port#
- Make sure that the license file is updated on the server node, and that the client nodes know how to find rlm – either with a license file with the SERVER line above, or by setting the RLM_LICENSE environment variable to main-rlm-server-port#@server-hostname
- Re-start rlm – you must restart RLM in order for any port changes to take effect. Restarting the ISV server via the web interface or rlmreread does not restart RLM.
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.
The question often comes up – “I am used to failover servers configured in a triad (3). Why can’t RLM support this?”
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
What do you do when you get a message saying “application cannot connect to license server”?
Sometimes, after completing the installation of your new software, the application refuses to run, giving you a “Can’t connect to server” error. When this happens, the error message will look similar to the following:
Usually, this means one of the following has happened:
- The license server is not running
- The hostname or port # on the application’s computer doesn’t match where the license server is actually running
- The license server (rlm) is running, but the ISV server for your application isn’t running for some reason
- A firewall is blocking access to rlm or the ISV server
- The license server machine is down
The first step in diagnosing this problem is to find out where the application thinks the license server should be running. The most accurate way to do this is to use rlm diagnostics with the application. Since RLM v8.0, every application which uses RLM has built-in diagnostics. The procedure for running diagnostics is described in this article:
Once you know the hostname and port of the license server, you should log in to that host and verify if the license server is running. You should see one process for the “rlm” generic server and a second one for your ISV server. Depending on whether the ISV server is a binary or a settings file, the process listing will be a bit different. On Unix systems, for an ISV server implemented as a settings file, the two process will look similar to the following (this is for the “reprise” ISV server):
For an ISV server binary, the output will look more like this:
In the windows task manager, you will see either 2 rlm processes or 1 named rlm and one with the name of your ISV server:
- If you can find rlm running, but not your ISV server, you will need to look at the debug log from rlm to see why the ISV server isn’t running. The simplest way to do this is to run rlm in a command window (on Windows) or from the shell on Unix. Go to the directory where the license servers are installed, and run the command “rlm”. If the problem is not apparent from the output of rlm, you should contatact the ISV who supplied your software – they should be able to help you get the servers running.
- If both rlm and ISV servers are running on the server node, the problem could be that either 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. If this is the case, configure your firewall to allow access to port “xxx”, and you can configure RLM to use a fixed port number for the ISV server by specifying the ISV server port, xxx, on the ISV line as such:
ISV isvname port=xxx (if you have RLM v9.0 or later), or
ISV isvname isv-binary isv-options-file xxx (if you have pre-v9 RLM)
If you see another cause of this problem, or have a different solution, please leave a comment.