f$file_attributes

[Wim Van den Wyngaert]

Why is f$file_attributes giving access conflict messages when used on open files while dir/fu isn't ?

[Ian Miller.]

which attributes are you asking for?
For some f$file_attributes has to open the file. Although I expect f$file_attrib opens the file with sharing options allowing others to access the file this is not necessarily garanteed to avoid file open conflicts.

I suspect DIR does things another way.

[Antoniov.]

Hi Wim,
I have same problem when inquire a file opened for read and write in exclusive mode; information of f$file in this way are not avaiable.
To avoid error message in command procedure usign f$file I wrote:
$ DEFINE SYS$OUTPUT NLA0:
$ DEFINE SYS$ERROR NLA0:
$ myInfo = F$FILE(myFile,"Item")
$ DEASS SYS$ERROR
$ DEASS SYS$OUTPUT
I've seen some information are empy (for example EOF return always 0)

H.T.H.
Antoniov

[Ian Miller.]

DIR command uses ACP QIOs to acquire information. F$FILE_ATTR uses RMS and is subject to the usual restrictions i.e it can't open files already opened in exclusive mode. If it gets errors then 0 can be returned.

[Wim Van den Wyngaert]

So, not a bug but a feature ?
The RMS way is simply not the way to do it I guess.

[Hein van den Heuvel]

F$FILE uses plain RMS and performance a full open to fill in FAB and XABFHC fields that are used to feed the requested data.

This fails on exclusively accessed files.
For some arguments, like EOF, one could argue it should fail because it is under control of the exclusive access stream.

DIR/FULL uses QIO access to get a snapshot of teh current values from the file header which may or might not be valid after obtained.

If desperate for this info, then I suppose you coudl parse FIR/FULL output (yuck!), or parse DUMP/HEADER output (yuck! yuck!), or write a program to do the QIO yourself (yumm!)

I would assume some customer at soem time haps already posted a formal request to resolve this and was denied. Still, you coudl try to escalate this (again) for fix in a future release. My 'shoot from the hip' reaction is that we need an RMS option to perform a read-only, header-only open. Maybe we need to make the 'UPI' bit a bit (sic!)stronger?! Or a new twist on the UFO bit perhaps? (Haven't checked... but I suspect UFO does not fill in XABs today. It could do so if XABs are present. Why not!).


[A similar question is why BACK/INGNO=INTERLOCK can read a file while no RMS usage can be used to read the file.

fwiw,
Hein.

[Ian Miller.]

Hein is THE RMS wizard and I think he is saying its supposed to work like it does. If you only wanted a few things then a small program would not be to bad. Open the file with the UPI option then use the file ACP QIOs to acquire the information you want.

[Jan van den Ende]

Ha Hein,

just thinking with my keyboard now...

Would it be too far-fetched to add some extra intelligence to f$FILE_ATT, such that: IF the file locked error is returned, THEN, for all meaningfull attributes the DIR/FULL- like header access is used, maybe with a different success status showing that this info IS from QIO, not from FAB (maybe in some situations it will be relevant (?) ).

-- Just thinking, maybe a suggestion to Guy Peleg :-)

I haven't got the faintest idea about how easy or how difficult it would be.

fwiw


Jan

[Martin P.J. Zinser]

Hi,

I do agree with Hein, certain things (like EOF) should not really reported while the file is under exclusive access, after all there most probably is a reason why the file is locked after all.

As for adding another code branch via QIO, on the one hand it sounds attractive, on the other hand it also is a sort of feature creep and makes the code definitly more complex (and therefore ultimatly more likely to fail). So maybe Guy can just do it, but maybe there are also good reasons to leave it as it is.

Greetings, Martin