False Denial Filtering

If denial monitoring has been enabled, historical denial reports will be available. Denials are obtained from the debug log of the license daemon and are filtered when parsed so that false denials are not loaded into the Monitor database and included in reports.

Denials are recorded in a debug log with an event label, such as the "DENIED" label in FlexNet Publisher. The denied label in the debug log cannot be relied upon to always indicate a true denial of a license checkout. There are many situations that can create false denials.

Monitor handles the following false denial situations.

False Denial Example 1: Denial Followed by Denial (same second)

This example shows two denials that occurred in the same second:
14:59:00 (xyzd) DENIED: "Affirma" jas@cs2  (Licensed number of users already reached(-4,342))
14:59:00 (xyzd) DENIED: "Affirma" jas@cs2  (Licensed number of users already reached(-4,342))

The first denial is filtered as false because within the same second that another denial occurred.

False Denial Example 2: Denial Followed by Denial (window)

This example shows two denials that occurred within a 10-second window of one another:
14:59:00 (xyzd) DENIED: "Affirma" jas@cs2  (Licensed number of users already reached(-4,342))
14:59:09 (xyzd) DENIED: "Affirma" jas@cs2  (Licensed number of users already reached(-4,342))

The first denial is filtered as false because within the 10-second window that another denial occurred. The window is configurable (default: 10 seconds). Refer to General Monitoring Configuration for details on configuring the window.

False Denial Example 3: Denial Followed by Checkout

This example shows multiple denials, followed by an immediate checkout:
14:59:00 (xyzd) DENIED: "Affirma" jas@cs2  (Licensed number of users already reached(-4,342))
14:59:01 (xyzd) OUT: "Affirma" jas@cs2

This is filtered as a false denial because a checkout was obtained within 1 second that denial event occurred.

False Denial Example 4: Equivalent Features

Some tools can utilize more than one license feature to satisfy its licensing requirement. These tools will have some hard-coded order in which they attempt checkouts, and will continue to search through the available features until it finds one that is available for checkout:
23:14:24 (xyzd) DENIED: "Affirma" edl@cs82 (Licensed number of users already reached(-4,342))
23:14:24 (xyzd) DENIED: "Affirma" edl@cs82 (Licensed number of users already reached(-4,342))
23:14:25 (xyzd) DENIED: "Affirma" edl@cs82 (Licensed number of users already reached(-4,342))
23:14:25 (xyzd) DENIED: "Affirma" edl@cs82 (Licensed number of users already reached(-4,342))
23:14:26 (xyzd) OUT: "MM_Sim" edl@cs82  
In this example, the tool first tries to check out an "Affirma" license but then falls back on a "MM_Sim" license within 1 second. From the point of view of the tool, there is no denial, and thus Monitor can be instructed to not consider it one. To eliminate these denials, include the following statement in the licmon.swd/config/parser.cfg file:
defineAlternativeFeatures "MM_Sim" "Affirma" 

If the file does not exist, an example file exists at $VOVDIR/etc/config/lm/parser.cfg that can be copied, or the file may be created by hand.

Filter Improvements

Altair relies on customer feedback to determine the effectiveness and areas of improvement for denial filtering. Engineering will modify the heuristics of the filters as new false denial situations are reported to Altair Engineering Support.

Monitor Support

Currently, Monitor supports parsing FlexNet Publisher, Dassault DSLS, and Altium debug logs for denial information. CodeMeter debug logs do not contain denial information. Please contact Altair Engineering Support to request support for additional license managers if needed.