smith@uoregon.UUCP (Dale Smith) (01/15/88)
The University of Oregon is currently in the process of converting from a DECsystem 1091 to a VAX 8800. One of the problem areas is the issue of accounting. We currently (on the DEC-10) have the ability for a person to charge different parts of a single session to several different accounts. Also, one can charge a batch job, print job, or plot job to an account different than the current one. How could one accomplish the same thing under VMS? In my naive view of VMS it seems that one could use the account field of VMS, have a database of valid values of the account field for each user, and some privileged program that allowed users to change the account field on the fly. Obviously, when one changed the account field, you would have to write an accounting record as if that person had logged out, then back in. I can imagine some similar situation for print, etc. The problem is, I don't know much of anything about VMS. Does anyone out there have software that does something similar? Has anyone heard of such software? Please, no flames. I hate accounting as much as the next person. Also, don't clutter up the net with replies, just reply directly back to me (notice that my e-mail address may be different than what appears in the header of this message). Thanks in advance, Dale Smith, Senior Systems Programmer Bitnet: dsmith@oregon.bitnet Internet: dsmith@oregon.cc.uoregon.edu (will go through csnet-relay I hope) Voice: (503)686-4394 USmail: University of Oregon Computing Center Eugene, OR 97403-1212
berkley@wucs2.UUCP (Berkley Shands) (02/11/88)
The following is a draft of a WHITE PAPER to be presented at the
spring DECUS symposium. If you have seen it before, it is still worth
reading and commenting on.
VAX / VMS Accounting
A White Paper from
The DECUS Large Systems SIG
Spring 1988
E. F. Berkley Shands
Washington University in St. Louis
Accounting on the VAX Page 2
ACCOUNTING ON THE VAX REV 2.1
1 ACCOUNTING ON THE VAX REV 2.1
Accounting for a commercial VAX/VMS system must have a central
philosophy by which the system works. This should be "Accuracy,
Repeatability, and Completeness". All information from the accounting
system must be accurate. How much CPU time did User X use? How much
disk space did User SYSHOG tie up running that sort? How many pages
of form type BIGBUCKS did that print job consume? If a user runs a
program today, and runs the same program tomorrow, the runtimes should
not differ to any extreme. Knowing the nature of timesharing,
accounting to the micro-second is not practical. However, accounting
accurate and repeatable is certainly within the realm of engineering.
This paper concerns itself with the types of data to be collected, and
suggests some possible formats for storage and management. The paper
does NOT consider technical details that would change from processor
to processor or release to release. Further, this paper is not
designed to describe a package that would process the accounting
records and produce reports. Such a task is best left to the customer
to decide what information is important to present.
The accounting hooks developed today must be flexible enough to
last through the 1990's into the year 2000 (or as long as VMS is
supported). It is better to think about that now, than wish you had
done so later; provisions should be made for extensibility. Providing
a complete solution (a VMS hallmark) is the prime objective. Take
into account LASER DISKS, Print servers, back end disk systems,
network devices, SMP systems, attached processors (CMP systems) etc.
Further take into account that some sites may only want parts of the
full accounting system, and not need to record others.
1.1 Functional Specifications For Accounting
An accounting system must provide the "hooks" and basis for
tracking system usage. This includes ALL peripherals and attached
processors. Consider the possibility of an array processor being part
of the system. Or consider the work performed in the HSC or even
DECNET hardware. The prime function for VMS is to collect these data
items. Analyzing them and producing a report is secondary.
1.1.1 Classes Of Resource Usage -
Historically, system usage has been based on charging for CPU
time, disk space, tape drive time, and printed/punched output. In the
era of networking and SMP computers, this doesn't cover all bases.
Today there is static and transient disk usage. Network terminal and
file access. Virtual addressing space usage as well as physical
memory usage and paging are distinct but inseparable quantities. Line
printers, plotters and laser output devices can have multiple forms,
fonts, pens, belts and the like. Some port switching systems can bill
by characters in and out. Tape drives still require operator
Accounting on the VAX Page 3
ACCOUNTING ON THE VAX REV 2.1
intervention for their care and feeding. Laser based write-once-media
(WORM) are appearing in the marketplace. How can all these different
entities be organized to provide a minimum number of resource classes?
1.1.1.1 Processor Resource -
Under this title comes the bulk of the CPU and memory domains.
Virtual addressing consumes swapping and paging space. Working set
management consumes physical memory. Poorly written programs stress
the machine more than tightly written non-thrashing ones. Page faults
drive up overhead, cause more memory accesses etc. Programs that have
a tight (cachable) core make less demands on the slow memory system
than do the spaghetti variety.
Tracking memory references (ALA MBOX cycle counters) provides a
way for the system manager to keep track of program performance.
Clearly this requires special hardware not found in the majority of
the VAX line. Therefore absolute counts are not obtainable. What is
needed is some machine independent metric. Perhaps the
Kilo-Core-Second and the Virtual-Kilo-Core-Second? A KCS is two pages
of physical memory in use for one second. A VKCS is two pages of
virtual address space (P0) in use for one second. If there is a good
way to account for FPA usage, it should be included. Records for each
process should be kept, updated and checkpointed. For those processes
that never terminate (SWAPPER, OPCOM...) the checkpointed values may
be used to complete the used cycle totals.
Some sites wish to charge different rates based on the time of
day. Therefore a method for flushing the entries for all active
processes is required. When the "shift" changes, all counters are
zeroed and processing continues without user intervention. These
shift changes need to be automatic. Forcing an operator or a batch
job to change the accounting shift would not be repeatable or
reliable.
1.1.1.2 Disk System Resource -
Xerox and IBM systems view two kinds of disk usage; Static and
dynamic. Static usage is the familiar "Whats on disk now, and who
owns it?" Dynamic usage is somewhat more complex, since it deals with
logged in disk use versus logged out disk usage. For example, a user
wants to sort an address file. The sorting program creates a
temporary file which is never closed, but chews up 1.4 million disk
blocks for an hour while it runs. A static disk analysis would never
see that use. A dynamic recorder would compute 1.4 Mega-blocks for
3,600 seconds and arrive at a Kilo-Byte-Disk-Second figure. Here is
where completeness comes in. Clearly this amounts to using a fair
chunk of system resource. To be fair, such usage would have to be
recorded. However, to continue being fair, a file should not be
billed for both static and dynamic charges. Therefore some clear
Accounting on the VAX Page 4
ACCOUNTING ON THE VAX REV 2.1
procedure must be established as to when a charge is assessed.
A further area of concern in disk usage is that of overhead
blocks and directory blocks. A file header takes up room. TOPS-10
charges for that space. TOPS-20 hides it. VMS hides it too, but
records directory usage. TOPS-20 hides directory blocks, but TOPS-10
doesn't. With allocation cluster factors getting higher and higher,
there is a larger percentage of the disk that is allocated but unused.
Is it fair to bill on allocated space when the user has no control
over the cluster factor? Is it fair to bill on used space when a user
can allocate far more than is needed (to be used at the users whim)?
This needs to be a site dependent decision. Collect BOTH, let the
user pick which one to use.
Deeper inside the disk usage issue is how to record file / disk
use. The scheme of a UIC owning a file is fine for access, but what
happens when a user is working on multiple projects at one time? A
secure system is required to have a one to one mapping between users
and usernames / UIC's. How can the standard UIC system handle
multiple projects by a single user? The solution in TOPS is to assign
an independent string for billing that does not reflect the owner.
This string is validated for the user (and a utility looks for files
that have invalid charge strings after data base changes). This keeps
the user honest, and the disks clean. But what about the user that
doesn't care about charges, and leaves mountains of files on disk
while never touching them. If the user is paying for such storage,
this may not be so terrible. In other environments this "disk hog"
must be dealt with in other ways to reduce the overall impact. There
should be several fields in the file header which are reserved for
tracking use of that file(s). A last read date, last write date, who
wrote it, who owns it, when it expires, when it was archived, when it
was returned from archiving and others MUST be kept! If a file is
migrated onto WORM storage, that should be recorded too. How should
WORM disk usage be treated? A user cannot DELETE such a file once
created! A further complication is "SET FILE/ENTER". The physical
file may reside in several directories, with one user archiving the
file and another desiring no archiving. This sticky problem must be
addressed outside of the scope of this paper.
1.1.1.3 Tape Usage -
Some large commercial sites have THOUSANDS of tapes in their
libraries. Large IBM shops have FLOORS full of tape drives. Even
smaller shops often have four to six tape drives. As a resource, any
tape related activity must be recorded. Tapes are operator intensive
by nature. For sites that must cost recover, recording operator
interactions is required.
All tape events need to be recorded. Mounts/DisMounts,
reads/writes, rewinds/skips (controller based today, host based
yesterday) and errors. This needs to be tracked on a per-tape drive
and VOLID/REELID basis. A charge string (the current default for the
Accounting on the VAX Page 5
ACCOUNTING ON THE VAX REV 2.1
user) would be used for recording purposes. If everything needs to be
recorded, don't forget the type of drive (some are faster), the
density, and the time of day.
1.1.1.4 Operator Usage -
How do you use your operator? The system operator(s) have a
tough job in a busy machine room. It was once suggested that they
wear roller skates. Disk and tape mounts/dismounts, printer/plotter
feeding, backups (DIGITAL disks never crash?), shift changes
accounting updates, etc. All of these items need to be tracked, as
well as how long it took the operator to respond to the request. If
the disk request didn't need operator intervention, fine. Record it
anyway.
File archiving takes lots of operator effort, and tape drive use
(today, but maybe WORM use tomorrow). A user can create an
operational nightmare by requesting files all day. Such requests
should be recorded for possible charge-back.
1.1.1.5 Spooling Usage -
The input and output spoolers do a fair amount of work. This
includes disk/cpu and related resource consumption. Any activity done
on behalf of a user should be charged to that user. Spooled line
printer output files need to be charged just as regular disk files do.
The forms used must be recorded, the time the spooler ran (TOD
clock), the queue name (batch too), and all recordable information as
well. Some field must be provided for the operator to add comments
"Printer munched 1/2 box of form BIGBUKS" or "The plotter ran out of
ink".
1.1.1.6 Network Usage -
This is a very tricky area to track. Should a user be billed for
using DECNET to transfer a file from a remote site? Should that user
be billed for SET HOST to another site? Should a transaction
processing system be billed for task to task I/O requests? How should
a user be billed for dial-out DECNET access to a remote host? What
about task to task within a machine or cluster? Who gets charged for
the time used on the remote machine? What about routers? How do you
bill for the overhead of "pass through" packets?
What is clear is that whatever information is available should be
recorded. If the local site wants to treat routing work as overhead,
that is a local decision. The more accurate the recording, the better
the justification for adding additional equipment.
Accounting on the VAX Page 6
ACCOUNTING ON THE VAX REV 2.1
1.1.2 User Features -
A user must be able to change account strings rapidly. Under
Security rules (government type), one user = one login name. You
can't get around that by giving multiple user names. Changing
sessions (with remarks) must be quick and transparent to the user.
This is known as "SET ACCOUNT". The account string must be valid, and
it must be usable by that user for that function. For example, a
charge string may be good for disk storage but not for CPU or tape
mounts. It might be good only from 09:00 until 11:00. To further
complicate things, each account string may be associated with a
particular scheduler class. Changing accounts may change your
scheduler class setting too (Process Priority).
Every accounting entry generated by the user's actions would
carry a charge string, unless another was subsituted by design. The
system must be capable of MASS updates to the database of valid charge
numbers. Third party retro-fits for accounting usually do not handle
this mass change. The system must be able to handle thousands of
charge strings (that means no linear searching too!). Utilities must
be provided to find files/queues/entities that have a particular
charge identifier (valid or not). Some user will complain "Why do I
have a $20,000 charge for disk space? I only have 30 blocks in my
directory!" Right, but you have 1.9 million disk blocks in queue
waiting to print. The system manager friendliness of the accounting
subsystem is very important!
The accounting system must checkpoint its data to protect against
system crashes. The active accounting data should be written to disk
at regular intervals controlled by the individual sites. This data
should not be written after every action, because that would seriously
impact system performance. The accounting data could be kept in an
in-core queue, to be written at the specified time or when the queue
became full. Consider a user program generating 1K accounting entries
per minute. What would happen if each entry required disk accesses?
A user should be able to get a DIRECTORY based on charge number;
"DIR/CHARGE=Bogus-account-51". LOGINOUT should prompt for missing
charge strings at login time. ".DIR" files should have their own
overriding default charge strings for files created in them like ACLs
with /OPT=DEFAULT.
The hooks for a user supplied accounting record should be
provided for those facilities that want to track finer detail than is
normally available.
1.2 What Won't Work
Access Control List (ACL) identifiers should not be used as
account strings. In large commercial sites, account string databases
may contain 10K entries, of which 2K will change each week. Further,
when an entry is deleted from RIGHTSLIST.DAT, all that remains in the
Accounting on the VAX Page 7
ACCOUNTING ON THE VAX REV 2.1
file header is %X8001BEEF. This number is very hard to correlate with
the original account string.
Any system that does not provide for account to user validation.
It would be best if the validation process could be user written, with
a template supplied by VMS Engineering.
Several other areas reflect government regulations for security
and ease of use concerns.
1) Grafted on accounting that requires a change of UIC to track usage.
2) Anything that requires multiple user IDs for a single user.
3) Anything not supporting shift changes on the fly.
4) Anything that will not provide a straight dump of the accounting
database. A callable interface would suffice, since you could read
records right out of the active file. The interface would need a call
for "GIVE ME INFO ON THE NEXT RECORD" and "GIVE ME THE DATA OF THE
NEXT RECORD".
5) Anything that does not allow the user program to validate a charge
number. (I.E. a System call to validate a charge number for a user.)
Spoolers should be able to validate access to charge strings like they
validate file access.
Accounting on the VAX Page 8
ACCOUNTING RECORD FORMATS
2 ACCOUNTING RECORD FORMATS
Every record written to the accounting data file should be
prefixed with information on what system wrote that record. At the
very least the actual SID register data and a text string should be
supplied. The text string should be at least 10 characters (node
names are too short). This provides for the centralized processing of
accounting data in a corporation which has a large number of networked
and clustered systems. Accounting data from one system could not be
interchanged with that of another. With each system identified on the
accounting record, the whole networks' data could be appended to one
file and processed.
In the following list, some items are redundant. This is due to
the need to have ALL the needed information IN ONE RECORD. The system
administrator should not have to determine by context the other items
needed.
3 ACCOUNTING RECORDS - DISK SYSTEM
3.1 File Header Items
Note: changing the file header should not cause
the data to be backed up on an incremental BACKUP.
1) Date of last user read
2) Date of last user write
3) Date of last archive
4) Date of last archive restore
5) Name of last writer
6) Name of last reader
7) Name of owner
8) Charge string (from CREATE or SET FILE)
9) Archive reason (age, request, etc)
10) File status flags
11) UIC of owner
3.2 Disk Usage Entries
3.2.1 Static Snapshot -
1) Charge string
2) Owner
3) Allocated blocks
4) Used blocks
5) Cluster factor
6) Name of directory
7) Total blocks in directory
8) Overhead blocks in directory
Accounting on the VAX Page 9
ACCOUNTING RECORDS - DISK SYSTEM
9) Date/time
10) Volume name
11) Device/type (Dba0/rp07)
3.2.2 Dynamic Disk Usage -
1) Charge string
2) Date/time
3) Owner
4) Kilo-Byte-Seconds of use
5) name of file
6) Directory of file
7) Max blocks used
8) Max blocks allocated
9) Volume name
10) device/type (dja2/ra60)
3.2.3 Disk Volume Mount/dismount -
1) Date/time
2) Charge string
3) user name
4) Requested disk
5) Disk drive used (type/device)
6) Opr response delta time
7) Status flags (WRITE/Success/automount)
8) Opr comments
3.3 Tape Drives
3.3.1 Tape Mount -
1) Date/time
2) Charge string
3) user name
4) Requested tape VOLID/REELID
5) Tape drive used (type/device)
6) Opr response delta time
7) Status flags (WRITE/Success)
8) Opr comments
9) Type of tape (labeled / unlabeled)
10) If labeled, type of label (ASCII/EBCDIC/OTHER)
3.3.2 Tape Usage -
1) Date/time start
Accounting on the VAX Page 10
ACCOUNTING RECORDS - DISK SYSTEM
2) Date/time stop
3) Charge string
4) User name
5) Reads
6) writes
7) Rewinds/file skips
8) Errors
9) Drive/type/density
10) Opr comments
3.4 Spooler Entries
3.4.1 Line Printer Usage -
1) Date/time
2) Charge string
3) User name
4) Device/type/location
5) Pages printed
6) Forms type
7) Ribbon type
8) Number of files
9) Number of copies
10) Completion date/time
11) Opr comments
12) CPU usage entry (process type)
13) Disk usage entry (dynamic)
14) Priority/queue name/entry number
3.4.2 Plotter Usage -
1) Date/time
2) Charge string
3) User name
4) Device/type/location
5) Feet plotted/ pages plotted
6) Forms type
7) Pens type
8) Number of files
9) Number of copies
10) Completion date/time
11) Opr comments
12) CPU usage entry (process type)
13) Disk usage entry (dynamic)
14) Priority/queue name/entry number
Accounting on the VAX Page 11
ACCOUNTING RECORDS - DISK SYSTEM
3.4.3 Other Spooler Types... -
1) Date/time
2) Charge string
3) User name
4) Device/type/location
5) Number of files
6) Number of copies
7) Completion date/time
8) Opr comments
9) CPU usage entry (process type)
10) Disk usage entry (dynamic)
11) Priority/queue name/entry number
3.4.4 Attach/Detach Entries -
This entry is written each time the user "CONNECTS" or
"DISCONNECTS" (ATTACH/DETACH) a process from a terminal. This is
completely distinct from the PROCESS type entries. Some sites may
want to charge different rates for DIAL-UP terminal VS DECNET
connections.
1) Date/time
2) Type of terminal connection (LAT/DECNET/HARDWIRE)
3) Source of connection (DECSERVER 200 CLYDE port 3 or
DECNET node YAHOO:: process 2065B410)
4) Username
5) Process ID
6) Account string active at the time
7) Characters sent since last ATT/DET
8) Characters recieved since last ATT/DET
9) Elapsed time port was used on DETACH
10) Elapsed time process was detached on ATTACH
11) Port specific info (line speed etc)
3.5 System Configuration Changes
3.5.1 Accounting Changes -
1) Shift change record
2) Account validation database update
3) Operator coverage change
3.5.2 Scheduler Type Change -
1) Priority
2) Class
3) Round-robin
Accounting on the VAX Page 12
ACCOUNTING RECORDS - DISK SYSTEM
4) Other
3.5.3 Device Status -
1) Disk/tape offline
2) Network link down
3) Terminal baud rate change
4) Terminal ADVISE/LINKING records
3.6 CPU Resources (at Process Termination Or Account Change)
3.6.1 Memory Usage -
1) User name
2) Process name
3) Charge string
4) Physical KCS used
5) Virtual KCS used
6) Mbox cycles
7) Working set size
8) Pager traps
9) Date/time
10) Scheduler class used (% allocated, number of class)
11) Type of scheduling in use (prio/RR/Class)
3.6.2 Processor Usage -
1) User name
2) Process name
3) Charge string
4) CPU time used (to MS)
5) flags (incl/excl interrupts + overhead)
6) CPU SID of processor (SMP tracking)
7) Floating point use cycles
8) Vector cpu use
9) Time of day/date
3.7 Process Usage
3.7.1 Resources Used -
1) User name
2) process name
3) charge string
4) Date/time
5) Node of session origin
Accounting on the VAX Page 13
ACCOUNTING RECORDS - DISK SYSTEM
6) Last node origin
7) This node name
8) Session start
9) Session end
10) Session remark
11) TTY I/O chars in/out
12) Flags (batch/network/etc)
13) Physical terminal name
14) Virtual terminal name
15) Kilo-Byte-Network data transmitted
16) CPU spent compiling
17) CPU spent executing
18) Baud rate of terminal
19) Number of OPR requests
20) Spooler proxy data
3.8 Network Usage
Some sites may wish to charge back network usage to the specific
individual or site (CPU) responsible for its use. Items include:
file transfers, records transfered, virtual terminal usage, network
spooling, etc. Note that each record transfered doesn't need an
entry. Just that User X made 124,498,200 record transfers.
3.8.1 Specifics -
1) Time of day
2) Network connection (source/dest, node::object)
3) Volume of data transfered (bytes or Kbytes) in and out
4) Type of entry (open/close)
5) User name
6) Account string at host
7) File transfer stats
8) NVT stats
3.9 Other Concern Areas
It would be nice to be able to track usage of 3rd party hardware
too. If each driver had a routine to record calls, CPU time, etc,
this would allow the system manager to see what devices are consuming
the systems resources. This could also be used as a hook for
accounting on attached array processors, BI based funny devices,
user-written pseudo devices (like PTYDRIVER/PHOTO) and the like.
A clean way to perform this would be to extend the current system
calls for writing accounting entries. Since these entries would be in
a user defined format, the only way to read them would be with the
callable accounting file reader. If the type of record were known
Accounting on the VAX Page 14
ACCOUNTING RECORDS - DISK SYSTEM
beforehand, a real 'CPU USAGE' record could be written. There is no
documented way of writing such an entry today.
Any change to the accounting system would force a change to
SYS$MANAGER:ACCOUNTNG.DAT. Obviously this would break a large
percentage of the currently available third party packages. Which
would you rather have, a system that patches SYS.EXE and breaks at
each release? Or all data collection done by VMS, and processed by
your favorite third party package?