IBM LUM i4blt command reference


Even though the IBM LUM license monitoring tool has decreased in popularity over the passed several years, it is still a widely spread tool for monitoring and tracking license usage of many CAD applications.

The OpenLM license monitoring tool extracts information from a variety of license managers, such as Flexnet / FlexLM, DSLS, Sentinel HASP, Sentinel RMS, Reprise RLM, and – of course IBM LUM. OpenLM extracts comprehensive license reports and obtains license statistics for all these lisence managers.

In order to interface the IBM LUM license manager, OpenLM employs the i4blt command.
The i4blt command is very versatile; its usage depends on the attached i4blt flag options. The following document is a reference to some of these flags.


There are several syntax rules to be met:
1. Named strings containing spaces must be presented within single quotation marks.
2. Names are case sensitive
3. Listed values must be presented within double quotation marks, e.g.:
i4blt -lp -n my_server -v “‘Vend A’ ‘Vend B'”
4. Parameters that appear within options are position specific, e.g.: vendor information in the i4blt -E (Enrollment) option include vendor_name, vendor_id, and vendor_password.

Command reference

The following diagram is a reference to some of the main i4blt options. The Yellow rectangle is a complete reference to the primary i4blt command options. the turquoise rectangles contain elaboration for some of these primary options.

Usage examples:

The following are usage examples of the i4blt command. The examples are taken from real workstations, and include genuine usage information. They were cleared of any user identification markings.

i4blt -s -lc

In order to obtain current license usage information, OpenLM employs the i4blt -s -lc option.

i4blt -ln

The list display option with the ‘n’ flag lists the servers which are monitored by the IBM LUM.

i4blt -r1 -e

The r1 report type enables the extraction of  further information. This example shows license related event logging, in this case: license release.

Forward reading

I have found the following links helpful:
From the University of Alberta

A bit about HAL (High – Availability licensing) : i4blt -H.

Multiple Server license management constellations

Flexera’s FlexLM (Flexnet)Three Server Redundancy (Triad)

IBM’s High Availability Licensing (HAL)

Dassault Systemes DSLS cluster for “Failover” mode


License management tools such as IBM and Flexera both a method of employing multiple license servers in a cluster as part of their attempt to assure a fault-free license management solution. This article summarizes the operative measures required for implementing each of these solutions, and attempts to compare them in terms of pros and cons.

The OpenLM Utilizer license monitoring tool supports both configurations. OpenLM is designed to extract license statistics from multiple servers over WAN. It has been tried and confirmed for Flexera’s Triad configuration. At the time of writing this revision (Rev 1.0), It has not yet been verified with the IBM LUM HAL.

Flexera’s Three Server Redundancy constellation


The Flexnet constellation is consisted of Three license servers, all inter-connected by TCP/IP. These machines are adequately named “Primary”, “Secondary” & “Tertiary”. Any one of the two first machines (Primary or Secondary) may be defined as the “Master”; which is counter intuitive, as it gets to do all the work while the other two basically sit on their hands. All licenses are served by this Master machine, and the Report & Debug logs are also accumulated by it.

Upon system start-up, the three FlexLM license servers are started up separately according to their order, and the Master role is set according to this order or according to a designated flag: “PRIMARY_IS_MASTER”.

The  FlexLM license Servers inter-communicate by a “Heartbeat” messages over TCP/IP, using the same port number. A machine which fails to receive a response to its sent Heartbeats turns down the vendor daemon and can not serve licenses. When the Master server (Primary or Secondary) fails, the Master role is passed to the other (Secondary or Primary) server. The new Master assumes the license management role for all the FlexEnabled applications, and accumulates new Debug and Report logs.

Configuration of a Three Server Redundancy constellation:

  • First, a set of three stable machines needs to be identified, and reliable communication needs to be set between them.
  • The software vendor must receive the HostID and Host name of the machines that consist the Triad. In return, they should provide system – specific license server files. Some changes may need to be done in the license file according to this new information, such as the PRIMARY_IS_MASTER value, the communication port number and the HEARTBEAT_INTERVAL which is effectively the timeout for license servers to be knocked out of the triad.
  • The license server package needs to be copied to each of the three participating servers.


  • There should always be at least two machines up and running. If any two machines halt – then the Triad is stopped as a whole, and no “FlexEnabled” applications are served. This is quite an odd limitation, as the system basically employs a single machine at a time anyway.
  • The “Tertiary” machine never gets to play “Master”. I find this an odd planning, because this in effect renders this machine useless.
  • This configuration puts a strain on one machine at a time. It does not share the work, and is prone for errors especially in busy environments.

IBM’s High Availability Licensing (HAL)


