[Info-vax] RMS File statistics and Hein's RMS_STATS program, all zeroes at times

[Richard Jordan]

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.