F$SEARCH failed

[Jan van den Ende]

Eberhard,

as long as f$search is not used on any wildcarded filespec. Because returning "" will also reset your context...

Jan

[cbkteam1]

Jan,
yes, no solution and not applicable in case of using wildcards.
Eberhard

[Wim Van den Wyngaert]

There is 1 universal solution :
$ dir/nohead/notrail/col=1/out=xxx
$ open/read x xxx
...
but this is not real time !

[Wim Van den Wyngaert]

What I still need to know :
Are there any other means of locking a directory ?

[Wim Van den Wyngaert]

Conclusion :
don't change protections on directories on active production systems.

[Antoniov.]

don't change protections on directories on active production systems.

To avoid change file protection you could use SET PROT statement as follow:
$! Set protection
$ SET PROT=(S:RWED,...)/DEF
$! here open new file

In this manner every new file assume the protection profile you have defined and you don't need change it (if it's applicable)

Antonio Vigliotti

[Jan van den Ende]

... unless for whatever reason a specific directory needs a protection that is NOT the same as your default....


Jan

[Uwe Zessin]

It is my experience that a directory inherits its protection from the parent directory and not from the process' protection mask. And a file does not inherit its protection from the parent directory's one, but from the process mask.

Both can be altered with an ACL, though.

[Eberhard Wacker]

Hi all, quote of Jan, nearly at the beginning:
... then, (and I know you read this), please, Guy Peleg, can we put this on your list?

Obviously he is not able to take part and read all of these many VMS entries in ITRC. But I'm sure several of you guys are quite familiar with him. So put him an email, I personally would also highly appreciate if f$search would send an error message in case of the directory file is locked instead of a "successfully" null string.

Cheers
Eberhard

[Martin P.J. Zinser]

Hi,

I've sent a mail to Guy with a link to this thread. Obviously this is an unconventional way to report such an issue and at best we can hope on a response on a "as time permits" basis. ITRC forums are not part of the job description for hp employees, so if they are not able to participate or react because of their regular work schedule this is maybe bad luck for us, but nothing you can complain about ;-)

Greetings, Martin