Exelis VIS's IDLToken Based License System for FLEXnet/FLEXlm Server-based Licenses

Topic:

Customers of IDL and IDL-based products are sometimes confused by the license count number that appears for the features called "idl" and "idl_rt" on the INCREMENT lines in Exelis VIS 'license.dat' files. We call that count the "number of tokens". There is a distinction between that number and the count of license privileges given by that license, which we refer to as "number of seats".

An IDL user session seat is functionally defined as any number of simultaneous IDL process sessions that are running on a single host system, owned under a single username, and displayed to a single physical display.

This Help Article discusses the meaning of the token count and how it relates to the number of seats.

For further information regarding the information contained in the licenses please see TechTip 1675.

Scope of this Article: IDL and IDL Runtime server based license features.

This article discusses IDL and IDL Runtime license units (tokens) and only with respect to license server-based license files (license files that contain a SERVER line). Unserverd license files* implement a different license seat access mechanism and are not discussed in the body of this article.

* Unserved license files do not include a SERVER line and do not require administration by a license manager process or service. Here is an example of an unserved license file:

############ license file comments, do not delete ###############
# License Number(s): 1234
#
INCREMENT idl idl_lmgrd 6.300 01-jan-0000 093E59FE832D8 \
   VENDOR_STRING="1234Example License" HOSTID=123456ABCDEL \
   PLATFORMS="i86_n x64_n" ck=120
##################### end of license file #######################


Discussion:
A typical FLEXlm license file contains structural elements that control which products may run, how many sessions of the product may run, and on which machine the license manager runs. In addition, the number of license units (or tokens) of the FEATURE or INCREMENT lines control the number of copies of the product that may run concurrently. These license units also dictate what operating systems are authorized to run a particular product.

Different types of computers require different numbers of license units to run IDL. The break down is as follows:

License Class Operating System License Tokens per 1 License Seat Unix Class UNIX Systems (i.e. Solaris, AIX, IRIX HP-UX...) 10 tokens PC Class * Mac Systems 6 tokens Windows Systems 6 tokens Linux Systems 6 tokens

Table 1: IDL License tokens required per IDL user session by operating system

* We refer to Windows, Linux and Mac OSX systems, which require 6 license tokens per 1 IDL license seat, collectively as "PC class" systems.

TIP #1 (Counting license tokens for "idl" and "idl_rt" product license features vs. other product features) Unlike the token count convention for the product features "idl" or "idl_rt", other ITT product license features such as "envi", "idl_dm", "idl_dicomex_rw", etc... have a one-to-one correleation between the number of license tokens (units) and the number of available license seats for that feature. For example, a 2-user server-based node-locked Linux (PC-class (6 token)) ENVI+IDL license would contain an "idl" INCREMENT line that has 12 tokens (6 x 2) and an "envi" INCREMENT line that contains 2 tokens.

The operating system class associated with your license contract specifies which token rules it follows in the creation of the license file. For example, a UNIX class server-based IDL license will be built with 10 tokens per licensed seat, while PC class server based license files having the same number of IDL seats, will be built with 6 tokens per licensed seat. The two licenses below are an example of a 10 and a 6 token floating license.

UNIX Class ENVI+IDL 1-User Floating License:

############ license file comments, do not delete ###############
# License Number(s): 1234
#
SERVER ServerB 000123abc456 1700
DAEMON idl_lmgrd
USE_SERVER
INCREMENT envi idl_lmgrd 4.300 01-jan-0000 1 123456ABCDEL9876541A \
   VENDOR_STRING="1234Example License"
INCREMENT idl idl_lmgrd 6.300 01-jan-0000 10 123456ABCDEL9876541A \
   VENDOR_STRING="1234Example License"
FEATURESET idl_lmgrd 7C0C27B17BC61B90
##################### end of license file #######################


PC Class ENVI+IDL 1-User Floating License:

############ license file comments, do not delete ###############
# License Number(s): 1234
#
SERVER ServerA 000123abc456 1700
DAEMON idl_lmgrd
USE_SERVER
INCREMENT envi idl_lmgrd 4.300 01-jan-0000 1 123456ABCDEL9876541A \
   VENDOR_STRING="1234Example License"
