F$SEARCH failed

[Wim Van den Wyngaert]

I do a f$search on 1 file several thousands of times a day. With success because the file always exists.

One day, f$search returned an empty string and this while the file did exist !!! Only once !

I found out that the only thing running was a procedure that was setting the protection of the file and the directory it is in.

I wrote a procedure to try to simulate this situation but f$search never failed.

Suggestions of what went wrong ?
I have no sys$ouput or sys$error and have never had this before during the 3 years that is is executing.

[Uwe Zessin]

Sounds like a typical race condition - you can try it a million times now, but it will never happen again.

The update could have locked the file header, but I think F$SEARCH() should have caused an error condition and not silently return an empty string.

On the other hand it is possible that the DCL symbol was already pre-loaded with an empty string, and F$SEARCH() did return a warning, but it was silently ignored. If I recall correctly, F$SEARCH() does not update the symbol when it encounters an error.

You could load the symbol with an 'impossible' filespecification and check the contents after the call to F$SEARCH().

[Wim Van den Wyngaert]

Uwe,

A "on warning" was active. So, no error or warning was given. The symbol was not initialized to "" by the procedure.

I tried to do a set prot in a loop and parallel the f$search, also in a loop. After 10 minutes there were still no problems.

[Antoniov.]

Wim,
if you have error and warning trap and you haven't received any error, the only reason of F$SEARCH() empty was the file didn't exist!
I guess your file may be deleted and rewritten or else may be procedure write always new version (as edit) with some purge command; in this situation, you could read file in very little time when file didn't exist.
As Uwe dixit it a race condition!

Antonio Vigliotti

[Petr Spisek]

F$Search() returns "" when wildcards in filename is using and condition is completes (list of suiting files). Do you use any wildcards in this case?

[Wim Van den Wyngaert]

I was able to simulate it. It does seems to be a feature/bug.

>ty wim1.lis
$a:
$ set file wim.dir/prot=w:rwed/own=system
$ set file [.wim]*.* /prot=w:rwed/own=system
$ goto a

>ty wim2.lis
$ set ver
$ on warning then exit
$ a:
$ if f$sea("[.wim]wim.lis") .eqs. "" then exit
$ goto a

I submitted the 2 files in batch on a system not doing anything else.

>ty wim2.log
08:32:29.83 $ set ver
08:32:29.83 $ on warning then exit
08:32:29.83 $ a:
08:32:29.83 $ if f$sea("[.wim]wim.lis") .eqs. "" then exit
08:32:29.86 $ goto a
08:32:29.86 $ a:
08:32:29.86 $ if f$sea("[.wim]wim.lis") .eqs. "" then exit
08:32:29.86 $ goto a
08:32:29.86 $ a:
08:32:29.86 $ if f$sea("[.wim]wim.lis") .eqs. "" then exit
08:32:29.86 $ goto a
08:32:29.86 $ a:
08:32:29.86 $ if f$sea("[.wim]wim.lis") .eqs. "" then exit
08:32:29.87 $ goto a
08:32:29.87 $ a:
08:32:29.87 $ if f$sea("[.wim]wim.lis") .eqs. "" then exit
08:32:29.87 $ goto a
08:32:29.87 $ a:
08:32:29.87 $ if f$sea("[.wim]wim.lis") .eqs. "" then exit
08:32:29.88 $ goto a
08:32:29.88 $ a:
08:32:29.88 $ if f$sea("[.wim]wim.lis") .eqs. "" then exit
08:32:29.88 $ goto a
08:32:29.88 $ a:
08:32:29.88 $ if f$sea("[.wim]wim.lis") .eqs. "" then exit
08:32:29.89 $ goto a
08:32:29.89 $ a:
08:32:29.89 $ if f$sea("[.wim]wim.lis") .eqs. "" then exit
08:32:29.89 $ goto a
08:32:29.89 $ a:
08:32:29.89 $ if f$sea("[.wim]wim.lis") .eqs. "" then exit
08:32:29.89 $ goto a
08:32:29.89 $ a:
08:32:29.89 $ if f$sea("[.wim]wim.lis") .eqs. "" then exit
08:32:29.91 $ goto a
08:32:29.91 $ a:
08:32:29.91 $ if f$sea("[.wim]wim.lis") .eqs. "" then exit
08:32:29.91 $ goto a
08:32:29.91 $ a:
08:32:29.91 $ if f$sea("[.wim]wim.lis") .eqs. "" then exit
08:32:29.91 $ goto a
08:32:29.91 $ a:
08:32:29.91 $ if f$sea("[.wim]wim.lis") .eqs. "" then exit
08:32:29.91 $ goto a
08:32:29.91 $ a:
....
08:32:30.40 $ a:
08:32:30.40 $ if f$sea("[.wim]wim.lis") .eqs. "" then exit
08:32:30.40 $ goto a
08:32:30.40 $ a:
08:32:30.40 $ if f$sea("[.wim]wim.lis") .eqs. "" then exit
SYSMGR_WVW job terminated at 27-MAY-2004 08:32:30.43

[Wim Van den Wyngaert]

Further test results.

1) VCC_FLAGS=0 -> same problem
2) 6.2 1H3 -> same problem

[Jan van den Ende]

Wim,



>ty wim2.lis
$ set ver
$ on warning then exit
$ a:
$ if f$sea("[.wim]wim.lis") .eqs. "" then exit
$ goto a



2 conditions, both EXIT procedure

Q&D: change to $ EXIT '$STATUS

other proposal:

$ On warning then goto _warning
$ if f$sea .eqs. "" then goto _EMPTY

$_warning:
---- MAIL or WRITE SYSOUTPUT or .. your favorite signalling for " At warning -- $STATUS= "
$ goto a ! Is this fleeting or persistent?

_empty:
--- similar


This way you DO make the distinction between some condition on one hand, or just FNF on the other!

From WIM1.LIS it is clear that the file definitely STAYS in existence. This rules out Antonio's suggestion (although the idea in itself was plausible enough to require verification!)

You DO have me curious!!

[Wim Van den Wyngaert]

Jan,

Tested it. It is not the warning condition but f$search that fails.
You can test it yourself on your machines. It should be the same.

My guess is that f$search considers "file or directory locked" as "file doesn't exist". While it should wait or return an error (or better : it should be an option to f$search).

[Wim Van den Wyngaert]

FYI the status is %X00010001 when the f$search fails.

Is it possible that an warning status is given without a message ? Never seen that !