This account contains a pair of programs for chargeback accounting on
RSX11M V3.1 or greater (sans "+").

One program, imaginatively titled "LOG" (ref LOG.MAC) takes care of
logging user task executions, device usage and terminal signon time.
The information is collected 'statistically', which is to say via samples.
These samples are however collected at frequent intervals.  The exact
interval is adjustable but should be in the range of .5-1.0 seconds for
most applications and to give a reasonable sample.  A hashing scheme is
used which keeps the overhead to a minimum.  This information is written
to a file (nominally LB:[6,10]ACCTLOG.DAT) in a format which is documented
in the preface of the LOG.MAC source.  There are also several parameters
which should be set there for individual sites as well.  This file is
checkpointed every few minutes (adjustable) so that accounting data is
rarely lost in event of a crash, (except of course for active tasks at
the time of the crash, and nobody would want to charge them).  This program
runs on an 11/70, but is probably OK for anything /34 or higher.  Some
adjustments would likely be needed for anything smaller.

The second program, "DSKLOG" will account for disk device usage by file
owner UIC.  The format of the file (LB:[6,10]DSKLOG.DAT) is compatible
with that generated by LOG, so that they can be merged for reporting
purposes.  DSKLOG could certainly report into the same file as LOG, but
that is a site decision.  The format of the DSKLOG command line is documented
in the source DSKLOG.MAC .

What one choses to do with these files after they are generated is up to
you.  I have included a horrid little FORTRAN menagerie that we use to
read a LOG/DSKLOG-format file (renamed or copied to LOGDATA.DAT) and
report into LOGDATA.OUT .  From there DATATRIEVE is used to generate the
final reports.  The DATATRIEVE procedures are included as LOG.DFN .
We go through this awful scenario once a month, which isn't too bad, but
the accounting file can get mighty big (> 1000 blocks) by then, so if
disk space is limited, consider a more frequent purge-out (perhaps to tape
once a week).  [If anybody takes the trouble to write a decent post-processor
I'd appreciate knowing about it.]

The environment under which this is run is a PDP11/70 RSX11M V3.1 BL22 w/
1MB semiconductor memory and 700Mb disk store.  Obviously this is hardly
spartan, and I can give little advice for more restricted environments.

Have fun.
					Steve Duff
					Santa Fe Engineering R&D
					505 South Main St.
					Orange Ca.  92668
					Nov-80