[Info-vax] $GETRMI RMI$_DISKS

[Neil Rieck]

On Mar 26, 8:51 am, Mark Daniel <mark.dan... at wasd.vsm.com.au> wrote:
> 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.htm...
>
> > 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/

Well if my boss was dumb enough to ask me to write something like
this, I might take the lazy route by first scanning all of the system
logical names looking for anything beginning with "DISK$" (which might
indicate a mounted device). Or, I might call SYS$DEVICE_SCAN like
this:

http://www3.sympatico.ca/n.rieck/demo_vms_html/bas_device_scan_demo.html

Once I had a list of mounted devices I might loop through them while
calling SYS$GETDVI

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