Klensin@MIT-MULTICS.ARPA (John C Klensin) (09/12/86)
Having recently finished a screaming match with DEC support on this
subject:
a) The documentation is misleading, or worse.
b) They "fixed" it all (i.e., made it different and at least as
confusing, but no better documented or more clear) with 4.4.
c) There are apparently some patches to 4.4 floating around -- after
the mandatory update -- that "fix" it differently. I don't have them,
and don't know what they do for (or to) us. Or if there is any
documentation at all associated with them.
d) It is "fixed" again with the 4.5 field test version, they tell me.
I, of course, have not seen that documentation.
Explanation (with a twist, see below, this is claimed to be the same
with 4.3 and 4.4):
It takes three separate things to have accounting running and doing
something useful...
a) The option(s) containing accounting must be installed. For
microVMS, this is called the "Secure user environment option". I don't
know what the analogy is for [big] VMS, or if there is one, or what it
is called.
b) The accounting piece of the job scheduler (I think) must be turned on.
c) The flags for whatever you want monitored must be turned on.
Now, SHOW ACCOUNTING essentially looks at the flags, and nothing else.
So, if, for example, you have the scheduler piece turned off, or (it is
alleged by at least one of the terribly helpful, but not terribly well
informed, folks at DEC Customer Support) don't even have the option
installed, SHOW ACCOUNTING will keep telling you what is enabled - it is
just looking at the flags, and that is what it means by "enabled".
The deep knowledge, of course completely obvious from the documentation,
is as follows (small variations between 4.2, 4.3, and 4.4, but the
principle is claimed to be constant) (the "claims" are not mine, and I'm
not sure that I completely believe them):
SET ACCOUNTING/ENABLE
Turns on the scheduler piece. Claim is that, for 4.3 and 4.4, does
not affect flags at all. I think I believe it for 4.4, have my doubts
about 4.3, don't remember 4.2
SET ACCOUNTING/ENABLE=(whatever,...)
Turns on flags. Does not affect the scheduler piece.
SET ACCOUNTING/DISABLE
Turns off the scheduler, does not affect flags (symmetric with /ENABLE).
SET ACCOUNTING/DISABLE=(whatever,...)
The current recommendation is that you not try combining "too many"
of these options in one command, they suggest issuing them separately.
[Aside, to clarify how confused someone is here: Under 4.1M (a
microVMS-patched version of 4.1), the suggested ritual (and the only
thing we could get to work that we tried -- after a lot of other
attempts) was
SET ACCOUNTING/NEW/DISABLE/ENABLE=(whatever,...)
Claim was that, until you created a new file, nothing happened,
regardless of what flags SHOW ACCOUNTING saw and reported. Don't ask me
what the combination of /DISABLE and /ENABLE did, given the above
theory, but it worked for 4.1M, 4.2, and 4.3 microVMS. -end aside.]
Finally, the 4.4 twist, to give you a preview of what is to come, is
that they have imposed a hierarchical relationship between "PROCESS" and
INTERACTIVE, BATCH, and DETACHED (and, I assume, NETWORK, but we are not
running DECNet). So, if you say
SET ACCOUNTING/NEW $! start a new log
SET ACCOUNTING/ENABLE $! turn on the accounting part
$! of the scheduler
SET ACCOUNTING/ENABLE=(INTERACTIVE,LOGIN_FAILURE) $! set the flags
then login_failures get logged, but nothing else happens (other
than the fact that SET ACCOUNTING, of course, shows both INTERACTIVE and
LOGIN_FAILURE as "enabled". The flags are on, how is it expected to
know?). So, you must say
SET ACCOUNTING /ENABLE=(PROCESS, INTERACTIVE, LOGIN_FAILURE)
to get the interactive job terminations logged. Ditto for BATCH,
DETACHED, etc.
I didn't make this up in a bad dream. Really.
A strongly-worded SPR has been submitted, suggesting that SHOW
ACCOUNTING be told about the scheduler and any hierarchical
relationships that may exist and that they stop overloading qualifiers
without the documentation giving a clue. A few dozen more might help.
Good luck. Hope I have not added to the confusion.
John Klensin, MIT