INCREMENT idl idl_lmgrd 6.300 01-jan-0000 6 123456ABCDEL9876541A \
   VENDOR_STRING="1234Example License"
FEATURESET idl_lmgrd 7C0C27B17BC61B90
##################### end of license file #######################


The token count is the number that follows the "1-jan-0000" (or other) date string. Notice that our examples show both ENVI and IDL license features. The token unit rules mentioned above only apply to the (idl and idl_rt) INCREMENT lines. ENVI and other Exelis VIS product feature INCREMENT lines show the exact license privileges, the exact number of seats.


How do seats correlate into the token system?

Seats will dictate how many extra tokens to add to a particular license. For example, a PC class, IDL Increment line, that has 2 seats will have a total of 12 tokens. The below is an example showing the idl tokens in a 2 seat PC class license INCREMENT line:

INCREMENT idl idl_lmgrd 6.300 01-jan-0000 12 1D762024614571D8415B \

Here is an example of a UNIX Class IDL license INCREMENT line with 3 seats:

INCREMENT idl idl_lmgrd 6.300 01-jan-0000 30 1D762024614571D8415B \


What does this mean for me?

TIP #2 (Heterogeneous networks and mixing license classes and license server machines) IDL sessions running on a machine of one operating system class can check out floating IDL license seats served by a license server machine of a different OS class and/or from a license file of a different OS class. The IDL license file class and the license server machine class don't need to correspond. That is, a UNIX class machine can serve IDL license seats from a PC class license file, and a PC class machine can serve IDL license seats from a UNIX class license file. Similarly, a license server machine of one class can serve licenses to machines of its own class or of the other class. That is, a UNIX class machine can serve licenses for IDL sessions running on either or both PC class and UNIX class machines. Likewise, a PC class machine can serve licenses to PC class and UNIX class machines. The number of idl or idl_rt tokens actually checked out by an IDL session depends on the operating system (UNIX class or PC class) of the IDL host machine. (See table 1: IDL license tokens required per IDL user session by operating system)

What this means is that a license manager serving a UNIX class IDL license with 1 seat (10 tokens), can provide a single IDL license seat to an IDL session running on a UNIX (requires 10 idl tokens), Mac (6 tokens), Windows (6 tokens), or Linux (6 tokens) system.

However, a license server that is managing a PC class (Mac, Windows or Linux) license with 1 seat (6 tokens), can only serve a single IDL license seat to a PC class system. An IDL session running on a UNIX system that attempts to check out an IDL license seat from a license server that can offer only 6 idl license tokens will fail because 10 idl license tokens would be required in this case.

Now if you take that same one-IDL seat, PC class, license file and incorporate additional IDL feature INCREMENT lines (adding purchased IDL licenses), or increase the number of licensed seats in the existing INCREMENT line, then there will be enough IDL tokens for the UNIX system to check out an IDL seat. How does this work, you ask? Since our license files are FLEXlm-based, the license manager will actually pool all the available floating licenses for a particular product feature together (or pool node-locked tokens for the same product feature that are locked to the same node-locked host ID). This will give you enough tokens to authorize different system classes to check out licenses from the license server source.

