The administrator must decide which lnodes are to be billed for resource usage. For example, administrators may only be concerned with billing entire departments. Thus, they may only want to bill the group headers of the topmost groups, whose accrued usage will include all the accrued usage of the lnodes at lower levels within their departments.
For administrators to be able to implement a billing system, they must determine a costing function for each resource to be billed. This can be a simple linear relationship (where unit cost is the same, regardless of the amount used), or it can be a non-linear relationship, such as a step function, or a curve where unit cost varies as the amount of usage varies.
In deciding upon a costing function for each resource, the administrators should keep in mind that the costing function will not only control the assignment of cost to accrued resource usage, it can also have an impact on the way in which a user uses the resource. For example, if the costing function for virtual memory usage causes the unit cost to increase as the amount of usage increases, there is a strong incentive for users to keep virtual memory usage low. Therefore, it is possible for administrators to control user behavior through the use of an appropriate costing strategy.
There is only one accrue attribute per resource. It contains the accrued usage for the resource based on the usage attribute for the resource. This means that there is no accrued usage corresponding to the myusage attribute. For group headers, there is no accrued usage for the user as an individual, because the accrue attribute holds the group's accrued usage. For lnodes with no children (leaf lnodes), this does not matter, since the myusage attribute and the usage attribute are identical. If a bill is required for the individual accrued usage for a group header, it must be calculated from the group total less the sum of the individual totals of each child in the group.
The default output of the liminfo command is designed for users who want to find out their current usages, limits, and privileges. liminfo is also of use to administrators who want to inquire on the attributes of other users. There are a number of different report formats that can be requested, including the use of options that make the output of liminfo suitable for processing by a pipeline of filters. Refer to liminfo(1SRM) for details of the command-line options and their meanings, and for a description of the fields that can be displayed.
The limreport command allows an administrator to query any attributes, including the accrue attributes, of any user. The command provides a flexible way to select information to be displayed from the chosen lnodes.
For example, the command:
% limreport 'cpu.accrue!=0' '%u %s %f\n' uid lname cpu.accrue
selects all lnodes with any accrued usage in the usr domain, and lists the UID and accrued usage attribute from each of the selected lnodes. To sort these values by cpu.accrue and list only the top 10 users, pipe the result to a sort command:
% limreport 'cpu.accrue!=0' '%u %s %f\n' uid lname cpu.accrue | sort -2n | head
Refer to limreport(1SRM) for additional information.
The limadm command can be used within a billing system to zero the accrue attributes after they have been billed. For example, the command:
# limreport 1 '%u\tcpu.accrue=0,mem.accrue=0\n' uid | limadm set -u -f -
uses the limreport command to generate a list of commands piped to limadm. Every lnode is selected, and for each lnode, the accrue attribute is zeroed.
The administrator should take care in determining when to clear the accrue attribute of an lnode. The timing will depend on the billing strategy. For example, if bills are to be produced at a group level, and then individual bills are to be produced for the group members, the accrue attributes of the group members should not be cleared until after both bills have been produced. However, if individual bills are not to be produced, the group members' accrue attributes should be cleared at the same time as the group header's, even though they may not have been individually used.
Refer to limadm(1MSRM) for additional information.