[Info-vax] $GETRMI RMI$_DISKS
abrsvc
dansabrservices at yahoo.com
Mon Mar 26 08:18:14 EDT 2012
On Monday, March 26, 2012 7:49:22 AM UTC-4, 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
> >
> > >> $ 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/
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
More information about the Info-vax
mailing list