image audit report issue

[SAMI AHMAD]

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

[Volker Halle]

An image accounting record is ONLY written at image exit.

Volker.

[SAMI AHMAD]

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.

[Hein van den Heuvel]

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

[Jon Pinkley]

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

[Jess Goodman]

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.

[Jon Pinkley]

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

[Jess Goodman]

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.

[Hoff]

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.

[John Gillings]

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.