John Malmberg wrote:
> Unfortunately this is the wrong thing to do when their are multiple
> users accessing the file. If one of them modifies the file on purpose,
> that modification date gets lost.
Yes, that is true.
> Either pure RMS or ACP calls need to be used, or an extension is needed
COLLOT Jean-Yves wrote:
> John Malmberg wrote:
These open/writes should not update the file modification dates. The
only way I see around this is to track to see if the file was actually
modified and then use the XQP function to restore the dates to what they
were when the file was opened.
I co
> These open/writes should not update the file modification dates. The
> only way I see around this is to track to see if the file was actually
> modified and then use the XQP function to restore the dates to what they
> were when the file was opened.
I completely agree. That's exactly what th
>The error is in what ever routine is converting UNIX filenames to VMS.
>It is setting the ":" as a filename character, and not as a device
>delimiter.
It's the sort of thing that decc$to_vms might be provoked into if
DECC$FILENAME_UNIX_ONLY were set. I suspect folks will be in for a
whole heap
B. Z. Ledermman wrote:
DISK$STORAGE:[SAMBA-2_2_7A-SRC.SOURCE.VMS]VMS_SUPPORT.C;262:(394)
vms_statfs: $GETDVI ERROR for disk$lederman^:^[lederman^].: sts= 0144, iosb =
0144
The error is in what ever routine is converting UNIX filenames to VMS.
It is setting the ":" as a filename charac
[EMAIL PROTECTED] wrote:
You are right that GETDVIW should be better than GETDVI, but this is clearly
not the point. In addition, you CAN use a full file spec for $GETDVI, so
it's not the point either. The addressing mode of the iosb is OK too.
Correct. SYS$GETDVI/W ignores everything after the ":
The disk on which I am testing (DISK$STORAGE) is ODS-5.
Bart.
PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING:
http://www.catb.org/~esr/faqs/smart-questions.html
CTED]>
À : [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date : jeudi, 27. mars 2003 15:31
Objet : RE : Problem with VMS_SUPPORT.C
xphp-ledermanb (16.32.216.244) connect to service lederman as
user lederman (uid=12582913, gid=192) (pid 816)
[2003/03/27 07:43:54, 0]
DISK$STORAGE:[SAMBA-2_2_
xphp-ledermanb (16.32.216.244) connect to service lederman as
user lederman (uid=12582913, gid=192) (pid 816)
[2003/03/27 07:43:54, 0]
DISK$STORAGE:[SAMBA-2_2_7A-SRC.SOURCE.VMS]VMS_SUPPORT.C;262:(394)
vms_statfs: $GETDVI ERROR for disk$lederman^:^[lederman^].: sts= 0144, iosb =
01
Hi.
Could you give me a copy of the full line (or lines) of the log where the
error appears ? It should look like "$GETDVI ERROR for xxx: sts = nnn,
iosb=yyy"
You are right that GETDVIW should be better than GETDVI, but this is clearly
not the point. In addition, you CAN use a full file spec for
---
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf
> Of B. Z. Lederman
> Sent: Wednesday, March 26, 2003 12:19 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Problem with VMS_SUPPORT.C
>
>
> In case it wasn't clear, I'm still seeing erros after changing
In case it wasn't clear, I'm still seeing erros after changing
the call to what I posted in my first message: sys$getdviw and
the correct addressing mode.
The error message passed back says it's trying to do a GETDVI
with a "device" name that in fact contains a file specification
string
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
13 matches
Mail list logo
