1. Ensuring Affordable Access to Complete Usage Data ENH Records Improved Reporting with an Enhanced Debug Log

2. Motivation: SAM and Sources of Usage Data usage analysis is a critical element of a software asset management (SAM) program – provides information to enable many software business issue decisions license manager log files are the primary source of usage data – enterprise end users have little to no control over choice of license manager Flex is by far the dominant license manager in use today

3. Motivation: Flex Log Files the Flex license manager creates 2 log files – debug log ASCII, open text basic information only – no precise out/in matching – no license sharing details – no project information – no software version details – no token usage details – report log encrypted (closed), requires proprietary tools more complete usage information – no token usage details

4. Motivation: Goals complete – all necessary/desired information open – ASCII text – published specification can be validated – usable by ISVs for pay-per-use and compliance verification ease of deployment – fast deployment: daemon based not client based – ISV development effort must be low affordable – for ISVs: integration and licensing costs can not discourage implementation – for end users: analysis tools must be priced to make buy/develop decision easy

5. How It Works: Using Available Callbacks Flex ISV customers are provided callbacks they can use in their vendor daemons they can write whatever they want into the debug log during these callbacks the Enhanced Logging Initiative convened interested parties to define: – a common format for enhanced records to be written into the debug log – common source code for vendor daemon integration to write the enhanced records

6. How It Works: Registering ENH Functions to Callbacks if ISVs are already using callbacks – then add calls to ENH functions in the existing callback functions if ISVs are not using the callbacks – then register the ENH functions to the callback primary ENH functions – enh_init() called after lmreread determines duplicate grouping information from FEATURE lines in license files – enh_out() called in the pre-checkout filter writes an ENH_OUT record – enh_in() called in the pre-checkin filter writes an ENH_IN record

7. How It Works: Building an ENH Daemon add LTI provided source to daemon build environment (source tree and makefile) modify two files (enh_vendor.c and enh_vendor.h) to customize for the specific software vendor register or modify callbacks build -> test -> deploy approximate level of effort -> ½ day

8. How It Works: Enabling the ENH Daemon standard vendor daemon replacement process set environment variable _ENH_RECORDS=1

9. How It Works: Processing ENH Records ENH_OUT records (pre-checkout) – process subsequent “standard” debug records to determine checkout or denied queuing or update ENH_IN records (pre-checkin) – process subsequent “standard” debug records to determine linger or direct checkin

10. ENH Records: Basic Usage Logging Standard Fields FieldTypeDescription featurestringfeature name userstringuser logon ID hoststringhost name timestampstringmilliseconds since 00:00:00 Jan. 1, 1970 (UTC) formatted as.mmm num_licensesintnumber of licenses requested/returned session_handleinthandle assigned by the license server displaystringdisplay details addrstringIP address of user

11. ENH Records: Basic Usage Logging Advanced Fields FieldTypeDescription dup_groupstringduplicate grouping N - none S - site UHDV - user, host, display, vendor if V, then V: projectstringvalue of LM_PROJECT sw_versionstringversion of software checking out the feature lingerintlinger period, in seconds ENH_IN only

12. ENH Records: Basic Usage Logging Token System Fields FieldTypeDescription actual_featurestringname of actual software feature used for token feature checked out actual_feature_countintegernumber of licenses of the actual feature used

13. ENH Records: Basic Usage Logging, ENH_OUT & ENH_IN ENH_OUT – output during the pre-checkout callback – provides all additional information needed for a detailed OUT or DENIED hh:mm:ss (daemon_name) ENH_OUT: “feature” user@host timestamp num_licenses session_handle “display” addr dup_group “project” “sw_version” “actual_feature” “actual_feature_count” ENH_IN – output during the pre-checkin callback – provides all additional information needed for a detailed IN, or detection of a “lingered” checkout hh:mm:ss (daemon_name) ENH_IN: “feature” user@host timestamp num_licenses session_handle “display” addr dup_group linger “project” “sw_version” “actual_feature” “actual_feature_count”

14. ENH Records: Log File Integrity ENH_SECURITY – indicates that log file security is being used – indicates which digest technique is being used – output during the enh_init() function hh : mm : ss ( daemon_name ) ENH_SECURITY: “ digest_method ” ENH_DIGEST – provides data for post processing to ensure log file integrity – obfuscated with a vendor specific pass phrase – output whenever one of two conditions is met length of text in digest number of records in digest hh : mm : ss ( daemon_name ) ENH_DIGEST: “ digest ”

15. ENH Records: Other Records ENH_VERSION – mandatory – output during enh_init() – provides ENH Records specification version hh : mm : ss ( daemon_name ) ENH_VERSION: version ENH_VENDOR – optional – provides some information for ISV specific post analysis – output whenever vendor chooses, ignored by License Tracker hh : mm : ss ( daemon_name ) ENH_VENDOR: “ name ” “ value ”

16. What It Costs for ISVs – source code license -> $0 – source code royalties -> $0 – integration effort -> approx. ½ day – for ISVs using ENH records for pay-per-use licensing or for compliance validation, a license for the License Tracker toolset is required for enterprise end users – for ENH daemon -> up to ISVs, likely $0 – for License Tracker software no additional cost -> just another data source

17. “You can only optimize - what you understand… …and you can only understand - what you track!” www.licensetracker.ca