The IBM HAL is based on the “License server Cluster” concept. A cluster is a group of 3 to 12 license servers, that jointly manage licensed applications. The management activity load is dynamically and equally shared among most of the servers, while one or two other servers remain on-hold, waiting to pitch in in case an active server becomes unavailable.
Network license servers that participate in a cluster can simultaneously serve server-bound licensed applications,  as well as cluster bound applications.

Configuring HAL

  • Select a set of interconnected license servers as cluster members. These members need to be stable machines, that stay on permanently. Network stability is also crucial in order to assure faultless system activity. It is recommended to maintain the machines in the same geographical vicinity, and that they all run the same operation system type.
  • Instal LUM on each of the license servers.
  • Create the cluster from one of the servers in the cluster. This may be done using the i4blt -H command or the GUI. In the following example, cluster ThisCluster was created, and it contains 3 servers: Server1, Server2 & Server3.
    • i4blt -H c -N ThisCluster -T 3 -n “Server1 Server2 Server3”
  • Activate each member of the cluster. The 1st member is already enabled by default following the cluster definition. This example enables Server2:
    • i4blt -H a -N ThisCluster -n Server2

In order to Deactivate a Server2, use

  • i4blt -H a -N ThisCluster -n Server2
  • Get a HAL Enrollment Certification File (ECF) from the license vendor. In order to do so, You must send him the “Cluster ID”. This ID can be obtained by typing in the status cmmad:
    • i4blt -H s -N ThisCluster.
  • Enroll the HAL ECF just like as for regular license servers, using the GUI or the i4blt command line. for example:
    • i4blt -a -n ThisCluster -f <ECF> -T <NumberOfLicenses>
  • Configure all clients to recognize all the cluster members.

Dassault Systemes DSLS

The DSLS license manager also implements a cluster structure, for “Failover mode”. Its characteristics are a mix of the two types mentioned above;

  • A server may not perform as part of a cluster AND as a stand alone server at the same time.
  • The number of license servers that participate in the cluster are exactly 3.
  • The OS on each server may be either Unix or Windows.
  • At least two machines should be up and running, and interconnected  in order to serve licensed applications.
  • There is no ‘Master’ here: all machines have the same role of license management.
  • The three machines each log the license activity independently. They update each other when usage conditions change.


It seems that the IBM LUM solution for multiple server constellations is more comprehensive than that of Flexera’s. Its main ‘Pro’ characteristics include:

  • Equal sharing of the workload.
  • Dynamic redistribution of license management as a function of server availability
  • Configurable amount of servers; a maximal 12 server constellation, in comparison to 3 (effectively 2) Flexera servers.

The main ‘con’ on the IBM LUM list is its lack of popularity in comparison to Flexnet (FlexLM). This has manifested in a trend of licensed application vendor’s migration from LUM to various other license management tools, e.g. FlexLM and DSLS.


Further Reading:

Trouble Shoot Form: Broker Item 003 (LUM licenses don’t show up in EasyAdmin)


Title LUM licenses don’t show up in EasyAdmin
Category Broker
Date Nov 11, 2011
Handled by
Relevant Links
Applies to license managers LUM
Applies to license model Floating licenses, Network licenses, Concurrent licenses, Node Locked
Symptoms LUM licenses don’t show up in EasyAdmin.
Observed during dubug 1. The Broker was not sending any information to the OpenLM Server
2. The Broker “test connectivity” button clicked: Broker saw the OpenLM Server OK.
Trouble shoot process 1. Upgraded Broker version.
2. Changed the I4BLT.EXE path from the OpenLM folder to one supplied by the application vendor.
Solution Found (Found/Pending/Known Issue)


LUM licenses don’t show up in EasyAdmin.


1. Upgrade the OpenLM Broker on the license server machine. Refer to the Application Note for reference.
2. As part of the OpenLM package, the latest version of the I4BLT.EXE file is supplied. This file may not be inter-operable (version too new) with the licensed application version. If this is the case, please follow these steps:

Changing a single port’s configuration

  1. Open the OpenLM Broker configuration tool.
  2. Select the relevant License server.
  3. Check the “Update to the following path” radio button
  4. Click the “Edit” button. The text box becomes active.
  5. In the “Path” text box, type in the path of the I4BLT.EXE file in the LUM folder, originally supplied by the application vendor.

This configuration change may also be achieved by individually typing the I4BLT.EXE file path in each Broker command text box.

Changing all ports’ configurations

  1. Open the OpenLM Broker configuration tool.
  2. Click the “Advanced Settings” wrench icon. The Advanced settings window opens.
  1. Click the “Edit” button. The text boxes become active.
  2. In the “I4BLT Path” text box, type in the path of the I4BLT.EXE file in the LUM folder, originally supplied by the application vendor.
  1. Select a specific port’s “Commands” list item. The “Commands” window opens.
  1. Check the “Update according to advanced settings” radio button, and click the “Update” button. The I4BLT path of the specific port is changed.
  2. Repeat steps 5 & 6 for all ports.