topic accounting/report=execution data produced in Operating System - OpenVMS

accounting/report=execution data produced

Edwin R. van der Kaaij — Mon, 10 Sep 2007 07:47:22 GMT

Hello All,

i'm trying to explain resource usage on 7.3-2
image accounting is on.

i do $acc/rep=exec - bla-die-bla - and make a report for just 5 minutes

i get:
username | image count | total records
*john* | 2.500.000 | 25

the total records are the 25 records from the accountng.dat file (25 images were run, like rmu71,show,copy,delete etc.), but what in the world are the 2 and a half million images mentioned? Where can I find what that is?

TIA,

Ed van der Kaaij

Re: accounting/report=execution data produced

Jon Pinkley — Mon, 10 Sep 2007 09:37:55 GMT

The ACCOUNTING utility was written before image accounting existed, and the /report=(execution) doesn't make sense with /type=image. It probably should report the same as record count under those circumstances. PHD$L_IMGCNT is almost certainly what accounting is using as the source for what it calls "Images executed:". It is the count of the number of image rundowns since the process has been created.

If you issue a command like $acc/full - bla-die-bla -, you will see each image accounting record has an increasing value of "Images executed:".

My GUESS is that what $ acc/report=(exec,rec)/sum=user/type=image is doing is adding up the counts for each record, which to me gives a nearly useless result. If there were 25 image records and the image counts totaled 2500000, then the average of the individual record's "Images executed:" was 100000. If they were all from the same process ID, then I would expect them to start at 99988 and end at 100012. (i.e. (99988+999989+...+100012) =250000

The images executed item really makes sense only with /type=process, as the total will then be the total number of images executed by the processes matching the selection criteria.

If you are interested in the internals, and have access to the Internals and Data Structures manual, look in the index under image count. Its original purpose was to allow things like AST delivery to detect that the image had changed.

Re: accounting/report=execution data produced

Jon Pinkley — Mon, 10 Sep 2007 18:46:56 GMT

Following is a demo showing that accounting /type=image /report=(execution,record) /sum overstates image activations.

Contents of imgcnt.com

$! demonstrate accounting/type=image/report=(execution) results
$ top:
$ show logical sys$login ! this activates an image (show translation does not)
$ if f$getjpi("","IMAGECOUNT") .lt. 99 then goto top
$ logout*

-----------

$ submit imgcnt/noprint/notify/queue=...
$ synch/entry=$entry
$ accounting /job=imgcnt /sin=-0:05 /bin/out=imgcnt.bin ! get accounting for job
$ accounting imgcnt.bin /full/out=imgcnt_full.rpt
$ search/nowin/nohigh imgcnt_full.rpt "termination","executed" ! note increasing images executed
$ accounting imgcnt.bin /type=process /sum=job /report=(execution,records)
$ accounting imgcnt.bin /type=image /sum=job /report=(execution,records)

My results (Alpha VMS 7.3-2):

$ acc scr:imgcnt.bin/type=proc /rep=(exec,rec)/sum=job

From: 10-SEP-2007 17:04 VMS Accounting Report To: 10-SEP-2007 17:04
Job name Image Total
Count Records
---------------------------------------------------------
IMGCNT 101 1
$ acc scr:imgcnt.bin/type=image/rep=(exec,rec)/sum=job

From: 10-SEP-2007 17:04 VMS Accounting Report To: 10-SEP-2007 17:04
Job name Image Total
Count Records
---------------------------------------------------------
IMGCNT 4950 100
$

Note that 4950 = sum(0...99), 99 whas the highest imagecount (the loginout at process deletion time).

I can't explain why process termination shows 101 images executed I would have expected 99 but could understand it being incremented by 1, as the initial LOGINOUT does not increment the imagecount, as the first image accounting record shows Images Executed: 0.

Re: accounting/report=execution data produced

Edwin R. van der Kaaij — Tue, 11 Sep 2007 00:31:56 GMT

Thanks for the explanation and the testing. I checked some acc/full record numbers and your explanation does add up to the totals. Now I'll report the performance findings and dig into this deeper when I get a bit more time :o) Thanks again!