Sujet : Re: RMS File statistics and Hein's RMS_STATS program, all zeroes at times
De : usenet (at) *nospam* cropcircledogs.com (Richard Jordan)
Groupes : comp.os.vmsDate : 18. Nov 2024, 22:08:40
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vhgaco$1e3q9$1@dont-email.me>
References : 1
User-Agent : Mozilla Thunderbird
On 11/18/24 2:45 PM, Richard Jordan wrote:
Still working on determining the cause of the sporadic severe slowdown issues with a particular batch job and have run into another issue.
We're trying to get RMS stats from one of the files. We have a monitor batch job that snapshots info about the problem batch job; that monitor batch job uses Hein's RMS_STATS program to dump them twice, once just before the start of the problem batch job, and once right after it completes. I don't want to risk using the option to zero the counters on the production system and file so we need before and after.
So the issue is, the output of RMS_STATS in the batch job looks correct but all the counters are always zero (0).
I can do
RMS_STATS -c -o=a DKA2:[DIR1.DIR2]FILE.DAT
interactively and I'll get the expected output, with counters climbing on subsequent runs.
If I temporarily disable stats I'll get the warning from RMS_STATS as expected; it is looking at the same correct file either way.
The problem batch job is run under a normal user account. The monitor batch that does the system analyzer snapshots (to watch for 'busy' file channels) and tries to use RMS_STATS is currently running as SYSTEM, but we've tested it under our priv'd maintenance account also. No difference in behavior.
And I can run the intaractive command under our maintenance account OR as SYSTEM and in both cases get real and incrementing counters back, not just zeroes.
Any thoughts?
Forgot to add the last test. I trimmed the monitor batch procedure that ran RMS_STATS down to just the symbol definitions and those two runs, only added a 5 second wait in between them, and its returning real numbers instead of zeroes. So something is different in the 1:55AM - 3:30AM timeframe when the full monitor job runs. Tested the same accounts (SYSTEM and our maintenance account) on two separate batch queues, all returns are good.