RUN detached process with /NoAccounting -- WHY?

[Verne Britton]

both the RUN command and the CrePrc system service support creating a process with the NoAccounting bit set.

My understanding is the only thing that happens from this is ... at process rundown, no record is written to ACCOUNTNG.DAT.

I can see if thousands of almost identical processes get created ... that using NoAccounting would cut down on the size of ACCOUNTNG.DAT ... but other than that, is there any real reason to ever use this flag?

I have just noticed a 3rd party package creates several detached processes (these processes run for days to weeks at a time) that are marked NoAccounting.

AND ... I was just starting to take a look at resource usage of these detached processes as we move to a new minor version ... and was going to stop and start them with the old and new EXEs, then run for awhile, then compare the accounting entries to see things like DIO, BIO, PgFaults and the like.

Of course I was very surprised to find out they are running with the NoAccounting flag and thus never make any ACCOUNTNG.DAT records :-)

Any thoughts on why NoAccounting is ever really useful ??

p.s. the Support Center informed me one way to look at the current setting of a process is inside SDA ... SHOW PROC ... look for NOACNT at the top by the Process status display ... also they told me it is bit 15 in the Status longword, so this can tell me too at DCL:

$x = f$getjpi(P1,"sts")
$if (%x8000 .and. x) .eq. %x8000 then write sys$output "NoAcct set -- ''P1' ", f$getjpi(P1,"PRCNAM")


Verne

[Hoff]

Disabling auditing shuts off all auditing.

My guess? They're probably masking questionable processing, processing that generates massive numbers of audits, or masking a bug within the application.

Please ask the third-party vendor.

Or flip the bit and watch the show.

[John McL]

It can make sense to disable accounting on systems where many processes are created and terminated in a short time because of the overheads (time, disk I/O, disk space). This problem has increased as VMS machines get bigger and the number of processes grows.

Where I work we have exactly that situation on each of 6 nodes (large Alphas) so we've completely disabled Accounting. This is not ideal because sometimes we would like to examine the accounting information.

We've sent a request for process-specific accounting to the VMS "wish list" for future development. We would like accounting to be enabled for some processes and disabled for others by default, and we want to be able to dynamically adjust it. The fact that the code to be executed by VMS at process termination already exists means that only the other stuff - SYSUAF flag, SYSUAF privilege, and modification to SET PROCESS need to be made.

[John Gillings]

Verne,

Back when disk space cost significant money this probably made more sense.

I guess if you have a well debugged mechanism that generates many processes it makes some sense to avoid cluttering the accounting log, but most of the time I prefer to be able to track even short lived processes.

>then compare the accounting entries to see
>things like DIO, BIO, PgFaults and the like.

To compare old and new without hacking the process creation code, use SHOW PROCESS/ACCOUNT/ID=pid from another process.

[Jon Pinkley]

Verne,

The biggest resource used by ACCOUNTING is disk space. If image accounting is turned on, then the amount of accounting data collected will be substantially more than the default process accounting.

As to the reason that the vendor turns off accounting, the only good explanation needs to come from them. Perhaps it is that they don't want to have to answer questions about why their product uses as many resources as it does.

One possible reason for them using /noaccounting is because the processes run for extended periods of time. Because of the way that accounting works, the usage shows up in one lump sum at the time the process goes away. So if the process has been running for 1 month, and uses 4 minutes of CPU every hour, when the accounting record gets written, it will show 48 hours of CPU use. This can be confusing to someone that doesn't understand how accounting works. Consider what will happen if the detached process exited at 15-DEC-2009 17:01 and then someone issued a command like the following on 16-DEC-2009:

$ accounting /since=15-dec-2009/before=16-dec-2009/sum=hour /report=(processor,elapsed,dir,buf,fau,rec)

There is going to be a big blip in hour 17, even though the usage was possibly evenly spread out over a whole month.

Auditing and accounting are not directly related. I am not aware of a way to specify that a detached process gets run with auditing turned off.

I have never seen accounting as being a bottleneck. Writing accounting records is reasonably efficient. That doesn't mean it isn't possible for it to be a bottleneck, but if it is, there are things being done that should probably be done in another way. In other words, if processes are being created and deleted so fast that accounting records can't be written fast enough to keep up, then a method that doesn't need so many process creations should be found. The same applies to image activations and image accounting.

I haven't tried this, but it certainly seems plausible to write a privileged program that could be run that could set the NOACNT bit and prevent the process accounting record from being written.

Jon

[Jim_McKinney]

<< I haven't tried this, but it certainly seems plausible to write a privileged program that could be run that could set the NOACNT bit and prevent the process accounting record from being written. >>


Been there long ago on as system where image accounting was de rigeur and I had certain jobs (not users) with lots and lots of image activations that I wanted to exempt... turns out that if you choose to toggle the noacnt bit off while in batch mode you must subsequently toggle it back on prior to job completion or the job will never completely terminate - it'll remain hung in the batch queue attempting to run down. I don't recall all the details (and perhaps current versions of VMS don't preserve this behavior). This post is just a caution to anyone who wants to go down this path - make sure you test for this.