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?