[Info-vax] $GETRMI RMI$_DISKS

[Neil Rieck]

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
>
> >> $ mcr [.OBJ_AXP]RALERT.EXE
> >> CollectDiskRMI()
> >> sys$getrmi() %X00000014  IOsb: %X00000014
> >> sys$setpri() %X00000001
> >> %SYSTEM-F-BADPARAM, bad parameter value
> >> $
>
> >> If I reduce the buffer size to 4 (longword) I get
>
> >> sys$getrmi() %X00000001  IOsb: %X00000001
>
> >> because it initialises the disk count longword but then seems to barf on
> >> the first disk data.  VMS V8.3 sources do not indicate this item is
> >> disabled, it is in the RMIDEF header, even though it is not a documented
> >> item in the System Services Manual.
>
> >> On both
>
> >> HP C V7.3-009 on OpenVMS Alpha V8.3
> >> HP C V7.1-011 on OpenVMS IA64 V8.4
>
> >> As always, thanks in advance, Mark Daniel.
>
> >> {
> >>      /* initialize structure for RMI items */
> >>      static struct {
> >>         short  BufferLength;
> >>         short  ItemCode;
> >>         void  *BufferPtr;
> >>         void  *LengthPtr;
> >>      } ItemList1[] =
> >>      {
> >>          { 0, RMI$_DISKS, 0, 0 },
> >>          {0,0,0,0}
> >>      };
>
> >>      int  status;
> >>      unsigned short  DiskDataSize;
> >>      char  *DiskDataPtr;
>
> >>      /*********/
> >>      /* begin */
> >>      /*********/
>
> >>      if (Debug) fprintf (stdout, "CollectDiskRMI()\n");
>
> >>      DiskDataPtr = calloc (1, DiskDataSize = RMI$C_DISK_MINSIZE * 100);
>
> >>      ItemList1[0].BufferPtr = DiskDataPtr;
> >>      ItemList1[0].BufferLength = DiskDataSize;
>
> >>      /* collect System Performance Information */
> >>      status = sys$getrmi (
> >>               SpiEfn,  /* efn */
> >>               0,  /* csiaddr */
> >>               0,  /* nodename */
> >>               &ItemList1,  /* item list */
> >>               &IOsb,  /* iosb */
> >>               0,      /* astaddr */
> >>               0 );    /* astprm */
>
> >>      if (Debug)
> >>         fprintf (stdout, "sys$getrmi() %%X%08.08X  IOsb: %%X%08.08X\n",
> >>                  status, IOsb.iosb$w_status);
>
> >>      if (VMSok (status)) status = IOsb.iosb$w_status;
> >>      if (VMSnok (status)) return (status);
>
> >>      return (SS$_NORMAL);
> >> }
>
> > The VMS docs are a tiny bit confusing unless you try to imagine it is
> > still 1978.
>
> > In the items list, we have four parameters.
>
> > P1 is the byte-size of the buffer pointed to by P3 (longs=4)
> > P2 is the item we want processed
> > P3 points to the buffer
> > P4 points to a long which will contain the actual number of bytes
> > written. Set this to zero if you don't care to know.
>
> > Sometimes it is easier to understand this stuff when you see the
> > solution done in a student language like BASIC so I spent 20 minutes
> > cobbling together this little RMI demo from my JPI demo.
>
> >http://www3.sympatico.ca/n.rieck/demo_vms_html/bas_getrmi_demo.html
>
> > Now if you want to see it done properly in C (using 64-bits no less),
> > check out this demo from Jim Duff's web site:
>
> >http://www.eight-cubed.com/examples/framework.php?file=sys_getrmi.c
>
> > Neil Rieck
> > Kitchener / Waterloo / Cambridge,
> > Ontario, Canada.
> >http://www3.sympatico.ca/n.rieck/
>
> Hi Neil.
>
> I'm one who for a number of years has frequented your ever-expanding
> site of useful and entertaining VMS items.  In fact for an equal number
> of years it has been pointed to by my own token list
>
>    http://wasd.vsm.com.au/ht_root/other/->lists.html
>
> Many thanks for these ongoing efforts.
>
> In this case, useful as the example might be to BASIC programmers
> without system service experience, the query was not how to program
> $GETRMI, or use item lists, etc., I was specifically asking for anyone
> who has had experience (by implication; positive or negative) with the
> RMI$_DISKS item of that service (the original query was poorly edited -
> and was intended to read "experienced with the $GETRMI RMI$_DISKS item"
> - type in haste, explain at leisure).
>
> When I went with the suggestion from hb to try the same with $GETSPI it
> worked as expected (should have thought of trying that myself).  This
> shows that either, 1) $GETRMI is an incomplete implementation (accepting
> the RMI$_DISKS item but not processing it correctly), or 2) there is
> some $GETRMI-specific quirk to using that item.  No-one has offered a
> definitive comment.  I lean towards the former explanation.  I had used
> the undocumented/unsupported $GETSPI API years and years ago but was
> just trying to drag myself into the late 1990s by using $GETRMI.  My
> code now uses $GETSPI for this particular item.
>
> If your BASIC example can get RMI$_DISKS to work I'd like to know!
>
> Cheers, Mark.

Hello Mark,

I wished I would have read all the posts in this thread before I
chimed in.

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.

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
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.

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