Created by Knowledge Admin on Apr 4, 2016 2:19 AM. Last modified by Knowledge Admin on Mar 20, 2019 5:40 PM.
Llicense reporting utility (version 7.5.10 and later) for BMC Performance Assurance. Several enhancements have been made in this version, and this documentation supercedes that for earlier versions.
You must run the reporting utility from a computer where you have access to your BMC Visualizer database(s).
You must run the reporting utility once for each BMC Visualizer data source in your environment.
The license information produced by the reporting utility is based on the data stored in the BMC Visualizer database. If information has been deleted from the database, the usage data generated by the utility might not be accurate.
The reporting utility reports the CPU (socket) count based on the physical cores that are presented to the operating system (which is stored in the Visualizer database). The current version of BMC Performance Assurance also captures the core configuration ("cores per socket" and "threads per core") from the physical hardware. The accuracy of this data is dependent on the version of the data collector, the management console version, and the particular platform being observed.
Accurate classification of servers as physical or virtual depends on having adequate versions of the BPA agent and console.
The license reporting utility produces usage data is based on the BMC Performance Assurance product, which might not agree with what was originally purchased under tier pricing or previous product names, or current product licensing options.
If you're using the Capacity Optimization console as well as the Performance Assurance console, each server only counts once for licensing, regardless of how many times it's been reported.
Make sure you create an ODBC connection to the BPA database.
Note that this utility is the same as what's executed when selecting the Generate Usage Report by CPU option documented at docs.bmc.com/docs/display/public/bcmco95/Working+with+the+Maintenance+Tool+License+Usage+Report+tab.
Also this utility can be used to obtain detailed results supporting the summarized result reported by the Generate Usage Report By Asset option. Note that the results reported by this option are not implemented via ProdUse, and are a separate set of queries documented below.
The command for running the reporting utility has several options that control the execution of the command. The command uses the following general syntax, and its options are described in Table 1. Separate options with a blank space.
· If you are running the utility in extract mode, you must specify the name of the BMC Visualizer system data source name (DSN).
· If you are running the utility in csv or text mode, you must specify the directory path where the csv output of the extract mode is stored.
specifies the output directory, where the output files and log files are written This directory must be an existing directory; the utility does not create it dynamically.
1. On the computer where a BMC Visualizer database is installed, open a command prompt.
2. Change directory to the location of the license reporting utility.
4. Repeat this step for each BMC Visualizer data source in your environment, using the same output directory each time that you run the utility. The output must be stored in the same directory so that the data from each run will be merged when you create the final usage reports.
The following example runs the command in extract mode.
·Scan a BMC Visualizer data source named WalSys.
·Generate a CSV output file that contain both summary and detail usage information; it has the same name as the data source from which it was created.
·Store the output in a directory named C:\license_output.
· “Intervals” is the number of data intervals in this database for which performance data was reported.
If you are using 1 hour intervals for reporting, that would be 24 intervals per day, and about 720 intervals per month; for 15 minute intervals, it’s 96 intervals per day and about 2880 per month.
ProdUse.exe is supplied as part of Perceiver (%PERCEIVER_HOME%/CWA) as well as the Windows management console (%BPA_HOME%). When patches are provided for either of these packages, an updated ProdUse is supplied.
This document is current as of version 9.5.00.0089 (information obtained by Properties, Version from the ProdUse.exe file).
that the BMC Performance Assurance Maintenance Tool portion of Perceiver or Windows console can be used to run this utility, but it does not allow you to specify a start and end date using the Maintenance Tool GUI (this restriction is current as of 9.5.02). You can use the command line version documented above if you want to specify a date range other than the last 365 days from today or you can apply the 9.5.02.01 CHF 2 or or 10.0.00.01 CHF 2 which contains a patch for defect QM001877569. This fixes the problem with the date in the GUI not being passed properly and it fixes an issue with the "by Asset" query which may crash or not return data.
Licensing can be based on the number of CPU sockets per managed host. This may or may not be how your specific license is written. Please check with your BMC account representative to verify what your licensing terms are.
For CPU socket licenses, you do not get charged separately for partitions on a host, or VIRTUAL systems on a host already licensed.
The current version of ProdUse is different from previous versions in that all CPU configuration data in the database is reported for the requested time period, then the user is expected to use Excel to sort/filter the data so that accurate license counts can be obtained.
For example, if multiple configurations are reported during the licensing period for one host, it’s relatively easy to determine that, and to then designate one configuration as the licensed one.
If there are any questions about accuracy or completeness of the CPU configuration reported, similar servers can be easily grouped together, and then evaluated as a group.
CPU Packages represents the calculated license count for each system.
When a system is reported in both CAXPSYS and CAXNODE, only one of those counts towards licensing, so exclude the CAXNODE report from the license count.
If you have LOGICAL systems, and you are using 7.5.00 console (or later), the physical system will be reported in the CAXPSYS table, so then all LOGICAL systems can be excluded from licensing counts. If you are not yet using 7.5.00, only one of the LOGICAL systems from each physical system needs to be counted.
Typically all VIRTUAL systems can be excluded from licensing counts as their physical hosts would already be listed (note that the physical host could be in a different Visualizer database or could be in your BCO database, if you have one).
All ZONE systems can be immediately excluded from licensing counts as their hosts will already be included elsewhere.
Q: How do I interpret License Utility output if I have a per managed endpoint license instead of a per CPU license?
Each server listed in CAXNODE with type "REGULAR" or in CAXPSYS counts for 1.
Each server listed in CAXNODE with type "LOGICAL" or in CAXVM/CAXEMVM would count for 1.
Each server list in CAXNODE with type "ZONE" or "WPAR" or in CAXWPAR would count for 1.
When a system is reported in both CAXPSYS/CAXVM/CAXEMVM/CAXWPAR and CAXNODE, only one of those counts towards licensing, so exclude one of the reports from the license count.
Each server listed in CAXNODE with type "VIRTUAL" counts 1 towards licensing if it's not reported someplace else, such as in CAXVM/CAXEMVM or as a guest entity in BCO.
Similar to the per CPU licensing, the key is that you only have to account for a server once, regardless of how many times it might be recorded in different forms or in different databases. Also similar to CPU licensing is that you should use Excel to sort and group servers in order to arrive at an accurate count.
Any consideration of cores, sockets, threading, etc. don't apply to this type of reporting.
Note that the current implementation of ProdUse does not obtain results from CAXVM or CAXEMVM, so if you have virtualizations which report exclusively to those tables, the detailed ProdUse output will report fewer servers than would be reported by the Generate Usage Report By Asset option. Support has obtained the queries used for managed endpoint as of version 9.5, and provided them in an attachment to this article. You can execute those queries and obtain the row-by-row results in order to confirm the high-level license counts output by the Generate Usage Report By Asset option.
Q: Does the License Utility properly report physical chip count for multi-core processors?
In general, the answer to this is yes for physical systems (using a BPA console and agent version 7.4.10 (or later) and a Visualizer 4.2.04 (or later) database schema).
This is done using the CAXNODE.Cores_Per_Socket field in the Visualizer database, (referred to by Cores per Package in the spreadsheet).
If the value for this field is -1, this would indicate that the information was not available (probably because you are not using the required versions of the components).
If the value for this field is 1 and the server is threaded, this would also indicate that the information was not available. An example of this would be Windows Hyper-Threading using proxy collection on a server with an OS earlier than Windows 2008.
Currently there is no ability to measure the cores per socket for AIX partitioned servers, so the value would always be shown as 1. Actually this value is more likely to be at least 2 (Power5, Power6) or more 4-8 (Power7). Note that even when multithreading/SMT is enabled, and Threads per Core is reported as 1, this is correct as far as getting an accurate configuration because all processor counts have already been corrected for SMT before being recorded in the configuration table(s).
Each of these exceptions are cases where you need to supplement the data from the database with realistic cores per socket values in order to re-calculate the number of sockets and reduce the license count. In these cases, you would need to manually override this value in the spreadsheet, and recalculate the number of CPU Packages.
For all physical systems, CAXPSYS entries have -1 reported for Threads per Core, because the threading (designated by HT/CMT) has already been adjusted for in the Total CPUs value, i.e. it is already the number of physical processors. So dividing Total CPUs (CAXMODEL.Max_Processors) by Cores per Package (CAXMODEL.Cores_per_socket) gives the correct result, and that's exactly what's been implemented in ProdUse. These same results can also be viewed using the Visualizer Graphics client, using Graphics -> Physical System -> License Reporting (by CPU), Sockets metric. Results are grouped by physical system type, as well as by processor type. Use Edit -> Show Table to export the results. The Visualizer display is suitable for checking a subset of systems for a limited period of time vs. the ProdUse approach which can be used to report over an entire year and any number of systems.
For systems recorded as type VIRTUAL (see a detailed description at KA391161), it's unlikely that what's been reported is accurate, because the operating system has in fact been virtualized. The observed processor count is in fact virtual and not physical, the hardware type is often missing or incorrect, the GHz can be incorrect, and cores per socket is usually 1, regardless of the underlying hardware. As mentioned earlier, usually you wouldn't be looking at this type of system for socket-based licensing since its physical host has been accounted for elsewhere in BPA or BCO. You can drill down on the results for this type of system using the Visualizer Graphics client, using Graphics -> Supportability -> License Reporting (by CPU), Sockets metric.