TOC INDEX

Chapter 1
Welcome to FLEXlm

FLEXlm® is the de facto standard network license manager used by over 2000 leading software vendors to control the use of their software products. If you are a system administrator or user, chances are one or more of the products currently on your network is licensed by FLEXlm.

This manual explains FLEXlm from an end user standpoint and describes how to use the tools which are part of the standard FLEXlm distribution kit. GLOBEtrotter Software also provides the SAMsuite™ asset management tool for more advanced license server control and reporting. Please contact GLOBEtrotter Software by email at info@globes.com or on the Internet at http://www.globetrotter.com for more information about SAMsuite.

Keep in mind that certain topics (such as password encryption) are vendor-specific and proprietary so we cannot document them in any detail. Also, because FLEXlm does not enforce a particular licensing strategy, each vendor's implementation can have subtle differences. If you do not find out what you need to know here, you should contact your vendor's technical support group.

1.1 Versions of FLEXlm

This manual covers features of interest to license administrators and end users in FLEXlm versions 1.0 through 7.2.

1.2 How to Use This Manual

This manual is written for two different audiences: the license administrator and the end user.

1.2.1 License Administrator

If you are a license administrator, read these chapters:

This chapter: Explains:
Welcome to FLEXlm
FLEXlm basics: license manager and vendor
daemons; the license file; configuring
FLEXlm; the license request process.
The License File
The license file format; setting the path at
start-up; different types of licensing policies.
Multiple License Files
Using license files from independent
software vendors.
Selecting Server Nodes
Selecting which machines will run the
license servers; resources required by the
servers; multiple servers; quorums;
redundant servers.
The Options File
Creating and editing the options file.
License Administration
Tools
Managing FLEXlm using GLOBEtrotter-
supplied utilities.

In addition, you can refer to Appendix B, "Troubleshooting Guide," which contains a list of common problems and their solutions and Appendix D, "Frequently Asked Questions."

1.2.2 End User

If you are an end user, read these chapters:

This chapter: Explains:
Welcome to FLEXlm
FLEXlm basics: license and vendor daemons;
the license file; configuring FLEXlm; the
license request process.
The License File
The license file format; setting the path at start-
up; different types of licensing policies.

In addition, you can refer to Appendix B, "Troubleshooting Guide," which contains a list of common problems and their solutions.

1.3 Related Documents from GLOBEtrotter Software

The SAMsuite Users Guide describes the SAMsuite license administration tool for managing FLEXlm-enabled applications, and the SAMwrap Users Guide describes SAMwrap for administrators who wish to provide FLEXlm license management for applications shipped without embedded license management.

The FLEXlm Programmers Guide and FLEXlm Reference Manual are for programmers responsible for incorporating FLEXlm into their products.

TOC INDEX

Chapter 2
Introduction and Overview

This chapter explains the basics of floating (network) licensing and gives a quick overview of the components of FLEXlm. It explains where license administrators have control and where end users have control. Section 2.5, "Getting Started Checklist," tells both license administrators and end users how to start managing FLEXlm.

2.1 Introduction to FLEXlm

FLEXlm is the most popular license manager used in the software industry. FLEXlm is best known for its ability to allow software licenses to be available (or float) anywhere on a network, instead of being tied to specific machines. Floating licensing benefits both users and license administrators. Users can make more efficient use of fewer licenses by sharing them on the network. License administrators can control who uses the licensed application and the node(s) where the licenses will be available. See Section 3.4, "Types of License Files," for details about the different licensing models supported by FLEXlm.

2.2 FLEXlm Components

The four main components of FLEXlm are:

2.2.1 The License Manager Daemon (lmgrd)

The license manager daemon (lmgrd) handles the initial contact with the client application programs, passing the connection on to the appropriate vendor daemon. It also starts and restarts the vendor daemons. FLEXlm permits multiple redundant license manager daemons on three server nodes, allowing you to make your license available if any two of the three server nodes is running. Redundancy can be achieved with three-server redundant servers or by using a license file list with any number of servers.

Note: lmgrd is not present on VMS or Netware systems.

2.2.2 The Vendor Daemon

