Click above to get retro games delivered to your door ever month!

 Accounting bindery properties
------------------------------------------------------------------------------
 The information used by the accounting services is stored in the following
 bindery properties:

 .  ACCOUNT_SERVERS
 .  ACCOUNT_BALANCE
 .  ACCOUNT_HOLDS

 ACCOUNT_SERVERS property

 When the accounting system of a file server is enabled (using the NetWare
 utility SYSCON), the ACCOUNT_SERVERS property is created for the file
 server object. The existence of this property can be tested for using the
 NOVLIB FSAccountingEnabledTest() function.
 This property contains the bindery object ID of every server, including the
 file server, which is authorised to submit accounting records to clients.
 For example, before a server can charge clients for its services, its
 object ID must be in the ACCOUNT_SERVERS property of the file server. (Any
 object that is security-equivalent to an object in the ACCOUNT_SERVERS
 property can also submit accounting records). This can be done using the
 NOVLIB FSAccountServerAdd() and FSAccountServerDelete() functions, which
 respectively add or delete an authorised account server.
 The ACCOUNT_SERVERS property is of type SET (see Chapter 3, Bindery
 Functions) and has read-Supervisor and write-Supervisor security access
 levels.

 ACCOUNT_BALANCE property

 When accounting is enabled, each user object is given an ACCOUNT_BALANCE
 property. Every user object created with SYSCON after accounting is enabled
 will also be given an ACCOUNT_BALANCE property. The account balance and
 minimum balance of an object are stored in this property. Servers can deny
 services to an object if the object has no ACCOUNT_BALANCE property.
 The ACCOUNT_BALANCE property is of type ITEM and has read-object and
 write-Supervisor security access levels.
 The account balance usually represents some monetary value, such as cents
 or yen. To avoid confusion, the system administrator must ensure that all
 servers submit their charges using the same monetary unit.
 If an object's account balance has no more funds, servers should refuse
 further service. However, if service has already been given, the server can
 charge for it even though no funds are in the account balance. This would
 make a negative account balance. Setting the minimum allowed balance to
 0x80000000 ( 134217728) indicates the object has no minimum balance, in
 which case service should never be refused.

 Property fields

 The fields in the first data block of the ACCOUNT_BALANCE property are
 listed and defined below:
 ACCOUNT_BALANCE Property
    Offset   Field Type  Order
    0  Balance  signed long high_low
    4  Credit Limit   unsigned long  high_low

 Balance

 This field contains a numeric value that indicates the account balance. It
 can be read or changed by the NOVLIB functions UsrAccBalanceGet() /
 UsrAccBalanceSet().

 Credit Limit

 This field contains a numeric value that indicates the lowest permissible
 balance. Services that cause the balance to drop below this minimum are
 denied. The minimum can be positive (requiring the users to always maintain
 some funds) or negative (allowing the user to receive services after the
 balance has dropped below zero). It can be changed by the NOVLIB function
 UsrAccLimitSet().

 ACCOUNT_HOLDS property

 The server can place a hold on a client's account before a request is
 serviced to ensure that the client has sufficient funds to pay for service.
 If the hold succeeds, this indicates the client has sufficient funds. The
 server can then perform the requested service, submit a charge for the
 service, then release the amount placed on hold.
 If the hold, along with all other holds, requires more funds than exist in
 the client's account (client's funds have gone below minimum balance), the
 hold request fails. The requested service should then be refused. An
 attempt to hold also fails if 16 other servers have already placed holds on
 a client's account.
 If the server does not place a hold on an account to ensure the client has
 sufficient funds, the server should query the account before rendering
 service. Then, if the client's account is empty, the request for service
 should be refused. If a holding server is disconnected, the hold it had on
 a client's account is cleared. The holding server can also explicitly clear
 a hold.

 If there are holds against a client's account, they are stored in the
 ACCOUNTS_HOLDS property. If there are no holds on the account, this
 property is not present. The ACCOUNT_HOLDS property is dynamic, of type
 ITEM, and has read-object and write-Supervisor security access levels ( see
 Bindery Services ). The existence of the ACCOUNT_HOLDS property can be
 tested for using the NOVLIB function ItmPropertyValueGet().

 Property Fields

 The fields in the ACCOUNT_HOLDS property value are listed and defined
 below:

    Offset   Field Type     Order
    0  Server 1    (Object ID) long  high-low
    4  Server 1    (Amount) long signed high-low
       .
       .
       .
    120   Server 16   (Object ID) long  high-low
    124   Server 16   (Amount) long signed high-low

 Holder ID

 This field contains the server ID of the server placing the hold. If this
 field is zero, the hold slot is not in use regardless of the contents of
 the amount field.

 Amount

 This field contains the amount of the hold.