Call to F$FILE_ATTRIBUTES fails with "%SYSTEM-W-ACCONFLICT, file access conflict"

[Dave Laurier]

Hi,

I have written a DCL command file that logs into a Cisco and then copies the configuration towards a TFTP server on OpenVMS. Afterwards I try to verify whether the file transfer succeeded by using the F$FILE_ATTRIBUTES lexical and check for the file size.

However, the call to F$FILE_ATTRIBUTES fails because the file is in unshared write access and I see:

SET-E-READERR, error reading TCPIP$TFTP_ROOT:[000000]RUNNING_CONFIG.TXT;2
-SYSTEM-W-ACCONFLICT, file access conflict %SYSTEM-W-ACCONFLICT, file access conflict \TCPIP$TFTP_ROOT:[000000]RUNNING_CONFIG.TXT\
%DCL-E-INVIFNEST, invalid IF-THEN-ELSE nesting structure or data inconsistency

The IF-THEN-ELSE construction that I am using is:

$ IF F$FILE_ATTRIBUTES ("TCPIP$TFTP_ROOT:[000000.''P1']RUNNING-CONFIG.TXT", "EOF") .EQ. 0
$ THEN
$ CALL SIGNAL_EVENT "EMPTY" "E" "File TCPIP$TFTP_ROOT:[000000.''P1']RUNNING-C
ONFIG.TXT is empty"
$ DELETE TCPIP$TFTP_ROOT:[000000.'P1']RUNNING-CONFIG.TXT;
$ ENDIF

Why does the lexical function not return the documented result? According to the OpenVMS DCL dictionary I should receive an integer when using the data type "EOF".

Isn't an lexical function designed to return "" if a warning occurs and not abort, thereby destroying the IF-THEN-ELSE construct?

Is the following construction the only solution to this bug/feature?

$ FILE_SIZE = F$FILE_ATTRIBUTES ("TCPIP$TFTP_ROOT:[000000.''P1']RUNNING-CONFIG.T
XT", "EOF")
$ IF (F$TYPE (FILE_SIZE) .EQS. "INTEGER") .AND. (FILE_SIZE .EQ. 0)
$ THEN
$ CALL SIGNAL_EVENT "EMPTY" "E" "File TCPIP$TFTP_ROOT:[000000.''P1']RUNNING-C
ONFIG.TXT is empty"
$ DELETE TCPIP$TFTP_ROOT:[000000.'P1']RUNNING-CONFIG.TXT;
$ ENDIF

Regards,

Dave Laurier

[Karl Rohwedder]

It seems as if the file is still opened by the FTP server, perhaps you can insert a little wait. The usual approach to check for 'locked' is to try to open the file using /ERROR label.

regards Kalle

[Dave Laurier]

Thanks for your suggestion to try to open the file and use the /ERROR construct. I consider this to be a proper work-around.

I think it is really strange that I can not use the F$FILE_ATTRIBUTES here, it even contains an item that suggests to test what I would like to know:

Item: LOCKED
Returns: String
Value: TRUE if a file is deaccessed-locked; otherwise FALSE.

When I use such a construction that first checks whether the file is locked (with F$FILE_ATTRIBUTES (... "LOCKED") then I see the same error occuring.

[Uwe Zessin]

> deaccessed-locked;

That is not the same as a file that is locked due to being open by another process. Deaccess-lock is a legacy from the RSX operating system. It means that the file was not properly closed by an application before, e.g. due to a system crash. As far as I can tell, it not used in these days.

[Wim Van den Wyngaert]

Also check this one.
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=602985

Wim

[Daniel Fernandez Illan]

Also check this threat

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=992684

[John Gillings]

Dave,

>I think it is really strange that I
>can not use the F$FILE_ATTRIBUTES here

F$FILE must open the file to access information in the header. It's subject to the same access rules as other processes. It will attempt to open the file for shared read access. If other processes that have the file open grant that access, then F$FILE will succeed.

However, if another processes has the file open for exclusive access, F$FILE will (correctly) fail with ACCONFLICT. If that happens, the return value is undefined, which means the IF statement is undefined, so the THEN/ENDIF becomes invalid.

I suppose F$FILE could have been defined to return "" (or maybe "ACCONFLICT"?) in this case, or there could be an item to explicitly ask "is this file locked" (subject to all the usual timing window issues of such things). Unfortunately for you it's not defined that way. As others have pointed out, "deaccess locked" means something completely different (and completely useless!).

This is probably worth an enhancement request to http://www.hpuseradvocacy.org/

[Dave Laurier]

Due to the behavior of F$FILE_ATTRIBUTES in case of an access conflict I have used the second mechanism as described in my original post (first put the result from F$FILE_ATTRIBUTES in a variable and then interpret that variable). This way the IF-THEN-ELSE construct is not destroyed when F$FILE_ATTRIBUTES aborts due to an access conflict.