Monitor RMS problem

[Bryan Ross]

I have a monitor recording containing data for about 50 files created by:

$ monitor /interval=60 /nodisplay /record=sys$monitor:filemon.dat rms /file=(file1,file2,…,file50)

Can you suggest why should I be unable to playback the data for any particular file? For example:

$ mon rms /file=filen /inp=sys$monitor:filemon.dat
%MONITOR-E-REQFILMIS, requested file is missing from input file
File name: filen
%MONITOR-E-RMSFILMIS, 1 or more requested RMS files are missing from input file

All the files are definitely present in the recording, because they display one by one with:

$ mon rms /inp=sys$monitor:filemon.dat

[Hein van den Heuvel]

Is that 'filen' just a convenient way to name the file in this topic, or is the real filename also extentionless

On the collection side MONI RMS will probably do a logical name translation for 'filen' and add a default spec of ".DAT".
For replay it might just do string matches and you would need to fully, or further, specify the name to be selected.

Just guessing... I never used replay :-).

Use the file name string(s) from the moni rms/inp output?

Actually I never use MONI RMS anymore. To little info on too many screens.

If interested in rms stats, then be sure to check out the T4 module for rms stats, as well as my RMS_STATS freeware alternative.

Hth,
Hein.

[Bryan Ross]

Yes 'filen' is just a convenient way to name the files. In the record command all the files are named in full (except version number) and I avoided using logical names.
In the playback command... I tried every combination I can think of and it doesn't work!

[John Gillings]

Bryan,

MONITOR RMS files are very fussy about the filespec. You have to use the EXACT filespec in the recording file. In some cases it may even be an invalid filespec, perhaps containing ".][" somwehere in the directory string.

Use:

$ SEARCH/FORM=DUMP FILEMON.DAT filen

to see the file name recorded. It will probably be delimited with ampersands "&". Put the entire exact filespec in the /FILE list, including version number.

You can also see the exact filespecs in the output of:

$ MONITOR RMS/INPUT=FILEMON.DAT

[Hein van den Heuvel]

The main reason I do not care for MONI RMS anymore is that it presents infomation which is only useful in combination accross multiple screens. Like; what good is a lock rate if you do not know the operation rate.

What are you using MONI RMS for? How do you use its output? What problem are you rally trying to solve? I'm always interested to find out.

Anyway... have you tried the T4 and its tools TlViz and csvpng? You might just like that as a better way to select and visualize MONI RMS data.

Start reading at:
http://h71000.www7.hp.com/OpenVMS/products/t4/index.html

-- untested hints from memory, from Steve Lieman --

Normally you'd have T4 issue the monitor rms using in T4$COLLECT to launch a $MONITOR ALL. But you have the data already.

next, look in T4$COLLECT.COM and find calls to T4EXTR. You will see that the basic one that creates the core of the .COMP file uses a NORMS
option along with NODISK and NOSCS
You will also see additional calls of T4EXTR to create a separate .DISK
file and a separate .SCS file.

You can add a new T4EXTR call to create a separate RMS file or change
the first call by removing the NORMS in which case the RMS data will be
included in the .COMP file.

Since there are about 60 or 70 stats per
file, the RMS data can get pretty big, pretty fast.

----------------
With 50 files you are probably going to want to trim it up aggresively with CSVPNG for example supressing always-zero columns and even do some [CALC] defintions to combine say all GET+FIND into an artificial read metric and all UPD+DEL+PUT into an artificial write metric, only looking at details for 'interesting' files.

Personally I like to present ratios like IOs per record operation, or LOCKS per record operation, and the old standby (but not overly useful) "cache hit rate".

We can possibly discus that further here or offline.

Better still, come to the OpenVMS Bootcamp in lovely Nashua NH Sunday May 21 to Friday May 26, 2006. Watch for details on the HP OpenVMS pages, and the www.openvms.org headlines. You can reasonably expect there to be both intermediate and advanced T4 as well as RMS sessions. (Bring your data! :-).

hth,
Hein.

[Bryan Ross]

John,

I always cut-and-pasted the exact filespecs from the
$ MON RMS /INP=FILEMON.DAT display.

If I don't include the version it just says "requested file is missing from input file".

If I do include the version it displays... the wrong file! No matter which file I try to display it always gives the second one in the list of 50.

Another thing I suspect might be relevant: All the files are in the same directory and *all have the same filename* - only the extension is different. (That's just the way the application works.) My guess is this is what is confusing MONITOR.

Hein,

We had a performance problem and suspected one of these 50 files was being accessed sequentially when it should have been using an index. Of course, I can extract that information from the recording without playing back each file individually - I just want to know why it doesn't work. We now know the problem was caused by an exclusive lock.

I've just discovered SYS$ETC and I'll certainly give T4 a try. Could it have helped to identify the locking issue, do you think?

And Nashua in May sounds a great idea! Can I give you my manager's email address?

Cheers

Bryan

[Hein van den Heuvel]

To identify the sequential reader (or not) you 'clearly' need to use my rms_stats :-),
Because your tasks proabbly needs the accumulated count, not the rate.
Also check out ANAL/SYS ... SHOW PROC/RMS=FSB
My stats tool can be found under:

http://h71000.www7.hp.com/freeware/freeware60/rms_tools/

And you probably need my 'keep_files_open' tool.
Because rms stats are kept in memory and will reset to 0 if, for a moment, no process has the file open.

I'll attach that tool.

For the bootcamp, well I am only a messenger. Sue organizes that.
Sure, let her know that I made you aware of the bootcamp.
Just keep your eyes open for the announcement(s) in a few weeks?
Last years info can be found under:
http://h71000.www7.hp.com/symposium
However, sure send that Email and I'll relay the information when it becomes available.

Hein.