Problem with VMS_SUPPORT.C

[Peter Smode]

The $GETDVI call is in vms_statfs, whose job it is to return info about the
file system; in VMS, the disk. When this procedure gets called is ultimately
the choice of SAMBA, not the VMS support extensions. Perhaps John could
chime in here with some background on the uglies of SAMBA. :)

The call to vms_get_filespec translates a Unix formatted path *relative to
the share mount point* (e.g. ".") into a VMS formatted one (e.g.
SYS$COMMON:[TNT.CLIENT], if this is the mount point,  for ".").

$GETDVI is a pretty flexible beast. It will or will not do logical name
translation depending upon whether the first character of the dev argument
starts with an "_". ($18$DKA0:[SYS0.SYSCOMMON.TNT.CLIENT]) Either way, if
the specification includes a ":", that character and all following are
disregarded ($18$DKA0).

The passing of the iosb argument is legit. This is syntax sugar for arrays,
where referring to the whole array without brackets in the procedure call
yields the starting address of the first element. Had iosb been declared as
a struct, the &iosb reference would have been required.

All that said, I believe you're right with the need for $GETDVIW instead of
$GETDVI.


Now, back to your errors. What is the argument for device name that it is
having a problem with? I wonder if we are actually seeing the error from the
previous call given that we are not using the synchronous version. A
controlled run with debug level three might be helpful here.


Peter

> -----Original Message-----
> From: samba-vms-bounces+psmode=jeslacs.bc.ca at lists.samba.org
> [mailto:samba-vms-bounces+psmode=jeslacs.bc.ca at lists.samba.org]On Behalf
> Of B. Z. Lederman
> Sent: Wednesday, March 26, 2003 8:42 AM
> To: samba-vms at lists.samba.org
> Subject: Problem with VMS_SUPPORT.C
>
>
>   I've been trying out the 2.2.7A kit on OpenVMS 7.3-1, and I've
>  noticed a problem I don't think I've seen mentioned here.
>
>     In the log.* file, I noticed there was a $GETDVI error after
>  every file accessed. So I looked around the source for where it
>  came from, and I see that the system call isn't coded properly in
>  VMS_SUPPORT.C
>
>        sts = sys$getdvi(0,0,&dev,&dvi_itm,iosb,0,0,0);
>
>     I think should be
>
>        sts = sys$getdviw(0,0,&dev,&dvi_itm,&iosb,0,0,0);
>
>     The "wait" version should be used to make sure the information
>  comes back before the program proceeds to use it.  Also, I think
>  the addressing mode on the I/O status block was wrong.  (I'm also
>  not thrilled with the declaration of iosb, but that's a separate
>  issue.)
>
>     However, this doesn't fix the underlying problem.  If you look
>  at the error code, it translates to "invalid device name".  If
>  you look at where "dev" is filled in, it calls vms_get_filespec,
>  which includes an entire file name specification.  I checked the
>  manual, and the item codes being requested for GETDVI, MAXBLOCKS,
>  FREEBLOCKS, and MAXFILES, apply only to devices, and not files.
>  (Actually, I believe all of GETDVI applies only to devices and
>  not files.)  So before calling GETDVI you need to strip off
>  everything but the device specification.
>
>     Even so, this code doesn't make obvious sense to me.  Why
>  would you need to retrieve this information when reading files?
>  I can see wanting to know how much free space remains on the disk
>  before trying to WRITE a file, but none of this is needed when
>  reading a file, and only FREEBLOCKS is of any use in telling you
>  if there is sufficient space to write a new file.  It seems to me
>  that SAMBA is doing a lot of unnecessary work here.
>
>     Suggestions?
>
>     Bart.
>
> PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING:
>
> http://www.catb.org/~esr/faqs/smart-questions.html
>