Discussion:
[Info-vax] $GETRMI RMI$_DISKS
Mark Daniel
2012-03-19 07:31:46 UTC
Permalink
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);
}
hb
2012-03-19 21:22:58 UTC
Permalink
Post by Mark Daniel
%SYSTEM-F-BADPARAM, bad parameter value
As you probably know, you will get SS$_BADPARAM when either the item
code or item size is wrong.
Post by Mark Daniel
If I reduce the buffer size to 4 (longword) I get
sys$getrmi() %X00000001 IOsb: %X00000001
You said you checked the sources, there should be the expected item
size. It seems it is 4.
Post by Mark Daniel
because it initialises the disk count longword but then seems to barf on ...
It initializes the disk count and then there is no more room to store
other data.
Mark Daniel
2012-03-20 07:43:28 UTC
Permalink
Post by hb
Post by Mark Daniel
%SYSTEM-F-BADPARAM, bad parameter value
As you probably know, you will get SS$_BADPARAM when either the item
code or item size is wrong.
Post by Mark Daniel
If I reduce the buffer size to 4 (longword) I get
sys$getrmi() %X00000001 IOsb: %X00000001
You said you checked the sources, there should be the expected item
size. It seems it is 4.
Not necessarily. The minimum size is 4 (a longword to store a count of
the number of devices it returns data against). Each of those data is
RMI$C_DISK_MINSIZE (37) bytes in size. The item should return a datum
for each device until no more devices or the buffer space is exhausted.

The following URL shows the relevant header file (quoted to avoid
wrapping - at least this end)
Post by hb
http://wasd.vsm.com.au/conan/sys$common/syslib/sys$starlet_c.tlb?key=RMIDEF
and shows the data structure associated with the datum returned (quoted
for the same reason).
Post by hb
typedef struct _rmi$disk_offsets { /* DISK class information for */
/* current revision level */
short int rmi$w_disk_alloclass; /* Allocation class */
int rmi$l_disk_devname; /* Device name */
short int rmi$w_disk_unitnum; /* Unit number */
char rmi$b_disk_flags; /* Flags byte (low bit indicates served disk */
__int64 rmi$q_disk_nodename; /* Nodename */
__int64 rmi$q_disk_volnamel; /* Volume name (low) */
int rmi$l_disk_volnameh; /* Volume name (high) */
int rmi$l_disk_optcnt; /* Operation count */
int rmi$l_disk_qcount; /* Queue length accumulator */
} RMI$DISK_OFFSETS;
In my way of thinking, if I call $GETRMI with a data buffer sized at 41
bytes I should get a longword containing 1 and the rest populated with
the relevant data from the first disk device. This is also the way the
source code indicates it operates. A buffer size of 78, returns up to 2
devices, etc. Instead I get %SYSTEM-F-BADPARAM, bad parameter value.
As reported, a buffer size of 4 returns SS$_NORMAL and 0 in the
longword. A buffer size of 0 returns %SYSTEM-F-BADPARAM. This
behaviour suggests the item is functional but ...
Post by hb
Post by Mark Daniel
because it initialises the disk count longword but then seems to barf on ...
It initializes the disk count and then there is no more room to store
other data.
Precisely but as covered above, supplying appropriate space results in
%SYSTEM-F-BADPARAM. Go figure.
hb
2012-03-20 09:40:29 UTC
Permalink
Post by Mark Daniel
The following URL shows the relevant header file (quoted to avoid
wrapping - at least this end)
http://wasd.vsm.com.au/conan/sys$common/syslib/sys$starlet_c.tlb?key=...
and shows the data structure associated with the datum returned (quoted
for the same reason).
... which contains RMI$_PROC (plus struct _rmi$proc_class) as well.
But RMI$_PROC is not supported: you will get BADPARAM no matter what
buffer size is passed. RMI$_MODES seems to be the only supported item
code with variable buffer size. And its structure isn't defined in
RMIDEF.H. So I would be very cautious with conclusions from what is
visible in the include file.
Mark Daniel
2012-03-20 10:10:37 UTC
Permalink
Post by hb
Post by Mark Daniel
The following URL shows the relevant header file (quoted to avoid
wrapping - at least this end)
http://wasd.vsm.com.au/conan/sys$common/syslib/sys$starlet_c.tlb?key=...
and shows the data structure associated with the datum returned (quoted
for the same reason).
... which contains RMI$_PROC (plus struct _rmi$proc_class) as well.
But RMI$_PROC is not supported: you will get BADPARAM no matter what
buffer size is passed. RMI$_MODES seems to be the only supported item
code with variable buffer size. And its structure isn't defined in
RMIDEF.H. So I would be very cautious with conclusions from what is
visible in the include file.
Not definitive (in the sense of an emphatic 'disabled in') but you're
correct, RMI$_PROC returns the same