TIP #3 A server-based ITT product license file can be composed of multiple classes of license INCREMENT lines. Floating license tokens from different INCREMENT lines for the same product feature will be available as a combined pool of floating tokens. Similarly, node-locked license tokens for a particular host machine ID from different INCREMENT lines for that product feature will be available as a combined pool of node-locked tokens for that particular machine's host ID. For example, suppose a license.dat file is composed of INCREMENT lines for a UNIX class 2-user floating ENVI+IDL license and PC class 3-user floating IDL license. The resulting license.dat file might look like this: ############ license file comments, do not delete ############### # License Number(s): 1234 # SERVER ServerB 000123abc456 1700 DAEMON idl_lmgrd USE_SERVER INCREMENT envi idl_lmgrd 4.300 01-jan-0000 2 123456ABCDEL9876541A \    VENDOR_STRING="1234Example License" INCREMENT idl idl_lmgrd 6.300 01-jan-0000 20 123456ABCDEL9876541A \    VENDOR_STRING="1234Example License" INCREMENT idl idl_lmgrd 6.300 01-jan-0000 18 123456ABCDEL9876541A \    VENDOR_STRING="1234Example License" FEATURESET idl_lmgrd 7C0C27B17BC61B90 ##################### end of license file ####################### In this case, only 2 ENVI+IDL (or even plain ENVI) session license seats are available from this license, restricted by the 2 envi tokens. However if only IDL sessions (with out ENVI) were being used, then the pool of floating idl tokens would be combined for a total of 38 idl tokens. With this pool of idl floating tokens, up to 6 simultaneous PC class IDL license seats (36 tokens) could be checked out. If mixed classes of IDL sessions were running simultaneously, for example, 3 UNIX class IDL license seats (30 tokens) and 1 PC class IDL seat could be checked out at the same time from this license.

Example 1:

Issue:

We have a two-user Linux IDL Floating license. Sometimes only 1 IDL license seat is available to the machines on the network.

Discussion:

In this case Server A (which happens to be a Linux machine) has two INCREMENT lines in a license file, with each line having one Floating IDL PC class seat, (6 "idl" tokens each). FLEXlm pools all available floating tokens together, thus giving Server A 12 "idl" tokens = 2 IDL PC class seats.

############ license file comments, do not delete ############### # License Number(s): 1234 2345 # SERVER ServerA 000123abc456 1700 DAEMON idl_lmgrd USE_SERVER INCREMENT idl idl_lmgrd 6.300 01-jan-0000 6 123456ABCDEL9876541A \    VENDOR_STRING="1234Example License" ck=10 INCREMENT idl idl_lmgrd 6.300 01-jan-0000 6 123456ABCDEL9876541A \    VENDOR_STRING="2345Example License" ck=11 FEATURESET idl_lmgrd 7C0C27B17BC61B90 ##################### end of license file #######################

Machine 1 is a UNIX system on which a user starts an IDL session which connects to Server A to check out 1 IDL UNIX class license seat, or 10 of the 12 "idl" tokens, leaving a remainder of 2 "idl" tokens.

A user working on Machine 2 a Windows system, tries to check out an IDL license seat from Server A. Since there are not enough "idl" tokens (only 2 remaining), the IDL session on Machine 2 cannot check out an IDL license seat despite the fact that the original license file was purchased and issued "2" Floating license seats. The issue is that these are PC Class license seats providing a total of 12 "idl" floating tokens, but then one IDL session running on a UNIX class machine checked out 10 "idl" tokens or one UNIX class IDL license seat from Server A.

**Had the first machine been a PC class system, then two IDL user sessions each running on PC class machines, which use just 6 tokens each, could have checked out two license seats from Server A. **

Example 2:

Issue:

We have a one-user Windows IDL Floating license for our network. Why can't users running IDL on Solaris check out the license?

Discussion:

In this case, Server B is serving a PC class one-user Floating IDL license file and so there are only 6 available "idl" floating license tokens:

############ license file comments, do not delete ############### # License Number(s): 1234 # SERVER ServerB 000123abc456 1700 DAEMON idl_lmgrd USE_SERVER INCREMENT idl idl_lmgrd 6.300 01-jan-0000 6 123456ABCDEL9876541A \    VENDOR_STRING="1234Example License" ck=10 FEATURESET idl_lmgrd 7C0C27B17BC61B90 ##################### end of license file #######################

Similar to the situation described in Example 1, Machine 2 is a UNIX class machine such that IDL sessions running there will require 10 "idl" tokens per user session. Since there are only 6 "idl" license tokens available from Server B IDL sessions running on Machine 2 will not be able to check out enough "idl" tokens from Server B to support a license IDL user seat.

On the other hand, Machine 3, a Windows system, can check out an IDL license seat from Server B since only 6 "idl" tokens would be required.

** Had Server B had 2 PC class IDL license seats in its license file, then the UNIX client could have connected as in Example 1. **Solution: