[Info-vax] $GETRMI RMI$_DISKS

[Mark Daniel]

On 26/03/12 10:19 PM, Neil Rieck wrote:
> On Mar 23, 3:12 am, Mark Daniel<mark.dan... at wasd.vsm.com.au>  wrote:
>> On 23/03/12 12:16 PM, Neil Rieck wrote:
>>> On Mar 19, 3:31 am, Mark Daniel<mark.dan... at wasd.vsm.com.au>    wrote:
>>>> Anyone with experienced with the GETRMI item.  Looks pretty
>>>> straightforward but when the code below is run (regardless of how I
>>>> tweak the buffer size) produces
8< snip 8<
> Hello Mark,
>
> I wished I would have read all the posts in this thread before I
> chimed in.

Bucket loads of time are essentially a luxury of the already retired 
Neil :-)

> First off, it looks like SYS$GETRMI is a clone of SYS$GETSPI which
> does not appear in the current OpenVMS documentation. Back in 1987-88
> when I was a VMS programmer in Toronto, that organization had
> purchased an optional product from DEC which "I think" was called SPM
> (software performance monitor). IIRC, SPM was based upon SYS$GETSPI
> and the documentation to use those calls was only installed with the
> product.

Yes.  I remember the product (not that we were funded to purchase such 
outrageously priced add-ons - I remember when AMDS was first released it 
was going to cost something like 1995-AU$100k for our sizable clusters 
of the time so we wrote our own (very-)poor-man's cluster monitor). 
Interesting that the API documentation came with the product.

I first plagiarised that interface for a command-line antecedent to HyperSPI

   http://wasd.vsm.com.au/wasd_root/SRC/HYPERSPI/spidef.h
   http://wasd.vsm.com.au/wasd_root/SRC/HYPERSPI/HYPERSPI$AGENT.C

which then soon grew into HyperSPI as the Web quickly broke over us.

> Does anyone else out there remember anything about SPI or SPM? Also,
> if anyone out there has any docs from VMS-4.x or VMS-5.x then you
> could do me a favor to see if those docs contain any mention of SYS
> $GETSPI or SYS$GETRMI.
>
> IIRC, SPM no longer worked work with VMS-6.x
>
> ###
>
> So next I decided to do a little hacking on my OpenVMS-8.4 system and
> enabled "tracing of system calls" while running the DCL command
> "monitor disk" which is documented here:
>
> http://www3.sympatico.ca/n.rieck/demo_vms_html/openvms_demo_index.html#advanced_hacking
>
> There wasn't one single instance of SYS$GETSPI or SYS$GETRMI which
> made me take a second look at the item list of SYS$GETRMI. I noticed
> that while there were items related to MSCP and SCS, there was nothing
> related to other disk storage technologies. This got me thinking that
> maybe the OpenVMS engineers stopped development of SYS$GETRMI. Why?
> Every time a new disk technology was developed, they would need to
> extend the functionality of SYS$GETRMI. So if the el-cheapo "monitor

It seems to be implemented more deeply than that, which would somewhat 
insulate it from any storage-specifics.  The sources (caveat: I am not 
an internals person) indicate that the RMI$_DISKS item locks then walks 
the I/O database looking for disk class devices, populating the supplied 
buffer space with as many device alloc classes, unit numbers, volume 
names, etc., and importantly device operation counts and current 
operation queue lengths, as it can fit into the supplied buffer space. 
So it should also be relatively efficient (at least in contrast to 
multiple calls to $DEVICE_SCAN, $GETDVI and the like).

> disk" tool is any indication, they probably do a device scan (or
> perhaps something simpler starting with a logical scan of anything
> mounted) then collect stats using other calls like SYS$GETDVI etc.
>
> Anyway, this problem is an interesting diversion so I'll probably
> continue researching it for a while.

I'd be interested in any findings.  Though now implemented using 
$GETSPI, and guessing that API won't ever go away, it would add a sense 
of completeness if it was all $GETRMI.  Damn that anal-retentiveness!

Cheers, Mark.

> Neil Rieck
> Kitchener / Waterloo / Cambridge,
> Ontario, Canada.
> http://www3.sympatico.ca/n.rieck/