Accuracy

The primary sampling method is to utilize the license manager status command on a periodic basis, parsing its output to find availability and utilization information. In versions prior to 2010.06, Monitor honored the checkout time reported by the status command. Throughout many experiences in the field, it has been discovered that this can lead to inaccurate utilization data. Some of the following scenarios have been encountered at customer sites, prompting the sampling methodology to change:

1. The status command fails to return all or part of the requested information, returning cleanly. If an active checkout was expected in the status command output, but is missing due to this type of failure, a premature checkin is created and loaded into the Monitor database. If a subsequent sampling comes back with a complete dataset and the checkout is once again present, a duplicate checkout is created using the same checkout time as the one already checked in, and eventually an attempt will be made to load it into the database. In versions prior to 2010.06, the database allowed duplicate checkouts (using a unique fingerprint of feature/checkout-time/user/handle).
2. The status command reports an inaccurate checkout time altogether. This has been seen when a live checkout is removed by the license manager checkout removal utility. If and when the tool reacquires a checkout, the checkout time is expected to be the reacquisition time, but instead is something between the original checkout time (for the checkout that was removed) and the reacquisition time. This new checkout overlaps the previous checkout due to the incorrect checkout time, causing an over-reporting of usage.

These scenarios, among others, as well as the fact that the reported checkout time for FlexNet Publisher is reported with 1-minute granularity, have prompted a change in the Monitor sampling methodology. In version 2010.06 and higher, the sampling time is used for the checkout time if the checkout was not detected in a previous sampling. If the checkout is already detected, the systems treats the checkout as a continuation of the pre-existing checkout. This removes the reliance upon the status command to be accurate with respect to the checkout time. The two above scenarios are now handled in the following ways:

1. For scenario 1, because the sampling time is used, there will be no duplicate checkout because the checkout times will be different. In the error condition mentioned, there will simply be a brief glitch in the continuation of the checkout that lasts as long as the error condition persists in the status command. As an additional level of protection, the database schema prevents duplicate checkouts from being loaded, based on the unique fingerprint of feature/checkout-time/user/handle.
2. For scenario 2, because the sampling time is used for the checkout time for new checkouts, the checkout time reported by the status command does not affect the checkout time in Altair Monitor, therefore, no overlap of usage occurs.

The following items are not typically available from the license manager status command:

• Process ID of the process for the checkout.
• Project (for FlexNet Publisher, the value of the LM_PROJECT variable).
• IP address of the host for the checkout.
• Checkin information. Monitor uses the absence of a previously-detected checkout as an indication of a checkin.
• Very short checkouts that are less than the sampling rate (default 30s).