🚀 go-pugleaf

None of the process accounting data that VMS records is a fair
and accurate way to charge a user for use of a time-shared Vax:

*  For a session where the user is retrieving a fixed amount of
   data, the elapsed process time is really a measure of how slow
   the system is at the time of that session.  Why should a user
   be charged *more* when he has to wait longer to get his data?

*  CPU-use based accounting over charges users when they run badly
   written applications that are CPU hogs.  If users are migrated
   among Vaxes with different CPU speeds determining a fair rate
   for CPU use becomes problematical.   And on faster Vaxes VMS is
   extremely inaccurate in recording CPU use; the interval timer
   interrupt service routine which records what process is using
   the CPU runs only every .01 seconds; in that interval many I/O
   bound processes may have briefly used the CPU and then returned
   to LEF state.

*  The process direct I/O count (DIOCNT) is, to some degree, a measure
   of how much work the process did.  But again it may often be more of
   an indication of how well specific applications were designed.  And
   it would be difficult for remote users to relate the DIOCNT figure
   to what they would perceive as the true value of their time-sharing
   session.  For most users this "perceived session value" would be
   related to how much data they receive on their terminal.

*  The process buffered I/O count (BIOCNT) counts not just I/O to
   the user's terminal but also file opens and other miscellaneous
   I/O types.

*  The number of I/Os performed on the user's terminal device could
   be calculated by storing the I/O count of the device at login and
   subtracting that from the I/O count at process termination.  This
   would require an executive rundown routine to perform this and to
   record the result somewhere.  This is getting closer to being a
   measure of the "perceived session value" but it still has one flaw:
   An I/O to the terminal device can vary from being one byte long to
   being a dump of a "n"K buffer.   A well designed application that
   uses large buffers would have at least the same perceived value as
   one that does no terminal I/O buffering, but its device I/O count
   could be less by orders of magnitude.

------------------------------------------------------------------------

So what is really needed is a count of the bytes written to the user's
terminal.  Unfortunately VMS does not record any statistics on the
number of bytes written to a device.

So I am asking all you internal gurus with those source listings by
your side for help!  How about a patch to the terminal class driver
that records the total number of bytes from all $QIOs (or just the
write $QIOs if possible) performed to a terminal device somewhere in
its UCB where I could access it when the master process of an inter-
active job logs out.

Or, alternately, record the total number of bytes written to any terminal
device by a process, since remote users normally don't use more than one
terminal device anyway.  If this value could be stored in an under-used
field that's written to the VMS accounting record for the process, such as
ACC$L_VOLUMES (remote users never mount volumes) that would be fantastic!
And if somehow this accounting could be done on job-wide basis instead of
per process that would be even better!!

A patch for any VMS 5.5 release would be fine.  I will be happy to debug
it myself.  And I promise not to bug the author for updates for new VMS
releases.

---------------------------------------------------------------------
                                                        Jess C. Goodman
                                                        814 238-2811
                                                        GOODMAN@ACCUWX.COM