[Info-vax] $GETRMI RMI$_DISKS

[Mark Daniel]

On 20/03/12 7:52 AM, hb wrote:
> On Mar 19, 8:31 am, Mark Daniel<mark.dan... at wasd.vsm.com.au>  wrote:
>
>> %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.
>
>> 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)

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

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

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