$ mcr [.OBJ_AXP]RALERT.EXE
CollectProcRMI()
ProcDataSize: 6700
sys$getrmi() %X00000014 IOsb: %X00000014
sys$setpri() %X00000001
%SYSTEM-F-BADPARAM, bad parameter value

Must have drawn a blank on these documented/undocumented items.

Will consider it not doable from USER mode unless advised otherwise.
Bummer. Back to the documented ones.
hb
2012-03-20 10:40:45 UTC
Permalink
Post by Mark Daniel
Must have drawn a blank on these documented/undocumented items.
You may have better luck with the undocumented $getspi and the
supplied getspidef.h. GETSPI$_DISKS and struct _getspi$disk_offsets
seem to work, as well as GETSPI$_PROC although its struct _getspi
$proc_class is broken and needs some alignment and additional members.
Mark Daniel
2012-03-20 10:54:53 UTC
Permalink
Post by hb
Post by Mark Daniel
Must have drawn a blank on these documented/undocumented items.
You may have better luck with the undocumented $getspi and the
supplied getspidef.h. GETSPI$_DISKS and struct _getspi$disk_offsets
seem to work, as well as GETSPI$_PROC although its struct _getspi
$proc_class is broken and needs some alignment and additional members.
Hmmm, fall-back to the really undocumented and deprecated API :-}

Might consider it if I wasn't so tired of working around absolutely
everything. Thanks for your input hb.
Mark Daniel
2012-03-20 17:34:13 UTC
Permalink
Post by Mark Daniel
Post by hb
Post by Mark Daniel
Must have drawn a blank on these documented/undocumented items.
You may have better luck with the undocumented $getspi and the
supplied getspidef.h. GETSPI$_DISKS and struct _getspi$disk_offsets
seem to work, as well as GETSPI$_PROC although its struct _getspi
$proc_class is broken and needs some alignment and additional members.
Hmmm, fall-back to the really undocumented and deprecated API :-}
Might consider it if I wasn't so tired of working around absolutely
everything. Thanks for your input hb.
Well of course I couldn't resist.

GETSPI$_DISKS works as suggested.

This seems to suggest $GETRMI as a fully planned but not fully
implemented equivalent documented/supported interface. Been around for
quite a while too! Don't know why the obvious should be further dwelt upon.
Neil Rieck
2012-03-23 01:46:50 UTC
Permalink
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/
Mark Daniel
2012-03-23 07:12:21 UTC
Permalink
Post by Neil Rieck
Post by Mark Daniel
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),
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.
Neil Rieck
2012-03-26 11:49:22 UTC
Permalink
Post by Mark Daniel
Post by Neil Rieck
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),
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/
abrsvc
2012-03-26 12:18:14 UTC
Permalink
Post by Neil Rieck
Post by Mark Daniel
Post by Neil Rieck
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),
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
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/
The following is from my memory(which is sketchy on the best of days...)

SPM grew out of a local DEC office project that was later turned into a product. It was merged with another product called DECPS and later became DECPM I think... The code was then sold to CA and still exists in some form.
SPM used some undocumented calls and accessed relatively undocumented hooks that were used by Monitor as well. I haven't looked at the sources in a while, but I do recall that SPM used a few services before they became "public".

The main differences between the products (and the reason for their later combination) were the emphasis on Capacity planning vs system monitoring. The "newer" DECPS also had a more elaborate interface.

I will have to look these up now. You have sparked my curiosity to revist the code.

Dan
Paul Sture
2012-03-26 12:29:42 UTC
Permalink
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.
I recall a consultant arriving at a customer site circa 1983/4 with SPM
to do a couple of days of performance analysis.

http://h71000.www7.hp.com/wizard/wiz_1412.html

----
Whither SPM?

The Question is:

What happened to SPM? I've been away from VMS for a few months and used
to use it heavily (as opposed to other fancier and more expensive
products).

The Answer is :

SPM was retired many moons ago, the last release of the product was in
1990. SPM was replaced by POLYCENTER Performance Solution back in 1993.
Computer Associates (CA) is now the vendor for this product.
----
--
Paul Sture
Neil Rieck
2012-03-26 22:18:22 UTC
Permalink
Post by Paul Sture
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.
I recall a consultant arriving at a customer site circa 1983/4 with SPM
to do a couple of days of performance analysis.
http://h71000.www7.hp.com/wizard/wiz_1412.html
----
Whither SPM?
What happened to SPM?  I've been away from VMS for a few months and used
to use it heavily (as opposed to other fancier and more expensive
products).
  SPM was retired many moons ago, the last release of the product was in
  1990.  SPM was replaced by POLYCENTER Performance Solution back in 1993.
  Computer Associates (CA) is now the vendor for this product.
