topic Re: image audit report issue in Operating System - OpenVMS

image audit report issue

SAMI AHMAD — Mon, 09 Mar 2009 17:14:10 GMT

I have a strange issue, I know certain image is running all day but it doesnt show up in report say between 1am - 2pm but if run the report for the whole day the image records show up. ?
like today the image was running at 11am but if i run the image report from 11am till 12 pm it doesnt show up .. why ?

$ACCOUNTING/TYPE=IMAGE/REPORT=(PROCESSOR,ELAPSED,DIRECT_IO,FAULTS,RECORDS)-
/SINCE=9-MAR-2009:11:00 -
/before=9-MAR-2009:12:30/SUMMARY=IMAGE/OUTPUT=a.lis

Re: image audit report issue

Volker Halle — Mon, 09 Mar 2009 17:26:37 GMT

An image accounting record is ONLY written at image exit.

Volker.

Re: image audit report issue

SAMI AHMAD — Mon, 09 Mar 2009 19:36:46 GMT

every night at 8 we stop the application so next day if i run the report for the period 10 - 12pm shouldnt i see the record ? iam not seeing it.

Re: image audit report issue

Hein van den Heuvel — Mon, 09 Mar 2009 19:50:07 GMT

Do you even have image accounting enabled?
($SHOW ACCOUNT)

And those timelines you mention do NOT make sense. If you stop and restart at 20:00 then 11:00 - 12:30 is not going the catch an activation or exit no?
Still, PROCESS accounting may be good enough

Me thinks you need to take 10 steps back.
What is this system? What is it supposed to be doign? Does the application provide performance feedback. Does that match the user experience? Does it match the system general performance footprint. Is this a new problem? Did it ever work well?

Your other topics mentioning DecPS or and other PERFORMANCE oriented tool like T4 may be a better place to start than ACCOUNTING, but admittedly accounting has frequently given me useful performance counter insights.

Work with some peers or a consultant to define the current performance in quantifiable terms. Come up with some measurement, then come up with some explanation.

Regards,
Hein van den Heuvel
HvdH Performance Consulting

Re: image audit report issue

Jon Pinkley — Mon, 09 Mar 2009 23:25:12 GMT

SAMI AHMAD,

$ accounting /since=x /before=y

will only report things that terminated between time x and y. As Volker stated, image records are written at image rundown. In general accounting records are written "after" the event has completed, and the selections times are only looking at the "Finish time:". As Hein has pointed out, the selection times don't include the image rundown time.

This thread (and possibly others) contain more details:

http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1198578

Jon

Re: image audit report issue

Jess Goodman — Tue, 10 Mar 2009 03:39:32 GMT

You said: "every night at 8 we stop the application". If by that you mean you use a command like:
$ STOP /ID=xxxxxxxx
then image rundown will not happen (unless the image is installed with privs) so you will not get an image accounting record.

You could try STOP/IMAGE/ID=xxxxxxxx instead.
This will do image rundown and unless your detached application is running a DCL command file the process will end.

Re: image audit report issue

Jon Pinkley — Fri, 20 Mar 2009 04:24:00 GMT

Jess wrote:
-----------------
$ STOP /ID=xxxxxxxx
then image rundown will not happen (unless the image is installed with privs) so you will not get an image accounting record.
-----------------

I don't believe that is true. A control-y won't always initiate a rundown, but the rundown will occur before the next image activation.

STOP/ID used to bypass exit handlers, but the default behavior has changed somewhere in the 7.3* timeframe, where at least the inner mode handlers get executed.

I am not able to reproduce the loss of image accounting records due to the use of $DELPRC.

Even using

$ STOP /ID=xxxxxxxx/NOEXIT

does not prevent the image accounting record from being written.

Test were on AlphaServer ES47 7/1150 running OpenVMS V7.3-2. Process being killed running from non-prived account (same results with prived account), running non-installed images (one a CPU burner written in FORTRAN), one a translated image (LIST_TV, translated from VAX exe of DECUS ICR LIST).

My guess is you looked in the accounting file before the buffer got flushed.

The image accounting is written to the job controller's mb before the image exits. It may take a while for that to actually be written to the accounting file. You may want to retry your test.

If someone can document a case where image accounting was enabled at the time the image was activated (and therefore ctl$gq_istart has non-zero value), the system hasn't crashed, accounting is still enabled at the time the image exits, the process did not have the noaccounting flag active, something has been written to the accounting file for an event that came after the image exit/rundown, and there is no image accounting record, I would be interested in how it was done. Using privileged software to circumvent is not allowed, e.g. clearing ctl$gq_istart will prevent it, but I am only interested in cases that could occur in normal operations.

Jon

Re: image audit report issue

Jess Goodman — Fri, 20 Mar 2009 14:44:47 GMT

My bad. My comments were based on recalling tests we did way back in the VMS 5.4 time frame. Either I recalled the results of our tests incorrectly or the behavior of STOP/ID= has changed since then.

Re: image audit report issue

Hoff — Fri, 20 Mar 2009 15:24:33 GMT

Process rundown was updated to perform the exec-mode handling (by default) and this can include flushing various buffers. For details on this, please see the OpenVMS Alpha V7.3-1 documentation around the sys$delprc system service and around the DELPRC_EXIT parameter.

Re: image audit report issue

John Gillings — Sun, 22 Mar 2009 22:32:29 GMT

Note, you can still get accounting information for selected images, without having to have (general) image accounting enabled. See $ INSTALL HELP ADD/ACCOUNTING:

ADD

/ACCOUNTING

/ACCOUNTING
/NOACCOUNTING (default)

Enables image-level accounting for selected images even if image accounting is disabled on the local node (by using the DCL command SET ACCOUNTING/DISABLE=IMAGE). When image accounting is enabled on the local node, it logs all images, and the /NOACCOUNTING qualifier has no effect.

I recommend you dump ALL the image accounting records for the image you're interested in for (say) an entire day. Look at the times you get records, and correlate them with known events. This should clarify the way accounting works.

If you want some kind of continuous performance data for a specific image, you'll have to roll your own. Maybe use $GETJPI to gather the stats, and dump them into a T4 compatible file.

I recently posted a procedure to gather GETJPI stats. You'll need to change it to hunt for processes running images of interest. Not difficult.