In FLEXlm, licenses are granted by running processes (unless they're node- locked, uncounted licenses, in which case they need only read the license file to run). There is one process for each vendor who has a FLEXlm-licensed product on the network. This process is called the vendor daemon. The vendor daemon keeps track of how many licenses are checked out, and who has them. If the vendor daemon terminates for any reason, all users lose their licenses (though this does not mean the applications suddenly stop running). Users normally regain their license automatically when lmgrd restarts the vendor daemon, though they may exit if the vendor daemon remains unavailable.

Client programs communicate with the vendor daemon, usually through TCP/IP network communications. The client application and the daemon processes (the license server) can run on separate nodes on your network, across any size wide-area network. Also, the format of the traffic between the client and the vendor daemon is machine independent, allowing for heterogeneous networks. This means the license server and the computer running an application can be either different hardware platforms or even different operating systems (Windows and UNIX, for example).

2.2.3 The License File

Licensing data is stored in a text file called the license file. The license file is created by the software vendor, and edited and installed by the license administrator. It contains information about the server nodes and vendor daemons, and at least one line of data (called FEATURE or INCREMENT lines) for each licensed product. Each FEATURE line contains a license key or signature based on the data in that line, the hostids specified in the SERVER line(s), and other vendor-specific data.

In some environments, the licensing information for several vendors may be combined into a single license file.

Most applications have an expected location for the license file, documented by that application. End users can usually override this location by setting the environment variable LM_LICENSE_FILE to point elsewhere, or by following instructions supplied with the licensed application. If your site has software from multiple vendors with incompatible license files (due to different sets of servers), you can keep the data in separate files and set the LM_LICENSE_FILE variable to reference multiple files.

It's strongly recommended that you keep a link (on UNIX) or copy of the license file in the vendor's expected license location, so that users will not need to set LM_LICENSE_FILE to run their applications. If the licenses are counted (floating) this license should have a USE_SERVER line directly after the SERVER line. For details, see Chapter 3, "The License File." See also Appendix C, "FLEXlm Environment Variables."

2.2.4 The Application Program

The application program using FLEXlm is linked with the program module (called the FLEXlm client library) that provides the communication with the license server. On Windows, this module is called lmgrxxx.dll, where xxx indicates the FLEXlm version. During execution, the application program communicates with the vendor daemon to request a license.

2.3 The License Request Process

When you run a counted FLEXlm-licensed application, the following occurs:

  1. The license module in the client application finds the license file, which includes the host name of the license server node and port number of the license manager daemon, lmgrd.
  2. The client establishes a connection with the license manager daemon (lmgrd) and tells it what vendor daemon it needs to talk to.
  3. lmgrd determines which machine and port correspond to the master vendor daemon and sends that information back to the client.
  4. The client establishes a connection with the specified vendor daemon and sends its request for a license.
  5. The vendor daemon checks in its memory to see if any licenses are available and sends a grant or denial back to the client.
  6. The license module in the application grants or denies use of the feature, as appropriate.

Uncounted features (where the license count is 0) do not require a server, and the FLEXlm client library routines in the application grant or deny usage based solely upon the license contents.

2.4 Configuring FLEXlm

Most of the parameters of FLEXlm are configurable by the license administrator. The license administrator can set the:

In addition, the license administrator can reserve licenses for specific users, nodes, or groups, and control other license-related options. Changing parameters is discussed in Chapter 6, "The Options File."

Note: Refer to your vendor's documentation before attempting to change file names, locations, or contents.

2.5 Getting Started Checklist

The following sections provide a quick overview of how to set up and use licensing for FLEXlm-licensed products. By scanning the list, you should be able to quickly find the areas of interest. Cross-references point to more details in other parts of this manual.

2.5.1 Installing Licensed Software

As a license administrator you are responsible for setting up licensing on your system or network. This section tells you how to do that. If you are an end user of the application and you will not be involved in installing it, then go to Section 2.5.2, "Notes for End Users."

Remember that the installation guide for your application software is the final word on installing and configuring FLEXlm. Generally, however, installing FLEXlm licensing requires the following steps:

  1. Select your license server nodes and get their hostids. See Appendix A, "Hostids for FLEXlm-Supported Machines."
  2. Give the hostids to your software vendor and get a license file (or the data to enter in the license file) in return.
  3. Consider combining the new license file with any existing license files. See Chapter 4, "Multiple License Files."
  4. Determine if an options file is desired, and if so, set it up.
  5. Determine where to install the FLEXlm utility programs such as lmgrd and lmutil (lmstat/lmdown/etc.) and install them, unless your vendor's installation script does so for you.
  6. Start lmgrd (the license manager daemon) manually; you may also want to set it up to start automatically at boot time. See Section 3.1.1, "Starting the License Server at System Startup."

These steps are discussed briefly below, with cross-references to the appropriate locations for more detail.

License Server Node and Hostids

Before running any FLEXlm-licensed program using floating licenses, you will need to set up your license server node (or nodes). You must select which node or nodes to run your license servers on and provide the hostids of those machines to your software vendor. For pointers on selecting your server machine, see Chapter 5, "Selecting Server Nodes."

You can get the hostid of the server machine by running FLEXlm's lmhostid utility on that machine. If you don't have lmhostid, you can get the hostid of your machine by using the appropriate command as described in Appendix A, "Hostids for FLEXlm-Supported Machines."

Using the hostid of your server machines, your vendor will send you a license file that enables their application software.

License Files and lmgrd

Once you have received a license file from your vendor, you must install it on your system and start up the license manager daemon, lmgrd.

Administration Tools

GLOBEtrotter Software supplies administration tools to your software vendor. The vendor usually includes them with their product. The recommended location for the tools is /usr/local/bin (UNIX), C:\flexlm (Windows), or SYS$COMMON:[SYSMGR] (VMS), but you can install them in a different location (or not at all). See Chapter 7, "License Administration Tools," for more information.

Options Files

The options file controls various options such as reservations and timeouts of licenses. Most users run without an options file, but you may decide you want to use some options. For example, many administrators use an option to limit the quantity and content of logged messages. To set up an options file, see Chapter 6, "The Options File."

2.5.2 Notes for End Users

As a user of a FLEXlm-licensed application, you may need to know a few things to use the system effectively. The main things you need to know are:

How to Specify a License File

The license file determines what features are available to a program. It also contains information telling the application how to connect to the license server.

For information about the standard way of specifying a license file for an application, see Chapter 3, "The License File."

Getting Information About Licenses

To find out who is using a license run lmstat, described in Chapter 7, "License Administration Tools."

TOC INDEX

Chapter 3
The License File

The license file contains all site-specific information required by FLEXlm. This information includes:

In general, the license file, or a copy of it, must be accessible to every machine that runs a FLEXlm-licensed application, and each machine designated as a license server. If the license file contains counted (also called "floating") licenses, before you can use the application you have to start the license manager daemon (lmgrd) using the following syntax:

lmgrd -c license_file_path -l debug_log_path

where license_file_path is the full path to the license file and debug_log_path is the full path to the debug log file.

Note: On VMS and Netware systems, there is no lmgrd and the vendor daemon is run directly.

3.1 Specifying Location of the License File

Most software vendors recommend a specific location for your license file. If you are running the application on multiple nodes, you have these options for making your license available on all the machines:

Since the vendor daemon keeps track of license usage, and since the license file contains encrypted data to protect it against modification, you may move and copy the license file as much as necessary.

For counted licenses, no matter which option you choose, you must first install lmgrd and the vendor daemon.

With a FLEXlm v6+ vendor daemon and lmgrd, the license path can be a list of files, separated by colons on UNIX or semi-colons on Windows. If there is a directory in this list, all files named *.lic in that directory are used.

Note: You can only start lmgrd on the server node specified in the license file.

Note: If you are running redundant servers, you should have separate copies of the license file (as well as the binaries for lmgrd and the vendor daemons) on each server node. If you do not do this, you lose all the advantages of having redundant servers, since the file server holding these files becomes a single point of failure.

3.1.1 Starting the License Server at System Startup

If any licenses in the license file are counted (license count > 0), then the license server must be started before the product can be used.

UNIX

To start the license manager daemon (lmgrd), execute a command similar to the following.

If you are running in the C shell:

lmgrd_path -c license_file_path -l debug_log_path &

If you are using either the Korn or Bourne shell:

nohup lmgrd_path -c license_file_path -l debug_log_path 2>&1 &

On UNIX, edit the appropriate boot script, which may be /etc/rc.boot, /etc/rc.local, /etc/rc2.d/Sxxx, /sbin/rc2.d/Sxxxx, etc. Remember that these scripts are run in /bin/sh, so do not use the csh ">&" redirection syntax.

Each UNIX operating system can have some quirks in doing this, but the following script has been successfully tested for HP700 systems. See the notes following for a full explanation.

/bin/su daniel -c 'echo starting lmgrd > \
/home/flexlm/v5.12/hp700_u9/boot.log'

/bin/nohup /bin/su daniel -c 'umask 022; \
/home/flexlm/v5.12/hp700_u9/lmgrd -c \
/home/flexlm/v5.12/hp700_u9/license.dat >> \
/home/flexlm/v5.12/hp700_u9/boot.log'

/bin/su daniel -c 'echo sleep 5 >> \
/home/flexlm/v5.12/hp700_u9/boot.log'

/bin/sleep 5

/bin/su daniel -c 'echo lmdiag >>\
/home/flexlm/v5.12/hp700_u9/boot.log'

/bin/su daniel -c '/home/flexlm/v5.12/hp700_u9/lmdiag -n -c\
/home/flexlm/v5.12/hp700_u9/license.dat >> \
/home/flexlm/v5.12/hp700_u9/boot.log'

/bin/su daniel -c 'echo exiting >>\
/home/flexlm/v5.12/hp700_u9/boot.log'

Please note the following about how this script was written:

Windows

From LMTOOLS, start lmgrd. You can optionally indicate that this should be started at system startup.

3.1.2 Setting the Path with an Environment Variable

Most applications specify a location where they expect to find the license file. Many will automatically install the license. You should rarely, if ever, be required to specify where the license file is located with an environment variable. However, you can change the license location with LM_LICENSE_FILE, or if a location is not set by the application, you can set one.

Use the environment variable LM_LICENSE_FILE to set the location of the license file. For example in the C shell:

setenv LM_LICENSE_FILE license_file_path

In the Korn and Bourne shells:

LM_LICENSE_FILE=license_file_path
export LM_LICENSE_FILE

On Windows 95, add the following line to C:\autoexec.bat:

SET LM_LICENSE_FILE=license_file_path

On Windows NT, use the System Control Panel to change the global environment, adding LM_LICENSE_FILE to license_file_path, where license_file_path is the full path to the license file. This can also be a port@host setting, where port and host are the port number and host name from the SERVER line in the license file. v6+ applications can use simply @host, if the server uses a default port number.

In FLEXlm v6+, applications will accept an environment variable (or Windows Registry) named VENDOR_LICENSE_FILE, where VENDOR is the vendor daemon name, e.g., GSI_LICENSE_FILE.

With lmgrd and lmutil (lmstat, lmdown, etc.), the -c option overrides the setting of the LM_LICENSE_FILE environment variable. See Section 4.1.3, "Using Separate License Files on the Same Server Node," for more information about LM_LICENSE_FILE.

Note: Some applications do not recognize the LM_LICENSE_FILE environment variable.

See also Appendix C, "FLEXlm Environment Variables."

3.2 License File Format

License files usually begin with a SERVER line (or three lines for redundant servers) followed by one or more DAEMON lines, followed by one or more FEATURE or INCREMENT lines. In some cases the license file requires no SERVER line and no DAEMON line. See Section 5.4, "Counted vs. Uncounted Licenses," for more information. Since FLEXlm v6.0, the DAEMON line can be called VENDOR. Wherever DAEMON appears, VENDOR can be used, if the lmgrd and vendor daemon are both >= FLEXlm v6.0.

You can modify these data items in the license file:

Long lines normally use the "\" line-continuation character to break up long lines (though this is not required with v7+ applications). FLEXlm v2 did not support the line-continuation character, although this rarely matters since optional attributes weren't support then either.

Note: Everything else is used to compute the license key or signature, and should be entered exactly as supplied by your software vendor. All data in the license file is case sensitive, unless otherwise indicated.

3.2.1 SERVER Lines

The SERVER line specifies the node name and hostid of the license server and the port number of the license manager daemon (lmgrd). Normally a license file has one SERVER line. Three SERVER lines mean that you are using redundant servers. The absence of a SERVER line means that every FEATURE or INCREMENT line in the license file is uncounted. For more information about uncounted features, see Section 3.2.4, "FEATURE or INCREMENT Lines." License administrators do not have the option of deleting SERVER lines from a license file because the hostids from the SERVER lines are computed into the license key or signature on every FEATURE and INCREMENT line. For more information about redundant servers, see Chapter 5, "Selecting Server Nodes."

The format of the SERVER line is:

SERVER host hostid [port]

where:

host
The system host name or IP address. String returned by
the UNIX hostname or uname -n command. On NT,
ipconfig /all; on Windows 95, winipcfg /all
return the host name. If the application uses FLEXlm v5 or
higher, this can be an IP address (in ###.###.###.###
format).
hostid
Usually the string returned by the lmhostid command.
This can only be changed by your software supplier.
port
TCP port number to use. A valid number is any unused
port number between 0 and 64000. On UNIX, choose a
port >1024, since those <1024 are privileged port
numbers. The port number is optional if lmgrd, the
vendor daemon, and the application are v6+ (if no port
number is specified, one of the default ports in the range
of 27000 and 27009 will be used).

Example:

SERVER enterprise 0122345 21987

3.2.2 DAEMON (or VENDOR) Lines

The DAEMON line specifies the daemon name and path. lmgrd uses this line to start the vendor daemon, and the vendor daemon reads it to find its options file. The format of the DAEMON line is shown below.

Note: Since FLEXlm v6.0, the DAEMON line can be called VENDOR. VENDOR can be used if the lmgrd and vendor daemon are both at least FLEXlm v6.0.
{DAEMON|VENDOR} vendor [vendor_daemon_path]\
[[options=]options_file_path] [[port=]port]

where:

vendor
Name of the vendor daemon used to serve some
feature(s) in the file. This name cannot be changed
by the administrator.
vendor_daemon_
path
Path to the executable for this daemon. Generally
the license administrator is free to install the
daemon in any directory. (It is recommended,
however, that it be installed in a local directory on
the license server node.)
If the vendor daemon is v6+, this path is optional.
If left out, lmgrd will look for the vendor daemon
binary in the current directory, the PATH list, or in
the directory where lmgrd is located. If the
vendor daemon path is blank, then the options=
and port= strings are required if options or port
number are specified.
options_file_

path
Full path to the end-user options file for this
daemon. (See Chapter 6, "The Options File.")
FLEXlm does not require an options file. The
keyword options= requires a v5+ vendor
daemon.
If the vendor daemon is v6+, the options file need
not be specified on this line. If it is called
vendor.opt (where vendor is the vendor
daemon name) and located in the same directory
as the license file, the vendor daemon will
automatically find and use it.
port
Vendor daemon port number. This requires a v5+
lmgrd.
Note: This is for firewall support only and is
otherwise not recommended. If a port number is
specified on the DAEMON line, there is a delay
restarting the vendor daemon until all the clients
have closed their connections to the vendor
daemon.

v6.0:

VENDOR sampled

pre-v6.0:

DAEMON sampled /etc/sampled \
/a/b/sampled/licenses/sampled.opt

3.2.3 USE_SERVER Line (v5+ only)

USE_SERVER takes no arguments and has no impact on the server. When the application sees USE_SERVER, it ignores everything in the license file except preceding SERVER lines, and the checkout validation occurs at the vendor daemon. USE_SERVER is recommended since it improves performance when a license server is used. For uncounted features, USE_SERVER can be used to force logging of usage by the daemons.

3.2.4 FEATURE or INCREMENT Lines

A FEATURE line describes the license to use a product. An INCREMENT line can be used in place of a FEATURE line, as well as to incrementally add licenses to a prior FEATURE or INCREMENT line in the license file.

Only the first FEATURE line for a given feature will be processed by the vendor daemon. If you want to have additional copies of the same feature (for example, to have multiple node-locked, counted features), then you must use multiple INCREMENT lines. INCREMENT lines form license groups based on the feature name, version, and node-lock hostid. If the feature name, version, and node-lock hostid (and optionally, the vendor string, if the vendor specified this) match a prior INCREMENT or FEATURE line, the new number of licenses is added to the old number. If any of the three do not match, a new group of licenses is created in the vendor daemon, and this group (called a license pool) is counted independently from others with the same feature name. INCREMENT is not available for pre-v2.61 FLEXlm clients or servers. A FEATURE line does not give an additional number of licenses, whereas an INCREMENT line always gives an additional number of licenses.

Note: There is a rarely used option in FLEXlm which causes FEATURE lines to function as INCREMENT lines. This option is called ls_use_all_feature_lines. You will have to ask your vendor if they use this option. If they do, then all FEATURE lines behave exactly as INCREMENT lines.

Note: A FEATURE line placed after another FEATURE or INCREMENT line will be ignored (unless ls_use_all_feature_lines is set).

The format for the FEATURE line changed in FLEXlm v3.0 and again in FLEXlm v6.0. The older formats are understood by new clients and servers, but the new formats are more flexible.

v2 format:

{FEATURE|INCREMENT} feature vendor \
feat_version exp_date num_lic key \
"vendor_str" [feat_hostid]

v3-v7.0 format:

{FEATURE|INCREMENT} feature vendor feat_version \
exp_date num_lic key [HOSTID=feat_hostid] \
[VENDOR_STRING="vendor_str"] [vendor_info="..."] \
[dist_info="..."] [user_info="..."] [asset_info="..."] \
[ISSUER="..."] [NOTICE="..."] [ck=nnn] [OVERDRAFT=nnn] \
[DUP_GROUP=NONE|SITE|[UHDV]]

v7.1+ format:

{FEATURE|INCREMENT} feature vendor feat_version \
exp_date num_lic [HOSTID=feat_hostid] \
[VENDOR_STRING="vendor_str"] [vendor_info="..."] \
[dist_info="..."] [user_info="..."] [asset_info="..."] \
[ISSUER="..."] [NOTICE="..."] [ck=nnn] [OVERDRAFT=nnn] \
[DUP_GROUP=NONE|SITE|[UHDV]] SIGN=sign

Note: Nothing in a FEATURE/INCREMENT line is editable, except for values in keyword=value pairs where keyword is all lowercase.

where:

feature
Name given to the feature by the vendor.
vendor
Name of the vendor daemon; also found in the
DAEMON line. The specified daemon serves
this feature.
feat_version
Version of this feature that is supported by this
license.
exp_date
Expiration date of license, e.g., 7-may-1996.
Note: If the year is 0 (or 00, 000, 0000) then
the license never expires. Dates before 2000
can be two- or four-digit years. After 2000
they must be four-digit years. The expiration
date is fully year-2000 compliant.
FLEXlm v6 (or later) applications only: the
keyword "permanent" can be used instead of
the date 1-jan-0.
num_lic
Number of concurrent licenses for this feature.
If the number of licenses is set to 0, the
licenses for this feature are uncounted and no
lmgrd is required but a hostid on the
FEATURE line is required. See Section 5.4,
"Counted vs. Uncounted Licenses."
FLEXlm v6 (or later) applications only: the
keyword "uncounted" can be used instead of a
license count of 0.
key
License key to authenticate this FEATURE
line. Two identical-looking FEATURE or
INCREMENT lines may have different license
keys if the start dates are different.
SIGN=sign
SIGN= signature to authenticate this
FEATURE line. (v7.1+)

The following fields are all optional (except for "vendor_str" in the v2 format). For optional fields of the keyword=value syntax, if the keyword is lowercase, it can be modified and the license will remain valid.

"vendor_str"
Vendor-defined string, enclosed in double
quotes. This string can contain any
characters except a quote. Required field in
the v2 format.
feat_hostid
String returned by lmhostid. Used only if
the feature is to be bound to a particular
host, whether its use is counted or not.
Numeric hostids are case insensitive. See
Appendix A, "Hostids for FLEXlm-
Supported Machines," for more information.
DUP_GROUP=...
Duplicate grouping parameter can be
specified in the license in FLEXlm v4.0 and
later. The syntax is:
DUP_GROUP=NONE|SITE|[UHDV]

U = DUP_USER
H = DUP_HOST
D = DUP_DISPLAY
V = DUP_VENDOR_DEF

Any combination of UHDV is allowed, and
the DUP_MASK is the OR of the
combination. For example,
DUP_GROUP=UHD means the duplicate
grouping is
(DUP_USER|DUP_HOST|DUP_DISPLAY),
so for a user on the same host and display,
additional uses of a feature do not consume
additional licenses.
HOSTID=

feat_hostid
Same as feat_hostid above, but in the
keyword=value pair syntax (FLEXlm v3.0
and later).
HOST_BASED[=n]
Host names must be specified in INCLUDE
statements in the end-user options file, and
the number of hosts is limited to num_lic,
or the number specified in =n.
ISSUED=

dd-mmm-yyyy
Date issued.
ISSUER="..."
Issuer of the license.
NOTICE="..."
A field for intellectual property notices.
OVERDRAFT=n
FLEXlm v4.0 and later. The overdraft policy
allows your vendor to specify a number of
additional licenses which users will be
allowed to use, in addition to the licenses
they have purchased. This allows your users
to not be denied service when in a
"temporary overdraft" state. Usage above
the license limit will be reported by the
SAMreport reporting tool.
PLATFORMS="..."
Usage is limited to the listed platforms.
(v5.11+ only).
SN=serial_num
Serial number, used to identify FEATURE or
INCREMENT lines.
START=

dd-mmm-yyyy
Start date (FLEXlm v6 or later only).
SUPERSEDE=

"f1 f2 ..."
If this appears, all licenses issued before the
date specified in ISSUED= are superseded
by this line and become ineffective.
USER_BASED[=n]
Users must be specified in INCLUDE
statements in the end-user options file, and
the number of users are limited to num_lic,
or the number specified in =n.
VENDOR_STRING=

"..."
Same as "vendor_str" above, but in
keyword=value pair syntax.

The following attributes can be changed or deleted by end users. This is indicated by a lowercase keyword.

asset_info=

"..."
Additional information provided by the license
administrator for asset management.
ck=nnn
A checksum, useful with the lmcksum utility,
which will verify that the license has been entered
correctly by the end user.
dist_info=

"..."
Additional information provided by the software
distributor.
user_info=

"..."
Additional information provided by the license
administrator.
vendor_info=

"..."
Additional information provided by the software
vendor.

Examples:

FEATURE xyz_app xyzd 2.300 31-dec-2005 20 123456789012 "xyz"
INCREMENT f1 xyzd 1.000 1-jan-0 5 901234567890 \
HOSTID=INTERNET=195.186.*.* NOTICE="Licensed to XYZ corp"

3.2.5 PACKAGE Lines

The purpose of the PACKAGE line is to support two different licensing needs:

A PACKAGE line, by itself, does not license anything--it requires a matching FEATURE/INCREMENT line to license the whole package. A PACKAGE line can be shipped by your software vendor with a product, independent of any licenses. Later, when you purchase a license for that package, one or more corresponding FEATURE/INCREMENT lines will enable the PACKAGE line.

Example:

PACKAGE package vendor pkg_version COMPONENTS=pkg_list \
[OPTIONS=SUITE] SIGN=pkg_sign

where:

package
Name of the package. The corresponding
FEATURE/INCREMENT line must have the same
name.
vendor
Name of the vendor daemon that supports this
package.
pkg_version
Version of the package. If specified, the enabling
FEATURE/INCREMENT line must have the same
version.
pkg_sign
License key or SIGN= signature.
pkg_list
List of package components. The format is:
feature[:version[:num_lic]]
Packages must consist of at least one component.
Version and count are optional, and if left out,
their values come from the corresponding
FEATURE/INCREMENT line. num_lic is only
legal if OPTIONS=SUITE is not set--in this case
the resulting number of licenses will be num_lic
on the COMPONENTS line multiplied by the
number of licenses in the
FEATURE/INCREMENT line. Examples:
COMPONENTS="comp1 comp2 comp3 comp4"
COMPONENTS="comp1:1.5 comp2 comp3:2.0:4"
OPTIONS=SUITE
This is what distinguishes a package suite from a
package used to ease distribution.
With OPTIONS=SUITE, the corresponding feature
of the same name as the package is checked out in
addition to the component feature being checked
out.
If OPTIONS=SUITE is not set, then the
corresponding feature of the same name as the
package is removed once the package is enabled;
is not checked out when a component feature is
checked out.

Examples:

PACKAGE suite xyzd 1.0 3B24B2F508CB \
COMPONENTS="comp1 comp2" OPTIONS=SUITE
FEATURE suite xyzd 1.0 1-jan-0 5 4193E6ABCCCB

This is a typical OPTIONS=SUITE example. There are two features, "comp1" and "comp2," which are each version 1.0, each with five non-expiring licenses available. When "comp1" or "comp2" is checked out, "suite" will also be checked out.

PACKAGE suite xyzd 1.0 2CBF44FCB9C1 \
COMPONENTS="c1:1.5:2 c2:3.0:4"
FEATURE suite xyzd 1.0 1-jan-2005 3 321E78A17EC1 SN=123

In this example, the component version overrides the feature version, and the number of licenses available for any component is the product of the three licenses for "suite" and the number of licenses for that component. The result is equivalent to:

FEATURE c1 xyzd 1.5 1-jan-2005 6 0D3AD5F26BEC SN=123
FEATURE c2 xyzd 3.0 1-jan-2005 12 EB16C5AE61F0 SN=123

With FLEXlm v6 (or later) applications only the PACKAGE lines can be stored in a separate file which need never be edited.

3.2.6 UPGRADE Lines

UPGRADE feature vendor from_feat_version to_feat_version \
exp_date num_lic [options ... ] SIGN=sign

All the data is the same as for a FEATURE or INCREMENT line, with the addition of the from_feat_version field. An UPGRADE line removes up to the number of licenses specified from any old version (>= from_feat_version) and creates a new version with that same number of licenses.

For example, the two lines:

INCREMENT f1 xyzd 1.000 1-jan-2005 5 SIGN=9BFAC0316462
UPGRADE f1 xyzd 1.000 2.000 1-jan-2005 2 SIGN=1B9A308CC0F7

would result in three licenses of v1.0 of "f1" and two licenses of v2.0 of "f1."

An UPGRADE line will operate on the closest preceding FEATURE or INCREMENT line with a version number that is >= from_feat_version, and < to_feat_version.

Note that UPGRADE lines do not work for node-locked, uncounted licenses before v6.

3.3 Sample License File

This is an example of a license file for a single vendor with two features.

SERVER excellent_server 17007ea8 1700
DAEMON xyzd /etc/xyzd
FEATURE xyz_app1 xyzd 1.000 01-jan-2005 10 1EF890030EAB
FEATURE xyz_app2 xyzd 1.000 01-jan-2005 10 084561FE98B3

The license file above would allow the license server "excellent_server" with the hostid "17007ea8" to serve ten floating licenses for "xyz_app1" and "xyz_app2" to any user on the network.

3.4 Types of License Files

License files are created by the software vendor. License files can specify floating (concurrent) usage, node-locked (both counted and uncounted), and any combination of floating, counted, and uncounted.

3.4.1 Floating (Concurrent) Licenses

A floating license means anyone on the network can use the licensed software, up to the limit specified in the license file (also referred to as concurrent usage or network licensing). Floating licenses have no hostids on the individual FEATURE lines. Floating licenses requires an lmgrd and a vendor daemon to be running to count the concurrent usage of the licenses.

An example of a license file that provides floating licenses is:

SERVER lulu 17001234 1700
DAEMON xyzd /etc/xyzd
FEATURE f1 xyzd 1.00 1-jan-2005 2 key1 ""
FEATURE f2 xyzd 1.00 1-jan-2005 6 key2 ""
FEATURE f3 xyzd 1.00 1-jan-2005 1 key3 ""

This license file specifies that two licenses for feature "f1," six licenses for feature "f2," and one license for feature "f3" are available anywhere on the network that can access the license server "lulu."

3.4.2 Node-Locked Licenses

Node-locking means the licensed software can only be used on one node. A node-locked license has a hostid on any FEATURE line that is node-locked to a particular host. There are two types of node-locked licenses; uncounted and counted.

If the number of licenses is set to 0, then the license is uncounted and unlimited use is permitted on the specified node. This configuration does not require an lmgrd or a vendor daemon because it is not going to count the concurrent usage of the features.

The following license file allows unlimited usage of feature "f1" on the nodes with hostids of "12001234" and "1700ab12":

FEATURE f1 xyzd 1.000 1-jan-2005 0 key1 "" 12001234
FEATURE f1 xyzd 1.000 1-jan-2005 0 key2 "" 1700ab12

Alternately, in FLEXlm v5.0 or later, these two FEATURE lines could have been issued by your software vendor with a hostid list:

FEATURE f1 xyzd 1.000 1-jan-2005 0 key HOSTID="12001234 1700ab12"

If these were the only FEATURE lines in this license file, no lmgrd daemon would be necessary and you should not start one.

The following license file allows three licenses for feature "f1" to be run, but only on the node with hostid "1300ab43." In this case, the daemons should be run on the same node that runs the software, since there is no reason to run the daemons on another node.

SERVER lulu 1300ab43 1700
DAEMON xyzd /etc/xyzd
FEATURE f1 xyzd 1.00 1-jan-2005 3 key HOSTID=1300ab43

3.4.3 Mixed Node-Locked and Floating Licenses

Uncounted node-locked and concurrent usage licenses can be mixed in the same license file.

The following license file allows unlimited use of feature "f1" on nodes "17001111" and "17002222," while allowing two other licenses for feature "f1" to be used anywhere else on the network:

SERVER lulu 17001234 1700
DAEMON xyzd C:\flexlm\xyzd.exe
FEATURE f1 xyzd 1.00 1-jan-2005 0 key1 HOSTID=17001111
FEATURE f1 xyzd 1.00 1-jan-2005 0 key2 HOSTID=17002222
FEATURE f1 xyzd 1.00 1-jan-2005 2 key3

This configuration requires an lmgrd and a vendor daemon because the concurrent usage of the two licenses on the third FEATURE line is counted.

3.5 Decimal Format

The decimal format was introduced in v6. Users with older products can still use the decimal format, but they will require a copy of the lminstall command (which is part of lmutil). The lminstall utility allows the user to type in a decimal line, which is then converted to the readable format, and saved in the specified location. The mixed node-locked and floating example above looks as follows in decimal format:

xyzd-f1-01761-55296-37046-04544-00017-06551-18072-57346-18754-136
xyzd-f1-01761-55296-37046-08896-00034-235
xyzd-f1-00481-55296-17590-2

A simple demo license in readable format:

FEATURE f1 xyzd 1.00 1-jan-2005 0 key1 HOSTID=DEMO

converted to decimal:

xyzd-f1-00737-55296-1825

Note that by default lminstall converts to v6 format. It can convert to a format compatible with older versions by using lminstall -overfmt 2 (or 3, 4, 5, 5.1, 6, 7, or 7.1, depending on the FLEXlm version).

3.6 License File Order

In some cases, the ordering of lines in a license file can be crucial. Version 7+ vendor daemons and clients automatically internally sort the lines so that in most cases the optimal result is achieved. For earlier versions of FLEXlm, note the following suggestions, which are all based on the fact the checkouts are attempted on lines in the order they appear in the license file:

  1. Place FEATURE lines before INCREMENT lines for the same feature.
    The rule regarding FEATURE lines is that only the first counted FEATURE line is observed by the license server, and that if there is a FEATURE line and INCREMENT lines, the FEATURE line must appear first. (A few large, older FLEXlm-licensed companies have FEATURE lines that behave identically to INCREMENT lines, and only the rules applying to INCREMENT apply to them.)
  2. Where multiple counted FEATURE lines exist for the same feature, make sure the desired FEATURE line appears first.
    All but the first is ignored.
  3. Place node-locked, uncounted lines before floating lines for the same FEATURE.
    Otherwise, the floating license may be consumed when a node-locked would have been used, resulting in denial for other users.
  4. The placement of a USE_SERVER line affects behavior.
    A USE_SERVER line is recommended. Normally, the USE_SERVER line is placed immediately after the SERVER line. However, if there are uncounted licenses which you don't want to fail if the server is unavailable, these should be placed at the top of the file, with the USE_SERVER line following them. This only works, however, if each user that needs the uncounted license has direct access to a current copy of the file. The advantage to placing USE_SERVER right after the SERVER line is users don't need up-to-date copies of the license file.

TOC INDEX

Chapter 4
Multiple License Files

Since more than 2000 vendors have chosen FLEXlm as their license manager, chances are good that you will have to administer FLEXlm licenses from more than one vendor or multiple products from the same vendor.

4.1 Overview of Combining License Files

When you are running FLEXlm-licensed products from multiple vendors, you may need to take steps to prevent licensing conflicts during installation. There are three ways you can accomplish this:

Note that before v6, each lmgrd could read only a single license file. In the first option mentioned above, you will have more license servers to monitor; in the third option you have only one server but multiple lmgrds to administer.

If all applications and vendor daemons are FLEXlm v6+, lmgrd can process multiple license files, even when the hostids in each license file are different, so long as they refer to the same node. For example, on UNIX:

lmgrd -c license_file_path_1:license_file_path_2 ...

Your product's license file(s) define the license server(s) by host name and hostid in the SERVER line(s) in the license file. If the license files for two or more products contain identical hostids on the SERVER line(s), then these files can be combined. If the license files for two products contain different hostids on a SERVER line, then the license servers for those products will be running on different nodes and the license files cannot be combined.

If you have two or more products whose license servers run on the same node (as specified by the SERVER lines in the license files), you may be able to combine the license files into a single license file. If the SERVER lines in those files have identical hostids, then you can combine the files into a single file. If the SERVER lines have different hostids, then you must keep the license files separate.

More precisely, you can combine two license files under the following conditions:

  1. The number of SERVER lines in each file is the same.
  2. The hostid field of each SERVER line in one file exactly matches the hostid field of each SERVER line in the other file.

Some possible reasons license files may not be compatible are:

If your license files are compatible as described above, then you have the option of combining license files and running a single lmgrd, as described below in Section 4.1.1, "Combining License Files from Multiple Vendors." If the license files are not compatible, then you must keep the license files separate and run separate copies of lmgrd for each license file, as described in Section 4.1.3, "Using Separate License Files on the Same Server Node."

Note that you are not required to combine compatible license files; you always have the option of running separate lmgrds, and there is virtually no performance or system-load penalty for running separate lmgrd processes.

4.1.1 Combining License Files from Multiple Vendors

If your license files are compatible, you can combine them with any text editor. To combine license files, read all of the compatible license files into one file, then edit out the extra SERVER lines so that only one set of SERVER lines remains. Write out this data, and you have your combined license file. If you combine license files from multiple vendors, it is a good idea to keep a copy of the combined license file in each vendor's default license file location. This way, users can avoid having to set LM_LICENSE_FILE, because each package finds it's license information in the default place. On UNIX, you can do this with a symbolic link from each default location to the location of the combined license file.

4.1.2 FLEXlm Version Component Compatibility

When you combine license files for two different FLEXlm-licensed products, it may be the case that those products do not use the same version of FLEXlm. FLEXlm is designed to handle this situation. There are two basic compatibility rules for FLEXlm:

From these two compatibility rules come the simple rules for selecting which version of administration tools to use:

  1. Always use the newest version of lmgrd and the newest version of each vendor daemon.
  2. Use the newest FLEXlm utilities.

For specific application programs, you can use either the new or the old version (of course, the vendor daemon for that application must be at least as new as the application itself). See also Section G.1, "Version Compatibility and Components."

4.1.3 Using Separate License Files on the Same Server Node

You must run a separate copy of lmgrd for each license file. When you run multiple copies of lmgrd, there are two details to remember:

  1. The port number on the SERVER line of each license file must be unique. You can use a standard text editor to change the port number in each license file so that they are all different.
  2. You must make sure that you are using a compatible version of lmgrd when you start it up for a particular license file. This can be done by using an explicit path to lmgrd.

When running client programs (such as a licensed application), you can set the LM_LICENSE_FILE environment variable to point to multiple license files. For example, you may have a license file from vendor "ABC" and a license file from vendor "XYZ" with incompatible servers. You can place the license file from vendor "ABC" into:

/usr/flexlm/abc.lic

and the license file from vendor "XYZ" into:

/usr/flexlm/xyz.lic

then set the LM_LICENSE_FILE environment variable to point to both of them. Each name in LM_LICENSE_FILE should be separated by a colon (":") on UNIX systems, a semicolon (";") on Windows and Windows/NT systems (in FLEXlm v4.1, a comma was used on Windows and NT), and a space (" ") on VMS systems.

In the C shell:

setenv LM_LICENSE_FILE /usr/flexlm/abc.lic:/usr/flexlm/xyz.lic

In the Korn and Bourne shells:

LM_LICENSE_FILE=/usr/flexlm/abc.lic:/usr/flexlm/xyz.lic
 export LM_LICENSE_FILE

4.2 Using LM_LICENSE_FILE License File List

If products use different license server nodes, each set of license servers requires separate license files. (When multiple software vendors use the same set of license server nodes, the technique described above in Section 4.1, "Overview of Combining License Files," can be used to combine license files.) The resulting (multiple) license files can be installed in convenient locations. On UNIX you would set the LM_LICENSE_FILE environment variable as follows:

setenv LM_LICENSE_FILE lfpath1:lfpath2:...

where lfpath1 is the path to the first license file, lfpath2 is the path to the second license file, etc.

Note: Use a colon (" : ") to separate the license file names on UNIX, on Windows and Windows/NT use a semicolon (" ; "), and on VMS use a space (" ").

Each application queries each license file in the order it is listed in LM_LICENSE_FILE. If the license server serving the license file listed in lfpath1 is unreachable, the other files listed in LM_LICENSE_FILE allow a user to obtain a license from another server. lfpathn can also be port@host, using the port number and host name from the SERVER line in the license file.

See also:

TOC INDEX

Chapter 5
Selecting Server Nodes

This chapter helps you decide which nodes to use as license server nodes.

5.1 Resources Used by the Server

This section discusses the resources used by the license server. When you select a server node, you may need to take into account the system limits on these resources. For small numbers of licenses (under about 100), most of these items should not be a problem on any workstation.

5.1.1 Sockets

When using TCP, a single vendor daemon can support as many users as the per-process system limit for file descriptors, which ranges from 256 on SunOS 4.x to 4000 on DEC Alpha. When no more file descriptors are available to a daemon, additional vendor daemons are spawned to allow for extra file descriptors, though this is not recommended. When using UDP, there is no limit to the number of end users per vendor daemon process, because they can share a single socket in the vendor daemon (UDP has other drawbacks, and TCP is preferred). If there are more than 250 concurrent clients from a SunOS vendor daemon, it may be a good idea to move the server to a different OS, since all other OSs support more file descriptors. If there are more than 1000 concurrent clients being supported by a single vendor daemon, then it's probably good to split the license file into more than one file, from different servers, to lighten the networking traffic (which will require the ISV to agree to issue new licenses). Clients can check out licenses from multiple servers using a license file list via the LM_LICENSE_FILE environment variable.

Each client connected to a license server uses one socket. The total number of sockets used by the license server programs is slightly larger than the total number of simultaneous clients.

On older SCO systems, the default number of sockets may be set fairly low; if you choose to run a server on such a machine, you may need to reconfigure your kernel to have more sockets.

The number of sockets available for Windows 95 clients is about 60. In general, NT is preferred for server systems, where there is no such limit, and the operating system is better designed for server processes.

5.1.2 CPU Time

For small numbers of clients, the license servers use very little CPU time. The servers might have only a few seconds of CPU time after many days.

For a large number of clients (who are each exchanging heartbeat messages with the server), or for high checkout/checkin activity levels (hundreds per second), the amount of CPU time consumed by the server may start to become significant, although, even here, CPU usage is normally not high. In this case, you may need to ensure that the server machine you select will have enough CPU cycles to spare.

Note: GLOBEtrotter Software has rarely encountered a situation where CPU cycles were an issue.

5.1.3 Disk Space

The only output files created by the license servers are the debug and report log files. The report log files are used to generate accurate usage reports by SAMreport. These log files contain one line for each checkout and one line for each checkin. If you have a lot of license activity, these log files will grow very large. You will need to consider where to put these files and how often to delete or prune them. The license administrator can opt not to log messages to the debug log file if disk space is at a premium. See Section 6.2.10, "NOLOG," and Section 6.2.11, "REPORTLOG."

Note that the log files should be local files on the server machine(s) to avoid networking dependencies.

Switching Output of the Debug Log File on UNIX Systems

On UNIX, the debug log file output can be switched after the daemons are running. The technique to do this involves piping the stdout of lmgrd to a shell script that appends to the file for each line.

This is done as follows:

Instead of the "normal" startup:

lmgrd > LOG

Start lmgrd this way:

lmgrd | sh -c 'while read line; do echo "$line" >> LOG ; done'

With this startup method, the output file LOG can be renamed and a new log file will be created. You could even make LOG a symbolic link and change the value of the link to switch the log file.

5.1.4 Memory

The FLEXlm daemons use little memory. On SunOS, lmgrd uses approximately160 KB and the vendor daemons use approximately 180 KB each, although memory usage increases in the vendor daemon with the size of the license file and the number of concurrent users.

5.1.5 Network Bandwidth

FLEXlm sends relatively small amounts of data across the network. Each transaction, such as a checkout or checkin, is typically satisfied with less than 1 KB of data transferred. This means that FLEXlm licensing can be effectively run over slow networks (such as dial-up SLIP lines) for small numbers of clients.

For a large number of clients (hundreds), each of which will be exchanging heartbeat messages with the vendor daemon, the network bandwidth used may start to become significant. In this case you should run client and server on the same local area network, which may require splitting licenses between two files for two servers. Users can use a license file list in the LM_LICENSE_FILE environment variable to have effective access to both servers.

In high-traffic networks, with FLEXlm clients older than v5, you may also want to avoid setting LM_LICENSE_FILE to a port@host address. Instead, the license administrator should place a copy of the license file in a file system local to the application. See Section 3.1, "Specifying Location of the License File."

5.2 Remote Mounted Disks

GLOBEtrotter Software recommends that you do not use remote mounted disks when you run the license server. In other words, we recommend that lmgrd, the vendor daemons, the license file, and the debug and report log files are all on locally mounted disks. If any of these files is on a remote mounted disk, you double the points of failure which could lead to a temporary loss of all of your licenses. When all files are mounted locally, the licenses will be available as long as the server machine is up; but when the files are on a different machine, then the loss of either the license server machine or the file server machine will cause the licenses to be unavailable.

5.3 Redundant Servers

If all the end-user data is on a single file server, then there is no need for redundant servers, and GLOBEtrotter Software recommends the use of a single server node for the FLEXlm daemons. If the end user's data is split among two or more server nodes and work is still possible when one of these nodes goes down or off the network, then multiple server nodes can be employed. In all cases, an effort should be made to select stable systems as server nodes; in other words, do not pick systems that are frequently rebooted or shut down for one reason or another. Redundant license server nodes can be any supported server nodes--it is not required that they be the same architecture or operating system.

FLEXlm supports two methods of redundancy: redundancy via a license file list in the LM_LICENSE_FILE environment variable and a set of three redundant license servers.

With LM_LICENSE_FILE list redundancy, each one of a group of license servers serves a subset of the total licenses. The end user sets LM_LICENSE_FILE to a list of license files, where each license file refers to one of the license servers. The application then tries each server in the list, in order, until it succeeds or gets to the end of the list.

With three-server redundancy, if any two of the three license servers are up and running (two out of three license servers is referred to as a quorum), the system is functional and hands out its total complement of licenses.

See also Section 4.2, "Using LM_LICENSE_FILE License File List."

5.3.1 Redundancy via License File List

This is best explained by example. If ten licenses are desired for both "f1" and "f2," the ISV would issue two sets of licenses with a count of 5 for each of "f1" and "f2." The server nodes (unlike three-server redundancy) can be physically distant.

The license files would look like:

License 1 for "chicago"

SERVER chicago 17007ea8 1700
DAEMON xyzd /etc/mydaemon
FEATURE f1 xyzd 1.000 01-jan-2005 5 26C7DD9C0186
FEATURE f2 xyzd 1.000 01-jan-2005 5 8CE46C57041D

License 2 for "tokyo"

SERVER tokyo 17007ea8 1700
DAEMON xyzd /etc/mydaemon
FEATURE f1 xyzd 1.000 01-jan-2005 5 16BE40E1D98D
FEATURE f2 xyzd 1.000 01-jan-2005 5 6DB6F3E402DF

The user in Chicago could set LM_LICENSE_FILE to:

1700@chicago:1700@tokyo

The user in Tokyo could set LM_LICENSE_FILE to:

1700@tokyo:1700@chicago

The application attempts the first server in the list, and if that fails for any reason, the second server is tried.

5.3.2 Three-Server Redundancy

These three-server redundant servers should have excellent communications and should be on the same subnet. Often this means that the three servers should be located physically close to each other. This form of redundancy requires that the servers exchange heartbeats periodically, and poor communications can cause poor performance. You should never configure redundant servers with slow communications or dial-up links.

Three-server redundancy does not provide load-balancing. Use LM_LICENSE_FILE list instead for this type of redundancy. This is because with three-server redundancy, only one of the three servers is "master," capable of issuing licenses. Since all clients must contact the "master," all clients must have reliable networking to a single node.

5.3.3 Comparing Three-Server to License File List

Are there any drawbacks to using the license file list for redundancy?

Yes. By default, once a license job has successfully checked out a license from one host, all subsequent checkouts must be satisfied from the same host. If the application requires more than one license, this could result in a license denial when the license is available on another server. An application can bypass this restriction if it is coded with the use of multiple FLEXlm license jobs. Only your application vendor can tell you if their application is programmed in this manner.

If the application supports license queueing, all licenses are only queued from the first host on the list.

Finally, if one server becomes unavailable, some licenses will be unavailable.

When is it recommended to use a license file list for redundancy rather than true redundant servers?

5.4 Counted vs. Uncounted Licenses

The license file determines whether a license server is needed. If all the FEATURE (or INCREMENT) lines have a license count of 0 (unlimited) or "uncounted" (FLEXlm v6 or later only), then no server is needed. This type of license is called uncounted. Alternatively, if any FEATURE lines have a non-zero license count, then a server is required to count those licenses. If a vendor wants to use FLEXlm without a server, they must issue uncounted licenses.

With FLEXlm v5 or later, the license server can serve uncounted licenses as well. This is done so that the report log file will include transactions for all license requests, which can then be reported on by SAMreport. To do this, include a SERVER line in the license file, and put the USE_SERVER line immediately after the SERVER line. The vendor daemon will serve the uncounted licenses, and the USE_SERVER line indicates to applications that they will be authorized by the server.

TOC INDEX

Chapter 6
The Options File

The options file allows the license administrator to control various operating parameters of FLEXlm. Users can be identified by their user name, host name, display, IP address, or PROJECT (which is set with the LM_PROJECT environment variable).

Specifically, the license administrator can:

Options files allow you, as the license administrator, to be as secure or open with licenses as you like.

Lines in the options file were limited to 200 characters prior to FLEXlm v3.0. In v3.0 and later, the line length is 2048 characters. FLEXlm v4.0 allows the "\" character as a continuation character in options file lines.

Identifying users by LM_PROJECT in the options file requires a v5+ application and v7+ vendor daemon.

6.1 Creating an Options File

To create an options file:

  1. Use the appropriate options listed in Section 6.2, "Options File Syntax," to create the options file using any text editor. You can put the options file anywhere; however, we recommend that the options file for vendor "XYZ" (whose vendor daemon is xyzd) be placed in:
    UNIX: /a/b/xyzd/licenses/xyzd.opt
    Windows: C:\a\b\xyzd\licenses\xyzd.opt
  2. Add the path to the options file in the license file as the fourth field on the DAEMON line for the application's vendor daemon. For example:
    DAEMON xyzd /etc/xyzd /a/b/xyzd/licenses/xyzd.opt
    would enable the xyzd vendor daemon to look at the specified options file. In FLEXlm v5 or later, you can put options= before the path. In FLEXlm v6 or later, adding the options path to the license file is optional. Instead, name the file vendor.opt, where vendor is the vendor daemon name, and place it in the same directory as the license used by lmgrd, and it will automatically be used at server startup.

6.2 Options File Syntax

Below is an overview of the options file syntax. See Section 6.5, "Options File Examples," for examples and additional information.

Each line of the file controls one option. The options are:

EXCLUDE
Deny a user access to a feature.
EXCLUDEALL
Deny a user access to all features served by this
vendor daemon.
GROUP
Define a group of users for use with any options.
HOST_GROUP
Define a group of hosts for use with any options
(v4.0+).
INCLUDE
Allow a user to use a feature.
INCLUDEALL
Allow a user to use all features served by this
vendor daemon.
LINGER
Cause licenses to be held by the vendor daemon
for a period after the application checks them in or
exits.
MAX
Limit usage for a particular feature/group--
prioritizes usage among users.
MAX_OVERDRAFT
Limit overdraft usage to less than the amount
specified in the license.
NOLOG
Turn off logging of certain items in the debug log
file.
REPORTLOG
Specify that a report log file suitable for use by the
SAMreport license usage reporting tool be written.
RESERVE
Reserve licenses for a user.
TIMEOUT
Specify idle timeout for a feature, returning it to
the free pool for use by another user.
TIMEOUTALL
Set timeout on all features.

You can include comments in your options file by starting each comment line with a pound sign "#." Everything in an options file is case sensitive. Be sure that user names and feature names, for example, are entered correctly.

Feature Specification

Starting with FLEXlm v5, you can specify options for a particular line of a given feature name, as follows:

feature:keyword=value

For example:

f1:VERSION=2.0

You can specify a feature by any of the following fields:

VERSION=, HOSTID=, EXPDATE=, KEY=, SIGN=, VENDOR_STRING=, ISSUER=, NOTICE=, dist_info=, user_info=, asset_info=

In FLEXlm v5.11 or later, you can use a package name in place of a feature name, and the option will apply to all of the components in the package.

The following option keywords restrict who may use licenses or where licenses may be used: EXCLUDE, EXCLUDEALL, INCLUDE, INCLUDEALL, MAX, and RESERVE. These options take a type argument, which specifies whether the restriction is based on USER, HOST, DISPLAY, INTERNET, or PROJECT:

On PCs, the USER, HOST and DISPLAY name are all set to the PC's host name.

The types listed above take a list of members, separated by spaces. For example:

EXCLUDE coolsoft USER joe barbara susan

Other valid types are GROUP and HOST_GROUP. These allow you to define a group of users or hosts on a separate line in the options file, then use those group names instead of an explicit list. For example:

GROUP stars joe barbara susan
EXCLUDE coolsoft GROUP stars

6.2.1 EXCLUDE

EXCLUDE feature[:keyword=value] type {list | group_name}

Excludes a list or pre-defined group of users, etc. from the list of who is allowed to use the feature. Excluded users will not be allowed to use the feature. EXCLUDE overrides INCLUDE.

feature
Name of the feature being affected.
type
One of USER, HOST, DISPLAY, INTERNET,
PROJECT, GROUP, or HOST_GROUP.
list
List of type members to exclude.
group_name
Name of the group to exclude.

To exclude the user "hank" from the list of users able to use feature "f1":

EXCLUDE f1 USER hank

6.2.2 EXCLUDEALL

EXCLUDEALL type {list | group_name}

Excludes a list or pre-defined group of users, etc. from the list of who is allowed to use all features served by this vendor daemon.

type
One of USER, HOST, DISPLAY, INTERNET,
PROJECT, GROUP, or HOST_GROUP.
list
List of type members to exclude.
group_name
Name of the group to exclude.

To exclude any user on the machine "chaos" from using all features served by this vendor daemon:

EXCLUDEALL HOST chaos

6.2.3 GROUP

GROUP group_name user_list

Defines a group of users for use in INCLUDE, INCLUDEALL, EXCLUDE, EXCLUDEALL, and RESERVE option lines.

group_name
Name of the group being defined.
user_list
List of user names in that group.

To define the group "Hackers" consisting of "bob," "howard," and "james":

GROUP Hackers bob howard james

Note: In FLEXlm v3.0, multiple GROUP lines will add all the specified users into the group. Pre-v3.0 FLEXlm daemons do not allow multiple GROUP lines to concatenate--the last GROUP line would define the GROUP.

Note: In FLEXlm v4.0 or later, USER_GROUP is an alias for GROUP.

6.2.4 HOST_GROUP

HOST_GROUP group_name host_list

Defines a group of hosts for use in INCLUDE, INCLUDEALL, EXCLUDE, EXCLUDEALL, and RESERVE option lines. Multiple HOST_GROUP lines will add all the specified hosts into the group.

group_name
Name of the group being defined.
host_list
List of host names in that group.

To define the host group "Pacific" consisting of "tokyo," "seattle," and "auckland":

HOST_GROUP Pacific tokyo seattle auckland

6.2.5 INCLUDE

INCLUDE feature[:keyword=value] type {list | group_name}

Includes a list or pre-defined group of users, etc. in the list of who is allowed to use the feature. Anyone not in an INCLUDE statement will not be allowed to use that feature. EXCLUDE overrides INCLUDE.

feature
Name of the feature being affected.
type
One of USER, HOST, DISPLAY, INTERNET,
PROJECT, GROUP, or HOST_GROUP.
list
List of type members to include.
group_name
Name of the group to include.

To include user "bob" in the list of users able to use feature "f1":

INCLUDE f1 USER bob

Note: INCLUDE is required for USER_BASED or HOST_BASED features. The system administrator specifies which users are allowed to use the product, via INCLUDE, and the license limits the number of users that can be INCLUDEd.

6.2.6 INCLUDEALL

INCLUDEALL type {list | group_name}

Includes a list or pre-defined group of users, etc. in the list of who is allowed to use all features served by this vendor daemon. Anyone not in an INCLUDEALL statement will not be allowed to use these features.

type
One of USER, HOST, DISPLAY, INTERNET,
PROJECT, GROUP, or HOST_GROUP.
list
List of type members to include.
group_name
Name of the group to include.

To allow the user "jane" to use all features served by this vendor daemon:

INCLUDEALL USER jane

6.2.7 LINGER

LINGER feature[:keyword=value] seconds

Rarely used. This causes the daemon to "hold on" to the license for feature for seconds after the application checks the license in or exits. This could be useful for short-duration programs which will be used many times in a row by the same user, to ensure that the user will be able to re-acquire the license repeatedly. On the other hand, other users have to wait until the first user is completely finished, plus a linger interval. This is useful only if the application uses duplicate grouping. Otherwise, LINGER will cause you to use extra licenses. Contact your software vendor for information about how they implemented duplicate grouping in their product.

If license lingering is set and lmremove is used to reclaim the license, lmremove will start, but not override, the license's linger time.

6.2.8 MAX

(v5.11+ vendor daemon only.)

MAX num_lic feature[:keyword=value] type {list | group_name}

Limits usage for a group or user.

num_lic
Usage limit for this user or group.
feature
Feature this limit applies to.
type
One of USER, HOST, DISPLAY, INTERNET,
PROJECT, GROUP, or HOST_GROUP.
list
List of type members to limit.
group_name
Name of the group to limit.

6.2.9 MAX_OVERDRAFT

MAX_OVERDRAFT feature[:keyword=value] num_lic

Limits OVERDRAFT license usage below the OVERDRAFT allowed by the license file.

6.2.10 NOLOG

NOLOG { IN | OUT | DENIED | QUEUED }

Suppresses logging the selected type of event in the debug log file.

To turn off logging of checkins:

NOLOG IN

To turn off logging of checkouts and queued requests two separate NOLOG lines are required:

NOLOG DENIED
NOLOG QUEUED

Note: License administrators might use this option to reduce the size of the debug log file.

6.2.11 REPORTLOG

REPORTLOG [+]report_log_path

REPORTLOG specifies the report log file for this vendor daemon. We recommend preceding the report_log_path with a + character to append logging entries, otherwise the file will be overwritten each time the daemon is started.

Note: SAMreport, a separate product available from GLOBEtrotter, is used to process FLEXlm report log files. SAMreport can process only report log files, not debug log files.
Reporting on Projects with LM_PROJECT

The SAMreport report writer can report on "projects." A project is set up by having all users working on a project set their LM_PROJECT environment variable (or registry on Windows) to a string that describes the project. SAMreport can then group usage by project, as defined by what LM_PROJECT was set to when the application was run.

See also Appendix C, "FLEXlm Environment Variables."

6.2.12 RESERVE

RESERVE num_lic feature[:keyword=value] type
{list | group_name}

Reserves licenses for a specific user.

num_lic
Number of license to reserve for this user or
group.
feature
Feature this reservation applies to.
type
One of USER, HOST, DISPLAY, INTERNET,
PROJECT, GROUP, or HOST_GROUP.
list
List of type members to reserve licenses for.
group_name
Name of group to reserve licenses for.

To reserve one license of feature "f1" for user "mel":

RESERVE 1 f1 USER mel

Note: Any licenses reserved for a user are dedicated to that user. Even when that user is not actively using the license it will be unavailable to other users. However, a RESERVEd license will not cause an overdraft to be reported by SAMreport if the license is not actually in use.

6.2.13 TIMEOUT

TIMEOUT feature[:keyword=value] seconds

Sets the time after which an inactive license is reclaimed by the vendor daemon.

feature
Name of the feature.
seconds
Number of seconds after which inactive license is
reclaimed.

To set the timeout for feature "f1" to one hour (3600 seconds):

TIMEOUT f1 3600

TIMEOUT checks in the licenses if the process has been "idle" for a period longer than the specified time period. The daemon declares a process idle when it has not heard from the process (the client sends heartbeats). The application must explicitly declare itself idle for this to work, or (on UNIX) the application must be stopped (^Z). That is, unless the appli