Retrieve file attribute information about a file (like sys$display) without opening it

[madhav_poddar]

Under the con straint that I cannot open the file (using sys$open), I want to use sys$display (or something similar) to retrieve file attribute information. I am able to read the file data using IO$_READVBLK QIO operation and some of the FIB attributes using IO$_ACCESS, without opening it. But I also want to retrieve file attribute information about the file and place this information in the FAB and in XABs chained to the FAB. This functionality is carried out by sys$display which is internally called by sys$open, but in my case, I should not open the file.

When I use sys$display without opening the file, it throws the following error :

%RMS-F-IFI, invalid internal file identifier (IFI) value

So I am guessing, it is only possible to use sys$display on an opened file.

Is there an alternate to sys$display ( a function or a code snippet ) which does not not require opening of the file ?

[Hein van den Heuvel]

Asked and answerred in

- https://community.hpe.com/t5/Operating-System-OpenVMS/Open-file-with-no-locks-enabled-so-that-a-2nd-process-can-access/td-p/7011048

It includes my reply with ways to get some attributes (non-indexed file of course)

I'm dissapointed to read you even bothered to try SYS$DISPLAY wihout an RMS OPEN.

I think you should start by explaining what problem you are really trying to solve.

I suspect that even if you found a way to do this, which you are not, you'd still not be able to get what you want.

So please explain why you think you need a fake sys$display, and how this will solve the porblem you are really trying to solve (which may well be impossible to solve).

Good luck!

[madhav_poddar]

My primary objective is to backup the entire file content along with all its attributes. I cannot skip any file attribute information because that would be equivalent to data loss during restore. Also, I want to read all type of files (including the files locked by other processes) without locking the files myself (because I dont want some other application trying to open the same file using NOSHARE to crash because of that). In other words, you can say that I want to duplicate what native OpenVMS backup API does internally to read a file.

Earlier, I was using sys$open, but that would not allow other processes to acquire NOSHARE on the file and also, it would fail to open file locked by other processes as well.

The new approach that you suggested is very helpful for me and it takes me very close to my goal. You have my sincere gratitude for that. The only issue with it is that I am not able to backup certain attribute information which I was earlier able to do using sys$open. For me, skipping any file attribute information such as the ones stored in XABs, is not an option.

Thanks,

Madhav

[Hein van den Heuvel · Accepted solution]

Now we are getting closer. Seems to me you do NOT need to file XAB's. Can you not stick to the BACKUP API?

You just have to completely save the ATR$C_RECATTR bits and restore those and so on. Perfectly documented in the hard-to-get OpenVMS File system Internals book (Kirby McCoy). Why allow RMS to put on its interpretation if you can, and must, use QIO ACCESS to open the source file and create the target file.

Hardest part will probably be the Security ACE's 

Seems to me you wnat something closer to COPY than BACKUP, so you should try to read both sources.

Mind you, it took OpenVMS 20 years to get a backup API and in 40 years they never managed to build a COPY api, so I don't rate your chances of success very high. I think you'll just end up with another square wheel, differently squared, but not round and nice and perfect.

You should test with backup, to see if a file opened with IGNORE=INTERLOCK can be re-opened by a subsequent process. And you do realize that the backup-warning 'means it'. It is too easy to pick up a corrupted, unuseable file, when copying an open file, notably it is non-linear with pointers back and forwards. The copy may for example have picked up an AREA descriptor (in the first few blocks) with some block marked as still available, but subsequenly alloctaed for the 'high' end of the file. Put the copy in use, and the block maybe we double-allocated. Stull like that.

Maybe you need to step even futher back... why is the copy needed? Can it be relegated to storage hardware to software shadowing?

But hey, if they are paying you a nice salary to putz aroudn with FIBs and FATs then take the money and have fun!

I wish you Good Luck, You'll need lots.

Hein.

[abrsvc]

Reading both this posting and the other related one referenced by Hein, I feel that you are trying to hammer in anail using a wrench.  What is the actual issue/problem that you are trying to solve?  Rather than trying to find a way to do what you have thus far described, perhaps if we understand the original problem, we can provide a different solution.

Dan