Dynamic Reservations

At certain times, it is desirable for one process to check out a license and ensure that a new process can get the same license. In order to accomplish this, RLM introduced the concept of a dynamic reservation.

While there may be many use cases for this within an ISV’s licensing design, the most general usage is in the case of job schedulers, such as IBM’s LSF and Runtime Design Automation’s WorkloadXelerator.

Dynamic reservations are accomplished with no changes to the RLM API - all capabilities are controlled via the environment variables RLM_RESERVE and RLM_RECLAIM. Of course, these variables can be set with the RLM API call rlm_setenv(). The reason we use environment variables for this capability is so that the job scheduler can set the environment before launching the ultimate application, and each ISV does not have to write code to specifically handle the dynamic reservation. Once linked with RLM v12.2+, every RLM-licensed application is enabled to use this capability.

To use a dynamic reservation, we will refer to the two processes as the reserving process – i.e., the process which creates the reservation, and the reclaiming process – the process which reclaims the license which was previously reserved.

How to use Dynamic Reservations

Creating the Reservation

In the reserving process, set RLM_RESERVE to:

isvname:#secs:string

Where:

isvname – is the name of the ISV which “owns” the license. If left blank, the current ISV name is used. If specified and different from the current ISV, then the checkout request will not perform encryption handshaking with the license server.

#secs – is the number of seconds to “hold” the reservation after the license is checked out by the reserving process.

string – is the string, or handle, that the reclaiming process must use to reclaim this license (max 32 bytes).

Once the license is checked out, the reserving process should check it back in, and start the reclaiming process within #secs seconds. Note that if the license itself specifies a hold time or a minimum_checkout time that time will apply to the checkout if the isvname is blank or the same as the current ISV. If the isvname is different from the current ISV, no hold time or minimum_checkout time will apply to the checkout itself.

If the ISV requesting the dynamic reservation is the same as the ISV that “owns” the licenses:

  • RESERVED, OUT and IN will all be logged in the debug log.

  • The new DYNRES line, OUT and IN will be logged in the report log.

If the ISV requesting the dynamic reservation is different:

  • Only the RESERVED line will be logged in the debug log.

  • Only the DYNRES line will be logged in the report log.

Other notes for dynamic reservations:

  1. Dynamic reservations are only supported on a license server (ie, not for node-locked, unserved licenses).

  2. If you ask to reserve N licenses, the server must have N free licenses available. Shared licenses do not count in this number, and other (non-dynamic) reservations do not count, either. In other words, the server does not consider licenses available for sharing or any reservations when computing the number of free licenses.

  3. You cannot QUEUE for dynamic reservations.

  4. Dynamic reservations do not work with Roaming or client caching.

  5. if both RLM_RESERVE and RLM_RECLAIM are set, RLM_RECLAIM takes precedence, in other words, the reservation will not be created.

Reclaiming the Reserved Licenses

In the reclaiming process, set RLM_RECLAIM to:

isvname:#secs:string

Where:

isvname – is the name of the ISV which “owns” the license. This will normally be blank, but in the case of a job scheduler which needs to cancel a reservation it created earlier, is will be filled in. If left blank, the current ISV name is used. If specified and different from the current ISV, then the checkout request will not perform encryption handshaking with the license server.

#secs – is the number of seconds to “hold” the reservation after the license is checked back in by the reclaiming process.

string – is the string, or handle, to reclaim the license.

Once the license is checked out, the reclaiming process can use it as normal, and at the end, the reservation will be released in #secs seconds. The license checkout is subject to the same rules as for the reserving process, i.e., if the license itself specifies a hold time or a minimum_checkout time that time will apply to the checkout if the isvname is blank or the same as the current ISV. If the isvname is different from the current ISV, no hold time or minimum_checkout time will apply to the checkout itself.

The reservation created by the reserving process will be independent of all the license restrictions specified in the license itself. So, for example, if that license is shareable by user/host, then the reclaiming process will be able to share the resulting license with other processes started on the same user/host. In this case, only the first process needs to present the handle to the server, the others can share that license without setting the RLM_RECLAIM environment variable.

Also note that once the reservation is created, multiple sequential processes can reclaim the same reservation with the RLM_RECLAIM environment variable. The last process which is going to use the reservation should set #secs to 0, so that the reservation goes away at that point. If a job scheduler creates a reservation, then later discovers that the jobs cannot continue to run, the scheduler can remove the reservation by setting RLM_RECLAIM with #secs set to 0.

Some notes and restrictions:

  1. Dynamic reservations are only supported on a license server (ie, not for node-locked, unserved licenses).

  2. You cannot QUEUE for dynamic reservations.

  3. Dynamic reservations do not work with ROAMING.

  4. If both RLM_RESERVE and RLM_RECLAIM are set, RLM_RECLAIM takes precedence.

  5. License sharing is never considered when creating dynamic reservations.

  6. Personal licenses and Dynamic reservations use the same variables for transport, so it is not possible to have a personal license that uses dynamic reservations. This is a minor restriction, since the use cases for these 2 kinds of licenses are so completely different.

Note

Dynamic reservations are not supported on Solaris.