KOMAND Tips:

• You will be happier with KOMAND if you do not force it to fill roles it was not really designed for, such as:
  • Capacity planning
  • Project management.
• If poorly set up, KOMAND tables can become maintenance-intensive. KOMAND can run automatically and virtually hands-off, if you:
  • Choose account codes that are general-purpose and stable (adding new accounts should be rare).
  • Enforce meaningful, strict naming conventions for user IDs, job names, file names, etc.
  • Assure that all jobs and users input proper account codes.
• "Don't spend dollars chasing pennies." Weigh the benefits of extra detail, processing, and maintenance against the costs of doing it.
• Change rates as infrequently as possible.
  • It's hard enough for your customers to budget once per fiscal year. Changing rates often, in effect, amounts to "variable rates," and makes chargeback more complicated and difficult for everyone.
  • Base your rates on actual resource usage as captured by KOMAND, not on usage reported by an unrelated product.
  • Let managers reduce their usage in order to reduce their costs. Saving capacity will benefit everyone in the long run.
  • Inequities even out over time.
• Beware rounding error! There are many ways it can creep in.
  • Fractional cents in rates can cause large rounding errors when applied to thousands of records, due to the fact that charges are only reported in whole cents. Examples: If you run a CA-7 tape library charging interface daily, you cannot charge 1.5 cents per day per tape; it will be truncated to 1 cent. Similarly, if the disk rate per track is $0.001, files smaller than 10 tracks will be charged zero.
  • Interface HISTORY and MUR records do not store the same decimal precision. You can get different answers from the same input data, depending on which output file you look at with DIS.
  • SAS and COBOL do not represent "0.5" the same way internally, so be careful when using SAS to verify KOMAND's bottom line. SAS actually uses "0.49999..." which adds up over thousands of records to report a significant difference from KOMAND's COBOL and Assembler program totals.
• Don't worry about "capture ratio" unless it gets out of hand.
  • Some competing products frighten customers by claiming that they are losing 7% of CPU time because KOMAND uses only SMF. They do not explain that this time would be charged as overhead, anyway. Extra processing to recover this "lost" data carries its own cost.
  • Incorporating this "missing" time into KOMAND rates is automatic and painless if you just ignore it and use KOMAND's reported usage as the basis for your rates.
  • If you are losing much more than 7%, look to blocking factors or other potential causes for dropped SMF records.
  • For those who remain unconvinced: Think of that 7% "loss" as tiny leaks in a water utility's lines. They cannot charge for water that their customers' meters do not report, therefore their billable usage should reflect only what customers received, not what left the reservoir. (Should customers pay for evaporation?) Rates based on their costs and the customers' usage will then automatically make up for the 7% "loss." As long as the leaks are small, it is less expensive for the utility (and the customer!) to ignore than to fix them.