Re: Chargeback to departments for ADSM usage

At 08:41 AM 2/12/99 -0500, Michael Dummitt wrote:
>Greetings,
>My company is looking into charging for ADSM services back to the Dept. that
>owns the server.
>Does anyone out there currently do this, and if so, what are you using to
>administer it.

We also do this.  We have Rexx execs that do it all, but I'm planning to
undertake a rewrite in Java to do it, so the code will be more portable and
shareable.  We have one exec that runs nightly which does a Q OCCUPANCY.
At the end of the month, another exec runs which processes the daily data.
This allows us to track overall usage by day, if we need to.

As someone else mentioned, the ADSM Accounting Log also contains some
useful information, and is the place to look if you want to charge based on
data transferred.  We have come to the conclusion that we need to measure
this as well, as we have a small number of nodes which have very dynamic
data (as opposed to static), which means that they are dumping most of
their data to the server on a frequent basis.  The modeling for all of this
can get complex, if you want it to, especially if you want to use ADSM for
a variety of solutions (as we do).

We also currently use the CONTACT field to store such things as accounting
information.  Depending on your environment, using the CONTACT field for
this might or might not be a problem.  In our environment, it poses a
problem as an admin user having Policy Domain privs has the capability of
changing the CONTACT field, and thereby rendering the accounting data (and
other data) unusable.  For this reason, we are thinking about moving this
info out of the CONTACT field.

Since a lot of different sites do similar things, it might be nice if we
could come up with some sort of standard format for formatting the CONTACT
field.  This might allow folks to more easily share their home-grown
utilities.  The format we have chosen is something like the following:

CONTACT field is: /key=value/key=value/key=value/...
where:
  key: is a 1 or 2 character key, indicating the field
  value: is the value associated with the key.
         The value is sometimes divided into 2 parts via a ":"
         Any slash characters in the value field are escaped with a
         leading slash.

So, here's an example:
Contact: /CN=Paul S.
Zarnowski/$=U:R52-1234-6510-000-000/N=1:psz1/CP=5-4757/CC=747 Rhodes

/CN specifies the Contact Name for the node
/$  specifies the account type and account number
    (the U indicates a University account number)
/N  specifies the notification policy
    (the 1 indicates notify after 1 day of non-backup, the next field
    is the e-mail address to notify (@cornell.edu is assumed)).
/CP is the Contact Phone
/CC is the Campus Mailing address
We also have other optional fields:
/ON is the system Owner's name
/OP is the Owner's Phone #
/OM is the Owner's e-Mail address

You get the idea.  This is based on some standard, but I forget what it is.
 :(

Sorry about the rambling...  got carried away I guess.

..Paul