----
--
Paul Sture
Try this hack:

$ lib BASIC$STARLET.TLB/text/extract=$getspidef /out=getspidef.txt
$ lib BASIC$STARLET.TLB/text/extract=$rmidef /out=rmidef.txt

$ dir/since=tod/siz/width=file=25

Directory SYS$SYSROOT:[SYSLIB]
GETSPIDEF.TXT;1 142
RMIDEF.TXT;1 219
Total of 2 files, 361 blocks.

$ dif GETSPIDEF.TXT RMIDEF.TXT /par

Notice that the two files are almost identical (except for variable
prefixes) until the point where GETSPI almost runs out of data. So it
does look like SPI was used as a starting point for RMI then a bunch
of stuff was tacked on. So why isn't SYS$GETRMI better document in the
manuals. Inquiring minds need to know :-)

Neil Rieck
Kitchener / Waterloo / Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/
Neil Rieck
2012-03-27 11:23:39 UTC
Permalink
Post by Neil Rieck
Post by Paul Sture
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.
I recall a consultant arriving at a customer site circa 1983/4 with SPM
to do a couple of days of performance analysis.
http://h71000.www7.hp.com/wizard/wiz_1412.html
----
Whither SPM?
What happened to SPM?  I've been away from VMS for a few months and used
to use it heavily (as opposed to other fancier and more expensive
products).
  SPM was retired many moons ago, the last release of the product was in
  1990.  SPM was replaced by POLYCENTER Performance Solution back in 1993.
  Computer Associates (CA) is now the vendor for this product.
----
--
Paul Sture
$ lib BASIC$STARLET.TLB/text/extract=$getspidef /out=getspidef.txt
$ lib BASIC$STARLET.TLB/text/extract=$rmidef /out=rmidef.txt
$ dir/since=tod/siz/width=file=25
Directory SYS$SYSROOT:[SYSLIB]
GETSPIDEF.TXT;1           142
RMIDEF.TXT;1              219
Total of 2 files, 361 blocks.
$ dif GETSPIDEF.TXT RMIDEF.TXT /par
Notice that the two files are almost identical (except for variable
prefixes) until the point where GETSPI almost runs out of data. So it
does look like SPI was used as a starting point for RMI then a bunch
of stuff was tacked on. So why isn't SYS$GETRMI better document in the
manuals. Inquiring minds need to know :-)
Neil Rieck
Kitchener / Waterloo / Cambridge,
Ontario, Canada.http://www3.sympatico.ca/n.rieck/
I received this (edited) information from a friend who wants to remain
anonymous:

###########################################

sys$getrmi is available OpenVMS V7.3 and later, and was intended to
provide a central and familiar interface for acquiring performance
information.

exe$getspi (note the exe$ prefix) is (was) the officially-undocumented
and private API underneath MONITOR. It is arcane, and somewhat flaky,
and does not follow the typical VMS system service API conventions.
On rare occasions, errant calls to exe$getspi have been known to crash
the OpenVMS system. Using exe$getspi usually involves looking at the
MONITOR source listings to figure out how the API works because it's
(wait for it) undocumented.

Both of these APIs were mentioned in old presentations and a few
examples of exe$getspi have been posted around the 'net. i_spi.c was
one that has been posted to places like this:
http://decuslib.com/decus/freewarev50/srh_examples
...and probably a few other spots.

SPM went to CA, and changed names. After the dust of the DEC TNSG
spin-off and sale settled, a chunk of the interesting parts of what
SPM could provide eventually became available via SDA extensions and a
few other tools.

Other options for retrieving performance data can include SNMP,
depending on what data you're after.

###########################################

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

Mark Daniel
2012-03-26 12:51:01 UTC
Permalink
Post by Neil Rieck
Post by Mark Daniel
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<
Post by Neil Rieck
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 :-)
Post by Neil Rieck
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.
Post by Neil Rieck
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
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).
Post by Neil Rieck
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.
Post by Neil Rieck
Neil Rieck
Kitchener / Waterloo / Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/
Neil Rieck
2012-03-26 21:59:27 UTC
Permalink
Post by Mark Daniel
Post by Neil Rieck
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<
Post by Neil Rieck
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 :-)
Post by Neil Rieck
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.
Post by Neil Rieck
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
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).
Post by Neil Rieck
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.
Post by Neil Rieck
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/
Loading...